1、Hadoop數據倉庫架構設計
如上圖。
ODS（Operation Data Store）層：ODS層通常也被稱為准備區（Staging area），它們是后續數據倉庫層（即基於Kimball維度建模生成的實時表和維度表層，以及基於事實表和明細表
加工的匯總層數據）加工數據的來源，同時ODS層也存儲着歷史的增量和或全量數據。
數據倉庫層（DW：Data Warehouse）: 是Hadoop數據平台的主體內容。數據倉庫層的數據是ODS層數據經過ETL清洗、轉換、加載生成的。Hadoop數據倉庫的DW層通常都是基於
Kimball的維度建模理論來構建的，並通過維度一致性和和數據總線來保證各個子主題的維度一致性。
DW層的數據一定是清洗過的、干凈的、一致的、規范的、准確的數據。數據平台 的下游用戶將會直接使用DW層數據，而ODS層數據原則上不允許下游用戶直接接觸和訪問。
此外，出於性能、重復計算和使用便捷性考慮，DW層數據除了保存基於Kimball維度建模的最細粒度的事實表和維度表（DW層的明細層，data warehouse detail 細節數據層），
還會基於它們生成一層匯總數據（即DW層的匯總層，data warehouse service 服務數據層）。匯總層的設計主要出於性能及避免重復計算考慮。實際數據倉庫的匯總層如何設計以及主要對
哪些維度進行匯總等，需要根據業務需求及明細層實際匯總頻率來確定，原則上，業務使用頻繁的的維度需要對這些維度建立匯總層，匯總的指標可以和業務需求共同設計完成。
應用層：在DW的基礎上，各個業務方或部門可以建立自己的數據集市（Data Mart）,此層一般稱為應用層。應用層的數據來源於DW層，原則上不允許應用層之間訪問ODS層，相比DW層，
應用層只包含部門或業務方自己關心的明細層和匯總層數據。
采用上述分層架構的好處：
1、屏蔽源頭系統業務變更、系統變更對於下游用戶的影響
如果源頭系統業務發生變更，相關的變更有DW層來處理，對下游用戶透明，無須改動下游用戶的代碼和邏輯。
2、屏蔽源頭系統的復雜性。
3、避免重復計算和存儲
通過匯總層的引入，避免了下游用戶邏輯的重復計算，節省了用戶的開發時間和精力，同時也節省了計算和存儲。
4、數據倉庫的可維護性
分層的設計使得某一層的問題只在該層得到解決，無須更改下一層的代碼和邏輯。
2、Hadoop數據倉庫規范設計
數據倉庫的的規范包括很多方面，如數據的命名規范、開發規范、流程規范、安全規范和質量規范等。
2.1、命名規范
表命名規范
表命名規范是為了讓數據所有相關方對於表包含的信息有一個共同的認知。比如屬於哪一次（ODS、DW明細層、DW匯總層、應用層）？哪個業務領域（銷售、庫存、客戶服務、催銷等）、
哪個維度（商品、買家、賣家、類目等）？哪個時間跨度（天、月、年、實時等）？增量還是全量？
基於此，數據平台建設者應該首先規定數據倉庫分層、業務領域、常見維度和時間跨度等的英文縮寫，並根據詞給出表的命名規范。
對於大型零售超市（FutureRetailer）數據平台，給出如下表命名規范：
第一部分為數據倉庫分層：可能取值為ODS(ODS層表)、DWD（DW明細層表）、DWS（DW匯總層表）、ADS（應用層表）等。
第二部分為業務領域：可能取值為sls（銷售）、inv（庫存）、srv（客戶服務）、prmt（促銷）等。
第三部分為用戶自定義標簽：比如商品粒度為itm、買家為byr、賣家為slr。當然用戶也可以自己定義自己的業務、項目和產品標簽。
第四部分為時間標簽：比如d為天、m為月、y為年、di為增量表，df為全量表等。
根據上述設計，一個匯總層、商品粒度的月度銷售匯總表的表應該為：dws_sls_itm_m
字段命名規范
字段命名規范應該有意義而易於理解，最好是能夠表達字段含義的英文字母。比如，數量型的字段一般以cnt(count)結尾、數值型的字段以amt（amount）結尾。
實際項目中，數據平台可以提供常用的英文縮寫，業務縮寫來規范用戶的字段命名。
3、流程規范
流程規范用於開發流程行為，以保證數據交付進度和質量，降低交付風險。
流程規范主要分為需求流程規范和開發流程規范。
常見的需求流程規范如下：
數據開發流程：
4、數據倉庫構建
維度建模采用有序的四個環節來設計各個業務主題的數據倉庫（選擇業務過程、定義粒度、確定維度和確定事實），同時維度建模用維度一致性和數據總線架構來保證各個子主題維度數據的一致性。
首先划分FutureRetailer的業務主題，可以將其主題划分為銷售域、庫存域、客戶服務器域、采購域等。其次是確定每個主題域的事實表和維度表。
對於每個主題域，比如銷售，需要選擇最細粒度的數據，很容易確定銷售域的最細粒度事實為購物小票的子項。庫存域的最細粒度為商品的SKU的庫存。客戶服務熱線的最細粒度為每一次電話呼叫。
采購域的最細粒度為某個商品的SKU的采購申請等。
確定粒度之后，相關的維度也基本確定，但是根據Hadoop的反規范和扁平化的設計思路，還需要確定哪些字段需要反規范化和扁平化到相關維度表中。
最后一步就是確定需要是事實表，而且應該明確需要哪種類型是事實表，是事務事實表，還是周期快照事實表以及累計快照事實表？如果維度表反規范化和扁平化設計一樣，也要講使用頻率高的維度
字段反規范化和扁平化到事實表中。
4.1、商品維度表
將商品維度表命名為dim_fr_item（參照上面的命名方式，fr代表FutureRetailer）
維度表設計的首要問題是維度表的拆分以及合並問題
4.2.、銷售事實表
銷售子主題是典型的事務性業務活動，並不涉及業務狀態的定期快照，也並非工作流形式的業務活動，因此僅需要事務事實表即可。
銷售事實表將通過商品ID、買家ID、賣家ID等和其它維度表關聯。如下圖：
根據Hadoop數據倉庫反規范化和扁平化的設計思想，除了度量以及維度外鍵ID等字段，事實表還需冗余相關常用維度字段到銷售事務事實表中。
參考資料：《離線和實時大數據開發實戰》