很多人跟我一樣，對于數(shù)據(jù)湖充滿好奇，也許還讀了不少數(shù)據(jù)湖文章，但無論別人怎么說，你還是會覺得難以把握數(shù)據(jù)湖的本質(zhì)。

有些人會望文生義說，數(shù)據(jù)湖嘛，就是什么東西都可以往里面扔，特別是對非結構數(shù)據(jù)的處理比較方便。

是這樣嗎?

有案例才有鑒別，有的人找了數(shù)據(jù)湖的作者AWS來說明數(shù)據(jù)湖是什么東西，比如下圖：

不懂數(shù)據(jù)的人也許會覺得數(shù)據(jù)湖很厲害，而懂數(shù)據(jù)的人也許會覺得僅是一堆數(shù)據(jù)倉庫技術的堆砌包裝而已，你看上面那張框架圖，哪個專業(yè)詞匯數(shù)據(jù)人士會不懂?憑什么數(shù)據(jù)湖被炒作成了一個新概念?

有比較才有鑒別，因此很多文章對數(shù)據(jù)湖與數(shù)據(jù)倉庫做了比較，下面是網(wǎng)上流傳的一些說法：

這種比較似乎能找到點區(qū)別，又會覺得隔靴搔癢，難道結構化與非結構化就成了數(shù)據(jù)倉庫和數(shù)據(jù)湖的一個主要區(qū)別?BI和機器學習成為了主要區(qū)別?

事實上，這種比較有較大邏輯漏洞：即是從結果出發(fā)來看差異，然后又用這個差異來說明區(qū)別，顛倒了因果，因此受到了不少專業(yè)人士的鄙視。比如AWS的數(shù)據(jù)湖能夠處理非結構化數(shù)據(jù)，而數(shù)據(jù)倉庫無法處理非結構化數(shù)據(jù)，就認為這是數(shù)據(jù)湖與數(shù)據(jù)倉庫的本質(zhì)區(qū)別之一。

筆者這次較了一下真，來跟大家聊聊我所理解的數(shù)據(jù)湖的本質(zhì)，對于一種新事物不了解本質(zhì)，你就很難駕馭它，更別說實踐它了，下面這張圖道盡了一切。

下面我用一篇文章來具體說明數(shù)據(jù)湖與數(shù)據(jù)倉庫的區(qū)別，更多的是給出why，知其所以然是我理解事物的一個原則。

數(shù)據(jù)倉庫和數(shù)據(jù)湖的處理流程可以用下圖來示意，其中用紅圈標出了5個對標的流程節(jié)點。

可以看到，數(shù)據(jù)湖并不比數(shù)據(jù)倉庫在處理流程上多出了什么內(nèi)容，更多的在于結構性的變化，下面就從數(shù)據(jù)存儲、模型設計、加工工具、開發(fā)人員和消費人員五個方面來進行比較。

(1)數(shù)據(jù)存儲

數(shù)據(jù)倉庫采集、處理過程中存儲下來的數(shù)據(jù)一般是以結構化的形式存在的，即使原始數(shù)據(jù)是非結構化的，但這些非結構化數(shù)據(jù)也只是在源頭暫存一下，它通過結構化數(shù)據(jù)的形式進入數(shù)據(jù)倉庫，成了數(shù)據(jù)倉庫的基本存儲格式，這個跟數(shù)據(jù)倉庫的模型(維度或關系建模)都是建立在關系型數(shù)據(jù)基礎上的特點有關。

事實上，是傳統(tǒng)的數(shù)據(jù)建模負擔讓數(shù)據(jù)倉庫只處理結構化數(shù)據(jù)，其實誰都沒規(guī)定過數(shù)據(jù)倉庫只處理和存儲結構化數(shù)據(jù)。

數(shù)據(jù)湖包羅萬象，輕裝上陣，結構化與非結構化數(shù)據(jù)都成為了數(shù)據(jù)湖本身的一部分，這體現(xiàn)了數(shù)據(jù)湖中“湖”這個概念。因為沒有數(shù)據(jù)倉庫建模的限制，當然什么東西都可以往里面扔，但這為其變成數(shù)據(jù)沼澤埋下了伏筆。

看了這段肯定無法讓人信服，不要急，接著往下看。

(2)模型設計

數(shù)據(jù)倉庫中所有的Schema(比如表結構)都是預先設計并生成好的，數(shù)據(jù)倉庫建設最重要的工作就是建模，其通過封裝好的、穩(wěn)定的模型對外提供有限的、標準化的數(shù)據(jù)服務，模型能否設計的高內(nèi)聚、松耦合成了評估數(shù)據(jù)倉庫好壞的一個標準，就好比數(shù)據(jù)中臺非常強調(diào)數(shù)據(jù)服務的復用性一樣。

你會發(fā)現(xiàn)，數(shù)據(jù)倉庫很像數(shù)據(jù)領域的計劃經(jīng)濟，所有的產(chǎn)品(模型)都是預先生成好的，模型可以變更，但相當緩慢。

數(shù)據(jù)湖的模型不是預先生成的，而是隨著每個應用的需要即時設計生成的，其更像是市場經(jīng)濟的產(chǎn)物，犧牲了復用性卻帶來了靈活性，這也是為什么數(shù)據(jù)湖的應用更多強調(diào)探索分析的原因。

(3)加工工具

數(shù)據(jù)倉庫的采集、處理工具一般是比較封閉的，很多采取代碼的方式暴力實現(xiàn)，大多只向集中的專業(yè)開發(fā)人員開放，主要的目的是實現(xiàn)數(shù)據(jù)的統(tǒng)一采集和建模，它不為消費者(應用方)服務，也沒這個必要。

數(shù)據(jù)湖的采集和處理工具是完全開放的，因為第(2)點提到過：數(shù)據(jù)湖的模型是由應用即席設計生成的，意味著應用必須具備針對數(shù)據(jù)湖數(shù)據(jù)的直接ETL能力和加工能力才能完成定制化模型的建設，否則就沒有落地的可能，更無靈活性可言。

工具能否開放、體驗是否足夠好是數(shù)據(jù)湖能夠成功的一個前提，顯然傳統(tǒng)數(shù)據(jù)倉庫的一些采集和開發(fā)工具是不行的，它們往往非常丑陋，不可能向普通大眾開放。

(4)開發(fā)人員

數(shù)據(jù)倉庫集中開發(fā)人員處理數(shù)據(jù)涵蓋了數(shù)據(jù)采集、存儲、加工等各個階段，其不僅要管理數(shù)據(jù)流，也要打造工具流。

由于數(shù)據(jù)流最終要為應用服務，因此其特別關注數(shù)據(jù)模型的質(zhì)量，而工具流只要具備基本的功能、滿足性能要求就可以了，反正是數(shù)據(jù)倉庫團隊人員自己用，導致的后果是害苦了運營人員。

數(shù)據(jù)湖完全不一樣，集中開發(fā)人員在數(shù)據(jù)流階段只負責把原始數(shù)據(jù)扔到數(shù)據(jù)湖，更多的精力花在對工具流的改造上，因為這些工具是直接面向最終使用者的，假如不好用，數(shù)據(jù)湖就死了。

(5)應用人員

數(shù)據(jù)倉庫對于應用人員暴露的所有東西就是建好的數(shù)據(jù)模型，應用方的所有角色只能在數(shù)據(jù)倉庫限定好的數(shù)據(jù)模型范圍內(nèi)倒騰，這在一定程度上限制了應用方的創(chuàng)新能力。比如原始數(shù)據(jù)有個字段很有價值，但數(shù)據(jù)倉庫集中開發(fā)人員卻把它過濾了。

這種問題在數(shù)據(jù)倉庫中很常見，很多取數(shù)人員只會取寬表，對于源端數(shù)據(jù)完全不清楚，成了井底之蛙，這是數(shù)據(jù)倉庫集中開發(fā)人員造的“孽”，所謂成也數(shù)據(jù)倉庫，敗也數(shù)據(jù)倉庫。

數(shù)據(jù)湖的應用方則可以利用數(shù)據(jù)湖提供的工具流接觸到最生鮮的原始數(shù)據(jù)，涵蓋了從數(shù)據(jù)采集、抽取、存儲、加工的各個階段，其可以基于對業(yè)務的理解，壓榨出原始數(shù)據(jù)的最大價值。

可以看到，數(shù)據(jù)倉庫和數(shù)據(jù)湖，代表著兩種數(shù)據(jù)處理模式和服務模式，是數(shù)據(jù)技術領域的一次輪回。

早在ORACLE的DBLINK時代，我們就有了第一代的數(shù)據(jù)湖，因為那個時候ORACLE一統(tǒng)天下，ORALCE的DBLINK讓直接探索原始數(shù)據(jù)有了可能。

隨著數(shù)據(jù)量的增長和數(shù)據(jù)類型的不斷豐富，我們不得不搞出一種新的“數(shù)據(jù)庫”來集成各種數(shù)據(jù)。

但那個時候搞出的為什么是數(shù)據(jù)倉庫而不是數(shù)據(jù)湖呢?

主要還是應用驅(qū)動力的問題。

因為那個時候大家關注的是報表，而報表最核心的要求就是準確性和一致性，標準化、規(guī)范化的維度和關系建模正好適應了這一點，集中化的數(shù)據(jù)倉庫支撐模式就是一種變相的計劃經(jīng)濟。

隨著大數(shù)據(jù)時代到來和數(shù)字化的發(fā)展，很多企業(yè)發(fā)現(xiàn)，原始數(shù)據(jù)的非結構化比例越來越高，前端應用響應的要求越來越高，海量數(shù)據(jù)挖掘的要求越來越對，報表取數(shù)已經(jīng)滿足不了數(shù)據(jù)驅(qū)動業(yè)務的要求了。

一方面企業(yè)需要深挖各種數(shù)據(jù)，從展示數(shù)據(jù)為主(報表)逐步向挖掘數(shù)據(jù)(探索預測)轉(zhuǎn)變，另一方面企業(yè)也需要從按部就班的支撐模式向快速靈活的方向轉(zhuǎn)變，要求數(shù)據(jù)倉庫能夠開放更多的靈活性給應用方，這個時候數(shù)據(jù)倉庫就有點撐不住了。

數(shù)據(jù)湖就是在這種背景下誕生的。

其實早在數(shù)據(jù)湖出來之前，很多企業(yè)就在做類似數(shù)據(jù)湖的工作了，比如我們5年前重構hadoop大數(shù)據(jù)平臺的時候，就已經(jīng)要求源端能將各種格式的數(shù)據(jù)直接扔過來，然后用不同的引擎處理，非結構化的就自己做一個定制化的ETL工具，只是沒有統(tǒng)一進行整合而已。

ETL之所以不開放，主要是驅(qū)動力不夠，其實我們沒有那么多類型的數(shù)據(jù)要定制化抽取，也許后續(xù)會需要吧。

而可視化開發(fā)平臺使用比較廣泛，只是因為市場覺得IT做的太慢了，需要一個可視化平臺來直接操作。

很多企業(yè)不搞可視化開發(fā)平臺也是容易理解的，報表就能活得很好，干嘛業(yè)務人員要自己開發(fā)和挖掘。現(xiàn)在數(shù)據(jù)湖叫的歡的，大多是互聯(lián)網(wǎng)公司，比如亞馬遜，這是很正常的。

數(shù)據(jù)湖和數(shù)據(jù)倉庫，不能說誰更好誰更差，大家都有可取之處，阿里最近一篇文章提到的數(shù)湖一體是很好的概念，可以實現(xiàn)雙方的優(yōu)勢互補，我這里畫一張圖，方便你的理解：

何謂湖倉一體?

• 湖和倉的數(shù)據(jù)/元數(shù)據(jù)無縫打通，互相補充，數(shù)據(jù)倉庫的模型反哺到數(shù)據(jù)湖(成為原始數(shù)據(jù)一部分)，湖的結構化應用知識沉淀到數(shù)據(jù)倉庫
• 湖和倉有統(tǒng)一的開發(fā)體驗，存儲在不同系統(tǒng)的數(shù)據(jù)，可以通過一個統(tǒng)一的開發(fā)/管理平臺操作
• 數(shù)據(jù)湖與數(shù)據(jù)倉庫的數(shù)據(jù)，系統(tǒng)可以根據(jù)自動的規(guī)則決定哪些數(shù)據(jù)放在數(shù)倉，哪些保留在數(shù)據(jù)湖，進而形成一體化

至于理解的對不對，你怎么看?