本文主要討論數據倉庫的構建方法論，包括數據倉庫的價值、選型、構建思路。隨著數據規模膨脹和業務復雜度的提升，大型企業需要構建企業級的數據倉庫（數據湖）來快速支撐業務的數據化需求，與傳統的數據庫構建不通，數據倉庫即是OLAP場景，偏于歷史數據的存儲/分析，用冗余存儲換取數據價值。

01 數據倉庫與數據庫的區別

所有的應用系統都會涉及到數據庫，針對數據庫歸納和存放，也就是數據庫的常見操作：增、刪、改、查，那么為什么想要對企業數據進行分析，不能直接查詢數據庫，非要大費力氣的去創建所謂的數據倉庫和數據湖呢？

數據倉庫主要是為了能夠支持管理決策，而數據庫是為了滿足系統的及時性、一致性。

好比你去銀行存錢，你希望剛把錢存進去就能夠查詢到余額增加，你不希望第二天才能夠確認，但是若是銀行想對你的流水和余額進行分析，這個時候希望知道你在不同時期的銀行余額，那么從數據庫里是查不到你的歷史余額信息的，因為數據庫在設計的時候就需要滿足一定的范式，為的就是滿足及時性和去冗余，一個客戶對應的余額只有一個，你在存款的時候，新的余額就會覆蓋掉老的余額，所以你的歷史信息在數據庫中是沒有記錄的。

如果銀行希望查詢客戶的歷史信息，比如說你需要查詢個人客戶信息，他可能在柜臺交易系統中有記錄，也可以在網上銀行交易系統也有記錄，而你希望查詢客戶柜臺交易信息以及網銀交易信息，這個時候需要跨系統查詢，有可能兩個系統所使用的數據庫都不一樣，各自權限負責人員也不一樣，跨系統查詢顯得非常困難，這個時候需要一個系統能夠將所有業務系統的數據匯總起來并能夠跨系統查詢，這個時候數據倉庫定義中的集成的，反映歷史變化的正好解決了此問題，數據庫和數據倉庫的對比。

其中OLTP（On-Line Transaction Processing）指的是傳統的關系型數據庫，針對實時業務處理，面對的主要操作是隨機讀寫，采用滿足三范式的實體關系模型存儲數據，從而在事務處理中解決數據的冗余和一致性問題。

而OLAP（On-Line Analytical Processing）系統面向數據批量讀寫，OLAP不關注事務處理的一致性，主要在數據的整合，以及復雜大數據查詢和處理性能，OLAP能夠支持復雜的分析操作。

綜上， 數據庫的設計是為了完成交易而設計的，不是為了而查詢和分析的便利設計的。而數據倉庫是為了大量的查詢和分析所設計的。

02 數據倉庫對于企業的價值

數據倉庫能實現跨業務條線、跨系統的數據整合，為管理分析和業務決策提供統一的數據支持，從根本上把運營數據轉化成為高價值的可以獲取的信息（或知識），并且在恰當的時候通過恰當的方式把恰當的信息傳遞給恰當的人。

數據倉庫定義：面向主題的（Subject Oriented）、集成的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合；

面向主題：是指用戶使用數據倉庫進行決策時所關心的重點方面，如：收入、客戶、銷售渠道等；所謂面向主題，是指數據倉庫內的信息是按主題進行組織的，而不是像業務支撐系統那樣是按照業務功能進行組織的。

集成的：是指數據倉庫中的信息不是從各個業務系統中簡單抽取出來的，而是經過一系列加工、整理和匯總的過程，因此數據倉庫中的信息是關于整個企業的一致的全局信息。

反映歷史變化：數據倉庫內的信息并不只是反映企業當前的狀態，而是記錄了從過去某一時點到當前各個階段的信息。通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。

如下圖，數據倉庫并非是面向生產的數據系統，而是集成并加工了多個數據庫系統數據，并面向各個業務條線構建的數據存儲體系，能夠提供快速的運營/決策支撐能力。

高級管理進行業務分析和績效考核的數據整合、分析和展現的工具。

主要用于歷史性、綜合性和深層次數據分析。

數據來源是ERP系統或其他業務系統。

能夠提供靈活、直觀、簡潔和易于操作的多維查詢分析。

不是日常交易操作系統，不能直接產生交易數據。

數據倉庫系統能夠為企業的數據化提供：

03 數據倉庫的模型構建

一、數據倉庫構建需要考慮的問題

與數據庫的單表基于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）和面向指標和報表的高度匯總層。

04 案例：招標采購系統的數據倉庫構建

按照數據倉庫的構建思路，順序是概念模型-->邏輯模型-->物理模型，最重要和復雜度較高的是概念模型的設計，需要結合業務，并根據業務特性設計事實表、維度表、頂層數據匯總表。

一、概念模型設計

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

招標：招標流程是招標人發起的，招標人將招標過程委托給代理機構，代理機構會發布招標公告，投標人在報名、響應階段產生數據，響應后需要付投標保證金。

投標：投標人給代理機構繳納標書費并下載招標文件，開標之前需要響應，并繳納投標保證金；發售招標文件和投標人購買標書后，如果投標人對招標文件提出質疑，或招標人要修改招標文件，此時要在規定時間內發布一個澄清公告。

開標：開標一般是線下進行，代理機構把投標人召集到開標室，公開宣讀投標人關于投標人報價、工期、質量、工程項目經理等投標人有實質要求的內容，此階段拆封投標文件，解密電子的投標文件。

評標：評標一般是線下進行，代理機構把監督人、投標人、專家召集到評標室，專家對投標人資質及投標書打分，分為技術、商務、報價分。

定標：專家對投標人綜合打分后，做一個總體排名，排名第1即為中標候選人，評標結束后需要發布預中標公告，將前3名公布，公告期間接受社會監督，期間產生的疑問、質疑需要代理機構/招標人澄清，澄清伴隨著澄清公告，若質疑生效則可能廢標和流標（評標成本高，一般不廢標）。

合同：若預中標發布后，質疑期間對于預中標候選人無影響，在預中標發布xxx天后，招標人需要同中標候選人簽訂合同，同時招標人需要退還其他沒有中標單位的保證金。

對于整個流程的梳理和業務了解后，客戶更加關注流程的監管預警，以此為準整理一些監管維度。

二、邏輯模型設計

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

數據表命名規范：tb_模型層次_主題域_業務域_匯總粒度

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

三、物理模型設計

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

在項目流程表中（定標流程），將招標人的編號設計在內，定標流程的統計項從該類ADS匯總維度出結果。

05 數據倉庫產品

前面講了數據倉庫的價值、構建思路、實例，完成數據倉庫的概念、邏輯、物理模型設計后，數倉的產品選型也是需要考慮的部分，根據數據存儲量、查詢效率、并發能力可以選用MPP數倉和基于Hadoop的分布式數倉等。

一、MPP還是Hadoop？

這里繼續用之前用到的圖講解，數據倉庫的特性是處理溫數據和冷數據，面向業務分析提供偏于離線分析能力，因此一般選用Hadoop+MPP數倉結合的解決方法，Hive能夠提供大批量歷史數據的存儲計算能力，Hbase能夠提供半結構化文檔的快速檢索能力，MPP能夠提供強大高壓縮比基礎上的快速查詢能力。

二、MPP數倉特性

在MPP解決方案中目前我已接觸過的是vertica和GP，在teradata實習期間沒有用到td數倉。

數倉的特性是大批量的查詢和索引，少量的改查工作，MPP (Massively Parallel Processing)，即大規模并行處理數據庫的一般特性。

① 列式存儲意味著高壓縮比、高IO能力、快速查詢能力、智能索引（數據寫入時）。

② shared nothing意味著節點的相互獨立、數據的冗余備份。

③ 分布式存儲/計算、存儲/計算的高擴展性、高安全。

MPP的架構分為3種，GP是master/slave模式，具備統一的查詢入口（master），vertica是無中心架構，所有節點都提供查詢服務，gbase是存儲/管理雙中心架構。

shared nothing 模式：x86機器構建計算/存儲的高擴展集群，數據拆分多份并備份。shared disk 模式：專用小型機，存儲1份數據。

<END>