在資料倉庫、資料平台、資料中台、資料湖的相關概念中，都與資料有關系，但它們之間又有什麼差別呢？本文圍繞它們的概念、架構、使用場景進行了介紹，一起來看一下吧。
我們經常聽到别人談論資料倉庫、資料平台、資料中台、資料湖的相關概念，它們都與資料有關系，但它們之間又有什麼差別，下面我們将圍繞資料倉庫、資料平台、資料湖和資料中台的概念、架構、使用場景進行介紹。
一、資料倉庫
1. 資料倉庫概念
資料倉庫由比爾·恩門（Bill Inmon，資料倉庫之父）于1990年提出，主要功能是将企業系統聯機事務處理（OLTP）長期壁壘的大量資料，通過資料倉庫理論支援所持有的資料存儲結構，做有系統的分析整理。
随着企業的發展，業務系統的資料不斷激增，這些存儲在企業業務資料庫中（也就是關系型資料庫Oracle，Microsoft SQL Sever，MySQL等）資料會随着時間的積累越來越多，會使業務資料庫會有一定的負載，導緻業務系統的運作效率低，且這些資料中有很大一部分是冷資料，而我們業務系統一般對我們近期的資料，也就是熱資料調用的比較頻繁，對冷資料使用頻率較低。
同時随着企業資料驅動業務概念的興起，企業需要将各業務部門的業務資料提取出來進行資料分析與挖掘，輔助高層進行分析與決策，但各部門需求的資料種類千差萬别，接口錯綜複雜，過多的資料查詢腳本以及接口的接入導緻業務資料庫的穩定性降低。
為了避免冷資料與曆史資料的積壓對我們業務資料庫效能産生影響，企業需要定期将冷資料從業務資料庫中轉移出來存儲到一個專門存放曆史資料的倉庫裡面，各部門可以根據自身業務特性對外提供統一的資料服務，這個倉庫就是資料倉庫。
2. 資料倉庫特點
資料倉庫（Data Warehoese）的特點：面向主題的、內建的、穩定的、反映曆史資料變化的。
- 面向主題的：資料倉庫是用來分析特點主題域的，是以說資料倉庫是面向主題的。例如，電商行業的主題域通常分為交易域、會員域、商品域等。
- 內建的：資料倉庫內建了多個資料源，同一主題或産品相關資料可能來自不同的系統不同類型的資料庫，日志檔案等。
- 穩定的：資料一旦進入資料倉庫，則不可改變。資料倉庫的曆史資料是不應該被更新的，同時存儲穩定性較強
- 反映曆史資料變化的：資料倉庫儲存了長期的曆史資料，這點相對OLTP的資料庫而言。因為性能考慮後者統籌儲存近期的熱資料。
3. OLTP與OLAP
1）OLTP與OLAP概念
資料處理大緻可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。
OLTP是傳統的關系型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，并且提供直覺易懂的查詢結果。
2）OLTP與OLAP差別
OLTP 系統強調資料庫記憶體效率，強調記憶體各種名額的指令率，綁定變量，并發操作等。OLAP 系統則強調資料分析，強調SQL執行市場，磁盤I/O，分區等。
3）OLTP與OLAP差別
OLAP和數倉的關系是依賴互補的，一般以資料倉庫作為基礎，既從資料倉庫中抽取出詳細資料的一個子集并經過必要的聚集存儲到OLAP存儲中供資料分析工具讀取。
4. 資料倉庫的作用
資料倉庫将來自不同來源的結構化資料聚合起來，用于業務智能領域的比較和分析，資料倉庫是包含多種資料的存儲庫，并且是高度模組化的。
如下圖所示：各個系統的中繼資料通過ETL同步到操作性資料倉庫ODS中，對ODS資料進行面向主題域模組化形成DW（資料倉庫），DM是針對某一個業務領域建立模型，具體使用者（決策層）檢視DM生成的報表。
什麼是ETL?（extraction-transformation-load 抽取-轉換-加載）
傳統的資料倉庫內建處理架構是ETL，利用ETL平台的能力，E=從源資料庫抽取資料，L=将資料清洗（不符合規則的資料）、轉化（對表按照業務需求進行不同次元、不同顆粒度、不同業務規則計算進行統計），T=将加工好的表以增量、全量、不同時間加載到資料倉庫。
什麼是ELT?（extraction-load-transformation抽取-加載-轉換）
大資料背景下的架構體系是ELT結構，其根據上層的應用需求，随時從資料中台中抽取想要的原始資料進行模組化分析。
ELT是利用資料庫的處理能力，E=從源資料庫抽取資料，L=把資料加載到目标庫的臨時表中，T=對臨時表中的資料進行轉換，然後加載到目标庫目标表中。
ELT對比ETL的優勢：
- 資源使用率的提升：ELT主要通過資料庫引擎來實作系統的可擴充性（尤其是當資料加工過程在晚上時，可以充分利用資料庫引擎的資源）。
- 任務運作效率的提升：ELT可以保持所有的資料始終在資料庫當中，避免資料的加載和導出，進而保證效率，提高系統的可監控性。
- 并行處理優化：ELT可以根據資料的分布情況進行并行處理優化，并可以利用資料庫的固有功能優化磁盤I/O。
- 可擴充性增強：ELT的可擴充性取決于資料庫引擎和其硬體伺服器的可擴充性。
- 性能優化：通過對相關資料庫進行性能調優，ETL過程獲得3到4倍的效率提升一般不是特别困難。
資料倉庫系統的作用能實作跨業務條線、跨系統的資料整合，為管理分析和業務決策提供統一的資料支援。資料倉庫能夠從根本上幫助你把公司的營運資料轉化成為高價值的可以擷取的資訊（或知識），并且在恰當的時候通過恰當的方式把恰當的資訊傳遞給恰當的人。以下圖為例：
資料倉庫的作用主要展現在企業決策、分析、計劃和響應以下幾個方面：
資料倉庫針對實時資料處理和非結構化資料處理能力較弱，以及在業務在預警預測等方面應用有一定的限制。
二、資料平台
1. 資料平台概念
大資料時代，資料平台一般被稱之為大資料平台。
狹義上的資料平台：是為了解決資料倉庫不能處理非結構化資料和報表開發周期長的問題，是以先撇開業務需求、把企業所有的資料都抽取出來放到一起，成為一個大的資料集，其中有結構化資料、非結構化資料等。當業務方有需求的時候，再把他們需要的若幹個小資料集單獨提取出來，以資料集的形式提供給資料應用。
廣義的大資料平台：廣義的大資料平台通常被賦予更多的使命，以處理海量資料存儲、計算及不間斷流資料實時計算、離線計算、智能推薦、互動式查詢、資料湖建構等場景為主的一套基礎設施。典型的包括基于Hadoop 生态建構的大資料平台。提供易于部署及管理的 Hive、Spark、HBase、Flink、StarRocks、Iceberg、Alluxio 等開源大資料計算和存儲引擎。
狹義的資料平台和傳統的資料平台（資料倉庫）功能一緻，差別隻是技術架構和資料容量方面的不同。
廣義上的大資料平台是資料湖的基座，提供易于部署和管理的泛Hadoop生态及其他存儲計算引擎的PaaS平台，助力企業建構企業級資料湖技術架構。
Tip：本文以狹義的資料平台進行對比，這裡不對狹義的資料平台做過多概述。
三、資料中台
1. 資料中台概念
資料中台的起源：2015 年年中，馬雲帶領阿裡巴巴集團高管拜訪了一家芬蘭的小型遊戲公司 Supercell。這家僅有不到 200 名員工的小型遊戲公司竟創造了高達 15 億美元的年稅前利潤！而 Supercell 之是以能夠支援多個團隊快速、靈活地推出高品質的遊戲作品，其強大的中台能力功不可沒。
是以，在拜訪 Supercell 的旅程結束之後，馬雲決定對阿裡巴巴的組織和系統架構進行整體調整，建立阿裡産品技術和資料能力的強大中台，建構“大中台，小前台”的組織和業務體制。
資料中台的主要目的：解決企業在發展過程中，由于資料激增與業務的擴大而出現的統計口徑不一緻、重複開發、名額開發需求響應慢、資料品質低、資料成本高等問題。通過一系列資料工具（中繼資料中心、資料名額中心、數倉模型中心、資料資産中心-資産品質/治理/安全、資料服務中心等），規範資料供應鍊的各個環節。
2. 資料中台特點
資料中台特點：以一種标準的、安全的、可靠的、統一的、共享的、解耦的、服務化的方式支援前端資料的應用。
3. 資料中台作用
（阿裡資料中台邏輯架構圖）
（資料中台産品能力圖）
資料中台通過對企業内外部多源異構的資料采集、建設、管理、分析和應用，使資料對内優化管理提高業務價值，對外進行資料合作讓業務價值得到釋放，使之成為企業資料資産管理中樞。資料中台建立後，會形成資料API服務，為企業和客戶提供高效各種資料服務。
資料中台對一個企業的數字化轉型和可持續發展起着至關重要的作用。資料中台為解耦而生，企業建設資料中台的最大意義就是應用與資料之間的解耦，這樣企業就可以不受限制地按需建構滿足業務需求的資料應用。
建構了開放、靈活、可擴充的企業級統一資料管理和分析平台， 将企業内、外部資料随需關聯，打破了資料的系統界限。
利用大資料智能分析、資料可視化等技術，實作了資料共享、日常報表自動生成、快速和智能分析，滿足企業各級部門之間的資料分析應用需求。
深度挖掘資料價值，助力企業數字化轉型落地。實作了資料的目錄、模型、标準、認責、安全、可視化、共享等管理，實作資料集中存儲、處理、分類與管理，建立大資料分析工具庫、算法服務庫，實作報表生成自動化、資料分析靈活化、資料挖掘可視化，實作資料品質評估、落地管理流程。
四、資料湖
1. 資料湖概念
資料湖起源：資料湖的起源，應該追溯到2010年10月，由 Pentaho 的創始人兼 CTO， James Dixon 所提出，他提出的目的就當時曆史背景來看，其實是為了推廣自家産品 Pentaho。當時核心要解決的問題是傳統資料倉庫報表分析面臨的兩個問題：
- 隻使用部分屬性，這些資料隻能回答預先定義好(pre-determined)的問題。
- 資料被聚合了，最低層級的細節丢失了，能回答的問題被限制了。
而我們目前所讨論的資料湖，已經遠遠超過了當初 James Dixon 所定義的資料湖，各廠商之間也對資料湖有了更多的不同定義。
1）AWS
A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.
“資料湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化資料。您可以按原樣存儲資料（無需先對資料進行結構化處理），并運作不同類型的分析– 從控制台和可視化到大資料處理、實時分析和機器學習，以指導做出更好的決策。”
2）微軟
Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics.
“Azure 的資料湖包括一切使得開發者、資料科學家、分析師能更簡單的存儲、處理資料的能力，這些能力使得使用者可以存儲任意規模、任意類型、任意産生速度的資料，并且可以跨平台、跨語言的做所有類型的分析和處理。資料湖在能幫助使用者加速應用資料的同時，消除了資料采集和存儲的複雜性，同時也能支援批處理、流式計算、互動式分析等。”
3）阿裡雲
“資料湖是統一存儲池，可對接多種資料輸入方式，您可以存儲任意規模的結構化、半結構化、非結構化資料。資料湖可無縫對接多種計算分析平台，根據業務場景不同，可以選擇相應的計算引擎對資料湖中存儲的資料進行資料處理與分析，進而打破孤島，挖掘業務價值。”
2. 資料湖内容
資料湖中包括來自于關系型資料庫中的結構化資料（行和列）、半結構化資料（如CSV、日志、XML、JSON）、非結構化資料（如 email、文檔、PDF 等）和 二進制資料（如圖像、音頻、視訊）。
3. 資料湖的特點
- 統一的資料存儲，存放原始的資料。
- 支援任意結構的資料存儲，包括結構化、半結構化、非結構化。
- 支援多種計算分析，适用多種應用場景。
- 支援任意規模的資料存儲與計算能力。
- 目标都是為了更好，更快的發現資料價值。
4. 資料湖能夠解決的問題
1）資料湖整體架構
最底下是分布式檔案系統；
第二層是資料加速層。資料湖架構是一個存儲計算徹底分離的架構，如果所有的資料通路都遠端讀取檔案系統上的資料，那麼性能和成本開銷都很大。如果能把經常通路到的一些熱點資料緩存在計算節點本地，這就非常自然的實作了冷熱分離，一方面能收獲到不錯的本地讀取性能，另一方面還節省了遠端通路的帶寬。
第三層就是 Table format 層，主要是把一批資料檔案封裝成一個有業務意義的 table，提供 ACID、snapshot、schema、partition 等表級别的語義。
最上層就是不同計算場景的計算引擎了。開源的一般有 Spark、Flink、Hive、Presto、Hive MR 等，這一批計算引擎是可以同時通路同一張資料湖的表的。
2）資料湖能解決哪類問題
資料分散，存儲散亂，形成資料孤島，無法聯合資料發現更多價值。
這方面來講，其實資料湖要解決的與資料倉庫是類似的問題，但又有所不同，因為它的定義裡支援對半結構化、非結構化資料的管理。而傳統資料倉庫僅能解決結構化資料的統一管理。
在這個萬物互聯的時代，資料的來源多種多樣，随着不同應用場景，産出的資料格式也是越來越豐富，不能再僅僅局限于結構化資料。如何統一存儲這些資料，就是迫切需要解決的問題。
3）存儲成本
資料庫或資料倉庫的存儲受限于實作原理及硬體條件，導緻存儲海量資料時成本過高，而為了解決這類問題就有了HDFS/對象存儲這類技術方案。資料湖場景下如果使用這類存儲成本較低的技術架構，将會為企業大大節省成本。結合生命周期管理的能力，可以更好的為湖内資料分層（冷溫熱存放在不同的存儲媒體：HDD、SSD、MEM），不用糾結在是保留資料還是删除資料節省成本的問題。
4）SQL已經無法滿足的分析需求
越來越多種類的資料，意味着越來越多的分析方式，傳統的 SQL 方式已經無法滿足分析的需求，如何通過各種語言自定義貼近自己業務的代碼，如何通過機器學習挖掘更多的資料價值。
5）存儲/計算擴充性不足
傳統資料庫等在海量資料下，如規模到 PB 級别，因為技術架構的原因，已經無法滿足擴充的要求或者擴充成本極高，而這種情況下通過資料湖架構下的擴充技術能力，實作成本為0，硬體成本也可控。業務模型不定，無法預先模組化。
傳統資料庫和資料倉庫，都是 Schema-on-Write 的模式，需要提前定義 Schema 資訊。而在資料湖場景下，可以先儲存資料，後續待分析時，再發現 Schema，也就是 Schema-on-Read。
五、對比
1. 資料倉庫 VS 資料中台 VS 資料湖
2. 資料倉庫 VS 資料平台
因狹義的資料平台是由于資料倉庫具有曆史性的特性，其中存儲的資料大多是結構化資料，而資料平台的出現解決了資料倉庫不能處理非結構化資料和報表開發周期長的問題，故将資料倉庫與資料平台（狹義）單獨做對比。
本質差別：技術架構和資料容量方面的不同。
通過以上的論述，我們發現資料平台和資料湖好像存在諸多相似性，這二者之間的差別，從個人角度了解上分析應該是資料加工的角度不同，資料湖更着重于對原始資料的存儲，而資料平台則同資料倉庫一樣，需對原始資料進行清洗、轉換等資料處理後按照統一的标準規範進行存儲。
六、總結
根據以上資料平台、資料倉庫、資料湖和資料中台的概念論述和對比，我們進行如下總結：
- 資料中台、資料倉庫和資料湖沒有直接的關系；
- 資料中台、資料平台、資料倉庫和資料湖在某個次元上為業務産生價值的形式有不同的側重；
- 資料倉庫是資料驅動業務的邏輯概念，用于支援管理決策分析，為業務提供服務的主要方式是報表；
- 資料中台是企業級的邏輯概念，展現企業資料向業務價值轉化的能力，為業務提供服務的主要方式是資料 API；
- 資料湖是企業級的技術邏輯概念，展現企業級資料湖架構加速資料向業務價值轉化的能力，為業務提供服務的主要方式是原始資料；
- 資料中台、資料湖距離業務更近，能夠更快速的響應業務和應用開發需求，進而為業務提供速度更快的服務；
- 資料中台可以建立在資料倉庫和資料平台之上，是加速企業從資料到業務價值的過程的中間層；
本文由 @Z先生聊産品 原創釋出于人人都是産品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。