作者：招商信诺大数据平台研发团队
导读： 当前，大数据、人工智能、云计算等技术应用正在推动保险科技发展，加速保险行业数字化进程。在这一背景下，招商信诺不断探索如何将多元数据融合扩充，以赋能代理人掌握更加详实的用户线索，并将智能分析贯穿业务全链路，实现对用户、产品、场景策略的全面洞察与闭环迭代。本文将详细介绍招商信诺在大数据基础建设方面的探索之旅，从最初为线报表、Ad-hoc 分析提供服务的 OLAP 引擎，逐步发展至基于Apache Doris 构建的统一实时数据仓库，通过一套架构实现各业务领域的多元数据实时分析与融合统一管理，最终实现保险一线业务降本增收的目标。
招商信诺人寿是由招商银行与信诺集团中外合资的寿险公司，为企业和个人提供涵盖保险保障、健康管理、财富规划等产品及服务。目前，招商信诺已累积服务客户超千万、完成理赔客户超百万，并凭借一站式便捷的健康管理服务、可灵活配置“定制化”的保险方案获得广大用户的持续选择与信赖。
面对全球数据量爆炸性增长的趋势，数据的时效性与准确性对企业精细化运营越来越重要。我们希望通过数据能够快速感知客户行为、定位客户问题、高效匹配用户所需的产品与服务，以达到精细化业务营销、拓宽可保边界等目标。
随着业务不断拓展、分析场景逐渐多元化，业务分析师的要求也变得更为复杂，不仅要求数仓能够快速开发数据报表，还需要实现流批一体、湖仓一体、多元化数据类型的统一分析与管理。在大数据基础建设中，这些融合统一的特性变得至关重要。在这样的背景下，我们持续升级与改进数仓架构，从最初仅支持Bl报表、数据大屏的一代架构到采用多个系统和组件提供数据服务的二代架构，再到如今新一代统一实时数据仓库，通过ApacheDoris一套组件实现了架构的简化、技术栈的统一、数据的统一管理与分析，不仅提升了数据处理效率，并且满足了更多样化的数据分析需求。
本文将详细介绍招商信诺在数仓架构迭代与升级过程中如何基于 Apache Doris统一存储、计算和查询出口、如何满足写入时效性的要求、如何在高并发点查与多表关联等场景下实现极速查询性能，为销售线索高效写入与查询、客户留存信息高频更新、服务场景数据一致打通等方面提供助力，进一步将客户线索转化为私域商机，赋予企业在经营、服务、营销等多方面的能力。
架构1.0:多组件准实时数仓
最初的业务需求是希望通过数仓来承载面向 C端用户的保单自助查询、面向业务分析人员的多维分析报表以及面向管理者的实时数据大屏(Dashboard) 三类业务场景。数仓需要满足业务数据的统一存储和高效的查询能力，以支持业务高效分析决策，同时还需要支持数据回写，以实现闭环式业务运营。
●保单自助查询：用户通过招商信诺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 余家分公司中上线使用，开发了大量的数据大屏以及 Bl报表。随着业务范围的不断拓展，营销、运营以及客户服务等场景对数据写入与查询性能提出了更高的要求，然而混合使用四个组件提供数据服务的1.0版本架构在实际业务中存在一些挑战。为了避免由于架构组件过多所产生的运维成本升高、研发人员学习成本升高等问题，也为了确保在离线与实时链路中多源数据的一致性，我们决定展开架构更新迭代之旅。
组件需求与系统选型
为满足业务需求，我们需要为架构“减负”,尽可能地缩短数据处理过程。而1.0 架构由于组件过多，链路冗余等问题势必降低了数据存储与分析的性能与时效性。因此，我们希望寻找一个OLAP 系统既能覆盖大部分的业务场景，也能够降低复杂技术栈带来的开发、运维和使用成本，还能最大化的提升架构性能。具体要求如下：
●导入性能：具备实时写入、实时更新的能力，并支持高吞吐的海量数据写入。
●查询性能：提供维度数据以及交易数据的查询服务，具备高性能的海量数据实时查询的能力。
●灵活性多维分析、自助查询能力：不仅能够支持主键索引以提供点查与范围查询，还能够支 持多维度检索分析，提供对亿级数据的表关联查询，实现灵活动态、下钻上卷的业务数据分析。
●数据平台架构简化：需要一款综合能力强的组件以替换当前冗余架构，满足在实时与离线数据的读写、不同场景下的高查询性能、简单易用的SQL语句查询等能力。
基于此，我们开始系统选型，将市面上热门组件与现有架构进行多方面对比，评估是否满足业务方对组件的需求，最终在众多OLAP 中锁定了ApacheDoris,具体原因如下
● 支持低延迟实时写入：支持FlinkCDC 在海量数据下的高吞吐写入，提供实时数据对外服务；支持主键表模型写时合并，实现微批高频实时写入；支持 Upsert 与 Insert Overwrite,保证高效的数据更新。
● 保证数据一致有序：支持Label机制和事务性导入，保证写入过程中Exactly Once 语义；支持主键模型Sequence 列设置，保证数据导入过程中的有序性。
● 查询性能优异：Doris支持 Rollup 预聚合与物化视图完成查询加速；支持向量化处理以减少虚函数调用和CacheMiss; 支持倒排索引以加速文本类、普通数值、日期类等全文检索或范索或范
●支持高并发点查询：支持分区分桶裁剪，通过 Partition将时间分区、设置 Bucket 数量过滤非必要的数据，以减少底层数据扫描，实现查询快速定位；此外，在Doris 2.0版本中还新增了行式存储格式、短路径点查、预处理语句等一系列优化，进一步提升点查执行效率、降低SQL解析开销。
● 支持多种数据模型： 支持星型模型，满足亿级数据表关联查询需求；支持大宽表聚合，提供单表极速查询性能与多维分析能力。
● 架构简单、易运维、易扩展、高可用：Doris FE 节点负责管理元数据与多副本、BE节点负责数据存储与任务执行。这使得架构在部署与配置方面操作简单，易于运维；同时 Doris能够一键加减节点、自动副本补齐与节点间的负载均衡，易于扩展；且当单节点故障时， Doris依旧能够保持集群稳定运行，满足我们对服务高可用、数据高可靠的要求。
注：图表评分由大数据团队内部选型小组根据需求评定，仅供实时数仓重构项目使用，不具备代表性
从对比图中我们也可以看出，不论是实时还是离线场景，ApacheDoris的综合能力最均衡也是最优秀的一个，能够支持自助查询、实时与离线OLAP 分析能力、高并发点查与表关联等查询场景，并且写入性能、高可用、易用性等方面表现优异，是一款能够满足多个业务场景的组件。
更多精彩内容，欢迎观看：
带你读《Apache Doris 案例集》—— 01 招商信诺人寿 基于 Apache Doris 统一 OLAP 技术栈实践（2）:https://developer.aliyun.com/article/1405779
