柚子快報激活碼778899分享：數(shù)據(jù)湖和數(shù)據(jù)倉庫核心概念與對比

http://yzkb.51969.com/

隨著近幾年數(shù)據(jù)湖概念的興起，業(yè)界對于數(shù)據(jù)倉庫和數(shù)據(jù)湖的對比甚至爭論就一直不斷。有人說數(shù)據(jù)湖是下一代大數(shù)據(jù)平臺，各大云廠商也在紛紛的提出自己的數(shù)據(jù)湖解決方案，一些云數(shù)倉產(chǎn)品也增加了和數(shù)據(jù)湖聯(lián)動的特性。但是數(shù)據(jù)倉庫和數(shù)據(jù)湖的區(qū)別到底是什么，二者是水火不容還是互為補充？本文從歷史的角度對數(shù)據(jù)湖和數(shù)據(jù)倉庫的來龍去脈進行剖析，來闡述兩者融合演進的新方向——湖倉一體，并就主流大廠設計方案進行介紹。

大數(shù)據(jù)領域回顧

概述

大數(shù)據(jù)領域從本世紀初發(fā)展到現(xiàn)在，觀察其中的發(fā)展規(guī)律，可以高度概括成如下五個方面：

1. 數(shù)據(jù)保持高速增長 - 從5V核心要素看，大數(shù)據(jù)領域保持高速增長，對于新興企業(yè)，大數(shù)據(jù)領域增長超過年200%。

2. 大數(shù)據(jù)作為新的生產(chǎn)要素，得到廣泛認可 - 大數(shù)據(jù)領域價值定位的遷移，從“探索”到“普惠”，成為各個企業(yè)/政府的核心部門，并承擔關鍵任務。

3. 數(shù)據(jù)管理能力成為新的關注點 - 數(shù)倉（中臺）能力流行起來，如何用好數(shù)據(jù)成為企業(yè)的核心競爭力。

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

5. 平臺技術演進出兩個趨勢，數(shù)據(jù)湖 VS 數(shù)據(jù)倉庫 - 兩者均關注數(shù)據(jù)存儲和管理（平臺技術），但方向不同。

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

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

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

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

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

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

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

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

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

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

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

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

開源 Hadoop 線，引擎、元數(shù)據(jù)、存儲等基礎部件的迭代更替進入相對穩(wěn)態(tài)，大眾對開源大數(shù)據(jù)技術的認知達到空前的水平。一方面，開放架構的便利帶來了不錯的市場份額，另一方面開放架構的松散則使開源方案在企業(yè)級能力構建上遇到瓶頸，尤其是數(shù)據(jù)安全、身份權限強管控、數(shù)據(jù)治理等方面，協(xié)同效率較差（如 Ranger 作為權限管控組件、Atlas 作為數(shù)據(jù)治理組件，跟今天的主流引擎竟然還無法做到全覆蓋）。同時引擎自身的發(fā)展也對已有的開放架構提出了更多挑戰(zhàn)，Delta Lake、Hudi 這樣自閉環(huán)設計的出現(xiàn)使得一套存儲、一套元數(shù)據(jù)、多種引擎協(xié)作的基礎出現(xiàn)了某種程度的裂痕。真正將數(shù)據(jù)湖概念推而廣之的是AWS。AWS 構筑了一套以 S3 為中心化存儲、Glue 為元數(shù)據(jù)服務，E-MapReduce、Athena 為引擎的開放協(xié)作式的產(chǎn)品解決方案。它的開放性和和開源體系類似，并在2019年推出Lake Formation 解決產(chǎn)品間的安全授信問題。雖然這套架構在企業(yè)級能力上和相對成熟的云數(shù)據(jù)倉庫產(chǎn)品相去甚遠，但對于開源技術體系的用戶來說，架構相近理解容易，還是很有吸引力。AWS 之后，各個云廠商也紛紛跟進數(shù)據(jù)湖的概念，并在自己的云服務上提供類似的產(chǎn)品解決方案。云廠商主推的數(shù)據(jù)倉庫類產(chǎn)品則發(fā)展良好，數(shù)倉核心能力方面持續(xù)增強。性能、成本方面極大提升（MaxCompute 完成了核心引擎的全面升級和性能跳躍式發(fā)展，連續(xù)三年刷新 TPCx-BigBench 世界記錄），數(shù)據(jù)管理能力空前增強（數(shù)據(jù)中臺建模理論、智能數(shù)倉），企業(yè)級安全能力大為繁榮（同時支持基于 ACL 和基于規(guī)則等多種授權模型，列級別細粒度授權，可信計算，存儲加密，數(shù)據(jù)脫敏等），在聯(lián)邦計算方面也普遍做了增強，一定程度上開始將非數(shù)倉自身存儲的數(shù)據(jù)納入管理，和數(shù)據(jù)湖的邊界日益模糊。

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

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

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

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

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

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

AWS的定義相對簡潔：

數(shù)據(jù)湖是一個集中式存儲庫，允許您以任意規(guī)模存儲所有結構化和非結構化數(shù)據(jù)。您可以按原樣存儲數(shù)據(jù)（無需先對數(shù)據(jù)進行結構化處理），并運行不同類型的分析 – 從控制面板和可視化到大數(shù)據(jù)處理、實時分析和機器學習，以指導做出更好的決策。

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

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

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

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

3. 豐富的計算模型/范式

4. 數(shù)據(jù)湖與上云無關

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

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

圖3. 數(shù)據(jù)湖技術架構演進

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

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

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

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

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

幫助用戶擺脫原生HDFS系統(tǒng)運維困難的問題。HDFS系統(tǒng)運維有兩個困難：1）存儲系統(tǒng)相比計算引擎更高的穩(wěn)定性要求和更高的運維風險 2）與計算混布在一起，帶來的擴展彈性問題。存儲計算分離架構幫助用戶解耦存儲，并交由云廠商統(tǒng)一運維管理，解決了穩(wěn)定性和運維問題。分離后的存儲系統(tǒng)可以獨立擴展，不再需要與計算耦合，可降低整體成本當用戶采用數(shù)據(jù)湖架構之后，客觀上也幫助客戶完成了存儲統(tǒng)一化（解決多個HDFS數(shù)據(jù)孤島的問題）

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

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

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

圖5. 數(shù)據(jù)湖架構圖（來自網(wǎng)絡）

什么數(shù)據(jù)倉庫

數(shù)倉的主要作用就是提供數(shù)據(jù)支撐，形成數(shù)據(jù)集進行報表展示，可視化管理，為企業(yè)戰(zhàn)略提供數(shù)據(jù)支撐。

Wikipedia對數(shù)據(jù)倉庫的定義：

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

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

包括如下概念：

ODS層(Operational Data Store)：“操作數(shù)據(jù)存儲”，它是數(shù)據(jù)倉庫體系結構中的一個重要組成部分。ODS層位于源系統(tǒng)和數(shù)據(jù)倉庫之間，它旨在提供一個介于實時操作系統(tǒng)和數(shù)據(jù)倉庫之間的中間層，用于存儲和維護最新的業(yè)務操作數(shù)據(jù)。

DWD（Data Warehouse Detail）：存儲詳細數(shù)據(jù)，通常采用事實表和維度表的結構。

DWM（Data Warehouse Middle）：存儲經(jīng)過輕度匯總的數(shù)據(jù)，用于支持部門級別的數(shù)據(jù)分析。

DWS（Data Warehouse Service）：按照主題業(yè)務組織主題寬表,用于OLAP分析

DM（Data Market）：存儲高度匯總的數(shù)據(jù)，用于支持企業(yè)級別的數(shù)據(jù)報告和分析。 形成一個主題域的報表數(shù)據(jù)

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

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

數(shù)據(jù)倉庫的本質包含如下三部分： ?

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

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

3. 強調建模和數(shù)據(jù)管理，供商業(yè)智能決策。

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

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

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

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

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

4. 完善的元數(shù)據(jù)管理能力，易于構建企業(yè)級數(shù)據(jù)中臺。

阿里巴巴飛天大數(shù)據(jù)平臺采用了數(shù)據(jù)倉庫的架構，即MaxCompute大數(shù)據(jù)平臺。MaxCompute（原ODPS)，實現(xiàn)阿里云上一種安全可靠、高效能、低成本、從GB到EB級別按需彈性伸縮的在線大數(shù)據(jù)計算服務（圖6.是MaxCompute產(chǎn)品架構，具體詳情請點擊阿里云MaxCompute官網(wǎng)地址）。

圖6. MaxCompute云數(shù)倉產(chǎn)品架構

得益于MaxCompute數(shù)據(jù)倉庫的架構，阿里巴巴上層逐步構建了“數(shù)據(jù)安全體系”、“數(shù)據(jù)質量”、“數(shù)據(jù)治理”、“數(shù)據(jù)標簽”等管理能力，并最終形成了阿里巴巴的大數(shù)據(jù)中臺。可以說，作為最早數(shù)據(jù)中臺概念的提出者，阿里巴巴的數(shù)據(jù)中臺得益于數(shù)據(jù)倉庫的架構。

圖7. 阿里巴巴數(shù)據(jù)中臺架構

數(shù)據(jù)湖 VS 數(shù)據(jù)倉庫

綜上，數(shù)據(jù)倉庫和數(shù)據(jù)湖，是大數(shù)據(jù)架構的兩種設計取向。兩者在設計的根本分歧點是對包括存儲系統(tǒng)訪問、權限管理、建模要求等方面的把控。 ?

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

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

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

數(shù)據(jù)倉庫優(yōu)先的設計通過抽象數(shù)據(jù)訪問接口/權限管理/數(shù)據(jù)本身，來換取更高的性能（無論是存儲還是計算）、閉環(huán)的安全體系、數(shù)據(jù)治理的能力等，這些能力對于企業(yè)長遠的大數(shù)據(jù)使用都至關重要，我們稱之為成長性。

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

圖8. 數(shù)據(jù)湖和數(shù)據(jù)倉庫在技術棧上的對比

靈活性和成長性，對于處于不同時期的企業(yè)來說，重要性不同。

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

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

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

最后只有遷移到數(shù)據(jù)倉庫優(yōu)先設計的大數(shù)據(jù)平臺，才解決了業(yè)務成長到一定規(guī)模后所出現(xiàn)的運維、成本、數(shù)據(jù)治理等問題。

圖9. 數(shù)據(jù)湖的靈活性 VS 數(shù)據(jù)倉庫的成長性的示意圖

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

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

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

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

1. 數(shù)倉支持數(shù)據(jù)湖訪問

2017年Redshift推出Redshift Spectrum，支持Redsift數(shù)倉用戶訪問S3數(shù)據(jù)湖的數(shù)據(jù)。2018年阿里云MaxCompute推出外表能力，支持訪問包括OSS/OTS/RDS數(shù)據(jù)庫在內(nèi)的多種外部存儲。

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

2. 數(shù)據(jù)湖支持數(shù)倉能力

2011年，Hadoop開源體系公司Hortonworks開始了Apache Atlas和Ranger兩個開源項目的開發(fā)，分別對應數(shù)據(jù)血緣追蹤和數(shù)據(jù)權限安全兩個數(shù)倉核心能力。但兩個項目發(fā)展并不算順利，直到 2017 年才完成孵化，時至今日，在社區(qū)和工業(yè)界的部署都還遠遠不夠活躍。核心原因數(shù)據(jù)湖與生俱來的靈活性。例如Ranger作為數(shù)據(jù)權限安全統(tǒng)一管理的組件，天然要求所有引擎均適配它才能保證沒有安全漏洞，但對于數(shù)據(jù)湖中強調靈活的引擎，尤其是新引擎來說，會優(yōu)先實現(xiàn)功能、場景，而不是把對接Ranger作為第一優(yōu)先級的目標，使得Ranger在數(shù)據(jù)湖上的位置一直很尷尬。2018年，Nexflix開源了內(nèi)部增強版本的元數(shù)據(jù)服務系統(tǒng)Iceberg，提供包括MVCC（多版本并發(fā)控制）在內(nèi)的增強數(shù)倉能力，但因為開源HMS已經(jīng)成為事實標準，開源版本的Iceberg作為插件方式兼容并配合HMS，數(shù)倉管理能力大打折扣。2018-2019年，Uber和Databricks相繼推出了Apache Hudi和DeltaLake，推出增量文件格式用以支持Update/Insert、事務等數(shù)據(jù)倉庫功能。新功能帶來文件格式以及組織形式的改變，打破了數(shù)據(jù)湖原有多套引擎之間關于共用存儲的簡單約定。為此，Hudi為了維持兼容性，不得不發(fā)明了諸如 Copy-On-Write、Merge-On-Read 兩種表，Snapshot Query、Incremental Query、Read Optimized Query 三種查詢類型，并給出了一個支持矩陣（如圖10），極大提升了使用的復雜度。

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

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

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

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

構建湖倉一體需要解決三個關鍵問題：

1. 湖和倉的數(shù)據(jù)/元數(shù)據(jù)無縫打通，且不需要用戶人工干預。

2. 湖和倉有統(tǒng)一的開發(fā)體驗，存儲在不同系統(tǒng)的數(shù)據(jù)，可以通過一個統(tǒng)一的開發(fā)/管理平臺操作。

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

柚子快報激活碼778899分享：數(shù)據(jù)湖和數(shù)據(jù)倉庫核心概念與對比

http://yzkb.51969.com/

參考文章