今天遇到一個數倉工程師經常會遇到的一個棘手問題，就是要提取一個供應商從2007到2017年來銷售的數據明細，本來從現有的數據作業關系架構圖中很容易取出這些數據，但是第一數據跨度太長，這種非原始數據底層只存了近5年的數；第二如果沖底層重新生成數據，由於供應商數據不是直接從底層處理而來，有好幾個前置作業，我必須了解前置作業10年前數據處理邏輯是什麽樣子（對於我這種工作不滿10年的完全是一場災難），只能重新對接業務部，從頭開發一張報表。這樣做實在是太耗費時間和人力了。

由此深深地覺得數據模型結構建設存在重大問題。目前使用的數倉架構實際上是一張業務架構圖，好處在於處理目前架構圖中已有或者相近的數據需求時將是非常簡單高效和快速的，但是，一旦業務有變化，整個架構圖都要改變，越是修改離樹根越近的作業， 相關的後續作業改的越多。更甚者像今天遇到的問題，要從底層處理10年前的數據，最高效的方法是找到10年前的數倉工程師和業務人員。

由此，我認為數倉的數據處理架構圖不應該由業務引導，而是要以數據為動力，通過整理數據的內在聯系，分門別類，最後形成一個包羅萬象的數據模型。

當然，數據和業務是不能完全脫離，數據建模就像一棵松樹的成長，數據骨幹要直，所有的枝葉（業務）數據都來自同一個口徑，不然一百個工程師處理同一個任務能出一百個哈利波特。由此本人數據建模過程總結：

1首先對業務進行整理，總結歸納業務需求。

2對各個業務的的數據進行分類，例如，本公司數據可以分為訂單數據，供應商數據，物流數據，用戶數據，優惠數據等幾大類

3對各大類數據進行維度分析歸類，例如，不論是訂單還是供應商都會涉及到地理維度數據，商品維度數據等

4模型建設，模型建設包括事實表建設和維表建設，事實表作為數據最底層，粒度越細越好，例如事實表中訂單銷售銷退數據，最好是精確到商品級，事實表要盡可能少地與維表數據重合，同樣，維表要盡可能精簡，鼓勵使用星型模型，不建議使用雪花模型

5

數據倉庫數據架構小序