數據湖已經逐步走到了精細化的管理，這意味着原始的計算引擎直接讀寫存儲的方式應當逐步演變爲使用標準方式讀寫數據湖存儲。然而“標準方式”實際上並無業界標準，與具體的計算引擎深度綁定，因此，支持計算引擎的豐富程度也就成了衡量數據湖的一個準則。
阿里雲數據湖構建服務支持豐富的計算引擎對接，包括但不限於阿里雲產品 E-MapReduce（EMR）、MaxCompute（開發中）、Blink（開發中）、Hologres（開發中）、PAI（開發中），以及開源系的 Hive、Spark、Presto 等等。
數據湖的對接主要體現在元數據與存儲引擎兩個方面。元數據爲所有用戶所共享，提供統一的元數據訪問接口。各個引擎使用定製化的元數據訪問客戶端來訪問元數據。元數據服務爲各個用戶提供租戶隔離保證和認證鑑權服務。在數據存儲方面，用戶使用自己的 OSS 存儲存儲數據，各個引擎需要具備訪問 OSS 的功能，這對於阿里雲服務和大部分支持 HDFS 存儲的引擎都不是什麼問題。在 OSS 存儲上層，數據湖構建服務還提供了可選的數據湖加速服務。而使用該服務也非常簡單，只需要在引擎側將對 OSS 的訪問路徑替換爲加速服務提供的路徑即可。
多引擎支持
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 存儲的性能。