关于数据库:招商信诺人寿基于-Apache-Doris-统一-OLAP-技术栈实践

32次阅读

共计 5836 个字符,预计需要花费 15 分钟才能阅读完成。

本文导读:

以后,大数据、人工智能、云计算等技术利用正在推动保险科技倒退,减速保险行业数字化过程。在这一背景下,招商信诺一直摸索如何将多元数据交融裁减,以赋能代理人把握更加详实的用户线索,并将智能剖析贯通业务全链路,实现对用户、产品、场景策略的全面洞察与闭环迭代。本文将具体介绍招商信诺在大数据根底建设方面的探索之旅,从最后为线报表、Ad-hoc 剖析提供服务的 OLAP 引擎,逐渐倒退至基于 Apache Doris 构建的对立实时数据仓库,通过一套架构实现各业务畛域的多元数据实时剖析与交融对立治理,最终实现保险一线业务降本增收的指标。

作者:招商信诺大数据平台研发团队


招商信诺人寿是由招商银行与信诺团体中外合资的寿险公司,为企业和集体提供涵盖保险保障、衰弱治理、财产布局等产品及服务。目前,招商信诺已累积服务客户超千万、实现理赔客户超百万,并凭借一站式便捷的衰弱治理服务、可灵便配置“定制化”的保险计划取得宽广用户的继续抉择与信赖。

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

随着业务一直拓展、剖析场景逐步多元化,业务分析师的要求也变得更为简单,不仅要求数仓可能疾速开发数据报表,还须要实现流批一体、湖仓一体、多元化数据类型的对立剖析与治理。在大数据根底建设中,这些交融对立的个性变得至关重要。在这样的背景下,继续降级与改良数仓架构,从最后仅反对 BI 报表、数据大屏的一代架构到采纳多个零碎和组件提供数据服务的二代架构,再到现在新一代对立实时数据仓库,通过 Apache Doris 一套组件实现了架构的简化、技术栈的对立、数据的对立治理与剖析,不仅晋升了数据处理效率,并且满足了更多样化的数据分析需要。

本文将具体介绍招商信诺在数仓架构迭代与降级过程中如何基于 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 存储具备局限性,容易呈现执行工夫过长、零碎返回谬误等问题。

Clickhosue

Clickhouse 在单表数据读取的性能上表现出色,在大表 Join 性能较弱。随着业务场景的减少,实时数据量一直叠加与更新下,Clickhouse 面对新的业务需要存在肯定局限:

  • 为缩小指标反复计算,须要引入星型模型进行多表关联与高并发点查问,而 Clickhouse 无奈反对;
  • 当保单内容产生变更时,须要数据实时更新写入,而 Clickhouse 短少实时事务的反对,面对数据变更时须要从新生成宽表以笼罩旧数据,在数据更新时效性要求方面存在肯定有余;

HBase

次要用于主键查问,从 MySQL 与 Hive 中读取用户根底状态数据,包含客户积分、承保工夫、累积承保保额。因为 HBase 不反对二级索引,对于非主键的数据读取较为局限,无奈满足关联查问场景,同时 HBase 也不反对 SQL 语句查问。

Presto

因为上述组件在数据查问方面的场景限度,咱们还引入了 Presto 作为离线数据的查问引擎,用于与 Hive 中的数据进行交互式剖析,为上游端提供报表服务。

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

组件需要与零碎选型

为满足业务需要,咱们须要为架构“减负”,尽可能地缩短数据处理过程。而 1.0 架构因为组件过多,链路冗余等问题势必升高了数据存储与剖析的性能与时效性。因而,咱们心愿寻找一个 OLAP 零碎既能笼罩大部分的业务场景,也可能升高简单技术栈带来的开发、运维和应用老本,还能最大化的晋升架构性能。具体要求如下:

  • 导入性能:具备实时写入、实时更新的能力,并反对高吞吐的海量数据写入。
  • 查问性能:提供维度数据以及交易数据的查问服务,具备高性能的海量数据实时查问的能力。
  • 灵活性多维分析、自助查问能力:不仅可能反对主键索引以提供点查与范畴查问,还可能反对多维度检索剖析,提供对亿级数据的表关联查问,实现灵便动静、下钻上卷的业务数据分析。
  • 数据平台架构简化:须要一款综合能力强的组件以替换以后冗余架构,满足在实时与离线数据的读写、不同场景下的高查问性能、简略易用的 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 一套零碎可能同时撑持在线与离线工作解决,实现 数据存储对立 ;可能满足了不同场景的数据分析服务,反对高吞吐的交互式剖析与高并发的点查问,实现 业务剖析对立

01 减速数据分析效率

通过 Doris 极速剖析性能,在面向 C 端用户的高并发点查问场景中,QPS 可能达到数千至数万,对于数亿或者数十亿数据的查问达到毫秒级响应; 利用 Doris 丰盛的数据导入形式和高效的写入能力,实现秒级写入时延,并利用 Unique Key 写时合并来进一步减速在并行读写阶段的查问性能。此外,咱们还利用了 Doris 冷热分层将海量的历史冷数据存储于便宜的存储介质中,升高了历史数据的存储老本并晋升了对热数据的查问效率。

02 升高各类老本收入

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

03 保障数据服务高可用

因为 Doris 的对立存储、计算和服务的数仓架构,平台整体灾备计划易于施行,不再放心多个组件造成数据失落、反复带来的问题。更重要的是,Doris 自带的跨集群复制 CCR 性能,可能提供集群间数据库表秒级至分钟级的同步,当零碎解体导致业务中断或者失落时,咱们能够从备份中疾速复原。

Doris 跨集群复制 CCR 性能两大机制满足了咱们在零碎服务可用性方面的抢需要,保障了数据服务高可用,具体如下:

  • Binlog 机制:当数据产生变更时,通过该机制咱们能够自动记录数据批改的记录与操作,并且对每个操作构建了递增序列的 LogID,实现数据的可追溯性与有序性。
  • 长久化机制:在零碎解体或者产生突发事件后,通过该机制可能将数据长久化至磁盘来确保数据的可靠性和一致性。

保险一线业务收益与实际

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

  • 销售线索高效追踪: 目前,咱们曾经在销售与业绩类追踪上线 30 + 新场景利用,业务人员可能基于销售线索精确、疾速地获取客户在官网、APP、商城、公众号、小程序等渠道的保险测评、直播参加数据、企微流动参加数据、免险投保等轨迹与数据,并通过 Apache Doris 多维分析进行线索转化,最终实现精准触达客户、无效抓住客户动机、及时跟进成单。
  • 客户留存信息高频更新: 在新客户转化与老客户关心类已上线 20 + 新场景利用,业务场景的顺利进行离不开数据平台对于客户留存信息的高频更新能力,通过 Apache Doris 对老客户数据定期剖析,可能无效查问客户在不同阶段的保险业务需要,发现老客户的保障缺口,拓宽老客户可保边界,进一步减少业务经营收益。
  • 业务场景数据统一买通: 在客户服务方面,咱们更关注为客户提供统一化的体验与疾速响应的服务。目前,咱们曾经上线了 20 + 相干服务体验的新场景利用,避免出现信息不对称、数据不统一的状况,保障各个销售环节的数据在承保、理赔、客服征询、会员中心等流程中可能统一对立。

将来布局

Apache Doris 的引入在实时数仓架构简化与性能晋升方面起到了至关重要的作用。目前,咱们曾经基于 Apache Doris 替换了 Presto、Clickhouse、MySQL、HBase 多个组件以实现 OLAP 技术栈对立、各类老本升高,并晋升导入与查问性能。

同时咱们也打算进一步基于 Doris 在批处理层(Batch Layer)的尝试利用,将离线数据批处理对立在 Doris 中进行,解决 Lambda 架构在实时和离线链路中老本叠加、无奈兼容的问题,真正实现架构在计算、存储、剖析的对立。同时,咱们也将持续施展 Doris 对立的劣势,利用 Multi-Catalog 让数据在湖与仓之间自在流动,实现数据湖和多种异构存储之上无缝且极速的剖析服务,成为一套更残缺、更凋谢对立的大数据技术生态系统。

非常感谢 SelectDB 团队始终以来对咱们的技术支持。至此,招商信诺数据仓库不再局限于简略的报表场景,通过一套架构撑持了多种不同场景的数据分析、满足了实时与离线数据的对立写入与查问,为产品营销、客户经营、C 端以及 B 端等业务提供数据价值,使保险人员更高效地获取数据、更精确地预知客户需要,为企业取得先机。

将来,咱们也会继续参加到 Apache Doris 社区建设中,奉献保险行业在实时数仓的建设教训与实际利用,心愿 Apache Doris 一直发展壮大,为根底软件建设添砖加瓦!

正文完
 0