关于后端:驶向高效运营StarRocks-助力蔚来汽车数据分析再升级

4次阅读

共计 7186 个字符，预计需要花费 18 分钟才能阅读完成。

作者：蔚来汽车数字化业务发展部大数据团队

小编导读：
蔚来汽车是一家全球化的智能电动汽车公司，是高端智能汽车市场的先驱及领跑者。蔚来致力于通过提供高性能的智能电动汽车与极致用户体验，为用户发明愉悦的生存形式。
为了晋升外部大数据分析的效率，蔚来陆续尝试了多种组件，如 Apache Druid、TiDB 和 Apache Doris，最终抉择了 StarRocks，落地场景蕴含：用户画像平台、数据经营平台、BI 自助取数和整车三电可靠性数据库。引入 StarRocks 之后，在不同场景下别离有 4-8 倍的晋升。

蔚来汽车外部有丰盛的 OLAP 应用场景需要，包含销售潜在客户人群圈选、供应链 / 生产 / 物流时效看板、车主用车行为剖析、车辆电池报警监控、售后培修归因等。

为了晋升大数据分析的效率，咱们陆续尝试了多种组件，如 Apache Druid、TiDB 和 Apache Doris，最终咱们抉择了 StarRocks。相较于同类 OLAP 产品，StarRocks 体现出以下显著劣势：

反对较高水平的并发（主键模型）
实时与离线剖析的双重反对
反对明细和聚合模型
反对肯定水平的更新
优良的 Rollup 和物化视图能力，显著晋升了查问效率
兼容 MySQL 协定，开发和应用老本比拟低
全面的向量化引擎，反对 SIMD 指令，读写性能十分优异，满足咱们的要求
架构简洁，运维老本比拟低

首先咱们来疾速回顾下 StarRocks 的架构。StarRocks 架构简洁，整个零碎的外围只有 FE（Frontend）、BE（Backend）两类服务过程，不依赖任何内部组件，不便部署与保护。FE 和 BE 模块都能够在线程度扩大，元数据和业务数据都有正本机制，确保整个零碎无单点。StarRocks 提供 MySQL 协定接口，反对规范 SQL 语法。用户可通过 MySQL 客户端不便地查问和剖析 StarRocks 中的数据。FE 是 StarRocks 的前端节点，负责管理元数据，治理客户端连贯，进行查问布局，查问调度等工作。每个 FE 节点都会在内存保留一份残缺的元数据，这样每个 FE 节点都可能提供无差别的服务。BE 是 StarRocks 的后端节点，负责数据存储、SQL 执行等工作。

（StarRocks 架构简洁且提供 MySQL 协定接口）

在咱们的大数据架构中，来自 Kafka/Hive 的业务 / 用户数据源，通过 Broker Load/Routine Load/Stream Load/Flink Connector 等多种离线 / 实时导入形式写入 StarRocks，次要用来存储 DWD/DWS/ADS 层的数据，用于离线和实时指标的疾速剖析。咱们深度自研的 DataSight 一站式数据治理与开发平台，曾经集成了 StarRocks，反对通过配置化形式不便的读写 StarRocks。
将历史工作迁徙到 StarRocks 后，改善和收益不言而喻。无论是查问速度还是运维老本，都失去了晋升。以某车辆数据指标的 BI 服务为例，过来该指标采纳 Druid 和 Cassandra 两种数据库存储，在迁徙到 StarRocks 后，通过正当的 Rollup 策略，均匀查问提早从 2s+ 升高到 500ms，查问效率进步 4-5 倍，并且仅需应用一种 OLAP 查问引擎。
目前，公司已有 20 多个业务线开始应用 StarRocks，广泛应用于研发、生产制作以及用户车辆经营等多个畛域的业务 BI 看板和指标大屏。

StarRocks 在咱们团队次要有几个典型的利用场景：用户画像平台、数据经营平台、BI 自助取数、整车三电可靠性数据库等。

蔚来数字化业务倒退部门自主研发的用户画像平台是具备标签、分群、洞察和触达能力的平台，能够帮忙业务全方位理解用户。这个平台全面帮忙业务部门深刻理解用户，通过标签圈选人群，生成用户画像定制个性化内容，并在用户生命周期中与他们进行深刻互动。同时，平台会主动跟踪触达成果，确保高效地为用户提供极致贴心的服务。
用户画像平台次要应用 StarRocks 来存储用户的标签和分群数据，利用 StarRocks 弱小的数据分析能力，能够通过用户的标签自由组合出各类用户画像，并使用于营销、经营、服务和数据分析等泛滥场景。

如图所示，咱们用户画像平台次要蕴含以下几个局部：

离线标签局部：应用了 Spark 工作计算出日级更新的标签，并导入 StarRocks 的离线标签表。
实时标签局部：应用了 Flink 工作实时监听业务数据库表变更，并实时进行数据加工解决，最初将实时标签数据导入到 StarRocks 的实时标签表。
算法标签局部：蕴含了离线的打标和实时的打标，最终数据都会进行到 StarRocks 相干表里。
数据服务局部：联合离线和实时标签数据，计算出各类分群数据，并存储到 StarRocks 分群表，在此基础上对外提供标签和分群服务，下层业务零碎可据此构建各种各样的基于特定人群的性能。

数据经营平台次要为一线服务人员提供低时延、低代码、多维分析等性能的云表格和图表产品。对数据应用有如下特点：

较低延时：业务数据产生到可应用，以秒级提早为主，分钟级~ 小时级提早为辅。
灵便应用：剖析指标多样性，指标由平台应用人员依据明细自在利落组合产生。
大数据聚合和极速查问：蕴含业务全生命周期数据，99th 查问须要在 3s 以内。
多种更新周期：同一数据表的不同字段的更新周期不同（有近实时、小时级 T+1、天级 T+1）。

StarRocks 反对流式数据和 HDFS 内部离线数据导入、主键模型局部列更新(Partial Update)、分区原子替换、分区数据裁剪以及索引等能力，很好的贴合以上数据应用的特点。在数据经营平台的落地过程中，咱们遇到了一些 StarRocks 应用上的问题，在社区踊跃的技术支持下逐个失去了解决和优化，以下是一些具体例子：

物化视图 (MATERIALIZED VIEW) 导致 Disk Storage 只增不减及查问无奈命中物化视图

StarRocks DWS 表由 DIM 表和 DWD 表关联后失去，原构想 DWS 应用多表关联建设 MATERIALIZED VIEW，同 Rollup 表一样是能够在 DWS 中及时对 DIM 和 DWD 的行级变更做出更新，在 StarRocks v2.4.3 版本验证应用过程中发现 MATERIALIZED VIEW 底层实现为 insert overwrite，Disk I/O 耗时较大，实测 500w 的数据行大概须要 10s~15s，须要更新数据量的大小间接影响了数据的更新时效。
创立的 MATERIALIZED VIEW 会导致 Disk Storage 只增不减，反馈 StarRocks 社区后定位为 bug，后续曾经修复。
另一个问题是查问执行打算无奈命中物化视图，经排查得悉创立初始表时采纳的流式写入形式是造成该问题的起因。在周期性更新的表中，物化视图可能被无效利用（在更新周期内），但对于初始表则无奈实现。因而，采纳 MATERIALIZED VIEW 形式要思考实用场景和限度。

并行 Insert Load 导致 Mem 和 CPU 负载过高
因为物化视图存在的问题，DWS 层的产出受到限制。为了克服这个问题，咱们采纳了与底层实现雷同的 insert overwrite 办法，通过多个规定，包含分区规定和数据量规定，对数据进行分片更新。为确保所有 DWS 层数据简直同时产出，咱们为所有 DWS 表配置了雷同的调度频次和工夫。在 DWS 更新过程中，曾呈现 CPU 和 MEM 过高的状况，但起初通过优化，咱们采纳了几个优先级队列来串行更新，从而放弃 CPU 和 MEM 的占用绝对安稳，最大限度地缩小了资源热点问题。下图显示了资源占用在优化前后的变动状况：

优化前资源占用状况：

优化后资源占用状况：

只管咱们曾经进行了优化，Insert Load 的资源占用仍比 Broker Load 和 Routine Load 高很多。为了进一步改善 DWS 的数据产出，咱们会基于 Flink+Iceberg 做 row-level 级别的更新，这样 StarRocks 集群只作为存储提供查问服务，不再执行相干 ETL 的操作。

Broker Load 和 Routine Load 监控告警
StarRocks 提供的集群监控指标在 Broker Load 只有各个状态的统计数量，而对于 load 失败后欠缺及时告警机制。对此问题咱们制作了一些工具，基于 show load 和 show routine load 查问以后 Broker Load 和 Routine Load 的状态信息，在 load 失败后进行重试、主动拉起并发出通知告警。

Datasight 的 BI 数据利用模块，次要解决的是用户看板需要、日常取数、剖析、开掘等场景。这些场景的数据有以下特点：数据变更频繁、报表须要实现准实时更新和大规模查问。
在 Datasight-BI 第一版的实现中，所有自主取数和数据集等需要，因用户 SQL 变更频繁，因为用户 SQL 频繁变更且为了解决查问性能问题，均通过 Presto 直连查问来实现。随着平台的扩大，大量业务应用案例波及到数据跨度较大且波及多个大型维表的查问，导致 Presto 查问变得迟缓，查问提早可长达数十秒甚至几十秒，给 Presto 集群造成了微小压力。
通过调研，思考到业务在应用报表的过程中不同报表的查问速度和更新频率有所不同，咱们最终决定选用 StarRocks 作为存储引擎进行改良。改良过程中，用户在间接连贯 Presto 的时候编写 SQL 进行即时查问，确认数据后创立抽取打算。简言之，行将用户通过 Presto 查问获取的数据导入到 StarRocks。尔后，用户所有查问都通过间接连贯 StarRocks 进行。通过这一改良，整体报表的查问速度失去了晋升，同时 Presto 查问压力得以扩散至不同时间段。

可靠性是指产品在规定条件下和特定工夫内实现预约性能的能力或概率。产品的可靠性涵盖了整个寿命周期的各个方面。咱们的数据平台会基于已有车辆的可靠性相干指标数据，对整车零部件、EDS 电机外围整机上市后的可靠性进行预估。这可能揭示整机的适度设计或欠缺设计状况，为下一代车型和电驱动零碎的研发提供数据根据和反对。
可靠性指标个别为月度指标，涵盖了多样的维度，如车型、电机组合等（约 20 个维度）。这些指标须要实时获取，包含次数、继续时长等统计度量。咱们抉择 StarRocks 来存储可靠性数据，目前 DWD 层的存量数据已达到数十亿条，而每月新增数据达到亿级。利用 StarRocks 弱小的数据分析能力，咱们可能疾速计算频数、分位数等用户所需的指标。
鉴于可靠性精准载荷指标维度的多样性，咱们采纳 StarRocks 聚合模型表，针对用户频繁查问维度建设多个维度的 Rollup 索引。减少 Rollup 索引后，多指标同时查问计算速度可由 15 秒缩减至 2s 左右，性能晋升了近 8 倍。下图展现了集成 StarRocks 的可靠性数据库系统架构：

在表设计方面，因为可靠性数据库波及业务指标较多且指标起源频繁更新（常常减少新的零部件数据），同时历史数据同步表工夫较长（每次须要同步几年的历史数据）等业务特点，如果将多个指标存入一张表中，前期的可维护性较差，并且会影响用户应用体验。因而，咱们的可靠性数据库在设计中将每个指标都对应一个表，而将公共数据独自存储在维度表中。这样在灌历史数据时就不会对其余的指标数据造成影响了。

此外，对于一些 ID 数量的统计，如车辆 ID 的统计，因为其是聚合表的一个维度，间接应用 SELECT COUNT(DISTINCT id) 进行统计仍可能导致全表扫描。此时可通过改写 SQL，在计算聚合指标值之前先对该 ID 进行聚合操作，从而实现对 Rollup 查问的无效利用，能够肯定水平上减少聚合查问速度。

咱们以后在线上运维着多个 StarRocks 生产集群，依据业务场景来划分，在国内和海内均有部署。将来随着业务规模持续增长，咱们也将进一步扩容集群，以满足一直增长的业务需要。为确保运维工作的无效进行，咱们采取了以下要害措施：

稳定性：为保障生产集群的稳定性，咱们每个集群都部署三个 FE 节点，以确保高可用性，防止因单点故障引起的问题。
易运维：集群所有 FE 和 BE 过程都应用 system 进行托管，并退出开机自启动。
监控告警：采纳 Prometheus+Grafana 计划进行监控和告警，保障集群稳定性
在过来要害版本升级时（如跨大版本升级），咱们失去了 StarRocks 社区团队的大力支持。他们帮助咱们制订了详尽的降级打算，而且在咱们为了最小化对业务的影响而抉择在中午进行降级时，社区的技术支持同学也为咱们提供了近程帮助，在这里特地表示感谢。

在集群运维过程中咱们遇到过一些问题，在社区的反对下均失去了较快的响应和解决，例如：

内存透露问题
在集群版本升级到 2.5.5 之后，业务方上线了一些作业，每天凌晨 0:00 到 4:00 左右集群常常有工作报错应用内存超限度。具体谬误如下：

errMsg":"Sql 执行失败, 起因 Memory of process exceed limit. Used: 107658772696, Limit: 107657841622. Mem usage has exceed the limit of BE"}]

通过监控数据的剖析，咱们留神到 Backend 的内存使用率会在达到 100GB 后忽然呈现降落。初期咱们猜想这可能是因为内存资源有余导致工作失败，然而在进行了扩容后，内存应用仍然呈直线回升的趋势，而且即使在进行了一天的扩容之后，依然呈现了内存不足的状况。基于这些状况，咱们开始狐疑零碎存在内存透露的问题。

依据零碎的内存应用，也发现将近 50GB 的内存不知所踪，具体如下图所示：

起初查问社区论坛，看到社区有人说 2.5.4 版本之后有内存透露问题，和咱们的状况很相似（备注 1: https://forum.mirrorship.cn/t/topic/6535），通过多方确认之后，咱们降级到最新的版本解决了该问题。

Delete 操作未失效
业务同学反馈 FlinkSQL 同步 Kafka 的数据到 StarRocks 的时候遇到了一个问题。Kafka 的存储格局是 debezium-json，在某些状况下，当数据的操作类型（op）为 delete 时，StarRocks 未能正确地将该数据删除。这问题体现为仿佛 delete 操作没有失效。举例来说，对于同一个主键 id，print 输入显示一条 insert 和一条 delete 的操作，但在将数据写入 StarRocks 后，该条数据依然存在。起初通过和 StarRocks 的专家沟通之后，确认了这个问题。相干 PR 已合入 2.5.9 版本。（备注 2: https://github.com/StarRocks/StarRocks/pull/26719）
集群扩容后的数据平衡
当集群 BE 扩容后，因为以后集群 tablet 数量比拟多，都是通过正本在各个 BE 之间拷贝实现的。如果同一台 BE 同一时间执行过多的工作，则会带来较大的 I/O 压力。因而，StarRocks 在调度时管制了每个节点上可能执行的工作数目。最小的资源管制单位是磁盘（即在 be.conf 中指定的一个数据门路）。StarRocks 默认为每块磁盘配置两个 slot 用于正本修复。一个 clone 工作会占用源端和目标端各一个 slot。如果 slot 数目为零，则不会再对这块磁盘分配任务。该 slot 个数能够通过 FE 的 tablet_sched_slot_num_per_path 参数动静配置。
因为 StarRocks 的架构简略清晰，人造具备易运维的性质。通过多版本的更新降级后，以后版本集群曾经非常稳固，在将来的运维工作中咱们会针对集群资源隔离和查问队列做进一步的摸索，限度查问对资源的耗费，避免繁多用户，或者繁多大查问占用集群过多资源和影响其余租户的失常应用，从而实现多租户之间的资源隔离与正当利用，减少集群可用性和稳定性。

将来咱们打算从以下几方面对 StarRocks 进行晋升改良，以更好地服务于公司内各个应用 StarRocks 的业务方：

大数据元数据管理和 Iceberg 数据湖整合：咱们打算将多个 StarRocks 集群接入大数据元数据管理系统，并和 Iceberg 数据湖进行买通，为构建基于元数据的对立数据查问剖析平台奠定根底。
存算拆散和老本优化：咱们打算尝试应用 StarRocks 3.x 版本的存算拆散架构，把海量车联网明细数据放到腾讯云对象存储上，从而升高海量车联网数据的存储老本。
资源隔离和多租户管控：启用资源隔离性能，进行更好的多租户资源管控和审计，以保障高优租户读写稳定性。

同时，咱们也向社区提出了一些倡议，心愿能进一步欠缺产品：

扩大云服务反对：咱们心愿 StarRocks 可能反对更多的私有云服务，如腾讯云和亚马逊 AWS，并期待能推出 serverless 云服务。这将有助于将来的迁徙工作，显著升高数据团队在 StarRocks 运维方面的老本。
权限治理加强：反对更细粒度的权限治理（行级别、列级别权限），能够和 Ranger 权限零碎买通。
流式读取和物化视图更新：反对 Flink 流式数据读取（row level 数据行变更）；反对流式物化视图，能依据上游依赖表的 row level 级变更自动更新物化视图。
简单嵌套类型反对：在内置原生 OLAP 引擎中反对 Struct 和 Map 等简单嵌套类型 (已在 3.1 反对)

积极参与开源社区：

在引入 StarRocks 后，咱们团队除了踊跃向社区反馈问题外，也向官网奉献了一些代码。到目前为止，咱们提交的 PR 有蕴含比特位运算函数反对和 StarRocks Spark Connector 写数据 bug 修复等。后续咱们也会积极参与开源社区，奉献咱们的一份心力。咱们对于 StarRocks 小伙伴们始终以来所提供的反对和帮助表示感激，同时也祝福 StarRocks 开源社区可能持续获得更大的成就！

本文由 mdnice 多平台公布

正文完