1.資料倉庫建模目標 資料倉庫建模的目標是通過建模的方法更好的組織、儲存資料，以便在效能、成本、 效率和資料質量之間找到最佳平衡點。 訪問效能：能夠快速查詢所需的資料，減少資料 I/O; 資料成本：減少不必要的資料冗餘，實現計算結果資料複用，降低大資料系統中的資料 成本和計算成本; 使用效率：改善使用者應用體驗，提高使用資料的效率。 資料質量：整合所有資料來源的資料，改善資料統計口徑的不一致性，減少資料計算錯誤 上述的四點之間是存在衝突的，為了提高訪問效能，可能會提高資料冗餘(減少 Join操作)， 這樣會降低計算成本，但是會導致資料儲存成本很高，並且由於資料的冗餘，會提高資料統 計口徑不一致的風險，我們的目的是通過合理的設計在效能、成本、效率和資料質量之間找 到平衡點。 2.維度模型基本概念 維度建模的理論由 Ralph Kimball 提出，他提出將資料倉庫中的表劃分為 事實表和 維度表兩種型別，專門用於分析型資料庫、資料倉庫、資料集市建模的方法。資料集市可以理解為是一種"小型資料倉庫"。 2.1維度表（用來儲存該維的元資料，即維的描述資訊，包括維的層次及成員類別等） 維度表示你要對資料進行分析時所用的一個量,比如你要分析產品銷售情況, 你可以選擇按類別來進行分析,或按區域來分析。這樣的按..分析就構成一個維度。再比如"昨天下午我在星巴克花費200元喝了一杯卡布奇諾"。那麼以消費為主題進行分析，可從這段資訊中提取三個維度：時間維度(昨天下午)，地點維度(星巴克), 商品維度(卡布奇諾)。通常來說維度表資訊比較固定，且資料量小。 2.2事實表（用來儲存事實的度量(measure)及指向各個維的外來鍵值）： 表示對分析主題的度量。事實表包含了與各維度表相關聯的外來鍵，並通過JOIN方式與維度表關聯。事實表的度量通常是數值型別，且記錄數會不斷增加，表規模迅速增長。比如上面的消費例子，它的消費事實表結構示例如下： 消費事實表：Prod_id(引用商品維度表), TimeKey(引用時間維度表), Place_id(引用地點維度表), Unit(銷售量)。 總的說來，在資料倉庫中不需要嚴格遵守規範化設計原則。因為資料倉庫的主導功能就是面向分析，以查詢為主，不涉及資料更新操作。事實表的設計是以能夠正確記錄歷史資訊為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為準則。 3.維度建模流程步驟

• 確認業務過程；
• 確認粒度；
• 確定維度；
• 確定事實；

3.1 確認業務過程 選擇建模的業務過程，比如園區中庫存單元被租賃出去。 3.2 確認粒度 保證粒度為最小粒度，保證以後的可擴充套件性，以及向下鑽去的靈活性。特殊說明，除週期性快照表，其他型別的事實表的時間粒度都保持操作性系統中的時間，即明細到時分秒。 3.3 確認維度 也就是確認業務過程設計到的維度，維度主要用途是回答“what, when, where, how”等這樣的問題。BI應用上，維度主要用來做篩選、分組、鑽取。 由於維度相對資料量較少，在hive中建立的維度表，建議不考慮使用分割槽。 3.3.1 緩慢漸變維 資料倉庫需要追蹤歷史，因此部分維度需要採用緩慢漸變的方式，計劃採用如下方式： 在維度表上增加起始日期(begin_date)與結束日期(end_date)，以及當前狀態（current_status） 3.3.2 維度一致性 在確認最小粒度之後，維度表儘量一次建成以後，後續可重複使用，如此可以保證維度的一致性。 3.4 確認事實 確認需要衡量的事實，例如進出園區人數，次數；園區租賃金額等。 •事務型事實表：主要用來捕捉特定維度範圍內，會經常發生的一系列基本無序的事件。 •週期型快照事實表：按照一定時間粒度（day/month），儲存特定維度範圍內的效能度量。例如，每日進出園區的人數。 •累積快照事實表：用來捕捉一系列有序的事件，在不同時間範階段內效能度量。例如，CRM系統中有lead(潛在意向客戶)->deal(簽約中的客戶) -> lease(發生租賃的客戶)，這樣一系列的流程可以考慮使用累積快照事實表。 4.維度建模三種模式 4.1 星型模式 星形模式(Star Schema)是最常用的維度建模方式。星型模式是以事實表為中心，所有的維度表直接連線在事實表上，像星星一樣。 星形模式的維度建模由一個事實表和一組維表成，且具有以下特點： a. 維表只和事實表關聯，維表之間沒有關聯； b. 每個維表主鍵為單列，且該主鍵放置在事實表中，作為兩邊連線的外來鍵； c. 以事實表為核心，維表圍繞核心呈星形分佈； 4.2 雪花模式 雪花模式(Snowflake Schema)是對星形模式的擴充套件。雪花模式的維度表可以擁有其他維度表的，雖然這種模型相比星型更規範一些，但是由於這種模型不太容易理解，維護成本比較高，而且效能方面需要關聯多層維表，效能也比星型模型要低。所以一般不是很常用。 4.3 星座模式 星座模式是星型模式延伸而來，星型模式是基於一張事實表的，而星座模式是基於多張事實表的，而且共享維度資訊。 前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。 5.維度建模例項 5.1 背景 某電商平臺，經常需要對訂單進行分析，以某寶的購物訂單為例，以維度建模的方式設計該模型。 5.2 事實表與維度表的劃分 事實表為訂單表、子訂單表，維度包括商品維度、使用者維度、商家維度、區域維度、時間維度。 5.3 事實表分析 訂單中包含的度量:商品件數、總金額、總減免金額; 描述性屬性:下單時間、付款時間、訂單狀態等; 子訂單包含度量:商品 ID、單價、減免金額; 描述性屬性:加入購物車時間、下單時間、付款時間、狀態; 5.4 維度表分析 商品維度:商品 ID、商品名稱、商品品類、單價、顏色、尺寸、生產商等; 使用者維度:使用者 ID、姓名、性別、生日、職業、信用值、收貨地址等; 時間維度:日期 ID、日期、周幾、是否週末、是否假期等; 區域維度:區域 ID，縣/區、縣/區 ID、市、市 ID、省、省 ID; 訂單表和子訂單表是兩張事實表，我們往往會避免事實表之間產生關係，因此會考慮讓子訂單表中有一定的資料冗餘，比如訂單表和訂單明細表都各自記錄著使用者 ID，區域 ID，時間 ID 等，這樣在查詢子訂單資訊時，就不用通過關聯訂單表來獲取上述資料了，但是子訂單表中仍會儲存訂單 ID 欄位。