https://m.sohu.com/a/420690978_355140/

近幾年坷牛，隨著數(shù)據(jù)湖概念的興起狞尔，業(yè)界對(duì)于數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖的對(duì)比甚至爭(zhēng)論始終不斷。數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖的區(qū)別到底是什么？本文作者來自阿里巴巴計(jì)算平臺(tái)部門整胃，在深度參與阿里巴巴大數(shù)據(jù) / 數(shù)據(jù)中臺(tái)領(lǐng)域建設(shè)之后赋秀，將對(duì)數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)的來龍去脈進(jìn)行深入剖析，闡述兩者融合演進(jìn)的新方向——湖倉(cāng)一體待榔。

大數(shù)據(jù) 20 年發(fā)展的變與不變

概述

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

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

數(shù)據(jù)保持高速增長(zhǎng)

大數(shù)據(jù)作為新的生產(chǎn)要素猾担，得到廣泛認(rèn)可

數(shù)據(jù)管理能力成為新的關(guān)注點(diǎn)

引擎技術(shù)進(jìn)入收斂期

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

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

縱觀大數(shù)據(jù)的發(fā)展歷史橘茉，可以看出數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖有著截然不同的發(fā)展脈絡(luò)工腋。大體上，計(jì)算機(jī)科學(xué)領(lǐng)域的數(shù)據(jù)處理技術(shù)的發(fā)展畅卓，主要分為四個(gè)階段：

階段一：數(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)期以來的高昂價(jià)格蹋肮，此時(shí)的數(shù)據(jù)倉(cāng)庫(kù)距離普通企業(yè)和用戶都還很遙遠(yuǎn)。人們甚至還在爭(zhēng)論數(shù)據(jù)倉(cāng)庫(kù)（統(tǒng)一集中管理）和數(shù)據(jù)集市（按部門璧疗、領(lǐng)域的集中管理）哪個(gè)更具可行性坯辩。

階段二：大數(shù)據(jù)技術(shù)的「探索期」。2000 年左右病毡，隨著互聯(lián)網(wǎng)的爆發(fā)濒翻，動(dòng)輒幾十億、上百億的頁(yè)面以及海量的用戶點(diǎn)擊行為啦膜，開啟了全球的數(shù)據(jù)量急劇增加的新時(shí)代有送。傳統(tǒng)的數(shù)據(jù)庫(kù)方案再也無力以可接受的成本提供計(jì)算力，巨大的數(shù)據(jù)處理需求開始尋找突破口僧家，大數(shù)據(jù)時(shí)代開始萌芽雀摘。Google 先后發(fā)表 3 篇經(jīng)典論文（GFS、MapReduce八拱、BigTable）阵赠，奠基了這個(gè)大數(shù)據(jù)時(shí)代的基本技術(shù)框架，即分布式存儲(chǔ)肌稻、分布式調(diào)度以及分布式計(jì)算模型清蚀。隨后，幾乎是在同一時(shí)期爹谭，誕生了包括 Google枷邪，微軟 Cosmos 以及開源 Hadoop 為代表的優(yōu)秀分布式技術(shù)體系，當(dāng)然诺凡，這其中也包括阿里巴巴的飛天系統(tǒng)东揣。此時(shí)人們興奮于追求數(shù)據(jù)的處理規(guī)模，即『大』數(shù)據(jù)腹泌，沒有閑暇爭(zhēng)論是數(shù)據(jù)倉(cāng)庫(kù)還是數(shù)據(jù)湖嘶卧。

階段三：大數(shù)據(jù)技術(shù)的「發(fā)展期」。21 世紀(jì)第二個(gè) 10 年凉袱，隨著越來越多的資源投入到大數(shù)據(jù)計(jì)算領(lǐng)域芥吟，大數(shù)據(jù)技術(shù)進(jìn)入一個(gè)蓬勃發(fā)展的階段，整體開始從能用轉(zhuǎn)向好用。代替手寫 MapReduce 作業(yè)运沦，是如雨后春筍般出現(xiàn)的各種以 SQL 為表達(dá)的計(jì)算引擎泵额，極大降低了大數(shù)據(jù)技術(shù)的使用成本，數(shù)據(jù)庫(kù)時(shí)代人們夢(mèng)想的大一統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)終于成為現(xiàn)實(shí)携添，各種數(shù)據(jù)庫(kù)時(shí)代的方法論開始抬頭。這個(gè)時(shí)期技術(shù)路線開始出現(xiàn)細(xì)分篓叶。云廠商主推的如 AWS Redshift烈掠、Google BigQuery，包括 MaxCompute 這樣的集成系統(tǒng)稱為大數(shù)據(jù)時(shí)代的數(shù)據(jù)倉(cāng)庫(kù)缸托。而以開源 Hadoop 體系為代表的的開放式 HDFS 存儲(chǔ)左敌、開放的文件格式、開放的元數(shù)據(jù)服務(wù)以及多種引擎（Hive俐镐、Presto矫限、Spark、Flink 等）協(xié)同工作的模式佩抹，則形成了數(shù)據(jù)湖的雛形叼风。

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

開源 Hadoop 線，引擎溉卓、元數(shù)據(jù)皮迟、存儲(chǔ)等基礎(chǔ)部件的迭代更替進(jìn)入相對(duì)穩(wěn)態(tài)，大眾對(duì)開源大數(shù)據(jù)技術(shù)的認(rèn)知達(dá)到空前的水平桑寨。一方面伏尼，開放架構(gòu)的便利帶來了不錯(cuò)的市場(chǎng)份額，另一方面開放架構(gòu)的松散則使開源方案在企業(yè)級(jí)能力構(gòu)建上遇到瓶頸尉尾，尤其是數(shù)據(jù)安全爆阶、身份權(quán)限強(qiáng)管控、數(shù)據(jù)治理等方面，協(xié)同效率較差辨图。同時(shí)引擎自身的發(fā)展也對(duì)已有的開放架構(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 為引擎的開放協(xié)作式的產(chǎn)品解決方案猿规。它的開放性和開源體系類似，并在 2019 年推出 Lake Formation 解決產(chǎn)品間的安全授信問題宙橱。這套架構(gòu)對(duì)于開源技術(shù)體系的用戶來說姨俩，架構(gòu)相近理解容易，仍然相當(dāng)有吸引力师郑。AWS 之后环葵，各個(gè)云廠商也紛紛跟進(jìn)數(shù)據(jù)湖的概念，并在自己的云服務(wù)上提供類似的產(chǎn)品解決方案呕乎。

云廠商主推的數(shù)據(jù)倉(cāng)庫(kù)類產(chǎn)品則發(fā)展良好积担，數(shù)倉(cāng)核心能力方面持續(xù)增強(qiáng)。性能猬仁、成本方面極大提升（如 MaxCompute 連續(xù)三年刷新 TPCx-BigBench 世界記錄）帝璧，數(shù)據(jù)管理能力空前增強(qiáng)（發(fā)展出數(shù)據(jù)中臺(tái)建模理論和智能數(shù)倉(cāng)），企業(yè)級(jí)安全能力大為繁榮（如細(xì)粒度數(shù)據(jù)安全控制湿刽、服務(wù)可用性 SLA 等）的烁，在聯(lián)邦計(jì)算方面也普遍做了增強(qiáng)，一定程度上開始將非數(shù)倉(cāng)自身存儲(chǔ)的數(shù)據(jù)納入管理诈闺，和數(shù)據(jù)湖的邊界日益模糊渴庆。

綜上所述，數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖是伴隨著大數(shù)據(jù)技術(shù)發(fā)展，進(jìn)化而來的兩種不同的大數(shù)據(jù)平臺(tái)技術(shù)，有著各自的特點(diǎn)和應(yīng)用場(chǎng)景岳瞭，在企業(yè)數(shù)字化建設(shè)中均扮演著重要的角色。

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

數(shù)據(jù)湖的本質(zhì)和技術(shù)架構(gòu)演進(jìn)

近幾年數(shù)據(jù)湖的概念非乘逝火熱，各家對(duì)數(shù)據(jù)湖的定義不盡相同卓缰，但不論如何计呈，數(shù)據(jù)湖的本質(zhì)其實(shí)都包含如下四部分：

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

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

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

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

從上述四個(gè)標(biāo)準(zhǔn)判斷砰诵，開源大數(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)過程击罪，整體上可分為三個(gè)階段：

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

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

階段二：云上托管 Hadoop 數(shù)據(jù)湖架構(gòu)（即 EMR 開源數(shù)據(jù)湖），底層物理服務(wù)器和開源軟件版本由云廠商提供和管理霍弹，數(shù)據(jù)仍統(tǒng)一存放在 HDFS 系統(tǒng)上毫别，引擎以 Hadoop 和 Spark 開源生態(tài)為主。這個(gè)架構(gòu)通過云上 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ì)算耦合在一起砾肺，兩種資源無法獨(dú)立擴(kuò)展。

階段三：云上數(shù)據(jù)湖架構(gòu)防嗡，即云上純托管的存儲(chǔ)系統(tǒng)逐步取代 HDFS变汪，成為數(shù)據(jù)湖的存儲(chǔ)基礎(chǔ)設(shè)施，并且引擎豐富度也不斷擴(kuò)展蚁趁。除了 Hadoop 和 Spark 的生態(tài)引擎之外裙盾，各云廠商還發(fā)展出面向數(shù)據(jù)湖探查分析產(chǎn)品。這個(gè)架構(gòu)仍然保持了一個(gè)存儲(chǔ)和多個(gè)引擎的特性他嫡，相對(duì)于原生 HDFS 的數(shù)據(jù)湖架構(gòu)的優(yōu)勢(shì)在于：

幫助用戶擺脫原生 HDFS 系統(tǒng)運(yùn)維困難的問題番官。分離后的存儲(chǔ)系統(tǒng)可以獨(dú)立擴(kuò)展，不再需要與計(jì)算耦合钢属，可降低整體成本當(dāng)用戶采用數(shù)據(jù)湖架構(gòu)之后徘熔，客觀上也幫助客戶完成了存儲(chǔ)統(tǒng)一化（解決多個(gè) HDFS 數(shù)據(jù)孤島的問題）。

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

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

數(shù)據(jù)倉(cāng)庫(kù)的概念最早來源于數(shù)據(jù)庫(kù)領(lǐng)域署咽，主要處理面向數(shù)據(jù)的復(fù)雜查詢和分析場(chǎng)景近顷。隨著大數(shù)據(jù)技術(shù)發(fā)展生音，大量借鑒數(shù)據(jù)庫(kù)的技術(shù)，例如 SQL 語(yǔ)言窒升、查詢優(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ù)的資源供給問題。云數(shù)據(jù)倉(cāng)庫(kù)作為大數(shù)據(jù)的高階（企業(yè)級(jí)）平臺(tái)能力酪呻，因其開箱即用减宣、無限擴(kuò)展、簡(jiǎn)易運(yùn)維等能力玩荠，越來越受到人們的矚目漆腌。

筆者認(rèn)為，數(shù)據(jù)倉(cāng)庫(kù)的本質(zhì)包含如下三部分：

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

數(shù)據(jù)需要清洗和轉(zhuǎn)化女坑，通常采用 ETL/ELT 方式填具；

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

從上述的標(biāo)準(zhǔn)判斷劳景，無論傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)還是新興的云數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)（AWS Redshift、Google BigQuery绰筛、阿里云 MaxCompute）均體現(xiàn)了數(shù)倉(cāng)的設(shè)計(jì)本質(zhì)枢泰，它們均沒有對(duì)外暴露文件系統(tǒng)，而是提供了數(shù)據(jù)進(jìn)出的服務(wù)接口铝噩。這個(gè)設(shè)計(jì)可以帶來多個(gè)優(yōu)勢(shì)：

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

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

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

完善的元數(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)，又是阿里云上的在線大數(shù)據(jù)計(jì)算服務(wù)（百度搜索阿里云官網(wǎng) - 左側(cè)大數(shù)據(jù)與人工智能選擇 MaxCompute）一姿。

圖 5. 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)』壤可以說先较，作為最早數(shù)據(jù)中臺(tái)概念的提出者，阿里巴巴的數(shù)據(jù)中臺(tái)得益于數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)悼粮。

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

數(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)訪問菜循、權(quán)限管理、建模要求等方面的把控申尤。

數(shù)據(jù)湖優(yōu)先的設(shè)計(jì)债朵，通過開放底層文件存儲(chǔ)，給數(shù)據(jù)入湖帶來了最大的靈活性瀑凝。進(jìn)入數(shù)據(jù)湖的數(shù)據(jù)可以是結(jié)構(gòu)化的，也可以是半結(jié)構(gòu)化的臭杰，甚至可以是完全非結(jié)構(gòu)化的原始日志粤咪。另外，開放存儲(chǔ)給上層的引擎也帶來了更多的靈活度渴杆，各種引擎可以根據(jù)自己針對(duì)的場(chǎng)景隨意讀寫數(shù)據(jù)湖中存儲(chǔ)的數(shù)據(jù)寥枝，而只需要遵循相當(dāng)寬松的兼容性約定（這樣的松散約定當(dāng)然會(huì)有隱患，后文會(huì)提到）磁奖。但同時(shí)囊拜，文件系統(tǒng)直接訪問使得很多更高階的功能很難實(shí)現(xiàn)，例如比搭，細(xì)粒度（小于文件粒度）的權(quán)限管理冠跷、統(tǒng)一化的文件管理和讀寫接口升級(jí)也十分困難（需要完成每一個(gè)訪問文件的引擎升級(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)過統(tǒng)一但開放的服務(wù)接口進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)，數(shù)據(jù)通常預(yù)先定義 schema穴亏，用戶通過數(shù)據(jù)服務(wù)接口或者計(jì)算引擎訪問分布式存儲(chǔ)系統(tǒng)中的文件蜂挪。數(shù)據(jù)倉(cāng)庫(kù)優(yōu)先的設(shè)計(jì)通過抽象數(shù)據(jù)訪問接口 / 權(quán)限管理 / 數(shù)據(jù)本身重挑，來?yè)Q取更高的性能（無論是存儲(chǔ)還是計(jì)算）、閉環(huán)的安全體系棠涮、數(shù)據(jù)治理的能力等谬哀，這些能力對(duì)于企業(yè)長(zhǎng)遠(yuǎn)的大數(shù)據(jù)使用都至關(guān)重要，我們稱之為成長(zhǎng)性故爵。

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

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

靈活性和成長(zhǎng)性诬垂，對(duì)于處于不同時(shí)期的企業(yè)來說劲室，重要性不同。

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

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

很多企業(yè)（尤其是新興的互聯(lián)網(wǎng)行業(yè)）正在經(jīng)歷這樣一個(gè)從探索創(chuàng)新到成熟建模的過程。在這個(gè)過程中桶良，因?yàn)閿?shù)據(jù)湖架構(gòu)太過靈活而缺少對(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ù)治理等問題。

阿里巴巴的數(shù)據(jù)中臺(tái)戰(zhàn)略缩焦，正是在 2015 年前后阿里巴巴全集團(tuán)完成 MaxCompute（數(shù)據(jù)倉(cāng)庫(kù)） 對(duì)多個(gè) Hadoop（ 數(shù)據(jù)湖）的完全替換（登月項(xiàng)目）才逐步形成的读虏。

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

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

經(jīng)過對(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)用戶友好灾螃，一個(gè)成長(zhǎng)性更佳。對(duì)企業(yè)來說揩徊，數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)是否必須是一個(gè)二選一的選擇題腰鬼？是否能有一種方案同時(shí)兼顧數(shù)據(jù)湖的靈活性和云數(shù)據(jù)倉(cāng)庫(kù)的成長(zhǎng)性，將二者有效結(jié)合起來為用戶實(shí)現(xiàn)更低的總體擁有成本塑荒？

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

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

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

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

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

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

2011 年赏参，Hadoop 開源體系公司 Hortonworks 開始了 Apache Atlas 和 Ranger 兩個(gè)開源項(xiàng)目的開發(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ù)湖具備與生俱來的靈活性紊浩。例如 Ranger 作為數(shù)據(jù)權(quán)限安全統(tǒng)一管理的組件窖铡，天然要求所有引擎均適配它才能保證沒有安全漏洞，但對(duì)于數(shù)據(jù)湖中強(qiáng)調(diào)靈活的引擎坊谁，尤其是新引擎來說费彼，會(huì)優(yōu)先實(shí)現(xiàn)功能、場(chǎng)景口芍，而不是把對(duì)接 Ranger 作為第一優(yōu)先級(jí)的目標(biāo)箍铲，使得 Ranger 在數(shù)據(jù)湖上的位置一直很尷尬。

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

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

圖 9. Hudi Support Matrix（來自網(wǎng)絡(luò)）

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

上述在數(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ì)唯竹，開始基于融合兩者的思路進(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)鍵問題：

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

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

數(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è)問題。

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

整體架構(gòu)

阿里云 MaxCompute 在原有的數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)上松嘶，融合了開源數(shù)據(jù)湖和云上數(shù)據(jù)湖艘狭，最終實(shí)現(xiàn)了湖倉(cāng)一體化的整體架構(gòu)（圖 10）。在該架構(gòu)中翠订，盡管底層多套存儲(chǔ)系統(tǒng)并存巢音，但通過統(tǒng)一的存儲(chǔ)訪問層和統(tǒng)一的元數(shù)據(jù)管理，向上層引擎提供一體的封裝接口尽超，用戶可以同時(shí)查詢數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖中的表官撼。

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

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

快速接入

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

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

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

MaxCompute 實(shí)現(xiàn)湖倉(cāng)一體化的元數(shù)據(jù)管理，通過 DB 元數(shù)據(jù)一鍵映射技術(shù)屈梁，實(shí)現(xiàn)數(shù)據(jù)湖和 MaxCompute 數(shù)倉(cāng)的元數(shù)據(jù)無縫打通，無須聯(lián)邦查詢方式里的人工操作榛了。MaxCompute 通過向用戶開放創(chuàng)建 external project 的形式在讶，將數(shù)據(jù)湖 HiveMetaStore 中的整個(gè) database 直接映射為 MaxCompute 的 project，對(duì) Hive Database 的改動(dòng)會(huì)實(shí)時(shí)反應(yīng)在這個(gè) project 中霜大。與此同時(shí)构哺，阿里云 EMR 數(shù)據(jù)湖解決方案在今年云棲大會(huì)也推出了 Data Lake Formation，湖倉(cāng)一體方案也會(huì)支持對(duì)該數(shù)據(jù)湖中的統(tǒng)一元數(shù)據(jù)服務(wù)的一鍵映射能力。

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

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

數(shù)據(jù)湖里的 Hive DataBase 映射為 MaxCompute external project娜扇，和普通 project 別無二致错沃，同樣享受 MaxCompute 數(shù)倉(cāng)里的數(shù)據(jù)開發(fā)、追蹤和管理功能雀瓢∈辔觯基于 DataWorks 強(qiáng)大的數(shù)據(jù)開發(fā) / 管理 / 治理能力，提供統(tǒng)一的湖倉(cāng)開發(fā)體驗(yàn)刃麸，降低兩套系統(tǒng)的管理成本醒叁。

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

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

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

構(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)之上無縫調(diào)度和管理牙瓢。

企業(yè)可以使用湖倉(cāng)一體化的數(shù)據(jù)中臺(tái)能力，優(yōu)化數(shù)據(jù)管理架構(gòu)间校，充分融合數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)各自優(yōu)勢(shì)矾克。使用數(shù)據(jù)湖做集中式的原始數(shù)據(jù)存儲(chǔ)，發(fā)揮數(shù)據(jù)湖的靈活和開放優(yōu)勢(shì)憔足。又通過湖倉(cāng)一體技術(shù)將面向生產(chǎn)的高頻數(shù)據(jù)和任務(wù)胁附，無縫調(diào)度到數(shù)據(jù)倉(cāng)庫(kù)中，以得到更好的性能和成本滓彰，以及后續(xù)一系列面向生產(chǎn)的數(shù)據(jù)治理和優(yōu)化控妻，最終讓企業(yè)在成本和效率之間找到最佳平衡。既適用于全新構(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)利舊郎哭。

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

新浪微博的”湖倉(cāng)一體“應(yīng)用

微博機(jī)器學(xué)習(xí)平臺(tái)團(tuán)隊(duì)，主要做社交媒體領(lǐng)域里的推薦主要做社交媒體領(lǐng)域里的推薦 / 排序菇存、文本 / 圖像分類夸研、反垃圾 / 反作弊等技術(shù)。技術(shù)架構(gòu)上主要圍繞開源 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)入到開源“無人區(qū)”关筒，開源數(shù)據(jù)湖方案在性能和成本方面都無法滿足微博的要求溶握。微博借助阿里巴巴飛天大數(shù)據(jù)和 AI 平臺(tái)能力（MaxCompute+PAI+DataWorks ），解決了超大規(guī)模下的特征工程蒸播、模型訓(xùn)練以及矩陣計(jì)算的性能瓶頸問題睡榆，進(jìn)而形成了阿里巴巴 MaxCompute 平臺(tái)（數(shù)倉(cāng)）+ 開源平臺(tái)（數(shù)據(jù)湖）共存的格局。

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

主要的痛點(diǎn)是：

安排專人專項(xiàng)負(fù)責(zé)訓(xùn)練數(shù)據(jù)同步葡兑，工作量巨大；

訓(xùn)練數(shù)據(jù)體量大赞草，導(dǎo)致耗時(shí)多讹堤，無法滿足實(shí)時(shí)訓(xùn)練的要求；

新寫 SQL 數(shù)據(jù)處理 query厨疙，無法復(fù)用 Hive SQL 原有 query洲守。

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

為了解決上述的痛點(diǎ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è)施撒蟀，打通用戶 VPC 私域叙谨，且依托 Hive 數(shù)據(jù)庫(kù)一鍵映射和強(qiáng)大完善的 SQL/PAI 引擎能力，將 MaxCompute 云數(shù)倉(cāng)和 EMR Hadoop 數(shù)據(jù)湖技術(shù)體系無縫對(duì)接牙肝，實(shí)現(xiàn)湖和倉(cāng)的統(tǒng)一且智能化管理和調(diào)度。

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

這套體系不僅融合了數(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ù)支撐能力。無須進(jìn)行數(shù)據(jù)搬遷和作業(yè)遷移股缸，即可將一套作業(yè)無縫靈活調(diào)度在 MaxCompute 集群和 EMR 集群中衡楞。

SQL 數(shù)據(jù)處理任務(wù)被廣泛運(yùn)行到 MaxCompute 集群，性能有明顯提升敦姻●常基于阿里巴巴 PAI 豐富且強(qiáng)大的算法能力，封裝出多種貼近業(yè)務(wù)場(chǎng)景的算法服務(wù)镰惦，滿足更多的業(yè)務(wù)需求迷守。

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

總 結(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è)界和用戶展現(xiàn)了一種數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)湖互相補(bǔ)充，協(xié)同工作的架構(gòu)突照。這樣的架構(gòu)同時(shí)為用戶提供了數(shù)據(jù)湖的靈活性和數(shù)據(jù)倉(cāng)庫(kù)的諸多企業(yè)級(jí)特性帮非，將用戶使用大數(shù)據(jù)的總體擁有成本進(jìn)一步降低，我們認(rèn)為是下一代大數(shù)據(jù)平臺(tái)的演進(jìn)方向讹蘑。