本文主要分為四個部分：

一、湖倉融合的趨勢分析

二、阿里雲湖倉一體

三、客戶案例分析

四、湖倉一體演示

一、 湖倉融合的趨勢分析

現在很多企業說不清楚現有大資料系統是資料湖還是資料倉庫，所以先帶著大家一起回顧一下。過去20年，整個大資料技術發展的過程，透過這樣一個剖析，希望能夠讓大家理解，資料湖和資料倉庫到底是一個什麼樣的系統，它們是因為什麼原因產生的，並且今天我們提的湖倉一體，它出現的一個背景是什麼。縱觀整個計算機科學技術領域，對於資料處理的技術主要分為四個階段，資料庫階段、大資料技術探索階段、大資料技術發展階段、大資料普惠階段。

資料庫階段主要是在上個世紀70年代至90年代期間，這個階段主要是資料庫加單機的黃金時代。資料庫系統主要是面向操作，面向事務，面向線上業務系統的一個數據系統。其實在90年代左右，資料倉庫概念就已經出現了。資料倉庫面向的是歷史全量資料分析，探查，但因為當時的整體資料量並不大，所以用一些資料庫技術的擴充套件，能夠支援當時資料倉庫的需求。

2000年左右，隨著網際網路技術的爆發，我們迎來了大資料時代。在這個階段，我們用傳統資料庫的技術是很難滿足海量資料處理的需求。大家應該都知道，Google的三篇論文，分散式儲存、排程、計算，奠定了整個大資料技術的基礎。基本上在同一個時期，2006年出現了Hadoop的系統，阿里巴巴在2009年發展出了飛天系統，包括微軟等頭部公司都發展出了比較優秀的分散式系統。整個這個階段，整個大資料的技術，其實是把資料做起來，資料大起來再說。

2010年左右，進入了大資料的一個蓬勃發展階段，這個階段是之前我們希望大資料技術從能用轉變為好用。這個階段出現了一系列以SQL表達為主的一些引擎，包括Hadoop體系發展出來Hive、Flink、Presto等一系列引擎。這個時候，逐漸形成了以HDFS為統一的儲存，以ORC、Parquet 為開放的檔案格式，上面有很多開放引擎為主的一個體系，這個體系像我們今天講的資料湖系統。這個階段，Hadoop的本質其實是一個數據湖系統。那資料湖的本質是什麼？本質是統一的儲存，能夠儲存原始的資料，能夠支援多種計算正規化，這就是資料湖的本質。

同一時期，阿里巴巴在飛天系統的基礎上釋出了 MaxCompute ，Google 釋出了Big Query，AWS 釋出了Redshift。這幾個系統可以稱之為大資料時代下的雲資料倉庫。那雲資料倉庫系統跟上述Hadoop體系有什麼區別呢？雲資料倉庫並不對外暴露檔案系統，暴露的是對資料的描述，用表的方式，用檢視的方式暴露出來。儲存引擎，計算引擎是被遮蔽在系統裡面的，所以儲存引擎，計算引擎可以進行深度的最佳化，然而使用者是沒有辦法感知的。這個階段可以看出來，整個大資料技術已經開始細分，已經初步的形成了湖的形態和倉的形態。

現在我們所處的這個階段，也就是2015年左右，我們進入了大資料普惠階段。這個階段我們有觀察到兩個趨勢。第一個趨勢，大資料技術的發展除了追求規模，效能之外。更多的是看資料安全、資料治理、穩定性、低成本等企業級能力。我們也可以看出來，阿里巴巴 基於MaxCompute ，構建出了非常有阿里特色的資料中臺系統。開源體系，也發展出了Atlas和Ranger，主要圍繞血緣、治理、安全等開源專案。第二個趨勢，隨著AI、IOT、雲原生技術的發展，對於非結構化資料處理的需求越來越強烈。使用雲上物件儲存作為統一儲存的趨勢越來越明顯。Hadoop的體系也逐漸由HDFS為統一儲存，發展為雲上像S3、OSS這樣的雲端儲存，做為統一儲存的資料湖體系。與此同時，出現了很多資料湖構建，像AWS Lake Formation以及阿里雲釋出的DLF這樣的產品。倉的這條線，也在為了適應這樣一個趨勢，我們也在跟資料湖做很密切的聯動，發展出了外表，透過外表的方式，可以對資料庫裡面的資料進行聯邦計算。

縱觀整個20年的發展，隨著大資料技術的演進，其實是發展出來了倉跟湖的兩種體系。

我們可以用下圖這張表來對比一下資料湖跟資料倉庫到底有什麼區別。

整體上來說，資料湖是一個寬進寬出，相對協同比較松耦合的系統。資料倉庫是一個嚴進嚴出，比較嚴格緊耦合的系統。資料湖是資料先進來，然後再開始用，所以是屬於事後建模。可以儲存結構化、半結構化、非結構化資料。資料湖是提供了一套標準的開放介面，來支援更多的引擎，像插拔式的插到這個體系裡面，所以它是向所有的引擎開放。但是這裡要注意了，正是因為它是插拔式的這種方式，計算跟儲存其實是獨立的兩套系統。它們彼此之間，其實是不能夠相互理解的，也沒有辦法做到深度的最佳化。這樣其實導致，引擎的最佳化只能做到適度有限最佳化。資料湖易於啟動，但是隨著資料規模的增長，一系列的治理管理的問題出現，後期是比較難以運維的。因為資料湖不做Schema的強一致的資料檢查，所以資料治理比較低，難管理使用。因為資料湖的資料是先進來再使用，所以它更適合解決未知的問題，比如探查類的分析，科學計算，資料探勘等計算處理。

資料倉庫在對比維度裡基本都是相反的狀態，資料倉庫是一個嚴格的系統，所以需要事前建模，資料經過轉化清洗進到倉裡面，儲存型別變為結構化或者半結構化。因為資料倉庫是一個相對封閉的系統，是一個自閉環的系統，所以資料倉庫向特定引擎開放，但是恰恰因為資料倉庫是一個自閉環系統，它的計算引擎、儲存引擎、元資料之間是可以做到非常深度、垂直的最佳化，可以獲得一個非常好的效能。資料倉庫因為事前建模，資料才能進來，所以難啟動，相對來講啟動成本較高。但一旦資料進入數倉之後，整個資料的高質量，方便做治理，這個時候它的整體成本會降低，甚至達到一個免運維的狀態。資料倉庫的Schema會做強一致的檢查，所以資料質量很高，易於使用。所以資料倉庫的計算負載天然的適合做離線計算，互動式計算以及BI和視覺化。

整體上來講，資料湖更偏靈活性，資料倉庫更偏企業級能力。那麼這兩種特點對於企業到底意味著什麼呢？我們用下面這張圖來表示。

橫軸是代表企業的業務規模，縱軸是代表企業搭建一套大資料系統所需要的成本。在企業初創的時候，整個業務規模還不大，資料從產生到消費的整個鏈路，是一個探索和創新的階段。在這個階段使用資料湖是非常容易啟動，成本也是比較低的。但是隨著業務的發展和壯大，參與的人員和部門越來越多，對於資料質量管理、許可權控制、成本要求會越來越高。這個時候再使用資料湖，成本是指數級上升。所以這個時候適合用資料倉庫，可以做好成本控制、資料質量管理等。從上圖可以看出，對於一個企業來講，在不同的階段，資料湖和資料倉庫都發揮著各自關鍵的作用。那是否有一種技術或者架構能同時發揮出兩者的優勢呢？

以阿里雲對業界的觀察和本身大量的實踐，我們認為資料湖和資料倉庫正在發生融合。並且它們以各自的方式，向著湖倉一體的方向進行演進。從上圖中可以看出，資料倉庫到湖倉一體的演進方向，資料湖到湖倉一體的演進方向，兩者是相反的，相對的。那麼在它們各自的演進上面需要做什麼工作呢？

資料倉庫是一個嚴格的系統，所以資料倉庫更適合做事務支援，Schema強一致檢查和演進，天然支援BI，更容易做實時性。對於資料湖，優勢在於資料型別豐富，支援多種計算模式，有開放的檔案系統，開放的檔案格式，是儲存計算分離的架構。

所以資料倉庫到湖倉一體的演進，需要從本身擁有的特性發展出資料湖的特性。其實是要跟HDFS、OSS這樣的系統做好聯動，做好融合，所以資料倉庫的結構更偏左右結構。對於資料湖到湖倉一體的演進，是需要更多的站在HDFS、OSS基礎上面，來做出強倉的特性。所以資料湖的結構更像一個上下結構。那麼，DeltaLake和Hudi其實就是在上下結構當中插了一層，做了一個湖上面的，能夠支援強倉的檔案型別。

但不管是資料倉庫到湖倉一體，還是資料湖到湖倉一體，最終大家演進的這個方向都是一致的，都是湖倉一體。湖倉一體的特性是不變的，四種偏倉的特性，四種偏湖的特性。

二、阿里雲湖倉一體

上圖為阿里雲湖倉一體整體架構，從下往上看，底層是網路層，中間層為湖倉引擎層，在往上是DataWorks 湖倉資料開發層，最上面是業務應用層。我們重點來講下引擎層，阿里雲湖倉一體是左右結構，左邊是阿里雲資料倉庫 MaxCompute，右邊是阿里雲資料湖 EMR，中間是透過元資料的統一，透過開放格式相容，以達到資料跟任務可以在資料倉庫和資料湖之間的任意流動。在2020年雲棲大會上釋出的是，對於Hadoop資料湖的支援。近期我們已經支援了OSS 資料湖的湖倉一體。

上圖右側是列出來一些我們近期釋出的具體功能點。

1。支援雲原生資料湖

MaxCompute 對接了阿里雲資料湖構建產品DLF，可以做到元資料的自動發現，做到湖/倉元資料統一儲存和管理。

2。對於資料湖查詢更好的效能

近期阿里雲正在灰度一個功能，智慧Cache，此功能可以實現OSS到倉裡面智慧化的資料分層。MaxCompute 在2020年釋出了查詢加速功能，未來一個版本我們會把查詢加速引擎也投射到資料湖上面，讓它能夠支援資料湖上面的查詢加速。

3。生態開放性

近期已支援Delta Lake開原始檔格式。

4。DataWorks 統一的資料開發平臺

DataWorks支援多引擎，提供了湖倉一體開發體驗。

不管是從上下結構還是左右結構演進過來的湖倉一體，最終都應該是一個簡單易用的系統體系。阿里雲湖倉一體有四大關鍵特性，這四大關鍵特性都是在圍繞怎麼把資料湖跟資料倉庫做到更加易用。

快速接入

主要有兩個層次，一個是網路層，一個是湖倉一體的開通層。MaxCompute 支援雲上雲下任何環境下Hadoop體系的打通，因為MaxCompute 自有的多租戶體系，如何跟特定的一個使用者環境打通，技術方面有很大的挑戰，我們研發了PrivateAccess網路連通技術，來達到這個目標。第二個關於DataWorks白屏操作自助開通湖倉一體，未來我們會很快釋出一個版本，使用者在控制檯裡面就可以很快開通湖倉一體，目前還是需要用工單方式來提交開通。

2。 統一的資料/元資料

其中關鍵的技術是，有一個Database級別的元資料對映，就是我們可以把資料湖上面的Database對映成MaxCompute 裡面的一個Project。資料湖上面的資料不需要移動，就可以讓 MaxCompute 像訪問操作普通Project一樣進行消費。同時做到資料湖和資料倉庫的資料/元資料做到實時同步，如果資料湖內的一張表資料或者Schema發生變化，可以及時的反應在 MaxCompute 數倉這一側。同時 MaxCompute 具備內建的儲存跟檔案格式，我們也在持續的跟進開源生態內的檔案格式，包含上文提到的Delta Lake。

3。 提供統一的開發體驗

資料湖和資料倉庫本身是兩套不同的系統，兩個系統有不同的資料庫模型的定義，物件模型的定義，我們在MaxCompute 這一側，把資料湖跟資料倉庫的物件模型進行了統一，再加上 MaxCompute 的SQL和Spark是高度相容社群的，所以我們可以做到作業在兩套系統內，無縫遷移。

4。 自動數倉

這條線比較有意思，也是我們近期重點投入領域。我們去年做了一版Cache，主要是根據歷史資料做Cache，今年我又做了一版Cache，是能夠根據業務場景動態調整的策略智慧化Cache，最終是要做到資料可以在資料湖跟資料倉庫中智慧化的冷熱分層。我們的Cache本身需要儲存跟計算，要做到深度耦合，所以數倉做這層Cache，可以做到更加的極致。另外，我們還嘗試在資料湖的資料上進行打標跟識別，是從資料建模的角度來判定，哪些資料更適合放到倉裡面，哪些資料更適合放到湖裡面。比如一些結構化被反覆訪問，比較高頻的表資料，更適合放到資料倉庫內。如果偏非結構化/半結構化低頻的資料，更適合放到資料湖內。最終的目的是為了在效能、成本以及業務效果上達到一個最佳的平衡。

阿里雲湖倉一體適合哪些場景？概況起來有三大類。

1。Hadoop叢集利舊上雲

線下Hadoop上雲需要很繁重的資料、任務搬遷，甚至要修改。這時就可以使用湖倉一體，讓線下Hadoop跟阿里雲 MaxCompute 進行快速的打通，線下的作業不需要修改，不需要搬遷的情況下，可以直接執行到MaxCompute 的系統裡面。

2。資料湖ETL/Ad-hoc加速

MaxCompute 作為SaaS模式雲資料倉庫，具有高效能、低成本以及Serverless能力。透過湖倉一體，是可以把倉的能力投射到湖裡面。

3。企業級跨平臺的統一大資料平臺

企業可以基於湖倉一體的技術，將現有的一個或多個Hadoop甚至OSS湖上的資料，跟 MaxCompute 數倉進行一個打通，最後構建一整套統一的資料開發，統一的管理、治理、排程的資料開發平臺。對上層業務提供的是，統一的、透明的中臺能力。

三、客戶案例分析

案例1、MaxCompute 數倉跟Hadoop資料湖的數倉一體案例業務介紹：

•主要做社交媒體領域裡的推薦 / 排序、文字 / 影象分類、反垃圾 / 反作弊等。在開源 Hadoop資料湖的基礎上，藉助阿里巴巴MaxCompute和PAI，解決了超大規模下的特徵工程、模型訓練等效能問題，形成了MaxCompute 和Hadoop資料湖共存的格局。

痛點：

•資料同步安排專人專項負責，工作量巨大；

•訓練資料體量大，導致耗時多，無法滿足實時訓練要求；

•新寫 SQL 資料處理 query，無法複用 Hive SQL 原有 query。

價值：

•透過湖倉一體，無須進行資料搬遷和作業遷移，原有生產作業無縫靈活排程MaxCompute 叢集和 EMR 叢集中，且效能有提升；

•封裝構建AI計算中臺，極大提升該團隊的業務支撐能力。

案例2、MaxCompute 數倉跟OSS資料湖的湖倉一體案例業務介紹：

•客戶廣告演算法團隊是湖倉一體主要客戶，主要應用是機器學習DW + MC + PAI + EAS 線上模型服務 。

痛點：

•演算法團隊想更集中在業務和演算法上，需要自服務程度高、一站式的機器學習平臺；

•Hadoop 叢集是多團隊共用，使用叢集管控較嚴，無法短時間支撐大workload 的創新業務。

價值：

•透過湖倉一體將新業務平臺與原有資料平臺打通，PAI on MaxCompute + DataWorks 為客戶創新業務提供敏捷、一站式機器學習模型開發、訓練、模型釋出，大規模計算能力、EAS 模型釋出流程；

•起到好的示範作用，並快速複製到其他業務線，高效的支撐了該客戶業務的快速增長。

案例3、MaxCompute數倉跟OSS資料湖的湖倉一體案例業務介紹：

•豐富的大資料平臺建設經驗，持續進行平臺的迭代升級以滿足業務不斷髮展的需求。從國外某廠商遷移到阿里雲後，積極建設和改造資料湖架構。

痛點：

•第一代資料湖是 EMR + OSS，公司引入的資料中臺的執行引擎和儲存是Maxcompute，兩套異構的執行引擎帶來儲存冗餘、元資料不統一、許可權不統一、湖倉計算不能自由流動。

價值：

•將 EMR 的元資料統一到DLF，底層使用 OSS 作統一儲存，並透過湖倉一體打通EMR資料湖和MaxCompute數倉兩套體系，讓資料和計算在湖和倉之間自由流動；

•實現湖倉資料分層儲存。資料中臺對資料湖資料進行維度建模的中間表儲存在MaxCompute上，建模的結果表放在資料湖裡供EMR或其他引擎消費。

講師：孫莉莉 阿里雲智慧 高階技術專家