前言：

　　不是做數倉的，但是也需要了解數倉的知識。

　　其實分層好多因人而異，問了同事好多分層的區別也不是很清晰。

　　所以后續有機會還是跟數倉的同事碰一下吧~

　　一. 各種名詞解釋

　　1.1 ODS是什么?

　　ODS層最好理解，基本上就是數據從源表拉過來，進行etl，比如mysql 映射到hive，那么到了hive里面就是ods層。

　　ODS 全稱是 Operational Data Store，操作數據存儲.“面向主題的”，數據運營層，也叫ODS層，是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗凈、傳輸，也就說傳說中的 ETL 之后，裝入本層。本層的數據，總體上大多是按照源頭業務系統的分類方式而分類的。但是，這一層面的數據卻不等同于原始數據。在源數據裝入這一層時，要進行諸如去噪(例如有一條數據中人的年齡是 300 歲，這種屬于異常數據，就需要提前做一些處理)、去重(例如在個人資料表中，同一 ID 卻有兩條重復數據，在接入的時候需要做一步去重)、字段命名規范等一系列操作。

　　1.2 數據倉庫層DW?

　　數據倉庫層(DW)，是數據倉庫的主體.在這里，從 ODS 層中獲得的數據按照主題建立各種數據模型。這一層和維度建模會有比較深的聯系。

　　細分：

　　數據明細層：DWD(Data Warehouse Detail)

　　數據中間層：DWM(Data WareHouse Middle)

　　數據服務層：DWS(Data WareHouse Servce)

　　1.2.1 DWD明細層?

　　明細層(ODS, Operational Data Store,DWD: data warehouse detail)

　　概念：是數據倉庫的細節數據層，是對STAGE層數據進行沉淀，減少了抽取的復雜性，同時ODS/DWD的信息模型組織主要遵循企業業務事務處理的形式，將各個專業數據進行集中，明細層跟stage層的粒度一致，屬于分析的公共資源

　　數據生成方式：部分數據直接來自kafka，部分數據為接口層數據與歷史數據合成。

　　這個stage層不是很清晰

　　1.2.2 DWM 輕度匯總層(MID或DWB, data warehouse basis)

　　概念：輕度匯總層數據倉庫中DWD層和DM層之間的一個過渡層次，是對DWD層的生產數據進行輕度綜合和匯總統計(可以把復雜的清洗，處理包含，如根據PV日志生成的會話數據)。輕度綜合層與DWD的主要區別在于二者的應用領域不同，DWD的數據來源于生產型系統，并未滿意一些不可預見的需求而進行沉淀;輕度綜合層則面向分析型應用進行細粒度的統計和沉淀

　　數據生成方式：由明細層按照一定的業務需求生成輕度匯總表。明細層需要復雜清洗的數據和需要MR處理的數據也經過處理后接入到輕度匯總層。

　　日志存儲方式：內表，parquet文件格式。

　　日志刪除方式：長久存儲。

　　表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。

　　庫與表命名。庫名：dwb,表名：初步考慮格式為：dwb日期業務表名,待定。

　　舊數據更新方式：直接覆蓋

　　1.2.3 DWS 主題層(DM，data market或DWS, data warehouse service)

　　概念：又稱數據集市或寬表。按照業務劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用于提供后續的業務查詢，OLAP分析，數據分發等。

　　數據生成方式：由輕度匯總層和明細層數據計算生成。

　　日志存儲方式：使用impala內表，parquet文件格式。

　　日志刪除方式：長久存儲。

　　表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。

　　庫與表命名。庫名：dm,表名：初步考慮格式為：dm日期業務表名,待定。

　　舊數據更新方式：直接覆蓋

　　1.3 APP?

　　數據產品層(APP)，這一層是提供為數據產品使用的結果數據。

　　主要是提供給數據產品和數據分析使用的數據，一般會存放在 ES、Mysql 等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供數據分析和數據挖掘使用。

　　如我們經常說的報表數據，或者說那種大寬表，一般就放在這里。

　　應用層(App)

　　概念：應用層是根據業務需要，由前面三層數據統計而出的結果，可以直接提供查詢展現，或導入至Mysql中使用。

　　數據生成方式：由明細層、輕度匯總層，數據集市層生成，一般要求數據主要來源于集市層。

　　日志存儲方式：使用impala內表，parquet文件格式。

　　日志刪除方式：長久存儲。

　　表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。

　　庫與表命名。庫名：暫定apl，另外根據業務不同，不限定一定要一個庫。(其實就叫app_)就好了

　　舊數據更新方式：直接覆蓋。

　　1.4 數據的來源

　　數據主要會有兩個大的來源：

　　業務庫，這里經常會使用 Sqoop 來抽取

　　我們業務庫用的是databus來進行接收，處理kafka就好了。

　　在實時方面，可以考慮用 Canal 監聽 Mysql 的 Binlog，實時接入即可。(有機會補一下這個canal)

　　埋點日志，線上系統會打入各種日志，這些日志一般以文件的形式保存，我們可以選擇用 Flume 定時抽取，也可以用用 Spark Streaming 或者 Storm 來實時接入，當然，Kafka 也會是一個關鍵的角色。

　　還有使用filebeat收集日志，打到kafka，然后處理日志

　　注意： 在這層，理應不是簡單的數據接入，而是要考慮一定的數據清洗，比如異常字段的處理、字段命名規范化、時間字段的統一等，一般這些很容易會被忽略，但是卻至關重要。特別是后期我們做各種特征自動生成的時候，會十分有用。

　　1.5 ODS、DW → App層

　　這里面也主要分兩種類型：

　　每日定時任務型：比如我們典型的日計算任務，每天凌晨算前一天的數據，早上起來看報表。 這種任務經常使用 Hive、Spark 或者生擼 MR 程序來計算，最終結果寫入 Hive、Hbase、Mysql、Es 或者 Redis 中。

　　實時數據：這部分主要是各種實時的系統使用，比如我們的實時推薦、實時用戶畫像，一般我們會用 Spark Streaming、Storm 或者 Flink 來計算，最后會落入 Es、Hbase 或者 Redis 中。

　　1.6 維表層DIM?

　　維表層(Dimension)

　　最后補充一個維表層，維表層主要包含兩部分數據：

　　高基數維度數據：一般是用戶資料表、商品資料表類似的資料表。數據量可能是千萬級或者上億級別。

　　低基數維度數據：一般是配置表，比如枚舉值對應的中文含義，或者日期維表。數據量可能是個位數或者幾千幾萬。

　　1.7 層級的簡單分層圖

　　見下圖，對DWD層在進行加工的話，就是DWM層(MID層)(我們的數倉還是有很多dwm層的)

　　這里解釋一下DWS、DWD、DIM和TMP的作用。

　　DWS：輕度匯總層，從ODS層中對用戶的行為做一個初步的匯總，抽象出來一些通用的維度：時間、ip、id，并根據這些維度做一些統計值，比如用戶每個時間段在不同登錄ip購買的商品數等。這里做一層輕度的匯總會讓計算更加的高效，在此基礎上如果計算僅7天、30天、90天的行為的話會快很多。我們希望80%的業務都能通過我們的DWS層計算，而不是ODS。

　　DWD：這一層主要解決一些數據質量問題和數據的完整度問題。比如用戶的資料信息來自于很多不同表，而且經常出現延遲丟數據等問題，為了方便各個使用方更好的使用數據，我們可以在這一層做一個屏蔽。(匯總多個表)

　　DIM：這一層比較單純，舉個例子就明白，比如國家代碼和國家名、地理位置、中文名、國旗圖片等信息就存在DIM層中。

　　TMP：每一層的計算都會有很多臨時表，專設一個DWTMP層來存儲我們數據倉庫的臨時表。

　　二. 問題

　　2.1 DWS 與 DWD?

　　問答一： dws 和 dwd 的關系

　　問：dws 和dwd 是并行而不是先后順序?

　　答：并行的，dw 層

　　問：那其實對于同一個數據，這兩個過程是串行的?

　　答：dws 會做匯總，dwd 和 ods 的粒度相同，這兩層之間也沒有依賴的關系

　　問：對呀，那這樣 dws 里面的匯總沒有經過數據質量和完整度的處理，或者單獨做了這種質量相關的處理，為什么不在 dwd 之上再做匯總呢?我的疑問其實就是，dws的輕度匯總數據結果，有沒有做數據質量的處理?

　　答：ods 直接到 dws 就好，沒必要過 dwd，我舉個例子，你的瀏覽商品行為，我做一層輕度匯總，就直接放在 dws 了。但是你的資料表，要從好多表湊成一份，我們從四五份個人資料表中湊出來了一份完整的資料表放在了 dwd 中。然后在 app 層，我們要出一張畫像表，包含用戶資料和用戶近一年的行為，我們就直接從dwd中拿資料， 然后再在 dws 的基礎上做一層統計，就成一個app表了。當然，這不是絕對，dws 和 dwd 有沒有依賴關系主要看有沒有這種需求。

　　2.2 ODS與DWD區別?

　　問：還是不太明白 ods 和 dwd 層的區別，有了 ods 層后感覺 dwd 沒有什么用了。

　　答：嗯，我是這樣理解的，站在一個理想的角度來講，如果 ods 層的數據就非常規整，基本能滿足我們絕大部分的需求，這當然是好的，這時候 dwd 層其實也沒太大必要。 但是現實中接觸的情況是 ods 層的數據很難保證質量，畢竟數據的來源多種多樣，推送方也會有自己的推送邏輯，在這種情況下，我們就需要通過額外的一層 dwd 來屏蔽一些底層的差異。

　　問：我大概明白了，是不是說 dwd 主要是對 ods 層做一些數據清洗和規范化的操作，dws 主要是對 ods 層數據做一些輕度的匯總?

　　答：對的，可以大致這樣理解。

　　2.3 app層干什么的?

　　問答三：app 層是干什么的?

　　問：感覺數據集市層是不是沒地方放了，各個業務的數據集市表是應該在 dwd 還是在 app?

　　答：這個問題不太好回答，我感覺主要就是明確一下數據集市層是干什么的，如果你的數據集市層放的就是一些可以供業務方使用的寬表表，放在 app 層就行。如果你說的數據集市層是一個比較泛一點的概念，那么其實 dws、dwd、app 這些合起來都算是數據集市的內容。

　　問：那存到 Redis、ES 中的數據算是 app層嗎?

　　答：算是的，我個人的理解，app 層主要存放一些相對成熟的表，能供業務側使用的。這些表可以在 Hive 中，也可以是從 Hive 導入 Redis 或者 ES 這種查詢性能比較好的系統中。

　　三. 總結

　　另一個博主的圖蠻好：

　　主題(Subject)是在較高層次上將企業信息系統中的數據進行綜合、歸類和分析利用的一個抽象概念，每一個主題基本對應一個宏觀的分析領域。在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析對象。例如“銷售分析”就是一個分析領域，因此這個數據倉庫應用的主題就是“銷售分析”。