本文轉自下面兩個文章:
洋碼頭技術公眾號的<<洋碼頭數據倉庫實踐>>
隨身雲技術團隊的 <<大數據環境數據倉庫&維度建模>>
在轉載之前, 先說明我認為比較合理的數倉分層:
有關ODS 層:
ODS層存在的意義已經被大量證明, 加上一個ODS層, 在技術層面可以保障業務系統穩定, 同時ODS也是數據團隊和業務團隊的一個天然職責分界.
ODS和業務數據庫的同步最好是使用現成工具, 比如OGG/canal/sqoop/Debezium. 這些工具抽取效率高, 能適應業務數據表的變更, 甚至能做到實時.
如果業務系統只能通過文件的方式導出數據, 推薦使用avro格式(比定長文件或csv文件更高效並易於處理)
如果業務上對於實時性要求很高, 最好將業務直接架在ODS層上.
ODS層可以和DW是同一類數據庫, 也可以是異構數據庫.
放在同一類數據庫的好處是: DW和ODS交互將非常簡單, 會節省很多ETL工作量, 如果是異構數據庫的話, DW抽取ODS數據就不那么方便了. 這里可以再深入分析一下, 因為業務數據庫是OLTP庫, OGG/canal要求同步的目標庫也是OLTP, 而DW往往是用OLAP庫.
如果我們是使用Oracle來架構小型DW, 通過OGG可以很容易將ODS和DW放在一起, 否則DW和ODS一定是異構. 還有一個思路可以將ODS層也放進OLAP庫, 方法是引入Cassandra, 將OGG結果發布到Cassandra上, 然后采用mini batch方式消費到數倉中. 網上更多的是引入 Kafka 而不是 Cassandra, 個人認為使用Cassandra要比Kafka更合適, 因為 數倉涉及的數據, 都是結構化的數據, Cassandra的吞吐能力也很不錯, Cassandra 的查詢和數據消費比 kafka 方便多了.
有關DWD層:
實時表應該是原始粒度的，即存放各主題域的最細粒度數據。
有關DM層:
一般地DM層內的數據多用於報表, 數據一般是大寬表, 揉合了多個度量值, 在粒度上也已經降維處理.
有關APP層:
DM層多用於報表展現, APP層多是將數據回饋給其他分析系統使用, 比如提供用戶畫像數據.
文章1: 洋碼頭數據倉庫實踐
作者介紹
孔永兵, 洋碼頭高級數據倉庫工程師
長期從事數據倉庫相關工作，有豐富的數據庫開發、設計、性能調優及倉庫架構經驗，目前負責洋碼頭數據倉庫架構設計及BI事務。
| 隨着洋碼頭公司業務的快速發展，需要分析和處理的數據更加多元化和復雜化，原有傳統關系型數據架構已很難滿足公司各業務方面的需求。數據倉庫的建立將洋碼頭業務按不同的主題進行維度建模，實現數據快速讀取、及時響應，同時也為產品、運營及數據分析人員提供了更加方便快捷的數據提取平台。本文對洋碼頭數據倉庫從無到有的過程做個大體介紹。 |
本文約2400字，可參閱下面的大綱閱讀。
1. 洋碼頭數據倉庫的三個階段
2. 洋碼頭數據倉庫技術架構
2.1 架構
2.2 維度建模
3. 遇到過的問題
3.1 代理鍵的使用
3.2 遲到維度的處理
3.3 緩慢變化維的處理
4. 參考書籍
1. 洋碼頭數據倉庫的三個階段
洋碼頭數據倉庫的發展經歷了從簡單報表階段、數據集市階段再到數據倉庫階段的過程。
-
簡單報表階段, 在此階段，系統的主要目標是解決一些業務運營人員的日常報表展現，以及生成一些簡單的能夠幫助領導進行決策所需要的匯總數據，靈活性差，性能低。
-
數據集市階段, 在數據倉庫建立之前，根據特定部門業務人員的需要，進行指標整理、清洗、轉換，進行多維報表的展現，為特定業務提供數據支持及決策。
-
數據倉庫階段, 按照業務主題進行划分，使用kimball經典的維度建模方法，經過指標清洗、轉換，構建成一致性維度及事實表，提供跨部門的，完全一致的業務報表數據。數據倉庫建好以后，數據提取效率有了質的提升，與前端報表工具整合更加容易。
2. 洋碼頭數據倉庫技術架構
2.1 架構
圖1 - 架構圖
如上圖所示，洋碼頭數據倉庫由數據源, 數據整合, 數據存儲, 數據展現&分析,及ETL調度等幾個模塊構成。
2.1.1 數據源
洋碼頭的業務數據來源於SQL Server、MySQL、MongoDB，包含了用戶、買手、商品、優惠券、活動、訂單、物流等碼頭核心業務數據。
用戶行為數據來源於前端埋點生成的各種訪問、點擊事件，通過用戶行為數據來分析app頁面模塊的粘性、活躍程度及產出情況。
2.1.2 數據整合
數據整合層將數據源中數據通過ETL框架平台經清洗，整合及轉換后存儲到數據存儲層，在數據抽取轉換過程中，根據不同的業務采取不同的調度頻度。
2.1.3 數據存儲
數據存儲層又可分為ODS層、DW層及DataMart層。
-
ODS層用於存儲自源系統抽取過來並經過清洗后的數據，由於該層是准實時的數據，大部分准實時的報表數據都來源於ODS層。
-
DW層是采用kimball的總線式數據倉庫架構，針對各主題進行維度建模后構建的一致性維度及事實表，DW層的粒度是原子的，即存放各主題域的最細粒度數據。洋碼頭目前分布的幾個重要的主題有用戶、買手、商品、優惠券、活動、訂單、物流。
-
DataMart層存放經由DW層數據經過一定的加工、匯總聚合而成的寬表，如用戶畫像、買手經營能力指標、買手DSR指標、商品動銷數據、物流監控等。
2.1.4 數據展現
報表展現及數據指標監控，為運營人員提供運營效果展現及運營決策支持，為管理層提供決策依據。數據分析及數據挖掘，為特定主題中主體進行價值分層，如用戶價值分層。
2.1.5 ETL調度
在ETL調度中，根據不同的業務需求配置不同調度，如從數據源到ODS的並行抽取調度，及DW中根據各主題域按順序依賴進行調度。在調度中詳細記錄每個任務的開始、結束時間，狀態，新增記錄數，更新記錄數，錯誤日記及遇到錯誤是及時報警。
圖2 - ETL日記
2.2 維度建模
2.2.1 模型選擇：星型vs雪花型
在維度建模過程中，根據事實表和維度表的關系，可將常見的模型分為星型模型和雪花型模型。在設計邏輯數據模型的時候，應考慮數據是按照星型模型還是雪花型模型進行組織。
星型架構是一種非正規化的結構，多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一定的冗余。 也正因為這種冗余，很多統計查詢不需要做外部的連接所以一般情況下效率比雪花型要高。
雪花模型是對星型模型的擴展。它對星型模型的維表進一步層次化，原有的各維表可能被擴展為小的事實表，形成一些局部的 " 層次 " 區域，這些被分解的表都連接到主維度表而不是事實表。
在洋碼頭數據倉庫建設中，兩種模型都有用到，但用的最多的是星型模型，這樣不只是查詢效率更高，對於不甚了解業務的新員工，相對雪花模型，能夠快速、較好地操縱模型。
圖3 - 星型模型
圖4 - 雪花型模型
2.2.2 邏輯設計
維度模型的邏輯設計是由四個主要決策所驅動的。
1) 選擇業務過程
第一步是選擇要建模的業務過程，業務過程是維度數據倉庫的基石，每個業務過程至少會產生一個事實表。以訂單業務為例，確定訂單業務后，首先要對訂單數據進行初探，了解該業務中有哪些數據產生及產生該數據時是否關聯其他業務。
2) 聲明粒度
聲明粒度也可以理解為聲明主鍵，選擇粒度時既要考慮到用什么來滿足業務需求，又要考慮基於源系統收集的數據可以得到什么。數據倉庫中建議存放最細粒度的數據，以訂單業務為例，訂單業務將會產生兩個事實表，基於訂單號粒度及訂單號加商品規格粒度。
3) 確定維度
當確定好粒度后，大多主要維度也就很自然的產生了，以訂單為例，粒度確定好了，對應的維度：用戶、買手、商品、活動、優惠券等都已確定。
4) 確定事實
確定事實也叫確定度量，大多數面向事務的業務過程只有少量的基礎事實，如數量和金額，但是卻有很多從這些基礎事實導出的組合和計算結果，以訂單為例，有訂單金額、商品數量、商品單價、商品金額、優惠券金額、實付金額等許多度量值。
圖5 - 維度建模
3. 遇到過的問題
1) 代理鍵的使用
是否要使用代理鍵？這是維度建模過程中經常遇到的問題。
-
如果數據倉庫數據來源於不同的系統，且各系統之間的主體需要合並以達到企業一致性維度時，需要使用代理鍵。
-
如果數據倉庫維度表涉及到緩慢變化維，需要跟蹤到歷史數據，需要使用代理鍵。
-
如果數據倉庫中業務鍵是字符類型(如Guid)，做關聯查詢時效率非常低，建議使用代理鍵。
洋碼頭數據倉庫在維度建模過程中主要針對后兩種情況來生成代理鍵。
2) 遲到維度的處理
數據倉庫的重要特點之一就是一致性維度，由於洋碼頭數據倉庫在建設過程中使用了代理建，導致有時候某些維度(如優惠券、商品)可能有比事實記錄晚到的情況。此時需要在維度表中建立一條“未知”的維度記錄，對於遲到的維度，都將該“未知”維度的代理鍵做為相關事實表的外鍵。等遲到的維度到來后，再將建立好的維度的代理鍵更新到相關的事實表中。
圖6 - 遲到維度處理
3) 緩慢變化維的處理
在洋碼頭數據倉庫維度建模過程中，針對需要根據時間追蹤歷史數據的維度，使用Type2-添加一個新的維度行的方式來處理，如下例，員工金波2015/4/8前居住在廣州，之后搬到上海，按照覆蓋原值的方式，金波的現居地為上海，按區域統計數據時他所有的銷售數據都會歸到上海。現將用戶維度做成緩慢變化維，在統計金波2015/4/8之前銷售的數據時，歸屬地為廣州，以此達到追蹤歷史的目的，該方法同樣可以用在拉鏈表的設計上。
圖7 - 緩慢變化維處理
文章2: 大數據環境數據倉庫&維度建模
這篇文章是一個ppt, 我截取了主要幾個頁面.
