招商信诺人寿：统一实时OLAP技术实践

来源：鑫智奖·2024第五届金融机构数智化转型优秀案例评选

获奖单位：招商信诺人寿

荣获奖项：数据管理优秀案例奖

一、项目背景

招商信诺是一家专业、稳健、创新、以健康保障为专长的中外合资寿险公司，为企业和个人提供涵盖保险保障、健康管理、财富规划的全方位产品及服务，中外股东分别为招商银行和信诺集团。目前，招商信诺已累积服务客户超千万、完成理赔客户超百万，并凭借一站式便捷的健康管理服务、可灵活配置“定制化”的保险方案获得广大用户的持续选择与信赖。

面对全球数据量爆炸性增长的趋势，数据的时效性与准确性对企业精细化运营越来越重要。我们希望通过数据能够快速感知客户行为、定位客户问题、高效匹配用户所需的产品与服务，以达到精细化业务营销、拓宽可保边界等目标。

随着业务不断拓展、分析场景逐渐多元化，业务分析师的要求也变得更为复杂，不仅要求能够快速开发数据报表，还需要实现流批一体、湖仓一体、多元化数据类型的统一分析与管理。在大数据基础建设中，这些融合统一的特性变得至关重要。在这样的背景下，招商信诺持续升级与改进数仓架构，从初仅支持 BI 报表、数据大屏的一代架构到采用多个系统和组件提供数据服务的二代架构，再到如今新一代统一实时数据仓库，通过 Apache Doris 一套组件实现了架构的简化、技术栈的统一、数据的统一管理与分析，不仅提升了数据处理效率，并且满足了更多样化的数据分析需求。

本文将详细介绍招商信诺在数仓架构迭代与升级过程中如何构建统一存储、计算和查询出口、如何满足写入时效性的要求、如何在高并发点查与多表关联等场景下实现极速查询性能，为销售线索高效写入与查询、客户留存信息高频更新、服务场景数据一致打通等方面提供助力，进一步将客户线索转化为私域商机，赋予企业在经营、服务、营销等多方面的能力。

架构 1.0 ：多组件实时数仓

初的业务需求是希望通过数仓来承载面向 C 端用户的保单自助查询、面向业务分析人员的多维分析报表以及面向管理者的实时数据大屏（Dashboard）三类业务场景。数仓需要满足数据计算、存储、查询能力以支持业务分析决策，同时还需要支持数据回写，以实现闭环式业务运营。

1.保单自助查询

用户通过招商信诺 APP 根据保单 ID 自助查询承保合同，或者通过不同维度（如承保时间、保险类别、理赔金额）进行自定义筛选查询，查看保单生命周期内的信息。

2.多维报表分析

依据业务需求，业务分析人员通过开发明细数据、指标维度报表，获得关于保单在产品创新、费率、反理赔欺诈等方面的业务洞察，并据此支持经营策略调整。

3.数据大屏（Dashboard）

主要用于某银行渠道、某分公司的实时大屏，通过对指标等数据的统一汇总，将热门险种、每日销售额、保险种类缴纳总额与占比、历年保险缴纳涨幅趋势等信息展示于实时大屏中。

业务初期对数据服务的要求较为单一，主要是以提升报表数据的时效性为主，因此在数仓搭建的过程中，我们采用典型的 Lambda 架构，通过实时与离线两条链路分别进行数据采集、计算与存储，其中数仓主要采用宽表模型设计以支持对指标数据、明细数据的查询分析。

由架构图可以看到，FlinkCDC 负责实时数据采集，我们自研的 Hisen 工具（包括 Sqoop、DataX 以及 Python）负责离线数据采集。原始数据采集后，实时数据利用 Flink 进行计算、离线数据交由 Hive 进行批处理，终导入至不同的 OLAP 组件（包括 Presto、Clickhouse、HBase 以及 MySQL）中，由 OLAP 向上层业务提供数据服务，其中各组件在架构中分别扮演不同的角色：

MySQL

按照业务需求，在数据完成计算后主要用于存储指标数据。目前，数仓表的数据量已经突破千万级， 而 MySQL 存储具有局限性，容易出现执行时间过长、系统返回错误等问题。

Clickhosue

Clickhouse 在单表数据读取的性能上表现出色，在大表 Join 性能较弱。随着业务场景的增加，实时数据量不断叠加与更新下，Clickhouse 面对新的业务需求存在一定局限：

为减少指标重复计算，需要引入星型模型进行多表关联与高并发点查询，而 Clickhouse 无法支持；

当保单内容发生变更时，需要数据实时更新写入，而 Clickhouse 不支持实时事务处理，面对数据变更只能重新生成宽表以覆盖旧数据，无法保证高效的数据更新；

Clickhouse 不支持标准 SQL 语句查询。

HBase

主要用于主键查询，从 MySQL 与 Hive 中读取用户基础状态数据，包括客户积分、承保时间、累积承保保额。由于 HBase 不支持二级索引，对于非主键的数据读取较为局限，无法满足关联查询场景，同时 HBase 也不支持 SQL 语句查询。

Presto

由于上述组件在数据查询方面的场景限制，我们还引入了 Presto 作为离线数据的查询引擎，用于与 Hive 中的数据进行交互式分析，为上游端提供报表服务。

在数仓 1.0 版本上线后，已在超过 10 余家分公司中上线使用，开发了大量的数据大屏以及 BI 报表。随着业务范围的不断拓展，营销、运营以及客户服务等场景对数据写入与查询性能提出了更高的要求，然而混合使用四个组件提供数据服务的 1.0 版本架构在实际业务中存在一些挑战。为了避免由于架构组件过多所产生的运维成本升高、研发人员学习成本升高等问题，也为了确保在离线与实时链路中多源数据的一致性，我们决定展开架构更新迭代之旅。

二、项目目标

为满足业务需求，我们需要为架构“减负”，尽可能地缩短数据处理过程。而 1.0 架构由于组件过多，链路冗余等问题势必降低了数据存储与分析的性能与时效性。因此，我们希望寻找一个系统既能覆盖大部分的业务场景，也能够降低复杂技术栈带来的开发、运维和使用成本，还能大化的提升架构性能。具体要求如下：

导入性能：具备实时写入、实时更新的能力，并支持高吞吐的海量数据写入。

查询性能：提供维度数据以及交易数据的查询服务，具备高性能的海量数据实时查询的能力。

灵活性多维分析、自助查询能力：不仅能够支持主键索引以提供点查与范围查询，还能够支持多维度检索分析，提供对亿级数据的表关联查询，实现灵活动态、下钻上卷的业务数据分析。

数据平台架构简化：需要一款综合能力强的组件以替换当前冗余架构，满足在实时与离线数据的读写、不同场景下的高查询性能、简单易用的 SQL 语句查询等能力。

基于此，我们开始系统选型，将市面上热门组件与现有架构进行多方面对比，评估是否满足业务方对组件的需求，终在众多 OLAP 组件中选择了 Apache Doris，具体原因如下：

支持低延迟实时写入：支持 FlinkCDC 在海量数据下的高吞吐写入，提供实时数据对外服务；支持主键表模型写时合并，实现微批高频实时写入；支持 Upsert 与 Insert Overwrite，保证高效的数据更新。

保证数据一致有序：支持 Label 机制、事物性导入、幂等性保证写入过程中 Exactly Once 语义；支持主键模型 Sequence 设置，保证数据导入过程中的有序性。

查询性能优异：Doris 支持 Rollup 预聚合与物化视图完成查询加速；支持向量化处理以减少虚函数调用和 Cache Miss；支持倒排索引以完成文本类、普通数值、日期类等全文检索或范围查询。

支持高并发点查询：支持分区分桶裁剪，通过 Partition 将时间分区、设置 Bucket 数量过滤非必要的数据，以减少底层数据扫描，实现查询快速定位；此外，在 Doris 2.0 版本中还新增了行式存储格式、短路径点查、预处理语句等一系列优化，进一步提升点查执行效率、降低 SQL 解析开销。

支持多种数据模型：支持星型模型，满足亿级数据表关联查询需求；支持大宽表聚合，提供单表极速查询性能与多维分析能力。

架构简单、易运维、易扩展、高可用：Doris FE 节点负责管理元数据与多副本、BE 节点负责数据存储与任务执行。这使得架构在部署与配置方面操作简单，易于运维；同时 Doris 能够一键加减节点、自动副本补齐与节点间的负载均衡，易于扩展；且当单节点故障时，Doris 依旧能够保持集群稳定运行，满足我们对服务高可用、数据高可靠的要求。

（*注：图表的评分由大数据团队内部选型小组根据需求评定，仅供实时数仓重构项目使用，不具备代表性）

从对比图中我们也可以看出，不论是实时还是离线场景，Apache Doris 的综合能力均衡也是优秀的一个，能够支持自助查询、实时与离线 OLAP 分析能力、高并发点查与表关联等查询场景，并且写入性能、高可用、易用性等方面表现优异，是一款能够满足多个业务场景的组件。

架构 2.0：基于 Apache Doris 统一数据服务

数仓架构的两代版本主要在存储、计算、查询分析方面有很大不同。1.0 版本依赖于多个组件共同构建 OLAP 分析引擎，在业务拓展阶段逐步出现架构存储冗余、数据延迟、维护成本过高等问题。架构 2.0 版本基于 Apache Doris 升级改造，替换了 Presto、MySQL、HBase、Clickhouse 四个组件并将数据迁移至 Apache Doris 中，以提供统一的对外查询服务。

新架构不仅实现了技术栈的统一，还降低了开发、存储与运维等各方面的成本支出，实现了业务与数据的进一步统一。基于 Apache Doris 一套系统能够同时支撑在线与离线任务处理，实现数据存储统一；能够满足了不同场景的数据分析服务，支持高吞吐的交互式分析与高并发的点查询，实现业务分析统一。

1.加速数据分析效率

通过 Doris 极速分析性能，在低延迟高并发查询中，QPS 能够达到数千至数万，对于数亿或者数十亿查询达到秒级响应；利用 Doris 丰富的数据导入，实现秒级写入，并进一步加速查询性能。此外，我们还利用了 Doris 冷热分层将海量的历史冷数据存储于廉价的 Hadoop 中，以提升对热数据的存储与查询效率。

2. 降低各类成本支出

新架构较于原有架构，核心组件的数量减少了一半，平台架构得以大幅简化，运维成本大大降低。此外，Apache Doris 使数据无需再通过不同组件完成存储与查询服务，统一了实时与离线业务负载、降低了存储成本；数据服务 API 对外提供服务时也无需再合并实时与离线数据，使数据服务 API 接入时的开发成本缩减至 50 %；

3.保证数据服务高可用

因为 Doris 的统一存储、计算和服务的数仓架构，平台整体灾备方案易于实施，不再担心多个组件造成数据丢失、重复带来的问题。更重要的是，Doris 自带的跨集群复制 CCR 功能，能够提供集群间数据库表秒级至分钟级的同步，当系统崩溃导致业务中断或者丢失时，我们可以从备份中快速恢复。

Doris 跨集群复制 CCR 功能两大机制满足了我们在系统服务可用性方面的抢需求，保证了数据服务高可用，具体如下：

Binlog 机制：当数据发生变更时，通过该机制我们可以自动记录数据修改的记录与操作，并且对每个操作构建了递增序列的 LogID，实现数据的可追溯性与有序性。

持久化机制：在系统崩溃或者发生突发事件后，通过该机制能够将数据持久化至磁盘来确保数据的可靠性和一致性。

三、项目成效

目前，基于 Apache Doris 统一技术栈的实时数仓已经在 2023年 Q3 上线并投入生产环境使用，用于支撑海量数据的 OLAP 高效分析能力，并在平台上支撑了更多业务相关的场景。在业务经营方面，销售线索的规模也在不断扩大，目前已达到亿级。随着 Apache Doris 的功能的进一步引入，由数仓支持的一线业务营收也在持续增长中。

1.销售线索高效追踪

目前，我们已经在销售与业绩类追踪上线 30 + 新场景应用，业务人员能够基于销售线索准确、快速地获取客户在官网、APP、商城、公众号、小程序等渠道的保险测评、直播参与数据、企微活动参与数据、免险投保等轨迹与数据，并通过 Apache Doris 多维分析进行线索转化，终实现精准触达客户、有效抓住客户动机、及时跟进成单。

2.客户留存信息高频更新

招商信诺在新客户转化与老客户关怀类已上线 20 + 新场景应用，业务场景的顺利进行离不开数据平台对于客户留存信息的高频更新能力，通过 Apache Doris 对老客户数据定期分析，能够有效查询客户在不同阶段的保险业务需求，发现老客户的保障缺口，拓宽老客户可保边界，进一步增加业务经营收益。

3.业务场景数据一致打通

在客户服务方面，我们更关注为客户提供一致化的体验与快速响应的服务。目前，我们已经上线了 20 + 相关服务体验的新场景应用，避免出现信息不对称、数据不一致的情况，保证各个销售环节的数据在承保、理赔、客服咨询、会员中心等流程中能够一致统一。

四、经验总结

Apache Doris 的引入在实时数仓架构简化与性能提升方面起到了至关重要的作用。目前，我们已经基于 Apache Doris 替换了 Presto、Clickhouse、MySQL、HBase 多个组件以实现 OLAP 技术栈统一、各类成本降低，并提升导入与查询性能。

同时我们也计划进一步考虑基于 Doris 在批处理层Batch Layer的尝试应用，将离线数据的批处理统一在 Doris 中进行，解决 Lambda 架构在实时和离线链路中成本叠加、无法兼容的问题，真正实现架构在计算、存储、分析的统一。同时，我们也将继续发挥实时数据统一服务的优势，利用 Multi-Catalog 让数据在湖与仓之间自由流动，实现数据湖和多种异构存储之上无缝且极速的分析服务，成为一套更完整、更开放统一的大数据技术生态系统。

更多金融科技案例和金融数据智能优秀解决方案，请在数字金融创新知识服务平台-金科创新社案例库、选型库查看。