10分鐘幫你清晰理解「Inmon數據倉庫建設」

人人都是產品經理 發佈 2021-10-21T15:56:30+00:00

編輯導語:數據分層都包含什麼,怎麼理解?在上一篇已經講清楚了,那麼Inmon數據倉庫建設該如何搭建?作者從其定義、模型建設以及適用範圍進行分析,提高企業管理和決策的效率,希望對你有幫助。上一篇我們把數倉的分層情況講解清楚:數倉的背景、邏輯、應用等等。

編輯導語:數據分層都包含什麼,怎麼理解?在上一篇已經講清楚了,那麼Inmon數據倉庫建設該如何搭建?作者從其定義、模型建設以及適用範圍進行分析,提高企業管理和決策的效率,希望對你有幫助。

上一篇我們把數倉的分層情況講解清楚:數倉的背景、邏輯、應用等等。

有心的同學一定會問了,這些分層是誰制定的呢?有相關的標準嗎?

想要了解這個問題,你要先了解兩個人,Inmon和Kimball,這兩位大師就像唐詩界的李白和杜甫,如果想要透徹了解清楚數倉,一定要了解下這兩位大師的對數倉的建設和推動做了哪些事情。

了解大師最好的方式就是去閱讀原著,由於今天的主角是Inmon大師,所以我精讀他的著作《Building the data warehouse》。第一遍我看的是中文版本,但是很多精髓在翻譯過程中有缺失,所以又去看了兩遍原著。

一、Inmon對數倉的定義

數據倉庫是在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改的數據集合。

面向主題:按照特定的業務特點來決定,例如:對一個保險公司來說,問題是:汽車保險、健康保險等等;對公司來說,問題是:顧客、保險單、保費、索賠。不同類型的公司主題集合不同。

集成的(重點):最為重要,把各個作業系統匯集到數據倉庫,要進行轉換、格式化、重新排列、匯總等。進入數據倉庫之前,需要消除不一致性,例如:有的性別維值是「男女」,有的是「f/m」。命名習慣、關鍵字結構、屬性度量單位以及數據物理特點。

不可修改的:作業系統環境一般是定期更新,數倉通常是批量載入與訪問(一般不進行傳統意義的更新)。數倉的載入是以靜態快照進行。

隨時間變化:在他的原著《Building the data warehouse》中,以上這些特徵都是和傳統的操作型環境對比而得出的特點。由於操作性環境不具備上述特徵無法滿足需求,所以inmon的數據倉庫才得以應運而生。

二、Inmon模型實施步驟

整體過程抽象出來可以分為兩步,分別是抽出(從操作型環境到數據倉庫)和遷入(數據模型的建設)。

第1步:抽出——從操作型環境到數據倉庫

這個過程簡單來理解就是有很多熊貓分布在北京、天津、河北等地方,但是由於熊貓不適合生存在這些地方,需要把他們整體遷移到四川。第一步需要把熊貓們從現有地方抽出來。但在這個過程中會有很多問題,例如:熊貓長得比較像無法區分、熊貓的身高體重需要統一標準去度量,以便我們更高的去搬運。

回到我們真實的場景中,由於在抽出數據的過程中會遇到如下問題,需要重點去考慮:

  • 命名規範:例如相同的數據以不同名字存在不同地方;相同數據在不同地方用相同方式標註;相同數據相同名字用了不同度量
  • 編碼規範:例如有的性別維值是「男女」,有的是「f/m;有的是cm,有的是英寸
  • 存儲適配:不同的作業系統有不同的格式存儲,有的在DB2中,有的在VSAM中

所以相應的,我們需要去解決以下問題:

  • 去除純粹用於作業系統型環境中的數據
  • 企業模型的關鍵字結構中增加時間元素

穩定性分析:根據各個屬性是否經常變化,而把屬性進行拆分,很少變化、不時變化、經常變化。

第2步:數據模型的建設

終於把熊貓們從各個地方抽離出來了,那麼如何把他們遷入他們最需要去的四川呢?是囫圇吞棗把熊貓們塞到四川呢?還是要先對他們進行分類(幼崽熊貓、青年熊貓、老年熊貓)分別進行有針對性的管理呢?

數據建模分為三個層次:高層模型、中間層模型、底層模型。

(1)高層模型(實體關係)

最抽象原始的一層,整個業務環境中最顯著的關係。例如:我們現在要進行電商業務的實體關係抽象(買家、賣家、訂單)。簡化一下這個模型,並且表明實體之間的關係是:一對一、一對多、多對多。

(2)中間層模型(數據項集或者DIS)

對高層模型中每個實體建一個中間層模型。即:上述模型中每一個實體(賣家、買家、訂單)都對應一個DIS。中間層模型的4個基本構造:

  • 主要數據分組:每個主題域有且只有一個主要數據分組。例如:下圖中的買家信息
  • 二級數據分組:每個主題域存在多次的屬性。例如:下圖中的收貨信息
  • 連接器:表示各個主題域之間關聯的外鍵。
  • 數據的類型:這裡可以理解為某個分組中具體的分類。例如:買家信息可以拆分為他的瀏覽信息、收藏信息、購物車信息、下單信息。而下單信息又可以分為訂單信息和物流信息

(3)底層模型(物理模型)

從中間層模型細化而來,有時也稱物理模型為關係表。如果要搭建好這一層,你需要進行如下兩步操作:

第一步:確定數據粒度。

啥是「數據的粒度」?數據粒度:數據最小的單元和數據匯總的單元,粒度越小表示越細,粒度越大表示越粗。例如:分鐘級別的數據粒度一定比月級別的數據粒度小。

🤔為啥要預估數據的粒度?好處是啥?

要回答好這個問題,首先要回憶一下上篇文章講解的「3層6類」數據分層。數據分層的方式有很多,針對不同體量、不同業務需求的數據會有不同的設計架構。並且數據粒度的預估同時可以帶來如下的好處:

  • 多視角分析數據:可以通過不同的粒度對數據進行分析。
  • 低粒度數據靈活:有了最小粒度的數據,可以定位到根本的原因
  • 高粒度數據概括:對於高度概括的數據,可以對整體業務進行把控
  • 未知數據需求:對於未來的各種預測場景,可以通過所搭建的各類數據建設去進行解決

數據粒度的分檔有哪些?

數據粒度的預估過程如下:對數倉中將來的數據行數和所需的DASD(直接存取存儲設備)數進行粗略估算。分檔可以按照如下進行分檔:

  • 少量數據:數據有10000行:啥粒度都可以,閉眼建粒度
  • 中等數據:數據有10000000行:需要一個低粒度級別,例如:天和周比起來就是低粒度,秒和分鐘比起來就是低粒度
  • 大量數據:數據有100億行:需要高粒度級+數據移到溢出存儲器。

如何預估數據粒度?

對一個已知的表,預估的方式如下:

  • 一張表的總空間=每行空間的大小*行數*時間+索引數據的大小*時間
  • 總空間=表1的空間+表2的空間+….+表N的空間每行空間的大小要分別從最大和最小考慮:
  • 每行空間的大小 = [每行的最小估計值(下限),每行的最大估計值(上限)]行數的預估,同樣需要需要預估下時間範圍內的最大和最小值:
  • 行數=[最小行數(下限),最大行數(上限)]

時間範圍可以暫且按照一年和五年這兩個時間去預估考慮下。

注意:

溢出存儲器中的數據。一年內總行數超過100000000,需小心設計,可以把一部分數據轉移到溢出存儲器中,從而應對數據量過大對性能造成的影響

確定粒度級別。首先要靠常識和行業處理經驗進行合理的推斷,接著要考慮對數據倉庫獲取數據的各個不同的體系結構實體的需求進行預測

第二步:考慮各種因素的核心物理I/O的使用情況。

物理IO就是將數據從外部存儲器調入計算器,或將數據從計算器送到外部存儲器。為啥要進行物理IO的考慮?

為什麼要考慮這一步?首先數據模型輸出的都是表,每張表上承載的數據是有限的,所以需要通過表和表之間的關聯進行關聯。關聯的方式就顯得異常重要,如何設計表和表之間的連結,顯得尤為重要。如果設計好了可以減少訪問次數,降低IO;如果設計不好就會造成數據冗餘,訪問困難,會提升IO。

如何進行規範化從而降低物理IO?

數據在計算機和外部存儲之間的傳送以塊為單位。從性能來看,物理IO重要是因為:存儲器和計算器間的數據傳輸速度比計算器運算速度要慢2-3個數量級。物理IO是影響性能的主要因素。那麼如何進行規範化降低物理IO,可以根據情況使用如下方式:

  1. 數據數組:數據放在數組的一行中,這樣可以一次性去獲取所需數據。
  2. 合併表:常用數據合併為一張表
  3. 選擇冗餘:特意引入冗餘數據。常用信息散落各個表中,便於查看
  4. 分離數據:從訪問次數這個角度把一張表中的數據分為高頻數據和低頻數據。分別建一張高頻表和一張低頻表
  5. 導出數據:生成一個欄位來存儲計算出的數據
  6. 預格式化
  7. 人工關係
  8. 預連接表

三、Inmon模型適用範圍

Inmon模型的特點是:開發進度慢,實施成本高,建設周期很長。尤其是建設前期需要花費大量時間,後期投入相對比較小,對開發人員的要求比較高,一般會選擇專家團隊進行開發,維護起來相對而言比較容易。

適合對設計科學性和規範性較高的企業,在業務模式較固定的行業應用較好,比如金融、電信、石油等行業。

四、Inmon模型小結

優點:可以系統性的滿足企業需求。因為Inmon採用的思路是自上而下的的建設方法,統一接入系統元數據,統一根據業務部門需求建設數據集市。因為建設較為規範,所以後期的維護成本非常小

缺點:瀑布式建設,前期建設人力(需要專家團隊建設)、資源等投入很大。由於它的思路是從數據源頭進行系統性的全面建設,一次性接入所有數據,打通所有數據,建好所有模型,所以建設的代價很大。

本文由 @數據產品高遠 原創發布於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於CC0協議

關鍵字: