先從大數據數據倉庫建設的整體架構說起。
下圖是數據倉庫的邏輯分層架構：
想看懂數據倉庫的邏輯分層架構，必須先弄懂以下4大概念。
數據源：數據來源，互聯網公司的數據來源隨着公司的規模擴張而呈遞增趨勢，同時自不同的業務源，比如埋點采集，客戶上報，API等。
ODS層：數據倉庫源頭系統的數據表通常會原封不動地存儲一份，這稱為ODS層, ODS層也經常會被稱為准備區。這一層做的工作是貼源，而這些數據和源系統的數據是同構，一般對這些數據分為全量更新和增量更新，通常在貼源的過程中會做一些簡單的清洗。
DW層：數據倉庫明細層和數據倉庫匯總層是數據倉庫的主題內容。將一些數據關聯的日期進行拆分，使得其更具體的分類，一般拆分成年、月、日，而ODS層到DW層的ETL腳本會根據業務需求對數據進行清洗、設計，如果沒有業務需求，則根據源系統的數據結構和未來的規划去做處理，對這層的數據要求是一致、准確、盡量建立數據的完整性。
DWS層：應用層匯總層，主要是將DWD和DWS的明細數據在hadoop平台進行匯總，然后將產生的結果同步到DWS數據庫，提供給各個應用。舉個例子，從ODS層中對用戶的行為做一個初步匯總，抽象出來一些通用的維度：時間、ip、id，並根據這些維度做一些統計值，比如用戶每個時間段在不同登錄ip購買的商品數等。這里做一層輕度的匯總會讓計算更加的高效，在此基礎上如果計算僅7天、30天、90天的行為的話會快很多。
DA應用層：
① 業務產品CRM、ERP等，業務產品所使用的數據，已經存在於數據共享層，直接從數據共享層訪問即可；
② 報表FineReport、業務報表，同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；
③ 即席查詢即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；
④ OLAP：目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型數據庫中做OLAP，但如果數據量巨大的話，關系型數據庫顯然不行；
⑤ 其它數據接口：這種接口有通用的，有定制的。比如一個從Redis中獲取用戶屬性的接口是通用的，所有的業務都可以調用這個接口來獲取用戶屬性。
一、數據采集
數據采集層的任務就是把數據從各種數據源中采集和存儲到數據存儲上，期間有可能會做一些ETL操作。數據源種類可以有多種：
- 日志：所占份額最大，存儲在備份服務器上
- 業務數據庫：如Mysql、Oracle
- 來自HTTP/FTP的數據：合作伙伴提供的接口
- 其他數據源：如Excel等需要手工錄入的數據
二、數據存儲與分析
隨着公司的規模不斷擴張，產生的數據也越來越到，像一些大公司每天產生的數據量都在PB級別，傳統的數據庫已經不能滿足存儲要求，目前hdfs是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。
離線數據分析與計算，也就是對實時性要求不高的部分，Hive還是首當其沖的選擇。豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapReduce要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼。當然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂意開發Java，或者對SQL不熟，那么也可以使用MapReduce來做分析與計算。
三、數據共享
這里的數據共享，其實指的是前面數據分析與計算后的結果存放的地方，其實就是關系型數據庫和NOSQL數據庫；
前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那么就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據。和數據采集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。
另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。
四、維度建模
維度建模是專門用於分析型數據庫、數據倉庫、數據集市建模的方法。這里牽扯到兩個基本的名詞：維度，事實。
維度：維度是維度建模的基礎和靈魂，在維度建模中，將度量成為事實，將環境描述為維度，維度是用於分析事實所需的多樣環境。例如，在分析交易過程中，可以通過買家、賣家、商品和時間等維度描述交易發生的環境。
事實：事實表作為數據倉庫維度建模的核心，緊緊圍繞着業務過程來設計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和與業務過程有關的度量。事實表中一條記錄所表達的業務細節被稱之為粒度。通常粒度可以通過兩種方式來表述：一種是維度屬性組合所表示的細節程度，一種是所表示的具體業務含義。
簡單的說，維度表就是你觀察該事物的角度（維度)，事實表就是你要關注的內容。例如用戶使用滴滴打車，那么打車這件事就可以轉化為一個事實表，即打車訂單事實表，然后用戶對應一張用戶維度表，司機對應一張司機維度表。
1、維度建模的三種模式：
- 星型模式
星型模型架構是一種非正規化的結構，特點是有一張事實表，多張維度表，是不存在漸變維度的，事實表和維度表通過主外鍵相關聯，維度表之間是沒有關聯，因為維度表的數據冗余，所以統計查詢時不需要做過多外部連接。
- 雪花模式
雪花模型架構就是將星型模型中的某些維度表抽取成更細粒度的維度表，然后讓維度表之間也進行關聯，通過最大限度的減少數據存儲量以及聯合較小的維度表來改善查詢性能。
下圖為使用雪花模式進行維度建模的關系結構：
星形模式中的維表相對雪花模式來說要大，而且不滿足規范化設計。雪花模型相當於將星形模式的大維表拆分成小維表，滿足了規范化設計。然而這種模式在實際應用中很少見，因為這樣做會導致開發難度增大，而數據冗余問題在數據倉庫里並不嚴重。
- 星座模式
數據倉庫由多個主題構成，包含多個事實表，而維表是公共的，可以共享，這種模式可以看做星型模式的匯集，因而稱作星系模式或者事實星座模式。
事實上，星座模式是數據倉庫最長使用的數據模式，尤其是企業級數據倉庫（EDW）。這也是數據倉庫區別於數據集市的一個典型的特征，從根本上而言，數據倉庫數據模型的模式更多是為了避免冗余和數據復用，套用現成的模式，是設計數據倉庫最合理的選擇。
2、維度表設計：
維度的設計過程就是確定維度屬性的過程，如何生成維度屬性，以及所生成維度屬性的優劣，決定了維度是用的方便性，成為數據倉庫易用性的關鍵。
數據倉庫的能力直接與維度屬性的質量和深度成正比。
3、維度表基本設計方法：
以商品維度為例對維度設計放發進行詳細說明。
- 第一步：確定維度，具備唯一性
作為維度建模的核心，在企業級數據倉庫中，必須保證維度的唯一性。以商品維度為例，有且只有一個維度定義。
- 第二步：確定主維表，確定描述維度的主表
此處的主維表一般是ODS表，直接與業務系統同步。
- 第三步：確定相關表，根據業務之間的關聯性，確定維度的相關表
數據倉庫是業務源系統的數據整合，不同業務系統或者同一業務系統中的表之間存在關聯性，根據業務系統的梳理，確定哪些表和主維表存在關聯關系，並選擇其中的某些表用於生成維度屬性。以商品維度為例，根據業務邏輯的梳理，可以得到商品與類目、sku、買家、賣家、店鋪等維度存在的關聯關系。
- 第四步：確定維度屬性
包含兩個階段，第一個階段從主維表中選擇維度屬性，第二階段從相關維表中選擇維度屬性。確定維度有以下原則：
① 盡可能豐富的維度屬性，為下游分析、統計提供良好的基礎
② 維度屬性提供編碼+文字的描述，編碼用於表關聯，文字表示真正的標簽
③ 沉淀出通用的維度屬性，一來減少下游使用的復雜度，二來避免下游口徑不一致
以商品維度為例，從主維表和類目、sku、賣家、店鋪等相關維表中選擇維度屬性或者生成新的維度屬性。
該模式就屬於雪花模式。
對於商品維度，如果采用反規范化，將表現為下圖所示的形式：
采用雪花模式，除了可以節約一部分存儲之外，對於OLAP系統來說沒有其他的效用。而現階段存儲的成本非常低。出於易用性和性能的考慮，維表一般設計成不規范化的。在實際應用中，幾乎總是使用維表的空間來換取簡明性和查詢性能。
4、事實表設計：
事實表作為數據倉庫維度建模的核心，緊緊圍繞着業務過程來設計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和業務過程有關的度量。
相對維表來說，事實表要細長的多，行的增加速度也比維表快很多。事實表分為三種類型：事務事實表，周期快照事實表，累計快照事實表。本文主要討論事務事實表，不做詞義贅述。
5、事實表設計原則及基本設計方法：
- 盡可能包括所有業務過程相關的事實
- 只選擇與業務過程相關的事實
- 分解不可加事實為可加的組件
- 選擇維度和事實之前必須先聲明粒度
- 在同一個事實表中不可以有多重不同粒度的事實
- 事實的單位要保持一致
- 對事實的null值要處理
- 使用退化維提高事實表的易用性
任何類型的事件都可以被理解成一種事務。比如交易過程中的創建訂單，買家付款，物流中的發貨，簽收，付款等。事務事實表針對這些過程創建的一種事實表。
6、下面店鋪交易事務為例，闡述事務事實表的一般設計過程。
（1）選擇業務過程及確定事實表類型：
交易的過程分為：創建訂單、買家付款、賣家發貨、買家確認收貨，即下單、支付、發貨和成功完結四個業務過程。Kimball維度建模理論認為，為了便於進行獨立的分析研究，應該為每一個業務過程建立一個事實表。
（2）聲明粒度：
業務過程選定之后，就要對每個業務過程確定一個粒度，即確定事實表每一行所表達的細節層次。需要為四個業務過程確定粒度，其中下單、支付和成功完結選擇交易子訂單粒度，即每個子訂單為事實表的一行，買家收貨的粒度為物流單。
（3）確定維度：
完成粒度聲明以后，也就意味着確定了主鍵，對應的維度組合以及相關的維度字段就可以確定了，應該選擇能夠描述清楚業務過程所處的環境的維度信息。在店鋪交易事實表設計過程中，按照經常用於統計分析的場景，確定維度包含：買家、賣家、商品、商品類目、發貨地區、收貨地址、父訂單維度以及雜項維度。
（4）確定事實：
作為過程度量的核心，事實表應該包含與其描述過程有關的所有事實。以店鋪交易事實表為例，選定三個業務過程:下單、支付、成功完結，不同的業務過程有不同的事實。比如在下單業務過程中，需要包含下單金額、下單數量、下單分攤金額；
經過以上四步店鋪交易事務事實表已成型，如下圖所示：
在確定維度時，包含了買賣家維度，商品維度，類目維度，收發貨等。Kimball維度建模理論建議在事實表中只保留這個維度表的外鍵，但是在實際的應用中，可以將店鋪名稱、商品類型、商品屬性、類目屬性冗余到事實表中，提高對事實表的過濾查詢，減少表之間的關聯次數，加快查詢速度，該操作稱之為退化維。
經過以上的操作，基本完成了店鋪交易事務事實表的設計工作。
五、元數據管理
元數據通常定義為”關於數據的數據”,在數據倉庫中是定義和描述DW/BI系統的結構，操作和內容的所有信息。
元數據貫穿了數據倉庫的整個生命周期，使用元數據驅動數據倉庫的開發，使數據倉庫自動化，可視化。
在操作數據倉庫時，操作的都是元數據，而元數據分為技術元數據和業務元數據。
業務元數據是為管理層和業務分析人員服務，從業務的角度描述數據，包括行業術語、數據的可用性、數據的意義等。常用的業務元數據有：
維度和屬性、業務過程、指標等規范化定義，用於更好的管理和使用數據。數據應用元數據，數據報表、數據產品等配置和運行元數據。
技術元數據是指數據倉庫開發、管理、維護相關的數據，描述了數據的原信息，轉換描述、數據映射、訪問權限等。常用的技術元數據有：
存儲位置、數據模型、數據庫表、字段長度、字段類型、ETL腳本、SQL腳本、接口程序、數據關系等。
元數據的存儲有常用的兩種，一種是以數據集為基礎，每一個數據集有對應的元數據文件，每一個元數據文件對應數據集的元數據內容，另一種是以數據庫為基礎，由若干項組成，每一項標識元數據的一個元素。
六、任務調度與監控
在數據倉庫建設中，有各種各樣非常多的程序和任務，比如：數據采集任務、數據同步任務、數據清洗任務、數據分析任務等。這些任務除了定時調度，還存在非常復雜的任務依賴關系。
比如：數據分析任務必須等相應的數據采集任務完成后才能開始；數據同步任務需要等數據分析任務完成后才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫的中樞，負責調度和監控所有任務的分配與運行。
目前有能力的公司都是自己開發調度工具，如中國平安（linkdu），銀行行業用的較多是Control-M，一些互聯網公司可能會選擇airflow作為自己的調度工具。
具體采用哪種工具，可以根據自己公司的本身現狀去做定奪。
最后，在我看來，數據倉庫建設是一個綜合性技術，而且當企業業務復雜的時候，這部分工作更是需要專門團隊與業務方共同合作來完成。
因此一個優秀的數據倉庫建模團隊既要有堅實的數據倉庫建模技術，還要有對現實業務清晰、透徹的理解。
另外，架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。