平安人壽基於 Apache Doris 統一 OLAP 技術棧實踐

SelectDB發表於2023-11-10

導讀:平安人壽作為保險行業領軍企業,堅持技術創新,以資料業務雙輪驅動的理念和更加開放的思路來應對不斷增長的資料分析和應用需求;以深挖資料價值、保障業務用數效率為目標持續升級大資料產品體系。自 2022 年起平安人壽開始引入開源實時資料倉儲 Apache Doris 並基於此統一 OLAP 技術棧,透過統一的資料開發與服務打破了原有系統的資料“孤島”、降低了需求的開發成本、加速了業務需求的交付週期,並滿足了業務方更高資料時效性與查詢響應度的要求,最終形成更開放、靈活、可擴充套件的企業級管理與分析大資料產品體系,實現資料價值的最大化釋放,助力企業由“粗放型”業務增長轉變為“精細化”效益提升。|作者:平安人壽大資料架構師 杜天敏、孫順

保險業務的持續擴充,離不開企業的數字化戰略創新。平安人壽秉承“一站式服務”的理念,以資料驅動服務質量,並早在 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 的社群建設,將相關成果貢獻回饋社群,實現價值共享!


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70017904/viewspace-2994755/,如需轉載,請註明出處,否則將追究法律責任。

相關文章