StarRocks实战——首汽约车实时数仓实践

前言

一、引入背景

二、OLAP引擎选型

三、架构演进

四、实时数仓构建

五、业务实践价值未来规划

原文大佬的这篇首汽约车实时数仓实践有借鉴意义，这里摘抄下来用作学习和知识沉淀。

前言

首汽约车（以下简称“首约”）是首汽集团打造的网约车出行平台。多样的用户人群、丰富的服务场景、持续升级的智能出行技术，带来业务分析需求的持续增加，分析需求复杂度的持续增加，构建一个强大统一的基础数据层势在必行。

一、引入背景

2016 年到2021年期间，基于 Hadoop、Spark、Presto 等组件，首约构建了集离线实时并行的 Lambda技术架构的大数据平台。离线计算基于Hadoop+SparkSQL 进行数仓建设，实时计算基于 Kafka+Spark Streaming 开发实时数据特征，数据落地到 MongoDB、MySQL、Redis等数据库，然后通过PrestoDB+Tableau Server 提供可视化的自助分析和交互式报表服务。

但随着数据累积和数据量的增长，加之精细化的管理运营需求，当前架构日渐吃力，业务上呈现出以下痛点:

1. 多维分析受限：从 2019 年到 2022 年初，业务数据量日增长近 10 倍，数据不断积累，分析维度不断细化，数据分析所涉及的维度越来越多。BI 层基于 Tableau Server 的多维分析报表，更新和查询效率都在变差，维度多的报表每天光刷新就需要几小时。而且基于 PrestoDB 实现的自助 SQL 查询平台并发性能较低，导致出现用户排队等待的情况，对业务方的工作效率产生了影响。

二、OLAP引擎选型

选型过程中，我们针对 StarRocks、ClickHouse、TiDB 做了一些调研和对比：

功能	StarRocks	ClickHouse	TiDB、TiFlash
标准 SQL	支持标准 SQL，兼容 MySQL 协议	不完全支持	支持标准 SQL，兼容 MySQL 协议
分布式Join	支持	几乎不支持分布式Join，推荐大宽表	支持
高并发查询	全面向量化引擎，提高并发查询量	不支持高并发，官方推荐 QPS为100	支持
运维	标准版：支持自动扩容、故障恢复，需要自己实现自动化部署，扩缩容节点、升级等，有一定开发工作企业版：管理界面，提供集群 DashBoard、SQL Profile、监控报警等功能	依赖 Apache Zookeeper，运维成本	运维方便
社区	开源活跃度高，社区论坛回复快	开源社区发展多年，但中文社区支持较少	开源社区积极良好
性能	读写性能好	单机性能强悍读性能比 StarRocks 差一些；写性能好	轻量级分析良好，数据量大时性能不如 StarRocks；写性能受限于 TiKV，一般
场景	纯分析场景	纯分析场景	使用HTAP 场景
其他	生态组件丰富		稳定性高

TiDB 适用在一些轻量级的分析场景，但对于一些数据量大、复杂查询的性能不尽人意。所以我们主要在 ClickHouse 和 StarRocks 中做选择：

在AP(分析)业务中，不同于以点查为主的TP(事务)业务，事实表和维度表的关联操作不可避免。但在一些灵活度要求较高的场景，比如订单的状态需要频繁改变，或者说业务人员的自助BI分析，宽表往往无法满足我们的需求，我们还需要使用更为灵活的星型或者雪花模型进行建模。

ClickHouse虽然提供了Join的的语义，但使用上对大宽表关联的能力支撑较弱，复杂的关联查询经常会引起 OOM，所以如果使用了ClickHouse，需要再ETL的过程中就将事实表与维度表打平成宽表。而StarRocks提供了Shuffle Join，Colocate Join，Broadcast Join、Bucket Shuffle Join 等多种Join模式，对于提升联表查询场景性能有着非常大的优势。

通过以上产品能力上的初步对比，我们已经比较倾向于选择 StarRocks。从使用和未来规划角度，我们继续对 StarRocks 进行了评估，双方在以下几方面具有很好的契合度：

1. 能够支撑 PB级别数据量，拥有灵活的建模方式，可以通过向量化引擎、物化视图、位图索引、稀疏索引等优化手段构建极速统一的分析层存储系统。
2.兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。可以轻松平稳地对接多种开源或者商业BI工具，比如Tableau、FineBI。
3. 支持 MySQL、StarRocks、Elasticsearch、 Hive、Hudi、Iceberg等多种外部表查询数据，重构了数据基础设施，把复杂的分析架构变得简单⽽统⼀。
4. 支持 Stream Load、Spark Load、Broker Load、Routine Load、DataX 导入、CloudCanal导入、Spark-connectors、Flink-connectors 多种导入。在离线与实时场景，可根据实际需要灵活选择各类导入方式，稳定且可靠。
5. 对于三方组件依赖少，可以极大减少运维范围和复杂度，并且企业版还提供了可视化的运维管理平台，极大方便了日常运维使用。
6. 社区活跃，问题能够较快获得反馈和解决。版本迭代快，产品能力和产品生态圈都可以看到提升迅速

StarRocks 把复杂的分析架构变得简单而统一

三、架构演进

目前主要是用StarRocks存储大量明细数据，利用时效性高的特点，替换了原有大数据架构分析层中依赖的MongDB、MySQL、Redis 等数据库，从而避免了数据指标的重复开发，极大减少了快速变化业务下的复杂开发工作。未来，计划利用StarRocks强大的物化视图，多种数据Load方式、外表能力、全面完成Presto的替换，进一步提升大数据的Ad-Hoc（数据探索）性能。

四、实时数仓构建

随着数据的增长速度越来越快，精细化运营的诉求不断增加，传统的T+1离线数仓构建模式，很难满足业务运营的增长需求。越早洞察数据，越早拿到分析指标结果，才能帮助业务把握先机。数仓时效性由此逐渐从天级提高到小时级，分钟级乃至秒级。

于是，我们采用了StarRocks构建了实时数仓：

通过FlinkCDC从kafka摄入业务数据写入StarRocks，构建了实时数仓ODS层，外部调度组件通过SQL完成ETL计算，通过微批方式写入DWD层；DWD层进一步统计聚合写入DWS，或者直接利用物化视图构建DWS层。
流式系统兼容，Flink/Spark Streaming 从 Kafka摄入数据，进行业务计算。通过StarRocks提供的Connector连接器将实时计算结果写入StarRocks实时数仓DWS层，在实时场景中实现统一OLAP分析。

引入StarRocks 之后，我们已经对订单分析、司机分析、风控分析、算法策略等场景的数据生产过程进行了改造:

1.在订单场景中，StarRocks极速查询能力能够帮助将订单相关的明细数据全部导入并保存起来。数据按天分区，使用主键模型及其部分列更新的特性，将原来存储于多个系统，不同时间更新的数据写入一张订单明细宽表，为订单业务的实时分析提供了统一的数据支撑，此外订单数据在很多场景的分析中都是需要的，因为未来可以通过在主键模型上构建物化视图，为订单分析业务拓展更多可能性，且能够保证相关数据的一致性。
2. 在司机运营分析场景中，通过 Spark/Flink Streaming实时地将用于计算司机运营指标的数据写入到StarRocks，然后利用其强大的多表Join能力，使得多维分析不再完成依赖预处理，让业务运营人员更加及时地掌握当前线上司机数量，上线时长等信息，为其精细化分析和运营提供了保障。与此同时，业务人员的查询性能体验了至少5倍的提升：

3.在实时风控场景下，能否保障数据的时效性，对于企业损失控制具有重要意义。以司机运营活动的作弊识别为例，之前由于作弊识别滞后的时间较长，存在先发奖又扣走的情况，使得司机的体验变差，且有成本损失风险。将风控识别实时化后，能极大避免此类问题。再比如某些渠道待付率异常上涨，若能实时识别、及时干预，就能减少不必要的损失。之前风控特征使用的是离线集群T+1产生的数据，且整个过程需要复杂代码才能实现。

引入StarRocks后，我们将kafka的数据通过Flink CDC的方式写入到ODS层，之后利用SQL 以微批的方式构建DWD和DWS层，对于实时性高的数据，则通过Spark Streaming/Flink后，再利用StarRocks提供的Connector写入到DWS层，最终指标的计算直接通过SQL查询DWS层即可完成。这不仅使得风控预警更加及时，也对风控指标的快速调整提供了重要支撑，当维度变化或增加新需求时，工作量从5天缩短到2-3天即可完成。

4. 在算法策略中，更实时的数据和更加灵活的模型特征构建，可以帮助业务团队更快对市场和竞争上的变化做出响应。以动调策略模型迭代为例，动调是平衡供需的重要手段，动调实验结果时效性的提高，可以极大提升业务团队的开城效率。我们正在尝试和算法团队一起，利用 StarRocks 极速查询的能力来提升实时特征构建效率，加速模型的迭代速度，工期预计缩短 70% 以上，为业务团队更灵活应对业务变化提供助力。

基于StarRocks搭建实时数仓的过程中，我们也遇到了一些问题，和StarRocks沟通找到的解决和优化方案如下：

1. 在 Flink中使用StarRocks维表做关联时，有时QPS（并发）过高导致整个集群查询性能下降。可以通过规避多条数据一次查询，合理设置分区等措施，提升了查询的并发数；
2. 实时数据导入时，有时写入频率过快，可能会导致版本过多/不健康副本的问题。通过设置Spark合并分区或重新分区方式来控制写入，调整Flink Sink并行或者Flink Connector并发的方式控制写入，有效解决了问题：
3. 多表 Join有时出现内存过高的问题。一方面在可接受的查询性能范围内，设置查询的并发度，查询调整内存参数等，另一方面，业务开发层面对查询任务进行分解，数据进行预计算，计算整合预计算结果，分而治之，减小了查询对集群的压力；
4.离线数据通过Broker导入时，会出现BE资源占有过高的问题。我们通过控制导入并发量等措施，保证了整个集群得以健康稳定运行。