淺談G行資料湖平臺建設

隨著移動網際網路的飛速發展，對於短時間內產生的大規模、多種類資料的儲存和分析要求越來越高。資料湖是一種支援結構化、半結構化、非結構化等大規模資料儲存和計算的系統架構，能夠高效地對原始資料進行儲存和取用，解決了傳統資料倉儲需要預先定義資料結構、海量資料載入慢的問題。目前，G行基於“湖倉一體”的建設思路實現了對行內海量資料的高效儲存和處理，本文主要介紹了G行資料湖平臺的建設實踐。

G行資料湖平臺建設實踐

近年來，G行大資料平臺專案建設取得了一定的成果。在大資料應用開發平臺的建設基礎上，資料湖平臺採用了採集層、平臺層、應用層的三層架構建設方案，如圖1所示。

圖1 資料湖平臺系統架構

採集層實現了對G行原始資料的統一採集管理。目前原始資料主要以資料檔案的形式推送入湖，在對檔案格式、檔案大小、資料內容等進行基本校驗後，將資料儲存到HDFS或Hive中。對於具備網路條件的源系統，透過HDFS直連方式進行資料推送，對資料進行校驗、壓縮等處理後完成入湖。對於部分準實時資料則透過Kafka實現採集傳輸，並由Flink消費後儲存入湖。為了更好地實現資料計算共享，下游數倉及應用加工處理後的資料也會迴流到資料湖進行統一匯聚和共享。

平臺層主要完成對入湖資料的儲存管理、授權管理、後設資料管理、任務管理等功能。根據應用對資料的需求，資料湖共設計了四種入湖模型，包括當日全量資料儲存、當日增量資料儲存、上日全量資料與當日更新增量資料合併儲存、拉鍊表儲存。平臺的授權管理基於Ranger實現，讓不同系統可透過資料湖進行資料共享。目前，平臺已經實現了G行將近200個系統1萬多張表的原始資料採集，併為約100個下游應用提供資料授權和呼叫。後設資料管理模組可以輕鬆實現對資料入湖、資料儲存方式以及資料下線的管理。任務管理模組實現了對資料入湖載入任務的狀態查詢、延遲查詢、任務重調、時長統計等功能。

圖2 資料湖平臺任務管理大屏

應用層主要基於G行的資料運營、營銷擴充、個性化推薦等業務場景，利用Oozie、Spark等元件實現對資料批次任務的排程和加工計算。同時，結合高斯數倉強大的MPP計算能力，對資料進行進一步的加工和處理，業務人員可以藉助Presto、openLooKeng等查詢分析引擎實現資料的實時查詢或多源分析。

實時資料湖建設

目前，G行資料湖中主要是T-1日的離線資料。隨著數字化轉型的不斷深入和業務場景的不斷豐富，對於資料分析的時效性要求越來越高。因此，G行建設了資料湖平臺實時資料湖子系統，完成了實時資料的統一接入、統一管理和統一服務，同時實現了對T-1離線資料的比對修正，保證了資料一致性。實時資料湖子系統設計架構如圖3所示。

圖3 實時資料湖子系統架構

根據G行資料平臺建設的現狀和需求，實時資料湖選擇了基於Hudi的技術方案。作為目前資料湖的熱門實現技術，Hudi可以高效處理大規模資料集，支援HDFS、S3等多種資料儲存方式，支援Spark、Flink計算引擎實時消費Kafka、Pulsar等訊息佇列的資料後入湖，支援Hive、Presto、Impala等引擎進行資料查詢分析，並且透過索引構建，提升了計算引擎的查詢效能。

為了便於實現對實時資料湖的管理，G行從作業管理、後設資料管理、任務監控方面進行了實時資料湖平臺的建設。

作業管理：支援批次初始化、實時資料入湖的配置化開發以及資料比對作業提交，最低開發成本保證實時資料入湖與查詢。

後設資料管理：為了實現與批式資料湖後設資料的統一，採用了基於Hive Metastore的後設資料儲存，透過Thrift介面協議，Flink在實時消費資料的同時將後設資料寫入到Hive Metastore中，實現後設資料的統一管理。

任務監控：為加強平臺運維管理，提供了資料湖流式作業以及服務執行狀態和效能的監控，並且接入了G行分散式監控系統提供實時故障告警，方便運維人員及時掌握生產執行情況。

總結與展望

目前，G行資料湖專案的建設取得了一定的成果，基本實現了全行資料的統一儲存和管理，支援了越來越多的基於資料共享和多維分析的業務場景，也助力數倉實現了資料的進一步加工和提取，使得業務應用的集市化建設更加便捷。但是，在實際生產中也存在一些亟需關注和解決的問題。

一、目前實時資料湖只是作為離線資料湖的補充和完善，批流資料入湖仍是分別基於Hive和Hudi兩套資料格式的實現方案。Hive資料更新只能透過全量資料覆寫的方式實現，佔用資源較高且比較耗時。而Hudi提供多種內建索引機制和高效的資料更新能力，既支援批次入湖，也支援流式資料，並且透過Clustering機制避免了小檔案問題造成的叢集壓力。因此，建設統一的基於Hudi的資料湖，不但可以高效地處理資料，也符合統一資料管理的要求。

二、資料鏈路治理也是需要關注和加強的地方，資料鏈路治理的目標是保障資料的準確性、可用性和及時性。由於上游任務異常或叢集故障問題，推送到資料湖的資料可能出現延遲，從而影響下游資料呼叫及批次任務。另外，如果上游入湖資料出現異常，會導致下游批次錯誤，修正資料則需要下游所有相關批次任務的重新執行，代價很大。因此，完善的延遲監控、資料異常監測及批次任務熔斷機制是後續需要重點加強的方面。

資料湖平臺在統一資料管理、資料鏈路治理等方面將日趨完善和健壯，持續助力資料價值的挖掘，不斷賦能G行業務的發展。