『壹』 數倉建模分層理論
這篇文章較為完整、清晰的講述了數倉建模分層理論，要點如下：
1、分層的意義：清晰結構體系、數據血緣跟蹤、減少重復開發、復雜問題簡單化及統一數據口徑
2、ODS：用作緩沖，可以存一周左右，跟DWD大多重復，留存的目的還在於保持跟源端一致，方便追溯
3、DWD：針對ODS做數據的清洗和整合，在DWD層會根據維度模型，設計事實表和維度表，DWD層是一個非常規范的、高質量的、可信的數據明細層
4、DWS：基於DWD層形成某一主題的輕度匯總表或分析寬表，DWS形成大量維度退化的事實表以提高易用性，DWS層應覆蓋80%的應用場景
5、TDM：標簽層，通過統一的ID-Mapping 把各個業務板塊，各個業務過程中同一對象的數據打通，形成對象的全域數據標簽體系，方便深度分析、挖掘、應用，大家注意，這個ID不僅僅指客戶或用戶ID，也包括其它的主數據ID，其是全流程分析的基礎
6、ADS：數據應用層ApplicationDataService面向業務定製的應用數據，主要提供給數據產品和數據分析使用的數據，一般會放在ES，MYSQL，Redis等前端系統供線上系統使用，也可以放在Hive中供數據分析和數據挖掘使用
7、DM：主要是提供數據產品和數據分析的數據，主要解決部門用戶報表和分析需求而建立資料庫，數據集市就代表數據倉庫的主題域。DM 是面向單個主題的，所以它不會從全局考慮進行建設。
強烈推薦閱讀！
正文開始
簡單點兒，直接ODS+DM就可以了，將所有數據同步過來，然後直接開發些應用層的報表，這是最簡單的了；當DM層的內容多了以後，想要重用，就會再拆分一個公共層出來，變成3層架構,這個過程有點類似代碼重構，就是在實踐中不斷的進行抽象、總結。
數倉的建模或者分層，其實都是為了更好的去組織、管理、維護數據,所以當你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 內存區域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區等)，大到國家的省市區的劃分，無一例外的都是為了更好的組織管理 。
所以數倉分層是數據倉庫設計中十分重要的一個環節， 優秀的分層設計能夠讓整個數據體系更容易理解和使用 。
這一節，我們主要是從整體上出發進行分析和介紹，就和上一節數倉建模方法論一樣，進度對比分析，更多細節的東西我們後面會單獨拆分出來，用案例進行演示，例如維度建模，維度表的設計，事實表的設計、以及如何設計標簽、如何管理標簽等等。
每一個數據分層都有它的作用域，這樣在使用表的時候能更方便的定位和理解。
由於最終給業務呈現的是一個能直接使用的業務表，但是表的數據來源有很多，如果有一張來源表出問題了，我們希望能夠 快速准確的定位到問題，並清楚它的影響范圍，從而及時給到業務方反饋，從而將損失降到最低 。
將一個復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護數據的准確性，當數據出現問題之後，可以不用修復所有的數據，只需要從有問題的步驟開始修復。
過數據分層提供統一的數據出口，統一對外輸出的數據口徑，這往往就是我們說的數據應用層。
前面我們說到分層其實是為了更好更快更準的組織管理，但是這個是從宏觀上來說的，接下來我們從微觀上也來看一下分層。
越靠上的層次，對應用越友好,比如ADS層，基本是完全為應用設計,從數據聚合程度來講，越上層的聚合程度越高，當然聚合程度越高可理解程度就越低。
數倉層內部的劃分不是為了分層而分層， 分層是為了解決 ETL 任務及工作流的組織、數據的流向、讀寫許可權的控制、不同需求的滿足等各類問題 ，當然我們常說的分層也是面向行業而言的，也是我們常用分層方法，但是你需要注意的是分層僅僅是手段而已。
ODS 全稱是 OperationalDataStore， 操作數據層存儲的是面向業務系統的數據 ，也是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗凈、傳輸，也就說傳說中的 ETL 之後，裝入本層。
本層的數據，總體上大多是 按照源頭業務系統的分類方式而分類的 ，前面我們說到為什麼在數倉主要用維度建模的情況下，我們依然要學習範式建模呢，因為我們的數據源是範式建模的，所以學習範式建模可以幫助我們更好的理解業務系統，理解業務數據，所以你可以認為我們的ODS 層其實就是用的實範式建模。
這里的數據處理，並不涉及業務邏輯，僅僅是針對數據完整性以及重復值和空值的處理，其實就是做的是數據規約，數據清洗，但是為了考慮後續可能追溯數據源問題，因此 對這一層不建議做過多的數據清洗工作 ，原封不動接入源數據即可，至於數據的去噪，去重，異常值處理等過程可以放在後面的DW層
表名的設計 ODS_業務系統_表名_標記 ，這樣的設計可以保持與業務表名一致，又可以有清晰的層次，還可以區分來源。標記一般指的是其他數倉特有的屬性，例如表是天級的還是小時的，是全量的還是增量的。
ods 的設計可以保證所有的數據按照統一的規范進行存儲。
DW是數據倉庫的核心，從ODS層中獲得的數據按照主題建立各種數據模型。DW又細分數據明細層DWD 和輕度匯總層DWS
這一層和維度建模會有比較深的聯系，業務數據是按照 業務流程方便操作的角度 來組織數據的，而統一數倉層是 按照業務易理解的角度或者是業務分析的角度 進行數據組織的，定義了一致的指標、維度，各業務板塊、數據域都是按照統一的規范來建設，從而形成統一規范的 標准業務數據體系 ，它們通常都是基於Kimball的維度建模理論來構建的， 並通過一致性維度和數據匯流排來保證各個子主題的維度一致性 。
公共層的維度表中相同維度屬性在不同物理表中的欄位名稱、數據類型、數據內容必須保持一致，因為這樣可以降低我們在使用過程中犯錯誤的概率，例如使用了不正確的欄位，或者因為數據類型的原因導致了一些奇怪的錯誤
將維度所描述業務相關性強的欄位在一個物理維表實現。相關性強是指經常需要一起查詢或進行報表展現、兩個維度屬性間是否存在天然的關系等。例如，商品基本屬性和所屬品牌。
公告明細數據層，可以說是我們數倉建設的核心了。
DWD層要做的就是將 數據清理、整合、規范化、臟數據、垃圾數據、規范不一致的、狀態定義不一致的、命名不規范的數據都會被處理 。然後加工成面向數倉的基礎明細表，這個時候可以加工一些面向分析的大寬表。
DWD層應該是覆蓋所有系統的、完整的、干凈的、具有一致性的數據層。在DWD層會根據維度模型，設計事實表和維度表，也就是說DWD層是一個非常規范的、高質量的、可信的數據明細層。
DWS層為 公共匯總層 ，這一層會進行輕度匯總，粒度比明細數據稍粗， 基於DWD層上的基礎數據，整合匯總成分析某一個主題域的服務數據 ，一般是也是面向分析寬表或者是面向某個注意的匯總表。DWS層應覆蓋80%的應用場景，這樣我們才能快速響應數據需求，否則的話，如果很多需求都要從ods開始做的話，那說明我們的數倉建設是不完善的。
例如按照業務劃分，例如流量，訂單，用戶等，生成欄位比較多的寬表，用於後續的業務查詢，OLAP分析，數據分析等。
一般採用維度模型方法作為理論基礎，更多的採用一些維度退化手法，將維度退化至事實表中，減少維度表與事實表的關聯，提高明細數據表的易用性；同時在匯總數據層要加強指標的維度退化，採用更多的寬表化手段構建公共指標數據層，提升公共指標的復用性，減少重復加工 。
維表層，所以其實維度層就是大量維表構成的，為了統一管理這些維度表，所以我們就建設維度層，維度表本身也有很多類型，例如穩定維度維表，漸變維度維表。
維度指的是觀察事物的角度，提供某一業務過程事件涉及用什麼過濾和分類的描述屬性 ，"誰、什麼時候、什麼地點、為什麼、如何"幹了什麼，維度表示維度建模的基礎和靈魂。
所以可以看出，維度表包含了業務過程記錄的業務過程度量的上下文和環境。維度表都包含單一的主鍵列， 維度表設計的核心是確定維度欄位，維度欄位是查詢約束條件(where)、分組條件(group)、排序(order)，與報表標簽的基本來源 。
維度表一般為 單一主鍵 ，在ER模型中，實體為客觀存在的事務，會帶有自己的描述性屬性，屬性一般為文本性、描述性的，這些描述被稱為維度。維度建模的核心是 數據可以抽象為事實和維度 ，維度即觀察事物的角度，事實某一粒度下的度量詞， 維度一定是針對實體而言的 。
每個維度表都 包含單一的主鍵列 。維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度錶行的描述環境應與事實錶行完全對應。維度表通常比較寬，是扁平型非規范表，包含大量的低粒度的文本屬性。例如customer（客戶表）、goods(商品表)、d_time(時間表)這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的數據信息。
維度表通常比較寬 ，包含多個屬性、是扁平的規范表 ，實際應用中包含幾十個或者上百個屬性的維度並不少見，所以 維度表應該包括一些有意義的描述，方便下游使用 。
維度表的維度屬性，應該盡可能的豐富，所以維度表中，經常出現一些反範式的設計，把其他維度屬性並到主維度屬性中， 達到易用少關聯的效果。
維度表的設計包括維度選擇，主維表的確定，梳理關聯維度，定義維度屬性的過程。
維度的選擇一般從報表需求和從業務人員的交談中發現，主要用於過濾、分組、排序，主維度表一般從業務庫直接同步，比如用戶表，但是數倉的本身也會有自己的維度，這是因為數倉是面向分析的，所以會有很多從分析的角度出發的維度。
關聯維度主要是不同業務系統或者同一業務系統的表之間存在關聯性(範式建模)，根據對業務表的梳理，確定哪些表和主維度表之間存在關聯關系，並選擇其中的某些表用於生成維度屬性。
隨著互聯網的普及，獲客成本越來越高，這也使得公司對用戶運營提出了更高的要求，不僅需要精細化更需要個性化。解決這一問題的辦法之一就是建立相對完備的標簽系統，而數倉的標簽層對於標簽系統而言就像數據倉庫對於數據系統一樣，有著舉足輕重的地位，這樣的標簽系統需要與業務進行緊密結合， 從業務中獲取養分—用戶標簽，同時也要服務於業務—給用戶提供更加精準和個性的服務 。
底層的標簽系統就像一個索引，層層展示大千世界，而用戶就從這大千世界中不斷選擇一些東西表明自己的身份和喜好，也不斷反哺，使得這個大千世界更加豐富多彩。 其實到最後用戶就是一些標簽的集合。
對跨業務板塊、跨數據域的特定對象進行數據整合，通過統一的ID-Mapping 把各個業務板塊，各個業務過程中 同一對象的數據打通 ，形成對象的全域數據標簽體系，方便深度分析、挖掘、應用。ID-Mapping 可以認為是通過對象的標識對不同數據體系下相同對象進行關聯和識別。對象的標識可以標識一個對象，一般是對象的ID,比如手機號，身份證，登錄賬號
完成對象的ID 打通需要給對象設置一個超級ID,需要根據對象當前業務體系的ID和獲取得到或者計算得到超級ID,進而完成所有業務標識的ID打通一般來說ID打通是建設標簽體系的前提，如果沒有ID打通就無法收集到一個對象的全面信息，也就無法對這個對象進行全面的標簽刻畫。
傳統的計算方法要有 ID-ID之間的兩兩關系，例如郵箱和手機號可以打通，手機號和身份證號可以打通，那麼郵箱就和身份證號可以打通，但是當數據量非常大，且業務板塊非常多的時候，例如有上一個對象，每個對象有數十種ID,這個時候打通就需要非常漫長的計算
那麼什麼是標簽呢，利用原始數據，通過一定的邏輯加工產出直接能被業務所直接使用的、可閱讀的，有價值的數據。標簽類目，是標簽的分類組織方式，是標簽信息的一種結構化描述，目的是管理、查找，一般採用多級類目，一般當一個對象的標簽個數超過50個的時候，業務人員查找標簽就會變得非常麻煩，這個時候我們往往會通過標簽類目進行組織管理
標簽按照產生和計算方式的不同可分為屬性標簽，統計標簽，演算法標簽，關聯標簽。
對象本身的性質就是屬性標簽，例如用戶畫像的時候打到用戶身上的標簽。
對象在業務過程中產生的原子指標，通過不同的計算方法可以生成統計標簽。
對象在多個業務過程中的特徵規律通過一定的演算法產出的標簽。
對象在特定的業務過程會和其他對象關聯，關聯對象的標簽也可以打在主對象上。
我們的標簽一定是針對用戶的，而不是一些虛假、高大上、無用的標簽，一定要真實反映用戶行為喜好的，所以我們不能只依賴人工智慧演算法的分析，來完成對一個用戶標簽的建立與定期維護，我們需要走出去和用戶交互，引導用戶使用，要抓住用戶痛點，及時獲取用戶反饋，形成閉環。
如何引導使用呢？這個方式有很多我們就不再這里介紹了，後面我們會專門介紹這一層的建設細節。
數據應用層ApplicationDataService面向業務定製的應用數據，主要提供給數據產品和數據分析使用的數據，一般會放在ES，MYSQL，Redis等系統供線上系統使用，也可以放在Hive中供數據分析和數據挖掘使用，或者使用一下其他的大數據工具進行存儲和使用。
數倉層，DIM 層，TDM 層是相對穩定的，所以無法滿足靈活多變業務需求 ，所以這和數倉層的規范和劃分相矛盾，所以我們在此基礎上建立了另外一個層，這就是ADS 層，解決了規劃穩定和靈活多變之間的矛盾。其實到這里你也就慢慢的看明白了，分層和分類其實沒多大差別，其實就是相似的放在一起，有點代碼重構的意味啊。
數據應用層，按照業務的需要，然後從統一數倉層和DIM進行取數，並面向業務的特殊需求對數據進行加工,以滿足業務和性能的需求。ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規范，只需要按照命名規范來進行就可以了。
前面也說了，ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規范，但是ADS 層的建設是強業務推動的，業務部門需要參與到ADS 的建設中來，至少我們得了解用戶的痛點才能對症施葯啊。
理清需求，了解業務方對數據內容、使用方式(怎麼交互的，報表、介面、即席查詢、在線查詢、指標查詢、搜索)、性能的要求。
盤點現有的數倉表是否可以支持，看以前有沒有類似的需求，有沒有可以復用的介面、報表什麼的。
代碼實現，選擇合適的存儲引擎和查詢引擎，配置線上監控然後交付。
主要是提供數據產品和數據分析的數據，一般會存放在ES、Mysql、也可能直接存儲在hive中或者druid供數據分析和數據挖掘使用。主要 解決部門用戶報表和分析需求 而建立資料庫，數據集市就代表數據倉庫的主題域。
DM 是面向單個主題的，所以它不會從全局考慮進行建設，只專注於自己的數據、往往是某個業務線，例如流量主題、社交主題、電商主題等等。
『貳』 典型的數據倉庫系統包括哪幾部分
?（一）數據源是數據倉庫系統的基礎，是整個系統的數據源泉。通常包括企業內部信息和外部信息。內部信息包括存放於rdbms中的各種業務處理數據和各類文檔數據。外部信息包括各類法律法規、市場信息和競爭對手的信息等等；（二）數據的存儲與管理是整個數據倉庫系統的核心。數據倉庫的真正關鍵是數據的存儲和管理。數據倉庫的組織管理方式決定了它有別於傳統資料庫，同時也決定了其對外部數據的表現形式。要決定採用什麼產品和技術來建立數據倉庫的核心，則需要從數據倉庫的技術特點著手分析。針對現有各業務系統的數據，進行抽取、清理，並有效集成，按照主題進行組織。數據倉庫按照數據的覆蓋范圍可以分為企業級數據倉庫和部門級數據倉庫（通常稱為數據集市）。（三）olap(聯機分析處理)伺服器對分析需要的數據進行有效集成，按多維模型予以組織，以便進行多角度、多層次的分析，並發現趨勢。其具體實現可以分為：rolap（關系型在線分析處理）、molap（多維在線分析處理）和holap（混合型線上分析處理）。rolap基本數據和聚合數據均存放在rdbms之中；molap基本數據和聚合數據均存放於多維資料庫中；holap基本數據存放於rdbms之中，聚合數據存放於多維資料庫中。（四）前端工具主要包括各種報表工具、查詢工具、數據分析工具、數據挖掘工具以數據挖掘及各種基於數據倉庫或數據集市的應用開發工具。其中數據分析工具主要針對olap伺服器，報表工具、數據挖掘工具主要針對數據倉庫。-----------------------------由安信公司歷經4年研發的監測數據管理平台，採用獨創的技術架構，在b/s架構上融入c/s模式，囊括了實驗室管理系統、監測站公自動化、監測站綜合業務管理系統、監測數據上報系統等諸多系統，把各個系統有機融合在一起，不同的業務科室展現不同工作頁面，內部卻又實現了數據共享。系統頁面簡單大方，操作輕松方便，在不增加實驗室工作量的情況下，能夠讓監測數據進入系統中，原始記錄單等諸多實驗室報表可協助生成（不完全生成，需人工簽字），隨後科室比如質控、綜合、主管領導即可對數據進行多層次利用查詢，並自動生成各類監測報表。系統採用流程化工作模式，對不同監測任務實施不同工作流，保證工作的科學和嚴謹，對於單位內部職工每天待事宜清晰顯示，讓內部職工對每天工作都一目瞭然。系統工作流程可自由配置，工作單可根據按照配置流轉相應單位，並且可以對工作流程進行追蹤查詢，作為領導可以查看到每一項安排工作的流轉情況、完成情況和監測結果。系統支持簡訊功能，對於領導等科室一些緊急任務可在系統下達後，立刻用簡訊通知相應工作人員，對於單位緊急通知等也可以進行簡訊通知，讓監測站的工作更加快捷高效。系統提供深層次數據挖掘功能，能夠根據監測數據，快速提供某監測點的多方位數據，比如歷年來某月cod的監測數據變化，幾年來某項監測數據的月平均值變化等等，為監測站領導決策提供科學依據。系統生成報表功能強大，除自身已包含眾多報表外，可迅速生成word下各種客戶要求的監測報表，並且查閱維護方便。系統作為平台拓展性強，可以融合其他系統與平台上，並且後期功能升級方便不影響前期功能。目前系統已經在多個地方監測站運行，從使用效果來看是比較實用的。
『叄』 請問數據倉庫都用什麼建立
1、首先你得搞清楚建設數倉的目的是什麼
是偏向於整合各系統數據，為數據分析決策服務，還是偏向於快速的完成分析決策需求？
如果是前者，那麼在數據倉庫建模的時候一般會選擇ER建模方法；
如果是後者，一般會選擇維度建模方法。
ER建模：即實體關系建模，由數據倉庫之父BIll Inmon提出，核心思想是從全企業的高度去設計三範式模型，用實體關系描述企業服務。主張的是自上而下的架構，將不同的OLTP數據集中到面向主題的數據倉庫中。
維度建模：由Kimball提出，核心思想是從分析決策的需求出發構建模型。這種模型由事實表和維表組成，即星悶叢型模型和雪花模型。Kimball倡導自下而上的架構，可以針對獨立部門建立數據集市，再遞增的構建，匯總成數據倉庫。
2、敗罩攜其次你得進行深入的業務調研和數據調研
業務調研：深入的業務調研能使你更加明確數倉建設的目的；同時也利於後續的建模設計，隨著調研的開展，如何將實體業務抽象為數倉模型會更加明朗。
數據調研：各部門或各科室的數據現狀了解，包括數據分類、數據存儲方式、數據量、具體的數據內容等等。這對後續的主數據串聯或者維度一致性處理等等都是必須的基礎。
3、然後是數據倉庫工具選型
傳統型數據倉庫：一般會選擇第三方廠家的資料庫和配套ETL工具。因為有第三方支持，相對有保障；但缺點也很明顯，受約束以及成本較高。
NoSQL型數據倉庫：一般是基於hadoop生態的數據倉庫。hadoop生態已經非常強大，可以找到各種開源組件去支持數據倉庫。缺點是需要招聘專門人士去摸索，並且相對會存在一些未知隱患。
4、最後是設計與實施
設計：包括數據架構中的數據層次劃分以及具體的模型設計；也包括程序架構中的數據質量管理、元數據管理、調度管理等；
實施：規范化的項目管理實施，但同時也需記住一點，數據倉庫不察伏是一個項目，它是一個過程。