众安保险 x StarRocks | 全新实时分析能力开启数字化经营新局面 sql数据库

作为国内?家互联?保险公司，众安保险是一家以技术创新带动?融发展的?融科技公司。区别于传统保险公司的运营模式，众安保险业务流程全程在线，全国均不设任何分?机构，完全通过互联?进?承保和理赔服务。目前已服务超5亿用户，2021 年总保费突破 200 亿元，同比增长 21.9%。
由“保险+科技”双引擎驱动，众安保险专注于应用新技术重塑保险价值链，围绕健康、数字生活、消费金融、汽车四大生态，以科技服务新生代，为其提供个性化、定制化、智能化的新保险。
在科技赋能保险的同时，众安保险将经过业务验证的科技对外输出，海外合作伙伴包括日本历史最悠久的财产保险公司 SOMPO、东南亚领先的 O2O 平台Grab、新加坡最大的综合保险机构 Income 等知名企业。

近年来，众安保险致力于加速数据价值向业务价值转化，促使数据要素带来业务的提质增效。这既需要专业技术团队+成熟的数字化体系，还需要技术具来提供智能化解决案。
本文将以众安集智平台基于极速 MPP 分析型数据库系统 StarRocks 的应用实践，讲解集智平台如何解决极速查询和高并发等数据问题，提升整体的数据支持能力。
行业背景在传统的保险售卖场景中，保险公司主要通过承保利润和投资收益两部分获得盈利，?保险?融的?业特殊性致使保司对公司整体的数据、安全、?控等持有?度敏感性，因此一款保险产品从市场投放到销售、核保及理赔，每个环节都需要严格监测业务?向和数据变化。
并且随着时间的沉淀和业务拓展，保司所涉及和积累的相关数据越来越多，其中既包含保司?营的业务数据，也有合作渠道的电商销售、医疗健康等数据以及第三?的信贷评级、核保?控等数据。在?益激烈的市场竞争和技术变?这两?背景下，基于?数据、??智能等技术的商业模式创新，以及数字化转型升级已经成为保险机构的必然选择。
因此在以上背景下诞?了专门针对保险?融?业的相关技术和产品，通过?数据、??智能等相关技术加持，保障保司在每个业务环节中做到费?可控数据可经营的?的。常?的例如营销场景中的渠道投放、?户触达、活动监控；信贷场景中的授信、??、还款、防?逆选择?险等场景。
当然?对保险?融?业如此?的数据量和业务复杂度，既有挑战也有机遇，但需要将这些数据进?充分整合并有效利?，才能更好地使其转换为企业??的数据资产，从传统的运营?式过渡到数字化在线经营。让数字反映出真实的运营状况，及时控制产品?险和策略调整，以实现保费收?的正向利润，达到精细化运营。
而众安作为全球?家以技术创新带动?融发展的互联?保险公司，在互联?+保险?融的双轮驱动下，全程通过互联?进?承保和理赔服务。在以上双重背景下诞?了数字化转型中专门针对业务数据管理和分析的系统产品——集智。
本?将以集智基于 StarRocks 全?升级数字化经营能?的真实使?场景为例，讲述集智如何通过 StarRocks 解决极速查询和?并发等数据问题，提升集智平台整体的数据?持能?和市场竞争?。
集智平台介绍集智是众安的一款可视化智慧经营分析平台产品，集成了??智能+商业智能+可视化数据仓库技术，智能整合来?不同场景的数据，规范企业数据池，完成繁杂的数据治理和智能决策环节。
集智秉着“助?企业实现智慧经营”的愿景和“从数据到价值，从看?到预?”的理念，依托丰富的可视化图表组件以及底层的?数据处理能?，实现零代码拖拽式分析与亿级数据的秒级响应，帮助企业战略规划?员、财务企划?员、销售管理?员、业务运营?员及数据?员等全?提升信息效率、资源效率及决策效率。
?前在众安内部，数字?活、健康险、?融、直营、?险各个业务线，以及 HR、运管、?控等中后台部门，超过 3000 ?都在使?集智平台，平均?活可达 2000+，提升超过 50% 的数据分析效率，降低了公司 40% 的??成本。

文章图片

业务背景一款好的数据分析产品离不开底层的数据引擎，集智平台的??使?场景对底层的数据架构提出了不同的要求

可视化分析→需要有丰富的函数库?持不同类型图表的数据计算；
交互式分析→需要分析结果的快速响应来保障?户流畅的分析思路；
多维透视分析→需要?数据量的明细数据来?撑不同维度的筛选和下钻；
实时数据分析→需要?持数据的实时写?、实时查询。

针对上述的?个需求，我们在平台建设的初期选?了 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 的应?，例如以下场景：