萬字詳解大數據架構新概念

隨着近幾年數據湖概念的興起，業界對於數據倉庫和數據湖的對比甚至爭論就一直不斷。有人說數據湖是下一代大數據平臺，各大雲廠商也在紛紛的提出自己的數據湖解決方案，一些雲數倉產品也增加了和數據湖聯動的特性。

但是數據倉庫和數據湖的區別到底是什麼，是技術路線之爭？是數據管理方式之爭？二者是水火不容還是其實可以和諧共存，甚至互爲補充？

本文作者來自阿里巴巴計算平臺部門，深度參與阿里巴巴大數據 / 數據中臺領域建設，將從歷史的角度對數據湖和數據倉庫的來龍去脈進行深入剖析，來闡述兩者融合演進的新方向——湖倉一體，並就基於阿里雲 MaxCompute/EMR DataLake 的湖倉一體方案做一介紹。

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 率先提出湖倉一體，爲業界和用戶展現了一種數據湖和數據倉湖互相補充，協同工作的架構。

這樣的架構同時爲用戶提供了數據湖的靈活性和數據倉庫的諸多企業級特性，將用戶使用大數據的總體擁有成本進一步降低，我們認爲是下一代大數據平臺的演進方向。

來源：CSDN

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/K-15stUeKRR3nmXNLxGfZA