本文目錄：
一、前言
二、概念解析
-
資料倉儲
-
資料湖
-
資料中臺
三、具體區別
-
資料倉儲 VS 資料湖
-
資料倉儲 VS 資料中臺
-
總結
四、湖倉一體
-
目前資料儲存方案
-
Data Lakehouse（湖倉一體）
一、前言
數字化轉型浪潮捲起各種新老概念滿天飛，資料湖、資料倉儲、資料中臺輪番在朋友圈刷屏，有人說“資料中臺算個啥，資料湖才是趨勢”，有人說“再見了資料湖、資料倉儲，資料中臺已成氣候”……
企業還沒推開數字化大門，先被各種概念絆了一腳。那麼它們 3 者究竟有啥區別？別急，先跟大家分享兩個有趣的比喻。
1、圖書館VS地攤
如果把資料倉儲比喻成“圖書館”，那麼資料湖就是“地攤”。去圖書館借書（資料），書籍質量有保障，但你得等，等什麼？等管理員先查到這本書屬於哪個類目、在哪個架子上，你才能精準拿到自己想要的書；而地攤上沒有人會給你把關，什麼書都有，你自己翻找、隨用隨取，流程上比圖書館便捷多了，但大家找書的過程是沒有經驗可複用的，偶爾多拿少拿我們們可能也不知道。
2、升級版銀行
假定資料倉儲、資料湖、資料中臺都是銀行，可以提供現金、黃金等多種服務。過去大家進銀行前都得先問門衛，裡面每個門牌上的數字對應哪個服務呢？是現金還是黃金呢？然後推開對應的門把東西取出來。而有了“資料中臺”這個銀行，大家一進來就能看到標著“現金”、“黃金”漢字的視窗，一目瞭然，你只需要走到視窗前，就有專人幫你辦理。
以上兩個例子不一定全面，但基本能解釋三者的優劣勢。資料倉儲具備規範性，但取數用數流程長；資料湖取數用數更實時、儲存量大，但資料質量難以保障；資料中臺能精準快速地響應業務需求，離業務側最近。
為了更清晰地區別三者，接下來我們們再來看看它們各自的定義以及應用區別。
二、概念解析
1. 資料倉儲
資料倉儲誕生於 1990 年，絕對算得上是“老前輩”了，它是一個相對具體的功能概念。目前對資料倉儲的主流定義是位於多個資料庫上的大容量儲存庫，它的作用在於儲存大量的結構化資料，並能進行頻繁和可重複的分析，幫助企業構建商業智慧（BI）。
具體定義：
資料倉儲(Data Warehouse)是一個面向主題的（Subject Oriented）、整合的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化的（Time Variant）資料集合，用於支援管理決策和資訊的全域性共享。其主要功能是將組織透過資訊系統之聯機事務處理(OLTP)經年累月所累積的大量資料，透過資料倉儲理論所特有的資料儲存架構，分析出有價值的資訊。
-
所謂主題：是指使用者使用資料倉儲進行決策時所關心的重點方面，如：收入、客戶、銷售渠道等；所謂面向主題，是指資料倉儲內的資訊是按主題進行組織的，而不是像業務支撐系統那樣是按照業務功能進行組織的。
-
所謂整合：是指資料倉儲中的資訊不是從各個業務系統中簡單抽取出來的，而是經過一系列加工、整理和彙總的過程，因此資料倉儲中的資訊是關於整個企業的一致的全域性資訊。
-
所謂隨時間變化：是指資料倉儲內的資訊並不只是反映企業當前的狀態，而是記錄了從過去某一時點到當前各個階段的資訊。通過這些資訊，可以對企業的發展歷程和未來趨勢做出定量分析和預測。
資料倉儲的作用：
資料倉儲系統的作用能實現跨業務條線、跨系統的資料整合，為管理分析和業務決策提供統一的資料支援。資料倉儲能夠從根本上幫助你把公司的運營資料轉化成為高價值的可以獲取的資訊（或知識），並且在恰當的時候通過恰當的方式把恰當的資訊傳遞給恰當的人。
-
是面向企業中、高階管理進行業務分析和績效考核的資料整合、分析和展現的工具；
-
是主要用於歷史性、綜合性和深層次資料分析；
-
資料來源是ERP（例:SAP）系統或其他業務系統；
-
能夠提供靈活、直觀、簡潔和易於操作的多維查詢分析;
-
不是日常交易作業系統，不能直接產生交易資料；
實時數倉
實時數倉和離線數倉非常的像，誕生的背景主要是近幾年企業對於資料服務的實時性需求日益增多。裡面的資料模型也會像中臺一樣分好幾層：ODS 、CDM、ADS。但整體對於實時性要求極高，因此一般儲存會考慮採用Kafka這種log base的MQ，而計算引擎會採用Flink這種流計算引擎。
2. 資料湖
資料湖是一種不斷演進中、可擴充套件的大資料儲存、處理、分析的基礎設施，它就像一個大型倉庫儲存企業多樣化原始資料以資料為導向，實現任意來源、任意速度、任意規模、任意型別資料的全量獲取、全量儲存、多模式處理與全生命週期管理。擁有強大的資訊處理能力和處理幾乎無限的併發任務或工作的能力。
資料湖從企業的多個資料來源獲取原始資料，資料可能是任意型別的資訊，從結構化資料到完全非結構化資料，並通過與各類外部異構資料來源的互動整合，支援各類企業級應用。結合先進的資料科學與機器學習技術，能幫助企業構建更多優化後的運營模型，也能為企業提供其他能力，如預測分析、推薦模型等，這些模型能刺激企業能力的後續增長。
進入網際網路時代，有兩個最重要的變化。
一個是資料規模前所未有，一個成功的網際網路產品日活可以過億，就像你熟知的頭條、抖音、快手、網易雲音樂，每天產生幾千億的使用者行為。傳統資料倉儲難於擴充套件，根本無法承載如此規模的海量資料。
另一個是資料型別變得異構化，網際網路時代的資料除了來自業務資料庫的結構化資料，還有來自 App、Web 的前端埋點資料，或者業務伺服器的後端埋點日誌，這些資料一般都是半結構化，甚至無結構的。傳統資料倉儲對資料模型有嚴格的要求，在資料匯入到資料倉儲前，資料模型就必須事先定義好，資料必須按照模型設計儲存。
所以，資料規模和資料型別的限制，導致傳統資料倉儲無法支撐網際網路時代的商業智慧。
05年的時候，Hadoop誕生了。Hadoop 相比傳統資料倉儲主要有兩個優勢：
-
完全分散式，易於擴充套件，可以使用價格低廉的機器堆出一個計算、儲存能力很強的叢集，滿足海量資料的處理要求；
-
弱化資料格式，資料被整合到 Hadoop 之後，可以不保留任何資料格式，資料模型與資料儲存分離，資料（包含了原始資料）在被使用的時候，可以按照不同的模型讀取，滿足異構資料靈活分析的需求。而數倉更加關注可以作為事實依據的資料。
隨著Hadoop與物件儲存的成熟，資料湖的概念在10年被提出：資料湖（Data Lake）是一個以原始格式儲存資料的儲存庫或系統（這意味著資料湖的底層不應該與任何儲存耦合）。
對應的來說，如果資料湖沒有被治理好（缺乏後設資料、定義資料來源、制定資料訪問策略和安全策略，並移動資料、編制資料目錄），則會變成資料沼澤。
而從產品形態上來說，數倉往往是獨立標準化的產品。而資料湖更像是一種架構指導——需要配合一系列的周邊工具，來實現業務需要的資料湖。
3. 資料中臺
大規模資料的應用，也逐漸暴露出現一些問題。
業務發展前期，為了快速實現業務的需求，煙囪式的開發導致企業不同業務線，甚至相同業務線的不同應用之間，資料都是割裂的。兩個資料應用的相同指標，展示的結果不一致，導致運營對資料的信任度下降。如果你是運營，當你想看一下商品的銷售額，發現兩個報表上，都叫銷售額的指標出現了兩個值，你的感受如何? 你第一反應肯定是資料算錯了，你不敢繼續使用這個資料了。
資料割裂的另外一個問題，就是大量的重複計算、開發，導致的研發效率的浪費，計算、儲存資源的浪費，大資料的應用成本越來越高。
-
如果你是運營，當你想要一個資料的時候，開發告訴你至少需要一週，你肯定想是不是太慢了，能不能再快一點兒？
-
如果你是資料開發，當面對大量的需求的時候，你肯定是在抱怨，需求太多，人太少，活幹不完。
-
如果你是一個企業的老闆，當你看到每個月的賬單成指數級增長的時候，你肯定覺得這也太貴了，能不能再省一點，要不吃不消了。
這些問題的根源在於，資料無法共享。2016 年，阿里巴巴率先提出了“資料中臺”的口號。資料中臺的核心，是避免資料的重複計算，通過資料服務化，提高資料的共享能力，賦能資料應用。之前，資料是要啥沒啥，中間資料難於共享，無法積累。現在建設資料中臺之後，要啥有啥，資料應用的研發速度不再受限於資料開發的速度，一夜之間，我們就可以根據場景，孵化出很多資料應用，這些應用讓資料產生價值。
資料中臺樣板
在建設中臺的過程中，一般強調這樣幾個重點：
-
效率、質量和成本是決定資料能否支撐好業務的關鍵，構建資料中臺的目標就是要實現高效率、高質量、低成本。
-
資料只加工一次是建設資料中臺的核心，本質上是要實現公共計算邏輯的下沉和複用。
-
如果你的企業擁有 3 個以上的資料應用場景，資料產品還在不斷研發和更新，你必須要認真考慮建設資料中臺。
那麼接下來就看一下阿里巴巴對於資料中臺的實踐。
正如上述提到的資料只加工一次是建設資料中臺的核心，本質上是要實現公共計算邏輯的下沉和複用。阿里資料中臺提到了各種one思想，如：
-
OneData：公共資料只儲存一份
-
OneService：通過一個服務介面進行暴露
三、具體區別
1. 資料倉儲 VS 資料湖
相較而言，資料湖是較新的技術，擁有不斷演變的架構。資料湖儲存任何形式（包括結構化和非結構化）和任何格式（包括文字、音訊、視訊和影像）的原始資料。根據定義，資料湖不會接受資料治理，但專家們一致認為良好的資料管理對預防資料湖轉變為資料沼澤不可或缺。資料湖在資料讀取期間建立模式。與資料倉儲相比，資料湖缺乏結構性，而且更靈活，並且提供了更高的敏捷性。值得一提的是，資料湖非常適合使用機器學習和深度學習來執行各種任務，比如資料探勘和資料分析，以及提取非結構化資料等。
2. 資料倉儲 VS 資料中臺
資料倉儲和傳統的資料平臺，其出發點為一個支撐性的技術系統，即一定要先考慮我具有什麼資料，然後我才能幹什麼，因此特別強調資料質量和後設資料管理；而資料中臺的第一齣發點不是資料而是業務，一開始不用看你係統裡面有什麼資料，而是去解決你的業務問題需要什麼樣的資料服務。
在具體的技術處理環節，二者也有明顯不同，資料的預處理流程正在從傳統的ETL結構向ELT結構轉變。傳統的資料倉儲整合處理架構是ETL結構，這是構建資料倉儲的重要一環，即使用者從資料來源抽取出所需的資料，經過資料清洗，將資料載入到資料倉儲中去。而大資料背景下的架構體系是ELT結構，其根據上層的應用需求，隨時從資料中臺中抽取想要的原始資料進行建模分析。
3. 總結
根據以上資料倉儲、資料湖和資料中臺的概念論述和對比，我們進行如下總結：
-
資料中臺、資料倉儲和資料湖沒有直接的關係；
-
資料中臺、資料倉儲和資料湖在某個維度上為業務產生價值的形式有不同的側重；
-
資料中臺是企業級的邏輯概念，體現企業資料向業務價值轉化的能力，為業務提供服務的主要方式是資料 API；
-
資料倉儲是一個相對具體的功能概念，是儲存和管理一個或多個主題資料的集合，為業務提供服務的方式主要是分析報表；
-
資料中臺距離業務更近，能夠更快速的響應業務和應用開發需求，從而為業務提供速度更快的服務；
-
資料倉儲是為了支援管理決策分析，而資料中臺則是將資料服務化之後提供給業務系統，不僅限於分析型場景，也適用於交易型場景；
-
資料中臺可以建立在資料倉儲和資料平臺之上，是加速企業從資料到業務價值的過程的中間層。
四、湖倉一體
有人說“湖倉一體成為下一站燈塔，數倉、資料湖架構即將退出群聊”。
2020年，大資料DataBricks公司首次提出了湖倉一體（Data Lakehouse）概念，希望將資料湖和資料倉儲技術合而為一，此概念一出各路雲廠商紛紛跟進。
Data Lakehouse（湖倉一體）是新出現的一種資料架構，它同時吸收了資料倉儲和資料湖的優勢，資料分析師和資料科學家可以在同一個資料儲存中對資料進行操作，同時它也能為公司進行資料治理帶來更多的便利性。
1. 目前資料儲存的方案
一直以來，我們都在使用兩種資料儲存方式來架構資料：
-
資料倉儲：主要儲存的是以關係型資料庫組織起來的結構化資料。資料通過轉換、整合以及清理，並匯入到目標表中。在數倉中，資料儲存的結構與其定義的schema是強匹配的。
-
資料湖：儲存任何型別的資料，包括像圖片、文件這樣的非結構化資料。資料湖通常更大，其儲存成本也更為廉價。儲存其中的資料不需要滿足特定的schema，資料湖也不會嘗試去將特定的schema施行其上。相反的是，資料的擁有者通常會在讀取資料的時候解析schema（schema-on-read），當處理相應的資料時，將轉換施加其上。
現在許多的公司往往同時會搭建數倉、資料湖這兩種儲存架構，一個大的數倉和多個小的資料湖。這樣，資料在這兩種儲存中就會有一定的冗餘。
2. Data Lakehouse（湖倉一體）
Data Lakehouse的出現試圖去融合數倉和資料湖這兩者之間的差異，通過將數倉構建在資料湖上，使得儲存變得更為廉價和彈性，同時lakehouse能夠有效地提升資料質量，減小資料冗餘。在lakehouse的構建中，ETL起了非常重要的作用，它能夠將未經規整的資料湖層資料轉換成數倉層結構化的資料。
下面詳細解釋下：
湖倉一體（Data Lakehouse）：
依據DataBricks公司對Lakehouse 的定義：一種結合了資料湖和資料倉儲優勢的新正規化，解決了資料湖的侷限性。Lakehouse 使用新的系統設計：直接在用於資料湖的低成本儲存上實現與資料倉儲中類似的資料結構和資料管理功能。
解釋擴充：
湖倉一體，簡單理解就是把面向企業的資料倉儲技術與資料湖儲存技術相結合，為企業提供一個統一的、可共享的資料底座。
避免傳統的資料湖、資料倉儲之間的資料移動，將原始資料、加工清洗資料、模型化資料，共同儲存於一體化的“湖倉”中，既能面向業務實現高併發、精準化、高效能的歷史資料、實時資料的查詢服務，又能承載分析報表、批處理、資料探勘等分析型業務。
湖倉一體方案的出現，幫助企業構建起全新的、融合的資料平臺。通過對機器學習和AI演算法的支援，實現資料湖+資料倉儲的閉環，提升業務的效率。資料湖和資料倉儲的能力充分結合，形成互補，同時對接上層多樣化的計算生態。
Lakehouse有如下關鍵特性：
-
事物支援：Lakehouse 在企業級應用中，許多資料管道通常會同時讀取和寫入資料。通常多方同時使用 SQL 讀取或寫入資料，Lakehouse 保證支援ACID事務的一致性。
-
模式實施和治理：Lakehouse 應該有一種支援模式實施和演變的方法，支援 DW 模式規範，例如 star /snowflake-schemas。該系統應該能夠推理資料完整性，並且應該具有健壯的治理和稽核機制。
-
BI支援：Lakehouse 可以直接在源資料上使用BI工具。這樣可以減少陳舊度和等待時間，提高新近度，並且降低必須在資料湖和倉庫中操作兩個資料副本的成本。
-
儲存與計算分離：事實上，這意味著儲存和計算使用單獨的群集，因此這些系統能夠擴充套件到更多併發使用者和更大資料量。一些現代資料倉儲也具有這種屬性。
-
相容性：Lakehouse 使用的儲存格式是開放式和標準化的，例如 Parquet，並且它提供了多種 API，包括機器學習和 Python/R 庫，因此各種工具和引擎都可以直接有效地訪問資料。
-
支援從非結構化資料到結構化資料的多種資料型別：Lakehouse 可用於儲存，優化，分析和訪問許多新資料應用程式所需的資料型別，包括影像，視訊，音訊，半結構化資料和文字。
-
支援各種工作場景：包括資料科學，機器學習和 SQL 分析。這些可能依賴於多種工具來支援的工作場景，它們都依賴於相同的資料儲存庫。
-
端到端流式任務：實時報告是許多企業的日常需要。對流處理的支援消除了對專門服務於實時資料應用程式的單獨系統的需求。
上面這張圖是DataBricks給出的架構演化參考圖。
我們可以看到，傳統的數倉目標非常明確，適用於將各業務資料來源合併後，進行商務BI分析和報表。隨著企業需要處理的資料型別越來越多，包括客戶行為，IoT，圖片，視訊等， 資料規模也成指數增加。
資料湖技術被引入，並用於承擔通用資料儲存和處理平臺的作用，資料湖由於其分散式儲存和計算能力的特點，也可以更好的支援機器學習計算， 在資料湖時代，我們通常可以看到DataLake和Data Warehouse還是會同時存在的。
隨著大資料時代的到來，是不是有可能讓大資料技術可以取代傳統數倉，形成一個統一的資料處理架構，湖倉一體的概念被提出，並由DataBricks和雲廠商們在進行快速的推演和實踐。