作为国内⾸家互联⽹保险公司，众安保险是一家以技术创新带动⾦融倒退的⾦融科技公司。区别于传统保险公司的经营模式，众安保险业务流程全程在线，全国均不设任何分⽀机构，齐全通过互联⽹进⾏承保和理赔服务。目前已服务超 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 的应⽤，例如以下场景：
- 离线场景的数据也逐渐接⼊ StarRocks，⽤对立的 OLAP 引擎实现 全场景，批流一体 的数据分析；
- 摸索 StarRocks 作为 轻量级数仓 ，以及 对立查问引擎 的能⼒；
- 摸索 StarRocks 在 ⽤户⾏为数据分析、⽤户画像 等其余业务场景中的应⽤。
更多场景分享会继续更新，可关注“众安科技”公众号进⾏订阅，对集智感兴趣的同学也可加产品经理企微沟通哦。
4 ⽉ 13 ⽇众安将与 StarRocks 举办一场线上联结直播，直播中会具体解说在集智平台落地 StarRocks 的过程及教训。
扫描下⽅海报⼆维码，提前锁定直播名额！