萬(wàn)字詳解大數(shù)據(jù)架構(gòu)新概念

隨著近幾年數(shù)據(jù)湖概念的興起，業(yè)界對(duì)于數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖的對(duì)比甚至爭(zhēng)論就一直不斷。有人說(shuō)數(shù)據(jù)湖是下一代大數(shù)據(jù)平臺(tái)，各大云廠商也在紛紛的提出自己的數(shù)據(jù)湖解決方案，一些云數(shù)倉(cāng)產(chǎn)品也增加了和數(shù)據(jù)湖聯(lián)動(dòng)的特性。

但是數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖的區(qū)別到底是什么，是技術(shù)路線之爭(zhēng)？是數(shù)據(jù)管理方式之爭(zhēng)？二者是水火不容還是其實(shí)可以和諧共存，甚至互為補(bǔ)充？

本文作者來(lái)自阿里巴巴計(jì)算平臺(tái)部門(mén)，深度參與阿里巴巴大數(shù)據(jù)/數(shù)據(jù)中臺(tái)領(lǐng)域建設(shè)，將從歷史的角度對(duì)數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)的來(lái)龍去脈進(jìn)行深入剖析，來(lái)闡述兩者融合演進(jìn)的新方向——湖倉(cāng)一體，并就基于阿里云MaxCompute/EMR DataLake的湖倉(cāng)一體方案做一介紹。

01 大數(shù)據(jù)領(lǐng)域發(fā)展20年的變與不變

1.1 概述

大數(shù)據(jù)領(lǐng)域從本世紀(jì)初發(fā)展到現(xiàn)在，已經(jīng)歷20年。從宏觀層面觀察其中的發(fā)展規(guī)律，可以高度概括成如下五個(gè)方面：

1.數(shù)據(jù)保持高速增長(zhǎng)- 從5V核心要素看，大數(shù)據(jù)領(lǐng)域保持高速增長(zhǎng)。阿里巴巴經(jīng)濟(jì)體，作為一個(gè)重度使用并著力發(fā)展大數(shù)據(jù)領(lǐng)域的公司，過(guò)去5年數(shù)據(jù)規(guī)模保持高速增長(zhǎng)（年化60%-80%），增速在可見(jiàn)的未來(lái)繼續(xù)保持。對(duì)于新興企業(yè)，大數(shù)據(jù)領(lǐng)域增長(zhǎng)超過(guò)年200%。

2.大數(shù)據(jù)作為新的生產(chǎn)要素，得到廣泛認(rèn)可- 大數(shù)據(jù)領(lǐng)域價(jià)值定位的遷移，從“探索”到“普惠”，成為各個(gè)企業(yè)/政府的核心部門(mén)，并承擔(dān)關(guān)鍵任務(wù)。還是以阿里巴巴為例，30%的員工直接提交大數(shù)據(jù)作業(yè)。隨大數(shù)據(jù)普惠進(jìn)入生產(chǎn)環(huán)境，可靠性、安全性、管控能力、易用性等企業(yè)級(jí)產(chǎn)品力增強(qiáng)。

3.數(shù)據(jù)管理能力成為新的關(guān)注點(diǎn)- 數(shù)倉(cāng)（中臺(tái)）能力流行起來(lái)，如何用好數(shù)據(jù)成為企業(yè)的核心競(jìng)爭(zhēng)力。

4.引擎技術(shù)進(jìn)入收斂期- 隨著Spark（通用計(jì)算）、Flink（流計(jì)算）、Hbase（KV）、Presto（交互分析）、ElasticSearch（搜索）、Kafka（數(shù)據(jù)總線）自從2010-2015年逐步占領(lǐng)開(kāi)源生態(tài)，最近5年新引擎開(kāi)源越來(lái)越少，但各引擎技術(shù)開(kāi)始向縱深發(fā)展（更好的性能、生產(chǎn)級(jí)別的穩(wěn)定性等）。

5.平臺(tái)技術(shù)演進(jìn)出兩個(gè)趨勢(shì)，數(shù)據(jù)湖VS 數(shù)據(jù)倉(cāng)庫(kù)- 兩者均關(guān)注數(shù)據(jù)存儲(chǔ)和管理（平臺(tái)技術(shù)），但方向不同。

圖1. 阿里巴巴雙十一單日處理數(shù)據(jù)量增長(zhǎng)

1.2 從大數(shù)據(jù)技術(shù)發(fā)展看湖和倉(cāng)

首先，數(shù)據(jù)倉(cāng)庫(kù)的概念出現(xiàn)的要比數(shù)據(jù)湖早的多，可以追溯到數(shù)據(jù)庫(kù)為王的上世紀(jì) 90 年代。因此，我們有必要從歷史的脈絡(luò)來(lái)梳理這些名詞出現(xiàn)的大概時(shí)間、來(lái)由以及更重要的背后原因。大體上，計(jì)算機(jī)科學(xué)領(lǐng)域的數(shù)據(jù)處理技術(shù)的發(fā)展，主要分為四個(gè)階段：

1. 階段一：數(shù)據(jù)庫(kù)時(shí)代。數(shù)據(jù)庫(kù)最早誕生于 20 世紀(jì)的 60 年代，今天人們所熟知的關(guān)系型數(shù)據(jù)庫(kù)則出現(xiàn)在 20 世紀(jì) 70 年代，并在后續(xù)的 30 年左右時(shí)間里大放異彩，誕生了很多優(yōu)秀的關(guān)系型數(shù)據(jù)庫(kù)，如 Oracle、SQL Server、MySQL、PostgresSQL 等，成為當(dāng)時(shí)主流計(jì)算機(jī)系統(tǒng)不可或缺的組成部分。到 20 世紀(jì) 90 年代，數(shù)據(jù)倉(cāng)庫(kù)的概念誕生。

此時(shí)的數(shù)據(jù)倉(cāng)庫(kù)概念更多表達(dá)的是如何管理企業(yè)中多個(gè)數(shù)據(jù)庫(kù)實(shí)例的方法論，但受限于單機(jī)數(shù)據(jù)庫(kù)的處理能力以及多機(jī)數(shù)據(jù)庫(kù)（分庫(kù)分表）長(zhǎng)期以來(lái)的高昂價(jià)格，此時(shí)的數(shù)據(jù)倉(cāng)庫(kù)距離普通企業(yè)和用戶(hù)都還很遙遠(yuǎn)。人們甚至還在爭(zhēng)論數(shù)據(jù)倉(cāng)庫(kù)（統(tǒng)一集中管理）和數(shù)據(jù)集市（按部門(mén)、領(lǐng)域的集中管理）哪個(gè)更具可行性。

2. 階段二：大數(shù)據(jù)技術(shù)的「探索期」。時(shí)間進(jìn)入到 2000 年附近，隨著互聯(lián)網(wǎng)的爆發(fā)，動(dòng)輒幾十億、上百億的頁(yè)面以及海量的用戶(hù)點(diǎn)擊行為，開(kāi)啟了全球的數(shù)據(jù)量急劇增加的新時(shí)代。

傳統(tǒng)的數(shù)據(jù)庫(kù)方案再也無(wú)力以可接受的成本提供計(jì)算力，巨大的數(shù)據(jù)處理需求開(kāi)始尋找突破口，大數(shù)據(jù)時(shí)代開(kāi)始萌芽。2003、2004、2006 年 Google 先后 3 篇經(jīng)典論文（GFS、MapReduce、BigTable）奠基了這個(gè)大數(shù)據(jù)時(shí)代的基本技術(shù)框架，即分布式存儲(chǔ)、分布式調(diào)度以及分布式計(jì)算模型。

隨后，幾乎是在同一時(shí)期，誕生了包括 Google，微軟 Cosmos 以及開(kāi)源 Hadoop 為代表的優(yōu)秀分布式技術(shù)體系，當(dāng)然，這其中也包括阿里巴巴的飛天系統(tǒng)。此時(shí)人們興奮于追求數(shù)據(jù)的處理規(guī)模，即『大』數(shù)據(jù)，沒(méi)有閑暇爭(zhēng)論是數(shù)據(jù)倉(cāng)庫(kù)還是數(shù)據(jù)湖。

3. 階段三：大數(shù)據(jù)技術(shù)的「發(fā)展期」。來(lái)到 21 世紀(jì)的第二個(gè) 10 年，隨著越來(lái)越多的資源投入到大數(shù)據(jù)計(jì)算領(lǐng)域，大數(shù)據(jù)技術(shù)進(jìn)入一個(gè)蓬勃發(fā)展的階段，整體開(kāi)始從能用轉(zhuǎn)向好用。

代替昂貴的手寫(xiě) MapReduce 作業(yè)的，則是如雨后春筍般出現(xiàn)的各種以 SQL 為表達(dá)的計(jì)算引擎。這些計(jì)算引擎針對(duì)不同的場(chǎng)景進(jìn)行針對(duì)性?xún)?yōu)化，但都采用門(mén)檻極低的 SQL 語(yǔ)言，極大降低了大數(shù)據(jù)技術(shù)的使用成本，數(shù)據(jù)庫(kù)時(shí)代人們夢(mèng)想的大一統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)終于成為現(xiàn)實(shí)，各種數(shù)據(jù)庫(kù)時(shí)代的方法論開(kāi)始抬頭。這個(gè)時(shí)期技術(shù)路線開(kāi)始出現(xiàn)細(xì)分。

云廠商主推的如 AWS Redshift、Google BigQuery、Snowflake，包括 MaxCompute 這樣的集成系統(tǒng)稱(chēng)為大數(shù)據(jù)時(shí)代的數(shù)據(jù)倉(cāng)庫(kù)。而以開(kāi)源 Hadoop 體系為代表的的開(kāi)放式 HDFS 存儲(chǔ)、開(kāi)放的文件格式、開(kāi)放的元數(shù)據(jù)服務(wù)以及多種引擎（Hive、Presto、Spark、Flink 等）協(xié)同工作的模式，則形成了數(shù)據(jù)湖的雛形。

4. 階段四：大數(shù)據(jù)技術(shù)「普及期」。當(dāng)前，大數(shù)據(jù)技術(shù)早已不是什么火箭科技，而已經(jīng)滲透到各行各業(yè)，大數(shù)據(jù)的普及期已經(jīng)到來(lái)。市場(chǎng)對(duì)大數(shù)據(jù)產(chǎn)品的要求，除了規(guī)模、性能、簡(jiǎn)單易用，提出了成本、安全、穩(wěn)定性等更加全面的企業(yè)級(jí)生產(chǎn)的要求。

開(kāi)源 Hadoop 線，引擎、元數(shù)據(jù)、存儲(chǔ)等基礎(chǔ)部件的迭代更替進(jìn)入相對(duì)穩(wěn)態(tài)，大眾對(duì)開(kāi)源大數(shù)據(jù)技術(shù)的認(rèn)知達(dá)到空前的水平。一方面，開(kāi)放架構(gòu)的便利帶來(lái)了不錯(cuò)的市場(chǎng)份額，另一方面開(kāi)放架構(gòu)的松散則使開(kāi)源方案在企業(yè)級(jí)能力構(gòu)建上遇到瓶頸，尤其是數(shù)據(jù)安全、身份權(quán)限強(qiáng)管控、數(shù)據(jù)治理等方面，協(xié)同效率較差（如 Ranger 作為權(quán)限管控組件、Atlas 作為數(shù)據(jù)治理組件，跟今天的主流引擎竟然還無(wú)法做到全覆蓋）。同時(shí)引擎自身的發(fā)展也對(duì)已有的開(kāi)放架構(gòu)提出了更多挑戰(zhàn)，Delta Lake、Hudi 這樣自閉環(huán)設(shè)計(jì)的出現(xiàn)使得一套存儲(chǔ)、一套元數(shù)據(jù)、多種引擎協(xié)作的基礎(chǔ)出現(xiàn)了某種程度的裂痕。

真正將數(shù)據(jù)湖概念推而廣之的是AWS。AWS 構(gòu)筑了一套以 S3 為中心化存儲(chǔ)、Glue 為元數(shù)據(jù)服務(wù)，E-MapReduce、Athena 為引擎的開(kāi)放協(xié)作式的產(chǎn)品解決方案。它的開(kāi)放性和和開(kāi)源體系類(lèi)似，并在2019年推出Lake Formation 解決產(chǎn)品間的安全授信問(wèn)題。雖然這套架構(gòu)在企業(yè)級(jí)能力上和相對(duì)成熟的云數(shù)據(jù)倉(cāng)庫(kù)產(chǎn)品相去甚遠(yuǎn)，但對(duì)于開(kāi)源技術(shù)體系的用戶(hù)來(lái)說(shuō)，架構(gòu)相近理解容易，還是很有吸引力。AWS 之后，各個(gè)云廠商也紛紛跟進(jìn)數(shù)據(jù)湖的概念，并在自己的云服務(wù)上提供類(lèi)似的產(chǎn)品解決方案。

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

綜上所述，數(shù)據(jù)倉(cāng)庫(kù)是個(gè)誕生于數(shù)據(jù)庫(kù)時(shí)代的概念，在大數(shù)據(jù)時(shí)代隨云廠商的各種數(shù)倉(cāng)服務(wù)落地開(kāi)花，目前通常指代云廠商提供的基于大數(shù)據(jù)技術(shù)的一體化服務(wù)。而數(shù)據(jù)湖則脫胎于大數(shù)據(jù)時(shí)代開(kāi)源技術(shù)體系的開(kāi)放設(shè)計(jì)，經(jīng)過(guò) AWS 整合宣傳，通常是由一系列云產(chǎn)品或開(kāi)源組件共同構(gòu)成大數(shù)據(jù)解決方案。

圖2. 20年大數(shù)據(jù)發(fā)展之路

02 什么是數(shù)據(jù)湖

近幾年數(shù)據(jù)湖的概念非常火熱，但是數(shù)據(jù)湖的定義并不統(tǒng)一，我們先看下數(shù)據(jù)湖的相關(guān)定義。

Wikipedia對(duì)數(shù)據(jù)湖的定義：

數(shù)據(jù)湖是指使用大型二進(jìn)制對(duì)象或文件這樣的自然格式儲(chǔ)存數(shù)據(jù)的系統(tǒng)。它通常把所有的企業(yè)數(shù)據(jù)統(tǒng)一存儲(chǔ)，既包括源系統(tǒng)中的原始副本，也包括轉(zhuǎn)換后的數(shù)據(jù)，比如那些用于報(bào)表, 可視化, 數(shù)據(jù)分析和機(jī)器學(xué)習(xí)的數(shù)據(jù)。數(shù)據(jù)湖可以包括關(guān)系數(shù)據(jù)庫(kù)的結(jié)構(gòu)化數(shù)據(jù)(行與列)、半結(jié)構(gòu)化的數(shù)據(jù)(CSV，日志，XML,JSON)，非結(jié)構(gòu)化數(shù)據(jù) (電子郵件、文件、PDF)和 二進(jìn)制數(shù)據(jù)(圖像、音頻、視頻)。儲(chǔ)存數(shù)據(jù)湖的方式包括Apache Hadoop分布式文件系統(tǒng)， Azure 數(shù)據(jù)湖或亞馬遜云 Lake Formation云存儲(chǔ)服務(wù)，以及諸如 Alluxio 虛擬數(shù)據(jù)湖之類(lèi)的解決方案。數(shù)據(jù)沼澤是一個(gè)劣化的數(shù)據(jù)湖，用戶(hù)無(wú)法訪問(wèn)，或是沒(méi)什么價(jià)值。

AWS的定義相對(duì)簡(jiǎn)潔：

數(shù)據(jù)湖是一個(gè)集中式存儲(chǔ)庫(kù)，允許您以任意規(guī)模存儲(chǔ)所有結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。您可以按原樣存儲(chǔ)數(shù)據(jù)（無(wú)需先對(duì)數(shù)據(jù)進(jìn)行結(jié)構(gòu)化處理），并運(yùn)行不同類(lèi)型的分析 – 從控制面板和可視化到大數(shù)據(jù)處理、實(shí)時(shí)分析和機(jī)器學(xué)習(xí)，以指導(dǎo)做出更好的決策。

Azure等其他云廠商也有各自的定義，本文不再贅述。

但無(wú)論數(shù)據(jù)湖的定義如何不同，數(shù)據(jù)湖的本質(zhì)其實(shí)都包含如下四部分：

1.統(tǒng)一的存儲(chǔ)系統(tǒng)

2.存儲(chǔ)原始數(shù)據(jù)

3.豐富的計(jì)算模型/范式

4.數(shù)據(jù)湖與上云無(wú)關(guān)

從上述四個(gè)標(biāo)準(zhǔn)判斷，開(kāi)源大數(shù)據(jù)的Hadoop HDFS存儲(chǔ)系統(tǒng)就是一個(gè)標(biāo)準(zhǔn)的數(shù)據(jù)湖架構(gòu)，具備統(tǒng)一的原始數(shù)據(jù)存儲(chǔ)架構(gòu)。而近期被廣泛談到的數(shù)據(jù)湖，其實(shí)是一個(gè)狹義的概念，特指“基于云上托管存儲(chǔ)系統(tǒng)的數(shù)據(jù)湖系統(tǒng)，架構(gòu)上采用存儲(chǔ)計(jì)算分離的體系”。例如基于AWS S3系統(tǒng)或者阿里云OSS系統(tǒng)構(gòu)建的數(shù)據(jù)湖。

下圖是數(shù)據(jù)湖技術(shù)架構(gòu)的演進(jìn)過(guò)程，整體上可分為三個(gè)階段：

圖3. 數(shù)據(jù)湖技術(shù)架構(gòu)演進(jìn)

1. 階段一：自建開(kāi)源Hadoop數(shù)據(jù)湖架構(gòu)，原始數(shù)據(jù)統(tǒng)一存放在HDFS系統(tǒng)上，引擎以Hadoop和Spark開(kāi)源生態(tài)為主，存儲(chǔ)和計(jì)算一體。缺點(diǎn)是需要企業(yè)自己運(yùn)維和管理整套集群，成本高且集群穩(wěn)定性差。

2. 階段二：云上托管Hadoop數(shù)據(jù)湖架構(gòu)（即EMR開(kāi)源數(shù)據(jù)湖），底層物理服務(wù)器和開(kāi)源軟件版本由云廠商提供和管理，數(shù)據(jù)仍統(tǒng)一存放在HDFS系統(tǒng)上，引擎以Hadoop和Spark開(kāi)源生態(tài)為主。

這個(gè)架構(gòu)通過(guò)云上 IaaS 層提升了機(jī)器層面的彈性和穩(wěn)定性，使企業(yè)的整體運(yùn)維成本有所下降，但企業(yè)仍然需要對(duì)HDFS系統(tǒng)以及服務(wù)運(yùn)行狀態(tài)進(jìn)行管理和治理，即應(yīng)用層的運(yùn)維工作。同時(shí)因?yàn)榇鎯?chǔ)和計(jì)算耦合在一起，穩(wěn)定性不是最優(yōu)，兩種資源無(wú)法獨(dú)立擴(kuò)展，使用成本也不是最優(yōu)。

3. 階段三：云上數(shù)據(jù)湖架構(gòu)，即云上純托管的存儲(chǔ)系統(tǒng)逐步取代HDFS，成為數(shù)據(jù)湖的存儲(chǔ)基礎(chǔ)設(shè)施，并且引擎豐富度也不斷擴(kuò)展。除了Hadoop和Spark的生態(tài)引擎之外，各云廠商還發(fā)展出面向數(shù)據(jù)湖的引擎產(chǎn)品。

如分析類(lèi)的數(shù)據(jù)湖引擎有AWS Athena和華為DLI，AI類(lèi)的有AWS Sagemaker。這個(gè)架構(gòu)仍然保持了一個(gè)存儲(chǔ)和多個(gè)引擎的特性，所以統(tǒng)一元數(shù)據(jù)服務(wù)至關(guān)重要，如AWS推出了Glue，阿里云EMR近期也即將發(fā)布數(shù)據(jù)湖統(tǒng)一元數(shù)據(jù)服務(wù)。該架構(gòu)相對(duì)于原生HDFS的數(shù)據(jù)湖架構(gòu)的優(yōu)勢(shì)在于：

幫助用戶(hù)擺脫原生HDFS系統(tǒng)運(yùn)維困難的問(wèn)題。HDFS系統(tǒng)運(yùn)維有兩個(gè)困難：1）存儲(chǔ)系統(tǒng)相比計(jì)算引擎更高的穩(wěn)定性要求和更高的運(yùn)維風(fēng)險(xiǎn) 2）與計(jì)算混布在一起，帶來(lái)的擴(kuò)展彈性問(wèn)題。存儲(chǔ)計(jì)算分離架構(gòu)幫助用戶(hù)解耦存儲(chǔ)，并交由云廠商統(tǒng)一運(yùn)維管理，解決了穩(wěn)定性和運(yùn)維問(wèn)題。

分離后的存儲(chǔ)系統(tǒng)可以獨(dú)立擴(kuò)展，不再需要與計(jì)算耦合，可降低整體成本

當(dāng)用戶(hù)采用數(shù)據(jù)湖架構(gòu)之后，客觀上也幫助客戶(hù)完成了存儲(chǔ)統(tǒng)一化（解決多個(gè)HDFS數(shù)據(jù)孤島的問(wèn)題）

下圖是阿里云EMR數(shù)據(jù)湖架構(gòu)圖，它是基于開(kāi)源生態(tài)的大數(shù)據(jù)平臺(tái)，既支持HDFS的開(kāi)源數(shù)據(jù)湖，也支持OSS的云上數(shù)據(jù)湖。

圖4. 阿里云EMR數(shù)據(jù)湖架構(gòu)

企業(yè)使用數(shù)據(jù)湖技術(shù)構(gòu)建大數(shù)據(jù)平臺(tái)，主要包括數(shù)據(jù)接入、數(shù)據(jù)存儲(chǔ)、計(jì)算和分析、數(shù)據(jù)管理、權(quán)限控制等，下圖是Gartner定義的一個(gè)參考架構(gòu)。當(dāng)前數(shù)據(jù)湖的技術(shù)因其架構(gòu)的靈活性和開(kāi)放性，在性能效率、安全控制以及數(shù)據(jù)治理上并不十分成熟，在面向企業(yè)級(jí)生產(chǎn)要求時(shí)還存在很大挑戰(zhàn)（在第四章會(huì)有詳細(xì)的闡述）。

圖5. 數(shù)據(jù)湖架構(gòu)圖（來(lái)自網(wǎng)絡(luò)）

03 數(shù)據(jù)倉(cāng)庫(kù)的誕生，以及和數(shù)據(jù)中臺(tái)的關(guān)系

數(shù)據(jù)倉(cāng)庫(kù)的概念最早來(lái)源于數(shù)據(jù)庫(kù)領(lǐng)域，主要處理面向數(shù)據(jù)的復(fù)雜查詢(xún)和分析場(chǎng)景。隨大數(shù)據(jù)技術(shù)發(fā)展，大量借鑒數(shù)據(jù)庫(kù)的技術(shù)，例如SQL語(yǔ)言、查詢(xún)優(yōu)化器等，形成了大數(shù)據(jù)的數(shù)據(jù)倉(cāng)庫(kù)，因其強(qiáng)大的分析能力，成為主流。

近幾年，數(shù)據(jù)倉(cāng)庫(kù)和云原生技術(shù)相結(jié)合，又演生出了云數(shù)據(jù)倉(cāng)庫(kù)，解決了企業(yè)部署數(shù)據(jù)倉(cāng)庫(kù)的資源供給問(wèn)題。云數(shù)據(jù)倉(cāng)庫(kù)作為大數(shù)據(jù)的高階（企業(yè)級(jí)）平臺(tái)能力，因其開(kāi)箱即用、無(wú)限擴(kuò)展、簡(jiǎn)易運(yùn)維等能力，越來(lái)越受到人們的矚目。

Wikipedia對(duì)數(shù)據(jù)倉(cāng)庫(kù)的定義：

在計(jì)算機(jī)領(lǐng)域，數(shù)據(jù)倉(cāng)庫(kù)（英語(yǔ)：data warehouse，也稱(chēng)為企業(yè)數(shù)據(jù)倉(cāng)庫(kù)）是用于報(bào)告和數(shù)據(jù)分析的系統(tǒng)，被認(rèn)為是商業(yè)智能的核心組件。數(shù)據(jù)倉(cāng)庫(kù)是來(lái)自一個(gè)或多個(gè)不同源的集成數(shù)據(jù)的中央存儲(chǔ)庫(kù)。數(shù)據(jù)倉(cāng)庫(kù)將當(dāng)前和歷史數(shù)據(jù)存儲(chǔ)在一起，用于為整個(gè)企業(yè)的員工創(chuàng)建分析報(bào)告。

比較學(xué)術(shù)的解釋是，數(shù)據(jù)倉(cāng)庫(kù)由數(shù)據(jù)倉(cāng)庫(kù)之父W.H.Inmon于1990年提出，主要功能乃是將組織透過(guò)信息系統(tǒng)之在線交易處理(OLTP)經(jīng)年累月所累積的大量數(shù)據(jù)，透過(guò)數(shù)據(jù)倉(cāng)庫(kù)理論所特有的數(shù)據(jù)存儲(chǔ)架構(gòu)，作一有系統(tǒng)的分析整理，以利各種分析方法如在線分析處理(OLAP)、數(shù)據(jù)挖掘(Data Mining)之進(jìn)行，并進(jìn)而支持如決策支持系統(tǒng)(DSS)、主管信息系統(tǒng)(EIS)之創(chuàng)建，幫助決策者能快速有效的自大量數(shù)據(jù)中，分析出有價(jià)值的信息，以利決策擬定及快速回應(yīng)外在環(huán)境變動(dòng)，幫助建構(gòu)商業(yè)智能(BI)。

數(shù)據(jù)倉(cāng)庫(kù)的本質(zhì)包含如下三部分：

1. 內(nèi)置的存儲(chǔ)系統(tǒng)，數(shù)據(jù)通過(guò)抽象的方式提供（例如采用Table或者View），不暴露文件系統(tǒng)。

2.數(shù)據(jù)需要清洗和轉(zhuǎn)化，通常采用ETL/ELT方式

3.強(qiáng)調(diào)建模和數(shù)據(jù)管理，供商業(yè)智能決策

從上述的標(biāo)準(zhǔn)判斷，無(wú)論傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)（如Teradata）還是新興的云數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)（AWS Redshift、Google BigQuery、阿里云MaxCompute）均體現(xiàn)了數(shù)倉(cāng)的設(shè)計(jì)本質(zhì)，它們均沒(méi)有對(duì)外暴露文件系統(tǒng)，而是提供了數(shù)據(jù)進(jìn)出的服務(wù)接口。

比如，Teradata提供了CLI數(shù)據(jù)導(dǎo)入工具，Redshift提供Copy命令從S3或者EMR上導(dǎo)入數(shù)據(jù)，BigQuery提供Data Transfer服務(wù)，MaxCompute提供Tunnel服務(wù)以及MMA搬站工具供數(shù)據(jù)上傳和下載。這個(gè)設(shè)計(jì)可以帶來(lái)多個(gè)優(yōu)勢(shì)：

1.引擎深度理解數(shù)據(jù)，存儲(chǔ)和計(jì)算可做深度優(yōu)化

2.數(shù)據(jù)全生命周期管理，完善的血緣體系

3.細(xì)粒度的數(shù)據(jù)管理和治理

4.完善的元數(shù)據(jù)管理能力，易于構(gòu)建企業(yè)級(jí)數(shù)據(jù)中臺(tái)

正因?yàn)槿绱耍⒗锇桶惋w天大數(shù)據(jù)平臺(tái)建設(shè)之初，在選型的時(shí)候就采用了數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)，即MaxCompute大數(shù)據(jù)平臺(tái)。MaxCompute（原ODPS)，既是阿里巴巴經(jīng)濟(jì)體的大數(shù)據(jù)平臺(tái)，又是阿里云上的一種安全可靠、高效能、低成本、從GB到EB級(jí)別按需彈性伸縮的在線大數(shù)據(jù)計(jì)算服務(wù)（圖6.是MaxCompute產(chǎn)品架構(gòu)，具體詳情請(qǐng)點(diǎn)擊阿里云MaxCompute官網(wǎng)地址）。

作為SaaS模式的企業(yè)級(jí)云數(shù)倉(cāng)，MaxCompute廣泛應(yīng)用在阿里巴巴經(jīng)濟(jì)體、以及阿里云上互聯(lián)網(wǎng)、新金融、新零售、數(shù)字政府等數(shù)千家客戶(hù)。

圖6. MaxCompute云數(shù)倉(cāng)產(chǎn)品架構(gòu)

得益于MaxCompute數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)，阿里巴巴上層逐步構(gòu)建了“數(shù)據(jù)安全體系”、“數(shù)據(jù)質(zhì)量”、“數(shù)據(jù)治理”、“數(shù)據(jù)標(biāo)簽”等管理能力，并最終形成了阿里巴巴的大數(shù)據(jù)中臺(tái)?？梢哉f(shuō)，作為最早數(shù)據(jù)中臺(tái)概念的提出者，阿里巴巴的數(shù)據(jù)中臺(tái)得益于數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)。

圖7. 阿里巴巴數(shù)據(jù)中臺(tái)架構(gòu)

04 數(shù)據(jù)湖VS 數(shù)據(jù)倉(cāng)庫(kù)

綜上，數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖，是大數(shù)據(jù)架構(gòu)的兩種設(shè)計(jì)取向。兩者在設(shè)計(jì)的根本分歧點(diǎn)是對(duì)包括存儲(chǔ)系統(tǒng)訪問(wèn)、權(quán)限管理、建模要求等方面的把控。

數(shù)據(jù)湖優(yōu)先的設(shè)計(jì)，通過(guò)開(kāi)放底層文件存儲(chǔ)，給數(shù)據(jù)入湖帶來(lái)了最大的靈活性。進(jìn)入數(shù)據(jù)湖的數(shù)據(jù)可以是結(jié)構(gòu)化的，也可以是半結(jié)構(gòu)化的，甚至可以是完全非結(jié)構(gòu)化的原始日志。另外，開(kāi)放存儲(chǔ)給上層的引擎也帶來(lái)了更多的靈活度，各種引擎可以根據(jù)自己針對(duì)的場(chǎng)景隨意讀寫(xiě)數(shù)據(jù)湖中存儲(chǔ)的數(shù)據(jù)，而只需要遵循相當(dāng)寬松的兼容性約定（這樣的松散約定當(dāng)然會(huì)有隱患，后文會(huì)提到）。

但同時(shí)，文件系統(tǒng)直接訪問(wèn)使得很多更高階的功能很難實(shí)現(xiàn)，例如，細(xì)粒度（小于文件粒度）的權(quán)限管理、統(tǒng)一化的文件管理和讀寫(xiě)接口升級(jí)也十分困難（需要完成每一個(gè)訪問(wèn)文件的引擎升級(jí)，才算升級(jí)完畢）。

而數(shù)據(jù)倉(cāng)庫(kù)優(yōu)先的設(shè)計(jì)，更加關(guān)注的是數(shù)據(jù)使用效率、大規(guī)模下的數(shù)據(jù)管理、安全/合規(guī)這樣的企業(yè)級(jí)成長(zhǎng)性需求。數(shù)據(jù)經(jīng)過(guò)統(tǒng)一但開(kāi)放的服務(wù)接口進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)，數(shù)據(jù)通常預(yù)先定義 schema，用戶(hù)通過(guò)數(shù)據(jù)服務(wù)接口或者計(jì)算引擎訪問(wèn)分布式存儲(chǔ)系統(tǒng)中的文件。

數(shù)據(jù)倉(cāng)庫(kù)優(yōu)先的設(shè)計(jì)通過(guò)抽象數(shù)據(jù)訪問(wèn)接口/權(quán)限管理/數(shù)據(jù)本身，來(lái)?yè)Q取更高的性能（無(wú)論是存儲(chǔ)還是計(jì)算）、閉環(huán)的安全體系、數(shù)據(jù)治理的能力等，這些能力對(duì)于企業(yè)長(zhǎng)遠(yuǎn)的大數(shù)據(jù)使用都至關(guān)重要，我們稱(chēng)之為成長(zhǎng)性。

下圖是針對(duì)大數(shù)據(jù)技術(shù)棧，分別比較數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)各自的取舍。

圖8. 數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)在技術(shù)棧上的對(duì)比

靈活性和成長(zhǎng)性，對(duì)于處于不同時(shí)期的企業(yè)來(lái)說(shuō)，重要性不同。

1. 當(dāng)企業(yè)處于初創(chuàng)階段，數(shù)據(jù)從產(chǎn)生到消費(fèi)還需要一個(gè)創(chuàng)新探索的階段才能逐漸沉淀下來(lái)，那么用于支撐這類(lèi)業(yè)務(wù)的大數(shù)據(jù)系統(tǒng)，靈活性就更加重要，數(shù)據(jù)湖的架構(gòu)更適用。

2. 當(dāng)企業(yè)逐漸成熟起來(lái)，已經(jīng)沉淀為一系列數(shù)據(jù)處理流程，問(wèn)題開(kāi)始轉(zhuǎn)化為數(shù)據(jù)規(guī)模不斷增長(zhǎng)，處理數(shù)據(jù)的成本不斷增加，參與數(shù)據(jù)流程的人員、部門(mén)不斷增多，那么用于支撐這類(lèi)業(yè)務(wù)的大數(shù)據(jù)系統(tǒng)，成長(zhǎng)性的好壞就決定了業(yè)務(wù)能夠發(fā)展多遠(yuǎn)。數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)更適用。

本文有觀察到，相當(dāng)一部分企業(yè)（尤其是新興的互聯(lián)網(wǎng)行業(yè)）從零開(kāi)始架構(gòu)的大數(shù)據(jù)技術(shù)棧，正是伴隨開(kāi)源 Hadoop 體系的流行，經(jīng)歷了這樣一個(gè)從探索創(chuàng)新到成熟建模的過(guò)程。在這個(gè)過(guò)程中，因?yàn)閿?shù)據(jù)湖架構(gòu)太過(guò)靈活而缺少對(duì)數(shù)據(jù)監(jiān)管、控制和必要的治理手段，導(dǎo)致運(yùn)維成本不斷增加、數(shù)據(jù)治理效率降低，企業(yè)落入了『數(shù)據(jù)沼澤』的境地，即數(shù)據(jù)湖中匯聚了太多的數(shù)據(jù)，反而很難高效率的提煉真正有價(jià)值的那部分。

最后只有遷移到數(shù)據(jù)倉(cāng)庫(kù)優(yōu)先設(shè)計(jì)的大數(shù)據(jù)平臺(tái)，才解決了業(yè)務(wù)成長(zhǎng)到一定規(guī)模后所出現(xiàn)的運(yùn)維、成本、數(shù)據(jù)治理等問(wèn)題。還是舉阿里巴巴的例子，阿里巴巴成功的數(shù)據(jù)中臺(tái)戰(zhàn)略，正是在 2015 年前后阿里巴巴全集團(tuán)完成 MaxCompute（數(shù)據(jù)倉(cāng)庫(kù)） 對(duì)多個(gè) Hadoop（ 數(shù)據(jù)湖）的完全替換（登月項(xiàng)目）才逐步形成的。

圖9.數(shù)據(jù)湖的靈活性 VS 數(shù)據(jù)倉(cāng)庫(kù)的成長(zhǎng)性的示意圖

05 下一代演進(jìn)方向：湖倉(cāng)一體

經(jīng)過(guò)對(duì)數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)的深入闡述和比較，本文認(rèn)為數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)作為大數(shù)據(jù)系統(tǒng)的兩條不同演進(jìn)路線，有各自特有的優(yōu)勢(shì)和局限性。

數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)一個(gè)面向初創(chuàng)用戶(hù)友好，一個(gè)成長(zhǎng)性更佳。對(duì)企業(yè)來(lái)說(shuō)，數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)是否必須是一個(gè)二選一的選擇題？是否能有一種方案同時(shí)兼顧數(shù)據(jù)湖的靈活性和云數(shù)據(jù)倉(cāng)庫(kù)的成長(zhǎng)性，將二者有效結(jié)合起來(lái)為用戶(hù)實(shí)現(xiàn)更低的總體擁有成本？

將數(shù)倉(cāng)和數(shù)據(jù)湖融合在一起也是業(yè)界近年的趨勢(shì)，多個(gè)產(chǎn)品和項(xiàng)目都做過(guò)對(duì)應(yīng)的嘗試：

1.數(shù)倉(cāng)支持?jǐn)?shù)據(jù)湖訪問(wèn)

2017年Redshift推出Redshift Spectrum，支持Redsift數(shù)倉(cāng)用戶(hù)訪問(wèn)S3數(shù)據(jù)湖的數(shù)據(jù)。

2018年阿里云MaxCompute推出外表能力，支持訪問(wèn)包括OSS/OTS/RDS數(shù)據(jù)庫(kù)在內(nèi)的多種外部存儲(chǔ)。

但是無(wú)論是 Redshift Spectrum 還是 MaxCompute 的外部表，仍舊需要用戶(hù)在數(shù)倉(cāng)中通過(guò)創(chuàng)建外部表來(lái)將數(shù)據(jù)湖的開(kāi)放存儲(chǔ)路徑納入數(shù)倉(cāng)的概念體系——由于一個(gè)單純的開(kāi)放式存儲(chǔ)并不能自描述其數(shù)據(jù)本身的變化，因此為這些數(shù)據(jù)創(chuàng)建外部表、添加分區(qū)（本質(zhì)上是為數(shù)據(jù)湖中的數(shù)據(jù)建立 schema）無(wú)法完全自動(dòng)化（需要人工或者定期觸發(fā) Alter table add partition 或 msck）。這對(duì)于低頻臨時(shí)查詢(xún)尚能接受，對(duì)于生產(chǎn)使用來(lái)說(shuō)，未免有些復(fù)雜。

2.數(shù)據(jù)湖支持?jǐn)?shù)倉(cāng)能力

2011年，Hadoop開(kāi)源體系公司Hortonworks開(kāi)始了Apache Atlas和Ranger兩個(gè)開(kāi)源項(xiàng)目的開(kāi)發(fā)，分別對(duì)應(yīng)數(shù)據(jù)血緣追蹤和數(shù)據(jù)權(quán)限安全兩個(gè)數(shù)倉(cāng)核心能力。但兩個(gè)項(xiàng)目發(fā)展并不算順利，直到 2017 年才完成孵化，時(shí)至今日，在社區(qū)和工業(yè)界的部署都還遠(yuǎn)遠(yuǎn)不夠活躍。核心原因數(shù)據(jù)湖與生俱來(lái)的靈活性。例如Ranger作為數(shù)據(jù)權(quán)限安全統(tǒng)一管理的組件，天然要求所有引擎均適配它才能保證沒(méi)有安全漏洞，但對(duì)于數(shù)據(jù)湖中強(qiáng)調(diào)靈活的引擎，尤其是新引擎來(lái)說(shuō)，會(huì)優(yōu)先實(shí)現(xiàn)功能、場(chǎng)景，而不是把對(duì)接Ranger作為第一優(yōu)先級(jí)的目標(biāo)，使得Ranger在數(shù)據(jù)湖上的位置一直很尷尬。

2018年，Nexflix開(kāi)源了內(nèi)部增強(qiáng)版本的元數(shù)據(jù)服務(wù)系統(tǒng)Iceberg，提供包括MVCC（多版本并發(fā)控制）在內(nèi)的增強(qiáng)數(shù)倉(cāng)能力，但因?yàn)殚_(kāi)源HMS已經(jīng)成為事實(shí)標(biāo)準(zhǔn)，開(kāi)源版本的Iceberg作為插件方式兼容并配合HMS，數(shù)倉(cāng)管理能力大打折扣。

2018-2019年，Uber和Databricks相繼推出了Apache Hudi和DeltaLake，推出增量文件格式用以支持Update/Insert、事務(wù)等數(shù)據(jù)倉(cāng)庫(kù)功能。新功能帶來(lái)文件格式以及組織形式的改變，打破了數(shù)據(jù)湖原有多套引擎之間關(guān)于共用存儲(chǔ)的簡(jiǎn)單約定。為此，Hudi為了維持兼容性，不得不發(fā)明了諸如 Copy-On-Write、Merge-On-Read 兩種表，Snapshot Query、Incremental Query、Read Optimized Query 三種查詢(xún)類(lèi)型，并給出了一個(gè)支持矩陣（如圖10），極大提升了使用的復(fù)雜度。

圖10. Hudi Support Matrix（來(lái)自網(wǎng)絡(luò)）

而DeltaLake則選擇了保證以Spark為主要支持引擎的體驗(yàn)，相對(duì)犧牲對(duì)其他主流引擎的兼容性。這對(duì)其他引擎訪問(wèn)數(shù)據(jù)湖中的Delta數(shù)據(jù)造成了諸多的限制和使用不便。例如Presto要使用DeltaLake表，需要先用Spark創(chuàng)建manifest文件，再根據(jù)manifest創(chuàng)建外部表，同時(shí)還要注意manifest文件的更新問(wèn)題；而Hive要使用DeltaLake表限制更多，不僅會(huì)造成元數(shù)據(jù)層面的混亂，甚至不能寫(xiě)表。

上述在數(shù)據(jù)湖架構(gòu)上建立數(shù)倉(cāng)的若干嘗試并不成功，這表明數(shù)倉(cāng)和數(shù)據(jù)湖有本質(zhì)的區(qū)別，在數(shù)據(jù)湖體系上很難建成完善的數(shù)倉(cāng)。數(shù)據(jù)湖與數(shù)據(jù)倉(cāng)庫(kù)兩者很難直接合并成一套系統(tǒng)，因此作者團(tuán)隊(duì)，開(kāi)始基于融合兩者的思路進(jìn)行探索。

所以我們提出下一代的大數(shù)據(jù)技術(shù)演進(jìn)方向：湖倉(cāng)一體，即打通數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖兩套體系，讓數(shù)據(jù)和計(jì)算在湖和倉(cāng)之間自由流動(dòng)，從而構(gòu)建一個(gè)完整的有機(jī)的大數(shù)據(jù)技術(shù)生態(tài)體系。

我們認(rèn)為，構(gòu)建湖倉(cāng)一體需要解決三個(gè)關(guān)鍵問(wèn)題：

1.湖和倉(cāng)的數(shù)據(jù)/元數(shù)據(jù)無(wú)縫打通，且不需要用戶(hù)人工干預(yù)

2.湖和倉(cāng)有統(tǒng)一的開(kāi)發(fā)體驗(yàn)，存儲(chǔ)在不同系統(tǒng)的數(shù)據(jù)，可以通過(guò)一個(gè)統(tǒng)一的開(kāi)發(fā)/管理平臺(tái)操作

3.數(shù)據(jù)湖與數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)，系統(tǒng)負(fù)責(zé)自動(dòng)caching/moving，系統(tǒng)可以根據(jù)自動(dòng)的規(guī)則決定哪些數(shù)據(jù)放在數(shù)倉(cāng)，哪些保留在數(shù)據(jù)湖，進(jìn)而形成一體化

我們將在下一章詳細(xì)介紹阿里云湖倉(cāng)一體方案如何解決這三個(gè)問(wèn)題。

06 阿里云湖倉(cāng)一體方案

6.1 整體架構(gòu)

阿里云MaxCompute在原有的數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)上，融合了開(kāi)源數(shù)據(jù)湖和云上數(shù)據(jù)湖，最終實(shí)現(xiàn)了湖倉(cāng)一體化的整體架構(gòu)（圖11）。

在該架構(gòu)中，盡管底層多套存儲(chǔ)系統(tǒng)并存，但通過(guò)統(tǒng)一的存儲(chǔ)訪問(wèn)層和統(tǒng)一的元數(shù)據(jù)管理，向上層引擎提供一體的封裝接口，用戶(hù)可以聯(lián)合查詢(xún)數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖中的表。整體架構(gòu)還具備統(tǒng)一的數(shù)據(jù)安全、管理和治理等中臺(tái)能力。

圖11. 阿里云湖倉(cāng)一體整體架構(gòu)

針對(duì)第五章提出的湖倉(cāng)一體的三個(gè)關(guān)鍵問(wèn)題，MaxCompute實(shí)現(xiàn)了以下4個(gè)關(guān)鍵技術(shù)點(diǎn)。

1.快速接入

MaxCompute全新自創(chuàng)PrivateAccess網(wǎng)絡(luò)連通技術(shù)，在遵循云虛擬網(wǎng)絡(luò)安全標(biāo)準(zhǔn)的前提下，實(shí)現(xiàn)多租戶(hù)模式下特定用戶(hù)作業(yè)定向與IDC/ECS/EMR Hadoop集群網(wǎng)絡(luò)整體打通能力，具有低延遲、高獨(dú)享帶寬的特點(diǎn)。

經(jīng)過(guò)快速簡(jiǎn)單的開(kāi)通、安全配置步驟即可將數(shù)據(jù)湖和購(gòu)買(mǎi)的 MaxCompute數(shù)倉(cāng)相連通。

2.統(tǒng)一數(shù)據(jù)/元數(shù)據(jù)管理

MaxCompute實(shí)現(xiàn)湖倉(cāng)一體化的元數(shù)據(jù)管理，通過(guò)DB元數(shù)據(jù)一鍵映射技術(shù)，實(shí)現(xiàn)數(shù)據(jù)湖和MaxCompute數(shù)倉(cāng)的元數(shù)據(jù)無(wú)縫打通。MaxCompute通過(guò)向用戶(hù)開(kāi)放創(chuàng)建external project的形式，將數(shù)據(jù)湖HiveMetaStore中的整個(gè)database直接映射為MaxCompute的project，對(duì)Hive Database的改動(dòng)會(huì)實(shí)時(shí)反應(yīng)在這個(gè)project中，并可以在MaxCompute側(cè)隨時(shí)通過(guò)這個(gè)project進(jìn)行訪問(wèn)、計(jì)算其中的數(shù)據(jù)。與此同時(shí)，阿里云EMR數(shù)據(jù)湖解決方案也將推出Data Lake Formation，MaxCompute湖倉(cāng)一體方案也會(huì)支持對(duì)該數(shù)據(jù)湖中的統(tǒng)一元數(shù)據(jù)服務(wù)的一鍵映射能力。MaxCompute側(cè)對(duì)external project的各種操作，也會(huì)實(shí)時(shí)反應(yīng)在Hive側(cè)，真正實(shí)現(xiàn)數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖之間的無(wú)縫聯(lián)動(dòng)，完全不需要類(lèi)似聯(lián)邦查詢(xún)方案里的元數(shù)據(jù)人工干預(yù)步驟。

MaxCompute實(shí)現(xiàn)湖倉(cāng)一體化的存儲(chǔ)訪問(wèn)層，不僅支持內(nèi)置優(yōu)化的存儲(chǔ)系統(tǒng)，也無(wú)縫的支持外部存儲(chǔ)系統(tǒng)。既支持HDFS數(shù)據(jù)湖，也支持OSS云存儲(chǔ)數(shù)據(jù)湖，可讀寫(xiě)各種開(kāi)源文件格式。

3.統(tǒng)一開(kāi)發(fā)體驗(yàn)

數(shù)據(jù)湖里的Hive DataBase映射為MaxCompute external project，和普通project別無(wú)二致，同樣享受MaxCompute數(shù)倉(cāng)里的數(shù)據(jù)開(kāi)發(fā)、追蹤和管理功能?；贒ataWorks強(qiáng)大的數(shù)據(jù)開(kāi)發(fā)/管理/治理能力，提供統(tǒng)一的湖倉(cāng)開(kāi)發(fā)體驗(yàn)，降低兩套系統(tǒng)的管理成本。

MaxCompute高度兼容Hive/Spark，支持一套任務(wù)可以在湖倉(cāng)兩套體系中靈活無(wú)縫的運(yùn)行。

同時(shí)，MaxCompute也提供高效的數(shù)據(jù)通道接口，可以讓數(shù)據(jù)湖中的Hadoop生態(tài)引擎直接訪問(wèn)，提升了數(shù)倉(cāng)的開(kāi)放性。

4.自動(dòng)數(shù)倉(cāng)

湖倉(cāng)一體需要用戶(hù)根據(jù)自身資產(chǎn)使用情況將數(shù)據(jù)在湖和倉(cāng)之間進(jìn)行合理的分層和存儲(chǔ)，以最大化湖和倉(cāng)的優(yōu)勢(shì)。MaxCompute開(kāi)發(fā)了一套智能cache技術(shù)，根據(jù)對(duì)歷史任務(wù)的分析來(lái)識(shí)別數(shù)據(jù)冷熱度，從而自動(dòng)利用閑時(shí)帶寬將數(shù)據(jù)湖中的熱數(shù)據(jù)以高效文件格式cache在數(shù)據(jù)倉(cāng)庫(kù)中，進(jìn)一步加速數(shù)據(jù)倉(cāng)庫(kù)的后續(xù)數(shù)據(jù)加工流程。不僅解決了湖倉(cāng)之間的帶寬瓶頸問(wèn)題，也達(dá)到了無(wú)須用戶(hù)參與即可實(shí)現(xiàn)數(shù)據(jù)分層管理/治理以及性能加速的目的。

6.2 構(gòu)建湖倉(cāng)一體化的數(shù)據(jù)中臺(tái)

基于MaxCompute湖倉(cāng)一體技術(shù)，DataWorks可以進(jìn)一步對(duì)湖倉(cāng)兩套系統(tǒng)進(jìn)行封裝，屏蔽湖和倉(cāng)異構(gòu)集群信息，構(gòu)建一體化的大數(shù)據(jù)中臺(tái)，實(shí)現(xiàn)一套數(shù)據(jù)、一套任務(wù)在湖和倉(cāng)之上無(wú)縫調(diào)度和管理。

企業(yè)可以使用湖倉(cāng)一體化的數(shù)據(jù)中臺(tái)能力，優(yōu)化數(shù)據(jù)管理架構(gòu)，充分融合數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)各自?xún)?yōu)勢(shì)。使用數(shù)據(jù)湖做集中式的原始數(shù)據(jù)存儲(chǔ)，發(fā)揮數(shù)據(jù)湖的靈活和開(kāi)放優(yōu)勢(shì)。

又通過(guò)湖倉(cāng)一體技術(shù)將面向生產(chǎn)的高頻數(shù)據(jù)和任務(wù)，無(wú)縫調(diào)度到數(shù)據(jù)倉(cāng)庫(kù)中，以得到更好的性能和成本，以及后續(xù)一系列面向生產(chǎn)的數(shù)據(jù)治理和優(yōu)化，最終讓企業(yè)在成本和效率之間找到最佳平衡。

總體來(lái)說(shuō)，MaxCompute湖倉(cāng)一體為企業(yè)提供了一種更靈活更高效更經(jīng)濟(jì)的數(shù)據(jù)平臺(tái)解決方案，既適用于全新構(gòu)建大數(shù)據(jù)平臺(tái)的企業(yè)，也適合已有大數(shù)據(jù)平臺(tái)的企業(yè)進(jìn)行架構(gòu)升級(jí)，可以保護(hù)現(xiàn)有投資和實(shí)現(xiàn)資產(chǎn)利舊。

圖12. DataWorks湖倉(cāng)一體化數(shù)據(jù)中臺(tái)

6.3 典型客戶(hù)案例：新浪微博應(yīng)用「湖倉(cāng)一體」構(gòu)建混合云AI計(jì)算中臺(tái)

案例背景

微博機(jī)器學(xué)習(xí)平臺(tái)團(tuán)隊(duì)，主要做社交媒體領(lǐng)域里的推薦主要做社交媒體領(lǐng)域里的推薦/排序、文本/圖像分類(lèi)、反垃圾/反作弊等技術(shù)。

技術(shù)架構(gòu)上主要圍繞開(kāi)源Hadoop數(shù)據(jù)湖解決方案，一份HDFS存儲(chǔ)+多種計(jì)算引擎（hive、spark、flink），以滿足以AI為主的多計(jì)算場(chǎng)景需求。但微博作為國(guó)內(nèi)Top的社交媒體應(yīng)用，當(dāng)前的業(yè)務(wù)體量和復(fù)雜性已然進(jìn)入到開(kāi)源“無(wú)人區(qū)”，開(kāi)源數(shù)據(jù)湖方案在性能和成本方面都無(wú)法滿足微博的要求。

微博借助阿里巴巴強(qiáng)大的飛天大數(shù)據(jù)和AI平臺(tái)能力（MaxC+PAI+DW ），解決了超大規(guī)模下的特征工程、模型訓(xùn)練以及矩陣計(jì)算的性能瓶頸問(wèn)題，進(jìn)而形成了阿里巴巴MaxCompute平臺(tái)（數(shù)倉(cāng)）+ 開(kāi)源平臺(tái)（數(shù)據(jù)湖）共存的格局。

核心痛點(diǎn)

微博希望借助這兩套異構(gòu)的大數(shù)據(jù)平臺(tái)，既保持面向AI的各類(lèi)數(shù)據(jù)和計(jì)算的靈活性，又解決超大規(guī)模下的計(jì)算和算法的性能/成本問(wèn)題。但因?yàn)檫@兩套大數(shù)據(jù)平臺(tái)在集群層面完全是割裂的，數(shù)據(jù)和計(jì)算無(wú)法在兩個(gè)平臺(tái)里自由流動(dòng)，無(wú)形之中增加了大量的數(shù)據(jù)移動(dòng)和計(jì)算開(kāi)發(fā)等成本，進(jìn)而制約了業(yè)務(wù)的發(fā)展。

主要的痛點(diǎn)是：1）安排專(zhuān)人專(zhuān)項(xiàng)負(fù)責(zé)訓(xùn)練數(shù)據(jù)同步，工作量巨大 2） 訓(xùn)練數(shù)據(jù)體量大，導(dǎo)致耗時(shí)多，無(wú)法滿足實(shí)時(shí)訓(xùn)練的要求 3） 新寫(xiě)SQL數(shù)據(jù)處理query，無(wú)法復(fù)用Hive SQL原有query。

圖13. 新浪微博業(yè)務(wù)痛點(diǎn)示意

解決方案

為了解決上述的痛點(diǎn)問(wèn)題，阿里云產(chǎn)品團(tuán)隊(duì)和微博機(jī)器學(xué)習(xí)平臺(tái)團(tuán)隊(duì)聯(lián)合共建湖倉(cāng)一體新技術(shù)，打通了阿里巴巴MaxCompute云數(shù)倉(cāng)和EMR Hadoop數(shù)據(jù)湖，構(gòu)建了一個(gè)跨湖和倉(cāng)的AI計(jì)算中臺(tái)。

MaxCompute產(chǎn)品全面升級(jí)網(wǎng)絡(luò)基礎(chǔ)設(shè)施，打通用戶(hù)VPC私域，且依托Hive數(shù)據(jù)庫(kù)一鍵映射和強(qiáng)大完善的SQL/PAI引擎能力，將MaxCompute云數(shù)倉(cāng)和EMR Hadoop數(shù)據(jù)湖技術(shù)體系無(wú)縫對(duì)接，實(shí)現(xiàn)湖和的倉(cāng)統(tǒng)一且智能化管理和調(diào)度。

圖14. 微博湖倉(cāng)一體架構(gòu)圖

案例價(jià)值

不僅融合了數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)的優(yōu)勢(shì)，在靈活性和效率上找到最佳平衡，還快速構(gòu)建了一套統(tǒng)一的AI計(jì)算中臺(tái)，極大提升該機(jī)器學(xué)習(xí)平臺(tái)團(tuán)隊(duì)的業(yè)務(wù)支撐能力。無(wú)須進(jìn)行數(shù)據(jù)搬遷和作業(yè)遷移，即可將一套作業(yè)無(wú)縫靈活調(diào)度在MaxCompute集群和EMR集群中。

SQL數(shù)據(jù)處理任務(wù)被廣泛運(yùn)行到MaxCompute集群，性能有明顯提升?；诎⒗锇桶蚉AI豐富且強(qiáng)大的算法能力，封裝出多種貼近業(yè)務(wù)場(chǎng)景的算法服務(wù)，滿足更多的業(yè)務(wù)需求。

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

07 總結(jié)

數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)，是在今天大數(shù)據(jù)技術(shù)條件下構(gòu)建分布式系統(tǒng)的兩種數(shù)據(jù)架構(gòu)設(shè)計(jì)取向，要看平衡的方向是更偏向靈活性還是成本、性能、安全、治理等企業(yè)級(jí)特性。

但是數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)的邊界正在慢慢模糊，數(shù)據(jù)湖自身的治理能力、數(shù)據(jù)倉(cāng)庫(kù)延伸到外部存儲(chǔ)的能力都在加強(qiáng)。在這樣的背景之下，MaxCompute 率先提出湖倉(cāng)一體，為業(yè)界和用戶(hù)展現(xiàn)了一種數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)湖互相補(bǔ)充，協(xié)同工作的架構(gòu)。

這樣的架構(gòu)同時(shí)為用戶(hù)提供了數(shù)據(jù)湖的靈活性和數(shù)據(jù)倉(cāng)庫(kù)的諸多企業(yè)級(jí)特性，將用戶(hù)使用大數(shù)據(jù)的總體擁有成本進(jìn)一步降低，我們認(rèn)為是下一代大數(shù)據(jù)平臺(tái)的演進(jìn)方向。

審核編輯 ：李倩