當前編輯版本為v0.2(2021.09.10)，
本博客主要參考資料為網上諸多博客，可能存在一定的錯誤，望指正，

資料倉庫理論

??資料倉庫（Data Warehouse）是面向主題的、資料集成的（非簡單的資料堆積）、相對穩定的、反應歷史變化的資料集合，數倉中的資料是有組織有結構的存盤資料集合，用于對管理決策程序的支持，

1. 前置知識

1.1. 聯機事務處理 OLTP

??聯機事務處理（OLTP，on-line transaction processing） 主要是執行基本日常的事務處理，比如資料庫記錄的增刪查改，比如在銀行的一筆交易記錄，就是一個典型的事務，

1.1.1. OLTP的特點

• 實時性要求高，我記得之前上大學的時候，銀行異地匯款，要隔天才能到賬，而現在是分分鐘到賬的節奏，說明現在銀行的實時處理能力大大增強，
• 資料量不是很大，生產庫上的資料量一般不會太大，而且會及時做相應的資料處理與轉移，
• 交易一般是確定的，比如銀行存取款的金額肯定是確定的，所以OLTP是對確定性的資料進行存取
• 高并發，并且要求滿足ACID原則，比如兩人同時操作一個銀行卡賬戶，比如大型的購物網站秒殺活動時上萬的QPS請求，

1.2. 聯機分析處理 OLAP

??聯機分析處理OLAP（On-Line Analytical Processing） 是資料倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果，典型的應用就是復雜的動態的報表系統，

1.2.1. OLAP的特點

• 實時性要求不是很高，比如最常見的應用就是天級更新資料，然后出對應的資料報表，
• 資料量大，因為OLAP支持的是動態查詢，所以用戶也許要通過將很多資料的統計后才能得到想要知道的資訊，例如時間序列分析等等，所以處理的資料量很大;
• OLAP系統的重點是通過資料提供決策支持，所以查詢一般都是動態，自定義的，所以在OLAP中，維度的概念特別重要，一般會將用戶所有關心的維度資料，存入對應資料平臺，

1.3. 資料庫

??資料庫是“按照資料結構來組織、存盤和管理資料的倉庫”，是一個長期存盤在計算機內的、有組織的、可共享的、統一管理的大量資料的集合，

??資料庫是以一定方式儲存在一起、能與多個用戶共享、具有盡可能小的冗余度、與應用程式彼此獨立的資料集合，可視為電子化的檔案柜，存盤電子檔案的處所，用戶可以對檔案中的資料進行新增、查詢、更新、洗掉等操作，資料組織主要是面向事務處理任務，

1.4. 資料庫設計三范式

??關系型資料庫設計時，遵照一定的規范要求，目的在于降低資料的冗余性和保證資料的一致性，這些規范就可以稱為范式NF(Normal Form)，大多數情況下，關系型資料庫的設計符合三范式即可，

??三范式并非相互獨立，而是一種約束上層層嚴苛的關系，

1.4.1. 第一范式（1NF）

??在第一范式中，資料庫所有欄位值都是不可分解、具備原子性的值，

1.4.2. 第二范式（2NF）

??第二范式在第一范式的基礎上更進一層，第二范式需要確保資料庫表中的每一列都和主鍵相關，也就是說在一個資料庫表中，一個表中只能保存一種資料，不可以把多種資料保存在同一張資料庫表中，

*： 有主鍵，非主鍵欄位依賴主鍵，

1.4.3. 第三范式（3NF）

??第三范式需要確保資料表中的每一列資料都和主鍵直接相關，而不能間接相關，

1.5. ER物體關系模型

??ER物體關系模型（Entity-Relationship）是資料庫設計的理論基礎，當前幾乎所有的OLTP系統設計都采用ER模型建模的方式,這種建模方式基于三范式，在資訊系統中，將事物抽象為“物體”、“屬性”、“關系”來表示資料關聯和事物描述，

1.5.1. 物體（Entity）

??物體是一類資料模型，指應用中可以區別的客觀存在的事物，它具有自己的屬性，在ER物體關系模型中物體使用方框表示，

1.5.2. 屬性（Attribute）

??對物體的描述、修飾就是屬性，即物體的某一特性稱為屬性，在ER物體關系模型中屬性使用橢圓來表示，

1.5.3. 關系（Relationship）

??關系表示一個或多個物體之間的關聯關系，可分為一對一關系、一對多關系和多對多關系，

2. 資料倉庫

2.1. 資料倉庫的提出

??1991年，比爾·恩門（Bill Inmon）出版了他的第一本關于資料倉庫的書《Building the Data Warehouse》，標志著資料倉庫概念的確立，該書定義了資料倉庫非常具體的原則，包括：

• 資料倉庫是面向主題的（Subject-Oriented）
• 集成的（Integrated）
• 包含歷史的（Time-variant）
• 不可更新的（Nonvolatile）
• 面向決策支持的（Decision Support）
• 面向全企業的（Enterprise Scope）
• 最明細的資料存盤（Atomic Detail）
• 資料快照式的資料獲取（Snap Shot Capture）

??這些原則到現在仍然是指導資料倉庫建設的最基本原則，憑借著這本書，Bill Inmon被稱為“資料倉庫之父”，

2.2. 資料庫vs資料倉庫

??傳統關系型資料庫的主要應用是OLTP(On-Line Transaction Processing)，主要是基本的、日常的事務處理，例如銀行交易，主要用于業務類系統，主要供基層人員使用，進行一線業務操作，

??數倉系統的主要應用主要是OLAP（On-Line Analytical Processing），支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果，OLAP資料分析的目標是探索并挖掘資料價值，作為企業高層進行決策的參考，

3. 維度建模

??維度建模主要源自資料集市，主要面向分析場景，

??維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模復雜查詢的回應性能，它與物體-關系（ER）建模有很大的區別，物體-關系建模是面向應用，遵循第三范式，以消除資料冗余為目標的設計技術，維度建模是面向分析，為了提高查詢性能可以增加資料冗余，反規范化的設計技術，

??Ralph Kimball推崇資料集市的集合為資料倉庫，同時也提出了對資料集市的維度建模，將資料倉庫中的表劃分為事實表、維度表兩種型別，

3.1. 事實表

??發生在現實世界中的操作型事件，其所產生的可度量數值，存盤在事實表中，

3.2. 維度表

??維度表包含了維度的每個成員的特定名稱，維度成員的名稱稱為“屬性”(Attribute)，

3.3. 維度建模模型

3.3.1. 星型模型

??當所有的維度表都由連接鍵連接到事實表時，結構圖如星星一樣，這種分析模型就是星型模型，

??星型模型因為資料的冗余所以很多統計查詢不需要做外部的連接，因此一般情況下效率比雪花型模型要高，星型結構不用考慮很多正規化的因素，設計與實作都比較簡單，

星型模型

3.3.2. 雪花模型

??當有一個或多個維表沒有直接連接到事實表上，而是通過其他維表連接到事實表上時，其結構圖就像雪花連接在一起，這種分析模型就是雪花模型，如下圖，雪花模型是對星型模型的擴展，它對星型模型的維表進一步層次化，原有的各維表可能被擴展為小的事實表，形成一些區域的“層次”區域，這些被分解的表都連接到主維度表而不是事實表，

雪花模型

??星型模型和雪花模型主要區別就是對維度表的拆分，對于雪花模型，維度表的設計更加規范，一般符合三范式設計;而星型模型，一般采用降維的操作，維度表設計不符合三范式設計，反規范化，利用冗余犧牲空間來避免模型過于復雜，提高易用性和分析效率，

??雪花型模型由于去除了冗余，有些統計就需要通過表的聯接才能產生，所以效率不一定有星型模型高，正規化也是一種比較復雜的程序，相應的資料庫結構設計、資料的ETL、以及后期的維護都要復雜一些，因此在冗余可以接受的前提下，數倉構建實際運用中星型模型使用更多，也更有效率，

3.3.3. 星座模型

星座模式也是星型模式的擴展，星型模型和雪花模型都是基于多維表對應事實表，有的時候多個事實表共用多張維度表，這個時候就需要采用星座模式，

星座范式

4. 資料倉庫分層架構

4.1. 分層架構的優勢

4.1.1. 清晰的資料結構

??每層資料都有各自的作用域和職責，在使用表的時候更方便定位和理解，

4.1.2. 減少重復開發

??規范資料分層，開發一層公用的中間層資料，減少重復計算流轉資料，

4.1.3. 統一資料出口

??通過資料分層，提供統一的資料出口，保證對外輸出資料口徑一致，

4.1.4. 簡化問題

??通過資料分層，將復雜的業務簡單化，將復雜的業務拆解為多層資料，每層資料負責解決特定的問題，

4.2. 分層思想

資料倉庫-分層架構

4.2.1. ODS(Operational Data Store)

??ODS層，操作資料層，也叫貼源層，本層直接存放從業務系統抽取過來的資料，這些資料從結構上和資料上與業務系統保持一致，降低了資料抽取的復雜性，本層資料大多是按照源頭業務系統的分類方式而分類的，一般來講，為了考慮后續可能需要追溯資料問題，因此對于這一層就不建議做過多的資料清洗作業，原封不動地接入原始資料即可，

4.2.2. DW(Data Warehouse)

??DW層，資料倉庫層，是我們在做資料倉庫時要核心設計的一層，本層將從 ODS 層中獲得的資料按照主題建立各種資料模型，每一個主題對應一個宏觀的分析領域，資料倉庫層排除對決策無用的資料，提供特定主題的簡明視圖，DW層又細分為 DWD（Data Warehouse Detail）層、DWM（Data Warehouse Middle）層和DWS（Data Warehouse Service）層，

4.2.3. DWD(Data Warehouse Detail)

??DWD,資料明細層一般保持和ODS層一樣的資料粒度，并且提供一定的資料質量保證，在ODS的基礎上對資料進行加工處理，提供更干凈的資料，同時，為了提高資料明細層的易用性，該層會采用一些維度退化手法，當一個維度沒有資料倉庫需要的任何資料時，就可以退化維度，將維度退化至事實表中，減少事實表和維表的關聯，例如：訂單id,這種量級很大的維度，沒必要用一張維度表來進行存盤，而我們一般在進行資料分析時訂單id又非常重要，所以我們將訂單id冗余在事實表中，這種維度就是退化維度，

4.2.4. DWM(Data Warehouse Middle)

??DWM,資料中間層,是會在DWD層的資料基礎上，對資料做輕度的聚合操作，生成一系列的中間表，提升公共指標的復用性，減少重復加工處理資料，簡單來說，就是對通用的維度進行聚合操作，算出相應的統計指標，方便復用，

4.2.5. DWS(Data Warehouse Service)

??DWS,資料服務層資料表會相對比較少，大多都是寬表(一張表會涵蓋比較多的業務內容，表中的欄位較多)，按照主題劃分，如訂單、用戶等，生成欄位比較多的寬表，用于提供后續的業務查詢，OLAP分析，資料分發等，
在實際業務處理中，如果直接從DWD或者ODS計算出寬表的統計指標，會存在計算量太大并且維度太少的問題，因此一般的做法是，在DWM層先計算出多個小的中間表，然后再拼接成一張DWS的寬表，由于寬和窄的界限不易界定，也可以去掉DWM這一層，只留DWS層，將所有的資料在放在DWS也沒有問題，

4.2.6. DM(Data Mart)

??DM層,資料集市層，也可以稱為資料應用層，基于DW上的基礎資料，整合匯總成分析某一個主題域的報表資料，主要是提供給資料產品和資料分析使用的資料，一般會存放在 ES、PostgreSql、Redis等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供資料分析和資料挖掘使用，比如我們經常說的報表資料，一般就放在這里，