這應該是資料倉儲同學在設計資料分層時首先要被挑戰的問題，類似的問題可能會有很多，比如說「為什麼要做資料倉儲？」、「為什麼要做元資料管理？」、「為什麼要做資料質量管理？」。當然，這裡我們只聊一下為什麼要做設計資料分層。
作為一名資料的規劃者，我們肯定希望自己的資料能夠有秩序地流轉，資料的整個生命週期能夠清晰明確被設計者和使用者感知到。直觀來講就是如下的左圖這般層次清晰、依賴關係直觀。
但是，大多數情況下，我們完成的資料體系卻是依賴複雜、層級混亂的。如下的右圖，在不知不覺的情況下，我們可能會做出一套表依賴結構混亂，甚至出現迴圈依賴的資料體系。
因此，我們需要一套行之有效的資料組織和管理方法來讓我們的資料體系更有序，這就是談到的資料分層。資料分層並不能解決所有的資料問題，但是，資料分層卻可以給我們帶來如下的好處：
「面向主題的」資料運營層，也叫ods層，是最接近資料來源中資料的一層，資料來源中的資料，經過抽取、洗淨、傳輸，也就說傳說中的 etl 之後，裝入本層。本層的資料，總體上大多是按照源頭業務系統的分類方式而分類的。
一般來講，為了考慮後續可能需要追溯資料問題，因此對於這一層就不建議做過多的資料清洗工作，原封不動地接入原始資料即可，至於資料的去噪、去重、異常值處理等過程可以放在後面的dwd層來做。
資料倉儲層是我們在做資料倉儲時要核心設計的一層，在這裡，從 ods 層中獲得的資料按照主題建立各種資料模型。dw層又細分為 dwd（data warehouse detail）層、dwm（data warehouse middle）層和dws（data warehouse servce）層。
1. 資料明細層：dwd（data warehouse detail）
該層一般保持和ods層一樣的資料粒度，並且提供一定的資料質量保證。同時，為了提高資料明細層的易用性，該層會採用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯。
另外，在該層也會做一部分的資料聚合，將相同主題的資料匯集到一張表中，提高資料的可用性，後文會舉例說明。
2. 資料中間層：dwm（data warehouse middle）
該層會在dwd層的資料基礎上，對資料做輕度的聚合操作，生成一系列的中間表，提公升公共指標的復用性，減少重複加工。
直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標。
3. 資料服務層：dws（data warehouse servce）
又稱資料集市或寬表。按照業務劃分，如流量、訂單、使用者等，生成字段比較多的寬表，用於提供後續的業務查詢，olap分析，資料分發等。
一般來講，該層的資料表會相對比較少，一張表會涵蓋比較多的業務內容，由於其字段較多，因此一般也會稱該層的表為寬表。
在實際計算中，如果直接從dwd或者ods計算出寬表的統計指標，會存在計算量太大並且維度太少的問題，因此一般的做法是，在dwm層先計算出多個小的中間表，然後再拼接成一張dws的寬表。由於寬和窄的界限不易界定，也可以去掉dwm這一層，只留dws層，將所有的資料在放在dws亦可。
在這裡，主要是提供給資料產品和資料分析使用的資料，一般會存放在 es、postgresql、redis等系統中供線上系統使用，也可能會存在 hive 或者 druid 中供資料分析和資料探勘使用。比如我們經常說的報表資料，一般就放在這裡。
最後補充乙個維表層，維表層主要包含兩部分資料：
高基數維度資料：一般是使用者資料表、商品資料表類似的資料表。資料量可能是千萬級或者上億級別。
低基數維度資料：一般是配置表，比如列舉值對應的中文含義，或者日期維表。資料量可能是個位數或者幾千幾萬。
至此，我們講完了資料分層設計中每一層的含義，這裡做乙個總結便於理解，如下圖。
趁熱打鐵，舉個栗子說明一下，如下圖，可以認為是乙個電商**的資料體系設計。我們暫且只關注使用者訪問日誌這一部分資料。
在ods層中，由於各端的開發團隊不同或者各種其它問題，使用者的訪問日誌被分成了好幾張表上報到了我們的ods層。
在dwm層，我們會從dwd層中選取業務關注的核心維度來做聚合操作，比如只保留人、商品、裝置和頁面區域維度。類似的，我們這樣做了很多個dwm的中間表
然後在dws層，我們將乙個人在整個**中的行為資料放到一張表中，這就是我們的寬表了，有了這張表，就可以快速滿足大部分的通用型業務需求了。
既然談到了資料分層，那不同的層次中會用到什麼計算引擎和儲存系統呢，本節來簡單分享一下。
資料層的儲存一般如下：
ods 層：ods 的資料量一般非常大，所以大多數公司會選擇存在hdfs上，即hive或者hbase，hive居多。
我個人從這幾個角度來理解資料分層的劃分：
從能力範圍來講，我們希望80%需求由20%的表來支援。直接點講，就是大部分（80%以上）的需求，都用dws的表來支援就行，dws支援不了的，就用dwm和dwd的表來支援，這些都支援不了的極少一部分資料需要從原始日誌中撈取。結合第一點來講的話就是：80%的需求，我們都希望以對應用很友好的方式來支援，而不是直接暴露給應用方原始日誌。
從資料聚合程度來講，我們希望，越上層資料的聚合程度越高，看上面的例子即可，ods和dwd的資料基本是原始日誌的粒度，不做任何聚合操作，dwm做了輕度的聚合操作只保留了通用的維度，dws做了更高的聚合操作，可能只保留一到兩個能表徵當前描述主體的維度。從這個角度來看，我們又可以理解為我們是按照資料的聚合程度來劃分資料層次的。
資料倉儲分層架構設計
大資料資料倉儲是基於hive構建的資料倉儲，分布檔案系統為hdfs，資源管理為yarn，計算引擎主要包括mapreduce tez spark等，分層架構如下 1 資料 層 日誌或者關係型資料庫，並通過flume sqoop kettle等etl工具匯入到hdfs，並對映到hive的資料倉儲表中。2...
資料倉儲分層架構
在一篇部落格看見了有關資料倉儲分層的內容，概括如下 複製層 ssa,system of records staging area ssa 直接複製源系統的資料，盡量保持業務資料的原貌 與源系統資料唯一不同的是，ssa 中的資料在源系統資料的基礎上加入了時間戳的資訊，形成了多個版本的歷史資料資訊。原子...
資料倉儲架構分層
資料倉儲簡介 有些人不理解資料倉儲，認為資料倉儲就是獲取資料，只要會使用hadoop spark等大資料工具就懂資料倉儲，這樣的認識太片面。如果要從海量資料中總結出乙個報表或者是多個報表，大資料工程師足以 如果在有限的資源動態的資料情況下，向前可歷史追溯，向後對不斷增加的報表實現相容，這就需要一套科...