數據倉庫模型全景

數據倉庫模型構建

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

與數據庫的單表基於 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 辦理費用等），項目表即是一個招標流程表，該表會記錄關於招標過程中的，招標、投標、開標、評標、定標相關的數據：

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

二、邏輯模型設計

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

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

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

三、物理模型設計

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

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

數據倉庫的產品

前面講了數據倉庫的價值、構建思路、實例，完成數據倉庫的概念、邏輯、物理模型設計後，數倉的產品選型也是需要考慮的部分，根據數據存儲量、查詢效率、併發能力可以選用 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 份數據。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XvgHtPFH4SJvotzJkKCZQQ

猜你喜歡