一、文章主題
本文對資料分層的討論適合下面一些場景，超過該範圍場景 or 資料倉儲經驗豐富的大神就不必浪費時間看了。
二、文章結構
最初在做資料倉儲的時候遇到了很多坑，由於自身資源有限，接觸資料倉儲的時候，感覺在網際網路行業裡面的資料倉儲成功經驗很少，網上很難找到實踐性比較強的資料。而那幾本經典書籍裡面又過於理論，折騰起來真是生不如死。還好現在過去了那個坎，因此多花一些時間整理自己的思路，幫助其他的小夥伴少踩一些坑。文章的結構如下：
0x01 為什麼要分層
我們對資料進行分層的乙個主要原因就是希望在管理資料的時候，能對資料有乙個更加清晰的掌控，詳細來講，主要有下面幾個原因：
資料體系中的各個表的依賴就像是電線的流向一樣，我們都希望它是規整、流向清晰、便於管理的，如下圖：
但是，最終的結果大多卻是依賴複雜、層級混亂，想梳理清楚一張表的聲稱途徑會比較困難，如下圖：
0x02 怎樣分層
一、理論
我們從理論上來做乙個抽象，可以把資料倉儲分為下面三個層，即：資料運營層、資料倉儲層和資料產品層。
在這裡，主要是提供給資料產品和資料分析使用的資料，一般會存放在 es、mysql 等系統中供線上系統使用，也可能會存在 hive 或者 druid 中供資料分析和資料探勘使用。
如我們經常說的報表資料，或者說那種大寬表，一般就放在這裡。
二、技術實踐
這三層技術劃分，相對來說比較粗粒度，後面我們會專門細分一下。在此之前，先聊一下每一層的資料一般都是怎麼流向的。這裡僅僅簡單介紹幾個常用的工具，側重中開源界主流。
1. 資料**層→ ods層
業務庫，這裡經常會使用 sqoop 來抽取，比如我們每天定時抽取一次。在實時方面，可以考慮用 canal 監聽 mysql 的 binlog，實時接入即可。
埋點日誌，線上系統會打入各種日誌，這些日誌一般以檔案的形式儲存，我們可以選擇用 flume 定時抽取，也可以用用 spark streaming 或者 storm 來實時接入，當然，kafka 也會是乙個關鍵的角色。
其它資料來源會比較多樣性，這和具體的業務相關，不再贅述。
注意： 在這層，理應不是簡單的資料接入，而是要考慮一定的資料清洗，比如異常欄位的處理、字段命名規範化、時間欄位的統一等，一般這些很容易會被忽略，但是卻至關重要。特別是後期我們做各種特徵自動生成的時候，會十分有用。後續會有文章來分享。
這裡面也主要分兩種型別：
每日定時任務型：比如我們典型的日計算任務，每天凌晨算前一天的資料，早上起來看報表。 這種任務經常使用 hive、spark 或者生擼 mr 程式來計算，最終結果寫入 hive、hbase、mysql、es 或者 redis 中。
實時資料：這部分主要是各種實時的系統使用，比如我們的實時推薦、實時使用者畫像，一般我們會用 spark streaming、storm 或者 flink 來計算，最後會落入 es、hbase 或者 redis 中。
0x03 舉個例子
網上的例子很多，就不列了，只舉個筆者早期參與設計的資料分層例子。分析一下當初的想法，以及這種設計的缺陷。上原圖和內容。
當初的設計總共分了 6 層，其中去掉元資料後，還有5層。下面分析一下當初的乙個設計思路。
緩衝層(buffer)
明細層(ods, operational data store,dwd: data warehouse detail)
canal日誌合成資料的方式待研究。
輕度彙總層(mid或dwb, data warehouse basis)
主題層(dm，data market或dws, data warehouse service)
0x04 如何更優雅一些
前面提到的一種設計其實相對來講已經很詳細了，但是可能層次會有一點多，而且在區分一張表到底該存放在什麼位置的時候可能還有不小的疑惑。我們在這一章裡再設計一套資料倉儲的分層，同時在前面的基礎上加上維表和一些臨時表的考慮，來讓我們的方案更優雅一些。
下圖，做了一些小的改動，我們去掉了上一節的buffer層，把資料集市層和輕度彙總層放在同乙個層級上，同時獨立出來了維表和臨時表。
這裡解釋一下dws、dwd、dim和tmp的作用。
0x05 問答
有朋友問了一些問題，有一些之前的確沒講清楚，補到這裡。
問答一： dws 和 dwd 的關係
問：dws 和dwd 是並行而不是先後順序?
答：並行的，dw 層
問：那其實對於同乙個資料，這兩個過程是序列的?
答：dws 會做彙總，dwd 和 ods 的粒度相同，這兩層之間也沒有依賴的關係
問：對呀，那這樣 dws 裡面的彙總沒有經過資料質量和完整度的處理，或者單獨做了這種質量相關的處理，為什麼不在 dwd 之上再做彙總呢?我的疑問其實就是，dws的輕度彙總資料結果，有沒有做資料質量的處理?
問答二： ods 和 dwd 的區別
問：還是不太明白 ods 和 dwd 層的區別，有了 ods 層後感覺 dwd 沒有什麼用了。
答：嗯，我是這樣理解的，站在乙個理想的角度來講，如果 ods 層的資料就非常規整，基本能滿足我們絕大部分的需求，這當然是好的，這時候 dwd 層其實也沒太大必要。 但是現實中接觸的情況是 ods 層的資料很難保證質量，畢竟資料的**多種多樣，推送方也會有自己的推送邏輯，在這種情況下，我們就需要通過額外的一層 dwd 來遮蔽一些底層的差異。
問：我大概明白了，是不是說 dwd 主要是對 ods 層做一些資料清洗和規範化的操作，dws 主要是對 ods 層資料做一些輕度的彙總?
答：對的，可以大致這樣理解。
0xff 總結
資料分層是資料倉儲非常重要的乙個環節，它決定的不僅僅是乙個層次的問題，還直接影響到血緣分析、特徵自動生成、元資料管理等一系列功能的建設。因此適於盡早考慮。
另外，每一層的名字不必太過在意，自己按照喜好就好。
資料倉儲和資料倉儲分層
資料倉儲 data warehouse 可簡寫為dw或dwh。資料倉儲，是為企業所有級別的決策制定過程，提供所有型別資料支援的戰略集合。它是單個資料儲存，出於分析性報告和決策支援目的而建立。為需要業務智慧型的企業，提供指導業務流程改進 監視時間 成本 質量以及控制。1 問題簡單化，將乙個複雜的問題分...
資料倉儲分層
下面的內容是基於參考中的文件進行的二次讀書筆記。傳統行業的資料倉儲工程師,開始嘗試架構工程領域比較流行的er模型 維度模型方式，構建出乙個四層的模型架構 阿里在構建er時碰到了較大的挑戰，主要是業務快速發展，人員快速變化 業務知識功底的不夠全面，導致er模型產出困難。阿里得出了乙個結論 在不太成熟 ...
資料倉儲分層
資料倉儲更多代表的是一種對資料的管理和使用的方式，它是一整套包括了etl 排程 建模在內的完整的理論體系。現在所謂的大資料更多的是一種資料量級的增大和工具的上的更新。兩者並無衝突，相反，而是一種更好的結合。資料倉儲在構建過程中通常都需要進行分層處理。業務不同，分層的技術處理手段也不同。分層的主要原因...