作为国内?家互联?保险公司,众安保险是一家以技术创新带动?融发展的?融科技公司。区别于传统保险公司的运营模式,众安保险业务流程全程在线,全国均不设任何分?机构,完全通过互联?进?承保和理赔服务。目前已服务超5亿用户,2021 年总保费突破 200 亿元,同比增长 21.9%。近年来,众安保险致力于加速数据价值向业务价值转化,促使数据要素带来业务的提质增效。这既需要专业技术团队+成熟的数字化体系,还需要技术具来提供智能化解决案。
由“保险+科技”双引擎驱动,众安保险专注于应用新技术重塑保险价值链,围绕健康、数字生活、消费金融、汽车四大生态,以科技服务新生代,为其提供个性化、定制化、智能化的新保险。
在科技赋能保险的同时,众安保险将经过业务验证的科技对外输出,海外合作伙伴包括日本历史最悠久的财产保险公司 SOMPO、东南亚领先的 O2O 平台Grab、新加坡最大的综合保险机构 Income 等知名企业。
本文将以众安集智平台基于极速 MPP 分析型数据库系统 StarRocks 的应用实践,讲解集智平台如何解决极速查询和高并发等数据问题,提升整体的数据支持能力。
行业背景 在传统的保险售卖场景中,保险公司主要通过承保利润和投资收益两部分获得盈利,?保险?融的?业特殊性致使保司对公司整体的数据、安全、?控等持有?度敏感性,因此一款保险产品从市场投放到销售、核保及理赔,每个环节都需要严格监测业务?向和数据变化。
并且随着时间的沉淀和业务拓展,保司所涉及和积累的相关数据越来越多,其中既包含保司?营的业务数据,也有合作渠道的电商销售、医疗健康等数据以及第三?的信贷评级、核保?控等数据。在?益激烈的市场竞争和技术变?这两?背景下,基于?数据、??智能等技术的商业模式创新,以及数字化转型升级已经成为保险机构的必然选择。
因此在以上背景下诞?了专门针对保险?融?业的相关技术和产品,通过?数据、??智能等相关技术加持,保障保司在每个业务环节中做到费?可控数据可经营的?的。常?的例如营销场景中的渠道投放、?户触达、活动监控;信贷场景中的授信、??、还款、防?逆选择?险等场景。
当然?对保险?融?业如此?的数据量和业务复杂度,既有挑战也有机遇,但需要将这些数据进?充分整合并有效利?,才能更好地使其转换为企业??的数据资产,从传统的运营?式过渡到数字化在线经营。让数字反映出真实的运营状况,及时控制产品?险和策略调整,以实现保费收?的正向利润,达到精细化运营。
而众安作为全球?家以技术创新带动?融发展的互联?保险公司,在互联?+保险?融的双轮驱动下,全程通过互联?进?承保和理赔服务。在以上双重背景下诞?了数字化转型中专门针对业务数据管理和分析的系统产品——集智。
本?将以集智基于 StarRocks 全?升级数字化经营能?的真实使?场景为例,讲述集智如何通过 StarRocks 解决极速查询和?并发等数据问题,提升集智平台整体的数据?持能?和市场竞争?。
集智平台介绍 集智是众安的一款可视化智慧经营分析平台产品,集成了??智能+商业智能+可视化数据仓库技术,智能整合来?不同场景的数据,规范企业数据池,完成繁杂的数据治理和智能决策环节。
集智秉着“助?企业实现智慧经营”的愿景和“从数据到价值,从看?到预?”的理念,依托丰富的可视化图表组件以及底层的?数据处理能?,实现零代码拖拽式分析与亿级数据的秒级响应,帮助企业战略规划?员、财务企划?员、销售管理?员、业务运营?员及数据?员等全?提升信息效率、资源效率及决策效率。
?前在众安内部,数字?活、健康险、?融、直营、?险各个业务线,以及 HR、运管、?控等中后台部门,超过 3000 ?都在使?集智平台,平均?活可达 2000+,提升超过 50% 的数据分析效率,降低了公司 40% 的??成本。
文章图片
业务背景 一款好的数据分析产品离不开底层的数据引擎,集智平台的??使?场景对底层的数据架构提出了不同的要求
- 可视化分析→需要有丰富的函数库?持不同类型图表的数据计算;
- 交互式分析→需要分析结果的快速响应来保障?户流畅的分析思路;
- 多维透视分析→需要?数据量的明细数据来?撑不同维度的筛选和下钻;
- 实时数据分析→需要?持数据的实时写?、实时查询。
文章图片
离线的数据会通过 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,成本?较?。
- 查询慢,Replacing 引擎使?的是 Merge-On-Read 的模式,数据写?时保存多个版本,在查询时需要指定 FINAL 关键字进?去重取出最新版本的数据。这导致对于 Replacing 引擎表的查询,SQL 中的谓词?法下推,同时在低版本的 ClickHouse 中,对于 FINAL 语义的查询也不?持多线程处理,?乎每次查询都需要单线程扫描全表数据,涉及 Replacing 引擎的查询响应时间往往在 10s 以上;
- Replacing 引擎只?持数据的更新,并不?持数据的删除。对于 Delete 操作,当前的做法是通过额外字段来标记当前数据是否已经被删除,同时借助 TTL 功能来定时清除已经被删除的数据。这样一??需要额外的定制处理,另一??新增的标记字段进一步拖慢了查询的性能;
- Replacing 引擎只能对同一分?上同一分区的数据去重,这意味着我们在设计表分区时,以及写?数据时,都需要做??的处理,增加了开发的成本。
StarRocks comes to the rescue StarRocks 是新一代 MPP 型 OLAP 分析引擎。我们通过调研发现,对于许多遇到的痛点,StarRocks 都提供了对应的解决?案:
- ?持多并发查询,部分场景可以达到 1 万以上 QPS;
- ?持 Shuffle Join,Colocate Join 等多种分布式 Join ?式,多表关联性能更优;
- ?持事务性的 DDL 与 DML 操作,兼容 MySQL 协议;
- FE、BE 架构简单,不依赖外部组件,运维更加简单;
- 数据?动均衡,集群随业务增??平扩展?便。
调研之后,我们也对 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% 左右。
文章图片
在集智平台的实时数仓?,业务库的 Binlog 数据与?志、事件数据会?先经由采集?具发送到 Kafka ?,中间通过 Flink 完成初步的数据清洗、转换,再次输出到 Kafka 做为 DWD/DIM 层。这一层的数据再次经过 Flink 处理,完成数据的关联、聚合,最后在 DWS 层?成不同主题的多维度明细宽表与指标汇总宽表。DWS 层的宽表会同时实时同步在 OLAP 引擎?,通过实时看板提供给业务同学查询。
实时数仓的场景对 OLAP 引擎提出了许多挑战,也是之前我们基于 ClickHouse 架构遇到的一?难题场景
- 业务同学需要根据实时看板随时调整投放策略,要求看板数据实时更新,快速响应;
- 实时看板的查看频率?离线看板普遍?出 3~5 倍,并且查询结果?法做缓存处理;
- 为了联合查询不同主题的数据,DWS 层的宽表之间往往还需要在 OLAP 层做关联操作;
- 为了满?多维分析的需求,落在 OLAP 层的是明细数据,数据量?;
- 为了保障数据的可维护性与数据快速修正的能?,这些明细数据需要?持按主键更新。
为此,我们计划使? 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 的过程及经验。
扫描下?海报?维码,提前锁定直播名额!
【众安保险 x StarRocks | 全新实时分析能力开启数字化经营新局面】
文章图片
推荐阅读
- 万字详解!搜狐智能媒体基于 Zipkin 和 StarRocks 的微服务链路追踪实践
- 如何打造极速数据湖分析引擎
- 金融数据查询增速三倍,服务器成本减半,海尔云链的 OLAP 引擎选型之路
- 慢sql治理经典案例分享
- SQL数据库|MySQL数据库(基础)