數據倉庫知識點梳理(1)

  • 2020 年 3 月 29 日
  • 筆記

近幾年隨着「大數據」、「數據驅動」、「數據中台」等概念在互聯網界的熱炒，懂數據的獲取、處理到算法推薦、模型預測等人才也得到熱捧。觀感上，這些技能領域是隨着大數據時代而來的。而實際上，早在上世紀80年到90年代初數據倉庫和數據決策支持系統概念已經提出，本質上都是將多源頭的數據集中起來，採用統計學的方法來進行數據分析以支持企業的各種決策。

既然換湯不換藥，我們可以通過數據倉庫知識來指導在大數據工程的實踐。本文將對數據倉庫的發展歷史和背景進行介紹，作為「數據倉庫知識梳理」系列的第一篇文章。

01 數據存儲的發展歷程

從狹義上講，數據倉庫也是一種數據的存儲形式。從電子計算機出現以來，數據的數字化存儲大致經歷了下面的幾個階段。

  • 1950s
    打孔卡（Punch cards），首個存儲數據的介質
  • 1960s
    磁性存儲（磁帶、磁盤）
  • 1970s
    首個數據庫管理軟件（IMS）， 層次型數據庫
    DBTG，網狀數據庫
  • 1980s早期
    關係數據模型，RDBMS的實現
  • 1980s末-1990s
    數據挖掘，數據倉庫（W. H. Inmon）
    95年數據倉庫流行：IBM的dw方案，Oracle/SQL Server綁定OLAP服務
  • 2000s
    隨着線上數據增長，成為BI解決方案的一部分
    與大數據，NoSQL系統的結合

02 企業的決策層級

企業中部署數據倉庫，其目的還是要用數據來說明現在的情況，並對下一步的動作計劃提供支持。企業的決策可以分成三個層級，如下圖所示。

底層可能有操作員就可以執行，比如一個電商訂單物流長期處於「發出」狀態，可能是出現丟件異常，就需要聯繫物流進行處理。中層的銷售預測，需要根據歷史的銷售記錄為主對未來一段時間的銷售進行預測，這一層級可能在特定部門內使用。頂層的新市場識別或者店鋪選址等動作，需要考慮整個公司的數據甚至是外部的數據，如地理、人口、經濟數據等結合起來而作出決策。

因此，在建立數據倉庫或者數據中台的時候，不是說越複雜的系統就越好，關鍵是看需要支持怎麼樣的決策層級。其次還要考慮實施難度和建設周期等多個方面的因素。

03 數據庫技術的限制

上一小節中的「異常訂單處理」，如果單純考慮超時提醒功能，可以直接在關係型數據庫中實現。但是上層的決策，在關係型數據庫上開發可能會遇到以下的3個問題。

1.性能限制：
1.不能同時保證事物處理和BI決策類型的統計查詢；

2.集成度不夠：
1.C/S，B/S架構，數據庫獨立服務特定應用，數據是分散的
2.還有外部數據源的數據
3.各系統間的名稱、單位口徑的統一

3.方法工具的缺失
1.統計查詢的優化
2.數據建模的方法論
3.配套的統計查詢和統計分析工具

基於以上原因，數據倉庫與業務數據庫有不同的底層設計。

04 數據倉庫的定義

數據倉庫是一個面向主題的、集成的、非易失的，隨時間變化的用來支持管理人員決策的數據集合。

​ ——《數據倉庫(第4版)》

  • 面向主題，是指對應企業中某一宏觀分析領域所涉及的分析對象

    • 例如："銷售分析"就是一個分析領域

    • 這個"銷售分析"所涉及到的分析對象為商品、供應商、顧客、倉庫等，那麼數倉主題可以確定為商品主題、供應商主題、顧客主題、倉庫主題

    • 數據層面來說，主題之間可能存在數據重疊關係

  • 集成

    • 數據來自於多個異構數據源
    • 標準化的數據集成方法

  • 非易失

    • 與數據源的數據分離保存
    • 一旦數據寫入數據倉庫，不進行更新
    • 數據倉庫的數據只支持數據的初次加載和訪問

  • 隨時間變化

    • 保留歷史數據（數據的快照）

    • 數據倉庫的數據包含時間元素（記錄時間戳）

    • 數據追加方式通過不同時間上數據的變化實現

05 數據建模方式

既然數據倉庫最基本的功能是存儲數據，數據如何存儲就是下一個問題了。數據建模方式即對數據的存儲方式進行設計，目前的主流的方式為維度建模，相對而言業務數據庫通常採用關心建模的方式。

上圖中，左邊是業務數據庫模型，訂單、顧客、產品表等都對於與業務中的實體，方面業務系統的數據查詢和新增，減少sql的查詢。其通常符合「範式」建模要求。

右邊是數倉的星型模型，以一個銷售主題，通過一個fact表，對接其他維度表信息。其特點是數據冗餘小，大量的屬性都存放在維度表中，結構清晰，便於使用相關的工具做數據分析。這裡先提一下，數據倉庫查詢語言的工業標準其實不是sql，而是mdx，後面會單獨出一篇講下mdx的工具和簡單語法。

06 架構設計

數據倉庫架構設計有自頂向下構建和自底向上構建兩種方式。

其中自頂向下構建方式需要從企業總體需求開始設計出整體的數據模型，然後將所有需要的數據彙集起來ETL到相應的模型對象之中，這是一種大一統的方式。最後再通過特定的權限設置，將數據的訪問提供給企業下面的部門。

自底向上的方式，可以在子部門中獲得特定主題的小型數據模型，建立服務於特定部門的數據倉庫，它們也被稱為數據集市。

至於如何選擇自己的架構，可以從以下兩個方面進行考慮。

  • ROI

    • 項目風險：自頂向下方式可能周期較長，部門間數據的流轉必然成為制肘
    • 商業價值：數據更集中更有可能發現其中蘊含的關係

  • IT部分角度

    • 資金政策的來源：明確項目的出資方和收益方
    • 數據信息的來源：明確誰能夠提供出數據

07 總結

本文簡要介紹了數據儲存的發展歷史，數據倉庫產生的原因，數據倉庫的定義、數據建模方式和數倉的架構設計。

歡迎掃描二維碼關注公眾號

VirMach 便宜 VPS

QNews

QNews