數據湖的熱還沒褪去，湖倉一體就被炒起來了，有人問要不要入局湖倉一體，我的觀點：先把自家的數據湖玩明白了再說吧，事實上，大多數的數據湖用得名不副實，更別提湖倉一體了。

為什么這么說呢？

判斷一個技術對自己有沒有用，我還是喜歡追溯下技術的源頭，很多技術被產品化后，夾雜了太多的私貨。

在說明我的觀點之前，先做一個數據技術的穿越，從數據庫、數據倉庫、數據湖再到湖倉一體。

1、簡單可用階段：數據庫（DataBase）

早在1980年代初中期，是沒有專門面向數據分析場景的產品。當時還是以面向事務交易場景為主，數據分析僅作為附帶提供的場景。主要是面對管理層提供固定報表，滿足宏觀管理決策。作為底層數據庫，通過標準SQL提供數據分析能力。

這一架構在面對數據分析場景的缺點很明顯，集成水平低，擴展性差，很難支持大規模數據分析，性能也無法滿足需求。這也催生專門解決數據分析的產品出現，即后面出現的數據倉庫。

2、 規范標準階段：數倉（Data Warehouse）

到了1980年代中后期，為解決數據庫面對數據分析的不足，孕育出新一類產品數據倉庫。讓我們先來看下數據倉庫的定義，數據倉庫（Data Warehouse）是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策和信息的全局共享。

上圖是數據倉庫的應用架構，從中可見其做了若干階段劃分，簡單可分為數據集成（裝載）、數據加工（ETL）、數據匯聚、數據展示及挖掘。數據經過這一過程，被抽取到數據倉庫中，并嚴格按照預先定義的模式被裝載進來，經過多層加工形成數據集市，并最終提供給終端應用或進一步供挖掘使用，主要場景包括編制報表、發布下游數據集市(Data Marts)，以及支持自助式商業智能等。

在技術實現上，主流采用MPP無共享存儲架構，基于標準X86服務器，可實現數百節點的擴展。其對外提供標準的SQL能力和ACID特性，整體計算性能可在一定程度上隨節點擴展可提升。

當然，隨著數據在企業內角色愈發重要，對其分析的要求不斷提高，例如，隨著數據規模擴大，對數據承載能力（容量、算力）的要求也不斷增大，數倉架構的擴展能力面臨考驗，規模的擴展會面臨大量資源的投入，但硬件資源缺乏彈性，會導致高峰時資源不足，低谷時資源閑置浪費問題。針對數據類型，也不再局限于結構化數據，更多半結構化、非結構化數據需要被利用起來，傳統的數據倉庫架構面臨諸多的挑戰，只能擴展上百節點的MPP架構快撐不住了。

3.、開放自由階段：數據湖（Data Lake）

相比于數據倉庫，數據湖是一種不斷演進中、可擴展的大數據存儲、處理、分析的基礎設施。它就像一個大型倉庫，可以存儲任何形式（包括結構化和非結構化）和任何格式（包括文本、音頻、視頻和圖像）的原始數據，數據湖通常更大，存儲成本也更為廉價，結合先進的數據科學與機器學習技術，能提供預測分析、推薦模型等能力。

數據倉庫中，數據存儲的結構與其定義的schema是強匹配的，也就是先建模再使用，簡單點說，數據倉庫就像是一個大型圖書館，里面的數據需要按照規范放好，你可以按照類別找到想要的信息，存儲在倉庫中都是結構化數據，可以直接消費。

而數據湖存儲其中的數據不需要滿足特定的schema，數據湖也不會嘗試去將特定的schema施行其上，任何格式的數據都可以扔進數據湖。數據使用通常會在讀取數據的時候解析schema（schema-on-read），當處理相應的數據時，將轉換施加其上，也就是說，數據湖對于入湖的數據不做任何規范和約束，只有在于使用時才定義存儲格式以便分析使用。

下面這張圖形象的表達了數據倉庫和數據湖的區別，數據倉庫有點像“計劃經濟”，而數據湖則是“市場經濟”。

基于以上的特點，業界一般都會認為數據倉庫成長性較好，適合于成熟規模型企業使用，因為規范化講究的是一個規模效益。數據湖靈活性較好，更適用于初創型企業使用，如下圖所示：

可以看到，數據湖和數據倉庫都有各自的優勢和不足，但不難發現，二者在某些層面是非常互補的，于是乎，2020年，大數據DataBricks公司首次提出了湖倉一體（Data Lakehouse）概念，希望將數據湖和數據倉庫技術合而為一。

此概念一出各路云廠商紛紛跟進，2021年，這個概念爬上了Gartner曲線，在國內火了起來，各種湖倉一體的產品也冒出來了，無論是國外的，阿里的，華為的，開源的等等。

無論是數據湖，還是湖倉一體，看起來都很美好，不可否認它們代表了一種技術趨勢，但這些老外傳過來的東西，其宣揚的那些特性，對你的企業真的有用嗎？

“不要說湖倉一體了，就連數據湖技術，大多企業也沒怎么玩明白，即使你已經擁有了它。”? 這是我當前給出的答案。

為什么要這么說？

2年前自己去參加一個展會，有人在那介紹數據湖的產品，我就問講解員數據湖相對數據倉庫帶來了什么增益價值？能否舉個讓人信服的例子？然后講解員巴拉巴拉的說了幾個例子，我問這不是傳統數據倉庫干的事情嗎？然后他就說，這是hadoop，它就是數據湖。

Hadoop就是數據湖？

有人解釋國外習慣把hadoop叫做數據湖，而我們國內一般叫做大數據平臺，雖然名字不一樣，但其實說得是同一回事，因此其實我們早就一步走上了技術巔峰，可能連我們自己都不知道呢？

不知道什么時候開始，很多企業的PPT里開始把大數據平臺改稱了數據湖，也許數據湖這個名字比較通俗易懂吧，老板們也喜歡用，似乎是一瞬間，大家的大數據平臺一下全部升級成為了數據湖。

遺憾的是，雖然大多企業的hadoop從技術角度來講可以叫作數據湖，但從業務的角度講，只是披著數據湖外衣的更大型的數據倉庫而已。

大多企業從來沒有像谷歌、互聯網大廠一樣發揮出過hadoop蘊含的數據湖的那些獨特價值，比如將非結構化數據，結構化數據，半結構化數據全部扔到hdfs上統一管理，然后數據科學家能夠所見即所得的進行分析使用。

事實上，大多企業只是把hadoop的hive當成了一個能處理海量數據的廉價數據倉庫，用以替代跑不動的可能還貴得要死的MPP，但我們還在用MPP時代使用數據倉庫的方式使用著數據湖，從來沒有變更過，好比我雖然買了一輛具備自動駕駛的汽車但從來沒有使用過自動駕駛功能一樣。

下面這張表說明了一切，你可以看看數據湖相對數據倉庫的11個方面的不同，然后想想咱家的hadoop數據湖跟這里提到的數據湖是不是同一個物種？

那么，造成這種現象的深層次原因是什么呢？

我想主要跟使用者的背景和業務有關，跟技術無關。

第一是原生數據的問題。數據湖緣起互聯網，強調從非結構化數據中挖掘價值，比如谷歌使用MR計算引擎來處理非結構化的網頁，而現在使用Hadoop的企業大多可是傳統行業，本身沒有什么非結構化數據，或者利用非結構化數據的業務驅動還不夠，大家只是希望利用數據湖的分布式計算框架來提升海量結構化數據的處理能力，這讓數據湖喪失了獨特價值。

第二是生產關系的問題。雖然不少企業擁有各種類型的數據，但要匯聚這些數據到統一數據湖首先得打破數據孤島，這對很多企業是巨大的挑戰，因為企業數據治理體系不是那么容易建立。

理論上講，一個公司有搞綜合的，有搞財務的，有搞人力的，也有搞供應鏈的，不可能不需要保存和使用非結構化數據，但現實情況是，即使企業有了數據湖，很多領域對各種非結構數據的存儲和處理其實還在用豎井的方式解決，比如構建獨立的文檔庫，大家并沒有什么入湖共享的意識。

前段時間我寫過一篇數據編織的文章，提到獲取完整的元數據是數據編織的前提，但如果連連接各個數據源的元數據權力都沒有，談何數據編織，而數據湖的困境也是一樣的。

下面這張圖體現出數據湖是一個生態，但生態的打造不是在一個空地上挖一個池子就可以的。

有人說數據湖的核心問題是數據太多缺乏治理導致變成了數據沼澤，我說你太杞人憂天了，數據湖的核心問題是湖水太少了，數據治理首先要解決的是有沒有水、能不能把水引進來的問題。

第三是數據應用的問題。數據湖的最大推動者是亞馬遜等一眾互聯網大廠，這些互聯網的數字原生企業，其本身的數字化水平是非常高的，面對激烈的市場競爭，早就不再滿足于數據倉庫那種按部就班的單一數據的供給模式，互聯網大廠的數據科學家具備足夠的能力從數據湖中獲取原始數據、解析數據、處理數據直到挖掘數據，所見即所得是數據科學家探索數據所需要的。

但在傳統企業里，數據分析師能夠基于數據倉庫提供的結構化數據進行自助取數、分析和挖掘已經是非常牛逼了，大多還是處于被動的數據供給模式，數據湖所倡導的靈活性對他們來說是沒有什么意義的，這是由企業的性質和所處的階段決定的。

由此可以看到，數據湖相對數據倉庫擁有的那些獨特優勢，無論是對于非結構數據的存儲處理還是分析的靈活性等等，在大多企業是沒有條件執行的，或者說沒有足夠的業務驅動力，大多企業的使用者眼里只有支持SQL的HIVE數據倉庫，數據湖對他們來講就是更大號的數據倉庫，比如企業90%的數據都是以HIVE表的形式存在的，所有的需求都不需要用到數據湖的獨特技術。

現在，hadoop這種數據湖技術已經逐步不能滿足互聯網大廠的要求了，因為hadoop實時性太差，無法滿足數據湖“對于業務系統中的數據都會存儲一份“一模一樣”的完整拷貝”的保真性要求。

這意味著數據寫入數據湖的時候要保證ACID，要高效支持upsert /delete歷史數據，要能容忍數據頻繁導入文件系統上產生的大量的小文件，顯然hadoop這種數據湖技術不夠看了，在這種背景下，Delta、iceberg和hudi等新技術逐漸冒出來了，但它們到底是屬于數據倉庫的升級，還是屬于數據湖的升級，那就見仁見智了，我們既可以說數據倉庫需要支撐實時數據，也可以說數據湖需要確保所有的數據能及時的扔進數據湖且跟原系統一模一樣。

但脫離了hadoop體系的新數據湖技術，大多企業估計也很難買單，一方面實時技術有很多替代品，即使不是那么完美，另一方面也有保護原有投資的需要。

明白了這一點，我們再回過頭來分析湖倉一體，自然會得到你需要的答案，我不否認湖倉一體是很好的技術，代表了某種趨勢，但回到每個企業每個個體，我們還是要回到業務原點去思考問題，雖然技術可以適當領先業務半步，但步子不要一下子邁得太大，還得因地制宜，諸如阿里提供的湖倉一體解決方案應該也有市場，因為能解決異構數據平臺的數據共享和同步問題，至少能保護企業的原有投資，但賣點不在湖倉一體本身。

最后一句話總結：數據倉庫永不過時，數據湖任重而道遠，湖倉一體就先讓子彈飛一會兒吧。