文章貢獻者 Authors

技術指導: 泰康人壽數據架構資深專家工程師王可
文章作者: 泰康人壽數據研發工程師田昕嶢

摘要 Abstract

本文詳細介紹了泰康人壽基於 Apache Hudi 構建湖倉一體分佈式數據處理平臺的技術選型方法、整體架構設計與實施、以及針對大健康領域的領域特徵和公司戰略對 Apache Hudi 進行的功能擴展與實施的詳細過程、並簡要分享領域實踐心得和部分應用成果。文章總體被分爲五個部分：首先，我們對該平臺與大健康領域和泰康方案相關的建設背景和涉及到的技術概念進行簡要介紹；其次，我們對架構中使用到的核心，即數據湖組件 Apache Hudi，進行橫向技術對比並完成技術選型；再次，我們繪製了整個平臺的宏觀架構圖並列舉了主要層級的實施細節來闡明該平臺的設計與實施過程；之後，我們詳細的闡述了架構中的數據湖平臺層 Apache Hudi 針對大健康領域進行了何種定製化改造與優化；最後，我們挑選了一個大健康領域內的典型應用場景，並將上述工作在該場景中的應用方法和總體實踐成果進行數字化的展示。下面，文章正文將正式拉開帷幕。

公司概況 Company Profile

泰康人壽保險有限責任公司（以下簡稱：泰康人壽）隸屬於泰康保險集團股份有限公司，其前身泰康人壽保險股份有限公司系 1996 年經由中國人民銀行批准成立的全國性、股份制人壽保險公司，由中石化、中國對外貿易運輸（集團）總公司、中國嘉德國際拍賣有限公司等16家國有大中型企業發起組建，公司總部設於北京。

自公司成立以來，在創始人、董事長兼首席執行官陳東昇先生的帶領下，泰康經歷了近 30 年的蓬勃發展，如今已經成爲一家涵蓋保險、資管、醫養三大核心業務的大型保險金融服務集團。截至 2023 年，公司已連續六年榮登《財富》世界 500 強榜單，管理資產總規模超 28000 億元，管理養老金規模超 7200 億元，核心個人有效客戶超 6200 萬人，累計服務企業客戶超 49 萬家，累計理賠金額超 1200 億元。

泰康人壽始終堅持 “尊重生命、關愛生命、禮讚生命” 的企業價值觀，堅持穩健、開拓、創新的經營理念，深耕壽險產業鏈，充分發揮保險補償、資金融通和社會管理功能，實現客戶、員工、股東和社會的共贏發展，致力於成爲新時代大民生工程核心骨幹企業，爲日益增長的中產人羣及其家庭打造長壽健康富足的服務平臺。不忘初心、創新永續、商業向善，“用市場經濟的方式方法，全心全意爲人民服務”。

建設背景 Backgrounds

隨着國家《健康中國行動 (2019-2030年)》[14] 等相關文件的出臺，人民健康和慢性疾病防治的受重視程度再次被推向了一個新的高點，爲保障民生福祉的 “大健康” 概念也被迅速普及並得到社會各界的廣泛關注，由傳統健康領域 (e.g. 醫療服務，藥械器材，etc.) 和範健康領域 (e.g. 健康保險，醫療護理，理療康復，養生保健，etc.) 所共同構成的大健康領域也在近年來得到了蓬勃發展，並吸引了衆多企業涉足探索，泰康人壽便是其中之一。

由於行業特性與歷史原因，加之經歷了近幾年該領域的高速發展，爲了適配瞬息萬變的業務場景，泰康人壽內部的數據基礎組件均以大型物理機搭配大型商用數據庫爲主，輔以商業分析軟件用於進行數據的分析與應用。這種建設方式的優勢非常明顯：即每一個基礎設施和數據庫都能被準確關聯到對應的業務條線，快速響應業務需求，並精確地對投入的 IT 成本進行控制。然而，隨着公司規模的不斷擴大和業務的持續發展，該方法也逐漸暴露出部分弊端：數據以業務條線爲單元零散分佈，最終產生了難以忽視的數據孤島現象，導致公司整體特別是跨團隊的數據使用效率一般，併產生了數據資產被妥善管理的難度較大、數據價值被有效發掘的成本較高等諸多隱患。

爲了保證公司在未來持續深耕大健康領域並落實頂層戰略的道路上不會爲數據問題所困，一套面向未來的、針對大健康領域特徵和公司戰略定製化設計的數據處理平臺就變得尤爲重要。因此，泰康人壽數據團隊毅然決然地決定構建一套湖倉一體化的分佈式數據處理平臺，集數據採集、數據注入、數據治理、數據處理與加工、數據分析等豐富功能於一體，從根源上解決由於數據零散分佈所造成的種種弊端，妥善管理數據資產，有效發掘數據價值，爲公司戰略的落實與業務的發展打好堅實的數據基石。

數據湖技術選型 Technical Selection

由於公司決定採用湖倉一體架構來建設一體化數據處理平臺並進行數據治理，故作爲整個架構地基的數據湖組件的選擇就變得尤爲重要。毫不誇張地說，底層數據湖組件技術選型的合適與否將直接決定整個平臺建設工作的成敗優劣，並在長遠的時間跨度內影響整個數據平臺的總體運行效率和穩定性。因此，在數據湖組件的選擇上必須儘可能全面地進行考慮。

目前行業內主流的數據湖組件共有三者，分別爲 Apache Iceberg [4]，Apache Hudi [5] 以及 Delta Lake [6]。基於上述數據湖組件在架構中的關鍵性與重要性，我們在技術選型時對這三者進行了儘可能全面且細緻的評估和對比。評估的角度可以按重要程度被主要歸納爲以下三點：社區相關情況 (發展態勢)、功能與特性、性能指標，我們接下來將逐一進行闡述。

考量維度 Consider Dimensions

社區相關情況 (發展態勢) Community Momentum

將社區相關情況放在考量的首位，是由於我們深刻地意識到社區的環境將會極大程度的影響項目未來的發展。一個氛圍良好成員活躍的社區往往能夠很大程度上產出一款成功的項目，並在長遠的時間範圍內保證項目的健康發展和平穩迭代。由於我們的湖倉一體架構將會在未來很長一段時間內承擔治理公司龐大數據的重要職責，因此我們絕不能以靜態短視的眼光來進行數據湖的技術選型，而是要儘可能長遠地爲公司的數據保駕護航，因此，我們將與項目能否良好發展息息相關的社區相關情況放在了首要位置進行考量。

我們針對這三個項目的 Github 總收藏數，Watchers 和 Forks 總量，主要貢獻者及 Commits 的增速，PRs (Pull Requests) 和 Issues 增速，以及主要貢獻來源進行了綜合性的量化分析和對比。此外，爲了直觀地感受每個社區對於使用其工具和開發時遭遇問題的解決與處理能力，我們分別加入了這三個社區的官方 Slack 社羣和 maillist，並事先擬定好問題，按照一定頻率每隔一段時間在 Slack 的主頻道提問，並觀測問題回覆和解決的時間。如下是我們的評估結果以及簡要分析：

從三大數據湖的開源社區總體情況我們可以看出，雖然 Deltalake 由於其創建時間較早導致總收藏數較多，但是背靠 Apache 基金會的 Iceberg 和 Hudi 則明顯呈現出了更強的發展勢頭。從柱狀圖中可以分析得出，在數據採集時間段內，Apache Hudi 項目不論訪客數量、Forks 數量、代碼提交請求數量和新功能提出數量都位列第一，呈現出在這三者之中最強的社區活躍程度與發展勢頭，Iceberg 次之，而 Deltalake 雖然總規模較大但發展 (特別是在新功能的提出與開發方面) 總體趨於平穩且略顯緩慢。

在三大數據湖主要貢獻者來源方面，我們可以看出，相比脫胎於開源社區 Apache 孵化項目的 Iceberg 和 Hudi 而言，依託於商業公司 Databricks 的 Deltalake 貢獻者來源明顯較爲單一，且以中國境外的貢獻者爲主。Apache Iceberg 的貢獻者呈現出較爲均衡的態勢；而 Apache Hudi 則在三者之中明顯最受中國開發者歡迎。也許是更符合中國信息技術基礎設施建設的原因，中國的代表性科技巨頭 BAT (i.e. 字節跳動 Bytedance, 阿里巴巴 Alibaba, 騰訊 Tencent) 的貢獻度均位於項目前列，還包括中國移動、華爲、百度、OPPO 等中國行業巨頭的參與，其貢獻程度與以 Uber、 Amazon 和 Apache 爲首的美國公司與組織呈現出分庭抗禮之勢。

而在社區問題反饋和問題解決的積極程度方面，雖然此處我們沒有能夠精準量化評估的方法，但從直觀感受來說，採用 Apache 開源模式 TAW (i.e. The Apache Way [9]) 進行管理的 Iceberg 和 Hudi 的情況要明顯強於 Deltalake，其中國本地化的社區 (e.g. 官方微信羣、釘釘羣、公衆號等) 建設情況也明顯更好，這也直接導致 Hudi 與 Iceberg 在中國的問題反饋與解決的情況要明顯優於 Deltalake。

功能與特性 Features

三個數據湖項目的社區相關情況及未來發展趨勢已經被簡要分析完畢，接下來我們將關注的焦點放在三者的功能和特性上。雖然這三個項目均具有數據湖的基本特性，即之前概念明晰章節中闡述的諸如 “快速注入大量數據”、“多形式多模態數據注入” 以及 “支持事務” 等特性，在具體的特性和功能上它們仍然存在諸多差異。對於湖倉一體架構而言，一個功能儘可能全面，且具備支撐大健康領域數據特性關鍵功能的數據湖組件將會使整個架構的健壯性和整體運行效率得到保證。因此，我們以公司實際的數據應用需求爲基礎，對這三個數據湖組件進行了深入的功能性調研與分析，並將調研結果以橫向功能對比表格的形式進行展現。調研結果如下：

可以發現，在公司業務對於數據湖組件功能需求的重點考量範圍內，Apache Hudi 的功能與特性能夠較爲全面的滿足所需，而 Deltalake 和 Apache Iceberg 都未能完全覆蓋公司對於數據湖組件的功能需求，或者至少在一定程度上存在欠缺。

性能指標 Benchmark Performance

在評估完各個數據湖組件是否具備滿足我們需求的相應功能後，利用數據集評估各個數據湖組件的 Benchmark Performance 就成爲了重點。受到一家商業數據湖公司 Onehouse 的一篇名爲 “Transparent TPC-DS Data Lakehouse Performance Benchmarks” 技術分享的啓發 [7]，由於利用湖倉一體架構治理公司內數據就是我們的根本目的，故相比於使用公開的數據集進行性能評估，利用公司內部已有的真實數據直接進行性能測試對我們來說既便捷又具有實際意義。因此，我們使用了公司內部最具代表性和業務價值的 “保險受理業務數據” 進行基線性能測試。保險受理業務數據不僅具有大健康領域數據的標誌性與代表性特徵，還具備現實性與實用性：由於受理業務的特性，其涉及代理人、保險公司、投保人、被保人等多方主體的各種信息和彼此之間複雜的關係，且與公司的保費收入密切相關，故使用該部分數據製作的數據集可謂進行基線性能測試不二之選。

該數據集原爲存儲於公司保險受理業務條線 IBM DB2 中的多張結構化數據表，經過數據抽取流程並使用 Hive 進行多個步驟的加工和處理，最終形成了共計超過 7400 萬條受理記錄、具有 70 餘列的密集型結構化數據表，所佔 HDFS 存儲空間總量爲 183.6 GB。測試方法主要爲目前數據湖領域通用的讀寫測試，即記錄多次數據集入湖和查詢的平均耗時，來作爲衡量性能的重要基準。寫 (入湖) 測試方面，我們使用了易於進行實踐測量的批處理模式進行測試；而在讀 (查詢) 方面，我們使用了佔據歷史總查詢數量超過 70% 的 “列查 + 點查 + 關聯查詢” 的方式進行測試。最終，我們將二者耗費的總時長求和，並與社區給出的極限測試結果進行綜合分析與評估。受限於公司法律合規的要求，這部分數據即使經過脫敏處理暫時也仍無法公開，但我們很樂意將基線性能測試的結果進行分享。測試結果如下所示：

可以發現，雖然性能差距沒有開源社區給出那麼顯著，但經過我們測試得出的三者性能的大體情況與開源社區給出的相吻合，即: Deltalake 的性能要略優於 Apache Hudi，但基本處於同一水平；而 Apache Iceberg 則相較於前兩者的性能存在較大差距。

選型結果 Selection Result

綜合上述三個選型維度以及公司內部數據的實際情況進行全方位的考量，我們最終選擇了 Apache Hudi 作爲整個湖倉一體架構的數據湖組件，用於在架構底層的分佈式存儲之上提供統一的數據湖層級和相應的 Table format，併爲更上層的數據模型和數據表提供統一的數據湖相關功能與特性 (詳見後續架構設計部分)。具體來說，我們選擇 Apache Hudi 的原因主要可以從上文分析的三個維度被歸納爲以下三點：

活躍的社區，多樣化的貢獻者，以及良好的發展勢頭：不論是從客觀指標還是我們參與社區的直觀感受，Apache Hudi 都是成爲我們架構內數據湖組件的理想之選。首先，雖然收藏總量不如 Deltalake，但在我們的評估期間，由於其具有最多的代碼提交 (Pull Requests) 和分支合併 (Merge Requests) 數量，以及良好的問題提出與解決 (Issues) 情況，故我們認爲其具備良好的發展勢能並在長期內對項目的穩定性做出保障；其次，由於其貢獻者有相當一部分來自於國內的頂尖企業，故我們認爲 Hudi 更符合在中國進行數據湖實施的基本情況；最後，由於其活躍的社區導致反饋的問題能夠及時得到解決，讓我們有信心面對和解決在後續的建設過程中可能遭遇的各種困難。
具備滿足我們需求的關鍵數據湖功能與特性，且對 Flink 具有良好的適配：根據功能性調研，目前 Hudi 是三個數據湖中最符合我們功能需求的數據湖組件。此外，由於團隊內的數據開發者多以使用 SQL 爲主，而 Hudi 對於 Flink 的集成與支持可以保證團隊藉助 Flink 的 Table API 撰寫 SQL-like 語句進行開發，最小化團隊的學習成本，保證開發效率。
性能滿足需求：根據開源社區給出的以及我們親自進行的性能測試結果，Apache Hudi 均表現出滿足我們核心需求的性能。

綜上所述，我們選擇 Apache Hudi 作爲泰康人壽湖倉一體分佈式數據平臺內的核心數據湖組件，並以此爲前提開始進行架構的設計與後續的具體實施工作。

湖倉一體架構的設計與實施 Lakehouse Architecture

架構設計 Architecture Design

在選定了 Apache Hudi 作爲數據湖平臺層的核心組件後，公司湖倉一體數據處理平臺的宏觀架構如下圖所示。我們以從左至右，自底向上的順序對該架構中的各個部分逐一進行簡要說明，並配以架構設計時的各種思考以供參考。

數據源：架構圖最左側的部分表示公司內部現有的各種與業務深度綁定的數據庫或消息中間件，它們主要以大型物理機配合商用數據庫 (i.e. 以 IBM DB2 爲主) 或開源數據庫所構成，用於存儲和處理以業務條線爲單元的相關數據。在構建湖倉一體數據處理平臺的過程中，這些以項目爲單位的商用和開源數據庫成爲了關鍵的數據源，作爲整個架構數據流程的起始點。此外，對於難以通過數據庫連接直接獲取的數據，以及絕大部分非結構化數據，諸如 Kafka 的消息中間件或消息隊列被大量使用，用於高效穩定地進行數據獲取。

數據處理組件：在數據源部分的右側，是本架構的數據處理組件部分。該部分主要由 Apache Flink 作爲主導，輔以較少比例的 Apache Spark 任務。採用 Apache Flink 作爲主要數據處理組件的原因主要有以下三點：其一，是由於其流批一體的設計模式，可以爲流式任務和批處理任務提供統一的處理方式，減少了開發的工作量；其二，Flink 具備豐富的 Connector 接口 (e.g. Kafka, PostgreSQL, Hudi, etc.) 以及可供自定義的 Connector API，使得在沒有相應接口滿足需求情況下，我們得以快速開發所需的 Flink 接口 (e.g. 團隊以 mysql 的 jdbc-connector 爲參考自主研發了 flink-db2 接口) 用於連接所需的數據源；其三，相比於 Spark，Flink 具備 SQL-like 的 Table API，使得我們團隊內部的數據開發者能夠快速從 DB2 等傳統數據庫的開發切換至 FlinkSQL 進行開發，從而快速上手新工具而無需學習 Java 等高級編程語言，很大程度地避免了團隊的牴觸情緒，降低了數據開發的門檻。此外，針對 Flink 批處理任務的調度與流式任務的長期運行，團隊內部自研了一套 Flink 任務管理平臺，用於監控管理持續運行 (e.g. 運行時長爲數週或數月) 的 Flink 流式任務，並每天定時調度 Flink 的批處理任務。

基礎設施層：在架構圖右側的最底部，是公司整個湖倉一體架構的基礎設施層，用於承載整個數據平臺的全部上層建築。基礎設施層主要由兩部分所構成：一者爲基於物理機的 HDFS 集羣，二者爲基於泰康雲的 OSS 對象存儲。前者作爲底層平臺提供分佈式存儲及容災備份的能力，並針對上層隱去了底層存儲的細節；後者依賴公司內部的泰康雲提供的 OSS 對象存儲，爲特定類型的數據 (主要是非結構化數據和稀鬆數據) 提供更爲廉價便捷的持久化功能。此二者共同構成了本架構的基礎設施層，併爲上層提供最基本的數據存儲服務。

數據湖平臺層：在基礎設施層之上，是由 Apache Hudi 構成的數據湖平臺層，或者根據 Hudi 官方的描述，該層也可以被稱爲 “流式數據湖平臺層 (Streaming Datalake Platform)”。根據 Apache Hudi 項目的 Project Leader Mr. Vinoth Chandar 在其設計之初的構想 [3]，與其將 Hudi 看作是 “一種新的表存儲結構 (A table format)” 或是 “在 Hdfs 之上的事務支持層 (a transactional layer upon HDFS)” ，不如說 Hudi 是 “圍繞數據庫內核構建的一個流式數據湖平臺 (a Streaming Data Lake Platform built around a database kernel)” 更爲全面和準確。在本湖倉一體架構中，我們採用了 Hudi 創始人的這種理念，以 Hudi 爲核心，在基礎設施層之上構建了獨立的流式數據湖平臺層。該層的特點亦可以從其命名被很好地理解。根據 Vinoth 的描述，流式數據湖平臺層擁有三大特點：第一是 “流式 (Streaming)”，即 Hudi 從原語層面支持注入 Kafka 之類事件驅動流的增量生產/消費、交互式查詢以及快速 Upsert 等操作；第二是 “數據湖 (Datalake)”，即擁有所有數據湖的特性，比如快速注入 (Fast Ingestion)、事務支持 (Transactional support) 等；第三是 “平臺 (Platform)” ，即 Hudi 可以作爲一個獨立的架構層 (layer) 保證可靠性的同時對外或其他架構層級提供易用的服務。基於 Vinoth 對於 Hudi 的定義以及上述三點特性，我們將 Hudi 作爲一個獨立的數據湖平臺層設計在架構之中，起到連接基礎設施層與數據建模層的作用，並搭配基礎設施層對上層提供 Hudi 的豐富特性 (e.g. 事務支持，準實時查詢，etc.) 作爲支持和底層保障。

Ps: Hudi 項目創始人在其博客[3]中繪製的幽默漫畫，用於說明 Apache Hudi 的本質是包含 “Transaction Layer” 與 “Table Format” 等特性的流式數據湖平臺 (Streaming Datalake Platform)，並感嘆似乎沒人真正理解這一點。

數據建模層：在數據湖平臺層之上，是數據架構師們熟悉的數據建模層。由於採用了湖倉一體架構，因此我們將所有與數據建模相關的流程放置在這一個層級中，並將它們統稱爲數據建模層，以便使架構層次顯得更直觀更簡潔。該層主要用於加工和管理從 Apache Flink 和 Spark 通過 Hudi Connector 獲取並持久化在文件系統上的數據。以 Flink 爲例，數據從數據源經由 Flink 以流式任務或批處的形式加工處理並通過 Hudi Connector 存儲爲對應的數據文件 (e.g. Parquet) 作爲數據準備區，並繼續通過流式或批處理 Flink 任務以 Hudi to Hudi 的方式進行數據建模，最終成爲複覈用戶需求、可供直接使用的數據集市。由於該層次內所有表的底層都由數據湖平臺層提供支持 (i.e. 其 Table format 均爲 Hudi)，故所有表都具備 Hudi 所提供的特性，比如大批量快速注入/查詢、支持事務、Upsert 插入以及準實時的邊插邊查功能，爲更上層的數據訪問和數據服務提供了衆多關鍵特性支持。

數據訪問層：位於數據建模層之上的，是由各種數據查詢和數據訪問組件組成的數據訪問層，其主要起到數據發現、元數據管理、以及訪問控制和權限管理的作用，同時爲數據需求方或使用方提供符合其使用習慣的客戶端或用戶接口。Apache Hive 作爲該架構層中的絕對核心，用於持久化數據建模層創建的衆多數據庫和數據表的元數據信息，對用戶提供數據的宏觀概覽，幫助用戶進行數據的發現和數據的理解。同時，搭配 Kerberos 以及 Hive 的權限控制機制 (或者 Apache Ranger 等其他工具)，數據訪問層還能對用戶進行身份認證和權限控制，對用戶的數據訪問和數據使用進行精細化管理。此外，本架構層還包括其他熱門的數據查詢組件 (e.g. Trino, Clickhouse, etc.)，以及爲數據應用開發者提供的用於獲取數據的 REST APIs，在進行訪問控制和滿足法律合規要求的同時，爲數據使用方提供多樣化的數據訪問服務以滿足其需求。

數據應用層：數據應用層位於整個湖倉一體架構的最頂層，用於對整個架構治理的全部數據進行綜合性的應用。如圖所示，該架構層可以提供豐富且多樣化的數據服務或數據應用，以適配大健康領域高速的發展並滿足複雜的業務需求，比如用戶數據分析、即席查詢、數據可視化、銷售戰報等等。正如繁碩的果實離不開牢固的樹幹和樹根，頂層琳琅滿目的數據應用也離不開湖倉一體架構底層各層級的堅實支撐。

至此，泰康人壽湖倉一體數據處理平臺的架構和設計時的思考已經大致介紹完畢。下面將簡要闡述架構的具體實施部分，並分享一些實施過程中遭遇的困難以供讀者參考。

架構實施 Architecture Implementations

任何項目從頂層設計到具體實施落地都不是一帆風順、一蹴而就的，泰康人壽湖倉一體數據處理平臺的建設實施也同樣不例外。歷時數月，從最底層的物理機實體與操作系統的管理、HDFS 與 Yarn 集羣搭建，再到實時計算引擎 Flink 的版本選型、流批一體任務管理、與 Hudi 和 Hive 的適配與集成，再到其上的數據倉庫內的模型構建與元數據管理，直至最後在頂層的數據訪問與應用，架構實施期間涉及的實施細節實在太過龐雜，此處便不再逐一贅述。相應地，我們將架構實施在落地過程中各組件的版本選型在此處進行整理，以幫助讀者規避在建設過程中可能產生的版本衝突等問題；同時，我們還挑選了架構實施過程中遭遇的比較有代表性、有價值的問題或解決方案在此處分享，以供讀者參考。

版本選型 Version Selection

架構內組件版本的具體選型一直是架構建設與集成工作中的重要環節，也是決定整體架構能否穩定運行的關鍵。此處，在進行了大量調研和試錯後，我們將目前架構內部組件的具體版本整理於此，以供讀者進行參考。

架構的具體建設與實施的過程總是充斥着繁雜的細節，而如果將其全部逐一贅述將會導致整篇文章變得龐雜而混亂。由於本文介紹的重點爲基於 Apache Hudi 建設湖倉一體分佈式數據平臺，故在此處我們主要分享三點在使用 Apache Hudi 建設數據湖平臺層時實際遭遇的問題，以及經過實踐所得到的行之有效的解決方案。

數據湖平臺層中 Hudi 表的元數據管理的相關問題與解決方法: 元數據的管理是任何數據架構中都無法忽視的關鍵問題，數據湖的元數據管理同樣不例外。由於 Apache Hudi 擁有自己的元數據結構並傾向於將之存儲在 HDFS 的對應目錄中，故若不對元數據進行精心管理則會顯著增加數據使用的各項成本 (e.g. 溝通成本、運維成本、etc.)。爲了解決此問題，我們在數據湖中的 Hudi 建表時，將其元數據同步至集羣內 Hive Metastore 的相應數據庫中，並以集羣爲單位對元數據進行治理。而在數據訪問時，我們使用 Trino 將多個 Hive 以 Trino Catalog 的形式進行再一次彙總，以確保用戶能夠統一地訪問位於多個集羣的基於數據湖存儲的數據表。相關詳細資料請綜合性地閱讀官方文檔: Apache Hudi - Syncing to Hive Metastore [10] 以及 Trino - Hive connector [11]。
數據湖組件 Hudi 快速注入導致 HDFS 上零散小文件過多的問題與解決方法: 多種格式數據的快速注入是數據湖的主要特性之一，也是使用數據湖的首要功能需求。然而，如果不進行妥善管理，則快速注入的數據將會在底層數據存儲中分散成衆多零散的小文件，極大影響底層存儲的性能，並對架構整體的穩定性產生嚴重威脅。根據我們的測試，使用 Copy-On-Write 方式雖然可以滿足數據初始化及快速注入的時間需求，但每千萬條數據會導致底層 HDFS 上出現幾萬個獨立存在的數據文件，進而嚴重影響集羣的健康情況。針對這種情況，數據湖相關的開源社區也一直在進行各種努力，包括開發異步文件聚類、異步文件清理，以及優化 Merge-On-Read 表的性能等。此處，我們使用了通過 Spark 在數據快速注入後進行 HDFS 文件聚合及清理的方式，將快速注入後產生的數十萬個小文件聚合成不足百個，大幅降低了底層存儲中的文件數量，顯著提升了數據湖的穩定性。相關詳細資料請參考筆者博文: Apache Hudi 使用文件聚類功能 (Clustering) 解決小文件過多的問題 [12]。
基於 Kerberos 進行數據湖平臺層中數據表的安全性保障: 適配 Kerberos 的 Hudi 源代碼修改與優化: 信息安全始終都是在架構建設時被各方關注的焦點，故數據湖的建設也必須同樣考慮到安全機制。雖然許多人認爲安全機制會阻礙架構建設或任務開發的效率，但是集羣長期穩定的運行卻同樣離不開安全機制。作爲一個較爲新穎的組件，Hudi 目前版本對於安全機制的支持始終顯地不那麼完善，特別是在其與開啓了 Kerberos 認證的 HDFS 或 Hive Metastore 這些經過多年沉澱的老牌組件進行交互時，安全性支持的不完備就顯得尤爲明顯。爲了確保 Hudi 能夠與架構中其他開啓 Kerberos 認證的組件無縫交互，我們針對 Hudi 的底層源代碼進行了修改和優化，並使其完美地嵌入到 Kerberos 的安全體制之中。相關詳細資料請參考筆者博文: 通過源代碼修改使 Apache Hudi 支持 Kerberos 訪問 Hive 的功能 [13]。

基於 Apache Hudi 的數據湖功能擴展 Customizable Improvements

在對於泰康人壽的湖倉一體架構有了基本的瞭解後，接下來我們將詳細闡述針對泰康方案對於底層數據湖組件 Apache Hudi 進行的定製化改造與功能研發，並挑選了一個實際的落地場景用於體現和說明自主研發功能的寶貴价值。

大健康領域與泰康方案 Big Health & The Taikang Solution

如前文所述，隨着國家《健康中國行動 (2019-2030年)》[14] 等相關文件的出臺，人民健康和慢性非傳染性疾病防治的受重視程度再次被推向了一個新的高點，爲保障民生福祉的 “大健康” 概念也順勢產生並迅速得到社會各界的廣泛關注。根據中商產業研究院 [15] 和中國社會科學院學者 [16] 的定義與解讀，大健康是建立在傳統健康認知之上的一個擴展性的概念，即以保障 “身體、精神和社會處於完好狀態” 爲根本目的的同時，將實現目的的途徑由 “治病爲中心” 轉變爲 “爲以人民健康爲中心”，由 “治已病” 轉變爲 “治未病”；而大健康領域，指的是由傳統健康產業 (e.g. 醫療服務產業，製藥產業，醫療器械產業，etc.) 與範健康產業 (e.g. 健康類保險，醫療護理，理療康復，養生保健，etc.) 共同構成的大健康產業所涉及的諸多領域，包括醫療服務、康養服務、健康保障 (i.e. 保險服務，救援服務，etc.)、養老服務等幾大板塊。

針對大健康領域的特徵，泰康人壽採用保險與養老、保險與醫療、保險與養老金和資產管理相融合的方式，專注打造 “長壽，健康、富足” 三大閉環，以保險作爲核心支點和客戶支付的主要途徑迅速進軍並深耕大健康領域的多個重要板塊，爲增進人民福祉做出切實的貢獻。以主力產品 “幸福有約” 爲例，根據泰康人壽創始人陳東昇先生在《幸福有約第一課》[17] 中的講述，泰康人壽首創以 “養老社區入住確認函” 爲紐帶，將虛擬的保險與實體的養老融會貫通，既規避了養老社區精算困難的癥結，又保證了客戶支付渠道的便捷，即客戶可以通過購買保險的方式獲得未來入住養老社區的資格，進而滿足養老的需求。藉助這種 “以保險爲支點搭配其他產業” 的創新思維與商業模式，泰康在大健康領域獲得了廣泛的商業成功並保持着良好的發展態勢，持續不斷地以市場經濟的方式全心全意爲人民服務。

基於公司戰略對數據湖功能進行的改良 Improvements Based on Strategies

泰康人壽針對大健康領域實際情況所制定的上述戰略和商業模式，爲科技的創新與應用提供了肥沃的土壤，我們湖倉一體架構中的數據湖組件 Apache Hudi 便是其中的受益者。作爲銜接上層數據模型與底層數據存儲的關鍵層級，如果數據湖平臺層的核心組件 Apache Hudi 能夠從源代碼級別就針對泰康方案 “三大閉環” 的戰略進行定製化的功能擴展與性能優化，那麼整個湖倉一體架構在公司的落地與使用將會更加如虎添翼，做到真正高效地治理公司的數據資產，爲公司未來的發展做好數據層面的保駕護航。

下面，我們將會結合泰康人壽在大健康領域的戰略與商業模式，簡要說明我們針對數據湖 Apache Hudi 所作出的功能改進及取得的正向效果。

“三大閉環” 與流式計算引擎中基於主鍵的多字段分片插入更新功能 Improvement No.1

如前文所述，泰康人壽堅定地打造由 “長壽，健康，財富” 所構成的三大閉環，以保險作爲核心支點和主要支付手段，整合 “保險+養老”、“保險+醫療”、“保險+養老金和資產管理” 等大健康領域內多個板塊的資源並向市場提供服務，並最終形成了在中國人均壽命再創新高的長壽時代獨樹一幟的泰康方案。

基於 “三大閉環” 的核心戰略，我們不難看出，其本質是 “以保險爲主體和核心，對於多個產業和領域的資源進行整合”，而從數據的角度來進行翻譯，就變成 “以保單信息爲核心數據，對其他各個產業的數據進行關聯整合” ，即：在數據層面，通過一個特定記錄的主鍵 (e.g. 保單記錄的保單號) 對於其他的相關聯的記錄 (e.g. 養老社區的相關信息，牙科診療的相關信息，etc.) 進行整合。因此，倘若作爲泰康人壽湖倉一體架構基石的流式數據湖平臺層能夠對這項功能進行源代碼層面的原生支持，則在未來將會節省大量在數據模型層的修改和開發的繁瑣工作，且會對公司戰略的實現以及未來長期的發展大有裨益。由此，基於對於公司戰略的理解以及在數據領域的專業知識和經驗，我們基於 Apache Hudi 實現了流式數據湖平臺層的 “基於主鍵的多字段分片插入更新功能”。

上述功能的具體含義爲，在實時計算的場景下，具有相同主鍵的多條記錄可以在結果表中自動尋找到屬於自己的字段範圍，並進行定向更新。該功能在注重準確性的批處理場景下已經存在多年，但在注重時效性的實時計算與數據湖領域卻仍未被實現。如果讀者仍覺得該描述較爲抽象，我們不妨來看下面這個例子：一張數據的整合表具有共計 31 列字段，其中第一個字段列 C0 爲保單號，從 C1-C10 爲保單相關數據列，C11-C20 爲養老信息相關數據列，C21-C30 爲牙醫數據診療字段列。在未使用自主研發的功能前，每次實時計算引擎的增量插入 (UPSERT) 操作都會僅保留與自己相關的信息而將其他列抹除 (比如，C11-C20 養老社區信息的更新會將已經存在的 C1-C10 保單信息置空抹除，因爲數據湖會默認 C1-C10 的空值即爲最新數據，需要將原有已經存在的 C1-C10 的保單信息覆蓋掉纔是正確的)，因此數據湖便難以起到直接將多個表的數據整合至一張寬表的功能；而在使用了自主研發的功能後，數據湖可以直接將多段信息整合成一行完整的記錄 (同時涵蓋保單信息、養老信息、以及牙醫診斷信息，各部分的空值不會將已有值覆蓋掉)，甚至無需藉助實時計算引擎 (e.g. Flink) 的狀態即可完成該操作，這爲計算資源的節約與開發流程的縮減都能起到極大的幫助作用。

“泰康方案” 與流式計算引擎中基於多個事件時間字段的數據準確性保障機制 Improment No.2

根據上文描述，“泰康方案” 的本質，就是將虛擬的保險支付與實體的醫養服務創新結合，通過長期穩定的投資實現複利現象，積累充足的財富資源，在人們老年的時候享受長壽、健康、富足的生活方式。因此，我們可以清晰的發現，與 “泰康方案” 和大健康領域特徵相關的數據，一定都對準確性有着嚴苛的要求。由於這些數據往往都涉及高度敏感 (保單金額，用戶繳費，用戶信息，etc.) 的信息，故數據處理過程中的丟數漏數或不準確是絕對不會被容忍的。由此，我們可以發現，一種基於數據湖的數據準確性保障機制必須被設計實施，才能保證湖倉一體架構在大健康領域被廣泛應用。

基於上述原因，我們基於數據湖 Apache Hudi 和實時計算引擎自主研發了名爲 “基於多個事件時間字段的數據準確性驗證” 的一種數據準確性保障機制 (目前，Apache Hudi 一張表僅支持一個 eventime 驗證字段)。該機制可以自動判定入湖的數據是否具備最新的事件時間，並對延遲數據或不正確數據進行自動篩查和處理。舉例而言，客戶產生的兩條信息 I1 和 I2 由於網絡延遲等原因沒有按照正確數據進入數據湖，倘若本應被存儲的最新狀態 I2 先於舊狀態 I1 經過流式計算引擎入湖，則數據湖就會選擇舊狀態 I1 進行存儲而丟棄 I2，最終導致數據產生偏差；在利用了我們自主研發的數據保障機制後，不論 I1 和 I2 以何種順序入湖，該機制都會按照順序對數據進行處理，並保證最新狀態 I2 被作爲最新狀態持久化。此外，該機制配合上述 “基於主鍵的多字段分片插入功能” 共同使用，可以實現結果表中各部分字段 (保單信息、養老信息、醫療信息) 的數據在保證準確性的基礎上分段更新、互不干擾，從而爲後續更多業態的數據整合提供堅實的底層技術保障。

落地場景與應用成果 Application Secnarios & Achievements

落地場景簡介 Application Secnarios

任何自主研發的功能都必須經過真實業務場景的實踐檢驗才能證明其實用性並體現其真正價值，我們基於數據湖 Apache Hudi 所研發的上述功能也同樣不例外。由此，在新功能的應用與實踐階段，我們綜合考慮了許多業務，最終再一次選擇了前文提到過的 “保單實時受理業績” 的應用場景。此場景可謂與新功能高度契合：首先，作爲泰康 “三大閉環” 戰略的核心，保單實時受理數據由於其對於數據的時效性與準確性均有嚴格要求，因此是我們用於驗證基於流式數據湖平臺層所研發的新功能的理想試驗田；其次，“保單實時受理業績” 需要使用 “公司+保單號” 作爲核心主鍵，用於整合包括保單信息、代理人信息在內的多部分信息至一張結果表，其內在數據邏輯具備豐富的信息整合場景，因此可以爲驗證 “基於主鍵的多字段分片插入功能” 提供豐富的實驗和測試場景；最後，在 “保單實時受理業績” 的應用場景中存在着保單的多狀態轉換，即遵循從“受理”到“代轉”直至“預收”的保單狀態轉化流程，故非常適用於驗證爲了 “泰康方案” 而專門設計研發的 “基於多個事件時間字段的數據準確性保障機制” 相關功能。綜合上面三點考量，我們選擇了該業務場景用於檢驗基於 Apache Hudi 自主研發的上述兩個功能。

數據湖自主研發功能的應用成果 Achievements of Customizable Improvements

令我們感到欣慰的是，基於數據湖研發的新功能在 “保單實時受理業績” 業務場景中的發揮超出預期，在保障數據準確性的基礎上真正發揮出了數據湖的獨特價值。其獨特價值主要可以被分爲兩個方面：第一，“基於主鍵的多字段分片插入功能” 由於其擺脫了流式計算引擎對於狀態的依賴，而真正做到了流數據與批數據的統一處理，極大發揮了湖倉一體架構帶來的 “流批一體” 數據處理方式的價值，並大幅縮減了數據處理流程，提升了數據研發者的開發效率；第二，“基於多個事件時間字段的數據準確性保障機制” 保障了數據的傳遞即使出現延遲，保單狀態的變化 (受理、待轉、預收) 也能通過保障機制被自動排序處理，並在最終的結果表中始終保持着最新的、準確的狀態。除此之外，數據湖的快速注入、事務支持等特性也被廣泛使用併爲架構上層提供可靠支持。

截至目前，使用經過我們改造的數據湖所研發的 “保單實時受理業績” 數據流程已經在泰康人壽湖倉一體分佈式數據平臺上穩定運行了超過一年的時間，其日均處理的數據量非常可觀：拋開中間過程不論，僅在最終結果表中，平均每日處理的保單更新總記錄數就超過 50 萬條，涉及的保單記錄操作總量更是超過日均 600 萬次；如果算上各種中間過程，日均鏈路總操作記錄條數更是達到數千萬次。更令人振奮的是，經過與批處理系統的數據比對，我們發現數據完全一致：採用實時計算引擎的數據湖，竟然沒有任何一條數據丟失或者產生偏差；換言之，數據在實時計算的場景下準確率居然達到了 100%。由此，我們相信，經過我們改良的數據湖組件與整個湖倉一體數據處理平臺將會在日後泰康人壽和大健康領域內豐富的應用場景中發揮更多難以估量的價值，爲公司的戰略與發展保駕護航。

架構總體應用成果 Achievements of Architecture Application

此外，在架構總體應用的層面，自泰康人壽湖倉一體分佈式數據處理平臺投入生產以來，其治理的數據規模以及涵蓋的業務種類經歷了持續性的高速增長。截至目前，本數據平臺管理的實時計算作業總數量已達近 100 個，調度與 ETL 任務總數量超過 1200 個，存儲的數據總量將近 300 TB，並持續保持快速增長的態勢；其治理數據所涉及的業務種類也體現出豐富的多樣性，包括：用戶行爲分析、合規監管、超體 OLAP 分析、方案激勵、實時指標、數據可視化等等。隨着公司戰略的進一步落實以及在大健康領域持續深入的探索，本數據平臺將會承擔更多的數據職能以及更重要的責任，爲公司戰略的落實以及業務的發展貢獻屬於自己的價值。

後續工作 Further Works

根據泰康方案的逐步落實與推進，以及大健康領域的實際情況，泰康人壽湖倉一體分佈式數據處理平臺的後續建設及發展重心主要會將被聚焦在如下三個方面：

在保障易用性的前提下持續集成更多組件以滿足大健康領域豐富的業務需求: 由於近年來大健康領域的迅猛發展，業務方對於數據的需求也變得前所未有地多樣化。使用湖倉一體架構集中對數據進行集中治理只是一個開端，數據價值的真正體現往往離不開實際的應用。因此，在後續對更加豐富的數據應用的支持 (包括對機器學習、深度學習模型的適配、對推薦算法或更復雜決策系統的支持等) 將會成爲湖倉一體架構發展的首要目標。
進一步完善平臺的監控機制、容錯機制以及災害恢復機制，以持續提升平臺的健壯性和可靠性: 作爲整個公司新的數據類基礎設施，湖倉一體數據處理平臺將會在未來治理種類更加豐富、數量更加龐大的業務數據。因此，作爲基礎設施的健壯性與可靠性就變得尤爲重要。如何在持續集成衆多組件的同時始終保持數據平臺的高可用性將會成爲後續工作關注的重點。
根據大健康領域的業務特點持續對數據湖組件 Apache Hudi 進行持續優化: 與所有的業務相同，大健康領域的相關業務也具備區別於其他領域的獨特性，這在保險與醫養和資管相融合的業務場景中體現的尤爲明顯。如何藉助數據湖組件 Apache Hudi 中提供的衆多可自定義特性 (e.g. Customized Filters, Customized Payloads, etc.) 來最大程度地適配大健康領域的業務特徵，並優化其作爲底層數據基礎設施的性能，也是在後續工作必不可少的環節。

小結 Summary

本文詳細介紹了泰康人壽湖倉一體分佈式數據處理平臺的建設過程，以及在大健康領域內針對 “泰康方案” 和 “三大閉環” 等公司核心戰略進行的定製化設計、改進與實施的詳細落地過程，並簡要分享領域實踐心得和部分應用成果。隨着公司戰略的進一步落實以及在大健康領域持續深入的探索，我們相信，本數據平臺和其中的核心組件 Apache Hudi 將會承擔更多的數據職能以及更重要的責任，爲公司戰略的落實以及業務的發展貢獻屬於自己的獨特價值。

作者簡介 About the Authors

技術指導: 王可

泰康人壽數據架構資深專家工程師

深耕金融領域數據架構多年，具備豐富的架構設計和實戰落地經驗，對大數據相關技術在金融領域的應用擁有獨到的見解。

文章作者: 田昕嶢

泰康人壽數據研發工程師

澳大利亞悉尼大學工程學碩士、管理學碩士。在求學及職業生涯期間，深耕大數據基礎架構與開源項目等領域，並積極探索數據領域內先進方法論和技術與金融與大健康領域高效有機結合的方式方法。工作期間曾多次參與設計和實施企業內部大數據集羣和數據平臺的建設工作，精細化構建團隊知識庫，並週期性地將團隊取得的優秀成果向行業及社區進行展現。

歡迎交流，聯繫方式: 知乎主頁: Xinyao Tian - 用戶主頁 | CSDN: Xinyao Tian - 會員中心 | LinkedIn: Xinyao Tian's Profile

參考文獻 References

[1] Microsoft - What is a Data Lake? [https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-a-data-lake/]
[2] IBM - What is a data warehouse [https://www.ibm.com/topics/data-warehouse]
[3] Vinoth Chandar - Apache Hudi - The Data Lake Platform [https://hudi.apache.org/blog/2021/07/21/streaming-data-lake-platform/]
[4] Apache Iceberg - Official Website [https://iceberg.apache.org/]
[5] Apache Hudi - Official Website [https://hudi.apache.org/]
[6] Delta Lake - Official Website [https://delta.io/]
[7] Onehouse - Apache Hudi vs Delta Lake - Transparent TPC-DS Data Lakehouse Performance Benchmarks [https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-transparent-tpc-ds-lakehouse-performance-benchmarks]
[8] IBM - What is a data lakehouse? [https://www.ibm.com/topics/data-lakehouse]
[9] Apache - Briefing: The Apache Way [https://www.apache.org/theapacheway/]
[10] Apache Hudi - Syncing to Hive Metastore [https://hudi.apache.org/docs/syncing_metastore/]
[11] Trino - Hive connector [https://ta.thinkingdata.cn/trino-docs/connector/hive.html]
[12] Xinyao Tian - Apache Hudi 使用文件聚類功能 (Clustering) 解決小文件過多的問題[https://blog.csdn.net/weixin_38070561/article/details/126548227]
[13] Xinyao Tian - 通過源代碼修改使 Apache Hudi 支持 Kerberos 訪問 Hive 的功能[https://blog.csdn.net/weixin_38070561/article/details/131981538]
[14] 中華人民共和國中央人民政府 - 《健康中國行動 (2019—2030年)》[https://www.gov.cn/xinwen/2019-07/15/content_5409694.htm]
[15] 中商產業研究院 - 2021年“十四五”中國大健康產業市場前景及投資研究報告 [https://www.askci.com/news/chanye/20210702/1733311504828.shtml]
[16] 唐均 - 大健康與大健康產業的概念、現狀和前瞻：基於健康社會學的理論分析 [https://caoss.org.cn/UploadFile/pic/2020101310303786123.pdf]
[17] 陳東昇 - 幸福有約第一課 [https://www.sohu.com/a/593416882_121124541]

萬字長文 | 泰康人壽基於 Apache Hudi 構建湖倉一體平臺的應用實踐

文章貢獻者 Authors

摘要 Abstract

公司概況 Company Profile

建設背景 Backgrounds

相關技術概念 Concepts