有了資料湖，資料倉儲究竟能不能被取代？

資料湖是近兩年中比較新的技術在大資料領域中，對於一個真正的資料湖應該是什麼樣子，現在對資料湖認知還是處在探索的階段，像現在代表的開源產品有iceberg、hudi、Delta Lake。

那對於資料湖應該是什麼樣子，先來看資料湖的作者AWS來說明資料湖是什麼東西，比如下圖：

不懂資料的人也許會覺得資料湖很厲害，而懂資料的人也許會覺得僅是一堆資料倉儲技術的堆砌包裝而已，你看上面那張框架圖，哪個專業詞彙資料人士會不懂?憑什麼資料湖被炒作成了一個新概念?

而對於資料湖的定義則是：

資料湖是一個集中式儲存庫，允許您以任意規模儲存所有結構化和非結構化資料。您可以按原樣儲存資料(無需先對資料進行結構化處理)，並執行不同型別的分析 – 從控制皮膚和視覺化到大資料處理、實時分析和機器學習，以指導做出更好的決策。

那麼資料湖和我們早先的資料倉儲究竟有什麼樣的區別呢：

資料倉儲是一個最佳化的資料庫，用於分析來自事務系統和業務線應用程式的關係資料。事先定義資料結構和 Schema 以最佳化快速 SQL 查詢，其中結果通常用於操作報告和分析。資料經過了清理、豐富和轉換，因此可以充當使用者可信任的“單一資訊源”。

資料湖有所不同，因為它儲存來自業務線應用程式的關係資料，以及來自移動應用程式、IoT 裝置和社交媒體的非關係資料。捕獲資料時，未定義資料結構或 Schema。這意味著您可以儲存所有資料，而不需要精心設計也無需知道將來您可能需要哪些問題的答案。您可以對資料使用不同型別的分析(如 SQL 查詢、大資料分析、全文搜尋、實時分析和機器學習)來獲得見解。

從介紹來看好像資料倉儲和資料湖的最主要的區別就是對結構化的資料和非結構化資料的儲存，但是真的僅僅是這樣嗎?

事實上，這種比較有較大邏輯漏洞：即是從結果出發來看差異，然後又用這個差異來說明區別，顛倒了因果。比如AWS的資料湖能夠處理非結構化資料，而資料倉儲無法處理非結構化資料，就認為這是資料湖與資料倉儲的本質區別之一。

下面的文章中將來探索資料湖和資料倉儲究竟有什麼樣的區別，學習一個新的事物要一步步的發現這個事物的本質是什麼。

資料倉儲和資料湖的處理流程可以用下圖來示意，其中用紅圈標出了5個對標的流程節點。

從圖中可以看出來資料湖並不比資料倉儲在處理流程上多出了什麼內容，更多的在於結構性的變化，下面就從資料儲存、模型設計、加工工具、開發人員和消費人員五個方面來進行比較。

(1)資料儲存

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

事實上，是傳統的資料建模負擔讓資料倉儲只處理結構化資料，其實誰都沒規定過資料倉儲只處理和儲存結構化資料。

資料湖包羅永珍，輕裝上陣，結構化與非結構化資料都成為了資料湖本身的一部分，這體現了資料湖中“湖”這個概念。因為沒有資料倉儲建模的限制，當然什麼東西都可以往裡面扔，但這為其變成資料沼澤埋下了伏筆。

(2)模型設計

資料倉儲中所有的Schema(比如表結構)都是預先設計並生成好的，資料倉儲建設最重要的工作就是建模，其透過封裝好的、穩定的模型對外提供有限的、標準化的資料服務，模型能否設計的高內聚、松耦合成了評估資料倉儲好壞的一個標準，就好比資料中臺非常強調資料服務的複用性一樣。

你會發現，資料倉儲很像資料領域的計劃經濟，所有的產品(模型)都是預先生成好的，模型可以變更，但相當緩慢。

資料湖的模型不是預先生成的，而是隨著每個應用的需要即時設計生成的，其更像是市場經濟的產物，犧牲了複用性卻帶來了靈活性，這也是為什麼資料湖的應用更多強調探索分析的原因。

(3)加工工具

資料倉儲的採集、處理工具一般是比較封閉的，很多采取程式碼的方式暴力實現，大多隻向集中的專業開發人員開放，主要的目的是實現資料的統一採集和建模，它不為消費者(應用方)服務，也沒這個必要。

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

工具能否開放、體驗是否足夠好是資料湖能夠成功的一個前提，顯然傳統資料倉儲的一些採集和開發工具是不行的，它們往往不可能向普通大眾開放。

(4)開發人員

資料倉儲集中開發人員處理資料涵蓋了資料採集、儲存、加工等各個階段，其不僅要管理資料流，也要打造工具流。

由於資料流最終要為應用服務，因此其特別關注資料模型的質量，而工具流只要具備基本的功能、滿足效能要求就可以了，反正是資料倉儲團隊人員自己用，導致的後果是害苦了運營人員。

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

(5)應用人員

資料倉儲對於應用人員暴露的所有東西就是建好的資料模型，應用方的所有角色只能在資料倉儲限定好的資料模型範圍內倒騰，這在一定程度上限制了應用方的創新能力。比如原始資料有個欄位很有價值，但資料倉儲集中開發人員卻把它過濾了。

這種問題在資料倉儲中很常見，很多取數人員只會取寬表，對於源端資料完全不清楚，所謂成也資料倉儲，敗也資料倉儲。

資料湖的應用方則可以利用資料湖提供的工具流接觸到最生鮮的原始資料，涵蓋了從資料採集、抽取、儲存、加工的各個階段，其可以基於對業務的理解，壓榨出原始資料的最大價值。

可以看到，資料倉儲和資料湖，代表著兩種資料處理模式和服務模式，是資料技術領域的一次輪迴。

早在ORACLE的DBLINK時代，我們就有了第一代的資料湖，因為那個時候ORACLE一統天下，ORALCE的DBLINK讓直接探索原始資料有了可能。

隨著資料量的增長和資料型別的不斷豐富，我們不得不搞出一種新的“資料庫”來整合各種資料。

但那個時候搞出的為什麼是資料倉儲而不是資料湖呢?

主要還是應用驅動力的問題。

因為那個時候大家關注的是報表，而報表最核心的要求就是準確性和一致性，標準化、規範化的維度和關係建模正好適應了這一點，集中化的資料倉儲支撐模式就是一種變相的計劃經濟。

隨著大資料時代到來和數字化的發展，很多企業發現，原始資料的非結構化比例越來越高，前端應用響應的要求越來越高，海量資料探勘的要求越來越對，報表取數已經滿足不了資料驅動業務的要求了。

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

資料湖就是在這種背景下誕生的。

其實早在資料湖出來之前，很多企業就在做類似資料湖的工作了，但是隻不過大家更多的集中在資料倉儲結構化的資料處理中，對於非結構化的資料日誌等更多的則是將其儲存起來，對於需要的時候再透過應用程式進行處理獲取到自己想要的結果，只不過是沒有系統化的處理而已。

ETL之所以不開放，主要是驅動力不夠，其實我們沒有那麼多型別的資料要定製化抽取。

很多企業不搞視覺化開發平臺也是容易理解的，報表就能活得很好，幹嘛業務人員要自己開發和挖掘。現在資料湖叫的歡的，大多是網際網路公司，比如亞馬遜，這是很正常的。

而最近比較新的概念湖倉一體，阿里提出的概念，下面這張圖來看一下：

何謂湖倉一體?

湖倉一體是一種新的資料管理模式，將資料倉儲和資料湖兩者之間的差異進行融合，並將資料倉儲構建在資料湖上，從而有效簡化了企業資料的基礎架構，提升資料儲存彈性和質量的同時還能降低成本，減小資料冗餘。

湖和倉的資料/後設資料無縫打通，互相補充，資料倉儲的模型反哺到資料湖(成為原始資料一部分)，湖的結構化應用知識沉澱到資料倉儲。

湖倉一體架構主要的一點是實現“湖裡”和“倉裡”的資料能夠無縫打通，對資料倉儲的彈性和資料湖的靈活性進行有效整合，在該架構中，主要將資料湖作為中央儲存庫，將機器學習、資料倉儲、日誌分析、大資料等技術進行整合，形成一套資料服務環，更好地分析、整合資料，讓資料倉儲和資料湖中的資料可以自由流動，使用者可以更便捷地調取其中的資料，讓資料“入湖”、“出湖”更為便捷。

湖倉一體化，是將資料倉儲和資料湖的價值進行疊加，克服資料重力，讓資料在服務之間流動起來，減少重複建設，讓湖中的資料可以”流到“資料倉中，並能直接進行資料呼叫;而資料倉中的資料也可以儲存於資料湖中，供未來資料探勘使用。藉助湖倉一體化，可快速處理數倉內的熱資料與資料湖中的歷史資料，並生成豐富的資料集，但無需在執行中做任何資料移動操作。

那資料湖究竟應該是什麼樣子，需要在接下來的發展中獲取到答案，但是以目前來看，典型的組織都需要資料倉儲和資料湖，因為它們可滿足不同的需求和使用訴求。所以資料湖和資料倉儲的存在並不衝突，也並不是取代的關係，而是相互的融合關係。