首汽约车驶向极速统一之路！出行平台如何基于StarRocks构建实时数仓？

王满 StarRocks 2023-02-18

收录于合集

作者：王满，高级数据架构工程师

首汽约车（以下简称“首约”）是首汽集团为响应交通运输部号召，积极拥抱互联网，推动传统出租车行业转型升级，加强建设交通强国而打造的网约车出行平台。

在用车服务方面，包括了即时用车、预约用车、多日接送、包车业务、接送机、国际用车、城际拼车等用车服务场景，提供出租、畅享、舒适、商务、豪华、巴士等丰富车型。首汽约车还通过数据整合和智能科技陆续推出了学生用车、老人用车等产品来满足不同人群的出行需求。随着5G时代的到来，首汽约车还开启基于5G边缘计算的网约车移动业务试点项目，探索5G时代边缘计算在出行领域的应用和拓展，推动出行行业的发展升级，引领智慧交通时代。

多样的用户人群、丰富的服务场景、持续升级的智能出行技术，带来业务分析需求的持续增加，分析需求复杂度的持续增加，构建一个强大统一的基础数据层势在必行。

#01

引入背景

—

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 查询平台并发性能较低，导致出现用户排队等待的情况，对业务方的工作效率产生了影响。

2. 指标复用性差，一致性难以保障：在业务实践过程中，派单策略、定价策略、风控策略上对实时特征的依赖日渐增加。由于缺失合适的存储层，原来使用 MongoDB 作为实时数据的存储层，无法存储大批量明细数据，只能存储维度聚合后的统计数据。因此，对于数据需求只能采用烟囱式开发，导致实时计算服务存在很多重复性开发，且数据指标的一致性难以得到保障。

3. 时效性低：企业的精细化运营越来越重要，但由于当前数据处理时效性不足，很多明细数据无法直接使用，近线数据的价值无法被充分利用；

4. 运维成本高：没有统一的 OLAP 引擎能满足大部分的分析场景，需要不同的组件搭建适配不同的业务场景，组件众多运维压力大，技术栈深且杂，业务开发学习成本高；

5. 灵活性差：单纯业务宽表场景下，业务维度变化时无法快速响应，计算模式不足以支撑越来越多的自助分析诉求。

为了给业务增长提供更强的助力，选择一款可以支持更灵活的数据模型、具有较强的并发查询性能、易于运维和使用的实时 OLAP 数据库产品，成为我们的工作重点。

#02

统一的 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、Apache Hive（以下简称 Hive）、Apache Hudi（以下简称 Hudi）、Apache Iceberg（以下简称 Iceberg）等多种外部表查询数据，重构了数据基础设施，把复杂的分析架构变得简单⽽统⼀。

4. 支持 Stream Load、Spark Load、Broker Load、Routine Load、DataX 导入、CloudCanal导入、Spark-connectors、Flink-connectors 多种导入。在离线与实时场景下，可根据实际需要灵活选择各类导入方式，稳定且可靠。

5. 对于三方组件依赖少，可以极大减小运维范围和复杂度，并且企业版还提供了可视化的运维管理平台，极大方便了日常运维使用。

6. 社区活跃，问题能够较快获得反馈和解决。版本迭代快，产品能力和产品生态圈都可以看到提升迅速。

（StarRocks 把复杂的分析架构变得简单⽽统⼀）

#03

架构演进

—

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

#04

基于 StarRocks 构建实时数仓

—

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

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

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

#05

业务实践价值

—

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

1. 在订单场景中，StarRocks 极速查询能力能够帮助将订单相关的明细数据全部导入并保存起来。数据按天分区，使用主键模型及其部分列更新的特性，将原来存储于多个系统、不同时间更新的数据写入到一张订单明细宽表，为订单业务的实时分析提供了统一的数据支撑。此外订单数据在很多场景的分析中都是需要的，因此未来可以通过在主键模型上构建物化视图，为订单分析业务拓展更多可能性，且能够保证相关数据的一致性。

2. 在司机运营分析场景中，通过 Spark/Flink Streaming 实时地将用于计算司机运营指标的数据写入到 StarRocks，然后利用其强大的多表 Join 能力，使得多维分析不再完全依赖预处理，让业务运营人员更加及时地掌握当前上线司机数量、上线时长等信息，为其精细化分析和运营提供了保障。与此同时，业务人员的查询性能体验有了至少 5 倍的提升：

场景	StarRocks *（40C、128G 、2T3）**	Presto+MongoDB *（40C、128G 、2.5T3）**
单表精确查询	1-10(ms)	5-10(ms)
单表统计查询	1-10(ms)	20-60（s）
单表范围+统计出查询	1-10(ms)	5-10(s)
联表查询（10亿 Join 300万）	3s	7(min)

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 资源占有过高的问题。我们通过控制导入并发量等措施，保证了整个集群得以健康稳定运行。

#06

业务实践价值未来规划

—

总体来说，StarRocks 拥有优秀的功能和性能，迭代快速，社区活跃，服务体系良好，能够很好支撑首约大数据部门未来的规划。下一步我们将从以下几方面继续推进：

1. 实时场景将全部迁入到 StarRocks，成为首约实时数仓统一的数据底座；

2. 接入部分离线数据，构建流批一体的数据仓库，实现极速统一的数据分析系统；

3. 加强 StarRocks 监控报警，包括数据接入、数据产出、任务监控等，及时干预，完善整体的运维体系。