近年来，众安保险致力于加速数据价值向业务价值转化，在“互联⽹ 保险⾦融”的双轮驱动下，诞生了数字化转型中专门针对业务数据管理和分析的系统产品——集智。
依托丰富的可视化图表组件以及底层的⼤数据处理能⼒，集智实现了零代码拖拽式分析与亿级数据的秒级响应。⽬前在众安内部，数字⽣活、健康险、⾦融、直营、⻋险各个业务线，以及 HR、运管、⻛控等中后台部门，超过 3000 ⼈都在使⽤集智平台，平均⽇活可达 2000 ，提升超过 50% 的数据分析效率，降低了公司 40% 的⼈⼒成本。
本文将以众安集智平台基于极速 MPP 分析型数据库系统 StarRocks 的应用实践，讲解集智平台如何解决极速查询和高并发等数据问题，提升整体的数据支持能力和市场竞争力。
一、业务背景
—
一款好的数据分析产品离不开底层的数据引擎，集智平台的⼏⼤使⽤场景对底层的数据架构提出了不同的要求
- 可视化分析→需要有丰富的函数库⽀持不同类型图表的数据计算；
- 交互式分析→需要分析结果的快速响应来保障⽤户流畅的分析思路；
- 多维透视分析→需要⼤数据量的明细数据来⽀撑不同维度的筛选和下钻；
- 实时数据分析→需要⽀持数据的实时写⼊、实时查询。
针对上述的⼏个需求，我们在平台建设的初期选⽤了 ClickHouse 作为底层统一的 OLAP 引擎，数据链路如下：
离线的数据会通过 DataX 统一采集到 MaxCompute 或 Hive 数仓，在离线数仓内部完成数据 ETL 的⼯作，数据加⼯完成之后，再次经由 DataX 输出到 ClickHouse 中，ClickHouse 中的数据直接提供给看板或者第三⽅系统做数据查询。
实时的数据会通过 Binlog 监听或者⽇志采集⼯具同步到 Kafka，再经由 Flink 完成实时的数据 ETL，最终落到 ClickHouse 中。值得一提的是，这⾥为了应对一些业务场景中数据需要实时按主键更新的需求，我们采⽤了 ClickHouse 的 ReplacingReplicatedMergeTree 引擎。由于 ClickHouse 对数据更新操作的⽀持还不够成熟，因此在使⽤ Replacing 引擎的过程中遇到很多问题，这也是我们寻求新的 OLAP 技术选型的主要原因。
二、平台现状
—
集智上线后采⽤的是 ClickHouse，并且已经伴随业务运⾏了一段时间，但随着使⽤平台的⽤户⽇渐增多，业务⽅需要查询的数据量也越来越⼤，业务场景变得复杂后，很多特定场景 ClickHouse ⽆法满⾜，⾯对不同⼈员⾓⾊的需求时也遇到一些瓶颈。同时我们分别从业务⽤户的⾓度，以及平台运维的⾓度发现了以下问题：
从⽤户⾓度
- 一⻚分析看板上往往有 6-8 个图表，这些图表的查询请求都是同时发给 ClickHouse 的。但是在多并发的场景，ClickHouse 的查询性能下降的很快，平时一个 1-2s 左右的查询，在 8 个并发下就可能把 CPU 吃满，平均响应时间退化 4 倍左右，降到 8-10s，对看板的⾸⻚加载时间，以及交互分析的体验影响都⽐较⼤；
- 平台⽀持数据表的关联查询，但是 ClickHouse 的多表关联查询性能⽋佳，涉及 Join 的查询往往都需要 10s 以上，数据量⼤的查询甚⾄直接超时⽆法返回结果。
从运维⾓度
- ClickHouse 不⽀持事务性的 DDL 与 DML 操作，⽽且多副本模式的元数据管理强依赖于 ZooKeeper，表结构变更时常常出现不同副本之间元数据不一致的问题，往往定位到最后都是 ZooKeeper 的原因，排查、运维的成本都⽐较⾼；
- 随着数据量的增多，集群需要扩容时，ClickHouse 缺少⾃动的 Resharding 机制，横向扩容时需要借助第三⽅⼯具或者⼿动 Reshard，成本⽐较⾼。
针对前⾯提到的实时场景，我们在使⽤ ClickHouse 的 Replacing 引擎中也遇到一些痛点：
- 查询慢，Replacing 引擎使⽤的是 Merge-On-Read 的模式，数据写⼊时保存多个版本，在查询时需要指定 FINAL 关键字进⾏去重取出最新版本的数据。这导致对于 Replacing 引擎表的查询，SQL 中的谓词⽆法下推，同时在低版本的 ClickHouse 中，对于 FINAL 语义的查询也不⽀持多线程处理，⼏乎每次查询都需要单线程扫描全表数据，涉及 Replacing 引擎的查询响应时间往往在 10s 以上；
- Replacing 引擎只⽀持数据的更新，并不⽀持数据的删除。对于 Delete 操作，当前的做法是通过额外字段来标记当前数据是否已经被删除，同时借助 TTL 功能来定时清除已经被删除的数据。这样一⽅⾯需要额外的定制处理，另一⽅⾯新增的标记字段进一步拖慢了查询的性能；
- Replacing 引擎只能对同一分⽚上同一分区的数据去重，这意味着我们在设计表分区时，以及写⼊数据时，都需要做⼩⼼的处理，增加了开发的成本。
上⾯描述的问题中，有一些涉及 ClickHouse 底层的缺陷，有一些场景利⽤ ClickHouse 提供的其他引擎或者 MaterializedView 等特性可以做一些定制的优化，但是掣肘于平台分析查询场景的多样性，我们很难做一些通⽤性的优化。基于这样的情况，我们决定需求新的 OLAP 技术选型。
三、StarRocks comes to the rescue
—
StarRocks 是新一代 MPP 型 OLAP 分析引擎。我们通过调研发现，对于许多遇到的痛点，StarRocks 都提供了对应的解决⽅案：
- ⽀持多并发查询，部分场景可以达到 1 万以上 QPS；
- ⽀持 Shuffle Join，Colocate Join 等多种分布式 Join ⽅式，多表关联性能更优；
- ⽀持事务性的 DDL 与 DML 操作，兼容 MySQL 协议；
- FE、BE 架构简单，不依赖外部组件，运维更加简单；
- 数据⾃动均衡，集群随业务增⻓⽔平扩展⽅便。
对于实时的场景，StarRocks 在 1.19 版本发布了 Primary Key 模型。对⽐ ClickHouse 的 Replacing 引擎与 StarRocks ⾃⾝的 Unique Key 模型，Primary Key 模型通过在内存中维护主键索引，⽀持频繁实时更新的同时，保证同一个主键下仅存在一条记录，解决了 Merge-on-Read ⽅式读取时在线合并，并且谓词⽆法下推和索引失效的问题。通过牺牲微⼩的写⼊性能和内存占⽤提升了查询的性能，⾮常符合我们实时数仓的场景。
调研之后，我们也对 StarRocks 和 ClickHouse，使⽤SSB数据集做了相应的性能对⽐测试。一共使⽤到四台 8c32g 的机器：StarRocks 1FE/4BE 混部，ClickHouse 两分⽚双副本。StarRocks 使⽤的版本是 2.1.0，ClickHouse 使⽤的版本是 21.9.5。测试中为了屏蔽掉系统缓存的影响，对于⽆并发的场景，每次查询前都会通过往 drop_cache ⽂件中写⼊来清除缓存。
测试的结果验证了 StarRocks 在多并发与多表关联场景下强悍的性能，同时也发现了⽬前 StarRocks 不⾜的一些地⽅：
- 单表⽆并发的场景，除个别 SQL 外，StarRocks 的查询速度与 ClickHouse 基本持平，但是 StarRocks 的 CPU 负载偏低，是 ClickHouse 的 25%~50%；
- 单表多并发的场景，除个别 SQL 外，StarRocks 的平均查询速度⽐ ClickHouse 快 1.8 倍；
- 多表关联⽆并发的场景，StarRocks 平均⽐ ClickHouse 快 1.8 倍；
- 多表关联多并发的场景，StarRocks 平均⽐ ClickHouse 快 8 倍；
- 数据实时写⼊实时查询的场景，不同的查询场景下，StarRocks 的 Primary Key 模型查询速度⽐ ClickHouse 的 Replacing 引擎快 3~10 倍，且查询性能较 ClickHouse 更加稳定（Replacing 引擎由于后台不断地 Merge 操作，查询的性能会随底表数据量的起伏对应地波动）；
- 数据批量导⼊的场景，我们⽐较了不同批次⼤⼩下的写⼊性能，StarRocks 的写⼊速率平均⽐ ClickHouse 要慢 20%~30% 左右。
基于上述的⼏点考虑与测试的结果，我们决定在平台的 OLAP 架构中引⼊ StarRocks，并优先在实时数仓的场景落地应⽤。
在集智平台的实时数仓⾥，业务库的 Binlog 数据与⽇志、事件数据会⾸先经由采集⼯具发送到 Kafka ⾥，中间通过 Flink 完成初步的数据清洗、转换，再次输出到 Kafka 做为 DWD/DIM 层。这一层的数据再次经过 Flink 处理，完成数据的关联、聚合，最后在 DWS 层⽣成不同主题的多维度明细宽表与指标汇总宽表。DWS 层的宽表会同时实时同步在 OLAP 引擎⾥，通过实时看板提供给业务同学查询。
实时数仓的场景对 OLAP 引擎提出了许多挑战，也是之前我们基于 ClickHouse 架构遇到的一⼤难题场景
- 业务同学需要根据实时看板随时调整投放策略，要求看板数据实时更新，快速响应；
- 实时看板的查看频率⽐离线看板普遍⾼出 3~5 倍，并且查询结果⽆法做缓存处理；
- 为了联合查询不同主题的数据，DWS 层的宽表之间往往还需要在 OLAP 层做关联操作；
- 为了满⾜多维分析的需求，落在 OLAP 层的是明细数据，数据量⼤；
- 为了保障数据的可维护性与数据快速修正的能⼒，这些明细数据需要⽀持按主键更新。
本就不擅⻓多并发与多表关联查询的 ClickHouse，再叠上 Replacing 引擎的 Debuff，导致许多实时的看板常常需要⼗⼏秒才能返回查询结果，不能很好地满⾜业务的需求。同时给集群的 CPU 负载也造成了不⼩的压⼒，有时会造成集群整体查询性能的波动。
为此，我们计划使⽤ StarRocks 的 Primary Key 模型来替换 ClickHouse 的 Replacing 引擎，针对线上的实时看板，我们模拟了真实的场景，选取了一个 4 张宽表关联的复杂查询，对两种不同的引擎做了对⽐测试，结果如下：
从结果中可以看到，在没有并发的场景下，StarRocks 的查询速度是 ClickHouse 的 2 倍左右，在多并发的场景下，StarRocks 的查询速度是 ClickHouse 的 3~3.5 倍左右。
除了查询性能提升之外，Primary Key 模型也可以⽀持数据的删除，并且不⽤数据开发额外地维护分⽚与分区的写⼊规则，降低了数据开发的成本。
四、集智平台集成 StarRocks 的功能应用
—
为了提升集智在查询加载⽅⾯的性能，同时将 StarRocks 极速查询及⾼并发相关能⼒更好的赋能给业务同学，集智在产品侧深度集成了 StarRocks，⽤户可以在平台上快速完成一站式的实时看板搭建。
在集智平台中，搭建一个分析看板前需要先创建数据模型，当数据开发同学⾯对业务⽅较为复杂或查询量较⼤的分析需求时，可在创建数据模型时选择 StarRocks 的优化⽅式，除了基础的索引字段、数据分布字段以及时间分区等字段外，还可选择对应的模型引擎以及填写数据保留的时⻓。
实时模型创建成功后，⽤户可以在模型的详情⻚拿到对应的 StarRocks 表连接信息，以及⾃动⽣成的 Flink SQL Sink 语句。
之后，⽤户可以在平台的数据 ETL 模块新建一个实时 Flink 任务，往对应的实时模型中写⼊数据。
数据写⼊模型之后，⽤户就可以在搭建看板时使⽤了，可以在模型上做一些字段的数据格式调整、字段编辑、基于原始字段新增复合字段等操作，以及图表样式的调整，满⾜业务⽅不同场景下的业务⼝径与展⽰需求。
看板搭建完成后可以进⾏发布操作⽣成一个固定链接，就可以提供给业务同学使⽤啦。
五、集成 StarRocks 对于业务的提升
—
以保险产品中线上渠道投放场景为例，当保险产品开始对外发售前后，市场⼈员会将产品投放到多个渠道进⾏推⼴曝光，通过经营的核⼼报表实时核算每个渠道的投放成本以及其对应的 ROI，根据数据表现情况实时调整投放策略，控制渠道营销流程中的获客单价和投放费⽤。
因此数据反馈的快慢也会决定业务⼈员在定位问题、调整策略等事件上是否占据最佳时机。
⽽集智使⽤ StarRocks 的模型作为实时报表的底层数据⽀撑后，在业务场景中的数据查询表现会怎么样，以下为真实场景测试结果：
1）在报表数据加载速度⽅⾯：过去业务⽅打开报表需要加载 10s ，常常因为打开速度过慢致使业务偶尔在关键节点上⽆法及时得到事故反馈，导致投放成本难以控制，严重影响后续的投放策略；
⽽使⽤ StarRocks 后加载速度只需 3s 左右，超强的响应速度让业务同学可以很快抓准业务实时的变动节点，及时对活动策略做出调整优化。
2）在查询数据量⽀持⽅⾯：过去使⽤ ClickHouse 的实时更新模型只能⽀持千万级数据量，更⼤数据量的实时更新 查询常常超时，严重影响业务进展，也会因此错过一些关键时机；
⽽使⽤ StarRocks 后可⽀持近亿级数据量，能够适配更多⼤数据量下的业务场景，同时也能更好的维持业务稳定性，增加了业务同学对平台的信任和粘性，极⼤的提⾼了⽣产效率。
六、总结与规划
—
从以上的调研和测试结果来看，StarRocks 的单表查询性能和 ClickHouse 不相上下，在多并发与多表关联查询的场景下性能明显优于 ClickHouse，特别是针对实时数仓的⾼频更新场景，StarRocks 的 Primary Key 模型能很好地解决 ClickHouse 的 Replacing 引擎遇到的一些痛点。此外，StarRocks 的 DDL/DML和数据导入具备事务保证，兼容 MySQL 协议，集群相对 ClickHouse 也更容易运维，对于研运同学来说更加友好。
之后除了在实时数仓场景的应⽤落地之外，众安也计划在其他场景中逐步推进 StarRocks 的应⽤，例如以下场景：
- 离线场景的数据也逐步接⼊ StarRocks，⽤统一的 OLAP 引擎完成全场景，批流一体的数据分析；
- 探索 StarRocks 作为轻量级数仓，以及统一查询引擎的能⼒；
- 探索 StarRocks 在⽤户⾏为数据分析、⽤户画像等其他业务场景中的应⽤。
