萬字詳解數據倉庫、數據湖、數據中台和湖倉一體

• 2022 年 2 月 22 日
• 筆記
• 大數據, 數據中台, 數據倉庫, 數據湖, 湖倉一體

​

 本文目錄：

一、前言
二、概念解析

1. 數據倉庫

2. 數據湖

3. 數據中台

三、具體區別

1. 數據倉庫 VS 數據湖

2. 數據倉庫 VS 數據中台

3. 總結

四、湖倉一體

1. 目前數據存儲方案

2. 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和雲廠商們在進行快速的推演和實踐。

​