一、前言
現在說數倉，更多的會和數據平臺或者基礎架構搭上，已經融合到整個基礎設施的搭建上。這裏呢，我們不說Hadoop各種組件之間的配合，我們就簡單說下數倉分層的意義價值和該如何設計分層，後面對於數倉的理解，其實都是工作中一點一點實踐和摸索得來的。
二、數倉建模
說到數倉建模，就得提下經典的2套理論：
-
範式建模
Inmon提出的集線器的自上而下（EDW-DM）的數據倉庫架構。 -
維度建模
Kimball提出的總線式的自下而上（DM-DW）的數據倉庫架構。
數倉的建模或者分層，其實都是爲了更好的去組織、管理、維護數據，實際開發時會整合2種方式去使用，當然，還有些其他的，像Data Vault模型、Anchor模型，暫時還沒有應用過，就不說了。
維度建模，一般都會提到星型模型、雪花模型，星型模型做OLAP分析很方便。
三、數倉分層
簡單點兒，直接ODS+DM就可以了，將所有數據同步過來，然後直接開發些應用層的報表，這是最簡單的了；當DM層的內容多了以後，想要重用，就會再拆分一個公共層出來，變成3層架構，最近看了本阿里的書，《大數據之路》，裏面有很多數倉相關的內容，很不錯，參考後，目前使用的分層模式如下：
按照這種分層方式，我們的開發重心就在dwd層，就是明細數據層，這裏主要是一些寬表，存儲的還是明細數據；到了dws層，我們就會針對不同的維度，對數據進行聚合了，按道理說，dws層算是集市層，這裏一般按照主題進行劃分，屬於維度建模的範疇；ads就是偏應用層，各種報表的輸出了。
四、數倉的基本特徵
數據倉庫有4個基本特徵：面向主題的、集成的、相對穩定的、記錄歷史的，而數據倉庫的價值正是基於這4個特徵體現的。
1、高效的數據組織和管理
面向主題的特性決定了數據倉庫擁有業務數據庫所無法擁有的高效的數據組織形式，更加完整的數據體系，清晰的數據分類和分層機制。因爲所有數據在進入數據倉庫之前都經過清洗和過濾，使原始數據不再雜亂無章，基於優化查詢的組織形式，有效提高數據獲取、統計和分析的效率。
2、時間價值
數據倉庫的構建將大大縮短獲取信息的時間，數據倉庫作爲數據的集合，所有的信息都可以從數據倉庫直接獲取，數據倉庫的最大優勢在於一旦底層從各類數據源到數據倉庫的ETL流程構建成型，那麼每天就會有來自各方面的信息通過自動任務調度的形式流入數據倉庫，從而使一切基於這些底層信息的數據獲取的效率達到迅速提升。
從應用來看，使用數據倉庫可以大大提高數據的查詢效率，尤其對於海量數據的關聯查詢和複雜查詢，所以數據倉庫有利於實現複雜的統計需求，提高數據統計的效率。
3、集成價值
數據倉庫是所有數據的集合，包括日誌信息、數據庫數據、文本數據、外部數據等都集成在數據倉庫中，對於應用來說，實現各種不同數據的關聯並使多維分析更加方便，爲從多角度多層次地數據分析和決策制定提供的可能。
4、歷史累積價值
記歷史是數據倉庫的特性之一，數據倉庫能夠還原歷史時間點上的產品狀態、用戶狀態、用戶行爲等，以便於能更好的回溯歷史，分析歷史，跟蹤用戶的歷史行爲，更好地比較歷史和總結歷史，同時根據歷史預測未來。
五、數據倉庫用途
- 整合公司所有業務數據，建立統一的數據中心
- 產生業務報表，用於作出決策
- 爲網站運營提供運營上的數據支持
- 可以作爲各個業務的數據源，形成業務數據互相反饋的良性循環
- 分析用戶行爲數據，通過數據挖掘來降低投入成本，提高投入效果
- 開發數據產品，直接或間接地爲公司盈利
六、數倉分層的好處
對數據進行分層的一個主要原因就是希望在管理數據的時候，能對數據有一個更加清晰的掌控，詳細來講，主要有下面幾個原因。
- 清晰數據結構：每一個數據分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。
- 數據血緣追蹤：簡單來講可以這樣理解，我們最終給業務呈現的是一張能直接使用的張業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，並清楚它的危害範圍。
- 減少重複開發：規範數據分層，開發一些通用的中間層數據，能夠減少極大的重複計算。
- 把複雜問題簡單化：將一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護數據的準確性，當數據出現問題之後，可以不用修復所有的數據，只需要從有問題的步驟開始修復。
- 屏蔽原始數據的異常：屏蔽業務的影響，不必改一次業務就需要重新接入數據。
數據體系中的各個表的依賴就像是電線的流向一樣，我們都希望它是規整、流向清晰、便於管理的，如下圖。
但是，最終的結果大多卻是依賴複雜、層級混亂，想梳理清楚一張表的生成途徑會比較困難，如下圖：
七、如何分層
理論抽象
我們可以從理論上對數倉來做一個抽象，可以把數據倉庫分爲下面三個層，即：數據運營層、數據倉庫層和數據產品層。
-
ODS 全稱是 Operational Data Store，操作數據存儲。“面向主題的”，數據運營層，也叫ODS層，是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗淨、傳輸，也就說傳說中的 ETL 之後，裝入本層。本層的數據，總體上大多是按照源頭業務系統的分類方式而分類的。但是，這一層面的數據卻不等同於原始數據。在源數據裝入這一層時，要進行諸如去噪(例如有一條數據中人的年齡是 300 歲，這種屬於異常數據，就需要提前做一些處理)、去重(例如在個人資料表中，同一 ID 卻有兩條重複數據，在接入的時候需要做一步去重)、字段命名規範等一系列操作。
-
數據倉庫層(DW)，是數據倉庫的主體. 在這裏，從 ODS 層中獲得的數據按照主題建立各種數據模型。這一層和維度建模會有比較深的聯繫。
-
數據產品層(APP)，這一層是提供爲數據產品使用的結果數據，在這裏，主要是提供給數據產品和數據分析使用的數據，一般會存放在 ES、MySQL等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供數據分析和數據挖掘使用。如我們經常說的報表數據，或者說那種大寬表，一般就放在這裏。
另外，我們在實際分層過程中，也可以根據我們的實際數據處理的流程進行分層。
八、舉個例子
網上的例子很多，以下是某位大牛早期參與設計的數據分層例子。我們分析一下當初的想法，以及這種設計的缺陷。上原圖和內容。
大佬當初的設計總共分了 6 層，其中去掉元數據後，還有5層。下面分析一下當初的一個設計思路。
緩衝層(buffer)
概念：又稱爲接口層(stage)，用於存儲每天的增量數據和變更數據，如Canal接收的業務變更日誌。
數據生成方式：直接從kafka接收源數據，需要業務表每天生成update,delete,inseret數據，只生成insert數據的業務表，數據直接入明細層
討論方案：只把canal日誌直接入緩衝層，如果其它有拉鍊數據的業務，也入緩衝層。
日誌存儲方式：使用impala外表，parquet文件格式，方便需要MR處理的數據讀取。
日誌刪除方式：長久存儲，可只存儲最近幾天的數據。討論方案：直接長久存儲
表schema：一般按天創建分區庫與表命名。庫名：buffer,表名：初步考慮格式爲：buffer日期業務表名,待定。
明細層(ODS, Operational Data Store,DWD: data warehouse detail)
概念：是數據倉庫的細節數據層，是對STAGE層數據進行沉澱，減少了抽取的複雜性，同時ODS/DWD的信息模型組織主要遵循企業業務事務處理的形式，將各個專業數據進行集中，明細層跟stage層的粒度一致，屬於分析的公共資源
數據生成方式：部分數據直接來自kafka，部分數據爲接口層數據與歷史數據合成。
canal日誌合成數據的方式待研究。
討論方案：canal數據的合成方式爲：每天把明細層的前天全量數據和昨天新數據合成一個新的數據表，覆蓋舊錶。同時使用歷史鏡像，按周/按月/按年 存儲一個歷史鏡像到新表。
日誌存儲方式：直接數據使用impala外表，parquet文件格式，canal合成數據爲二次生成數據，建議使用內表，下面幾層都是從impala生成的數據，建議都用內表+靜態/動態分區。
日誌刪除方式：長久存儲。
表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。
庫與表命名：庫名：ods,表名：初步考慮格式爲ods日期業務表名,待定。
舊數據更新方式：直接覆蓋
輕度彙總層(MID或DWB, data warehouse basis)
概念：輕度彙總層數據倉庫中DWD層和DM層之間的一個過渡層次，是對DWD層的生產數據進行輕度綜合和彙總統計(可以把複雜的清洗，處理包含，如根據PV日誌生成的會話數據)。輕度綜合層與DWD的主要區別在於二者的應用領域不同，DWD的數據來源於生產型系統，並未滿意一些不可預見的需求而進行沉澱;輕度綜合層則面向分析型應用進行細粒度的統計和沉澱
數據生成方式：由明細層按照一定的業務需求生成輕度彙總表。明細層需要複雜清洗的數據和需要MR處理的數據也經過處理後接入到輕度彙總層。
日誌存儲方式：內表，parquet文件格式。
日誌刪除方式：長久存儲。
表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。
庫與表命名：庫名：dwb,表名：初步考慮格式爲：dwb日期業務表名,待定。
舊數據更新方式：直接覆蓋
主題層(DM，data market或DWS, data warehouse service)
概念：又稱數據集市或寬表。按照業務劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用於提供後續的業務查詢，OLAP分析，數據分發等。
數據生成方式：由輕度彙總層和明細層數據計算生成。
日誌存儲方式：使用impala內表，parquet文件格式。
日誌刪除方式：長久存儲。
表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。
庫與表命名：庫名：dm,表名：初步考慮格式爲：dm日期業務表名,待定。
舊數據更新方式：直接覆蓋
應用層(App)
概念：應用層是根據業務需要，由前面三層數據統計而出的結果，可以直接提供查詢展現，或導入至Mysql中使用。
數據生成方式：由明細層、輕度彙總層，數據集市層生成，一般要求數據主要來源於集市層。
日誌存儲方式：使用impala內表，parquet文件格式。
日誌刪除方式：長久存儲。
表schema：一般按天創建分區，沒有時間概念的按具體業務選擇分區字段。
庫與表命名：庫名：暫定apl，另外根據業務不同，不限定一定要一個庫。
舊數據更新方式：直接覆蓋。
九、如何更優雅一些
前面提到的一種設計其實相對來講已經很詳細了，但是可能層次會有一點多，而且在區分一張表到底該存放在什麼位置的時候可能還有不小的疑惑。我們可以再設計一套數據倉庫的分層，同時在前面的基礎上加上維表和一些臨時表的考慮，來讓我們的方案更優雅一些。
下圖，做了一些小的改動，我們去掉了上一節的Buffer層，把數據集市層和輕度彙總層放在同一個層級上，同時獨立出來了維表和臨時表。
這裏解釋一下DWS、DWD、DIM和TMP的作用。
DWS：輕度彙總層，從ODS層中對用戶的行爲做一個初步的彙總，抽象出來一些通用的維度：時間、ip、id，並根據這些維度做一些統計值，比如用戶每個時間段在不同登錄ip購買的商品數等。這裏做一層輕度的彙總會讓計算更加的高效，在此基礎上如果計算僅7天、30天、90天的行爲的話會快很多。我們希望80%的業務都能通過我們的DWS層計算，而不是ODS。
DWD：這一層主要解決一些數據質量問題和數據的完整度問題。比如用戶的資料信息來自於很多不同表，而且經常出現延遲丟數據等問題，爲了方便各個使用方更好的使用數據，我們可以在這一層做一個屏蔽。
DIM：這一層比較單純，舉個例子就明白，比如國家代碼和國家名、地理位置、中文名、國旗圖片等信息就存在DIM層中。
TMP：每一層的計算都會有很多臨時表，專設一個DWTMP層來存儲我們數據倉庫的臨時表。
Refer
http://bigdata.51cto.com/art/201710/554810.htm
https://blog.csdn.net/hadoopdevelop/article/details/79282844