背景
保险业务的持续拓展，离不开企业的数字化战略创新。平安人寿秉承“一站式服务”的理念，以数据驱动服务质量，并早在 2005 年已经建立了离线数仓，将业务系统的数据集中存储于 Oracle 中并按业务需求开发数据报表，同时根据寿险的不同业务主题搭建了数据集市，以加快报表生成。
随着大数据时代的到来，传统数据库出现性能瓶颈，基于 Oracle 的数据仓库无法满足海量数据的存储、处理与应用需求，因此在 2016 年平安人寿引入了 Hadoop 建立寿险大数据平台。在近十年的大数据技术探索中，以提升数据质量、加快业务数据分析效率、加速数据价值变现为目标，平安人寿基于大数据平台构建了数据中台并引入数据治理体系，全方位保障业务用数效率、提升数据生产力。在数据应用层引入了多个开源大数据处理和分析组件，结合业务对于分析的实际需求开发了多个数据应用系统，为业务用户分析决策提供支持。
如今，随着数智化时代的到来，数据价值的重要性得到更深度认可，深挖数据价值成为新的目标。在此背景下，平安人寿坚持技术创新，以更加开放的思路来应对不断增长的数据分析和应用需求，升级大数据产品体系正是其中至关重要的一步。
为了进一步提升数据应用效率、降低多组件带来的运维和使用成本，平安人寿自 2022 年起开始引入开源实时数据仓库 Apache Doris，对多个数据应用系统进行了升级，基于 Apache Doris 统一了 OLAP 引擎层技术栈。Apache Doris 的引入为平安人寿大数据产品体系打破了原有系统的数据“孤岛”、统一了数据开发与应用层查询服务，降低了需求的开发成本、加速了业务需求的交付周期，并满足业务方更高数据时效性与查询响应度的要求，最终形成更开放、灵活、可扩展的企业级管理与分析大数据产品体系，实现数据价值的最大化释放。
本文将深入探讨大数据产品体系中应用系统的迭代升级经验，分享平安人寿在数据开发与服务化平台的创新应用实践，并介绍如何基于 Apache Doris 极速分析与融合统一的特性，助力企业运营效率提升、业务决策高效，实现由“粗放型”业务增长转变为“精细化”效益提升，通过以数据驱动的数智化转型，推进保险企业高质量发展。
早期大数据产品体系
早期大数据产品体系如上图所示，数据流转过程主要分为离线与实时两条链路：
- 离线数据通过 Sqoop 、ETL 工具接入，借助 MapReduce、Spark 或 Tez 计算引擎对数据进一步处理转化、层层加工，基于 Hive 搭建离线数仓，并分别借助 PostgreSQL、Presto、Druid、HBase、Clickhouse 以及 Kylin 等不同组件支持离线数据查询与检索。
- 实时数据通过 Kafka 消息队列实时写入，借助 Flink 计算处理，并将计算好的指标结果存储于 PostgreSQL 中，与离线数据关联查询支持上游应用层实时分析。
基于实际的分析需求，平安人寿开发了各类数据应用系统以支持不同业务人群进行决策分析，包括面向管理层的报表分析系统、面向总部运营人员的即席查询系统、面向一线业务人用的多维分析系统以及面向总部与分公司营销人员的人群圈选系统。
针对各类应用系统，在分析过程中对 OLAP 性能有不同的要求，具体如下：
- 报表分析系统：管理层需要通过报表全景分析对经营数据进行探查，了解各线业务经营情况，以支持业务洞察、问题定位、趋势预测以及经营全貌概览。当管理者在查看数据时，对于报表产出时效性与查询速度有较高的要求，通常单个报表页面涉及成千上百个指标计算，这时则需要 OLAP 能够支持高并发和低延迟响应，使报表响应时间控制在百毫秒以内。
- 即席查询：总部运营人员需要通过可视化分析直观地展示寿险理赔、核保、保全等数据结果，使运营人员能够更好地理解数据、及时地作出业务决策。在该场景中，实时、灵活地查询数据是业务运营人员最主要的诉求，因此 OLAP 需要满足数据及时更新与快速响应。
- 多维分析系统：一线业务人员结合指标数据进行多维分析，从不同角度来审视业务的衡量指标，以支持更细致的业务数据剖析。该场景是企业内最常见的应用场景，承接了一线业务 90 % 的查询流量，每日数据查询访问量高达数十万，对后台数据计算与前台响应的速度要求较高，且希望能够进行更复杂的指标二次开发。
- 人群圈选系统：总部与分公司营销人员需要通过对客户数据汇总计算后形成寿险用户属性、用户行为、用户消费等维度标签。营销人员借助多个标签找到潜在用户群体，以更精准投放与推广寿险产品。因此，灵活的开发与关联查询标签数据是营销人员最主要的诉求。
早期应用痛点
由于早期架构基于多个 OLAP 组件（包括 Presto 、PostgreSQL、Hive、Kylin、Druid、Clickhouse 以及 HBase）提供计算存储与查询服务，虽然能够满足业务要求，但架构复杂与链路过长势必会增加运维成本、学习成本，同时也无法保障系统之间多源数据的一致性。
更重要的是，随着用户规模的增长与业务场景多样化，数据的写入效率、查询时效性、后台稳定性也逐渐无法得到保证，时常影响业务分析效率。接下来，将详细为大家分析以上业务应用痛点、选型过程以及相应的解决方案，希望为读者带来关于架构升级的新视角。
01 报表分析系统
早期主要基于 Hive 与 PostgreSQL 支持该应用场景，当业务全域数据经过 ETL 清洗处理后，全量存储于 Hive 中。为了满足管理层快速查看报表的需求，开发人员首先会将数据进行多轮处理清洗，并采用预汇总结果的方式，将计算好的指标数据导入 PostgreSQL 中。
虽然这种方式能够应对查询低延迟响应的要求，但指标结果多轮计算会导致数据处理链路过长、各类成本的叠加，例如将数据拆分存储至 14 个 PostgreSQL 库中所造成的存储冗余与资源成本增加、将报表异地聚合与定制化开发所造成的开发成本增加、将 PostgreSQL 与应用端交叉使用所造成的运维成本增加等。
02 即席查询
早期即席查询场景由多个组件共同支持，其中 Hive 负责离线数据分层存储、PostgreSQL 用于存储指标结果数据、Presto 则作为查询引擎对 Hive 中数据查询下压。然而，由于业务查询严重依赖 PostgreSQL 中的指标数据，一旦未提前计算好指标，查询压力将全部交给 Presto，容易造成资源浪费、查询响应延迟等问题。同时，该系统的权限管理不清晰、业务之间没有资源隔离限制，所有业务运营人员均可以查询 Hive 底层中的数据，造成临时表多、查询任务并发过高、资源抢占等问题。
03 多维分析系统
早期该场景利用 Druid 组件提供维度与指标存储查询服务。在业务数据激增的过程中，平台容易出现导数失败或系统故障，Druid 节点重启时常需要 24 小时，系统超长重启时间对业务中断带来了巨大的风险。
同时，Druid 在查询性能中存在一定的局限性，如不支持关联查询、不支持精细去重。在理赔与用户数据 Join 的查询场景下，业务人员只能先将所需数据形成宽表满足查询需求；在面对用户数据精细去重时，只能对 Druid 组件功能改造。这些局限性不仅使查询复杂度增加，也会消耗大量的人力、学习、开发等成本。
04 人群圈选系统
早期该系统借助 HBase 提供标签计算与存储、Clickhouse 与 Kylin 作为人群圈选的查询引擎。 在标签构建过程中，由于 HBase 只能通过主键进行查询，不支持二级索引，无法使用复杂的查询语句和条件进行数据检索，开发人员需要通过主键来设计和实现标签查询，增加开发难度和复杂性。同时，HBase 的扩展能力也存在一定局限性，比如无法处理数字或日期等复杂数据类型、无法展开更细粒度的追踪调用。 在标签查询过程中，当系统面对 200 人的并发查询需求，Clickhouse 时常难以承载，需要借助 Kylin 通过 Cube 预聚合索引来分担查询压力。然而在两个组件共同提供服务时，Clickhouse 与 Kylin 配合灵活度不足成为目前系统最大的痛点之一。以查询 Array 字段为例，Clickhouse 支持 Array 而 Kylin 不支持，涉及到相关字段查询时，非常依赖于后端人工判断数据在哪种数据库中，再发送查询请求给 Clickhouse。除此之外，两个组件皆无法支持多表关联查询，也无法提供灵活的数值区间圈选。
大数据产品体系组件选型与思考
在上述各应用痛点中不难发现，组件过多容易出现数据存储冗余、数据不一致等问题，开发人员也需要来回导数整合组件之间的数据流，加重开发运维成本。并且，组件之间还会加重数据孤岛的现象，使数据之间缺乏关联与共享。基于此，我们希望选出一款综合性强、灵活度高的组件，能够统一 OLAP 技术栈，打通平台之间的数据读取，覆盖日常分析场景需求，实现高效导数与极速分析。除此之外，为了将数据治理更体系化，还希望引入的 OLAP 组件支持指标、标签等维度数据统一计算与存储，借用 API 为上游应用层提供统一查询服务。
在经过调研选型后，如图所示，我们发现 Apache Doris 非常符合升级需求，不仅能够覆盖常规业务场景，满足写查性能需求，同时，基于 Apache Doris 统一技术栈也将大幅度降低架构复杂度，减少运维、开发以及使用成本，最大化提升架构性能。因此，平安人寿基于 Apache Doris 开启了新架构的升级之旅。
大数据产品体系基于 Apache Doris 融合统一的演进之路
在未引入 Apache Doris 之前，大数据产品体系借助不同 OLAP 组件提供数据存储、计算与查询服务。引入 Apache Doris 后，平安人寿以 OLAP 引擎统一为基础，在 Apache Doris 集群之上构建了一体化指标与标签设计平台，形成 “上下经营一张表”，完善经营指标管理体系，并通过 API 接口直通应用层，面向多种场景的统一数据服务。
01 引擎优化：基于 Apache Doris 逐步统一 OLAP 技术栈
目前，平安人寿已使用 Apache Doris 替换了 HBase、PostgreSQL 、Presto 、Druid 组件，统一指标标签计算存储，支持报表分析、即席查询以及多维分析的应用，并已上线了管理层的报表应用系统、总部与一线运营人员的可视化分析系统。同时，平安人寿也已完成 Apache Doris 与各类数据源适配，进一步替换 Clickhouse、Kylin 组件。预计在今年 11 月份，Apache Doris 将上线并应用于营销机构人群圈选系统的生产使用。
通过 Apache Doris 一套系统同时满足数据存储、计算与查询服务，不仅避免了数据多轮计算带来的重复开发与冗余存储问题，更满足了更灵活、更细粒度、更高效的查询分析。平安人寿在应用上线后取得如下收益：
- 降低各类资源成本：借助 Apache Doris 丰富的数据模型，数据无需经过多轮预聚合汇总，能够大幅度简化数据处理流程，降低运维成本的同时释放了原 14 个 PostgreSQL 数据库的资源成本压力。
- 提升开发与查询效率：统一指标与标签数据开发在降本的同时更加速了业务交付时间，开发周期由原来的两周缩短至一天，效率提升 14 倍。在引入 Apache Doris 后，借助 Doris 设置了查询层级权限，使业务人员只可访问数据 ADS 层中的数据，解决数仓各表交叉使用的问题，提升指标数据复用率与使用效率；借助 Doris 优异的高并发性能满足了报表分析与多维分析场景下的秒级毫秒级的查询响应需求，查询提速达 5-10 倍。
- 打破数据孤岛，实现闭环管理：在统一技术栈的优势下，Apache Doris 打破了各类应用系统数据孤岛的现象，为业务人员提供了更全面的数据、更细粒度的维度查询，实现精细化的查询分析、一致的业务洞察视角、闭环式的数据管理，使企业上下更精准地掌握寿险经营走向。
02 语义与服务层优化：基于 Apache Doris 统一指标和标签服务
当统一了 OLAP 技术栈后，平安人寿进一步引入统一语义层，将复杂查询语句进行拆解转化，简化加速 SQL 语句执行效率，并借助数据服务 API 接入的方式，连接各业务应用层。
借助这种方式，平安人寿全域数据从采集接入后进入 Doris 数仓，业务人员在后台通过拖拽实现指标标签数据自助定义和自动计算，生成的 SQL 会发送至 Doris ADS 层中。其中，若涉及复杂的多表关联查询，SQL 语句会在语义层中过滤，生成简单的执行语句。借助通用的 API 服务，调用 Doris 库中数据，统一支持业务分析在客户经营、代理人、保单、产品、理赔等方面的需求。目前，平安人寿基于统一服务化平台已支持日均数百万次的数据调用，每张报表的查询响应时间实现 200 - 300 ms ，实现多场景下极速、统一的数据服务。
至此，平安人寿从数据设计直通数据服务，有效避免业务之间冗余开发与重复使用，缩短业务交付周期，加速查询响应时间。基于高内聚低耦合的统一服务平台，使查询分析能够及时配合业务需求变更，确保了企业内外数据流转的流畅性。
总结与未来规划
一站式数据门户是平安人寿大数据产品体系自始至终的构建目标，基于 Apache Doris 统一 OLAP 多个技术栈，并将标签与指标标准化开发与管理，共同提供统一的数据服务，使业务分析师能够进行自助式的数据探查，减少对技术人员的依赖，同时，通过方便快捷地访问、分析和可视化各种数据资源，实现数据高效、低成本的交付。
未来，平安人寿将进一步拓展 Apache Doris 湖仓一体化的应用，使用 Doris 替换 Presto 进行数据湖查询分析，让数据和计算在湖与仓之间自由流动。同时，还将引入 Apache Doris 多租户和资源隔离方案，完善应用系统间负载均衡性能，避免导数过程中出现任务并发高、CPU 内存占用大、查询性能受阻的风险，减少多用户数据操作时在同一集群内被干扰，将集群资源更合理的分配给各个应用系统。
平安人寿将持续推动保险行业转型进程，带来更多业务机会与产品创新，也将持续参与 Apache Doris 的社区建设，将相关成果贡献回馈社区，实现价值共享！
快来关注
2023年10月31日-11月2日，云栖大会在杭州举办，阿里云正式对外发布了云原生全托管产品——“阿里云数据库 SelectDB 版”，SelectDB 是基于 Apache Doris 内核打造的聚焦于企业大数据实时分析需求的企业级产品，通过深度融合云随需而用的特性，构建起云原生存算分离的全新架构，面向企业海量数据的实时分析需求提供极速实时、融合统一、简单易用的云上数仓服务。
