招商信诺人寿基于 Apache Doris 统一 OLAP 技术栈实践
当前，大数据、人工智能、云计算等技术应用正在推动保险科技发展，加速保险行业数字化进程。在这一背景下，招商信诺不断探索如何将多元数据融合扩充，以赋能代理人掌握更加详实的用户线索，并将智能分析贯穿业务全链路，实现对用户、产品、场景策略的全面洞察与闭环迭代。本文将详细介绍招商信诺在大数据基础建设方面的探索之旅，从最初为线报表、Ad-hoc 分析提供服务的 OLAP 引擎，逐步发展至基于 Apache Doris 构建的统一实时数据仓库，通过一套架构实现各业务领域的多元数据实时分析与融合统一管理，最终实现保险一线业务降本增收的目标。
作者｜招商信诺大数据平台研发团队
招商信诺人寿是由招商银行与信诺集团中外合资的寿险公司，为企业和个人提供涵盖保险保障、健康管理、财富规划等产品及服务。目前，招商信诺已累积服务客户超千万、完成理赔客户超百万，并凭借一站式便捷的健康管理服务、可灵活配置“定制化”的保险方案获得广大用户的持续选择与信赖。
架构架构 1.0 ：多组件准实时数仓
保单自助查询：用户通过招商信诺 APP 根据保单 ID 自助查询承保合同，或者通过不同维度（如承保时间、保险类别、理赔金额）进行自定义筛选查询，查看保单生命周期内的信息。
多维报表分析：依据业务需求，业务分析人员通过开发明细数据、指标维度报表，获得关于保单在产品创新、费率、反理赔欺诈等方面的业务洞察，并据此支持经营策略调整。
数据大屏（Dashboard）：主要用于某银行渠道、某分公司的实时大屏，通过对指标等数据的统一汇总，将热门险种、每日销售额、保险种类缴纳总额与占比、历年保险缴纳涨幅趋势等信息展示于实时大屏中。
业务初期对数据服务的要求较为单一，主要是以提升报表数据的时效性为主，因此在数仓搭建的过程中，我们采用典型的 Lambda 架构，通过实时与离线两条链路分别进行数据采集、计算与存储，其中数仓主要采用宽表模型设计以支持对指标数据、明细数据的查询分析。
由架构图可以看到，FlinkCDC 负责实时数据采集，我们自研的 Hisen 工具（包括 Sqoop、DataX 以及 Python）负责离线数据采集。原始数据采集后，实时数据利用 Flink 进行计算、离线数据交由 Hive 进行批处理，最终导入至不同的 OLAP 组件（包括 Presto、Clickhouse、HBase 以及 MySQL）中，由 OLAP 向上层业务提供数据服务，其中各组件在架构中分别扮演不同的角色：
MySQL：按照业务需求，在数据完成计算后主要用于存储指标数据。目前，数仓表的数据量已经突破千万级， 而 MySQL 存储具有局限性，容易出现执行时间过长、系统返回错误等问题。
Clickhouse：Clickhouse 在单表数据读取的性能上表现出色，在大表 Join 性能较弱。随着业务场景的增加，实时数据量不断叠加与更新下，Clickhouse 面对新的业务需求存在一定局限：
为减少指标重复计算，需要引入星型模型进行多表关联与高并发点查询，而 Clickhouse 无法支持；
当保单内容发生变更时，需要数据实时更新写入，而 Clickhouse 缺少实时事务的支持，面对数据变更时需要重新生成宽表以覆盖旧数据，在数据更新时效性要求方面存在一定不足。
HBase：主要用于主键查询，从 MySQL 与 Hive 中读取用户基础状态数据，包括客户积分、承保时间、累积承保保额。由于 HBase 不支持二级索引，对于非主键的数据读取较为局限，无法满足关联查询场景，同时 HBase 也不支持 SQL 语句查询。
Presto：由于上述组件在数据查询方面的场景限制，我们还引入了 Presto 作为离线数据的查询引擎，用于与 Hive 中的数据进行交互式分析，为上游端提供报表服务。
在数仓 1.0 版本上线后，已在超过 10 余家分公司中上线使用，开发了大量的数据大屏以及 BI 报表。随着业务范围的不断拓展，营销、运营以及客户服务等场景对数据写入与查询性能提出了更高的要求，然而混合使用四个组件提供数据服务的 1.0 版本架构在实际业务中存在一些挑战。为了避免由于架构组件过多所产生的运维成本升高、研发人员学习成本升高等问题，也为了确保在离线与实时链路中多源数据的一致性，我们决定展开架构更新迭代之旅。
组件需求与系统选型
导入性能：具备实时写入、实时更新的能力，并支持高吞吐的海量数据写入。 查询性能：提供维度数据以及交易数据的查询服务，具备高性能的海量数据实时查询的能力。 灵活性多维分析、自助查询能力：不仅能够支持主键索引以提供点查与范围查询，还能够支持多维度检索分析，提供对亿级数据的表关联查询，实现灵活动态、下钻上卷的业务数据分析。 数据平台架构简化：需要一款综合能力强的组件以替换当前冗余架构，满足在实时与离线数据的读写、不同场景下的高查询性能、简单易用的 SQL 语句查询等能力。
支持低延迟实时写入：支持 FlinkCDC 在海量数据下的高吞吐写入，提供实时数据对外服务；支持主键表模型写时合并，实现微批高频实时写入；支持 Upsert 与 Insert Overwrite，保证高效的数据更新。 保证数据一致有序：支持 Label 机制和事务性导入，保证写入过程中 Exactly Once 语义；支持主键模型 Sequence 列设置，保证数据导入过程中的有序性。 查询性能优异：Doris 支持 Rollup 预聚合与物化视图完成查询加速；支持向量化处理以减少虚函数调用和 Cache Miss；支持倒排索引以加速文本类、普通数值、日期类等全文检索或范围查询。 支持高并发点查询：支持分区分桶裁剪，通过 Partition 将时间分区、设置 Bucket 数量过滤非必要的数据，以减少底层数据扫描，实现查询快速定位；此外，在 Doris 2.0 版本中还新增了行式存储格式、短路径点查、预处理语句等一系列优化，进一步提升点查执行效率、降低 SQL 解析开销。 支持多种数据模型：支持星型模型，满足亿级数据表关联查询需求；支持大宽表聚合，提供单表极速查询性能与多维分析能力。 架构简单、易运维、易扩展、高可用：Doris FE 节点负责管理元数据与多副本、BE 节点负责数据存储与任务执行。这使得架构在部署与配置方面操作简单，易于运维；同时 Doris 能够一键加减节点、自动副本补齐与节点间的负载均衡，易于扩展；且当单节点故障时，Doris 依旧能够保持集群稳定运行，满足我们对服务高可用、数据高可靠的要求。
03 保证数据服务高可用
Binlog 机制：当数据发生变更时，通过该机制我们可以自动记录数据修改的记录与操作，并且对每个操作构建了递增序列的 LogID，实现数据的可追溯性与有序性。 持久化机制：在系统崩溃或者发生突发事件后，通过该机制能够将数据持久化至磁盘来确保数据的可靠性和一致性。
销售线索高效追踪：目前，我们已经在销售与业绩类追踪上线 30 + 新场景应用，业务人员能够基于销售线索准确、快速地获取客户在官网、APP、商城、公众号、小程序等渠道的保险测评、直播参与数据、企微活动参与数据、免险投保等轨迹与数据，并通过 Apache Doris 多维分析进行线索转化，最终实现精准触达客户、有效抓住客户动机、及时跟进成单。
客户留存信息高频更新：在新客户转化与老客户关怀类已上线 20 + 新场景应用，业务场景的顺利进行离不开数据平台对于客户留存信息的高频更新能力，通过 Apache Doris 对老客户数据定期分析，能够有效查询客户在不同阶段的保险业务需求，发现老客户的保障缺口，拓宽老客户可保边界，进一步增加业务经营收益。
业务场景数据一致打通：在客户服务方面，我们更关注为客户提供一致化的体验与快速响应的服务。目前，我们已经上线了 20 + 相关服务体验的新场景应用，避免出现信息不对称、数据不一致的情况，保证各个销售环节的数据在承保、理赔、客服咨询、会员中心等流程中能够一致统一。
未来规划
同时我们也计划进一步基于 Doris 在批处理层（Batch Layer）尝试应用，将离线数据批处理统一在 Doris 中进行，解决 Lambda 架构在实时和离线链路中成本叠加、无法兼容的问题，真正实现架构在计算、存储、分析的统一。同时，我们也将继续发挥 Doris 统一的优势，利用 Multi-Catalog 让数据在湖与仓之间自由流动，实现数据湖和多种异构存储之上无缝且极速的分析服务，成为一套更完整、更开放统一的大数据技术生态系统。
非常感谢 SelectDB 团队一直以来对我们的技术支持。至此，招商信诺数据仓库不再局限于简单的报表场景，通过一套架构支撑了多种不同场景的数据分析、满足了实时与离线数据的统一写入与查询，为产品营销、客户运营、C 端以及 B 端等业务提供数据价值，使保险人员更高效地获取数据、更准确地预知客户需求，为企业获得先机。
未来，我们也会持续参与到 Apache Doris 社区建设中，贡献保险行业在实时数仓的建设经验与实践应用，希望 Apache Doris 不断发展壮大，为基础软件建设添砖加瓦！
- END-
欢迎更多的开源技术爱好者加入 Apache Doris 社区交流群，携手成长，共建社区生态。Apache Doris 社区当前已汇集了上万名开发者和使用者，承载了 50+ 交流社群，如果你也是 Apache Doris 的爱好者，非常欢迎您的加入！