本項目教程筆記源自多易教育《Titan綜合數據倉庫與數據運營系統》，在CSDN學院有相關視頻教程購買鏈接，大數據企業級項目實戰–Titan大型數據運營系統
本項目課程是一門極具綜合性和完整性的大型大數據項目實戰課程，課程項目的業務背景源自各類互聯網公司對海量用戶瀏覽行爲數據和業務數據分析的需求及企業數據管理、數據運營需求。
學完本課程，你將很容易就拿到大數據數倉建設或用戶畫像建設等崗位的OFFER
本課程項目涵蓋數據採集與預處理、數據倉庫體系建設、用戶畫像系統建設、數據治理（元數據管理、數據質量管理）、任務調度系統、數據服務層建設、OLAP即席分析系統建設等大量模塊，力求原汁原味重現一個完備的企業級大型數據運營系統。
跟隨項目課程，歷經接近100+小時的時間，從需求分析開始，到數據埋點採集，到預處理程序代碼編寫，到數倉體系搭建…逐漸展開整個項目的宏大視圖，構建起整個項目的摩天大廈。
一、事實和維度
1、基本概念
事實： 現實發生的某件事
維度： 衡量事實的一個角度
事實表： 記錄事實的表；比如，訂單表，註冊表，購物車，退貨表，瀏覽日誌表
維度表： 對維度的詳細描述信息；比如，地域維表，產品維表，品類維表，欄目維表，時間維表；
2、事實表及維度舉例
訪客瀏覽記錄表
uid,session,page,lanmu,pinlei,pid,datetime,areacode
u1,s1,/abc/dd,lm1,cat1,p01,2019-10-21 16:18:21,11010
u1,s1,/bbb/cd,lm2,cat3,p08,2019-10-21 16:18:30,11010
u2,s2,/aty/rt,lm3,cat5,p05,2019-10-21 16:17:21,01010
u2,s2,/bbb/cd,lm2,cat3,p08,2019-10-21 16:19:30,01010
上面的表就是一個 事實表
對事實表，假如要計算pv數（指標）
我們按如下口徑來統計：
總pv數
每個欄目的pv數
每個省份的pv數
每個商品品類的pv數
每個省份中的每個欄目的pv數
從這些需求中可以看出，同一個指標，可以通過多種角度（口徑）去統計！
這些角度，或口徑，就叫“維度！”
維度組合中的維度越多，統計出來的事實指標粒度越細
3、維表舉例
欄目維度表：
欄目id，欄目名稱
lm1,生鮮水產
lm2,衝調飲品
lm3,智能設備
地域碼維表：
地域碼 省 市
11010 湖北省,武漢市
01010 山西省,臨汾市
時間維表：
日期 季度 週數 周幾 銷售季 活動期間
2019-10-21 4 38 monday
2019-10-21 4 38 monday
維表的作用： 可以對統計維度進行人性化的詮釋！可以豐富維度內容！
4、維度建模經典模型
星型模型
雪花模型
星座模型
二、數倉分層管理
數倉分層： 就是將數倉中大量的表進行分層管理！
1、數倉分層概述
數據倉庫中的數據表，往往是分層管理、分層計算的：
ADS層： 應用服務層
DWS層：數倉彙總層
DWD層：數倉明細層
ODS層：操作數據（最原始的數據）層 – 貼源層
ODS層：對應着外部數據源ETL到數倉體系之後的表！
DWD層：數倉明細層；一般是對ODS層的表按主題進行加工和劃分；本層中表記錄的還是明細數據；
DWS層：數倉彙總層；
ADS層： 應用層，主要是一些結果報表！
2、分層思想示意圖
分層的意義：數據管理更明晰！運算複用度更高！需求開發更快捷！便於解耦底層業務（數據）變化！
圖示：什麼叫運算複用！
分層的意義舉例說明：
– ods層 ： 貼源層，跟瀏覽日誌結構保持一致
– dwd層明細表 ： 對ods的某些字段進行了更進一步的細化，或者關聯了一些額外信息
user,session,page,lanmu,pinlei,pid,datetime,areacode
u1,s1,/abc/dd,lm1,cat1,p01,2019-10-21 16:18:21,11010
u1,s1,/bbb/cd,lm2,cat3,p08,2019-10-21 16:18:30,11010
u2,s2,/aty/rt,lm3,cat5,p05,2019-10-21 16:17:21,01010
u2,s2,/bbb/cd,lm2,cat3,p08,2019-10-21 16:19:30,01010
u1,s3,/bbb/cd,lm2,cat3,p08,2019-10-21 16:18:30,11010
--dws層: 會話聚合 dws_acc_agg_s
用戶 會話 pvs
u1 s1 2
u1 s3 1
u2 s2 2
--dws層: 用戶聚合 dws_acc_agg_u
用戶 會話數 pvs
u1 2 3
u2 1 2
有了上述模型，則：
需求1： 日活總數
需求2： 日訪問總次數
需求3： 日pv總數
需求4： 日訪問次數>2次的人
需求5： 日訪問pv數最高的前100人
需求6： 日訪問次數最高的前100人
這些需求，都可以直接從dws_acc_agg_u得出
3、分層的原因
1)、空間換時間（讓大量運算任務可複用）
通過建設多層次的數據模型供用戶使用，避免用戶直接使用操作型數據，可以更高效的訪問數據。
2)、把複雜問題簡單化
將一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護數據的準確性，當數據出現問題之後，可以不用修復所有的數據，只需要從有問題的步驟開始修復。
3)、便於解耦 “底層業務（數據）的變化”對上層的影響
隨着業務的變化，只需要調整底層的數據，應用層對業務的調整零感知.
三、數倉建模理論
1、什麼是數據模型
數據模型是數據特徵的抽象。數據是描述事物的符號記錄，模型是現實世界的抽象。數據模型從抽象層次上描述了系統靜態特徵、動態行爲和約束條件爲數據庫系統信息表示與操作提供了一個抽象的框架。簡單講數據模型就是數據組織和存放的方法，它強調從業務、數據存取和使用角度合理存儲數據。
數據模型所描述的內容有三部分：數據結構、數據操作、數據約束。
數據結構：主要描述數據的類型、內容、性質以及數據間的聯繫等，是目標類型的集合。
數據操作：主要描述在相 應的數據結構上的操作類型和操作方式。
數據約束：主要描述數據結構內數據間的語法詞義聯繫、他們之間的制約和依存關係，以及數據動態變化的規則，以保證數據的正確、有效和相容。它是完整性規則的集合，用以限定符合數據模型的數據庫狀態，以及狀態的變化。約束條件可以按不同的原則劃分爲數據值的約束和數據間聯繫的約束；靜態約束和動態約束；實體約束和實體間的參照約束等。
2、爲什麼要數據模型
從性能、成本、效率、質量的角度看：
性能：良好的數據模型能幫助我們快速查詢所需要的數據，減少數據的I/O吞吐。
成本：良好的數據模型能極大減少不必要的數據冗餘，也能實現計算結果複用，極大地降低大數據系統中的存儲和計算成本。
效率：良好的數據模型能極大地改善用戶使用數據的體驗，提高使用數據的效率。
質量：良好的數據模型能改善數據統計口徑的不一致，減少數據計算錯誤的可能性。
因此，毋庸置疑，大數據系統需要數據模型方法來幫助更好地組織和存儲數據，以便在性能、成本、效率和質量之間取得最佳平衡。
從業務和數倉建設的角度看：
在數據倉庫的建設中，我們一再強調需要數據模型，那麼數據模型究竟爲什麼這麼重要呢？首先我們需要了解整個數據倉庫的建設的發展史。數據倉庫的發展大致經歷了這樣的三個過程：
簡單的報表階段：這個階段，系統的主要目標是解決一些日常工作中業務人員需要的報表，以及生成一些簡單的能夠幫助領導進行決策所需要的彙總數據。這個階段的大部分表現形式爲數據庫和前端報表工具。
數據集市階段：這個階段主要是根據某個業務部門的需要，進行一定的數據的採集，整理，按照業務人員的需求，進行多維報表的展現，能夠提供對特定業務指導的數據，並且能夠提供特定的領導決策數據。
數據倉庫階段：這個階段主要是按照一定的數據模型，對整個企業的數據進行採集整理，並且能夠按照各個業務部門的需要，提供跨部門的，完全一致的業務報表數據，能夠通過數據倉庫生成對業務具有指導性的數據，同時爲領導決策提供全面的數據支持。
通過對數據倉庫建設的發展階段，我們能夠看出，數據倉庫的建設和數據集市的建設的重要區別就在於數據模型的支持。因此，數據模型的建設，對於我們數據倉庫的建設，有着決定性的意義。 一般來說，數據模型的建設主要能夠幫助我們解決以下的一些問題：
進行全面的業務梳理，改進業務流程。在業務模型建設的階段，能夠幫助我們的企業或者管理機構對本單位的業務進行全面的梳理。通過業務模型的建設，我們應該能夠全面瞭解該單位的業務架構圖和整個業務的運行情況，能夠將業務按照特定的規律進行分門別類和程序化，同時，幫助我們進一步的改進業務的流程，提高業務效率，指導我們業務部門的生產。
建設全方位的數據視角，消滅信息孤島和數據差異。通過數據倉庫的模型建設，能夠爲企業提供一個整體的數據視角，不再是各個部門只是關注自己的數據，而且通過模型的建設，勾勒出部門之間的聯繫，幫助消滅各部門之間的信息孤島的問題，更爲重要的是，通過數據模型的建設，能夠保證這個企業的數據一致性，各個部門之間數據的差異將會得到有效解決。
解決業務的變動和數據倉庫的靈活性。通過數據模型的建設，能夠很好的分離出底層技術的實現和上層業務的展現。當上層業務發生變化時，通過數據模型，底層的技術實現可以非常輕鬆的完成業務的變動，從而達到整個數據倉庫的靈活性。
幫助數據倉庫系統本身的建設。通過數據倉庫的模型建設，開發人員和業務人員能夠很容易的達成系統建設範圍的界定，以及長期目標的規劃，從而能夠使整個項目組明確當前的任務，加快這個系統建設的速度。
3、數據倉庫建模階段劃分
從上圖我們可以清楚地看出，數據倉庫的數據建模大致分爲四個階段：
1. 業務建模，這部分建模工作，主要包含以下幾個部分：
劃分整個單位的業務，一般按照業務部門的劃分，進行各個部分之間業務工作的界定，理清各業務部門之間的關係。
深入瞭解各個業務部門內的具體業務流程並將其程序化。
提出修改和改進業務部門工作流程的方法並程序化。
數據建模的範圍界定，整個數據倉庫項目的目標和階段劃分。
2. 領域概念建模，這部分的建模工作，主要包含以下幾個部分：
抽取關鍵業務概念，並將之抽象化。
將業務概念分組，按照業務主線聚合類似的分組概念。
細化分組概念，理清分組概念內的業務流程並抽象化。
理清分組概念之間的關聯，形成完整的領域概念模型。
3. 邏輯建模，這部分的建模工作，主要包含以下幾個部分：
業務概念實體化，並考慮其具體的屬性
事件實體化，並考慮其屬性內容
說明實體化，並考慮其屬性內容
4. 物理建模，這部分得建模工作，主要包含以下幾個部分：
針對特定物理化平臺，做出相應的技術調整
針對模型的性能考慮，對特定平臺作出相應的調整
針對管理的需要，結合特定的平臺，做出相應的調整
生成最後的執行腳本，並完善之。
從我們上面對數據倉庫的數據建模階段的各個階段的劃分，我們能夠了解到整個數據倉庫建模的主要工作和工作量，希望能夠對我們在實際的項目建設有所幫助
4、數據倉庫建模方法論
1)、範式建模法
範式建模法其實是我們在構建數據模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關係型數據庫得數據存儲，利用的一種技術層面上的方法。目前，我們在關係型數據庫中的建模方法，大部分採用的是三範式建模法。
範式是數據庫邏輯模型設計的基本理論，一個關係模型可以從第一範式到第五範式進行無損分解，這個過程也可稱爲規範化。在數據倉庫的模型設計中目前一般採用第三範式，它有着嚴格的數學定義。從其表達的含義來看，一個符合第三範式的關係必須具有以下三個條件 :
1、每個屬性值唯一，不具有多義性 ;
2、每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分 ;
3、每個非主屬性不能依賴於其他關係中的屬性，因爲這樣的話，這種屬性應該歸到其他關係中去。
由於範式是基於整個關係型數據庫的理論基礎之上發展而來的，因此，本人在這裏不多做介紹，有興趣的讀者可以通過閱讀相應的材料來獲得這方面的知識。
根據 Inmon 的觀點，數據倉庫模型的建設方法和業務系統的企業數據模型類似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分爲兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關係型數據庫上的實例。
從業務數據模型轉向數據倉庫模型時，同樣也需要有數據倉庫的域模型，即概念模型，同時也存在域模型的邏輯模型。這裏，業務模型中的數據模型和數據倉庫的模型稍微有一些不同。主要區別在於：
1、數據倉庫的域模型應該包含企業數據模型的域模型之間的關係，以及各主題域定義。數據倉庫的域模型的概念應該比業務系統的主題域模型範圍更加廣。
2、在數據倉庫的邏輯模型需要從業務系統的數據模型中的邏輯模型中抽象實體，實體的屬性，實體的子類，以及實體的關係等。
以筆者的觀點來看，Inmon 的範式建模法的最大優點就是從關係型數據庫的角度出發，結合了業務系統的數據模型，能夠比較方便的實現數據倉庫的建模。但其缺點也是明顯的，由於建模方法限定在關係型數據庫之上，在某些時候反而限制了整個數據倉庫模型的靈活性，性能等，特別是考慮到數據倉庫的底層數據向數據集市的數據進行彙總時，需要進行一定的變通才能滿足相應的需求。因此，筆者建議讀者們在實際的使用中，參考使用這一建模方式。
2)、維度建模法
維度建模法簡單描述就是按照事實表、維度表來構建數倉、集市。維度建模從分析決策的需求出發構建模型，爲分析需求服務，因此它重點關注用戶如何更快速地完成需求分析，同時具有較好的大規模複雜查詢的相應性能。其典型的代表是星型模型，以及在一些特殊場景下使用的雪花模型。
維度建模的優缺點：
優點，以星型模型爲例子，其針對各個維度做了大量的預處理，如按照維度進行預先的統計、分類、排序等，從而極大的提升數據倉庫的處理能力；另一個優點是維度建模非常直觀，緊緊圍繞着業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。
缺點，由於在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些預處理過程中，往往會導致大量的數據冗餘；另外一個維度建模法的缺點就是，如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用於維度建模的方法。
所以維度建模的領域主要適用於數據集市層，它的最大的作用其實是爲了解決數據倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的複雜關係的抽象方法
維度建模大致分爲一下幾個步驟：
1.選擇需要進行分析決策的業務過程。業務過程可以是單個業務時間，比如交易的支付、退款等；也可以是某個事件的狀態，比如當前的賬戶餘額等；還可以是一系列相關業務時間組成的業務流程，具體需要看我們分析的是某些時間發生情況，還是當前狀態或是時間流轉效率
2.選擇粒度。在事件分析中，我們需要預判所有分析需求細分的程度，從而決定選擇的粒度，粒度是維度的一個組合。
3.識別維表。選擇好粒度之後，就需要基於粒度設計維表，包括維度屬性，用於分析時進行分組和篩選。
4.選擇事實。確定分析需要衡量的指標。
3)、Data Vault建模
Data Vault 是ER模型的衍生，其設計的出發點也是爲了實現數據的整合，但不能直接用於數據分析決策，它強調建立一個可審計的基礎數據層，也就是強調數據的歷史性、可追溯性和原子性，而不要求對數據進行過度的一致性處理和整合；同時它基於主題概念將企業數據進行結果化組織，並引入了更進一步的範式處理來優化模型以應對源系統變更的擴展性。Data Vault模型由以下幾部分組成。
1、Hub：是企業的核心業務實體，由實體key、數據倉庫序列代理鍵、裝載時間、數據來源組成。
2、Link：代表Hub之間的關係。這裏與ER模型最大的區別是將關係作爲一個獨立的單元抽象，可以提升模型的擴展性。它可以直接描述1:1、1:n、n:n的關係，而不需要做任何變更。它由Hub的代理鍵、裝載時間、數據來源組成。
3、Satellite：是Hub的詳細描述內容，一個Hub可以有多個Satellite。它由Hub代理鍵、裝載時間、數據來源、詳細的Hub描述信息組成。
Data Vault 模型比ER模型更容易設計和產出，它的ETL加工可實現配置化。Hub可以想像成人的骨架，那麼Link就是鏈接骨架的韌帶，Satellite是骨架上的血和肉
4)、Anchor 建模
Anchor 對Data Vault模型做了進一步規範化處理，初衷是設計一個高度可擴展的模型，其核心思想是所有的擴展只是添加而不是修改，一次將模型規範到6NF，基本變成了K-V結構化模型。Anchor模型的組成。
Anchors：類似於Data Vault的Hub，代表業務實體，且只有主鍵。
Attributes：功能類似於Data Vault的Satellite，但是它更加規範化，將其全部K-V結構化，一個表只有一個Anchors的屬性描述。
Ties：將是Anchors之間的關係，單獨用表來描述，類似於Data Vault的Link，可以提升整體模型關係的擴展能力。
Knots：代表哪些可能會在多個Anchors中公用的屬性的提煉，比如性別、狀態等這種枚舉類型且被公用的屬性。
在上述四個基本對象的基礎上，又可以細化分爲歷史的和非歷史的，其中歷史的會以時間戳加多條記錄的方式記錄數據的變遷歷史。Anchor模型的創建者以此方式來獲取極大的可擴展性，但是也會增加非常多的查詢join操作，創建者的觀點是，數據倉庫中的分析查詢只是基於一小部分字段進行的，類似於列存儲結構，可以大大減少數據掃描，從而對查詢性能影響較小。一些有數據表裁剪特性的數據庫如MariaDB 的出現，會大量減少join操作。但實際情況是不是如此還有帶商榷。
5、數據倉庫建設流程
1)、數據調研
略
2)、業務調研
數據倉庫是要涵蓋所有業務領域，還是各個業務領域獨自建設，業務領域內的業務線也同樣面臨着這個問題。所以要構建大數據數據倉庫，就需要了解各個業務領域、業務線的業務有什麼共同點和不同點，以及各個業務線可以細分爲哪幾個業務模塊，每個業務模塊具體的業務流程又是怎樣的。業務調研是否充分，將會直接決定數據倉庫建設是否成功。
3)、需求調研
瞭解業務系統的業務後不等於說就可以實施數倉建設了，還需要收集數據使用者的需求，及找分析師、運營人員、產品人員等了解他們對數據的訴求。通常需求調研分下面兩種途徑：
1.根據與分析師、運營人員、產品人員的溝通獲取需求。
2.對現有報表、數據進行研究分析獲取數據建設需求。
例：保險數倉需求指標：
4)、調研方法論
本項目教程筆記源自多易教育《Titan綜合數據倉庫與數據運營系統》，在CSDN學院有相關視頻教程購買鏈接，大數據企業級項目實戰–Titan大型數據運營系統
本項目課程是一門極具綜合性和完整性的大型大數據項目實戰課程，課程項目的業務背景源自各類互聯網公司對海量用戶瀏覽行爲數據和業務數據分析的需求及企業數據管理、數據運營需求。
學完本課程，你將很容易就拿到大數據數倉建設或用戶畫像建設等崗位的OFFER
本課程項目涵蓋數據採集與預處理、數據倉庫體系建設、用戶畫像系統建設、數據治理（元數據管理、數據質量管理）、任務調度系統、數據服務層建設、OLAP即席分析系統建設等大量模塊，力求原汁原味重現一個完備的企業級大型數據運營系統。
跟隨項目課程，歷經接近100+小時的時間，從需求分析開始，到數據埋點採集，到預處理程序代碼編寫，到數倉體系搭建…逐漸展開整個項目的宏大視圖，構建起整個項目的摩天大廈。