作者：關濤、李睿博、孫莉莉、張良模、賈揚清 （from 阿里雲智慧計算平臺)    黃波、金玉梅、於茜、劉子正 （from 新浪微博機器學習研發部)

近幾年，隨著資料湖概念的興起，業界對於資料倉庫和資料湖的對比甚至爭論始終不斷。資料倉庫和資料湖的區別到底是什麼？本文作者來自阿里巴巴計算平臺部門，在深度參與阿里巴巴大資料 / 資料中臺領域建設之後，將對資料湖和資料倉庫的來龍去脈進行深入剖析，闡述兩者融合演進的新方向——湖倉一體。

大資料 20 年發展的變與不變

概述

大資料從本世紀初發展到現在，已經歷 20 年。從巨集觀層面觀察其中的發展規律，可以高度概括成如下五個方面：

圖 1. 阿里巴巴雙十一單日處理資料量增長

1. 資料保持高速增長
2. 大資料作為新的生產要素，得到廣泛認可
3. 資料管理能力成為新的關注點
4. 引擎技術進入收斂期
5. 平臺技術演進出兩個趨勢，資料湖 VS 資料倉庫。兩者均關注資料儲存和管理（平臺技術），但方向不同。

從大資料技術發展看湖和倉

縱觀大資料的發展歷史，可以看出資料倉庫和資料湖有著截然不同的發展脈絡。大體上，電腦科學領域的資料處理技術的發展，主要分為四個階段：

階段一：資料庫時代。資料庫最早誕生於 20 世紀的 60 年代，今天人們所熟知的關係型資料庫則出現在 20 世紀 70 年代，並在後續的 30 年左右時間裡大放異彩，誕生了很多優秀的關係型資料庫，如 Oracle、SQL Server、MySQL、PostgresSQL 等，成為當時主流計算機系統不可或缺的組成部分。到 20 世紀 90 年代，資料倉庫的概念誕生。此時的資料倉庫概念更多表達的是如何管理企業中多個數據庫例項的方法論，但受限於單機資料庫的處理能力以及多機資料庫（分庫分表）長期以來的高昂價格，此時的資料倉庫距離普通企業和使用者都還很遙遠。人們甚至還在爭論資料倉庫（統一集中管理）和資料集市（按部門、領域的集中管理）哪個更具可行性。

階段二：大資料技術的「探索期」。2000 年左右，隨著網際網路的爆發，動輒幾十億、上百億的頁面以及海量的使用者點選行為，開啟了全球的資料量急劇增加的新時代。傳統的資料庫方案再也無力以可接受的成本提供計算力，巨大的資料處理需求開始尋找突破口，大資料時代開始萌芽。Google 先後發表 3 篇經典論文（GFS、MapReduce、BigTable），奠基了這個大資料時代的基本技術框架，即分散式儲存、分散式排程以及分散式計算模型。隨後，幾乎是在同一時期，誕生了包括 Google，微軟 Cosmos 以及開源 Hadoop 為代表的優秀分散式技術體系，當然，這其中也包括阿里巴巴的飛天系統。此時人們興奮於追求資料的處理規模，即『大』資料，沒有閒暇爭論是資料倉庫還是資料湖。

階段三：大資料技術的「發展期」。21 世紀第二個 10 年，隨著越來越多的資源投入到大資料計算領域，大資料技術進入一個蓬勃發展的階段，整體開始從能用轉向好用。代替手寫 MapReduce 作業，是如雨後春筍般出現的各種以 SQL 為表達的計算引擎，極大降低了大資料技術的使用成本，資料庫時代人們夢想的大一統的資料倉庫終於成為現實，各種資料庫時代的方法論開始抬頭。這個時期技術路線開始出現細分。雲廠商主推的如 AWS Redshift、Google BigQuery，包括 MaxCompute 這樣的整合系統稱為大資料時代的資料倉庫。而以開源 Hadoop 體系為代表的的開放式 HDFS 儲存、開放的檔案格式、開放的元資料服務以及多種引擎（Hive、Presto、Spark、Flink 等）協同工作的模式，則形成了資料湖的雛形。

階段四：大資料技術「普及期」。當前，大資料技術早已不是什麼火箭科技，而已經滲透到各行各業，大資料的普及期已經到來。市場對大資料產品的要求，除了規模、效能、簡單易用，提出了成本、安全、穩定性等更加全面的企業級生產的要求。

開源 Hadoop 線，引擎、元資料、儲存等基礎部件的迭代更替進入相對穩態，大眾對開源大資料技術的認知達到空前的水平。一方面，開放架構的便利帶來了不錯的市場份額，另一方面開放架構的鬆散則使開源方案在企業級能力構建上遇到瓶頸，尤其是資料安全、身份許可權強管控、資料治理等方面，協同效率較差。同時引擎自身的發展也對已有的開放架構提出了更多挑戰，Delta Lake、Hudi 這樣自閉環設計的出現使得一套儲存、一套元資料、多種引擎協作的基礎出現了某種程度的裂痕。

真正將資料湖概念推而廣之的是 AWS。AWS 構築了一套以 S3 為中心化儲存、Glue 為元資料服務，E-MapReduce、Athena 為引擎的開放協作式的產品解決方案。它的開放性和開源體系類似，並在 2019 年推出 Lake Formation 解決產品間的安全授信問題。這套架構對於開源技術體系的使用者來說，架構相近理解容易，仍然相當有吸引力。AWS 之後，各個雲廠商也紛紛跟進資料湖的概念，並在自己的雲服務上提供類似的產品解決方案。

雲廠商主推的資料倉庫類產品則發展良好，數倉核心能力方面持續增強。效能、成本方面極大提升（如 MaxCompute 連續三年重新整理 TPCx-BigBench 世界記錄），資料管理能力空前增強（發展出資料中臺建模理論和智慧數倉），企業級安全能力大為繁榮（如細粒度資料安全控制、服務可用性 SLA 等），在聯邦計算方面也普遍做了增強，一定程度上開始將非數倉自身儲存的資料納入管理，和資料湖的邊界日益模糊。

綜上所述，資料倉庫和資料湖是伴隨著大資料技術發展，進化而來的兩種不同的大資料平臺技術，有著各自的特點和應用場景，在企業數字化建設中均扮演著重要的角色。

圖 2. 20 年大資料發展之路

資料湖的本質和技術架構演進

近幾年資料湖的概念非常火熱，各家對資料湖的定義不盡相同，但不論如何，資料湖的本質其實都包含如下四部分：

1. 統一的儲存系統
2. 儲存原始資料
3. 豐富的計算模型 / 正規化
4. 資料湖與上雲無關

從上述四個標準判斷，開源大資料的 Hadoop HDFS 儲存系統就是一個標準的資料湖架構，具備統一的原始資料儲存架構。而近期被廣泛談到的資料湖，其實是一個狹義的概念，特指“基於雲上託管儲存系統的資料湖系統，架構上採用儲存計算分離的體系”。例如基於 AWS S3 系統或者阿里雲 OSS 系統構建的資料湖。

下圖是資料湖技術架構的演進過程，整體上可分為三個階段：

圖 3. 資料湖技術架構演進

階段一：自建開源 Hadoop 資料湖架構，原始資料統一存放在 HDFS 系統上，引擎以 Hadoop 和 Spark 開源生態為主，儲存和計算一體。缺點是需要企業自己運維和管理整套叢集，成本高且叢集穩定性差。

階段二：雲上託管 Hadoop 資料湖架構（即 EMR 開源資料湖），底層物理伺服器和開源軟體版本由雲廠商提供和管理，資料仍統一存放在 HDFS 系統上，引擎以 Hadoop 和 Spark 開源生態為主。這個架構通過雲上 IaaS 層提升了機器層面的彈性和穩定性，使企業的整體運維成本有所下降，但企業仍然需要對 HDFS 系統以及服務執行狀態進行管理和治理，即應用層的運維工作。同時因為儲存和計算耦合在一起，兩種資源無法獨立擴充套件。

階段三：雲上資料湖架構，即雲上純託管的儲存系統逐步取代 HDFS，成為資料湖的儲存基礎設施，並且引擎豐富度也不斷擴充套件。除了 Hadoop 和 Spark 的生態引擎之外，各雲廠商還發展出面向資料湖探查分析產品。這個架構仍然保持了一個儲存和多個引擎的特性，相對於原生 HDFS 的資料湖架構的優勢在於：

幫助使用者擺脫原生 HDFS 系統運維困難的問題。分離後的儲存系統可以獨立擴充套件，不再需要與計算耦合，可降低整體成本當使用者採用資料湖架構之後，客觀上也幫助客戶完成了儲存統一化（解決多個 HDFS 資料孤島的問題）。

圖 4. 阿里雲 EMR 資料湖架構

資料倉庫的誕生及與資料中臺的關係

資料倉庫的概念最早來源於資料庫領域，主要處理面向資料的複雜查詢和分析場景。隨著大資料技術發展，大量借鑑資料庫的技術，例如 SQL 語言、查詢優化器等，形成了大資料的資料倉庫，因其強大的分析能力，成為主流。近幾年，資料倉庫和雲原生技術相結合，又演生出了雲資料倉庫，解決了企業部署資料倉庫的資源供給問題。雲資料倉庫作為大資料的高階（企業級）平臺能力，因其開箱即用、無限擴充套件、簡易運維等能力，越來越受到人們的矚目。

筆者認為，資料倉庫的本質包含如下三部分：

1. 內建的儲存系統，資料通過抽象的方式提供（例如採用 Table 或者 View），不暴露檔案系統；
2. 資料需要清洗和轉化，通常採用 ETL/ELT 方式；
3. 強調建模和資料管理，供商業智慧決策。

從上述的標準判斷，無論傳統資料倉庫還是新興的雲資料倉庫系統（AWS Redshift、Google BigQuery、阿里雲 MaxCompute）均體現了數倉的設計本質，它們均沒有對外暴露檔案系統，而是提供了資料進出的服務介面。這個設計可以帶來多個優勢：

1. 引擎深度理解資料，儲存和計算可做深度優化
2. 資料全生命週期管理，完善的血緣體系
3. 細粒度的資料管理和治理
4. 完善的元資料管理能力，易於構建企業級資料中臺

正因為如此，阿里巴巴飛天大資料平臺建設之初，在選型的時候就採用了資料倉庫的架構，即 MaxCompute 大資料平臺。MaxCompute（原 ODPS) 既是阿里巴巴經濟體的大資料平臺，又是阿里雲上的線上大資料計算服務（百度搜索阿里雲官網 - 左側大資料與人工智慧選擇 MaxCompute）。

圖 5. MaxCompute 雲數倉產品架構

得益於 MaxCompute 資料倉庫的架構，阿里巴巴上層逐步構建了“資料安全體系”、“資料質量”、“資料治理”、“資料標籤”等管理能力，並最終形成了阿里巴巴的大資料中臺。可以說，作為最早資料中臺概念的提出者，阿里巴巴的資料中臺得益於資料倉庫的架構。

圖 6. 阿里巴巴資料中臺架構

資料湖 VS 資料倉庫

綜上，資料倉庫和資料湖，是大資料架構的兩種設計取向。兩者在設計的根本分歧點是對包括儲存系統訪問、許可權管理、建模要求等方面的把控。

資料湖優先的設計，通過開放底層檔案儲存，給資料入湖帶來了最大的靈活性。進入資料湖的資料可以是結構化的，也可以是半結構化的，甚至可以是完全非結構化的原始日誌。另外，開放儲存給上層的引擎也帶來了更多的靈活度，各種引擎可以根據自己針對的場景隨意讀寫資料湖中儲存的資料，而只需要遵循相當寬鬆的相容性約定（這樣的鬆散約定當然會有隱患，後文會提到）。但同時，檔案系統直接訪問使得很多更高階的功能很難實現，例如，細粒度（小於檔案粒度）的許可權管理、統一化的檔案管理和讀寫介面升級也十分困難（需要完成每一個訪問檔案的引擎升級，才算升級完畢）。

而資料倉庫優先的設計，更加關注的是資料使用效率、大規模下的資料管理、安全 / 合規這樣的企業級成長性需求。資料經過統一但開放的服務介面進入資料倉庫，資料通常預先定義 schema，使用者通過資料服務介面或者計算引擎訪問分散式儲存系統中的檔案。資料倉庫優先的設計通過抽象資料訪問介面 / 許可權管理 / 資料本身，來換取更高的效能（無論是儲存還是計算）、閉環的安全體系、資料治理的能力等，這些能力對於企業長遠的大資料使用都至關重要，我們稱之為成長性。

下圖是針對大資料技術棧，分別比較資料湖和資料倉庫各自的取捨。

圖 7. 資料湖和資料倉庫在技術棧上的對比

靈活性和成長性，對於處於不同時期的企業來說，重要性不同。

當企業處於初創階段，資料從產生到消費的生命週期還需要一個創新探索的階段才能逐漸沉澱下來，那麼用於支撐這類業務的大資料系統，靈活性就更加重要，資料湖的架構更適用。

當企業逐漸成熟起來，已經沉澱為一系列資料處理流程，問題開始轉化為資料規模不斷增長，處理資料的成本不斷增加，參與資料流程的人員、部門不斷增多，那麼用於支撐這類業務的大資料系統，成長性的好壞就決定了業務能夠發展多遠。資料倉庫的架構更適用。

很多企業（尤其是新興的網際網路行業）正在經歷這樣一個從探索創新到成熟建模的過程。在這個過程中，因為資料湖架構太過靈活而缺少對資料監管、控制和必要的治理手段，導致運維成本不斷增加、資料治理效率降低，企業落入了“資料沼澤”的境地，即資料湖中匯聚了太多的資料，反而很難高效率地提煉真正有價值的那部分。最後只有遷移到資料倉庫優先設計的大資料平臺，才解決了業務成長到一定規模後所出現的運維、成本、資料治理等問題。

阿里巴巴的資料中臺戰略，正是在 2015 年前後阿里巴巴全集團完成 MaxCompute（資料倉庫） 對多個 Hadoop（ 資料湖）的完全替換（登月專案）才逐步形成的。

圖 8. 資料湖的靈活性 VS 資料倉庫的成長性的示意圖

下一代演進方向：湖倉一體

經過對資料湖和資料倉庫的深入闡述和比較，本文認為資料湖和資料倉庫作為大資料系統的兩條不同演進路線，有各自特有的優勢和侷限性。資料湖和資料倉庫一個面向初創使用者友好，一個成長性更佳。對企業來說，資料湖和資料倉庫是否必須是一個二選一的選擇題？是否能有一種方案同時兼顧資料湖的靈活性和雲資料倉庫的成長性，將二者有效結合起來為使用者實現更低的總體擁有成本？

將數倉和資料湖融合在一起也是業界近年的趨勢，多個產品和專案都做過對應的嘗試：

數倉支援資料湖訪問

1. 2017 年 Redshift 推出 Redshift Spectrum，支援 Redsift 數倉使用者訪問 S3 資料湖的資料。
2. 2018 年阿里雲 MaxCompute 推出外包能力，支援訪問包括 OSS/OTS/RDS 資料庫在內的多種外部儲存。

但是無論是 Redshift Spectrum 還是 MaxCompute 的外部表，仍舊需要使用者在數倉中通過建立外部表來將資料湖的開放儲存路徑納入數倉的概念體系——由於一個單純的開放式儲存並不能自發描述其資料本身的變化，因此為這些資料建立外部表、新增分割槽（本質上是為資料湖中的資料建立 schema）無法完全自動化（需要人工或者定期觸發 Alter table add partition 或 msck）。這對於低頻臨時查詢尚能接受，對於生產使用來說，未免有些複雜。

資料湖支援數倉能力

2011 年，Hadoop 開源體系公司 Hortonworks 開始了 Apache Atlas 和 Ranger 兩個開源專案的開發，分別對應資料血緣追蹤和資料許可權安全兩個數倉核心能力。但兩個專案發展並不算順利，直到 2017 年才完成孵化，時至今日，在社群和工業界的部署都還遠遠不夠活躍。核心原因是資料湖具備與生俱來的靈活性。例如 Ranger 作為資料許可權安全統一管理的元件，天然要求所有引擎均適配它才能保證沒有安全漏洞，但對於資料湖中強調靈活的引擎，尤其是新引擎來說，會優先實現功能、場景，而不是把對接 Ranger 作為第一優先順序的目標，使得 Ranger 在資料湖上的位置一直很尷尬。

2018 年，Nexflix 開源了內部增強版本的元資料服務系統 Iceberg，提供包括 MVCC（多版本併發控制）在內的增強數倉能力，但因為開源 HMS 已經成為事實標準，開源版本的 Iceberg 作為外掛方式相容並配合 HMS，數倉管理能力大打折扣。

2018-2019 年，Uber 和 Databricks 相繼推出了 Apache Hudi 和 DeltaLake，推出增量檔案格式用以支援 Update/Insert、事務等資料倉庫功能。新功能帶來檔案格式以及組織形式的改變，打破了資料湖原有多套引擎之間關於共用儲存的簡單約定。為此，Hudi 為了維持相容性，不得不發明了諸如 Copy-On-Write、Merge-On-Read 兩種表，Snapshot Query、Incremental Query、Read Optimized Query 三種查詢型別，並給出了一個支援矩陣（如圖 9），極大提升了使用的複雜度。

圖 9. Hudi Support Matrix（來自網路）

而 DeltaLake 則選擇了保證以 Spark 為主要支援引擎的體驗，相對犧牲對其他主流引擎的相容性。這對其他引擎訪問資料湖中的 Delta 資料造成了諸多的限制和使用不便。例如 Presto 要使用 DeltaLake 表，需要先用 Spark 建立 manifest 檔案，再根據 manifest 建立外部表，同時還要注意 manifest 檔案的更新問題；而 Hive 要使用 DeltaLake 表限制更多，不僅會造成元資料層面的混亂，甚至不能寫表。

上述在資料湖架構上建立數倉的若干嘗試並不成功，這表明數倉和資料湖有本質的區別，在資料湖體系上很難建成完善的數倉。資料湖與資料倉庫兩者很難直接合併成一套系統，因此作者團隊，開始基於融合兩者的思路進行探索。提出下一代的大資料技術演進方向：湖倉一體，即打通資料倉庫和資料湖兩套體系，讓資料和計算在湖和倉之間自由流動，從而構建一個完整的有機的大資料技術生態體系。

我們認為，構建湖倉一體需要解決三個關鍵問題：

1. 湖和倉的資料 / 元資料無縫打通，且不需要使用者人工干預；
2. 湖和倉有統一的開發體驗，儲存在不同系統的資料，可以通過一個統一的開發 / 管理平臺操作；
3. 資料湖與資料倉庫的資料，系統負責自動 caching/moving，系統可以根據自動的規則決定哪些資料放在數倉，哪些保留在資料湖，進而形成一體化；我們將在下一章詳細介紹阿里雲湖倉一體方案如何解決這三個問題。

阿里雲湖倉一體方案

整體架構

阿里雲 MaxCompute 在原有的資料倉庫架構上，融合了開源資料湖和雲上資料湖，最終實現了湖倉一體化的整體架構（圖 10）。在該架構中，儘管底層多套儲存系統並存，但通過統一的儲存訪問層和統一的元資料管理，向上層引擎提供一體的封裝介面，使用者可以同時查詢資料倉庫和資料湖中的表。

圖 10. 阿里雲湖倉一體整體架構

針對上文提到的湖倉一體的三個關鍵問題，MaxCompute 實現了以下 4 個關鍵技術點。

快速接入

MaxCompute 全新自創 PrivateAccess 網路連通技術，在遵循雲虛擬網路安全標準的前提下，實現多租戶模式下特定使用者作業定向與 IDC/ECS/EMR Hadoop 叢集網路整體打通能力，具有低延遲、高獨享頻寬的特點。

經過快速簡單的開通、安全配置步驟即可將資料湖和購買的 MaxCompute 數倉相連通。

統一資料 / 元資料管理

MaxCompute 實現湖倉一體化的元資料管理，通過 DB 元資料一鍵對映技術，實現資料湖和 MaxCompute 數倉的元資料無縫打通，無須聯邦查詢方式裡的人工操作。MaxCompute 通過向用戶開放建立 external project 的形式，將資料湖 HiveMetaStore 中的整個 database 直接對映為 MaxCompute 的 project，對 Hive Database 的改動會實時反應在這個 project 中。與此同時，阿里雲 EMR 資料湖解決方案在今年雲棲大會也推出了 Data Lake Formation，湖倉一體方案也會支援對該資料湖中的統一元資料服務的一鍵對映能力。

MaxCompute 實現湖倉一體化的儲存訪問層，不僅支援內建優化的儲存系統，也無縫的支援外部儲存系統。既支援 HDFS 資料湖，也支援 OSS 雲端儲存資料湖，可讀寫各種開原始檔格式。

統一開發體驗

資料湖裡的 Hive DataBase 對映為 MaxCompute external project，和普通 project 別無二致，同樣享受 MaxCompute 數倉裡的資料開發、追蹤和管理功能。基於 DataWorks 強大的資料開發 / 管理 / 治理能力，提供統一的湖倉開發體驗，降低兩套系統的管理成本。

MaxCompute 高度相容 Hive/Spark，支援一套任務可以在湖倉兩套體系中靈活無縫的執行。

同時，MaxCompute 也提供高效的資料通道介面，可以讓資料湖中的 Hadoop 生態引擎直接訪問，提升了數倉的開放性。

自動數倉

構建湖倉一體化的資料中臺

基於 MaxCompute 湖倉一體技術，DataWorks 進一步對湖倉兩套系統進行封裝，遮蔽湖和倉異構叢集資訊，構建一體化的大資料中臺，實現一套資料、一套任務在湖和倉之上無縫排程和管理。

企業可以使用湖倉一體化的資料中臺能力，優化資料管理架構，充分融合資料湖和資料倉庫各自優勢。使用資料湖做集中式的原始資料儲存，發揮資料湖的靈活和開放優勢。又通過湖倉一體技術將面向生產的高頻資料和任務，無縫排程到資料倉庫中，以得到更好的效能和成本，以及後續一系列面向生產的資料治理和優化，最終讓企業在成本和效率之間找到最佳平衡。既適用於全新構建大資料平臺的企業，也適合已有大資料平臺的企業進行架構升級，可以保護現有投資和實現資產利舊。

圖 11. DataWorks 湖倉一體化資料中臺

新浪微博的”湖倉一體“應用

微博機器學習平臺團隊，主要做社交媒體領域裡的推薦主要做社交媒體領域裡的推薦 / 排序、文字 / 影象分類、反垃圾 / 反作弊等技術。技術架構上主要圍繞開源 Hadoop 資料湖解決方案，一份 HDFS 儲存 + 多種計算引擎（hive、spark、flink），以滿足以 AI 為主的多計算場景需求。

但微博作為國內 Top 的社交媒體應用，當前的業務體量和複雜性已然進入到開源“無人區”，開源資料湖方案在效能和成本方面都無法滿足微博的要求。微博藉助阿里巴巴飛天大資料和 AI 平臺能力（MaxCompute+PAI+DataWorks ），解決了超大規模下的特徵工程、模型訓練以及矩陣計算的效能瓶頸問題，進而形成了阿里巴巴 MaxCompute 平臺（數倉）+ 開源平臺（資料湖）共存的格局。

微博希望藉助這兩套異構的大資料平臺，既保持面向 AI 的各類資料和計算的靈活性，又解決超大規模下的計算和演算法的效能 / 成本問題。但因為這兩套大資料平臺在叢集層面完全是割裂的，資料和計算無法在兩個平臺裡自由流動，無形之中增加了大量的資料移動和計算開發等成本，進而制約了業務的發展。

主要的痛點是：

1. 安排專人專項負責訓練資料同步，工作量巨大；
2. 訓練資料體量大，導致耗時多，無法滿足實時訓練的要求；
3. 新寫 SQL 資料處理 query，無法複用 Hive SQL 原有 query。

圖 12. 新浪微博業務痛點示意圖

為了解決上述的痛點問題，阿里雲產品團隊和微博機器學習平臺團隊聯合共建湖倉一體新技術，打通了阿里巴巴 MaxCompute 雲數倉和 EMR Hadoop 資料湖，構建了一個跨湖和倉的 AI 計算中臺。MaxCompute 產品全面升級網路基礎設施，打通使用者 VPC 私域，且依託 Hive 資料庫一鍵對映和強大完善的 SQL/PAI 引擎能力，將 MaxCompute 雲數倉和 EMR Hadoop 資料湖技術體系無縫對接，實現湖和倉的統一且智慧化管理和排程。

圖 13. 微博湖倉一體架構圖

這套體系不僅融合了資料湖和資料倉庫的優勢，在靈活性和效率上找到最佳平衡，還快速構建了一套統一的 AI 計算中臺，極大提升該機器學習平臺團隊的業務支撐能力。無須進行資料搬遷和作業遷移，即可將一套作業無縫靈活排程在 MaxCompute 叢集和 EMR 叢集中。

SQL 資料處理任務被廣泛執行到 MaxCompute 叢集，效能有明顯提升。基於阿里巴巴 PAI 豐富且強大的演算法能力，封裝出多種貼近業務場景的演算法服務，滿足更多的業務需求。

MaxCompute 雲原生的彈性資源和 EMR 叢集資源形成互補，兩套體系之間進行資源的削峰填谷，不僅減少作業排隊，還能降低整體成本。

總 結

資料湖和資料倉庫，是在今天大資料技術條件下構建分散式系統的兩種資料架構設計取向，要看平衡的方向是更偏向靈活性還是成本、效能、安全、治理等企業級特性。但是資料湖和資料倉庫的邊界正在慢慢模糊，資料湖自身的治理能力、資料倉庫延伸到外部儲存的能力都在加強。

在這樣的背景之下，MaxCompute 率先提出湖倉一體，為業界和使用者展現了一種資料湖和資料倉湖互相補充，協同工作的架構。這樣的架構同時為使用者提供了資料湖的靈活性和資料倉庫的諸多企業級特性，將使用者使用大資料的總體擁有成本進一步降低，我們認為是下一代大資料平臺的演進方向。