數據倉庫總結

項目上線了，結合數據倉庫實戰視頻，覆盤總結下。

歷史的浪潮

1、數倉痛點

感受到疼痛的點

煙囪式開發形成的數據孤島和重複計算：–建模規範和開發規範

各業務系統都存在匯率、證券信息等公開市場信息的重複計算，重複做；
客戶信息表是全量，更新很少，但需要某個歷史時刻的客戶狀態，重複做；

指標口徑不一致導致數據可信度下降： --指標字典

同樣的股基交易量，要和另一部門的數據保持一致；

產出形式單一： --數據產品和服務化

離線的報表。

數據模型

實際項目中，完善了DWD明細層，未衍生DWS、DWM；但根據需要設計了指標中心，服務於應用層；
實際應用中會遇到數倉的兩個架構，kimball維度建模和Inmon模式；
Inmon都是以數據源頭爲導向。首先，需要探索性地去獲取儘量符合預期的數據，嘗試將數據按照預期劃分爲不同的表需求。其次，明確數據的清洗規則後將各個任務通過ETL由Stage層轉化到DW層，這裏DW層通常涉及到較多的UDF開發，將數據抽象爲實體-關係模型。接着，在完成DW的數據治理之後，可以將數據輸出到數據集市中做基本的數據組合。最後，將數據集市中的數據輸出到BI系統中去輔助具體業務。很關注數據的清洗工作，從中抽取實體-關係
Kimball都是以最終任務爲導向。首先，在得到數據後需要先做數據的探索，嘗試將數據按照目標先拆分出不同的表需求。其次，在明確數據依賴後將各個任務再通過ETL由Stage層轉化到DM層。這裏DM層數據則由若干個事實表和維度表組成。接着，在完成DM層的事實表維度表拆分後，數據集市一方面可以直接向BI環節輸出數據了，另一方面可以先DW層輸出數據，方便後續的多維分析。
Kimball往往意味着快速交付、敏捷迭代，不會對數據倉庫架構做過多複雜的設計，在變換莫測的互聯網行業，這種架構方式逐漸成爲一種主流範式。實際案例可兩數倉架構的對比

實體表、維度表、事實表的關係：
事實表是多個維度表的一個交點。而維度表是分析事實的一個窗口，數據庫結構中的星型結構，該結構在位於結構中心的單個事實數據表中維護數據，其它維度數據存儲在維度表中。每個維度表與事實數據表直接相關，且通常通過一個鍵聯接到事實數據表中。
星型架構是數據倉庫比較流行的一種架構。
事實表是數據倉庫結構中的中央表，它包含聯繫事實與維度表的數字度量值和鍵。事實數據表包含描述業務（例如產品銷售）內特定事件的數據。
維度表是維度屬性的集合。是分析問題的一個窗口。是人們觀察數據的特定角度，是考慮問題時的一類屬性，屬性的集合構成一個維。
聚合表一種中間表。數據是按照最詳細的格式存儲在事實表中，各種報表可以充分利用這些數據。一般的查詢語句在查詢事實表時，一次操作經常涉及成千上萬條記錄，但是通過使用匯總、平均、極值等聚合技術可以大大降低數據的查詢數量。因此，來自事實表中的底層數據應該事先經過聚合存儲在中間表中。中間表存儲了聚合信息，所以被稱爲聚合表，這種處理過程被稱爲聚合過程。
實體表就是一個實際對象的表，實體表它放的數據一定是一條條客觀存在的事物數據，比如說設備，它就是客觀存在的，所以可以將其設計一個實體表；