StarRocks实践

文章概览

• 业务背景

• 应用实践

• 未来规划

作者介绍：

任志民，2023年加入去哪儿旅行数据平台团队，主要负责数据平台OLAP引擎基础建设和相关数据产品研发工作。

一、业务背景

去哪儿网的数据平台为了满足各业务线的看数、取数、用数需求，沉淀出多种数据产品，包括QBI看板、质检系统、即席/SQL分析、趣分析、离线圈人、实时营销等。这些数据产品依赖于多种计算引擎和数据存储来满足不同的业务场景需求。例如：

• Trino、Presto：基于Hive数据分析，应用于看板、即席分析场景

• Impala、kudu：业务系统埋点数据实时写入，Hive离线、kudu实时数据联邦分析

• Druid：kafka数据实时写入，应用于看板

• Clickhouse：Hive数据离线导入，应用于用户分析、离线圈人场景

然而，多引擎架构带来了诸多挑战，如引擎之间的兼容性问题、性能瓶颈、运维成本高等。因此，去哪儿网决定对现有的计算架构进行升级，引入一种更为高效、统一的数据处理方案。

（一）选型与评估

在选型过程中，对StarRocks、ClickHouse、Trino、Kylin等多个引擎进行了深入调研和评估。从场景覆盖度、查询性能、运维难度等多个角度综合考虑，StarRocks表现优异，最终成为去哪儿网数据平台升级的首选方案。

1. 场景覆盖度

2. 写入能力对比

（1）StarRocks

 • 支持Flink/Kafka实时摄入+ 批量导入（broker load）

 • 独创的Primary Key模型支持UPSERT（类似Kudu）

（2）ClickHouse

 • 更适合批量导入（如INSERT INTO SELECT）

 • 实时写入依赖Kafka引擎表+物化视图，链路复杂

（3）Trino

 • 本质是查询层，写入依赖底层存储（如HDFS/S3）

 • 无法自主优化数据布局

（4）Kylin

 • 必须通过Cube构建作业（通常小时/天级延迟）

 • 无法处理实时更新

3. 运维成本的关键考量

另外当前看板平台引擎以Trino为主，StarRocks支持了Trino方言，兼容率达到了90%，经过二次开发后兼容率达到了99%，这样可以极大的提高迁移效率，降低了迁移成本。

（二）StarRocks简介

StarRocks 是新一代极速全场景 MPP (Massively Parallel Processing) 分布式数据库。可以满足企业级用户的多种分析需求，包括 OLAP (Online Analytical Processing) 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等。

StarRocks的架构简单，分为前端和后端。前端节点称为 FE。后端节点有两种类型，BE 和 CN (计算节点)。当使用本地存储数据时，需要部署 BE；当数据存储在对象存储或 HDFS 时，需要部署 CN。StarRocks 不依赖任何外部组件，简化了部署和维护。节点可以水平扩展而不影响服务正常运行。此外，StarRocks 具有元数据和服务数据副本机制，提高了数据可靠性，有效防止单点故障 (SPOF)。

（三）StarRocks特性-MPP架构

StarRocks采用的是MPP分布式执行框架，一条查询请求会被拆分成多个物理计算单元，在多机并行执行。每个执行节点拥有独享的资源（CPU、内存），能够使得单个查询请求可以充分利用所有执行节点的资源。

以下图为例，查询SQL在经过词法、语法解析、生成逻辑计划、逻辑计划重写、CBO优化器后，最终生成了物理执行计划。每个物理计划是由一系列的操作算子组成，例如Frgment2包含了Scan、Local Aggregate、DataSink。每个物理执行计划又会按照实际处理的数据量大小，生成多个实例执行，每个实例是最小的执行单元，会调度在BE节点执行。不同逻辑执行单元可以由不同数目的物理执行单元来具体执行，以提高资源使用率，提升查询速度。

（四）其他特性

另外StarRocks具备其他特性，例如全新的CBO优化器，在复杂的多表关联场景下，优秀的优化器可以选择一个更优的执行计划，这样才可以保障极致的查询性能。智能物化视图，可以用于数仓分仓、查询加速，StarRocks的物化视图支持基表更新、物化视图同步更新的策略。

二、应用实践

（一）集群现状

目前去哪儿网的StarRocks集群已经覆盖了全司业务线，包括7个数据产品。集群规模达到数百级，最大单集群规模达到几十台。日PV近百万+，外表P95耗时秒级，内表P95耗时毫秒级。这些性能指标充分证明了StarRocks在去哪儿网数据平台中的高效性和稳定性。

（二）新数据平台架构

在新数据平台架构中，StarRocks作为统一的OLAP计算引擎，替代了原有的Trino、Presto、Druid、Impala、kudu、Iceberg、Clickhouse等多个引擎。这一变革极大地简化了数据平台的运维工作，降低了运维成本。同时StarRocks的高性能也提升了数据平台的整体查询性能。

新的数据平台演进主要分为基础建设、业务产品落地两个阶段。

（三）基础建设

为了保障StarRocks集群的稳定性和高效性，去哪儿网在基础建设方面做了大量工作。包括建设可观测、高可用的StarRocks集群，并基于StarRocks建设统一的查询服务。通过采集服务、监控告警、节点自愈等技术手段，实现了对StarRocks集群的全面监控和管理。此外，还通过分区裁剪、物化缓存等技术手段对查询性能进行了优化。

1. 可观测性-指标监控

为了全面掌控StarRocks集群的运行状态，我们决定将StarRocks的指标信息与公司内部的监控系统实现无缝对接，以此为基础构建一套完善的监控与管理体系。具体而言，我们将主要开展以下工作：

（1）优化StarRocks的指标信息体系：我们对StarRocks进行改造，以丰富和完善其现有的指标信息。在此过程中，我们将特别关注那些对集群性能有重要影响的关键指标，如访问HDFS和MetaStore的相关耗时等，并考虑将它们作为自定义指标纳入监控体系。这将有助于我们更准确地了解集群的实时运行状况，及时发现潜在的问题。

（2）采集StarRocks的metrics数据并集成到监控系统中：部署专门的采集服务，用于实时抓取StarRocks的metrics数据。这些数据将被实时传输到watcher（监控系统的核心组件）中，由后者进行进一步的处理和分析。通过watcher，我们可以实现对StarRocks集群的实时监控，包括性能指标、健康状态等关键信息的展示和告警。

（3）部署常驻服务以实现自动化处理：为了提升集群的运维效率，在集群节点上部署常驻服务。这些服务将负责接收watcher发出的回调信息，并根据预设的策略进行自动化处理。例如，对于某些可以通过重启恢复正常的节点故障，常驻服务可以实现节点的自动重启，从而大大缩短故障恢复的时间。

通过上述措施的实施，我们将能够建立起一套高效、可靠的StarRocks集群监控与管理体系，为集群的稳定运行提供有力保障。

2. 高可用-集群灾备

为了确保对外提供稳定且高效的服务，集群灾备方案的实施是不可或缺的。在集群的设计过程中，我们深入考虑了业务的独特性质，包括使用高峰时段、严格的响应时间要求以及容错性需求。例如，看板服务的访问主要集中在每天的10点至20点，且对响应时间有着极高的要求；而邮件服务则主要在0点至24点进行访问，对响应时间的要求相对较低，但对容错性有着较高的标准。为了应对这些不同的业务需求，我们做了以下工作。

（1）搭建了两个独立的集群（StarRocks1和StarRocks2）。看板、邮件服务均接入统一的查询服务，该服务根据业务类型智能地路由到不同的集群（看板服务路由到StarRocks1，邮件服务路由到StarRocks2），从而实现了物理层面的隔离。

（2）针对看板服务在特定时间段内资源利用率较低的问题，我们充分利用了StarRocks的CN节点快速上下线的特性。在非高峰时段，即非10点至20点的时间段内，我们将StarRocks1集群中的部分CN节点下线，并将这些资源灵活地扩容到StarRocks2集群中，以应对质检和邮件服务在夜间高峰时段的资源需求。

（3）此外，为了避免邮件服务和质检服务在StarRocks2集群中可能产生的资源竞争问题，我们运用了StarRocks的资源组功能，实现了业务之间的隔离。这不仅确保了每个业务都能获得所需的资源，还提高了整个系统的稳定性和可靠性。

通过这一系列精心设计的策略，我们成功地构建了一个既高效又灵活的集群系统，能够充分满足各种业务的复杂需求。

3. 查询性能-性能优化

StarRocks作为一个功能强大的开源产品，虽然在多数情况下能够提供出色的性能和功能，但在某些特定的应用场景中，仍然存在一定的优化空间。为了更好地满足我们业务的需求，我们结合实际使用场景，对StarRocks进行了一系列有针对性的优化。

如下图，两个SQL语义相同，查询Hive表的昨天分区的一条数据，但是执行情况却相差很大，包括扫描的分区数、读取的数据量、以及最终的查询耗时。

于是我们通过分析进行了特定优化。

（1）对SQL的解析流程进行了详尽的分析，从SQL文本输入到最终生成物理执行计划，整个流程涵盖了词法分析、语法分析、逻辑计划生成、逻辑计划重写、基于代价的优化（CBO）以及物理计划的最终确定。在深入剖析这一流程后，我们发现生成逻辑计划和逻辑计划改写这两个环节对SQL执行计划的影响尤为显著。

（2）在生成逻辑计划的过程中，系统遵循一系列预定义的规则来进一步简化关系表达式。

（3）其中FoldConstantsRule规则扮演着至关重要的角色，它专注于常量折叠，通过不断迭代操作符，对函数类型的操作（如callOperator）利用预置的函数进行反射调用，从而提前计算出常量值，实现表达式的简化。

（4）以date_format(days_add(now(), -1), %Y-%m-%d)为例，具体的递归结果如下。

（5）随后在逻辑计划改写环节，系统进一步应用分区裁剪等优化规则，以减少不必要的数据扫描和处理，提高查询效率。

（6）经过深入的分析和讨论，确定jodatime_format函数没有折叠是因为缺少相应的解析函数，因此在生成逻辑计划的阶段新增jodatime_format方法。这个方法将利用Joda-Time库（或类似的日期时间处理库）来更高效地处理日期和时间的格式化操作，从而进一步提升SQL解析和执行的效率。通过这一优化措施，能够为用户提供更加快速和准确的查询服务。

（四）应用落地

StarRocks凭借其强大的查询分析能力，完美支持了对Hive、Pamion等数据湖存储平台的深度整合与高效查询。这一特性使得StarRocks能够轻松驾驭看板展示、即席查询、质量检测等多种复杂分析场景，为用户提供了前所未有的数据洞察能力。在存算分析方面，StarRocks更是展现出了其独特的优势。它支持实时导入和离线导入两种灵活的导入方式，为用户提供了极大的便利，已经成功应用于趣分析、基础平台、CDP等多个产品，同时在机票价格分析、漏斗分析、机票售后服务等场景中，也展现出了其强大的分析能力和应用价值。

1. 最佳实践-QBI看板

QBI看板简介

QBI看板是去哪儿网数据平台中的重要应用之一。QBI看板实现了自助化看板配置，承载了全司的报表业务，月PV是百万级别、月UV是千级别。通过视图、图表、看板分层，实现了数据与可视化的解耦以及数据复用。这些特性极大地提升了QBI看板的使用效率和用户体验。

QBI看板应用效果

自3月份起，QBI看板项目踏上了逐步迁移的征程，并在4月份圆满完成了整个迁移过程，随着迁移工作的持续推进，QBI看板的查询性能越来越好。具体来看，2月份时，查询P95还徘徊在5.7秒的较高水平；而到了4月份，随着迁移工作的逐步完成，查询P95已经显著下降至3.3秒；5月份，这一指标进一步优化至2.4秒，实现了近乎翻倍的性能提升。

挑战与方案

（1）结果一致性保障

引擎切换需要保障结果一致性以及迁移过程对用户透明。因此我们建立了完善的校验体系、保障了平滑的迁移。主要工作包括：

a. 自主研发智能化比对工具链

• 实现全量SQL采集与自动化回放验证

• 支持多维度结果比对（数值精度容错、NULL值等价判断、排序规则标准化）

• 智能归因分析引擎，自动分类不一致场景

b. 动态路由保障体系

• 基于一致性校验结果的智能路由决策

• 双引擎无缝切换机制

• 故障自动降级策略，确保业务连续性

• 全流程用户无感知迁移方案

（2）语法兼容性挑战

针对StarRocks与Trino语法体系的兼容性挑战（基准兼容率90%），如果需要手动兼容，工作量巨大且容易出错。因此我们改造StarRocks来实现最后10%的兼容，主要涉及复杂函数语义、特殊语法结构和执行逻辑等核心难点，主要工作包括：

a. DDL语法增强

• 支持CTAS（CREATE TABLE AS SELECT）语法

• 支持INSERT INTO语法兼容

b. 函数库深度对齐

• 实现dow/week等日期函数语义统一

• 开发date_parse/parse_datetime等时间解析函数

• 支持from_iso8601_timestamp等ISO格式处理

c. 特殊值处理

• 统一NULL值语义处理标准

（3）迁移流程图

2. 最佳实践-趣分析迁移

趣分析是去哪儿网提供的一款灵活自助的多维分析工具，实现了对后端埋点数据和离线数仓表的接入分析。同时通过SQL拆分、碎片缓存、结果拼接等技术手段，提升了查询性能和分析效率。

趣分析架构

（1）离线数据无需写入，数据存在 HDFS 上，Trino 连 Hive 可直接读表查询。

（2）实时数据来源包括实时数仓、规范化埋点实时数据等，通过 Kafka 由 Flink 实时写入 Kudu 表作为热数据，同时写一份到 HDFS 做为冷数据和备份

（3）在 Hive 表和 Kudu 表基础上建 Impala 视图，将离线和实时数据表 Union 在一起，以供查询。

迁移过程

为了确保趣分析平台上近200个项目能够顺利且平稳地完成迁移，我们主要采取以下策略：

（1）在数据写入层采用双写，同步写StarRocks、Kudu，同时会做数据一致性校验，保证数据的完整性、准确性。

（2）在数据查询层，增加路由信息，以根据实际需求自动或手动调整查询引擎。

（3）在切换查询引擎前，进行了详尽的性能测试，以确保StarRocks能够满足业务需求，同时做了语法校验，保证查询结果的一致性。

挑战与方案：如何保障数据低延迟？

为了保证实施数据的低延迟，对Flink任务进行了分析，主要分为3个环节，kafka-source负责读取数据，data-transform负责做数据转换，sr-sink负责把数据写入到StarRocks。

其中sr-sink是采用的StarRocks提供的connector，基本原理是在内存中积攒小批数据，再通过 Stream Load 一次性导入 StarRocks。

为了保障数据低延迟同时又不增加导入StarRocks频率的有效方法是把相同项目的数据，发送到同一组的sr-sink算子， 使内部尽快达到行数或者字节数的条件。同时为了保证数据延迟的可观测性，采集了算子的相关指标，进行监控。

3. StarRocks改造以及社区贡献

在StarRocks的落地过程中，我们对StarRocks做了改造，包括提高Trino语法兼容率（90% -> 99%)；改造优化器支持语法裁剪；增加自定义参数、自定义指标，提高集群的自我保护机制，并向社区提交多个PR。

具体功能改造，举例如下：

三、未来规划

（1）在当前数据驱动决策的时代背景下，企业对于数据仓库的扩展能力、灵活性、可靠性及稳定性提出了更为严苛的要求。为此，我们未来会把StarRocks部署于公司自建的Kubernetes集群之上，旨在借助Kubernetes的强大基础设施管理能力，为StarRocks提供一个更加健壮、灵活且易于扩展的运行环境。

（2）在实时数仓场景中，利用物化视图的多层构建和同步更新机制，可以显著提升查询性能，为了实践该特性，为企业提供了更为实时、准确的数据支持，助力业务决策的高效进行。

疑问？为什呢没用Doris