@TOC
秀昌筆記
數(shù)據(jù)倉庫和數(shù)據(jù)集市詳細信息:ODS、DW、DWD、DWM、DWS、ADS:
失落里錐谷水倉實戰(zhàn)中的1項目需求及體系結(jié)構(gòu)設(shè)計:
失落里錐谷水倉庫實戰(zhàn)中的二水倉庫分層維度建模:
失落里錐谷水倉庫實戰(zhàn)中的三水倉庫建設(shè):
失落里錐谷數(shù)據(jù)倉庫4.0視頻教程
B站直通車:2021新版電子企業(yè)數(shù)量倉庫V4.0、大數(shù)據(jù)倉庫項目實戰(zhàn):
百度網(wǎng)盤:提取代碼:yyds
阿里云:啊,代碼提?。?35o
數(shù)據(jù)流
使用案例
什么是數(shù)字倉庫DW
Data warehouse(可以縮寫為DW或DWH)數(shù)據(jù)倉庫是一個完整的理論體系,包括ETL、調(diào)度和建模(如果數(shù)據(jù)庫已經(jīng)存在很多)。
數(shù)據(jù)倉庫的方案建設(shè)的目的,是為前端查詢和分析作為基礎(chǔ),主要應(yīng)用于OLAP(on-line Analytical Processing),支持復(fù)雜的分析操作,側(cè)重決策支持,并且提供直觀易懂的查詢結(jié)果。目前行業(yè)比較流行的有:AWS Redshift,Greenplum,Hive等。
數(shù)據(jù)倉庫并不是數(shù)據(jù)的最終目的地,而是為數(shù)據(jù)最終的目的地做好準備,這些準備包含:清洗、轉(zhuǎn)義、分類、重組、合并、拆分、統(tǒng)計等
主要特點(了解)
- 面向主題[附錄]操作型數(shù)據(jù)庫組織面向事務(wù)處理任務(wù),而數(shù)據(jù)倉庫中的數(shù)據(jù)是按照一定的主題域進行組織。主題是指用戶使用數(shù)據(jù)倉庫進行決策時所關(guān)心的重點方面,一個主題通過與多個操作型信息系統(tǒng)相關(guān)。
- 集成需要對源數(shù)據(jù)進行加工與融合,統(tǒng)一與綜合在加工的過程中必須消除源數(shù)據(jù)的不一致性,以保證數(shù)據(jù)倉庫內(nèi)的信息時關(guān)于整個企業(yè)的一致的全局信息。(關(guān)聯(lián)關(guān)系)
- 不可修改DW中的數(shù)據(jù)并不是最新的,而是來源于其他數(shù)據(jù)源數(shù)據(jù)倉庫主要是為決策分析提供數(shù)據(jù),涉及的操作主要是數(shù)據(jù)的查詢
- 與時間相關(guān)處于決策的需要數(shù)據(jù)倉庫中的數(shù)據(jù)都需要標明時間屬性
與數(shù)據(jù)庫的對比
- DW:專門為數(shù)據(jù)分析設(shè)計的,涉及讀取大量數(shù)據(jù)以了解數(shù)據(jù)之間的關(guān)系和趨勢
- 數(shù)據(jù)庫:用于捕獲和存儲數(shù)據(jù)
特性 | 數(shù)據(jù)倉庫 | 事務(wù)數(shù)據(jù)庫 |
適合的工作負載 | 分析、報告、大數(shù)據(jù) | 事務(wù)處理 |
數(shù)據(jù)源 | 從多個來源收集和標準化的數(shù)據(jù) | 從單個來源(例如事務(wù)系統(tǒng))捕獲的數(shù)據(jù) |
數(shù)據(jù)捕獲 | 批量寫入操作通過按照預(yù)定的批處理計劃執(zhí)行 | 針對連續(xù)寫入操作進行了優(yōu)化,因為新數(shù)據(jù)能夠最大程度地提高事務(wù)吞吐量 |
數(shù)據(jù)標準化 | 非標準化schema,例如星型Schema或雪花型schema | 高度標準化的靜態(tài)schema |
數(shù)據(jù)存儲 | 使用列式存儲進行了優(yōu)化,可實現(xiàn)輕松訪問和高速查詢性能 | 針對在單行型物理塊中執(zhí)行高吞吐量寫入操作進行了優(yōu)化 |
數(shù)據(jù)訪問 | 為最小化I/O并最大化數(shù)據(jù)吞吐量進行了優(yōu)化 | 大量小型讀取操作 |
為何要分層
數(shù)據(jù)倉庫中涉及到的問題:
- 為什么要做數(shù)據(jù)倉庫?
- 為什么要做數(shù)據(jù)質(zhì)量管理?
- 為什么要做元數(shù)據(jù)管理?
- 數(shù)倉分層中每個層的作用是什么?
- …...
在實際的工作中,我們都希望自己的數(shù)據(jù)能夠有順序地流轉(zhuǎn),設(shè)計者和使用者能夠清晰地知道數(shù)據(jù)的整個聲明周期,比如下面左圖。
但是,實際情況下,我們所面臨的數(shù)據(jù)狀況很有可能是復(fù)雜性高、且層級混亂的,我們可能會做出一套表依賴結(jié)構(gòu)混亂,且出現(xiàn)循環(huán)依賴的數(shù)據(jù)體系,比如下面的右圖。
為了解決我們可能面臨的問題,需要一套行之有效的數(shù)據(jù)組織、管理和處理方法,來讓我們的數(shù)據(jù)體系更加有序,這就是數(shù)據(jù)分層。數(shù)據(jù)分層的好處:
- 清晰數(shù)據(jù)結(jié)構(gòu):讓每個數(shù)據(jù)層都有自己的作用和職責(zé),在使用和維護的時候能夠更方便和理解
- 復(fù)雜問題簡化:將一個復(fù)雜的任務(wù)拆解成多個步驟來分步驟完成,每個層只解決特定的問題
- 統(tǒng)一數(shù)據(jù)口徑:通過數(shù)據(jù)分層,提供統(tǒng)一的數(shù)據(jù)出口,統(tǒng)一輸出口徑
- 減少重復(fù)開發(fā):規(guī)范數(shù)據(jù)分層,開發(fā)通用的中間層,可以極大地減少重復(fù)計算的工作
數(shù)據(jù)分層
每個公司的業(yè)務(wù)都可以根據(jù)自己的業(yè)務(wù)需求分層不同的層次;目前比較成熟的數(shù)據(jù)分層:數(shù)據(jù)運營層ODS、數(shù)據(jù)倉庫層DW、數(shù)據(jù)服務(wù)層ADS(APP)。
數(shù)據(jù)運營層ODS
數(shù)據(jù)運營層:Operation Data Store 數(shù)據(jù)準備區(qū),也稱為貼源層。數(shù)據(jù)源中的數(shù)據(jù),經(jīng)過抽取、洗凈、傳輸,也就是ETL過程之后進入本層。該層的主要功能:
- ODS是后面數(shù)據(jù)倉庫層的準備區(qū)
- 為DWD層提供原始數(shù)據(jù)
- 減少對業(yè)務(wù)系統(tǒng)的影響
在源數(shù)據(jù)裝入這一層時,要進行諸如去噪(例如有一條數(shù)據(jù)中人的年齡是 300 歲,這種屬于異常數(shù)據(jù),就需要提前做一些處理)、去重(例如在個人資料表中,同一 ID 卻有兩條重復(fù)數(shù)據(jù),在接入的時候需要做一步去重)、字段命名規(guī)范等一系列操作。
但是為了考慮后續(xù)可能需要追溯數(shù)據(jù)問題,因此對于這一層就不建議做過多的數(shù)據(jù)清洗工作,原封不動地接入原始數(shù)據(jù)也可以,根據(jù)業(yè)務(wù)具體分層的需求來做。
這層的數(shù)據(jù)是后續(xù)數(shù)據(jù)倉庫加工數(shù)據(jù)的來源。數(shù)據(jù)來源的方式:
- 業(yè)務(wù)日志經(jīng)常會使用sqoop來抽取,例如每天定時抽取一次。實時方面,可以考慮用canal監(jiān)聽mysql的binlog,實時接入即可。
- 埋點日志日志一般以文件的形式保存,可以選擇用flume定時同步可以用spark streaming或者Flink來實時接入kafka也OK
- 第三方爬蟲數(shù)據(jù)
數(shù)據(jù)倉庫層
數(shù)據(jù)倉庫層從上到下,又可以分為3個層:數(shù)據(jù)細節(jié)層DWD、數(shù)據(jù)中間層DWM、數(shù)據(jù)服務(wù)層DWS。
數(shù)據(jù)細節(jié)層DWD
數(shù)據(jù)細節(jié)層:data warehouse details,DWD(數(shù)據(jù)清洗/DWI)
該層是業(yè)務(wù)層和數(shù)據(jù)倉庫的隔離層,保持和ODS層一樣的數(shù)據(jù)顆粒度;主要是對ODS數(shù)據(jù)層做一些數(shù)據(jù)的清洗和規(guī)范化的操作,比如去除空數(shù)據(jù)、臟數(shù)據(jù)、離群值等。
為了提高數(shù)據(jù)明細層的易用性,該層通常會才采用一些維度退化方法,將維度退化至事實表中,減少事實表和維表的關(guān)聯(lián)。
數(shù)據(jù)中間層DWM(DIM 維度層)
數(shù)據(jù)中間層:Data Warehouse Middle,DWM
該層是在DWD層的數(shù)據(jù)基礎(chǔ)上,對數(shù)據(jù)做一些輕微的聚合操作,生成一些列的中間結(jié)果表,提升公共指標的復(fù)用性,減少重復(fù)加工的工作。
簡答來說,對通用的核心維度進行聚合操作,算出相應(yīng)的統(tǒng)計指標
數(shù)據(jù)服務(wù)層DWS(DWT)
數(shù)據(jù)服務(wù)層:Data Warehouse Service,DWS(寬表-用戶行為,輕度聚合)
DWT在DWS的基礎(chǔ)之上聚合的總信息,比如用戶的信息,DWS的單位是天,DWT就是多天的信息
該層是基于DWM上的基礎(chǔ)數(shù)據(jù),整合匯總成分析某一個主題域的數(shù)據(jù)服務(wù)層,一般是寬表,用于提供后續(xù)的業(yè)務(wù)查詢,OLAP分析,數(shù)據(jù)分發(fā)等。
一般來說,該層的數(shù)據(jù)表會相對較少;一張表會涵蓋比較多的業(yè)務(wù)內(nèi)容,由于其字段較多,因此一般也會稱該層的表為寬表。
- 用戶行為,輕度聚合對DWD
- 主要對ODS/DWD層數(shù)據(jù)做一些輕度的匯總。
數(shù)據(jù)應(yīng)用層ADS
數(shù)據(jù)應(yīng)用層:Application Data Service,ADS(APP/DAL/DF)-出報表結(jié)果
該層主要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù),一般會存放在ES、Redis、PostgreSql等系統(tǒng)中供線上系統(tǒng)使用;也可能存放在hive或者Druid中,供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用,比如常用的數(shù)據(jù)報表就是存在這里的。
實際應(yīng)用簡圖
事實表 Fact Table
事實表是指存儲有事實記錄的表,比如系統(tǒng)日志、銷售記錄等。事實表的記錄在不斷地增長,比如電商的商品訂單表,就是類似的情況,所以事實表的體積通常是遠大于其他表。
維表層Dimension(DIM)
維度表(Dimension Table)或維表,有時也稱查找表(Lookup Table),是與事實表相對應(yīng)的一種表;它保存了維度的屬性值,可以跟事實表做關(guān)聯(lián),相當于將事實表上經(jīng)常重復(fù)出現(xiàn)的屬性抽取、規(guī)范出來用一張表進行管理。維度表主要是包含兩個部分:
- 高基數(shù)維度數(shù)據(jù):一般是用戶資料表、商品資料表類似的資料表,數(shù)據(jù)量可能是千萬級或者上億級別
- 低基數(shù)維度數(shù)據(jù):一般是配置表,比如枚舉字段對應(yīng)的中文含義,或者日期維表等;數(shù)據(jù)量可能就是個位數(shù)或者幾千幾萬。
事實表和維度表
個人理解:事實表描述的是一件完整的事,維度表是從事實表中抽取出不同維度的屬性,這個維度也就是常說的何人、何地、何時做了這么一件事,這是一個事件發(fā)展所需要的屬性元素。
臨時表TMP
每一層的計算都會有很多臨時表,專設(shè)一個DWTMP層來存儲我們數(shù)據(jù)倉庫的臨時表
數(shù)據(jù)集市
數(shù)據(jù)集市(Data Mart),也叫數(shù)據(jù)市場,數(shù)據(jù)集市就是滿足特定的部門或者用戶的需求,按照多維的方式進行存儲,包括定義維度、需要計算的指標、維度的層次等,生成面向決策分析需求的數(shù)據(jù)立方體。而數(shù)據(jù)倉庫是企業(yè)級的,能為整個企業(yè)各個部門的運行提供決策手段。
帶有數(shù)據(jù)集市的數(shù)據(jù)倉儲結(jié)構(gòu)
區(qū)別數(shù)據(jù)倉庫
數(shù)據(jù)集市就是企業(yè)級數(shù)據(jù)倉庫的一個子集,它主要面向部門級業(yè)務(wù),并且只面向某個特定的主題。為了解決靈活性與性能之間的矛盾,數(shù)據(jù)集市就是數(shù)據(jù)倉庫體系結(jié)構(gòu)中增加的一種小型的部門或工作組級別的數(shù)據(jù)倉庫。數(shù)據(jù)集市存儲為特定用戶預(yù)先計算好的數(shù)據(jù),從而滿足用戶對性能的需求。數(shù)據(jù)集市可以在一定程度上緩解訪問數(shù)據(jù)倉庫的瓶頸。
理論上講,應(yīng)該有一個總的數(shù)據(jù)倉庫的概念,然后才有數(shù)據(jù)集市。實際建設(shè)數(shù)據(jù)集市的時候,國內(nèi)很少這么做。國內(nèi)一般會先從數(shù)據(jù)集市入手,就某一個特定的主題(比如企業(yè)的客戶信息)先做數(shù)據(jù)集市,再建設(shè)數(shù)據(jù)倉庫。數(shù)據(jù)倉庫和數(shù)據(jù)集市建立的先后次序之分,是和設(shè)計方法緊密相關(guān)的。而數(shù)據(jù)倉庫作為工程學(xué)科,并沒有對錯之分。
在數(shù)據(jù)結(jié)構(gòu)上,數(shù)據(jù)倉庫是面向主題的、集成的數(shù)據(jù)的集合。而數(shù)據(jù)集市通常被定義為星型結(jié)構(gòu)或者雪花型數(shù)據(jù)結(jié)構(gòu),數(shù)據(jù)集市一般是由一張事實表和幾張維表組成的。
問題總結(jié)
ODS與DWD區(qū)別?
問:還是不太明白 ods 和 dwd 層的區(qū)別,有了 ods 層后感覺 dwd 沒有什么用了。
答:嗯,我是這樣理解的,站在一個理想的角度來講,如果 ods 層的數(shù)據(jù)就非常規(guī)整,基本能滿足我們絕大部分的需求,這當然是好的,這時候 dwd 層其實也沒太大必要。 但是現(xiàn)實中接觸的情況是 ods 層的數(shù)據(jù)很難保證質(zhì)量,畢竟數(shù)據(jù)的來源多種多樣,推送方也會有自己的推送邏輯,在這種情況下,我們就需要通過額外的一層 dwd 來屏蔽一些底層的差異。
問:我大概明白了,是不是說 dwd 主要是對 ods 層做一些數(shù)據(jù)清洗和規(guī)范化的操作,dws 主要是對 ods 層數(shù)據(jù)做一些輕度的匯總?
對的,可以大致這樣理解。
APP層干什么的?
問:感覺DWS層是不是沒地方放了,各個業(yè)務(wù)的DWS表是應(yīng)該在 DWD還是在 app?
答:這個問題不太好回答,我感覺主要就是明確一下DWS層是干什么的,如果你的DWS層放的就是一些可以供業(yè)務(wù)方使用的寬表表,放在 app 層就行。如果你說的數(shù)據(jù)集市是一個比較泛一點的概念,那么其實 dws、dwd、app 這些合起來都算是數(shù)據(jù)集市的內(nèi)容。
問:那存到 Redis、ES 中的數(shù)據(jù)算是 app層嗎?
答:算是的,我個人的理解,app 層主要存放一些相對成熟的表,能供業(yè)務(wù)側(cè)使用的。這些表可以在 Hive 中,也可以是從 Hive 導(dǎo)入 Redis 或者 ES 這種查詢性能比較好的系統(tǒng)中。
附錄
ETL
ETL :Extract-Transform-Load,用于描述將數(shù)據(jù)從來源端經(jīng)過抽取、轉(zhuǎn)換、加載到目的端的過程。
寬表
- 含義:指字段比較多的數(shù)據(jù)庫表。通常是指業(yè)務(wù)主體相關(guān)的指標、緯度、屬性關(guān)聯(lián)在一起的一張數(shù)據(jù)庫表。
- 特點:寬表由于把不同的內(nèi)容都放在同一張表,寬表已經(jīng)不符合三范式的模型設(shè)計規(guī)范:壞處:數(shù)據(jù)有大量冗余好處:查詢性能的提高和便捷寬表的設(shè)計廣泛應(yīng)用于數(shù)據(jù)挖掘模型訓(xùn)練前的數(shù)據(jù)準備,通過把相關(guān)字段放在同一張表中,可以大大提供數(shù)據(jù)挖掘模型訓(xùn)練過程中迭代計算的消息問題。
主題(Subject)
是在較高層次上將企業(yè)信息系統(tǒng)中的數(shù)據(jù)進行綜合、歸類和分析利用的一個抽象概念,每一個主題基本對應(yīng)一個宏觀的分析領(lǐng)域。在邏輯意義上,它是對應(yīng)企業(yè)中某一宏觀分析領(lǐng)域所涉及的分析對象。例如“銷售分析”就是一個分析領(lǐng)域,因此這個數(shù)據(jù)倉庫應(yīng)用的主題就是“銷售分析”。
參考:
百度百科
1.《關(guān)于dwd022我想說數(shù)據(jù)倉庫和數(shù)據(jù)集市詳解:ODS、DW、DWD、DWM、DWS、ADS》援引自互聯(lián)網(wǎng),旨在傳遞更多網(wǎng)絡(luò)信息知識,僅代表作者本人觀點,與本網(wǎng)站無關(guān),侵刪請聯(lián)系頁腳下方聯(lián)系方式。
2.《關(guān)于dwd022我想說數(shù)據(jù)倉庫和數(shù)據(jù)集市詳解:ODS、DW、DWD、DWM、DWS、ADS》僅供讀者參考,本網(wǎng)站未對該內(nèi)容進行證實,對其原創(chuàng)性、真實性、完整性、及時性不作任何保證。
3.文章轉(zhuǎn)載時請保留本站內(nèi)容來源地址,http://f99ss.com/gl/2536669.html