資料湖 VS 資料倉儲之爭？阿里提出大資料架構新概念：湖倉一體

隨著近幾年資料湖概念的興起，業界對於資料倉儲和資料湖的對比甚至爭論就一直不斷。有人說資料湖是下一代大資料平臺，各大雲廠商也在紛紛的提出自己的資料湖解決方案，一些雲數倉產品也增加了和資料湖聯動的特性。但是資料倉儲和資料湖的區別到底是什麼，是技術路線之爭？是資料管理方式之爭？二者是水火不容還是其實可以和諧共存，甚至互為補充？本文作者來自阿里巴巴計算平臺部門，深度參與阿里巴巴大資料/資料中臺領域建設，將從歷史的角度對資料湖和資料倉儲的來龍去脈進行深入剖析，來闡述兩者融合演進的新方向——湖倉一體，並就基於阿里雲MaxCompute/EMR DataLake的湖倉一體方案做一介紹。

大資料領域發展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年大資料發展之路

什麼是資料湖

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

Wikipedia對資料湖的定義：

A data lake is a system or repository of datastored in its natural/raw format,usually object blobsor files. A data lake is usually a single store of all enterprise data including raw copies of source system data and transformed data used for tasks such as reporting, visualization, advanced analyticsand machine learning. A data lake can include structured datafrom relational databases(rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data(emails, documents, PDFs) and binary data(images, audio, video). A data lake can be established "on premises" (within an organization's data centers) or "in the cloud" (using cloud services from vendors such as Amazon, Google and Microsoft).A data swamp is a deteriorated and unmanaged data lake that is either inaccessible to its intended users or is providing little value.

資料湖是指使用大型二進位制物件或檔案這樣的自然格式儲存資料的系統。它通常把所有的企業資料統一儲存，既包括源系統中的原始副本，也包括轉換後的資料，比如那些用於報表, 視覺化, 資料分析和機器學習的資料。資料湖可以包括關聯式資料庫的結構化資料(行與列)、半結構化的資料(CSV，日誌，XML, JSON)，非結構化資料 (電子郵件、檔案、PDF)和 二進位制資料(影像、音訊、視訊)。儲存資料湖的方式包括 Apache Hadoop分散式檔案系統， Azure 資料湖或亞馬遜雲 Lake Formation雲端儲存服務，以及諸如 Alluxio 虛擬資料湖之類的解決方案。資料沼澤是一個劣化的資料湖，使用者無法訪問，或是沒什麼價值。

AWS的定義相對簡潔：

A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.

資料湖是一個集中式儲存庫，允許您以任意規模儲存所有結構化和非結構化資料。您可以按原樣儲存資料（無需先對資料進行結構化處理），並執行不同型別的分析 – 從控制皮膚和視覺化到大資料處理、實時分析和機器學習，以指導做出更好的決策。

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. 資料湖架構圖（來自網路）

資料倉儲的誕生，以及和資料中臺的關係

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

Wikipedia對資料倉儲的定義：

In computing, a data warehouse (DW or DWH), also known as an enterprise data warehouse (EDW), is a system used for reportingand data analysis, and is considered a core component of business intelligence.DWs are central repositories of integrated data from one or more disparate sources. Extract, transform, load(ETL) and extract, load, transform(E-LT) are the two main approaches used to build a data warehouse system.

在計算機領域，資料倉儲（英語：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. 阿里巴巴資料中臺架構

資料湖 VS 資料倉儲

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

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

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

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

圖8. 資料湖和資料倉儲在技術棧上的對比

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

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

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

本文有觀察到，相當一部分企業（尤其是新興的網際網路行業）從零開始架構的大資料技術棧，正是伴隨開源 Hadoop 體系的流行，經歷了這樣一個從探索創新到成熟建模的過程。在這個過程中，因為資料湖架構太過靈活而缺少對資料監管、控制和必要的治理手段，導致運維成本不斷增加、資料治理效率降低，企業落入了『資料沼澤』的境地，即資料湖中匯聚了太多的資料，反而很難高效率的提煉真正有價值的那部分。最後只有遷移到資料倉儲優先設計的大資料平臺，才解決了業務成長到一定規模後所出現的運維、成本、資料治理等問題。還是舉阿里巴巴的例子，阿里巴巴成功的資料中臺戰略，正是在 2015 年前後阿里巴巴全集團完成 MaxCompute（資料倉儲） 對多個 Hadoop（ 資料湖）的完全替換（登月專案）才逐步形成的。

圖9. 資料湖的靈活性 VS 資料倉儲的成長性的示意圖

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

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

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

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，系統可以根據自動的規則決定哪些資料放在數倉，哪些保留在資料湖，進而形成一體化

我們將在下一章詳細介紹阿里雲湖倉一體方案如何解決這三個問題。

阿里雲湖倉一體方案

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. 微博湖倉一體架構圖

• 案例價值

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

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

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

總結

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

 

作者 |關濤、李睿博、孫莉莉、張良模、賈揚清（from 阿里雲智慧計算平臺）

黃波、金玉梅、於茜、劉子正（from 新浪微博機器學習研發部）

 

原文連結

本文為阿里雲原創內容，未經允許不得轉載。