01 大數據領域發展20年的變與不變

1.1 概述

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

1.數據保持高速增長- 從5V核心要素看，大數據領域保持高速增長。阿里巴巴經濟體，作為一個重度使用并著力發展大數據領域的公司，過去5年數據規模保持高速增長（年化60%-80%），增速在可見的未來繼續保持。對于新興企業，大數據領域增長超過年200%。

2.大數據作為新的生產要素，得到廣泛認可- 大數據領域價值定位的遷移，從“探索”到“普惠”，成為各個企業/政府的核心部門，并承擔關鍵任務。還是以阿里巴巴為例，30%的員工直接提交大數據作業。隨大數據普惠進入生產環境，可靠性、安全性、管控能力、易用性等企業級產品力增強。

3.數據管理能力成為新的關注點- 數倉（中臺）能力流行起來，如何用好數據成為企業的核心競爭力。

4.引擎技術進入收斂期- 隨著Spark（通用計算）、Flink（流計算）、Hbase（KV）、Presto（交互分析）、ElasticSearch（搜索）、Kafka（數據總線）自從2010-2015年逐步占領開源生態，最近5年新引擎開源越來越少，但各引擎技術開始向縱深發展（更好的性能、生產級別的穩定性等）。

5.平臺技術演進出兩個趨勢，數據湖VS 數據倉庫- 兩者均關注數據存儲和管理（平臺技術），但方向不同。

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

1.2 從大數據技術發展看湖和倉

首先，數據倉庫的概念出現的要比數據湖早的多，可以追溯到數據庫為王的上世紀 90 年代。因此，我們有必要從歷史的脈絡來梳理這些名詞出現的大概時間、來由以及更重要的背后原因。大體上，計算機科學領域的數據處理技術的發展，主要分為四個階段：

1. 階段一：數據庫時代。數據庫最早誕生于 20 世紀的 60 年代，今天人們所熟知的關系型數據庫則出現在 20 世紀 70 年代，并在后續的 30 年左右時間里大放異彩，誕生了很多優秀的關系型數據庫，如 Oracle、SQL Server、MySQL、PostgresSQL 等，成為當時主流計算機系統不可或缺的組成部分。到 20 世紀 90 年代，數據倉庫的概念誕生。

此時的數據倉庫概念更多表達的是如何管理企業中多個數據庫實例的方法論，但受限于單機數據庫的處理能力以及多機數據庫（分庫分表）長期以來的高昂價格，此時的數據倉庫距離普通企業和用戶都還很遙遠。人們甚至還在爭論數據倉庫（統一集中管理）和數據集市（按部門、領域的集中管理）哪個更具可行性。

2. 階段二：大數據技術的「探索期」。時間進入到 2000 年附近，隨著互聯網的爆發，動輒幾十億、上百億的頁面以及海量的用戶點擊行為，開啟了全球的數據量急劇增加的新時代。

傳統的數據庫方案再也無力以可接受的成本提供計算力，巨大的數據處理需求開始尋找突破口，大數據時代開始萌芽。2003、2004、2006 年 Google 先后 3 篇經典論文（GFS、MapReduce、BigTable）奠基了這個大數據時代的基本技術框架，即分布式存儲、分布式調度以及分布式計算模型。

隨后，幾乎是在同一時期，誕生了包括 Google，微軟 Cosmos 以及開源 Hadoop 為代表的優秀分布式技術體系，當然，這其中也包括阿里巴巴的飛天系統。此時人們興奮于追求數據的處理規模，即『大』數據，沒有閑暇爭論是數據倉庫還是數據湖。

3. 階段三：大數據技術的「發展期」。來到 21 世紀的第二個 10 年，隨著越來越多的資源投入到大數據計算領域，大數據技術進入一個蓬勃發展的階段，整體開始從能用轉向好用。

代替昂貴的手寫 MapReduce 作業的，則是如雨后春筍般出現的各種以 SQL 為表達的計算引擎。這些計算引擎針對不同的場景進行針對性優化，但都采用門檻極低的 SQL 語言，極大降低了大數據技術的使用成本，數據庫時代人們夢想的大一統的數據倉庫終于成為現實，各種數據庫時代的方法論開始抬頭。這個時期技術路線開始出現細分。

云廠商主推的如 AWS Redshift、Google BigQuery、Snowflake，包括 MaxCompute 這樣的集成系統稱為大數據時代的數據倉庫。而以開源 Hadoop 體系為代表的的開放式 HDFS 存儲、開放的文件格式、開放的元數據服務以及多種引擎（Hive、Presto、Spark、Flink 等）協同工作的模式，則形成了數據湖的雛形。

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

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

真正將數據湖概念推而廣之的是AWS。AWS 構筑了一套以 S3 為中心化存儲、Glue 為元數據服務，E-MapReduce、Athena 為引擎的開放協作式的產品解決方案。它的開放性和和開源體系類似，并在2019年推出Lake Formation 解決產品間的安全授信問題。雖然這套架構在企業級能力上和相對成熟的云數據倉庫產品相去甚遠，但對于開源技術體系的用戶來說，架構相近理解容易，還是很有吸引力。AWS 之后，各個云廠商也紛紛跟進數據湖的概念，并在自己的云服務上提供類似的產品解決方案。

云廠商主推的數據倉庫類產品則發展良好，數倉核心能力方面持續增強。性能、成本方面極大提升（MaxCompute 完成了核心引擎的全面升級和性能跳躍式發展，連續三年刷新 TPCx-BigBench 世界記錄），數據管理能力空前增強（數據中臺建模理論、智能數倉），企業級安全能力大為繁榮（同時支持基于 ACL 和基于規則等多種授權模型，列級別細粒度授權，可信計算，存儲加密，數據脫敏等），在聯邦計算方面也普遍做了增強，一定程度上開始將非數倉自身存儲的數據納入管理，和數據湖的邊界日益模糊。

綜上所述，數據倉庫是個誕生于數據庫時代的概念，在大數據時代隨云廠商的各種數倉服務落地開花，目前通常指代云廠商提供的基于大數據技術的一體化服務。而數據湖則脫胎于大數據時代開源技術體系的開放設計，經過 AWS 整合宣傳，通常是由一系列云產品或開源組件共同構成大數據解決方案。

圖2. 20年大數據發展之路

02 什么是數據湖

近幾年數據湖的概念非常火熱，但是數據湖的定義并不統一，我們先看下數據湖的相關定義。

Wikipedia對數據湖的定義： 數據湖是指使用大型二進制對象或文件這樣的自然格式儲存數據的系統。它通常把所有的企業數據統一存儲，既包括源系統中的原始副本，也包括轉換后的數據，比如那些用于報表, 可視化, 數據分析和機器學習的數據。數據湖可以包括關系數據庫的結構化數據(行與列)、半結構化的數據(CSV，日志，XML, JSON)，非結構化數據 (電子郵件、文件、PDF)和 二進制數據(圖像、音頻、視頻)。儲存數據湖的方式包括 Apache Hadoop分布式文件系統， Azure 數據湖或亞馬遜云 Lake Formation云存儲服務，以及諸如 Alluxio 虛擬數據湖之類的解決方案。數據沼澤是一個劣化的數據湖，用戶無法訪問，或是沒什么價值。

AWS的定義相對簡潔： 數據湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化數據。您可以按原樣存儲數據（無需先對數據進行結構化處理），并運行不同類型的分析 – 從控制面板和可視化到大數據處理、實時分析和機器學習，以指導做出更好的決策。 Azure等其他云廠商也有各自的定義，本文不再贅述。 但無論數據湖的定義如何不同，數據湖的本質其實都包含如下四部分： 1.統一的存儲系統 2.存儲原始數據 3.豐富的計算模型/范式 4.數據湖與上云無關 從上述四個標準判斷，開源大數據的Hadoop HDFS存儲系統就是一個標準的數據湖架構，具備統一的原始數據存儲架構。而近期被廣泛談到的數據湖，其實是一個狹義的概念，特指“基于云上托管存儲系統的數據湖系統，架構上采用存儲計算分離的體系”。例如基于AWS S3系統或者阿里云OSS系統構建的數據湖。 下圖是數據湖技術架構的演進過程，整體上可分為三個階段：

圖3. 數據湖技術架構演進

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

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

3. 階段三：云上數據湖架構，即云上純托管的存儲系統逐步取代HDFS，成為數據湖的存儲基礎設施，并且引擎豐富度也不斷擴展。除了Hadoop和Spark的生態引擎之外，各云廠商還發展出面向數據湖的引擎產品。 如分析類的數據湖引擎有AWS Athena和華為DLI，AI類的有AWS Sagemaker。這個架構仍然保持了一個存儲和多個引擎的特性，所以統一元數據服務至關重要，如AWS推出了Glue，阿里云EMR近期也即將發布數據湖統一元數據服務。該架構相對于原生HDFS的數據湖架構的優勢在于：

幫助用戶擺脫原生HDFS系統運維困難的問題。HDFS系統運維有兩個困難：1）存儲系統相比計算引擎更高的穩定性要求和更高的運維風險 2）與計算混布在一起，帶來的擴展彈性問題。存儲計算分離架構幫助用戶解耦存儲，并交由云廠商統一運維管理，解決了穩定性和運維問題。

分離后的存儲系統可以獨立擴展，不再需要與計算耦合，可降低整體成本

當用戶采用數據湖架構之后，客觀上也幫助客戶完成了存儲統一化（解決多個HDFS數據孤島的問題）

下圖是阿里云EMR數據湖架構圖，它是基于開源生態的大數據平臺，既支持HDFS的開源數據湖，也支持OSS的云上數據湖。

圖4. 阿里云EMR數據湖架構 企業使用數據湖技術構建大數據平臺，主要包括數據接入、數據存儲、計算和分析、數據管理、權限控制等，下圖是Gartner定義的一個參考架構。當前數據湖的技術因其架構的靈活性和開放性，在性能效率、安全控制以及數據治理上并不十分成熟，在面向企業級生產要求時還存在很大挑戰（在第四章會有詳細的闡述）。

圖5. 數據湖架構圖（來自網絡）

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

Wikipedia對數據倉庫的定義： 在計算機領域，數據倉庫（英語：data warehouse，也稱為企業數據倉庫）是用于報告和數據分析的系統，被認為是商業智能的核心組件。數據倉庫是來自一個或多個不同源的集成數據的中央存儲庫。數據倉庫將當前和歷史數據存儲在一起，用于為整個企業的員工創建分析報告。 比較學術的解釋是，數據倉庫由數據倉庫之父W.H.Inmon于1990年提出，主要功能乃是將組織透過信息系統之在線交易處理(OLTP)經年累月所累積的大量數據，透過數據倉庫理論所特有的數據存儲架構，作一有系統的分析整理，以利各種分析方法如在線分析處理(OLAP)、數據挖掘(Data Mining)之進行，并進而支持如決策支持系統(DSS)、主管信息系統(EIS)之創建，幫助決策者能快速有效的自大量數據中，分析出有價值的信息，以利決策擬定及快速回應外在環境變動，幫助建構商業智能(BI)。

數據倉庫的本質包含如下三部分： 1. 內置的存儲系統，數據通過抽象的方式提供（例如采用Table或者View），不暴露文件系統。 2.數據需要清洗和轉化，通常采用ETL/ELT方式 3.強調建模和數據管理，供商業智能決策 從上述的標準判斷，無論傳統數據倉庫（如Teradata）還是新興的云數據倉庫系統（AWS Redshift、Google BigQuery、阿里云MaxCompute）均體現了數倉的設計本質，它們均沒有對外暴露文件系統，而是提供了數據進出的服務接口。 比如，Teradata提供了CLI數據導入工具，Redshift提供Copy命令從S3或者EMR上導入數據，BigQuery提供Data Transfer服務，MaxCompute提供Tunnel服務以及MMA搬站工具供數據上傳和下載。這個設計可以帶來多個優勢： 1.引擎深度理解數據，存儲和計算可做深度優化 2.數據全生命周期管理，完善的血緣體系 3.細粒度的數據管理和治理 4.完善的元數據管理能力，易于構建企業級數據中臺 正因為如此，阿里巴巴飛天大數據平臺建設之初，在選型的時候就采用了數據倉庫的架構，即MaxCompute大數據平臺。MaxCompute（原ODPS)，既是阿里巴巴經濟體的大數據平臺，又是阿里云上的一種安全可靠、高效能、低成本、從GB到EB級別按需彈性伸縮的在線大數據計算服務（圖6.是MaxCompute產品架構，具體詳情請點擊阿里云MaxCompute官網地址）。 作為SaaS模式的企業級云數倉，MaxCompute廣泛應用在阿里巴巴經濟體、以及阿里云上互聯網、新金融、新零售、數字政府等數千家客戶。

圖6. MaxCompute云數倉產品架構 得益于MaxCompute數據倉庫的架構，阿里巴巴上層逐步構建了“數據安全體系”、“數據質量”、“數據治理”、“數據標簽”等管理能力，并最終形成了阿里巴巴的大數據中臺。可以說，作為最早數據中臺概念的提出者，阿里巴巴的數據中臺得益于數據倉庫的架構。

圖7. 阿里巴巴數據中臺架構

04 數據湖VS 數據倉庫

綜上，數據倉庫和數據湖，是大數據架構的兩種設計取向。兩者在設計的根本分歧點是對包括存儲系統訪問、權限管理、建模要求等方面的把控。 數據湖優先的設計，通過開放底層文件存儲，給數據入湖帶來了最大的靈活性。進入數據湖的數據可以是結構化的，也可以是半結構化的，甚至可以是完全非結構化的原始日志。另外，開放存儲給上層的引擎也帶來了更多的靈活度，各種引擎可以根據自己針對的場景隨意讀寫數據湖中存儲的數據，而只需要遵循相當寬松的兼容性約定（這樣的松散約定當然會有隱患，后文會提到）。

但同時，文件系統直接訪問使得很多更高階的功能很難實現，例如，細粒度（小于文件粒度）的權限管理、統一化的文件管理和讀寫接口升級也十分困難（需要完成每一個訪問文件的引擎升級，才算升級完畢）。 而數據倉庫優先的設計，更加關注的是數據使用效率、大規模下的數據管理、安全/合規這樣的企業級成長性需求。數據經過統一但開放的服務接口進入數據倉庫，數據通常預先定義 schema，用戶通過數據服務接口或者計算引擎訪問分布式存儲系統中的文件。 數據倉庫優先的設計通過抽象數據訪問接口/權限管理/數據本身，來換取更高的性能（無論是存儲還是計算）、閉環的安全體系、數據治理的能力等，這些能力對于企業長遠的大數據使用都至關重要，我們稱之為成長性。 下圖是針對大數據技術棧，分別比較數據湖和數據倉庫各自的取舍。

圖8. 數據湖和數據倉庫在技術棧上的對比 靈活性和成長性，對于處于不同時期的企業來說，重要性不同。 1. 當企業處于初創階段，數據從產生到消費還需要一個創新探索的階段才能逐漸沉淀下來，那么用于支撐這類業務的大數據系統，靈活性就更加重要，數據湖的架構更適用。 2. 當企業逐漸成熟起來，已經沉淀為一系列數據處理流程，問題開始轉化為數據規模不斷增長，處理數據的成本不斷增加，參與數據流程的人員、部門不斷增多，那么用于支撐這類業務的大數據系統，成長性的好壞就決定了業務能夠發展多遠。數據倉庫的架構更適用。 本文有觀察到，相當一部分企業（尤其是新興的互聯網行業）從零開始架構的大數據技術棧，正是伴隨開源 Hadoop 體系的流行，經歷了這樣一個從探索創新到成熟建模的過程。在這個過程中，因為數據湖架構太過靈活而缺少對數據監管、控制和必要的治理手段，導致運維成本不斷增加、數據治理效率降低，企業落入了『數據沼澤』的境地，即數據湖中匯聚了太多的數據，反而很難高效率的提煉真正有價值的那部分。 最后只有遷移到數據倉庫優先設計的大數據平臺，才解決了業務成長到一定規模后所出現的運維、成本、數據治理等問題。還是舉阿里巴巴的例子，阿里巴巴成功的數據中臺戰略，正是在 2015 年前后阿里巴巴全集團完成 MaxCompute（數據倉庫） 對多個 Hadoop（ 數據湖）的完全替換（登月項目）才逐步形成的。

圖9.數據湖的靈活性 VS 數據倉庫的成長性的示意圖

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

經過對數據湖和數據倉庫的深入闡述和比較，本文認為數據湖和數據倉庫作為大數據系統的兩條不同演進路線，有各自特有的優勢和局限性。 數據湖和數據倉庫一個面向初創用戶友好，一個成長性更佳。對企業來說，數據湖和數據倉庫是否必須是一個二選一的選擇題？是否能有一種方案同時兼顧數據湖的靈活性和云數據倉庫的成長性，將二者有效結合起來為用戶實現更低的總體擁有成本？ 將數倉和數據湖融合在一起也是業界近年的趨勢，多個產品和項目都做過對應的嘗試：

1.數倉支持數據湖訪問

2017年Redshift推出Redshift Spectrum，支持Redsift數倉用戶訪問S3數據湖的數據。

2018年阿里云MaxCompute推出外表能力，支持訪問包括OSS/OTS/RDS數據庫在內的多種外部存儲。

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

2.數據湖支持數倉能力

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 三種查詢類型，并給出了一個支持矩陣（如圖10），極大提升了使用的復雜度。

圖10. Hudi Support Matrix（來自網絡） 而DeltaLake則選擇了保證以Spark為主要支持引擎的體驗，相對犧牲對其他主流引擎的兼容性。這對其他引擎訪問數據湖中的Delta數據造成了諸多的限制和使用不便。例如Presto要使用DeltaLake表，需要先用Spark創建manifest文件，再根據manifest創建外部表，同時還要注意manifest文件的更新問題；而Hive要使用DeltaLake表限制更多，不僅會造成元數據層面的混亂，甚至不能寫表。 上述在數據湖架構上建立數倉的若干嘗試并不成功，這表明數倉和數據湖有本質的區別，在數據湖體系上很難建成完善的數倉。數據湖與數據倉庫兩者很難直接合并成一套系統，因此作者團隊，開始基于融合兩者的思路進行探索。 所以我們提出下一代的大數據技術演進方向：湖倉一體，即打通數據倉庫和數據湖兩套體系，讓數據和計算在湖和倉之間自由流動，從而構建一個完整的有機的大數據技術生態體系。 我們認為，構建湖倉一體需要解決三個關鍵問題： 1.湖和倉的數據/元數據無縫打通，且不需要用戶人工干預 2.湖和倉有統一的開發體驗，存儲在不同系統的數據，可以通過一個統一的開發/管理平臺操作 3.數據湖與數據倉庫的數據，系統負責自動caching/moving，系統可以根據自動的規則決定哪些數據放在數倉，哪些保留在數據湖，進而形成一體化 我們將在下一章詳細介紹阿里云湖倉一體方案如何解決這三個問題。

06 阿里云湖倉一體方案

6.1 整體架構

阿里云MaxCompute在原有的數據倉庫架構上，融合了開源數據湖和云上數據湖，最終實現了湖倉一體化的整體架構（圖11）。 在該架構中，盡管底層多套存儲系統并存，但通過統一的存儲訪問層和統一的元數據管理，向上層引擎提供一體的封裝接口，用戶可以聯合查詢數據倉庫和數據湖中的表。整體架構還具備統一的數據安全、管理和治理等中臺能力。

圖11. 阿里云湖倉一體整體架構 針對第五章提出的湖倉一體的三個關鍵問題，MaxCompute實現了以下4個關鍵技術點。

1.快速接入

MaxCompute全新自創PrivateAccess網絡連通技術，在遵循云虛擬網絡安全標準的前提下，實現多租戶模式下特定用戶作業定向與IDC/ECS/EMR Hadoop集群網絡整體打通能力，具有低延遲、高獨享帶寬的特點。 經過快速簡單的開通、安全配置步驟即可將數據湖和購買的 MaxCompute數倉相連通。

2.統一數據/元數據管理

MaxCompute實現湖倉一體化的元數據管理，通過DB元數據一鍵映射技術，實現數據湖和MaxCompute數倉的元數據無縫打通。MaxCompute通過向用戶開放創建external project的形式，將數據湖HiveMetaStore中的整個database直接映射為MaxCompute的project，對Hive Database的改動會實時反應在這個project中，并可以在MaxCompute側隨時通過這個project進行訪問、計算其中的數據。與此同時，阿里云EMR數據湖解決方案也將推出Data Lake Formation，MaxCompute湖倉一體方案也會支持對該數據湖中的統一元數據服務的一鍵映射能力。MaxCompute側對external project的各種操作，也會實時反應在Hive側，真正實現數據倉庫和數據湖之間的無縫聯動，完全不需要類似聯邦查詢方案里的元數據人工干預步驟。 MaxCompute實現湖倉一體化的存儲訪問層，不僅支持內置優化的存儲系統，也無縫的支持外部存儲系統。既支持HDFS數據湖，也支持OSS云存儲數據湖，可讀寫各種開源文件格式。

3.統一開發體驗

數據湖里的Hive DataBase映射為MaxCompute external project，和普通project別無二致，同樣享受MaxCompute數倉里的數據開發、追蹤和管理功能。基于DataWorks強大的數據開發/管理/治理能力，提供統一的湖倉開發體驗，降低兩套系統的管理成本。 MaxCompute高度兼容Hive/Spark，支持一套任務可以在湖倉兩套體系中靈活無縫的運行。 同時，MaxCompute也提供高效的數據通道接口，可以讓數據湖中的Hadoop生態引擎直接訪問，提升了數倉的開放性。

4.自動數倉

湖倉一體需要用戶根據自身資產使用情況將數據在湖和倉之間進行合理的分層和存儲，以最大化湖和倉的優勢。MaxCompute開發了一套智能cache技術，根據對歷史任務的分析來識別數據冷熱度，從而自動利用閑時帶寬將數據湖中的熱數據以高效文件格式cache在數據倉庫中，進一步加速數據倉庫的后續數據加工流程。不僅解決了湖倉之間的帶寬瓶頸問題，也達到了無須用戶參與即可實現數據分層管理/治理以及性能加速的目的。

6.2 構建湖倉一體化的數據中臺

基于MaxCompute湖倉一體技術，DataWorks可以進一步對湖倉兩套系統進行封裝，屏蔽湖和倉異構集群信息，構建一體化的大數據中臺，實現一套數據、一套任務在湖和倉之上無縫調度和管理。 企業可以使用湖倉一體化的數據中臺能力，優化數據管理架構，充分融合數據湖和數據倉庫各自優勢。使用數據湖做集中式的原始數據存儲，發揮數據湖的靈活和開放優勢。 又通過湖倉一體技術將面向生產的高頻數據和任務，無縫調度到數據倉庫中，以得到更好的性能和成本，以及后續一系列面向生產的數據治理和優化，最終讓企業在成本和效率之間找到最佳平衡。 總體來說，MaxCompute湖倉一體為企業提供了一種更靈活更高效更經濟的數據平臺解決方案，既適用于全新構建大數據平臺的企業，也適合已有大數據平臺的企業進行架構升級，可以保護現有投資和實現資產利舊。

圖12. DataWorks湖倉一體化數據中臺

6.3 典型客戶案例：新浪微博應用「湖倉一體」構建混合云AI計算中臺

案例背景

微博機器學習平臺團隊，主要做社交媒體領域里的推薦主要做社交媒體領域里的推薦/排序、文本/圖像分類、反垃圾/反作弊等技術。 技術架構上主要圍繞開源Hadoop數據湖解決方案，一份HDFS存儲+多種計算引擎（hive、spark、flink），以滿足以AI為主的多計算場景需求。但微博作為國內Top的社交媒體應用，當前的業務體量和復雜性已然進入到開源“無人區”，開源數據湖方案在性能和成本方面都無法滿足微博的要求。 微博借助阿里巴巴強大的飛天大數據和AI平臺能力（MaxC+PAI+DW ），解決了超大規模下的特征工程、模型訓練以及矩陣計算的性能瓶頸問題，進而形成了阿里巴巴MaxCompute平臺（數倉）+ 開源平臺（數據湖）共存的格局。

核心痛點

微博希望借助這兩套異構的大數據平臺，既保持面向AI的各類數據和計算的靈活性，又解決超大規模下的計算和算法的性能/成本問題。但因為這兩套大數據平臺在集群層面完全是割裂的，數據和計算無法在兩個平臺里自由流動，無形之中增加了大量的數據移動和計算開發等成本，進而制約了業務的發展。 主要的痛點是：1）安排專人專項負責訓練數據同步，工作量巨大 2） 訓練數據體量大，導致耗時多，無法滿足實時訓練的要求 3） 新寫SQL數據處理query，無法復用Hive SQL原有query。

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

解決方案

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

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

案例價值

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

SQL數據處理任務被廣泛運行到MaxCompute集群，性能有明顯提升。基于阿里巴巴PAI豐富且強大的算法能力，封裝出多種貼近業務場景的算法服務，滿足更多的業務需求。

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

07 總結

數據湖和數據倉庫，是在今天大數據技術條件下構建分布式系統的兩種數據架構設計取向，要看平衡的方向是更偏向靈活性還是成本、性能、安全、治理等企業級特性。 但是數據湖和數據倉庫的邊界正在慢慢模糊，數據湖自身的治理能力、數據倉庫延伸到外部存儲的能力都在加強。在這樣的背景之下，MaxCompute 率先提出湖倉一體，為業界和用戶展現了一種數據湖和數據倉湖互相補充，協同工作的架構。 這樣的架構同時為用戶提供了數據湖的靈活性和數據倉庫的諸多企業級特性，將用戶使用大數據的總體擁有成本進一步降低，我們認為是下一代大數據平臺的演進方向。

編輯：黃飛