導讀：當前，大數據、人工智能、云計算等技術應用正在推動保險科技發展，加速保險行業數字化進程。在這一背景下，招商信諾不斷探索如何將多元數據融合擴充，以賦能代理人掌握更加詳實的用戶線索，并將智能分析貫穿業務全鏈路，實現對用戶、產品、場景策略的全面洞察與閉環迭代。本文將詳細介紹招商信諾在大數據基礎建設方面的探索之旅，從最初為線報表、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 不斷發展壯大，為基礎軟件建設添磚加瓦！
