招商信諾人壽基於 Apache Doris 統一 OLAP 技術棧實踐
本文導讀:
當前,大資料、人工智慧、雲端計算等技術應用正在推動保險科技發展,加速保險行業數字化程式。在這一背景下,招商信諾不斷探索如何將多後設資料融合擴充,以賦能代理人掌握更加詳實的使用者線索,並將智慧分析貫穿業務全鏈路,實現對使用者、產品、場景策略的全面洞察與閉環迭代。本文將詳細介紹招商信諾在大資料基礎建設方面的探索之旅,從最初為線報表、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 不斷髮展壯大,為基礎軟體建設添磚加瓦!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70017904/viewspace-2984410/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 平安人壽基於 Apache Doris 統一 OLAP 技術棧實踐Apache
- Apache Doris在京東搜尋實時OLAP中的應用實踐Apache
- 招商信諾人壽榮獲“年度社會責任貢獻企業”獎
- 大資料技術 - Apache Doris大資料Apache
- 日增百億資料,查詢結果秒出, Apache Doris 在 360商業化的統一 OLAP 應用實踐Apache
- 應用實踐 | 10 億資料秒級關聯,貨拉拉基於 Apache Doris 的 OLAP 體系演進(附 PPT 下載)Apache
- 基於Apache Doris的湖倉分析Apache
- 小米 A/B 實驗場景基於 Apache Doris 的查詢提速最佳化實踐Apache
- 基於Ansible實現Apache Doris快速部署運維指南Apache運維
- 應用實踐 | 蜀海供應鏈基於 Apache Doris 的資料中臺建設Apache
- Apache Doris 輕鬆入門和快速實踐Apache
- 最佳實踐|Apache Pulsar 在拉卡拉的技術實踐Apache
- 查詢平均提速 700%,奇安信基於 Apache Doris 升級日誌安全分析系統Apache
- EasyMR 基於國產化信創的適配實踐技術詳解
- 長安汽車基於 Apache Doris 的車聯網資料分析平臺建設實踐Apache
- 賦能直播行業精細化運營,鬥魚基於 Apache Doris 的應用實踐行業Apache
- eBay 基於 Apache Kyuubi 構建統一 Serverless Spark 閘道器的實踐ApacheServerSpark
- 實時分析全面賦能金融業務,馬上消費基於 Apache Doris 構建實時數倉的實踐Apache
- 位元組跳動基於Doris的湖倉分析探索實踐
- Android技術棧(四)Android Jetpack MVVM 完全實踐AndroidJetpackMVVM
- 微店的Flutter混合棧管理技術實踐Flutter
- OnZoom 基於Apache Hudi的流批一體架構實踐OOMApache架構
- 亞信科技基於 Apache SeaTunnel 的二次開發應用實踐Apache
- 弘康人壽基於 RocketMQ 構建微服務邊界匯流排的實踐MQ微服務
- 聯想基於Apache DolphinScheduler構建統一排程中心的應用實踐Apache
- 微信後團隊分享:微信後臺基於Ray的分散式AI計算技術實踐分散式AI
- 個人技術棧總結
- 複雜查詢響應速度提升10+倍,度言軟體基於 Apache Doris 實時數倉建設實踐Apache
- 基於kubernetes自研容器管理平臺的技術實踐
- 基於 Flink CDC 的現代資料棧實踐
- Robinhood基於Apache Hudi的下一代資料湖實踐Apache
- 觸寶科技基於Apache Hudi的流批一體架構實踐Apache架構
- 基於實踐:一套百萬訊息量小規模IM系統技術要點總結
- 快手基於 Apache Flink 的實時數倉建設實踐Apache
- Apache Doris 在同程數科數倉建設中的實踐Apache
- OLAP:實現高效BI分析的必備技術
- 基於小程式技術棧的跨端框架有哪些?跨端框架
- 基於 Coolbpf 的應用可觀測實踐 | 龍蜥技術