【金猿案例展】中國平安人壽保險股份有限公司——基于Apache Doris統(tǒng)一OLAP技術(shù)棧實踐

金猿案例展中國平安人壽保險股份 OLAP技術(shù)棧

杜天敏、孫順 | 2024-01-12 21:06

【數(shù)據(jù)猿導讀】本項目案例由飛輪科技投遞并參與“數(shù)據(jù)猿年度金猿策劃活動——2023大數(shù)據(jù)產(chǎn)業(yè)年度創(chuàng)新服務(wù)企業(yè)榜單/獎項”評選。

【金猿案例展】中國平安人壽保險股份有限公司——基于Apache Doris統(tǒng)一OLAP技術(shù)棧實踐

飛輪科技案例

本項目案例由飛輪科技投遞并參與“數(shù)據(jù)猿年度金猿策劃活動——2023大數(shù)據(jù)產(chǎn)業(yè)年度創(chuàng)新服務(wù)企業(yè)榜單/獎項”評選。

保險業(yè)務(wù)的持續(xù)拓展，離不開企業(yè)的數(shù)字化戰(zhàn)略創(chuàng)新。平安人壽秉承“一站式服務(wù)”的理念，以數(shù)據(jù)驅(qū)動服務(wù)質(zhì)量，并早在 2005 年已經(jīng)建立了離線數(shù)倉，將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)集中存儲于 Oracle 中并按業(yè)務(wù)需求開發(fā)數(shù)據(jù)報表，同時根據(jù)壽險的不同業(yè)務(wù)主題搭建了數(shù)據(jù)集市，以加快報表生成。

隨著大數(shù)據(jù)時代的到來，傳統(tǒng)數(shù)據(jù)庫出現(xiàn)性能瓶頸，基于 Oracle 的數(shù)據(jù)倉庫無法滿足海量數(shù)據(jù)的存儲、處理與應(yīng)用需求，因此在 2016 年平安人壽引入了 Hadoop 建立壽險大數(shù)據(jù)平臺。在近十年的大數(shù)據(jù)技術(shù)探索中，以提升數(shù)據(jù)質(zhì)量、加快業(yè)務(wù)數(shù)據(jù)分析效率、加速數(shù)據(jù)價值變現(xiàn)為目標，平安人壽基于大數(shù)據(jù)平臺構(gòu)建了數(shù)據(jù)中臺并引入數(shù)據(jù)治理體系，全方位保障業(yè)務(wù)用數(shù)效率、提升數(shù)據(jù)生產(chǎn)力。在數(shù)據(jù)應(yīng)用層引入了多個開源大數(shù)據(jù)處理和分析組件，結(jié)合業(yè)務(wù)對于分析的實際需求開發(fā)了多個數(shù)據(jù)應(yīng)用系統(tǒng)，為業(yè)務(wù)用戶分析決策提供支持。

如今，隨著數(shù)智化時代的到來，數(shù)據(jù)價值的重要性得到更深度認可，深挖數(shù)據(jù)價值成為新的目標。在此背景下，平安人壽堅持技術(shù)創(chuàng)新，以更加開放的思路來應(yīng)對不斷增長的數(shù)據(jù)分析和應(yīng)用需求，升級大數(shù)據(jù)產(chǎn)品體系正是其中至關(guān)重要的一步。

為了進一步提升數(shù)據(jù)應(yīng)用效率、降低多組件帶來的運維和使用成本，平安人壽自 2022 年起開始引入開源實時數(shù)據(jù)倉庫 Apache Doris，對多個數(shù)據(jù)應(yīng)用系統(tǒng)進行了升級，基于 Apache Doris 統(tǒng)一了 OLAP 引擎層技術(shù)棧。Apache Doris 的引入為平安人壽大數(shù)據(jù)產(chǎn)品體系打破了原有系統(tǒng)的數(shù)據(jù)“孤島”、統(tǒng)一了數(shù)據(jù)開發(fā)與應(yīng)用層查詢服務(wù)，降低了需求的開發(fā)成本、加速了業(yè)務(wù)需求的交付周期，并滿足業(yè)務(wù)方更高數(shù)據(jù)時效性與查詢響應(yīng)度的要求，最終形成更開放、靈活、可擴展的企業(yè)級管理與分析大數(shù)據(jù)產(chǎn)品體系，實現(xiàn)數(shù)據(jù)價值的最大化釋放。

應(yīng)用場景

基于實際的分析需求，平安人壽開發(fā)了各類數(shù)據(jù)應(yīng)用系統(tǒng)以支持不同業(yè)務(wù)人群進行決策分析，包括面向管理層的報表分析系統(tǒng)、面向總部運營人員的即席查詢系統(tǒng)、面向一線業(yè)務(wù)人用的多維分析系統(tǒng)以及面向總部與分公司營銷人員的人群圈選系統(tǒng)。

- 報表分析系統(tǒng)：管理層需要通過報表全景分析對經(jīng)營數(shù)據(jù)進行探查，了解各線業(yè)務(wù)經(jīng)營情況，以支持業(yè)務(wù)洞察、問題定位、趨勢預(yù)測以及經(jīng)營全貌概覽。當管理者在查看數(shù)據(jù)時，對于報表產(chǎn)出時效性與查詢速度有較高的要求，通常單個報表頁面涉及成千上百個指標計算，這時則需要 OLAP 能夠支持高并發(fā)和低延遲響應(yīng)，使報表響應(yīng)時間控制在百毫秒以內(nèi)。

- 即席查詢：總部運營人員需要通過可視化分析直觀地展示壽險理賠、核保、保全等數(shù)據(jù)結(jié)果，使運營人員能夠更好地理解數(shù)據(jù)、及時地作出業(yè)務(wù)決策。在該場景中，實時、靈活地查詢數(shù)據(jù)是業(yè)務(wù)運營人員最主要的訴求，因此 OLAP 需要滿足數(shù)據(jù)及時更新與快速響應(yīng)。

- 多維分析系統(tǒng)：一線業(yè)務(wù)人員結(jié)合指標數(shù)據(jù)進行多維分析，從不同角度來審視業(yè)務(wù)的衡量指標，以支持更細致的業(yè)務(wù)數(shù)據(jù)剖析。該場景是企業(yè)內(nèi)最常見的應(yīng)用場景，承接了一線業(yè)務(wù) 90 % 的查詢流量，每日數(shù)據(jù)查詢訪問量高達數(shù)十萬，對后臺數(shù)據(jù)計算與前臺響應(yīng)的速度要求較高，且希望能夠進行更復雜的指標二次開發(fā)。

- 人群圈選系統(tǒng)：總部與分公司營銷人員需要通過對客戶數(shù)據(jù)匯總計算后形成壽險用戶屬性、用戶行為、用戶消費等維度標簽。營銷人員借助多個標簽找到潛在用戶群體，以更精準投放與推廣壽險產(chǎn)品。因此，靈活的開發(fā)與關(guān)聯(lián)查詢標簽數(shù)據(jù)是營銷人員最主要的訴求。

面臨挑戰(zhàn)

由于早期架構(gòu)基于多個 OLAP 組件（包括 Presto 、PostgreSQL、Hive、Kylin、Druid、Clickhouse 以及 HBase）提供計算存儲與查詢服務(wù)，雖然能夠滿足業(yè)務(wù)要求，但架構(gòu)復雜與鏈路過長勢必會增加運維成本、學習成本，同時也無法保障系統(tǒng)之間多源數(shù)據(jù)的一致性。

更重要的是，隨著用戶規(guī)模的增長與業(yè)務(wù)場景多樣化，數(shù)據(jù)的寫入效率、查詢時效性、后臺穩(wěn)定性也逐漸無法得到保證，時常影響業(yè)務(wù)分析效率。各場景面臨的挑戰(zhàn)具體包括：

1、報表分析系統(tǒng)

早期主要基于 Hive 與 PostgreSQL 支持該應(yīng)用場景，當業(yè)務(wù)全域數(shù)據(jù)經(jīng)過 ETL 清洗處理后，全量存儲于 Hive 中。為了滿足管理層快速查看報表的需求，開發(fā)人員首先會將數(shù)據(jù)進行多輪處理清洗，并采用預(yù)匯總結(jié)果的方式，將計算好的指標數(shù)據(jù)導入 PostgreSQL 中。

雖然這種方式能夠應(yīng)對查詢低延遲響應(yīng)的要求，但指標結(jié)果多輪計算會導致數(shù)據(jù)處理鏈路過長、各類成本的疊加，例如將數(shù)據(jù)拆分存儲至 14 個 PostgreSQL 庫中所造成的存儲冗余與資源成本增加、將報表異地聚合與定制化開發(fā)所造成的開發(fā)成本增加、將 PostgreSQL 與應(yīng)用端交叉使用所造成的運維成本增加等。

2、即席查詢

早期即席查詢場景由多個組件共同支持，其中 Hive 負責離線數(shù)據(jù)分層存儲、PostgreSQL 用于存儲指標結(jié)果數(shù)據(jù)、Presto 則作為查詢引擎對 Hive 中數(shù)據(jù)查詢下壓。然而，由于業(yè)務(wù)查詢嚴重依賴 PostgreSQL 中的指標數(shù)據(jù)，一旦未提前計算好指標，查詢壓力將全部交給 Presto，容易造成資源浪費、查詢響應(yīng)延遲等問題。同時，該系統(tǒng)的權(quán)限管理不清晰、業(yè)務(wù)之間沒有資源隔離限制，所有業(yè)務(wù)運營人員均可以查詢 Hive 底層中的數(shù)據(jù)，造成臨時表多、查詢?nèi)蝿?wù)并發(fā)過高、資源搶占等問題。

3、多維分析系統(tǒng)

早期該場景利用 Druid 組件提供維度與指標存儲查詢服務(wù)。在業(yè)務(wù)數(shù)據(jù)激增的過程中，平臺容易出現(xiàn)導數(shù)失敗或系統(tǒng)故障，Druid 節(jié)點重啟時常需要 24 小時，系統(tǒng)超長重啟時間對業(yè)務(wù)中斷帶來了巨大的風險。

同時，Druid 在查詢性能中存在一定的局限性，如不支持關(guān)聯(lián)查詢、不支持精細去重。在理賠與用戶數(shù)據(jù) Join 的查詢場景下，業(yè)務(wù)人員只能先將所需數(shù)據(jù)形成寬表滿足查詢需求；在面對用戶數(shù)據(jù)精細去重時，只能對 Druid 組件功能改造。這些局限性不僅使查詢復雜度增加，也會消耗大量的人力、學習、開發(fā)等成本。

4、人群圈選系統(tǒng)

早期該系統(tǒng)借助 HBase 提供標簽計算與存儲、Clickhouse 與 Kylin 作為人群圈選的查詢引擎。

在標簽構(gòu)建過程中，由于 HBase 只能通過主鍵進行查詢，不支持二級索引，無法使用復雜的查詢語句和條件進行數(shù)據(jù)檢索，開發(fā)人員需要通過主鍵來設(shè)計和實現(xiàn)標簽查詢，增加開發(fā)難度和復雜性。同時，HBase 的擴展能力也存在一定局限性，比如無法處理數(shù)字或日期等復雜數(shù)據(jù)類型、無法展開更細粒度的追蹤調(diào)用。

在標簽查詢過程中，當系統(tǒng)面對 200 人的并發(fā)查詢需求，Clickhouse 時常難以承載，需要借助 Kylin 通過 Cube 預(yù)聚合索引來分擔查詢壓力。然而在兩個組件共同提供服務(wù)時，Clickhouse 與 Kylin 配合靈活度不足成為目前系統(tǒng)最大的痛點之一。以查詢 Array 字段為例，Clickhouse 支持 Array 而 Kylin 不支持，涉及到相關(guān)字段查詢時，非常依賴于后端人工判斷數(shù)據(jù)在哪種數(shù)據(jù)庫中，再發(fā)送查詢請求給 Clickhouse。除此之外，兩個組件皆無法支持多表關(guān)聯(lián)查詢，也無法提供靈活的數(shù)值區(qū)間圈選。

應(yīng)用技術(shù)與實施過程

引入 Apache Doris 后，平安人壽以 OLAP 引擎統(tǒng)一為基礎(chǔ)，在 Apache Doris 集群之上構(gòu)建了一體化指標與標簽設(shè)計平臺，形成 “上下經(jīng)營一張表”，完善經(jīng)營指標管理體系，并通過 API 接口直通應(yīng)用層，面向多種場景的統(tǒng)一數(shù)據(jù)服務(wù)。

金猿案例展_中國平安人壽保險股份_OLAP技術(shù)棧-1

1、引擎優(yōu)化：基于 Apache Doris 逐步統(tǒng)一 OLAP 技術(shù)棧

目前，平安人壽已使用 Apache Doris 替換了 HBase、PostgreSQL 、Presto 、Druid 組件，統(tǒng)一指標標簽計算存儲，支持報表分析、即席查詢以及多維分析的應(yīng)用，并已上線了管理層的報表應(yīng)用系統(tǒng)、總部與一線運營人員的可視化分析系統(tǒng)。同時，平安人壽也已完成 Apache Doris 與各類數(shù)據(jù)源適配，進一步替換 Clickhouse、Kylin 組件。預(yù)計在今年 11 月份，Apache Doris 將上線并應(yīng)用于營銷機構(gòu)人群圈選系統(tǒng)的生產(chǎn)使用。

通過 Apache Doris 一套系統(tǒng)同時滿足數(shù)據(jù)存儲、計算與查詢服務(wù)，不僅避免了數(shù)據(jù)多輪計算帶來的重復開發(fā)與冗余存儲問題，更滿足了更靈活、更細粒度、更高效的查詢分析。平安人壽在應(yīng)用上線后取得如下收益：

- 降低各類資源成本：借助 Apache Doris 豐富的數(shù)據(jù)模型，數(shù)據(jù)無需經(jīng)過多輪預(yù)聚合匯總，能夠大幅度簡化數(shù)據(jù)處理流程，降低運維成本的同時釋放了原 14 個 PostgreSQL 數(shù)據(jù)庫的資源成本壓力。

- 提升開發(fā)與查詢效率：統(tǒng)一指標與標簽數(shù)據(jù)開發(fā)在降本的同時更加速了業(yè)務(wù)交付時間，開發(fā)周期由原來的兩周縮短至一天，效率提升 14 倍。在引入 Apache Doris 后，借助 Doris 設(shè)置了查詢層級權(quán)限，使業(yè)務(wù)人員只可訪問數(shù)據(jù) ADS 層中的數(shù)據(jù)，解決數(shù)倉各表交叉使用的問題，提升指標數(shù)據(jù)復用率與使用效率；借助 Doris 優(yōu)異的高并發(fā)性能滿足了報表分析與多維分析場景下的秒級毫秒級的查詢響應(yīng)需求，查詢提速達 5-10 倍。

- 打破數(shù)據(jù)孤島，實現(xiàn)閉環(huán)管理：在統(tǒng)一技術(shù)棧的優(yōu)勢下，Apache Doris 打破了各類應(yīng)用系統(tǒng)數(shù)據(jù)孤島的現(xiàn)象，為業(yè)務(wù)人員提供了更全面的數(shù)據(jù)、更細粒度的維度查詢，實現(xiàn)精細化的查詢分析、一致的業(yè)務(wù)洞察視角、閉環(huán)式的數(shù)據(jù)管理，使企業(yè)上下更精準地掌握壽險經(jīng)營走向。

2、語義與服務(wù)層優(yōu)化：基于 Apache Doris 統(tǒng)一指標和標簽服務(wù)

當統(tǒng)一了 OLAP 技術(shù)棧后，平安人壽進一步引入統(tǒng)一語義層，將復雜查詢語句進行拆解轉(zhuǎn)化，簡化加速 SQL 語句執(zhí)行效率，并借助數(shù)據(jù)服務(wù) API 接入的方式，連接各業(yè)務(wù)應(yīng)用層。

借助這種方式，平安人壽全域數(shù)據(jù)從采集接入后進入 Doris 數(shù)倉，業(yè)務(wù)人員在后臺通過拖拽實現(xiàn)指標標簽數(shù)據(jù)自助定義和自動計算，生成的 SQL 會發(fā)送至 Doris ADS 層中。其中，若涉及復雜的多表關(guān)聯(lián)查詢，SQL 語句會在語義層中過濾，生成簡單的執(zhí)行語句。借助通用的 API 服務(wù)，調(diào)用 Doris 庫中數(shù)據(jù)，統(tǒng)一支持業(yè)務(wù)分析在客戶經(jīng)營、代理人、保單、產(chǎn)品、理賠等方面的需求。目前，平安人壽基于統(tǒng)一服務(wù)化平臺已支持日均數(shù)百萬次的數(shù)據(jù)調(diào)用，每張報表的查詢響應(yīng)時間實現(xiàn) 200 - 300 ms ，實現(xiàn)多場景下極速、統(tǒng)一的數(shù)據(jù)服務(wù)。

至此，平安人壽從數(shù)據(jù)設(shè)計直通數(shù)據(jù)服務(wù)，有效避免業(yè)務(wù)之間冗余開發(fā)與重復使用，縮短業(yè)務(wù)交付周期，加速查詢響應(yīng)時間?；诟邇?nèi)聚低耦合的統(tǒng)一服務(wù)平臺，使查詢分析能夠及時配合業(yè)務(wù)需求變更，確保了企業(yè)內(nèi)外數(shù)據(jù)流轉(zhuǎn)的流暢性。

商業(yè)變化

一站式數(shù)據(jù)門戶是平安人壽大數(shù)據(jù)產(chǎn)品體系自始至終的構(gòu)建目標，基于 Apache Doris 統(tǒng)一 OLAP 多個技術(shù)棧，并將標簽與指標標準化開發(fā)與管理，共同提供統(tǒng)一的數(shù)據(jù)服務(wù)，使業(yè)務(wù)分析師能夠進行自助式的數(shù)據(jù)探查，減少對技術(shù)人員的依賴，同時，通過方便快捷地訪問、分析和可視化各種數(shù)據(jù)資源，實現(xiàn)數(shù)據(jù)高效、低成本的交付。具體體現(xiàn)為：

- 降低各類資源成本：借助 Apache Doris 豐富的數(shù)據(jù)模型，大幅度簡化數(shù)據(jù)處理流程，降低運維成本的同時釋放了數(shù)據(jù)庫的資源成本壓力。

- 提升開發(fā)與查詢效率：開發(fā)周期由原來的兩周縮短至一天，效率提升 14 倍。借助 Doris 優(yōu)異的高并發(fā)性能滿足了報表分析與多維分析場景下的秒級毫秒級的查詢響應(yīng)需求，查詢提速達 5-10 倍。