數據倉庫的哪些事兒

數據倉庫

大數據平臺

簡介

通常說的大數據平臺主要包括三部分：

1. 數據相關的工具、產品和技術：

• 批量數據採集傳輸sqoop，spark
• 離線數據處理Hadoop，Hive，Spark
• 實時流處理Storm，Spark Streaming，Flink

1. 數據資產：

• 公司業務本身產生和沉澱的數據
• 公司運作產生的數據（如財務、行政）
• 第三方數據：外界購買、交換或者爬蟲而來的數據

1. 數據管理：有了工具和數據，需要進行管理才能讓數據價值最大和風險最小

• 相關數據管理技術和概念：數據倉庫、數據建模、數據質量、數據規範、數據安全和元數據管理

離線平臺

• 對分析需求最擅長，也是最成熟的，使用最廣泛的。
• 開源的解決方案和商業性的解決方案很多
• 是構建公司和企業數據平臺的根本和基礎
• 也是目前數據平臺的主戰場

離線數據平臺架構

離線數據平臺架構

• 在大數據出現之前，離線數據平臺就是數據倉庫，數據部門也就是數據倉庫部門
• hadoop出現之前，數據倉庫的主要技術是商業化數據，比如微軟的SQL Server、甲骨文
  Oracle、IBM的DB2等
• 隨着數據量的爆炸性增長，Hadoop的MapReduce，Spark，Hive等大數據技術被應用到
  數據倉庫中。
• 離線數據平臺另一關鍵技術是數據的建模：維度表 事實表
• 離線數據內容建設會對精心加工後的數據進行分層：

1. ODS原始數據層
2. DWD明細數據層
3. DWS彙總層
4. ADS集市數據層

數據倉庫技術 -OLTP&OLAP

• OLTP：(online transaction Processing)：

1. OLTP數據庫，如商業性的Oracle、MS SQL Server和開源的MySQL等關係數據庫
2. 主要用於事務處理：增刪改查
3. OLTP核心需求：單條記錄的高效快速處理，索引技術、分庫分表

• OLAP：

1. OLAP數據庫，專門的分析型數據庫，是爲了滿足分析人員的統計分析需求而發展起來的
2. OLAP一般只需要處理數據查詢請求，數據都是批量導入的，因此通過列存儲、列壓縮和
   位圖索引等技術可以大大加快響應請求速度

OLTP&OLAP對比

• 需求上不同：

1. OLTP側重單條數據的處理效率
2. OLAP側重數據分析，需要訪問大量的數據，單條數據分析沒有意義

• 資源和性能上：

1. 分析上需要頻繁的統計和查詢，統計需要全表掃描，會大量佔用數據庫的資源，嚴重影響
   線上的OLTP的性能，所以需要單獨爲分析建立OLAP的分析型的數據庫。
2. OLTP的分佈式爲了解決海量單條數據請求壓力，將所有用戶請求均勻分佈到每個節點上
3. OLAP的分佈式爲了將用戶單次對大數據集的請求任務分配到各個節點上獨立計算然後再進
   行彙總返回（map reduce原理）

OLTP和OLAP數據庫簡單對比

對比項	OLTP	OLAP
用戶	操作人員、一線管理人員	分析決策人員、高級管理人員
功能	日常操作	分析決策
讀寫	一般讀寫數條記錄	一次讀取大量記錄
用戶數	面向外部的用戶數上億都可能、面向	一般面向內部，幾十個抑或上千個，
內部系統	用戶數一般有限	取決於公司規模大小
DB大小	一般不存儲歷史數據，MB、GB	包含歷史數據，GB、TB、PB級別
響應時間	毫秒級 秒、	分鐘甚至小時
DB設計	面向應用	面向主題
事務支持	必須支持	沒必要，不支持
數據	當前應用的，最新的數據	歷史的、聚集的、多維、集成、統一的數據

分析型數據庫

• 專門分析型數據庫出現標誌着數據倉庫由學術（概念階段）進入工業階段
• 商業性的MPP（分佈式的分析型數據庫）和類MPP架構應運而生：
  Orcale Exadata、天睿公司的Teradata、IBM收購的Netezza、EMC公司的Greenplum、惠普的HP

Vertica等
通過一站式解決方案和產品“一體機”運營： 數據倉庫軟件+配套硬件設施（服務器、存儲設備、高速
網絡交換設備），實現開箱即用。

• OLAP用戶單次請求大量數據的統計分析，OLTP所有用戶單條數據請求：
  OLAP需要列式存儲：列存儲的類型是固定的，可以很容易採用高壓縮比的算法進行壓縮和解壓縮，磁

盤I/O會大大減少，列存儲只需要讀取對應的列，不需用讀取整個表的所有字段進行處理
– OLTP行式存儲：把所有字段都存儲在一起

Hadoop數據倉庫

• Hadoop內在技術決定：容易擴展、成本低廉，這兩點是決定流行的
關鍵，如果大公司使用MPP，會有想當大的開銷。
• 基於Hadoop的數據倉庫的解決方案（Hive）面臨最大的挑戰是數據
查詢的延遲

數據倉庫建模技術

• 三種搭建數據倉庫的方式：

1. 傳統OLTP數據庫中搭建
2. 商業性數據倉庫產品中搭建（MPP架構的Teradata）
3. 基於Hadoop來搭建

• 不管哪種方式都會面臨以下問題：

1. 怎麼組織數據倉庫中的數據？
2. 怎麼組織才能使得數據使用最爲方便和便捷？
3. 怎麼組織才能使得數據倉庫具有良好的可擴展性和可維護性？

兩種數據倉庫的架構

• 在數據倉庫領域有兩個派系：Bill Inmon建模方法論和Ralph Kimball建
模方法論
• Bill Inmon被稱爲“數據倉庫之父”
• Ralph Kimball被稱爲“商業智能之父”
• 兩種觀點誕生以來，圍繞“哪種架構最佳”的爭論一直存在，但一直無
法形成統一的結論
• 供用戶不同的場合、針對不同的應用場景選擇某方法或者採用混合兩者的方法

RalphaKimball建模方法論

• Kimball對數據倉庫的理論與維度設計和建模有關。維度建模將客觀世界分爲：
度量： 主要由業務過程和支持業務的源系統產生的數據，常以數值形式（訂單金額、庫存數量）存在，稱爲事實
上下文：圍繞着事實的大量文本形式存在的上下文，這些上下文通常被直觀
地分割成多個獨立的邏輯塊，維度建模稱之爲維。維描述了度量的5個W（When、Where、What、Who和Why）信息，比如：什麼時間下單、何種方式下單、買的是什麼、客戶是誰。

星形架構

• 維度建模的Kimball數據倉庫通常以星形架構來呈現
• 由於星形緊貼業務過程，非常直觀和符合業務人員的視角，因此被廣泛和大量使用

基於維度的 “總線體系架構 ”

• Kimball對數據倉庫建模理論的第二大貢獻是基於維度的“總線體系架構”。
• 總線體系架構和一致性維度一起保證了多個主題的事實表和維度表能夠最終集成在一起，提供一致
和唯一的口徑給業務人員。
• Kimball維度建模的主題主要以星形架構爲主，主題與主題之間則用一致性維度和企業總線體系架
構保證數據倉庫的一致性。

倉庫體系架構

BillInmon建模方法論

• Bill Inmon是第一個提出來OLAP和數據倉庫概念的人，所以被稱之爲“數據倉庫之父”
• 他認爲：數據倉庫是“在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改
的數據集合”
• 數據倉庫更像是一種過程，對分佈在企業內部各處的業務數據的整合、加工和分析的過程，
而不是一種可以夠買的產品。稱之爲“企業信息化工廠”

企業級數據倉庫體系架構

企業數據倉庫

• Inmon的企業信息化工程包括源頭系統、準備區、ETL、企業數據倉庫、數據集市等，而企業數據倉庫是企業化信息工廠的樞紐。
• 數據集市，所謂“集市”，就是部門級的數據倉庫，Inmon主張從企業數據倉庫中提取所需要的數據，從而保證數據的一致性。
• 不同點：
– 不同於Kimball，Inmon認爲企業數據倉庫應爲原子數據的集成倉庫，應該用第三範式和ER理論而非維度建模的事實表和維度表來建模。
– Inmon認爲先有企業數據倉庫纔可能開始建立部門級的數據集市。
• Inmon也認爲應該用Kimball的維度建模理論來構建數據集市。

數據倉庫建模實踐

• Inmon的方法是一種由上而下（top-down）的數據倉庫建模方法，主張首先要對企業數據倉庫進行總體規劃，並將不同的OLTP數據集中到面向對象主題、集成的、不易失的和時間變化的企業數據倉庫中。數據集市應該是數據倉庫的子集，每個數據集市都是爲獨立部門專門設計的。
• Kimball方法相反，是一種自下向上的（down-top）。Kimball認爲數據倉庫是一系列數據集市的集合，企業可以通過一致性的維度表和“企業總線架構”來遞增式集成各個數據集市，從而構建整個企業的數據倉庫。
• 對比：
– Inmon的方法部署和開發週期較長，但是容易維護而且高度集成。由於互聯網業務變化快，系統一直變，數據一直變，導致可能永遠設計不出一個企業數據倉庫，所以可以先建立數據集市，而後根據業務進展再沉澱出企業數據倉庫。
– Kimball的方法可以迅速響應業務需求，快速構建一個數據倉庫，成效要求快，投資回報快，但是後期集成和維護較爲麻煩。

數據倉庫邏輯架構設計

• 離線數據倉庫通常基於維度建模理論來構建，但是除此之外，離線數據倉庫通常
還會從邏輯上進行分層，這也是業界最佳實踐。分層主要基於以下考慮：
– 隔離性：
• 數據是精心準備、規範、乾淨，方便理解和使用
• 上游業務系統的變動給下游使用的用戶最小化影響
– 性能和可維護性：
• 數據加工和處理都在數據團隊，相同的業務邏輯不用重複執行，減少存儲和計算的開銷
• 分層可以將處理邏輯解耦，方便定位問題和修復
– 規範性：對於公司和團隊，需要有統一的口徑

數據倉庫分層

• ODS層：數據倉庫源頭系統的數據表通常會原封不動地存儲一份，這稱爲ODS（Operation Data Store）層，存儲着歷史增量和全量數據。
• DW層（DWD和DWS層）：數據倉庫明細層DWD和數據倉庫彙總層DWS是數據平臺的主要內容。它們是通過ODS層經過ETL清洗、轉換、加載生成的，基於維度建模理論來構建，通過一致性維度和數據總線來保證各個子主題的維度一致性。
• 應用層（ADS）：應用層主要是各個業務方或者部門基於DWD和DWS建立的數據集市（DM），數據集市是相對於數據倉庫來說的。一般應用層的數據是來源於DW層，原則上是不能訪問ODS層的。對比於DW層，應用層只包含部門或業務方自己關心的明細層和彙總層的數據。

數據分層架構圖

實時數據平臺架構

• 離線數據平臺產出數據的週期一般是天，也就是說，今天看到的是昨天的數據，對於大部分的分
析和“看”數據場景來說，這種T+1的離線數據可以滿足業務分析需求
• 實時數據：
– 業務場景需要馬上看到業務效果，尤其是在業務促銷活動（雙十一大促、618大促）等
– 算法需求：實時數據訓練的算法效果和離線數據訓練的算法效果有着天壤之別，因爲時效性比較好，帶來
的算法效果會更好

實時平臺架構

實時數據平臺

• 實時數據平臺首先要保證數據來源的實時性。數據來源主要分爲兩類：

1. 數據庫：注意業內最佳實踐並不是直接訪問數據庫抽取數據，而是會直接採集數據變更日誌
2. 日誌文件
   • 數據採集工具（Flume）採集binlog事件，產生速度和頻率通常取決於源頭系統。和下游的實時數據處理工具（Storm、Spark、Flink等流計算框架和平臺）處理數據的速度通常是不匹配的。

• 實時數據處理通常還會從某個歷史時間點重啓以及多個實時任務都要使用同一源頭數據的需求，因此通常還會引入消息中間件（消息隊列比如kafka）來作爲緩衝，從而達到實時數據採集和處理適配

實時數據存儲

• 實時數據存儲根據下游數據使用的不同方式通常放在不同的數據存儲內。
• 對於數據在線服務（即數據使用方傳入某業務ID，然後獲取到所有此ID的相關字段），通常放在HBase內
• 對於實時數據大屏，通常放在某關係數據庫（如Mysql）內，有時爲了提高性能並減輕對底層數據庫的壓力，還
會使用緩存數據庫（Redis）等

數據管理

• 對於一個公司和組織來說，僅有數據的技術是不夠的，還必須對數據進行管理。
• 數據管理的範疇很廣，但是具體主要包含以下幾個：
‒ 數據探查
‒ 數據集成
‒ 數據質量
‒ 元數據管理
‒ 數據屏蔽

數據探查

• 數據探查就是對數據本身和關聯關係等進行分析，包括但不限於：

• 需要的數據是否有
• 都有哪些字段
• 字段含義是否規範明確
• 字段的分析和質量如何

• 數據探查常用的分析技術包括：

• 主外鍵
• 字段類型
• 字段長度
• null值佔比
• 枚舉值分佈
• 最小值
• 最大值
• 平均值

數據探查

• 數據探查分爲戰略性和戰術性的。
• 戰略性：是指使用數據之前首先對數據進行輕量級的數據分析，確定其是否可用、數據穩定性
如何，以決定是否可以納入數據平臺使用。這是構建數據平臺的首要任務，不合格的數據源頭
必須儘快剔除。
• 戰術性：是指用技術手段對數據進行詳盡的分析，發現儘可能多的數據質量問題並反饋給業務
人員或者通知源頭系統進行改進。
• 數據探查是構建數據平臺的基礎，好的數據探查工作直接爲後續的數據建模、數據集成和數據
質量等工作提供了指導，也能讓數據平臺團隊對數據做到心中有數。

數據集成

• 數據倉庫的數據集成也叫ETL（抽取：extract、轉換：transform、加載：load）是數據平臺構建的核心，也是數據平臺構建過程最耗時的過程。
• ETL泛指講數據從數據源抽取、經過清洗、轉換、關聯等轉換，並最終按照預先設計的數據模型將數據加載到數據倉庫的過程。
• ETL處理的結果是爲數據使用者提供一個彙總、規範、包含所有相關訂單信息的寬表。（就是select *就能拿到所有想要的數據）
• ETL過程技術上需要解耦任務，這樣會產生大量的執行job，這些需要通過專門的調度和管理，關鍵是設置checkpoint保證出錯時重跑成本低。
• ETL開源工具：Kettle、Talend，Hive，spark

數據質量

• 數據質量問題始終是每個數據相關人員的核心訴求，尤其是數據分析師、數據開發工程師、業務分析接口人
• 這些人經常面臨的問題：“這個數據準確麼？”
• 或者被質疑：
– “這個數據有問題”
– “這個數據肯定是錯誤的”

• 數據的準與不準需要從以下4個方面進行衡量：
– 完整性：是指數據信息是否存在缺失狀況，不完整的數據質量會大大降低
• 數據記錄缺失
• 數據記錄中字段值缺失
– 一致性：指數據是否遵循了統一的規範，是否保持統一的格式
• 數據記錄的規範：IP地址一定是有4個0~255的數據加上“.”組成
• 數據是否合乎邏輯：互聯年齡主要集中在12-60，不可能是負數，也不可能大於1000
– 準確性：指數據記錄的信息是否存在異常或錯誤，是否符合業務的預期
• 與一致性的區別：準確性不只是規則上的不一致，更多的是業務規則的衝突，比如：業務規定某字段值只有（1,0），但是出現了3或者其他字符串
– 及時性：指數據的產生時間是否及時、準時，符合預期。

• 數據從生產到消費有很多環節，每個環節都可能出現數據質量問題，但是對於直接使用數據的人來說，數據開發團隊被視爲數據質量問題的第一責任人，數據開發團隊有義務和責任來解決數據質量問題，推動解決問題。
• 數據質量問題需要藉助系統和工具才能落地，主要監控：
– 數據行數波動
– 主鍵重複
– 字段空值比，空值率
– 枚舉值檢查、枚舉值佔比
– 字段最小值、最大值、均值、數值合計

• 通過這些指標+業務規則監測來衡量是否有數質量問題，如果發現系統報警，需要第一時間
解決和修復。

數據屏蔽

• 數據倉庫存儲了企業所有的數據，其中有些數據是非常敏感的，比如用戶的信用卡信息、身份證、手機號等，這些信息如果泄露會給企業和公司帶來災難性的後果。但如果直接刪除，會對開發測試和分析統計帶來影響。
• 數據屏蔽就是對數據進行脫敏，進行不可逆的處理，既能滿足開發測試和統計分析使用
• 主要方法：
– 替換：用預先準備的測試數據來替換真實的敏感數據
– 洗牌（shuffle）：和替換一直，只是替換的數據集是其本身
– 刪除/加擾：刪除會破壞數據完整性，可以通過“”來替代，150*6789
– 加密：通過加密算法，將原始數據變爲無意義字符，只有應用“密鑰”才能查看原始數據

維度建模技術

維度建模過程

• 維度建模過程順序分爲四個過程：

1. 選取業務過程：針對項目業務活動，不如百度主要業務活動是搜索，維度模型是同部門捆綁在一起的，所以無法避
   免數據不一致的情況，（比如業務編碼、含義），需要從全局考慮。
2. 定義粒度：對事實表實際代表的內容和含義給出明確的說明，粒度傳遞了事實表度量值相聯繫的細節所達到的程度
   的信息。（比如：訂單信息orders表，更細粒度的priors表每個訂單具體的商品信息）粒度定義需要最大程度選擇

業務過程中最爲原子性的粒度，這樣能讓後續處理更加靈活

1. 確定維度：維度是對度量的上下文和環境的描述。（比如用戶的註冊的基本信息，商品的基本屬性信息）
2. 確定事實：通過業務過程可能要分析什麼來確定。比如促銷活動，需要度量的是銷售量和銷售金額

維度表設計

• 維度表示維度建模的靈魂，在維度表設計中碰到的問題直接關係到維度建模的好壞。
• 主要問題：
– 維度變化：維度是緩慢變化的過程
– 維度層次：某個維度表中的屬性之間存在的從屬關係
– 維度一致性：兩個維度如果有關係，要麼相同，要麼是子集。不一致包括表內容和屬性上的不一致。
– 維度整合和拆分：同一個維度來自多個業務系統，需要整合和拆分。
– 維度其他

維度變化

• 維度表的數據通常來自與業務系統，商品是會發生變化的，比如商品的所屬類目、商品價格、商品描述
等。這些變化可能是之前錯誤的修正，或者實際商品更新。這個變化稱爲“緩慢變化維”
• 確定源數據變化在維度表中如何表示非常重要，根據變化內容的不同，下游分析可能要求用不同的辦法
來處理。
– 商品的描述信息變化：也許業務人員不太敏感，可以直接覆蓋
– 商品所屬類目變化：涉及到這個商品的銷售活動是哪個類目的
• 是全部歸到新類目，還是全部歸到舊類目？
• 變化前歸到就類目，還是變化後歸到新類目？

• 緩慢變化維的幾種處理辦法：
– 重新維度值：當一個維度值屬性發生變化時，重寫維度值方法直接用新值覆蓋舊值。在
不需要保留維度屬性歷史變化的情況。
– 插入新的維度行：不維護維度屬性變化，通過插入新的行來保存和記錄變化的情況。保
存了變化前後的歷史數據，但是沒有變化的數據會有冗餘現象。
– 插入新的維度列：下游分析需要用到變化前和變化後的屬性值，有能用變化後的屬性值
來分析變化前的所有事實，這時可以採用插入新的維度列。這樣會導致表結構需要發生
變化，或者提前預留。

維度層次

• 維度層次指的是某個維度表中屬性之間存在的從屬關係問題。比如商品的類目可能是有層次的（一級類
目、二級類目、三級類目等），那麼維度建模如何處理這些層次結構的呢？
• 有兩種處理辦法：
– 將所有維度層次結構去全部扁平化，冗餘存儲到一個表中，星形架構
– 新建類目維度表，並在維度表中維護父子關係，雪花架構
• 在維度建表中一般採用星形架構，雖然犧牲了部分的存儲，但是給用戶使用帶來了便捷，也減低了學習
使用的成本。
• 維度層級結構通常和鑽取練習在一起，所謂鑽取就是對信息的持續深入挖掘。
• 鑽取的實質是增加或者減少維度分爲兩種：
– 向下鑽取：從彙總數據深入到細節數據。比如年度銷售總額增長20%，增加時間維度，分析季度增長率

– 向上鑽取：從細節數據概括到彙總數據。

維度一致性

• 維度設計理論中，數據倉庫是在對多個主題、多個業務過程的多次迭代過程中逐步建立的，邏輯上劃分
迭代過程爲數據集市
– 數據集市一般由一張和多張緊密關聯的事實表以及多個維度表組成，一般是部門或者面向某個特定的主題。
– 數據倉庫則是企業級的、面向主題的、集成的數據集合
• 如果分步建立數據集市的過程中維度表不一致，那麼數據集市就會變成孤立的集市，不能從邏輯上組合
成一個集成的數據倉庫，而一致性就是爲了解決這個問題。
• 維度一致性：兩個維度如果有關係，要麼完全一樣，要麼數據邏輯上是另一個的子集。
– 內容不一致：某種交易上缺失了部分商品，那麼對這些缺失商品的交易分析無法完成。
– 維度不一致：比如日期格式、類目和日組合成一個數據信息、
• 可以採用共享同一個維度表或者讓其中一個維度表示另一個維度表的子集的方式保證一致性。

維度整合 &拆分

• 有時候出現同一個維度表來自於多個前臺業務系統的問題，此時會帶來維度整合和拆分問題。比如：移
動端交易系統和PC端交易系統的系統架構和底層數據庫、表結構等的不同。
• 同一個維度的整個需要考慮以下問題：
– 命名規範：要確保一致和統一
– 字段類型：統一整合爲一個字段類型
– 字段編碼和含義：編碼及含義要整個爲一致的。
• 對於業務系統的不同通常有兩種處理辦法：
– 建立一個基礎的維度表，此基礎維度表包含這些不同業務的共有屬性，同時簡歷各自業務的單獨維度表以包含其獨
特的業務屬性。
– 拆分，即不合並，即各個業務差異獨特性的業務各自建立完全獨立的兩個維度表，各自管理各自維度表和屬性。

• 實際操作中，對於業務差異大的業務，耦合在一起並不能帶來很大的便利和好處，因此通常傾向於拆分（
即不合並），各自管理各自的維度表。對於業務相似度比較大的業務，則可以採用第一種辦法。

深入事實表
• 事實表示維度建模的核心和基本表。事實表存儲了業務過程的各種度量和事實，而這些度量和事實正是
下游數據使用人員關心和分析的對象。
• 事實表的三種主要的類型：
– 事務事實表：記錄業務過程原子粒度的事件，每個事務一條記錄。
– 快照事實表：業務的狀態（當前狀態、歷史狀態），比如商品的庫存，擠壓促銷。
– 累計快照事實表：適用於具有工作流或者流水線形式的業務的分析。比如：漏斗分析（瀏覽、點擊、轉化）

數據倉庫
事務事實表
• 事務事實表記錄業務過程的事件，而且是原子粒度的事件。
• 數據在事務發生後產生，數據的粒度通常是每個事務一條記錄。
• 一旦事務被提交，事實表數據被插入。
• 通過事務事實表存儲單詞業務事件/行爲的細節，以及存儲與事件相關的維度細節，
用戶可以單獨聚合分析業務事件和行爲。

數據倉庫
事務事實表
• 結合超市零售業務以及維度建模的四個環節來說明事務事實表：

1. 選擇業務過程
   • 理解POS系統記錄的顧客購買情況，什麼時候、什麼商品、哪個收銀臺、銷售了哪些商品等
2. 定義粒度
   • 用戶購買行爲體現在一張小票，事務事實選擇最原子粒度的事件，所以小票的子項目（商品）是超市零

售事務事實表的粒度

1. 確定維度
   • 粒度確定後，銷售日期、銷售商品、銷售收銀臺、收銀員、銷售門店等維度就容易被確定下來了。細節

（促銷行爲）

1. 確定事實
   • 確定哪些事實和度量應該在事實表中出現。本例：商品銷售數量、銷售價格、銷售金額等

數據倉庫
快照事實表
• 在實際業務中，除了關心單次的業務事件和行爲外，很多時候還關心業務的狀態（
當前狀態、歷史狀態），比如在商品中對應的是庫存情況。
• 快照事實表，又叫週期快照事實表，指間隔一定的週期對業務的狀態進行一次拍照
並記錄下來的事實表。最常見的例子：銷售庫存，賬戶餘額等
• 對比事務事實表發生纔會記錄，週期快照則必須捕獲當前每個實體的狀態。比如：
某個商品當天沒有售賣，事務事實表不會有記錄，但週期快照需要對其庫存進行定
時記錄。
• 週期快照事實表的週期需要和業務方共同確定，最常見的週期（day、Week、

Month）

數據倉庫
快照事實表
• 以超市的庫存業務啦介紹週期快照事實表的設計過程：

1. 選擇業務過程
   • 業務目的爲了更好理解超市庫存情況，業務過程就是商品庫存情況。什麼時候、什麼商品、哪個倉庫的庫存

量

1. 定義粒度
   • 主要指定庫存的週期。週期爲day的記錄計算：100家連鎖店*10000個商品=100w行記錄/day
2. 確定維度
   • 週期（天、周、月等）、商品、倉庫
3. 確定事實

• 庫存量、增量度量（庫存價值、庫存成本、週期銷售量、去化天數【基於週期內銷售預計需要庫存天數】）

數據倉庫
累計快照事實表
• 累計快照事實表非常適用於具有工作流或者流水線形式業務的分析，這些業務通
常涉及多個時間點或者有主要的里程碑事件，是從全流程角度對業務狀態的拍照
• 以車險舉例：
– 主要事件：客戶報案、保險公司立案、客戶提交理賠材料、理賠審批通過和付款。
– 目標：分析各個理賠的狀態、步驟間的耗時

1. 選擇業務過程：更好的理解保險公司的車險理賠業務，業務過程是車險理賠
2. 定義粒度：某個客戶的保險理賠申請作爲一個記錄
3. 確定維度：快照週期、理賠申請人、受理人、審覈人、網點等
4. 確定事實：索賠金額、審批金額、打款金額、處理時長

數據倉庫構建

業務需求

• 以零售業務爲例，涉及到全國連鎖業務形態、收銀臺購物流程、商品供應鏈、商品庫存管理等。這麼大規模
的零售，運營設計到什麼？
– 整個公司的整體銷售趨勢如何？
– 是否應該對某些滯銷商品進行促銷？
– 客戶是否流失？
– 某些暢銷商品是否應該及時補貨？
– 如何選擇自營商品從而利潤最大化？
• 數據倉庫平臺是以上問題實現數據化運營的前提和基礎。基於數據倉庫平臺生成的各種銷售報表和庫存報表是
公司管理層和各個城市運營人員決策的主要依據。

數據倉庫架構設計

• 數據倉庫在實際設計中，通常出於可維護性、性能成本以及使用便捷性考慮，會對數據倉庫中的表進行分層
• ODS層：源頭數據原封不同存儲一份，是後面DW層（倉庫層）的源數據，ODS層存儲的是歷史增量或者全
量數據
• DW層：
– ODS層經過ETL生成，這一層的數據一定是清洗過的，乾淨的、一致的、規範的、準確的數據。下游用戶直接使用DW層
數據，而ODS層原則上不允許下游用戶直接接觸。
– 明細層：保存最細粒度的事實表和維度表
– 彙總層：設計主要是出於性能以及避免重複計算考慮，如何設計需要根據業務需求以及明細層實際彙總頻率來確定
– 原則上，業務使用頻繁的維度需要對這些數據建立彙總層，彙總的指標可以和業務需求方共同設計完成。
• 應用層：數據來源於DW層，原則上訪問不了ODS層。各個業務方或者部門可以建立自己的數據集市（Data

Mart），只包含部門或者業務方自己關心的明細層和彙總層的數據。一般由下游用戶自己維護和開發。

數據倉庫規範設計

• 對於公司來說，使用數據的用戶成百上千，如何降低大家對於數據使用的溝通成本、如何通過規範大家的行
爲來降低使用數據的風險。需要通過規範來實現。
• 數據倉庫的規範包括很多方面，主要有：
–命名規範
–開發規範
–流程規範
– 安全規範
– 質量規範

命名規範

• 表命名規範：爲了讓數據所有相關方對於表包含的信息有一個共同的認知。比如說屬於哪一層（ODS,DW明
細，DW彙總、應用層）？哪個業務線/部門？哪個維度（商品、賣家、買家、類目）？哪個時間跨度（天、
月、年、實時）？增量還是全量？
• 數據平臺建設者應該首先規定數據倉庫的分層、業務/部門、常見威懾時間跨度的英文縮寫，並根據這個縮寫
來命名。

開發規範

• 開發規範主要用於規範和約束數據開發人員和使用人員的習慣，以最大限度降低數據使用風險，並同時保證
用戶準守最佳實踐。主要包括以下幾個方面：
–數據任務的分類和存放（即目錄結構的劃分）：公共代碼如何存放，個人代碼如何存放，項目和產品的代碼如何分類存
放，實際項目中需要統籌規劃並保證每人都遵守，方便用戶找到對應項目、產品或者各個層次的代碼（ODS、DWD、
DWS、ADS）
– 代碼的編程規範：比如任務註釋的規範必須包含哪幾部分、代碼對其規範、代碼的開發約定等
– 最佳實踐：有些最佳實踐（靈活運用時間分區、timestamp定義到毫秒還是秒、數據類型定義規範多個）都需要開發規
範來約束，以確保最佳實踐得以落地。

流程規範

數據倉庫構建示例 - -商品維度表

• 商品維度表命名dim_fr_item，設計說明：

1. 維度表設計的首要問題是維度表的拆分以及合併問題
   – 主要存放共有屬性
2. 對於緩慢變化維和微型維度的問題，dim_fr_item通過快
   照和分區字段來解決。

– dim_fr_item將每天存放一份全量數據快照，存放的生命週期
由業務需求確定
• 出於屬性擴展性考慮，dim_fr_item將包含JSON和
KeyValue的大字端，但相應地會增加了使用成本。

數據倉庫
銷售事實表

數據倉庫
銷售事實表

數據倉庫
數據平臺架構 - -數據湖
• 數據湖和數據倉庫的核心區別：
1.數據湖存放所有數據：數據湖存儲結構化、半結構化（JSON、XML）和非結構化（語音、視頻）數據，同時存放所有數據，
不僅包括現在需要用到的數據，也包括以後會用到的數據或者壓根不用的數據；而數據倉庫通常存放的是經過處理、結構化
的數據
2.Schema-On-Read：數據在數據湖中保存他們原有的形態知道即將被使用的時候纔會進行轉換（shema-on-read）；而數
據倉庫在寫入之前必須定義好結構和形態（schema-on-write）
3.更容易適應變化：若數據有價值且可被重複利用的，轉換爲日常任務。如果沒用的無須投入人力和時間成本
4.更快的洞察能力：因爲數據湖包含所有數據和數據類型，並且它能夠讓用戶在數據經過清洗、轉換、結構化之前就訪問數據
，這種方式使得用戶能夠比傳統數據倉庫方式更快得到結果。鼓勵用戶自助、自由分析數據。