數倉 | Kimball的維度建模過時了嗎？
本文轉載自微信公眾號「大數據技術與數倉」，作者西貝。轉載本文請聯系大數據技術與數倉公眾號。
從20世紀80年代中期以來，kimball一直是數據倉庫和商業智能行業維度建模方法的思想開拓者。維度建模之初假設數據倉庫僅限于單服務器數據庫，隨著大數據時代的到來，分布式計算和分式存儲成為了新的趨勢，所以Ralph Kimball所普及的維度數據建模方法和技術需要一些修訂，這樣才能更好地滿足大數據建模的需求。需要注意的是，在數據倉庫領域， Inmon和Kimball是兩大主要陣營，但是Kimball的維度建模理論對于現代數倉建設的影響可謂是非常深遠的，所以本文主要討論維度建模的相關問題。
不要使用代理鍵
在KimBall的維度建模中，必須使用代理鍵作為每個維表的主鍵，用于處理緩慢變化維。
這個問題對于初學數倉維度建模的人而言，很容易陷入Kimball提出的代理鍵的漩渦之中，以至于把時間都浪費了。其實代理鍵在大數據倉庫環境下顯得很不合時宜，并且很難維護。在實際的建模中使用自然鍵是一個很好的選擇，如果維度有一個復合主鍵，只需將它們與合理的分隔符連接在一起，即可根據多個自然鍵生成單個鍵。
總結下來不使用代理鍵主要有一下兩個原因：
- 分布式計算系統，淡化了事務的概念，生成代理鍵的代價會很高
- 代理鍵會大大增加ETL的復雜性，對于ETL任務的開發和維護成本很高
避免使用 Type-2 SCD
緩慢變化維是維度建模理論的一個非常重要的概念，大多數情況下，Type-0 或 Type-1 SCD 可以解決問題。除非有特別關鍵的原因，否則我會避免使用 Type-2 SCD。尤其是在大數據環境下的數據建模，幾乎很少使用Type-2 SCD。
關于SCD的解釋如下：
- SCD1：通過更新維度記錄直接覆蓋已存在的值，它不維護記錄的歷史。SCD1一般用于修改錯誤的數據。
- SCD2：在源數據發生變化時，給維度記錄建立一個新的“版本”記錄，從而維護維度歷史。SCD2不刪除、修改已存在的數據。
- SCD3：通常用作保持維度記錄的幾個版本。它通過給某個數據單元增加多個列來維護歷史。例如，為了記錄客戶地址的變化，customer_dim維度表有一個 customer_address列和一個previous_customer_address列，分別記錄當前和上一個版本的地址。SCD3可以有效維護有限的歷史，而不像SCD2那樣保存全部歷史。SCD3 很少使用。它只適用于數據的存儲空間不足并且用戶接受有限維度歷史的情況。
如果非得需要實現 Type-2 SCD(不建議使用)，也不要使用代理鍵。相反，將自然鍵與表示 SCD 中的有效日期和到期日期字段結合使用。這只是查詢稍微復雜一點，但更靈活，更容易實現，并且避免了對代理鍵的需要。
維表快照
在關系型數據倉庫時代，快照維度顯得沒有意義，但在大數據環境中卻非常有意義。簡單將就是使用分區表，每個分區內存儲的是截止當前時間的全量維度信息。
通過快照的方式處理緩慢變化維，是在大數據環境的數據倉庫實踐中常用的方式。以離線數倉為例，計算周期一般是每天一次，基于此周期，處理緩慢變化維的方式就是每天保留一份全量的快照數據。以商品維度為例，就是每天保留一份全量的商品快照數據。在下游的使用過程中，可以獲取每天的維度信息，使用起來非常方便。
優點
- 簡單，開發和維護成本低
- 方便，很容易理解，下游使用數據時只需要限定所需要的日期即可
缺點
- 存儲浪費
- 綜合看來，由于存儲成本遠低于CPU、內存的成本，此方法是犧牲存儲獲取ETL效率優化和邏輯上的簡單，顯然是利大于弊的。
數據建模的非規范化
所謂的非規范化，即是將某些維度屬性冗余至事實表。過去之所以不贊成這樣做，部分原因是因為 RDBMS 將數據存儲在表中的方式。隨著 Parquet 和 ORC 等列式數據存儲格式的出現;這不再是一個大問題。
在傳統的維度建模的星型模型中，對于維度的處理是將其單獨存放在專門的維表中，然后通過事實表的外鍵獲取維度。這樣做的目的是為了減少事實表的冗余，從而減少存儲消耗。
但是在大數據背景下，考慮到提高下游任務的使用效率，降低獲取數據的復雜性，減少關聯表的數量，通常的做法是將常用的維度冗余至事實表中。
善于使用復雜的數據類型
通常，作為數據工程師，我們的工作是將非結構化數據集重新組織為結構化(或半結構化)數據集，但是在一些場景下，非結構化是一個很好的選擇。
復雜的數據類型違反了最重要的范式(原子列)規則，其實你會發現，維度數據建模的許多傳統理論都違反了其中的一些規則。由于復雜數據類型使用起來非常靈活，其在現代數據倉庫中功能是非常強大的。
當某個實體的詳細信息在不久的將來發生變化時，使用一個 JSON來保存這些字段是很有必要的，直到schema的細節可以固化。
對于一對多的情況，使用數組或許是一個很好的方案，例如，如果在商品維度中存儲一些標簽字段，我們就可以將這些字段存在在一個數組字段中，而不是將標簽存儲在 一張標簽表中。
值得注意的是，對于一些特殊的場景，要善于使用復雜類型，而不是濫用復雜數據類型。結構化依然是建模過程中需要考慮的重點。
總結
Ralph Kimball的維度建模理論對于當今數據倉庫建模的影響可謂是非常深遠的，我們現在主流的數倉建模都是基于維度建模的。隨著大數據技術的不斷發展，維度建模的一些方法需求隨之做出一些調整，但是其核心思想是不變的。另外，作為數倉開發者，我們要遵循一個準則：數據倉庫的設計是為了業務服務的，是為了發揮數據運營的優勢而存在的，所以彰顯數據價值，賦能業務增長才是我們需要考慮的最根本問題。
