大數據引擎的現狀
在大數據計算和存儲領域，因不同業務場景、不同數據規模，誕生了很多適合處理不同需求的各類大數據引擎，比如計算引擎類有數據分析引擎Hive、交互式分析引擎Presto、迭代計算引擎spark以及流處理引擎Flink等，存儲類有日誌存儲系統的SLS、分佈式文件系統HDFS等，這些引擎和系統很好的滿足了某一領域的業務需求，但也存在非常嚴重的數據孤島問題：在同一份數據上綜合使用這些系統，必然面臨着大量的ETL工作，而且更關鍵的是在目前各種公司業務鏈路上這種使用方式非常常見，同時因數據加工、轉儲產生的成本以及整體延時大大增加，業務決策時間也相應變長，解決這一問題的關鍵在於引擎元數據需要互通，只有構建滿足各種引擎需求的數據湖統一元數據服務視圖，才能實現數據共享，避免其中額外的ETL成本以及降低鏈路的延時。
數據湖元數據服務的設計
數據湖元數據服務的設計目標是能夠在大數據引擎、存儲多樣性的環境下，構建不同存儲系統、格式和不同計算引擎統一元數據視圖，並具備統一的權限、元數據，且需要兼容和擴展開源大數據生態元數據服務，支持自動獲取元數據，並達到一次管理多次使用的目的，這樣既能夠兼容開源生態，也具備極大的易用性。另外元數據應該支持追溯、審計，這就要求數據湖統一元數據服務具備以下能力和價值：
- 提供統一權限、元數據管理模塊：統一的權限/元數據管理模塊是各類引擎和存儲互通的基礎，不僅權限/元數據模型需要滿足業務對於權限隔離的需要，也需要能夠合理支持目前引擎的各種權限模型。
- 提供大規模元數據的存儲和服務能力，提升元數據服務能力極限，滿足超大數據規模和場景
- 提供存儲統一的元數據管理視圖：將各類存儲系統（對象、文件、日誌等系統）上數據進行結構化既能夠方便數據的管理，也因爲有了統一元數據，才能進行下一步的分析和處理。
- 支撐豐富的計算引擎：各類引擎，通過統一元數據服務視圖訪問和計算其中的數據，滿足不同的場景需求。比如PAI/MaxCompute/Hive等可以在同一份OSS數據上進行計算和分析。通過引擎支撐的多樣化，業務場景將越來容易進行場景轉換和使用。
- 元數據操作的追溯/審計
- 元數據自動發現和收集能力：通過對文件存儲的目錄/文件/文件格式的自動感知，自動創建和維護元數據的一致性，方便存儲數據的自動化維護和管理。
數據湖元數據服務的架構
元數據服務上層是引擎接入層
- 通過提供各種協議的SDK和插件，能夠靈活支撐各種引擎的對接，滿足引擎對於元數據服務的訪問需要。並且通過元數據服務提供的視圖，對底層文件系統進行分析和處理。
- 通過插件體系無縫兼容EMR引擎，能夠使EMR全家桶開箱即用，用戶全程無感知，即可體驗統一元數據服務，避免原Mysql等存儲的可擴展性差的問題
元數據服務提供存儲視圖
通過對不同存儲格式/存儲目錄文件的抽象，爲引擎提供統一元數據服務，同時能夠避免多引擎獨立使用元數據服務之間的不一致性
元數據的管理和自動發現
元數據通過各種方式能夠靈活的、跨引擎管理元數據，既能使用戶方便的集成元數據服務、擴展元數據服務能力，也能夠降低管理成本。
- Web Console、Sdk、各類引擎客戶端和接口
1.兼容開源生態引擎的各類數據庫/表/分區上的DDL操作。
2.提供多版本元數據管理/追溯的能力
3.通過元數據能力的開放，在ETL部分/開源工具部分將來也能通過各式插件進行對接，進一步完善整體生態
- 元數據自動發現
元數據自動發現能力是元數據管理能力的另一核心部分，能夠自動收集各處文件系統散落的數據，極大了拓寬了統一元數據服務的場景，節省了管理的代價和複雜性。這其中的能力包括
1.自動分析目錄層次，動態增量創建database/table/partition等元數據
2.自動分析文件格式，對於各類格式比如常規文本格式及開源大數據格式parquet、orc等都進行了支持
元數據服務的未來
數據湖元數據服務爲大數據而生，爲互通生態而生，期望後續繼續完善其服務能力和支撐更多的大數據引擎，通過開放的服務能力、存儲能力、統一的權限及元數據管理能力，爲客戶節省管理/人力/存儲等各項成本，實現客戶自己的業務價值。
原文鏈接
本文爲阿里雲原創內容，未經允許不得轉載。