資料湖已經逐漸走到了精細化的管理，這意味着原始的計算引擎直接讀寫存儲的方式應當逐漸演變為使用标準方式讀寫資料湖存儲。然而“标準方式”實際上并無業界标準，與具體的計算引擎深度綁定，是以，支援計算引擎的豐富程度也就成了衡量資料湖的一個準則。
阿裡雲資料湖建構服務支援豐富的計算引擎對接，包括但不限于阿裡雲産品 E-MapReduce（EMR）、MaxCompute（開發中）、Blink（開發中）、Hologres（開發中）、PAI（開發中），以及開源系的 Hive、Spark、Presto 等等。
多引擎支援
EMR
使用 EMR 通路資料湖建構服務最為簡單。在使用者建立 EMR 叢集的時候，可以直接選擇使用資料湖建構服務的中繼資料服務作為中繼資料庫，EMR 服務與資料湖建構服務在認證鑒權方面深度打通，隻要獲得使用者的授權，EMR 基于資料湖中繼資料的使用體驗和用本地中繼資料庫體驗幾乎完全一緻。因為在 EMR 叢集建立階段已經自動安裝了資料建構服務的相關SDK，同時EMR上的開源計算引擎 Spark、Hive 和 Presto 都完成了對資料湖建構服務的相容支援，是以使用者通過 EMR 引擎可獲得資料湖分析的最佳體驗。
即便使用者在建立叢集的時候沒有選擇使用資料湖中繼資料服務，也可以在後期通過配置将中繼資料轉移到資料湖中繼資料服務。在資料存儲方面，由于資料湖建構在使用者 OSS 之上，是以不存在跨服務認證問題。而 EMR 天然内置了 OSS 的通路支援，并提供了 JindoFS 的增強功能，使得 EMR 使用者通路資料湖資料将獲得比原生 OSS 通路更佳的性能提升（JindoFS 是建構在 OSS 之上的，專門為大資料使用場景深度定制的檔案系統，在中繼資料操作、資料緩存等方面有獨到的優勢。更多相關文章請參考文末連結。）。對于那些已經在使用 EMR 的使用者，資料湖建構服務提供了一鍵遷移工具，友善使用者将中繼資料從本地中繼資料庫轉移到資料湖中繼資料服務。對于資料部分，使用者可以選擇将資料繼續存儲在本地 HDFS 系統，或者遷移至 OSS。
值得一提的是 EMR 提供了免 AK 通路資料湖建構服務的功能。使用者不需要提供 AK 即可通路中繼資料服務以及 OSS 上的資料，前提是資料湖建構服務獲得了使用者的授權。該功能的實作基于 EMR 的 MetaService 功能，在使用者授權的前提下，MetaService 為本機請求提供 Assume Role 的 AK 資訊，進而讓調用者以使用者身份通路目标服務。免 AK 通路功能最小化了使用者機密資訊丢失的風險。
阿裡雲服務
MaxCompute、實時計算、Hologres、PAI 等阿裡雲服務，通過資料湖建構服務在底層打通資料，在一定程度上達到通過使用一份資料滿足多種不同場景的計算需求。例如，MaxCompute 可以直接讀取資料湖建構服務的資料内容，配合 DataWorks 給使用者良好的數倉使用體驗；實時計算服務可以将資料實時注入資料湖，進而實作基于資料湖的流批一體計算；而 Hologres 則可以應對對性能要求較高的場景，既能夠對于資料湖内溫冷資料做加速分析，也能夠配合 Hologres 的内置存儲處理溫熱資料，進而建構資料從産生到歸檔一整個生命周期的一站式分析方案；PAI 則可以将資料湖作為資料來源，也可以将其他引擎計算的離線特征存儲到資料湖做模型建構之用等等。
開源引擎
對于直接使用開源産品的使用者，資料湖建構服務也提供了一些方法讓這些服務能夠快速對接資料湖，不過這可能需要使用者基于開源代碼打個 patch，以便在開源代碼中插件化地嵌入資料湖中繼資料的通路。對于資料通路，由 EMR 團隊貢獻 Hadoop 社群的 OSSFileSystem 可以完成對使用者 OSS 存儲的通路，是以隻要引擎支援讀寫 HDFS，就可以讀寫 OSS。對于中繼資料和 OSS 的通路控制，則統一使用阿裡雲 RAM 方式，體驗上保證一緻。
特殊格式支援
除了計算引擎本身，某些引擎還可以讀寫特定的表格式，如近兩年興起的 Delta Lake、Hudi、Iceberg 等等。資料湖建構服務不局限使用者使用哪一種存儲格式，但是由于這些表格式有自己的中繼資料，是以在引擎對接方面仍然需要做一些額外的工作。以 Delta Lake 為例，其中繼資料存儲在 OSS 之上，而中繼資料服務中也會存一份中繼資料，這樣便引出了兩個問題：一是引擎應該讀取哪份中繼資料，二是如果有必要存兩份中繼資料的話，中繼資料的一緻性如何保證。對于第一個問題，如果是開源元件，我們應當遵循開源預設的做法，通常是讓引擎去讀取 OSS 中的中繼資料。對于中繼資料服務中的中繼資料也非常有必要儲存，這可以服務于頁面顯示，并且可以省去 OSS 中繼資料解析的巨大性能損耗。對于第二個問題，資料湖建構服務開發了一個 hook 工具，每當 Delta Lake 有事務送出時，便會自動觸發 hook，将 OSS 中的中繼資料同步到中繼資料服務中。除此之外，Delta Lake 中繼資料的設計最大程度的保證了一份中繼資料同時支援 Spark、Hive、Presto 等多個引擎，使用者不必像開源産品那樣為不同引擎維護不同的中繼資料。
如圖所示，中繼資料服務中的中繼資料（Delta Table）為 OSS 中 Delta 表中繼資料（Delta Log）的映像，并通過 commit hook（3）保持同步；Delta Tabe 為頁面展示，以及 Hive、Spark 引擎讀取必要資訊（如 table path、InputFormat/OutputFormat 等）所用（1）；當引擎獲得必要資訊後讀取 table path 下 Delta 表的中繼資料，完成中繼資料解析和資料讀取工作（2）；當引擎完成資料操作并送出事務後，Delta Log 通過 commit hook 同步至 Delta Table（3），完成一個循環。
未來工作
資料湖建構服務的多引擎支援在諸多方面尚在快速發展之中。未來我們将圍繞以下幾點繼續開展工作：
- 阿裡雲服務對接：從解決方案角度完善阿裡雲産品對接，給使用者更平滑的體驗；
- 開源引擎支援：更多的開源引擎支援，如 Impala、Flink 等；
- 功能豐富：如完善統計資訊支援，支援事務接口等；
- 性能提升：做到超越本地中繼資料與本地 HDFS 存儲的性能。
更多資料湖技術相關的文章請點選：
阿裡雲重磅釋出雲原生資料湖體系更多資料湖相關資訊交流請加入阿裡巴巴資料湖技術釘釘群