資料倉儲模型構建

一、資料倉儲構建需要考慮的問題

與資料庫的單表基於ER模型構建思路不同，其面向特定業務分析的特性，決定了它的構建需要整合多套資料輸入系統，並輸出多業務條線的、整合的資料服務能力，需要考慮更全面的因素，包括：

業務需求：從瞭解業務需求著手分析業務特點和業務期望;
系統架構：從系統架構和資料分佈、資料特性等角度，分析系統架構設計上是否有問題;
邏輯設計：從資料模型邏輯設計出發是否設計合理，是否符合資料庫開發和設計規範等;
物理設計：從庫表型別、庫表分割槽、索引、主鍵設計等維度，主要針對效能，可擴充套件性進行物理模型設計審查

二、什麼是數倉的資料模型

資料倉儲模型構建的宗旨能夠直觀地表達業務邏輯，能夠使用實體、屬性及其關係對企業運營和邏輯規則進行統一的定義、編碼和命名，是業務人員和開發人員之間溝通的一套語言，資料倉儲資料模型的作用：

統一企業的資料檢視;
定義業務部門對於資料資訊的需求;
構建資料倉儲原子層的基礎;
支援資料倉儲的發展規劃;
初始化業務資料的歸屬;

常用資料模型的是關係模型和維度模型，關係模型從全企業的高度設計一個3NF模型的方法，用實體加關係描述的資料模型描述企業業務架構，在正規化理論上符合3NF，其站在企業角度進行面向主題的抽象，而不是針對某個具體業務流程的，它更多是面向資料的整合和一致性治理;

維度建模以分析決策的需求為出發點構建模型，直接面向業務，典型的代表是我們比較熟知的星形模型，以及在一些特殊場景下適用的雪花模型，大多資料倉儲均會採用維度模型建模;

維度建模中的事實表客觀反應整個業務的流程，比如一次購買行為我們就可以理解為是一個事實，訂單表就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄，訂單表存放一些維度表中的主鍵集合，這些ID分別能對應到維度表中的一條記錄，使用者表、商家表、時間表這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的資料資訊：

如果是採用ER模型，需要設計出一個大寬表，將訂單-商家-地址-時間等資訊囊括在內，比較直觀、細粒度，但也存在設計冗餘，如果資料量很大，對於查詢和檢索將是一個災難;

三、如何構建數倉的資料模型

概念模型設計(業務模型)：界定系統邊界;確定主要的主題域及其內容;邏輯模型設計：維度建模方法(事實表、維度表);以星型和雪花型來組織資料;物理模型設計：將資料倉儲的邏輯模型物理化到資料庫的過程;

1、概念模型設計

資料倉儲中資料模型設計順序如上，資料倉儲是為了輔助決策的，與業務流程(Business Process)息息相關，資料模型的首要任務便是選擇業務流程，為資料倉儲的建立提供指導方向，這樣才能反過來為業務提供更好的決策資料支撐，讓資料倉儲價值的最大化，對於每個業務流程，都需要進行獨立的資料建模，將業務系統中的 ER 模型轉化為資料倉儲中的維度資料模型，以便更好的查詢與分析。

2、邏輯模型設計

事實表一般由兩部分組成，維度(Dimension)和度量(Measurement)，事實表可以通俗的理解為「什麼人在什麼時間做了什麼事」的事實記錄或者場景上下文，擁有最大的資料量，它是業務流程的核心體現，比如電商場景中的訂單表，其主鍵為一個聯合主鍵，由各個維度的外來鍵組成，外來鍵不能為空值，事實表一般不包含非數字型別欄位，雖然資料量大，但佔用的空間並不大，保證更高的查詢效率。

維度表用於對事實表的補充說明，描述和還原事實發生時的場景，如電商訂單中定義使用者、商品、地址、時間、促銷5個維度，透過這5個維度還原訂單發生時的場景，什麼人在什麼時間在什麼地方購買了什麼商品，以及購買該商品的促銷方式。對於每一個維度而言，都有若干個屬性來描述，比如使用者有性別、年齡、所在地等資訊。這些維度的屬性就是之後資料統計的依據，比如我們可以統計不同性別，不同年齡，不同地區在訂單中的差異，從向使用者制定更精細的營銷策略。

在關係型資料庫三正規化(3NF)設計極力避免資料的冗餘，達到資料的高度一致性，但在資料倉儲中3NF並不是最佳實踐，反而讓系統複雜不已，不利於理解和維護，所以在維度建模中，維度表一般採取反正規化的設計，在一張維度表中扁平化儲存維度的屬性，儘量避免使用外來鍵。

3、物理模型設計

在完成資料倉儲的概念模型和邏輯模型設計之後，物理模型設計就是落地實施環節，根據資料的粒度和對於業務支撐能力將資料進行分層儲存，資料分層儲存簡化了資料清洗的過程，每一層的邏輯變得更加簡單和易於理解，當發生錯誤或規則變化時，只需要進行區域性調整;

ODS層：全稱是Operational Data Store,又叫資料準備層，資料來源層，主要用於原始資料在資料倉儲的落地，這些資料邏輯關係都與原始資料保持一致，在源資料裝入這一層時，要進行諸如業務欄位提取或去掉不用欄位，髒資料處理等等。可以理解為是關係層的基礎資料;

DIM層：Dimension層，主要存放公共的資訊資料，如國家程式碼和國家名，地理位置等資訊就存在DIM層表中，對外開放，用於DWD，DWS和APP層的資料維度關聯。

DWD層：全稱是Data Warehouse Detail，用於源系統資料在資料倉儲中的永久儲存，用以支撐DWS層和DM層無法覆蓋的需求，該層的資料模型主要解決一些資料質量問題和資料的完整度問題，比如商場的會員資訊來與不同表，某些會員的的和資料可能不完整等等問題;

DWS層：全稱是Data Warehouse Service，主要包含兩類彙總表：一是細粒度寬表，二是粗粒度彙總表，按照商場訂單例子，包含基於訂單、會員、商品、店鋪等實體的細粒度寬表和基於維度組合(會員日進場彙總、會員消費彙總、商場銷售日彙總、店鋪銷售日彙總等)的粗粒度彙總表。這層是對外開放的，用以支撐絕大部分的業務需求，彙總層是為了簡化源系統複雜的邏輯關係以及質量問題等，這層是的業務結構容易理解，dws層的彙總資料目標是能滿足80%的業務計算。

其上根據業務需求可以繼續構建ADS層(Application Data Store)和麵向指標和報表的高度彙總層。

案例解讀： 招標採購業務的資料倉儲模型構建

按照資料倉儲的構建思路，順序是概念模型-->邏輯模型-->物理模型，最重要和複雜度較高的是概念模型的設計，需要結合業務，並根據業務特性設計事實表、維度表、頂層資料彙總表;

一、概念模型設計

概念模型需要結合生產系統的ER關係模型，梳理業務邏輯，當前生產交易系統使用的是ORACLE資料庫，將資料分成多個庫：業務庫(包含招標採購專案流程)、主體+組織庫(招標人、投標人、評標專家、代理機構)、財務庫(標書費、平臺服務費、招標保證金、CA辦理費用等)，專案表即是一個招標流程表，該表會記錄關於招標過程中的，招標、投標、開標、評標、定標相關的資料：

招標：招標流程是招標人發起的，招標人將招標過程委託給代理機構，代理機構會發布招標公告，投標人在報名、響應階段產生資料，響應後需要付投標保證金;
投標：投標人給代理機構繳納標書費並下載招標檔案，開標之前需要響應，並繳納投標保證金;發售招標檔案和投標人購買標書後，如果投標人對招標檔案提出質疑，或招標人要修改招標檔案，此時要在規定時間內釋出一個澄清公告。
開標：開標一般是線下進行，代理機構把投標人召集到開標室，公開宣讀投標人關於投標人報價、工期、質量、工程專案經理等投標人有實質要求的內容，此階段拆封投標檔案，解密電子的投標檔案;
評標：評標一般是線下進行，代理機構把監督人、投標人、專家召集到評標室，專家對投標人資質及投標書打分，分為技術、商務、報價分;
定標：專家對投標人綜合打分後，做一個總體排名，排名第1即為中標候選人，評標結束後需要釋出預中標公告，將前3名公佈，公告期間接受社會監督，期間產生的疑問、質疑需要代理機構/招標人澄清，澄清伴隨著澄清公告，若質疑生效則可能廢標和流標(評標成本高，一般不廢標);
合同：若預中標釋出後，質疑期間對於預中標候選人無影響，在預中標釋出xxx天后，招標人需要同中標候選人簽訂合同，同時招標人需要退還其他沒有中標單位的保證金;

對於整個流程的梳理和業務瞭解後，客戶更加關注流程的監管預警，以此為準整理一些監管維度：

二、邏輯模型設計

邏輯模型採用上一篇博文提及的維度建模模型，雪花模型，專案ID、投標人ID、招標人ID、代理機構ID、專家ID分別是整個招、投、開、評、定標流程的主要參與主體，資料抽取工具使用kettle：

資料表命名規範：tb_模型層次_主題域_業務域_彙總粒度

kettle命名規範：kt_模型層次_主題域_業務域_彙總粒度

三、物理模型設計

構建ODS-->DWD-->DWS-->ADS的分層模型，這裡ODS只抽取oracle庫中源資料，不做任何清洗和變動，DWD層開始做資料的清洗和資料工程，DWS作輕度彙總，ADS面向應用查詢提供更上層的彙總;以專案和供應商的彙總維度為例，專案流程是模型設計主體，供應商是類似維度表的資料，兩者結合能夠得到業務需要的一些投/中標相關的彙總維度(比如中標率排行、某個專案的投標人的註冊金額相關統計、某投標人參與投標相關統計等)：