首汽约车（以下简称“首约”）是首汽团体为响应交通运输部号召，踊跃拥抱互联网，推动传统出租车行业转型降级，增强建设交通强国而打造的网约车出行平台。在用车服务方面，包含了即时用车、预约用车、多日接送、包车业务、接送机、国内用车、城际拼车等用车服务场景，提供出租、畅享、舒服、商务、奢华、巴士等丰盛车型。首汽约车还通过数据整合和智能科技陆续推出了学生用车、老人用车等产品来满足不同人群的出行需要。随着 5G 时代的到来，首汽约车还开启基于 5G 边缘计算的网约车挪动业务试点我的项目，摸索 5G 时代边缘计算在出行畛域的利用和拓展，推动出行行业的倒退降级，引领智慧交通时代。
多样的用户人群、丰盛的服务场景、继续降级的智能出行技术，带来业务剖析需要的继续减少，剖析需要复杂度的继续减少，构建一个弱小对立的根底数据层势在必行。
引入背景
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 数据库产品，成为咱们的工作重点。
对立的 OLAP 实时数据库选型
选型过程中，咱们针对 StarRocks、ClickHouse、TiDB 做了一些调研和比照：
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 把简单的剖析架构变得简略⽽统⼀架构演进）
目前次要是用 StarRocks 存储大量明细数据，利用时效性高的特点，替换了原有大数据架构剖析层中依赖的 MongDB、MySQL、Redis 等数据库，从而防止了数据指标的反复开发，极大缩小了疾速变动业务下的简单开发工作。
将来，打算利用 StarRocks 弱小的物化视图、多种数据 Load 形式、表面能力，全面完成 Presto 的替换，进一步晋升大数据的 Ad-Hoc 性能。
基于 StarRocks 构建实时数仓
随着数据的增长速度越来越快，精细化经营的诉求一直减少，传统的 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 资源占有过高的问题。咱们通过管制导入并发量等措施，保障了整个集群得以衰弱稳固运行。
将来布局
总体来说，StarRocks 领有优良的性能和性能，迭代疾速，社区沉闷，服务体系良好，可能很好撑持首约大数据部门将来的布局。
下一步咱们将从以下几方面持续推动：
1. 实时场景将全副迁入到 StarRocks，成为首约实时数仓对立的数据底座；
2. 接入局部离线数据，构建流批一体的数据仓库，实现极速对立的数据分析系统；
3. 增强 StarRocks 监控报警，包含数据接入、数据产出、工作监控等，及时干涉，欠缺整体的运维体系。
将来，咱们也更加期待 StarRocks 后续版本更加弱小的性能个性：
1. 反对简单数据类型，如 Map、Struct 等；
2.RoutineLoad 反对自定义解析、单个工作可导入多张表数据；
3.Spark-connector 反对 DataFrame 写入；
4. 局部列更新不须要指定，可自适应需要更新列。