數(shù)據(jù)湖倉基礎(chǔ)知識2025年5月26日

R1.0

版數(shù)據(jù)倉庫

數(shù)據(jù)湖

數(shù)據(jù)湖倉目

錄CONTENTSPART

數(shù)據(jù)倉庫上世紀(jì)70年代，關(guān)系數(shù)據(jù)庫(傳統(tǒng)數(shù)據(jù)庫的主要類型)剛剛崛起時(shí)，美國康奈比爾

·恩門

(Bill

Innmon,

也有譯為比爾·

因蒙)就開始定義和討論數(shù)據(jù)倉庫這一術(shù)語。1988年，

IBM研究人員巴里

·德夫林

(BarryDevlin)

和鮑爾

·

(PaulMurphy),聯(lián)合發(fā)表了文章《商業(yè)和信息系統(tǒng)的架構(gòu)》,其中引入了“商業(yè)數(shù)據(jù)倉庫”一詞。他們還開發(fā)了一種叫做“業(yè)務(wù)數(shù)據(jù)倉庫”的系統(tǒng)。幾年后，1990年，美國科學(xué)家拉爾夫

·金博爾

(RalphKimball)創(chuàng)立了Red

Brick

Systems

公司，推出專門用于數(shù)據(jù)倉庫的數(shù)據(jù)庫管理系統(tǒng)Red

Brick

Warehouse。1991年，

比爾

·恩門創(chuàng)立了PrismSolutions公司，推出用于開發(fā)數(shù)據(jù)倉庫的軟件PrismWarehouseManager。同年，比爾

·恩門正式出版了數(shù)據(jù)倉庫的經(jīng)典著作——《構(gòu)建數(shù)據(jù)庫倉庫》,標(biāo)志著數(shù)據(jù)倉

庫概念的正式確立。他也被譽(yù)為“數(shù)據(jù)倉庫之父”?！鯏?shù)據(jù)倉庫的誕生比爾

·

恩門□數(shù)據(jù)倉庫的定義數(shù)據(jù)倉庫，英文全稱Data

Warehouse,簡稱DW

或DWH。比爾·恩門在《構(gòu)建數(shù)據(jù)庫倉庫》書中給出的數(shù)據(jù)倉庫的定義——·數(shù)據(jù)倉庫，是一個(gè)面向主題的

(Subject

Oriented)、集成的(Integrated)

、

相對穩(wěn)定的

(Non-Volatile)

、

反映歷史變化

(TimeVariant)

的數(shù)據(jù)集合，用于支持管理決策

(DecisionMakingSupport)。□數(shù)據(jù)倉庫的特征支持管理決策·

描述：簡單來說，傳統(tǒng)數(shù)據(jù)庫主要是員工使用，支撐某項(xiàng)具體的工作(例如收銀系統(tǒng)等)。而數(shù)據(jù)倉庫主

要是管理層使用，用于掌握宏觀情況，以便做出更合理的決策?！?/p>

總結(jié)：數(shù)據(jù)倉庫是一個(gè)戰(zhàn)略級的工具。它通常用于商業(yè)智能

(Business

Intelligence,簡

稱BI)和決策支

持，可以幫助企業(yè)從大量數(shù)據(jù)中獲得有價(jià)值的信息，增加洞察能力?！?/p>

目的：增加收入、提升效率、降低成本。□數(shù)據(jù)倉庫的特征面向主題·

描述：傳統(tǒng)數(shù)據(jù)庫，圍繞具體的工作(應(yīng)用)來組織數(shù)據(jù)，用于一個(gè)明確的事務(wù)。例如進(jìn)銷存數(shù)據(jù)庫、考

勤數(shù)據(jù)庫、財(cái)務(wù)數(shù)據(jù)庫等。而數(shù)據(jù)倉庫，是按照主題來組織數(shù)據(jù)的。所謂主題，是一個(gè)特定的業(yè)務(wù)領(lǐng)域，

或者一個(gè)明確的分析目標(biāo)，例如銷售分析主題、員工敬業(yè)度主題，學(xué)生在校表現(xiàn)主題等等。主題的范圍更大

，level

(層級)更高?！?/p>

總結(jié)：數(shù)據(jù)倉庫的數(shù)據(jù)，是多個(gè)傳統(tǒng)數(shù)據(jù)庫的集合和“拉通”。它把不同數(shù)據(jù)庫表單的信息挑選整合在一起，

提供了一個(gè)更全面的數(shù)據(jù)呈現(xiàn)?！?/p>

目的：適合支持管理者做決策和分析?！鯏?shù)據(jù)倉庫的特征集成·描述：數(shù)據(jù)倉庫可以整合來自多個(gè)不同數(shù)據(jù)源(企業(yè)數(shù)據(jù)庫、供應(yīng)商數(shù)據(jù)庫、渠道商數(shù)據(jù)庫等)的數(shù)據(jù)?！た偨Y(jié)：數(shù)據(jù)倉庫可以包括結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)等，但主要還是以結(jié)構(gòu)化數(shù)據(jù)為主?！?/p>

目的：提供一個(gè)更全面的視角，以便服務(wù)于分析和決策。架構(gòu)化數(shù)據(jù)非架構(gòu)化數(shù)據(jù)半架構(gòu)化數(shù)據(jù)數(shù)據(jù)倉庫□數(shù)據(jù)倉庫的特征相對穩(wěn)定·

描述：數(shù)據(jù)一旦被加載到數(shù)據(jù)倉庫中，通常不會(huì)更新或修改，確保了數(shù)據(jù)的穩(wěn)定性和用于長期分析的可靠性?！?/p>

總結(jié)：數(shù)據(jù)倉庫所涉及的操作，主要是數(shù)據(jù)查詢，而不是修改。數(shù)據(jù)查詢數(shù)據(jù)修改□數(shù)據(jù)倉庫的特征反映歷史變化·描述：傳統(tǒng)數(shù)據(jù)庫，一般都是數(shù)據(jù)更新。寫入新數(shù)據(jù)，替換舊數(shù)據(jù)。數(shù)據(jù)倉庫不一樣，它保存了大量的歷史

數(shù)

據(jù)

。·目

的

：

有

利

于

企

業(yè)

從

時(shí)

間

的

維

度，

分

析

業(yè)

務(wù)

的

發(fā)

展

趨

勢

。OrderyPaymenaDatawarehouseContactPoaduc■

數(shù)據(jù)倉庫□數(shù)據(jù)倉庫的參考架構(gòu)原始數(shù)據(jù)層

(ODS,Operation

Data

Store):也叫數(shù)據(jù)引入層、操作數(shù)據(jù)層、數(shù)據(jù)準(zhǔn)備層或貼源層，用于采集和存儲原始數(shù)據(jù)。數(shù)據(jù)公共層

(CDMmon

Data

Model)

:又分為基礎(chǔ)層/明細(xì)層

(DWD,DW

Detail)、匯總層/服務(wù)層(DWS,DW

Service)、公共維度層

(DIM)

。DWD

對源數(shù)據(jù)進(jìn)行清洗以便將其加載到數(shù)據(jù)倉庫中。DWS將經(jīng)過清洗和轉(zhuǎn)換后的數(shù)據(jù)并輕度匯總。DIW

用于保存維度信息，用于建模。數(shù)據(jù)應(yīng)用層

(ADS,Application

Data

Service):主要功能是保存結(jié)果數(shù)據(jù)，為外部系統(tǒng)提供查詢接口，用于滿足特定的商業(yè)智能、數(shù)據(jù)挖掘和報(bào)表應(yīng)用。數(shù)據(jù)應(yīng)用BI

報(bào)表展示

數(shù)據(jù)挖掘ADS

數(shù)據(jù)應(yīng)用層CDM

層DWS

數(shù)據(jù)匯總層DWD

數(shù)據(jù)明細(xì)層ODS

原始數(shù)據(jù)層ETL過程數(shù)據(jù)源企業(yè)數(shù)據(jù)

供應(yīng)商數(shù)據(jù)數(shù)據(jù)產(chǎn)品元數(shù)據(jù)管理DIM公共維度層數(shù)據(jù)安全運(yùn)營運(yùn)維數(shù)據(jù)倉庫公共數(shù)據(jù)……從不同的數(shù)據(jù)源系統(tǒng)中抽取數(shù)據(jù)。定期進(jìn)行的(例如每天或每周)。提高數(shù)據(jù)質(zhì)量和一致性。清洗包括修正錯(cuò)誤、去除重復(fù)項(xiàng)、處理缺失值等。轉(zhuǎn)換則是將數(shù)據(jù)轉(zhuǎn)化為統(tǒng)一

的格式，以便在數(shù)據(jù)倉庫中進(jìn)行有效存儲和查詢。采用特定的數(shù)據(jù)模型，對數(shù)據(jù)進(jìn)行組織和存儲，設(shè)計(jì)數(shù)據(jù)表。選擇合適的模型，可以簡化數(shù)據(jù)查詢和分析過程，提高查詢性能。通常采用大容量、高性能的存儲系統(tǒng)，以滿足大量數(shù)據(jù)的存儲和查詢需求。數(shù)據(jù)倉庫的存

儲結(jié)構(gòu)通常針對查詢性能進(jìn)行了優(yōu)化，如列式存儲、索引等。ETL后

的

數(shù)

據(jù)

，

會(huì)

被

加

載

到

數(shù)

據(jù)

倉

庫

中

。

分

為

全

量

加

載

和

增

量

加

載

兩

種

方

式

。根據(jù)需要

，

還可能會(huì)進(jìn)一步加工

，

例如聚合

、

摘要和索引創(chuàng)建

，

以優(yōu)化查詢性能

。支持各種數(shù)據(jù)分析和報(bào)表工具，如商業(yè)智能、SQL

查

詢

、OLAP

、

數(shù)據(jù)挖掘等。用戶可以通過這些工具，對數(shù)據(jù)進(jìn)行深入分析，找到其中的規(guī)律和趨勢。需要注意數(shù)據(jù)安全和訪問控制。確保數(shù)據(jù)的安全性和合規(guī)性，防止數(shù)據(jù)和濫用。數(shù)據(jù)抽取數(shù)據(jù)清洗和轉(zhuǎn)換數(shù)據(jù)建模數(shù)據(jù)存儲數(shù)據(jù)加載數(shù)據(jù)訪問與分析數(shù)據(jù)安全和訪問控制□數(shù)據(jù)倉庫的工作流□數(shù)據(jù)倉庫的工作流——數(shù)據(jù)建模數(shù)據(jù)倉庫建模中，比較有代表性的兩類方法論是Ralph

Kimball的建模方法論和Bill

Inmon建模方法論。Ralph

Kimball的維度建模方法論：是一種常用的數(shù)據(jù)倉庫建模方法，它強(qiáng)調(diào)使用星型模型、雪花模型、星座模型來設(shè)計(jì)數(shù)據(jù)倉庫。Bill

Inmon的建模方法論：認(rèn)為企業(yè)數(shù)據(jù)倉庫應(yīng)為原子數(shù)據(jù)的集成倉庫，應(yīng)用第三范式和ER

模型而非維度建模的事實(shí)表、維度表來建模。星型模型

雪花模型產(chǎn)品表產(chǎn)品ID產(chǎn)品名稱

產(chǎn)品類別

產(chǎn)品價(jià)格

產(chǎn)品顏色客戶ID客戶名稱

客戶電話

客戶年齡

客戶性別顧

客

表產(chǎn)

品

表產(chǎn)品ID

產(chǎn)品名稱

產(chǎn)品類別

產(chǎn)品價(jià)格

產(chǎn)品顏色客戶ID客戶名稱

客戶電話

客戶年齡

客戶性別顧

客

表供

應(yīng)

商

表產(chǎn)品ID供應(yīng)商名稱

供應(yīng)商位置

供應(yīng)商規(guī)模產(chǎn)品ID產(chǎn)品原料

產(chǎn)品產(chǎn)地日

期

表時(shí)間ID日期月份年份商店ID

商店地址

商店面積

商店類型商

店

表日

期

表時(shí)間ID日期月份年份商店ID商店地址

商店面積

商店類型商

店

表□數(shù)據(jù)倉庫的工作流——數(shù)據(jù)建模時(shí)間ID

商店ID

產(chǎn)品ID客戶ID銷售額

支付方式事

實(shí)

表時(shí)間ID商店ID產(chǎn)品ID客戶ID銷售額

支付方式事

實(shí)

表□數(shù)據(jù)倉庫的工作流——數(shù)據(jù)建模元數(shù)據(jù)：·

元數(shù)據(jù)是描述數(shù)據(jù)的數(shù)據(jù)。·

元數(shù)據(jù)中包括了數(shù)據(jù)存儲位置、數(shù)據(jù)格式、數(shù)據(jù)模式、數(shù)據(jù)分布等信息?！?/p>

它用以描述數(shù)據(jù)倉庫內(nèi)數(shù)據(jù)的結(jié)構(gòu)、位置和建立方法，便于數(shù)據(jù)倉庫的管理和使用?！鯏?shù)據(jù)倉庫的工作流——數(shù)據(jù)加載

ETL

的定義：·抽取

(Extract):主要負(fù)責(zé)從各種數(shù)據(jù)源(如關(guān)系型數(shù)據(jù)庫、文件、API

接口等)中捕獲和收集數(shù)據(jù)。在這個(gè)過程中，需要考慮到數(shù)據(jù)的完整性、一致性和準(zhǔn)確性，確保抽取到的數(shù)據(jù)是可靠且有效的?！まD(zhuǎn)換

(Transform)

:在數(shù)據(jù)抽取完成后，接下來就是對數(shù)據(jù)進(jìn)行清洗、轉(zhuǎn)換和整合。這個(gè)過程包括了對數(shù)據(jù)的去重、格式轉(zhuǎn)換、錯(cuò)誤修正、

數(shù)據(jù)關(guān)聯(lián)、計(jì)算等操作，以確保數(shù)據(jù)符合目標(biāo)數(shù)據(jù)倉庫的規(guī)范和要求?！?/p>

加載

(Load):主要將經(jīng)過轉(zhuǎn)換處理后的數(shù)據(jù)加載到目標(biāo)數(shù)據(jù)庫或數(shù)據(jù)倉庫中。在這個(gè)過程中，需要考慮到數(shù)據(jù)的加載效率、數(shù)據(jù)的完

整性和安全性等因素?！鯏?shù)據(jù)倉庫的工作流——數(shù)據(jù)加載

ETL的發(fā)展階段：·手工化階段：在早期階段，主要通過開發(fā)人員手動(dòng)編寫代碼來實(shí)現(xiàn)數(shù)據(jù)的抽取、轉(zhuǎn)換和加載。這種方式雖然靈活，但效率低下，且難以維護(hù)和擴(kuò)展?！すぞ呋A段：隨著技術(shù)的某省市面上出現(xiàn)了ETL

工具，如Informatica、OracleDataIntegrator、Talend等。這些工具提供了圖形化界面和豐富的功能，大大降低了開發(fā)人員的工作量，提高了ETL

過程的效率和可維護(hù)性?！?/p>

自動(dòng)化與智能化階段：近年來，隨著大數(shù)據(jù)和人工智能技術(shù)的興起，

ETL過程也在向自動(dòng)化和智能化方向發(fā)展。一些先進(jìn)的ETL

工具已經(jīng)能夠自動(dòng)識別數(shù)據(jù)源中的模式和規(guī)律，實(shí)現(xiàn)數(shù)據(jù)的智能抽取和轉(zhuǎn)換。也能夠通過自動(dòng)化工具實(shí)現(xiàn)ETL

任務(wù)的調(diào)度、監(jiān)控和告警等功能，進(jìn)一步提高了ETL

過程的效率和穩(wěn)定性。對比維度傳統(tǒng)數(shù)據(jù)庫數(shù)據(jù)倉庫設(shè)計(jì)方式面向事務(wù)的設(shè)計(jì)面向主題的設(shè)計(jì)設(shè)計(jì)目的支持業(yè)務(wù)操作和日常事務(wù)處理支持企業(yè)數(shù)據(jù)分析和決策數(shù)據(jù)特點(diǎn)當(dāng)前數(shù)據(jù)、細(xì)節(jié)化、短期存儲歷史數(shù)據(jù)、聚合、長期存儲主要應(yīng)用場景OLTP在線事務(wù)處理OLAP在線分析處理時(shí)效性實(shí)時(shí)性要求高實(shí)時(shí)性要求低操作特點(diǎn)數(shù)據(jù)更新修改較多不做數(shù)據(jù)更新成本建設(shè)和維護(hù)成本低建設(shè)和維護(hù)成本高■

數(shù)據(jù)倉庫□數(shù)據(jù)倉庫和傳統(tǒng)數(shù)據(jù)庫的對比□某省市

(Data

Mart)

的定義某省市可以認(rèn)為是數(shù)據(jù)倉庫的子集，是專用于特定業(yè)務(wù)部門或功能的數(shù)據(jù)系統(tǒng)。某省市的數(shù)據(jù)是從數(shù)據(jù)倉庫中提取并進(jìn)一步加工得到的。數(shù)

據(jù)

源

數(shù)據(jù)倉庫數(shù)據(jù)應(yīng)用報(bào)表展示數(shù)據(jù)分析數(shù)據(jù)挖掘數(shù)據(jù)查詢操作數(shù)據(jù)存儲數(shù)據(jù)倉庫某省市ODSDWDM1

DM2ETL抽取(Extract)轉(zhuǎn)換(Transform)

裝載(Load)外部數(shù)據(jù)數(shù)據(jù)日志數(shù)據(jù)元數(shù)據(jù)管理□某省市

(Data

Mart)

的優(yōu)點(diǎn)·

規(guī)模?。?/p>

由于只包含與特定主題相關(guān)的數(shù)據(jù)，因此某省市的規(guī)模相對較小，建和維護(hù)?！?/p>

數(shù)據(jù)深：

某省市可以滿足特定部門或用戶的需求，提供更加詳細(xì)和深入的數(shù)據(jù)支持?！?/p>

響應(yīng)快：

因?yàn)樗臄?shù)據(jù)量相對較小且針對特定需求進(jìn)行了優(yōu)化，所以能夠提供更快的查詢響應(yīng)時(shí)間?！?/p>

建設(shè)周期短：

數(shù)據(jù)倉庫的建設(shè)周期較長，

一般需要數(shù)個(gè)月甚至一年以上。某省市由于規(guī)模較小且面向特

定需求，所以建設(shè)周期通常較短，可以快速實(shí)現(xiàn)并投入使用。·靈活性高：某省市的數(shù)據(jù)模型和結(jié)構(gòu)可以根據(jù)特定需求進(jìn)行調(diào)整，具有較高的靈活性?！?/p>

成本低：

某省市的實(shí)現(xiàn)成本相對較低，因?yàn)槠鋽?shù)據(jù)量和復(fù)雜度較數(shù)據(jù)倉庫低?！鯏?shù)據(jù)倉庫的發(fā)展趨勢·發(fā)展早期，數(shù)據(jù)倉庫基本上就是基于傳統(tǒng)數(shù)據(jù)庫產(chǎn)品(例如Oracle)進(jìn)行構(gòu)建。數(shù)據(jù)倉庫最早也是離線的，數(shù)據(jù)源通過離線方

式導(dǎo)入到離線數(shù)據(jù)倉庫中。·

進(jìn)入21世紀(jì)，有了大數(shù)據(jù)技術(shù)(Hadoop、Spark

等)。就開始將這些技術(shù)引入到數(shù)據(jù)倉庫，通過MapReduce、Hive、SparkSQL

等離線計(jì)算引擎進(jìn)行數(shù)據(jù)處理，處理效率有了明顯提升?！?/p>

2010年左右，發(fā)展出了Lambda

架構(gòu)(離線+實(shí)時(shí)結(jié)合)和Kappa

架構(gòu)(批流

一體)。·近年，發(fā)展出了基于MPP

數(shù)據(jù)庫和數(shù)據(jù)湖的實(shí)時(shí)數(shù)倉架構(gòu)。這些架構(gòu)支持高性能并行處理，支持復(fù)雜查詢。在處理能力和效率上已經(jīng)今非昔比，能夠幫助企業(yè)更及時(shí)、更準(zhǔn)確地進(jìn)行決策。從部署方面來看，數(shù)據(jù)倉庫也有變化。以前是本地單機(jī)部署，后來是分布式部署，再后來，云計(jì)算崛起，就是云部署。·目

前

發(fā)

展

：Al與數(shù)據(jù)系統(tǒng)的深度結(jié)合。讓數(shù)據(jù)倉庫能夠更智能地處理和分析數(shù)據(jù)，提高數(shù)據(jù)的準(zhǔn)確性和可靠性。PART

數(shù)據(jù)湖□數(shù)據(jù)湖的定義數(shù)據(jù)湖，英文名叫做Data

Lake。數(shù)據(jù)湖和數(shù)據(jù)庫、數(shù)據(jù)倉庫一樣，是一種存儲和處理數(shù)據(jù)的平臺。更準(zhǔn)確來說，數(shù)據(jù)湖是一個(gè)技術(shù)體系。它不是某一個(gè)具體的產(chǎn)品，而是一種架構(gòu)，包括了很多的技術(shù)和組件?！鯏?shù)據(jù)湖的誕生背景2010年10月，在紐約的Hadoop

World大會(huì)上，Pentaho公司創(chuàng)始人及CTO

詹姆斯

·迪克森(James

Dixon)

率先提出了數(shù)據(jù)湖的概念。詹姆斯·迪克森之所以提出數(shù)據(jù)湖，主要是為了推廣自家的Pentaho

產(chǎn)品。Pentaho

是一個(gè)BI(BusinessIntelligence,商業(yè)智能)分析組件，嘗試將當(dāng)時(shí)新興的Hadoop

技術(shù)應(yīng)用于數(shù)據(jù)倉庫，以此解決數(shù)據(jù)倉庫

的能力不足問題?！鯏?shù)據(jù)湖的誕生背景數(shù)據(jù)倉庫正式誕生于1990年左右，到2010年，已經(jīng)無法跟上時(shí)代。數(shù)據(jù)倉庫(包括某省市)會(huì)對來自數(shù)據(jù)源的數(shù)據(jù)進(jìn)行預(yù)處理和篩選。所以，在進(jìn)行數(shù)據(jù)分析和數(shù)據(jù)價(jià)值

挖掘時(shí)，會(huì)面臨幾個(gè)問題：·數(shù)據(jù)被預(yù)處理過，只保留了指定的屬性。分析時(shí)，只能回答之前預(yù)設(shè)的問題?！?shù)據(jù)被篩選過，很多底層的細(xì)節(jié)被篩除了。分析時(shí)，無法獲得這些信息?！るS著當(dāng)時(shí)互聯(lián)網(wǎng)的高速發(fā)展，非結(jié)構(gòu)化數(shù)據(jù)以及半結(jié)構(gòu)化數(shù)據(jù)迅猛增長。數(shù)據(jù)倉庫主要以處理結(jié)構(gòu)化的數(shù)據(jù)為主，無法很好地滿足需求。換言之，數(shù)據(jù)倉庫是把所有數(shù)據(jù)源的數(shù)據(jù)，按一開始制定的規(guī)則，進(jìn)行了處理，變成了產(chǎn)品，缺乏靈活性?！鯏?shù)據(jù)湖的誕生背景數(shù)據(jù)湖解決了以下問題：數(shù)據(jù)湖中的數(shù)據(jù)接近原生，內(nèi)容齊全，屬性完整。應(yīng)用層在使用數(shù)據(jù)時(shí)，可以基于需求，進(jìn)行靈活設(shè)計(jì)。

數(shù)據(jù)信息未被篩選，底層細(xì)節(jié)都在，可以盡可能還原業(yè)務(wù)(也是為了更好地分析)。結(jié)構(gòu)化、非結(jié)構(gòu)化、半結(jié)構(gòu)化，所有數(shù)據(jù)都能保存和處理，滿足互聯(lián)網(wǎng)時(shí)代發(fā)展的需要。數(shù)據(jù)孤島問題。企業(yè)各個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)都放在一起了，當(dāng)然也就沒有孤島了，可以開發(fā)橫跨多個(gè)系

統(tǒng)的數(shù)據(jù)應(yīng)用?！鯏?shù)據(jù)湖的誕生背景2011年，CITO

Research網(wǎng)站的CTO

和作家丹·

伍德斯(Dan

Woods)

也力推數(shù)據(jù)湖的概念。他指出：“如果我們把數(shù)據(jù)比作大自然的水，那么各個(gè)江川河流的水加工，源源不斷地匯聚到數(shù)據(jù)湖中?！睘槭裁唇小皵?shù)據(jù)湖”?而不是“數(shù)據(jù)池”、“數(shù)據(jù)河”、“數(shù)據(jù)?！?·

“數(shù)據(jù)池”太小，體現(xiàn)不出數(shù)據(jù)的大量?！?/p>

“數(shù)據(jù)河”是流動(dòng)的，數(shù)據(jù)無法保存?！?/p>

“數(shù)據(jù)?！睕]有邊界。數(shù)據(jù)湖是屬于企業(yè)的，需要邊界，需要注意隱私和安全。□

數(shù)據(jù)湖的主要特征·

數(shù)據(jù)的多樣性：數(shù)據(jù)湖可以存儲多種類型的數(shù)據(jù)，包括結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。這符

合了物聯(lián)網(wǎng)、社交媒體和某著名企業(yè)互聯(lián)網(wǎng)的時(shí)代需求。數(shù)據(jù)湖有利于企業(yè)發(fā)展A業(yè)務(wù)，例如機(jī)器學(xué)習(xí)、生成式

人工智能等。·

處理的實(shí)時(shí)性：數(shù)據(jù)湖采用的是讀時(shí)模式

(Schema-On-Read)。只需加載原始數(shù)據(jù)，然后，當(dāng)準(zhǔn)備使用

數(shù)據(jù)時(shí)，再定義它?！?/p>

容量更大：數(shù)據(jù)湖具有海量的數(shù)據(jù)存儲能力。數(shù)據(jù)湖基于分布式存儲系統(tǒng)構(gòu)建，能夠靈活擴(kuò)展，可以輕松

應(yīng)對PB

級甚至EB

級的數(shù)據(jù)量。·

成本更低：數(shù)據(jù)湖往往基于開源軟件和廉價(jià)硬件構(gòu)建，而且部署在云環(huán)境中，成本大幅下降，減少了企業(yè)

的投資?！?/p>

應(yīng)用的多樣化：

企業(yè)用戶可以進(jìn)行批處理分析、實(shí)時(shí)流處理分析和交互式分析，滿足不同業(yè)務(wù)場景的需求。數(shù)據(jù)倉庫數(shù)據(jù)湖優(yōu)點(diǎn)·

數(shù)據(jù)體系嚴(yán)格，提前建?！?/p>

數(shù)據(jù)治理容易·

向特定引擎開放，高度優(yōu)化·

靈活性較高·

數(shù)據(jù)種類豐富(結(jié)構(gòu)/半結(jié)構(gòu)/非結(jié)構(gòu))·

成本較低缺點(diǎn)·

靈活性較低·

數(shù)據(jù)種類單一(結(jié)構(gòu)化為主)·

成本較高·

數(shù)據(jù)體系松散，事后建?！?/p>

數(shù)據(jù)治理困難·

向所有引擎開放，各引擎有限優(yōu)化主要作用·面向成熟數(shù)據(jù)的企業(yè)級分析與處理·面向異構(gòu)數(shù)據(jù)的科學(xué)探查與價(jià)值挖掘■

數(shù)據(jù)湖□數(shù)據(jù)湖與數(shù)據(jù)倉庫數(shù)據(jù)源

ETL數(shù)據(jù)源BI分析報(bào)表查詢BI分析報(bào)表查詢數(shù)據(jù)倉庫數(shù)據(jù)湖某省市按需□數(shù)據(jù)湖與數(shù)據(jù)倉庫特征數(shù)據(jù)湖數(shù)據(jù)倉庫數(shù)據(jù)類型結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化主要是結(jié)構(gòu)化數(shù)據(jù)存儲原始數(shù)據(jù)存儲，等待被查詢和分析時(shí)加工經(jīng)過加工的數(shù)據(jù)，符合預(yù)先定義的架構(gòu)處理方式ELT(提取、加載、轉(zhuǎn)換)ETL(提取、轉(zhuǎn)換、加載)靈活性高，可以存儲任何形式的數(shù)據(jù)，不需要預(yù)先定義架構(gòu)較低，需要預(yù)先定義數(shù)據(jù)架構(gòu)目標(biāo)用戶數(shù)據(jù)科學(xué)家、分析師、開發(fā)人員業(yè)務(wù)分析師、決策者分析目的探素性分析、機(jī)器學(xué)習(xí)、大數(shù)據(jù)處理標(biāo)準(zhǔn)報(bào)告、業(yè)務(wù)智能、績效指標(biāo)分析數(shù)據(jù)治理與質(zhì)量相對較松，依賴用戶對數(shù)據(jù)的掌握程度較為嚴(yán)格，確保數(shù)據(jù)質(zhì)量和一致性數(shù)據(jù)模式模式在讀(Schema-on-Read)模式在寫(Schema-on-Write)可擴(kuò)展性高，容數(shù)據(jù)量的增長受到架構(gòu)和設(shè)計(jì)的限制成本通常成本較低，尤其在初期存儲大量原始數(shù)據(jù)時(shí)高，由于需要大量預(yù)處理和維護(hù)預(yù)定義的架構(gòu)查詢性能可能需要更多的處理時(shí)間，因?yàn)閿?shù)據(jù)在查詢時(shí)才進(jìn)行

加工，但適合復(fù)雜分析快速，數(shù)據(jù)已經(jīng)過優(yōu)化以支持快速查詢□數(shù)據(jù)湖與數(shù)據(jù)倉庫□數(shù)據(jù)湖面對的挑戰(zhàn)·

性能數(shù)據(jù)湖的數(shù)據(jù)量很大，數(shù)據(jù)格式也很雜。缺乏一致的數(shù)據(jù)結(jié)構(gòu)和ACID(原子性、

一致性、隔離性和持久性)

事務(wù)支持，導(dǎo)致數(shù)據(jù)湖在滿足報(bào)告和分析需求時(shí)性能不佳?！?/p>

數(shù)據(jù)治理數(shù)據(jù)治理是數(shù)據(jù)湖的最核心要素(沒有之一),指對企業(yè)中數(shù)據(jù)的可用性、完整性和安全性的全面管理，以提升數(shù)據(jù)的質(zhì)量和可用性?！鯏?shù)據(jù)湖面對的挑戰(zhàn)——數(shù)據(jù)治理·我們可以將數(shù)據(jù)源的數(shù)據(jù)“倒入”數(shù)據(jù)湖，無需進(jìn)行處理。但是，“不處理”并不代表“不治理”、“不管理”?！?/p>

數(shù)據(jù)湖擁有海量數(shù)據(jù)，管理元數(shù)據(jù)顯得更為重要。數(shù)據(jù)湖會(huì)建立一個(gè)數(shù)據(jù)目錄。數(shù)據(jù)目錄是元數(shù)據(jù)的集合，

可以理解為是一張“數(shù)據(jù)清單”。通過數(shù)據(jù)目錄，用戶可以搜索和發(fā)現(xiàn)數(shù)據(jù)湖中的數(shù)據(jù)，提高數(shù)據(jù)的可訪問

性和可發(fā)現(xiàn)性。□數(shù)據(jù)湖面對的挑戰(zhàn)——數(shù)據(jù)治理數(shù)據(jù)治理還需要關(guān)注數(shù)據(jù)質(zhì)量和數(shù)據(jù)合規(guī)?！?/p>

數(shù)據(jù)質(zhì)量：數(shù)據(jù)湖存儲的數(shù)據(jù)，具有不同的質(zhì)量和精度，可能導(dǎo)致分析結(jié)果不準(zhǔn)確、不可靠。因此，需要

建立數(shù)據(jù)質(zhì)量系統(tǒng)，確保數(shù)據(jù)的完整性、準(zhǔn)確性、

一致性以及標(biāo)準(zhǔn)化?！?/p>

數(shù)據(jù)合規(guī)：

數(shù)據(jù)存儲和使用必須符合法律法規(guī)，例如GDPR

(通用數(shù)據(jù)保護(hù)條例)、HIPAA

(健康保險(xiǎn)便

利和責(zé)任法案)等。數(shù)據(jù)合規(guī)一旦出問題，可能導(dǎo)致數(shù)據(jù)、法律訴訟或巨額罰款，損害企業(yè)的聲譽(yù)，

也帶來經(jīng)濟(jì)上的損失?！鯏?shù)據(jù)湖面對的挑戰(zhàn)——數(shù)據(jù)治理·

如果數(shù)據(jù)湖沒有得到妥善的治理，就會(huì)變成龐大的“數(shù)據(jù)沼澤”?！?/p>

數(shù)據(jù)沼澤是一種設(shè)計(jì)不良、未充分歸檔或未有效維護(hù)的數(shù)據(jù)湖。這些缺陷損害了檢索數(shù)據(jù)的能力，用戶無法

有效地分析和利用數(shù)據(jù)。盡管數(shù)據(jù)已經(jīng)存在，但如果沒有上下文元數(shù)據(jù)，數(shù)據(jù)沼澤就無法檢索數(shù)據(jù)。·

數(shù)據(jù)沼澤無法發(fā)揮數(shù)據(jù)的價(jià)值，反而變成企業(yè)的累贅，浪費(fèi)資源。□

數(shù)據(jù)湖的架構(gòu)不同的方案提供商，會(huì)提出不同的數(shù)據(jù)湖架構(gòu)。但是，基本上都包括四個(gè)主要層次：·

數(shù)據(jù)攝取層(數(shù)據(jù)采集層)

:負(fù)責(zé)從各種數(shù)據(jù)源收集數(shù)據(jù)，并將其傳輸?shù)綌?shù)據(jù)湖中?！?/p>

數(shù)據(jù)存儲層：

以原始格式存儲大規(guī)模的數(shù)據(jù)?！?/p>

數(shù)據(jù)管理層：

對數(shù)據(jù)進(jìn)行管理和組織，包括數(shù)據(jù)的分類、編目、索引等功能。還要負(fù)責(zé)數(shù)據(jù)的安全和合規(guī)?！?/p>

數(shù)據(jù)訪問層(數(shù)據(jù)分析層):提供各種工具和框架，支持用戶對數(shù)據(jù)湖中的數(shù)據(jù)進(jìn)行查詢、統(tǒng)計(jì)分析、機(jī)

器學(xué)習(xí)等操作?！?/p>

數(shù)據(jù)湖□數(shù)據(jù)湖的架構(gòu)數(shù)據(jù)源結(jié)構(gòu)化數(shù)據(jù)半結(jié)構(gòu)化數(shù)據(jù)非架構(gòu)化數(shù)據(jù)前

端工具與應(yīng)用大數(shù)據(jù)管理交互式查詢運(yùn)營分析.計(jì)算引擎批處理流計(jì)算交互式機(jī)器學(xué)習(xí)任務(wù)管理目錄管理數(shù)據(jù)接入質(zhì)量管理更新集中式存儲流程編排數(shù)據(jù)溯源權(quán)限管理萃

取

沉

淀數(shù)據(jù)湖數(shù)據(jù)湖管理用戶功能方向典型工具和組件數(shù)據(jù)存儲對象存儲：

Amazon

S3、Azure

Data

Lake

Storage、Google

Cloud

Storage、阿里云OSS分布式文件系統(tǒng)：HDFS數(shù)據(jù)處理與計(jì)算引擎批處理：Apache

Spark:支持大規(guī)模數(shù)據(jù)處理、SQL、機(jī)器學(xué)習(xí)的通用引擎。Apache

Hive:基于Hadoop的數(shù)據(jù)倉庫工具，支持SQL查詢。流處理：Apache

Flink:低延遲的流處理框架，支持事件時(shí)間語義。Apache

Kafka

Streams:輕量級流處理庫，與Kafka深度集成。交互式查詢：Presto/Trino:分布式SQL查詢引擎，支持跨數(shù)據(jù)源快速分析。Dremio:基于數(shù)據(jù)湖的查詢加速引擎。數(shù)據(jù)湖表格式Apache

Iceberg:面向分析場景的表格式，支持事務(wù)、模式變更和時(shí)間旅行。Delta

Lake:Databricks開源的表格式，深度集成Spark.Apache

Hudi:支持增量更新和刪除，適合流批一體場景。元數(shù)據(jù)管理AWS

Glue

Data

Catalog:云托管的元數(shù)據(jù)服務(wù)，兼容Hive

Metastore.Apache

Hive

Metastore:傳統(tǒng)的元數(shù)據(jù)存儲服務(wù)，常用于Hadoop生態(tài)。Nessie:支持Git-like分支和版本控制的元數(shù)據(jù)管理工具。數(shù)據(jù)治理與安全Apache

Atlas:元數(shù)據(jù)治理框架，支持?jǐn)?shù)據(jù)血緣和分類。AWS

Lake

Formation:云上數(shù)據(jù)湖治理工具，統(tǒng)一權(quán)限和元數(shù)據(jù)管理。Open

Policy

Agent(OPA):統(tǒng)一策略管理工具，控制數(shù)據(jù)訪問權(quán)限。Apache

Ranger:Hadoop生態(tài)的權(quán)限控制工具，支持細(xì)粒度訪問控制。數(shù)據(jù)集成與攝取Apache

Kafka:實(shí)時(shí)數(shù)據(jù)管道，用于流式數(shù)據(jù)攝取。

Debezium:CDC(變更數(shù)據(jù)捕獲)工具，捕獲數(shù)據(jù)庫變更。AWS

DMS/Azure

Data

Factory:云服務(wù)的數(shù)據(jù)遷移和ETL工具?！鯏?shù)據(jù)湖的工具和組件□數(shù)據(jù)湖的架構(gòu)圍繞數(shù)據(jù)湖的技術(shù)組件和產(chǎn)品，一般來自四類廠商：·

開源解決方案·

云服務(wù)商(如亞馬遜AWS、華為云等)·

專業(yè)數(shù)據(jù)庫出身的廠商·

一些初創(chuàng)企業(yè)或團(tuán)隊(duì)PART

數(shù)據(jù)湖倉□

數(shù)據(jù)湖倉的定義數(shù)據(jù)湖倉

(Data

Lakehouse),也被稱為湖倉一體。數(shù)據(jù)湖倉是一種將數(shù)據(jù)倉庫和數(shù)據(jù)湖打通的新型開放式架構(gòu)。數(shù)據(jù)湖倉既具備數(shù)據(jù)湖的靈活性，也具備數(shù)據(jù)倉庫的高性能及管理能力，為企業(yè)進(jìn)行數(shù)據(jù)治理帶來了更大的便利和更高的效率。數(shù)

據(jù)

湖數(shù)據(jù)湖倉數(shù)據(jù)倉庫□數(shù)據(jù)湖倉的誕生數(shù)據(jù)倉庫和數(shù)據(jù)湖各有優(yōu)缺點(diǎn)，有企業(yè)開始考慮將兩者進(jìn)行結(jié)合。主要思路包括兩種：一種是讓數(shù)據(jù)倉庫支持對數(shù)據(jù)湖的訪問。還有一種，是讓數(shù)據(jù)湖具備數(shù)據(jù)倉庫的一些能力?！で罢弑容^有代表性的，是2017年Redshift推出的RedshiftSpectrum。它支持Redsit數(shù)據(jù)倉庫用戶訪問AWS

S3數(shù)據(jù)湖的數(shù)據(jù)?！ず笳哂写硇缘谋容^多，包括2017年Hortonworks

孵化出的Apache

Atlas和Ranger項(xiàng)目，2018年Nexflix開源的增強(qiáng)版本元數(shù)據(jù)服務(wù)系統(tǒng)lceberg。2018-2019

年

，Uber

和Databricks相繼推出了ApacheHudi和DeltaLake,推出增量文件格式，用以

支持Update/lnsert、事務(wù)等數(shù)據(jù)倉庫功能。所有這些嘗試和努力，都多多少少存在一些缺陷(數(shù)據(jù)倉庫和數(shù)據(jù)湖存在本質(zhì)的區(qū)別，整合難度很大),并不算成功?！?/p>

數(shù)據(jù)湖倉的誕生2020年，數(shù)據(jù)智能獨(dú)角獸企業(yè)Databricks

(提出DeltaLake的公司，數(shù)據(jù)湖的代表企業(yè))正式提出了數(shù)據(jù)湖倉

(Data

Lakehouse)

概念。Databricks聯(lián)合創(chuàng)始人兼首席執(zhí)行官阿里

·戈德西

(AliGhodsi)表示：“從長遠(yuǎn)來看，所有數(shù)據(jù)倉庫都將被納入數(shù)

據(jù)湖倉，這不會(huì)在一夜之間發(fā)生——這些東西會(huì)共存一段時(shí)間——在價(jià)格和性能上，數(shù)據(jù)湖倉完勝數(shù)據(jù)倉庫?！薄?/p>

數(shù)據(jù)湖倉□數(shù)據(jù)湖倉的誕生數(shù)據(jù)倉庫DataWarehouse1990-2010數(shù)據(jù)湖倉Data

Lakehouse2020-現(xiàn)在數(shù)據(jù)湖Data

Lake2010-2020□數(shù)據(jù)湖倉的特點(diǎn)數(shù)據(jù)湖倉的特點(diǎn)，其實(shí)就是數(shù)據(jù)倉庫的優(yōu)點(diǎn)+數(shù)據(jù)湖的優(yōu)點(diǎn)。在數(shù)據(jù)存儲方面：繼承了數(shù)據(jù)湖的優(yōu)勢，支持多樣化數(shù)據(jù)，且以HDFS

或云對象存儲為基礎(chǔ)，實(shí)現(xiàn)了低成本、高可用。在數(shù)據(jù)一致性方面：

提

供ACID

(原子性、一致性、隔離性、持久性)保證，確保數(shù)據(jù)寫入的一致性，保證了多方同時(shí)讀取或?qū)懭霐?shù)據(jù)時(shí)的數(shù)據(jù)準(zhǔn)確性。在數(shù)據(jù)管理方面：數(shù)據(jù)湖倉實(shí)現(xiàn)了統(tǒng)一的元數(shù)據(jù)管理，支持全鏈路血緣，提供統(tǒng)一的命名空間、全局的數(shù)據(jù)目錄。無論數(shù)據(jù)

存儲在何處，使用何種計(jì)算引擎，用戶都能通過統(tǒng)一的API進(jìn)行快速檢索、理解與訪問數(shù)據(jù)。數(shù)據(jù)治理，變得非常高效。在數(shù)據(jù)安全方面：數(shù)據(jù)湖倉一般還支持多租戶和庫表列級數(shù)據(jù)權(quán)限，能夠很好地進(jìn)行租戶隔離和數(shù)據(jù)權(quán)限管控，確保了數(shù)據(jù)的安全性和隱私性。維度數(shù)據(jù)倉庫數(shù)據(jù)湖數(shù)據(jù)湖倉(湖倉一體)數(shù)據(jù)類型結(jié)構(gòu)化數(shù)據(jù)為主任意類型(原始數(shù)據(jù))結(jié)構(gòu)化+半結(jié)構(gòu)化存儲成本較高低中等處理模式Schema-on-WriteSchema-on-Read混合模式ACID符合不符合符合核心優(yōu)勢高性能分析、事務(wù)一致性靈活性、低成本存儲湖+倉能力融合典型場景BI、報(bào)表機(jī)器學(xué)習(xí)、數(shù)據(jù)探索混合負(fù)載分析□數(shù)據(jù)湖倉的特點(diǎn)□數(shù)據(jù)湖倉的參考架構(gòu)早期是數(shù)據(jù)倉庫和數(shù)據(jù)湖獨(dú)立建設(shè)。后來逐漸形成了“湖上建倉”與“倉外掛湖”兩種實(shí)踐路徑：·

湖上建倉：是指基于數(shù)據(jù)湖架構(gòu)，或者以數(shù)據(jù)湖作為數(shù)據(jù)存儲中間層，實(shí)現(xiàn)多源異構(gòu)數(shù)據(jù)的統(tǒng)一存儲。然后，以統(tǒng)一調(diào)

用接口方式調(diào)用計(jì)算引擎，最終實(shí)現(xiàn)上下結(jié)構(gòu)的湖倉一體架構(gòu)?！?/p>

倉外掛湖：是指以MPP數(shù)據(jù)庫為基礎(chǔ)，使用可插拔架構(gòu)，通過開放接口對接外部存儲，實(shí)現(xiàn)統(tǒng)一存儲。上層應(yīng)用

商業(yè)智能湖倉數(shù)據(jù)治理安全管理數(shù)據(jù)湖數(shù)據(jù)源

結(jié)構(gòu)化數(shù)據(jù)分析統(tǒng)一湖倉血緣統(tǒng)一元數(shù)據(jù)管理計(jì)算流動(dòng)半結(jié)構(gòu)化數(shù)據(jù)看板統(tǒng)一數(shù)據(jù)管理數(shù)據(jù)倉庫非結(jié)構(gòu)化□數(shù)據(jù)湖倉的參考架構(gòu)廠商數(shù)據(jù)湖倉解決方案國外廠商亞馬

遜AWSRedshiftSpectrum某著名企業(yè)AzureAzureDatabricksDatabricksDatabricksLakehouseSnowflakeIceberg+Polaris國內(nèi)廠商阿里云Mapute+DataWorks騰訊云TCHouse+DLCServerlessSpark華為云Fusion

Insight星環(huán)科技TDH+ArgoDB鏡舟科技StarRocks+Paimon滴普科技FastData□數(shù)據(jù)湖倉的參考架構(gòu)□數(shù)據(jù)湖倉的參考架構(gòu)科杰的數(shù)據(jù)湖倉架構(gòu)：

企業(yè)級湖倉一體解決方案平臺安全與監(jiān)控?cái)?shù)據(jù)源

統(tǒng)一存儲

批處理Hudi/Delta/lceberg

ETLHDFSERPCRMS3

實(shí)時(shí)處理Ganglia數(shù)據(jù)科學(xué)家數(shù)據(jù)分析師業(yè)務(wù)人員SaaS

服務(wù)API調(diào)用-C科本大數(shù)據(jù)圖片來自網(wǎng)絡(luò)Keberos

LDAPStaged30LSQL機(jī)器學(xué)習(xí)/人工智能AITensorflow

Spark

ML服務(wù)數(shù)據(jù)開發(fā)管理

平臺數(shù)據(jù)資產(chǎn)目錄實(shí)時(shí)計(jì)算平臺數(shù)據(jù)科學(xué)平臺數(shù)據(jù)服務(wù)平臺圖形/視頻/音頻OSSIOT

設(shè)備EventStreamAnalysiseoNCETMATIa

oN

Si0ATA

sOLuTIONAzure

的數(shù)據(jù)湖倉架構(gòu)：

IngestAzu

u

entspaikbsEvHre■

數(shù)據(jù)湖倉□數(shù)據(jù)湖倉的參考架構(gòu)ServeAzure

Machine

LearningAzureDatabnicksSQLAnalyticsPower

BIProcessAzureDatabricksmlflowAzureSynapse

AnalyticsDELTALAKEStoreAzure

DataFactoryBrOnze

Sitver

GoldAzureDevOpsAzureKeyVaultAzure

Active

DirectoryMonitorand

governAzure

MonitorAzureCost

Managementand

Billing圖片來自網(wǎng)絡(luò)AzureKubenetesServicesAzureDataLake

StorageMicrosoft

AzureAzurePurview數(shù)據(jù)消費(fèi)層AthenaEMR

Glue數(shù)據(jù)處理層