數據湖管理及優化
摘要：本文整理自阿里雲開源大數據高級開發工程師楊慶葦在7月17日阿里雲數據湖技術專場交流會的分享。本篇內容主要分為兩個部分：
- 數據湖元數據倉庫介紹
- 阿里雲DLF數據湖管理與優化
數據湖元數據倉庫介紹
數據湖的實踐過程中，我們面臨了諸多挑戰：
第一，數據難以識別和查找。數據湖記憶體在大量未被有效識別的數據，可能是歷史遺留或未被管理的數據，比如通過文件拷貝上傳或其他工具引擎寫入湖內的數據。其次，傳統元數據服務里缺乏有效的檢索服務，數據增長到一定規模時，很難從大量元數據中搜索和定位到特定場景下的數據。
第二，數據資產管理能力弱，湖上缺乏有效的數據資產分析和優化工具，難以精細化掌握庫、表分區級別的數據明細。對 schema 維度存儲分層方案落地困難，數據冷熱難以辨別，無法在庫、表分區維度實現分層。
第三，湖格式優化缺乏系統的解決方案。比如小文件合併操作需要用戶對湖格式有一定的了解，能主動發現部分 schema 存在不合理的小文件，且利用計算引擎運行小文件合併任務，存在一定的使用門檻。此外，需要用戶能夠識別無效的歷史數據以對其進行清理。
為了解決數據湖實踐過程中遇到的挑戰，綜合湖上數據特點以及計算引擎特點，阿里雲提出了基於元倉數據底座，以雲原生資源池的海量計算能力為基礎，結合管控的在線服務能力，為用戶提供全託管的湖管理和優化的解決方案。
數據湖元數據倉庫架構
元倉組成湖上元數據以及分析和計算數據，為湖管理和優化提供了參考指標。經過數據採集、ETL、數據分析、計算等過程，將湖上分布在各處的數據進行整合，提取出有意義的指標，構建出分析庫、指標庫和索引庫，為上層應用提供數據支撐。
上圖右側是雲原生計算池，通過 Spark 引擎利用雲上的可伸縮資源運行 Analyze、Indexing、Compaction、Tiering 等分析和優化任務，並實時將計算結果寫回元倉，參與指標庫與索引庫的建設，豐富和擴展元倉的指標資產，如在計算池內運行 stats 任務、獲取錶行數大小等指標，並回寫到元倉指標庫，用戶可在第一時間查看錶的基礎資訊，並以此為參考做數據品質分析等操作。
管控層提供用了在線服務能力，如在線目錄、檢索服務、指標服務等，優化引擎負責分析元倉上的指標，並依據規則生成優化任務提交給雲原生計算池進行計算。在此之上延伸出了很多湖管理優化的能力：
①元數據能力：解決了數據難以識別和操作的問題。比如針對元數據檢索，通過建立檢索庫，快速搜索元數據以及相關的 schema 明細。元數據發現通過雲原生池計算運行任務提取元數據資訊，有效識別湖內未知數據。
②存儲優化能力：解決了數據資產管理能力弱的痛點。比如存儲統計分析，通過元倉的指標庫分析庫、表分區級別的數據明細、冷熱分層，通過指標庫提供的表分區，最近訪問時間、訪問頻率、冷熱指標對錶分區自動分層。
③查詢優化能力：如小文件合併，通過指標庫提取出小文件表和分區資訊，根據規則在雲原生資源池上運行小文件合併任務。此為全託管過程，用戶側無感知。
④湖格式管理優化：實現了元數據加速和自動優化。
以上方案解決了數據湖管理與優化的部分問題，幫助用戶更好地使用和管理數據湖。
數據湖元數據倉庫建設
湖上元倉的原始數據由三類數據構成：
①存儲數據：文件級別的OSS存儲數據資訊，包括大小、存儲路徑、存儲類型、最近更新時間等，均來自存儲訪問日誌和明細清單，這些基礎數據構成存儲屬性的元數據，是分析和管理對象存儲的基礎。
②元數據：描述目錄、庫、表、分區、函數等的數據，包括索引、屬性、存儲以及 stats的統計數據。主要來自於引擎元數據服務存儲以及 stats的計算擴充，是大表治理、小文件合併等優化操作的基礎數據。
③引擎行為數據：包括血緣數據、引擎任務執行數據，比如文件大小、文件數、任務上下游依賴資訊數據。這些數據在引擎計算時產生，是建設數據地圖、生命周期管理的基礎數據。
以上數據經過日誌服務消費、Spark 批任務、離線同步、Spark Structured Streaming、流任務實時消費等方式集成到元倉，作為元倉的原始數據。元倉選擇 Hologres 作為存儲庫，因為Hologres對於海量數據的實時寫入、實時更新、實時分析能提供較好的支援。
對於實時性要求不高，但有較大數據量分析的場景，比如庫表存儲分析，可以通過 MaxCompute 離線數據加工的方式，將原始數據轉換成明細數據，並提供離線指標給管控層；對於有較高實時性要求的場景，比如獲取表分區行數、執行更新時間等，通過 Hologres 實時分析能力，實時計算出分析指標，並提供給 DLF 管控。
元倉包含了實時和離線場景，為數據湖管理和優化提供了穩定、高品質的數據基礎。
阿里雲DLF數據湖管理與優化
元數據檢索
元數據檢索解決了數據湖上數據難以查找的痛點。主要提供了兩種搜索方式，一是全文檢索，通過對元數據所有列屬性建立索引，滿足對任意單詞的搜索都能在毫秒級別內做出響應；二是提供了多列精確查詢，滿足在特定條件場景下的搜索，比如按庫名、表名、列名、Location地址、創建時間、最後修改時間等特殊屬性精確匹配搜索。
索引庫選擇了阿里雲Elasticsearch方案。 ES 是實時分散式的搜索與分析引擎，可以近乎准實時地存儲、查詢和分析超大數據集，非常適合元數據的實時搜索場景。為了達到搜索結果秒級延遲的效果，我們選用 Spark Streaming 流技術，實時同步和解析引擎生產的 DML 日誌寫入 ES 庫。
但消費日誌存在著兩個天然的問題：一是消息的順序性，無法保證順序產生的 DML 事件能被順序地消費並寫入 ES 庫；二是消息的可靠性，日誌服務無法保證集群日誌能夠百分百被捕捉並寫入到 hub。
為了解決上述痛點，一方面會通過消息內的最近更新時間做判斷，邏輯上保證了消息的順序性；另一方面，通過每日的離線任務同步元資料庫做索引補償，保證了每日元數據資訊的可靠性。通過流技術、離線補償技術、ES檢索能力，實現了湖內從大量元數據中快速搜索和定位的能力。
數據資產分析
分析維度：
湖上資產分析能力能夠更高效、簡潔地幫助用戶分析和管理湖上資產，包含了資源統計、趨勢變化、存儲排名、存儲分層。
資源統計提供了總存儲量、總庫表數量、 API 訪問資訊總量，為用戶提供了直觀的數據感受，對湖上資產進行全局把握。
趨勢變化反映了上述統計指標近 7 天、30天和 1 年的增減變化。通過數據波動能夠發現業務的發展狀態，比如判斷某業務近期的發展態勢，並根據態勢調整資源投入。
存儲排名反映了庫表在一定範圍內的排序情況，用戶可以根據這一排名發現表的數據成本問題，比如 80% 的存儲集中在 20% 表裡。
存儲分層描述了對象存儲上存儲類型的分布情況、存儲格式分布情況以及大小文件分布情況。通過分布情況判斷當前數據分層是否合理。
以上分析數據一方面能夠幫助用戶更好地理解和掌握湖上資產，另一方面為用戶管理和優化湖數據提供了事實依據。
數據模型：
資產分析的模型建立遵循數倉的分層範式，從下至上分別為源數據層、數據公共層、數據應用層。 OSS存儲的日誌、明細數據、元數據和審計數據通過離線任務同步至元倉 ODS 層，然後通過離線加工計算出公共層數據，包括元數據、維表、文件存儲、明細表、庫表匯總等，然後根據業務需求將公共數據加入到應用數據並輸出給管控，最後進行報表展示。
庫表維度精細化分析-DataProfile
DataProfile 模組在庫表元素之上，增加擴展了 stats 指標。stats 是引擎對於表的統計資訊，包括表的記錄數、表大小、文件數量等基礎數據。在此基礎上做了 stats 擴展，包括小文件數據、小文件佔比、冷熱度、分層資訊指標等。由於數據湖對接多種引擎，Spark、 Hive 等。每種引擎 stats 計算結果都無法保證全面準確，且觸發條件不一致，指標的覆蓋度較低。默認情況下，如果分區表的記錄數、大小文件指標覆蓋度不足20%，則無法直接使用元數據 stats 指標。因此，我們通過主動提交 stats 分析任務，幫助用戶計算表的 stats 數據。
首先，引擎做 DML 任務後會產生一個事件，元倉記錄這一事件， stats 集群實時消費 DML 事件，並拉起對應的 stats 分析任務，同時擴展了 analyze 命令，支援小文件數量、數據分層佔比等分析指標。整個 stats 集群運行在雲原生資源池內，為避免元數據服務與業務庫的衝突，任務運行完成後會實時寫入指標庫。
上述方案補充了雲原生計算引擎 stats 數據覆蓋準確度不高的問題，為表分析和優化提供了基礎數據。Stats 能為管控頁面提供庫、表分區級別的明細數據，也能為其他優化引擎提供數據支援，比如分析表的小文件數量指標進行小文件合併，同時也能服務多種引擎做 CBO 優化。
生命周期管理
生命周期管理模組能夠對 schema 維度存儲分層，有效地幫助用戶降低存儲成本。 OSS 對象存儲提供了文件級別的分層能力，OSS 不同存儲類型價格不同，由熱到冷分別為標準、低頻、歸檔、冷歸檔，成本依次遞減。基於此能力，可以將不常使用的數據冷凍，待使用時再解凍，以此降低存儲成本。
基於 OSS 的分層能力，結合引擎元數據，提供庫表分區粒度的生命周期管理能力，根據規則對錶和分區進行冷凍或解凍，以此降低用戶對數據湖內冷熱分層的使用門檻。
規則中心通過元倉提供的指標制定，包括最近修改時間、創建時間、分區值、訪問頻率等指標，其中訪問頻率由分析引擎任務明細產生，通過 hook 的方式採集 Spark 或 Hive 執行任務時的任務明細，經過計算加工提取訪問頻率和最近訪問的時間冷熱資訊。最近修改時間、創建時間分區值等基礎指標由元倉計算而來。
決策中心定期觸發規則判斷，在滿足規則的情況下會產生歸檔任務，由任務中心實行。整個任務中心通過分散式調度，定時或手動執行解凍或歸檔任務，利用 JindoSDK 的高並發、高穩定特性，執行目錄級別的文件歸檔操作。
生命周期管理過程對於用戶而言十分便捷，用戶無需操作 OSS 文件，極大提高了用戶對湖上數據的分層管理能力。
以上為阿里雲數據湖團隊在數據湖管理優化過程中的實踐，在實際應用過程中，幫助客戶優化存儲成本的同時，提高了數據的使用效率。
更多資訊：
產品官網
[1] 數據湖構建Data Lake Formation：//www.aliyun.com/product/bigdata/dlf
[2] 開源大數據平台EMR： //www.aliyun.com/product/emapreduce
[3] 大數據知識圖譜： //developer.aliyun.com/learning/topic/bigdata
數據湖系列
[1] 數據湖揭秘—Delta Lake： //developer.aliyun.com/article/909818
[2] 數據湖構建—如何構建湖上統一的數據許可權： //developer.aliyun.com/article/918403
[3] 關於 Data Lake 的概念、架構與應用場景介紹：//developer.aliyun.com/article/944650
[4] 數據湖架構及概念簡介：
//developer.aliyun.com/article/1004847
[5] 數據湖統一元數據和許可權
//developer.aliyun.com/article/1008235
