做展厅的网站,品牌网站建设新闻,东莞网站建设营销平台的,智慧软文发稿平台本文导读#xff1a;
当前#xff0c;大数据、人工智能、云计算等技术应用正在推动保险科技发展#xff0c;加速保险行业数字化进程。在这一背景下#xff0c;招商信诺不断探索如何将多元数据融合扩充#xff0c;以赋能代理人掌握更加详实的用户线索#xff0c;并将智能…本文导读
当前大数据、人工智能、云计算等技术应用正在推动保险科技发展加速保险行业数字化进程。在这一背景下招商信诺不断探索如何将多元数据融合扩充以赋能代理人掌握更加详实的用户线索并将智能分析贯穿业务全链路实现对用户、产品、场景策略的全面洞察与闭环迭代。本文将详细介绍招商信诺在大数据基础建设方面的探索之旅从最初为线报表、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 存储具有局限性容易出现执行时间过长、系统返回错误等问题。
Clickhouse
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 不断发展壮大为基础软件建设添砖加瓦
