隨著移動互聯網的飛速發展，對于短時間內產生的大規模、多種類數據的存儲和分析要求越來越高。數據湖是一種支持結構化、半結構化、非結構化等大規模數據存儲和計算的系統架構，能夠高效地對原始數據進行存儲和取用，解決了傳統數據倉庫需要預先定義數據結構、海量數據加載慢的問題。目前，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行業務的發展。
