导读：近年来，众安保险致力于加速数据价值向业务价值转化，在“互联+保险融”的双轮驱动下，诞生了数字化转型中专门针对业务数据管理和分析的系统产品——集智。
依托丰富的可视化图表组件以及底层的数据处理能，集智实现了零代码拖拽式分析与亿级数据的秒级响应。前在众安内部，数字活、健康险、融、直营、险各个业务线，以及HR、运管、控等中后台部门，超过都在使集智平台，平均活可达+，提升超过50%的数据分析效率，降低了公司40%的成本。
本文将以众安集智平台基于极速MPP分析型数据库系统StarRocks的应用实践，讲解集智平台如何解决极速查询和高并发等数据问题，提升整体的数据支持能力和市场竞争力。
01
业务背景
一款好的数据分析产品离不开底层的数据引擎，集智平台的使场景对底层的数据架构提出了不同的要求：
可视化分析→需要有丰富的函数库持不同类型图表的数据计算；
交互式分析→需要分析结果的快速响应来保障户流畅的分析思路；
多维透视分析→需要数据量的明细数据来撑不同维度的筛选和下钻；
实时数据分析→需要持数据的实时写、实时查询。
针对上述的个需求，我们在平台建设的初期选了ClickHouse作为底层统一的OLAP引擎，数据链路如下：
离线的数据会通过DataX统一采集到MaxCompute或Hive数仓，在离线数仓内部完成数据ETL的作，数据加完成之后，再次经由DataX输出到ClickHouse中，ClickHouse中的数据直接提供给看板或者第三系统做数据查询。
实时的数据会通过Binlog监听或者志采集具同步到Kafka，再经由Flink完成实时的数据ETL，最终落到ClickHouse中。值得一提的是，这为了应对一些业务场景中数据需要实时按主键更新的需求，我们采了ClickHouse的ReplacingReplicatedMergeTree引擎。由于ClickHouse对数据更新操作的持还不够成熟，因此在使Replacing引擎的过程中遇到很多问题，这也是我们寻求新的OLAP技术选型的主要原因。
02
平台现状
集智上线后采的是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技术选型。
03
StarRocksComestotheRescue
StarRocks是新一代MPP型OLAP分析引擎。我们通过调研发现，对于许多遇到的痛点，StarRocks都提供了对应的解决案：
持多并发查询，部分场景可以达到1万以上QPS；
持ShuffleJoin，ColocateJoin等多种分布式Join式，多表关联性能更优；
持事务性的DDL与DML操作，兼容MySQL协议；
FE、BE架构简单，不依赖外部组件，运维更加简单；
数据动均衡，集群随业务增平扩展便。
对于实时的场景，StarRocks在1.19版本发布了PrimaryKey模型。对ClickHouse的Replacing引擎与StarRocks的UniqueKey模型，PrimaryKey模型通过在内存中维护主键索引，持频繁实时更新的同时，保证同一个主键下仅存在一条记录，解决了Merge-on-Read式读取时在线合并，并且谓词法下推和索引失效的问题。通过牺牲微的写性能和内存占提升了查询的性能，常符合我们实时数仓的场景。
调研之后，我们也对StarRocks和ClickHouse，使SSB数据集做了相应的性能对测试。一共使到四台8c32g的机器：StarRocks1FE/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的PrimaryKey模型查询速度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的PrimaryKey模型来替换ClickHouse的Replacing引擎，针对线上的实时看板，我们模拟了真实的场景，选取了一个4张宽表关联的复杂查询，对两种不同的引擎做了对测试，结果如下：
从结果中可以看到，在没有并发的场景下，StarRocks的查询速度是ClickHouse的2倍左右，在多并发的场景下，StarRocks的查询速度是ClickHouse的3~3.5倍左右。
除了查询性能提升之外，PrimaryKey模型也可以持数据的删除，并且不数据开发额外地维护分与分区的写规则，降低了数据开发的成本。
04
集智平台集成StarRocks的功能应用
为了提升集智在查询加载的性能，同时将StarRocks极速查询及并发相关能更好的赋能给业务同学，集智在产品侧深度集成了StarRocks，户可以在平台上快速完成一站式的实时看板搭建。
在集智平台中，搭建一个分析看板前需要先创建数据模型，当数据开发同学对业务较为复杂或查询量较的分析需求时，可在创建数据模型时选择StarRocks的优化式，除了基础的索引字段、数据分布字段以及时间分区等字段外，还可选择对应的模型引擎以及填写数据保留的时。
实时模型创建成功后，户可以在模型的详情拿到对应的StarRocks表连接信息，以及动成的FlinkSQLSink语句。
之后，户可以在平台的数据ETL模块新建一个实时Flink任务，往对应的实时模型中写数据。
数据写模型之后，户就可以在搭建看板时使了，可以在模型上做一些字段的数据格式调整、字段编辑、基于原始字段新增复合字段等操作，以及图表样式的调整，满业务不同场景下的业务径与展需求。
看板搭建完成后可以进发布操作成一个固定链接，就可以提供给业务同学使啦。
05
集成StarRocks对于业务的提升
以保险产品中线上渠道投放场景为例，当保险产品开始对外发售前后，市场员会将产品投放到多个渠道进推曝光，通过经营的核报表实时核算每个渠道的投放成本以及其对应的ROI，根据数据表现情况实时调整投放策略，控制渠道营销流程中的获客单价和投放费。
因此数据反馈的快慢也会决定业务员在定位问题、调整策略等事件上是否占据最佳时机。集智使StarRocks的模型作为实时报表的底层数据撑后，在业务场景中的数据查询表现会怎么样，以下为真实场景测试结果：
（1）在报表数据加载速度：过去业务打开报表需要加载10s+，常常因为打开速度过慢致使业务偶尔在关键节点上法及时得到事故反馈，导致投放成本难以控制，严重影响后续的投放策略；
使StarRocks后加载速度只需3s左右，超强的响应速度让业务同学可以很快抓准业务实时的变动节点，及时对活动策略做出调整优化。
（2）在查询数据量持：过去使ClickHouse的实时更新模型只能持千万级数据量，更数据量的实时更新+查询常常超时，严重影响业务进展，也会因此错过一些关键时机；
使StarRocks后可持近亿级数据量，能够适配更多数据量下的业务场景，同时也能更好的维持业务稳定性，增加了业务同学对平台的信任和粘性，极地提了产效率。
06
总结与规划
从以上的调研和测试结果来看，StarRocks的单表查询性能和ClickHouse不相上下，在多并发与多表关联查询的场景下性能明显优于ClickHouse，特别是针对实时数仓的频更新场景，StarRocks的PrimaryKey模型能很好地解决ClickHouse的Replacing引擎遇到的一些痛点。此外，StarRocks的DDL/DML和数据导入具备事务保证，兼容MySQL协议，集群相对ClickHouse也更容易运维，对于研运同学来说更加友好。
之后除了在实时数仓场景的应落地之外，众安也计划在其他场景中逐步推进StarRocks的应，例如以下场景：
离线场景的数据也逐步接StarRocks，统一的OLAP引擎完成全场景，批流一体的数据分析；
探索StarRocks作为轻量级数仓，以及统一查询引擎的能；
探索StarRocks在户为数据分析、户画像等其他业务场景中的应。
今天的分享就到这里，谢谢大家。