資料倉庫分層之辯
阿新 • • 發佈：2019-02-05
資料倉庫的分層可以算是資料倉庫架構的子話題。在前段時間參與的一次討論中，筆者發現其中爭論的焦點集中在每一層的作用、特點、是否有必要存在等問題。其中，大家雖然一致提到某些相關概念，但各方的理解卻並非完全一致。例如對於ODS是什麼、維度建模是什麼等問題的解讀，都是如此。
不妨想想看：資料從分散而異構的資料來源中長途跋涉，到最終的報表、儀表盤、OLAP應用等等，讓使用者看到一致的結果，這是一個過程。記得以前有個礦泉水廣告，說要經過N層的過濾才得到了那種水。而資料倉庫也一樣，從原來亂七八糟的資料到交付到使用者手中的“純淨”資料，也需要這樣一個過濾過程，需要各種不同的過濾裝置。這個過濾過程，我們可以稱之為ETL；而那些過濾裝置，就可以看作資料倉庫的分層。從目前來看，還沒有非常統一的分層方法，其中，Inmon和Kimball是最具代表性的兩種分層方法。
Inmon與Kimball
在Inmon提出的CIF（Corporate Information Factory，企業資訊工廠)中，他將ODS（Operational Data Store，操作型儲存）、EDW（Enterprise Data Warehouse，企業資料倉庫）、DM（DataMart，資料集市）區別開來，共分三層。相對於此，Kimball的匯流排架構強調多個數據集市合成了資料倉庫，只是他們基於統一的維度而已。因此，匯流排架構的分層中，從資料來源介面就直接到了DM了。
根據這兩種思路，又可以衍生一些不同的方法。例如IBM就提出一種CDW的概念，叫做企業資料倉庫層，這一層介於EDW和DM之間，起過渡作用（因為EDW和DM兩層的建模理念是不同的）。
除了這些分層，大家都還認同一個Staging Area（集結地）的地方。這是用於ETL過程中資料的臨時儲存，可究竟這個區域是位於介面到ODS之間，還是ODS到DW之間，或是CDW到DM之間，並沒有達成一致的意見。在筆者看來，既然它是用於ETL中間資料快取的，那麼，在以上每一層都會需要，它是一個每層共用的儲存區域。
ODS層與DW層
對於ODS層，一般大家都能夠認同它是一種操作型比較強的、未保留歷史或者保留近期歷史的資料。所謂操作型，是相對分析型而言的。後者多是彙總的、便於分析統計的結構。操作型的另一個特點就是經常會被更新，而分析型資料很少如此。然而，對於ODS的認識，也有不同。
常見的爭議包括： ODS是否應該被終端使用者訪問？ODS存在的目的是僅僅供DW層獲取經過清洗的資料，還是能夠讓使用者從中得到統計報表？
對於DW層，一般大家都會認同，這是保留歷史資料的地方。但它是按照第三正規化還是維度建模呢？當然，最大的不同就是：是需要一箇中心DW，還是一個由若干資料集市組成的“虛擬”的DW。至於DM層，對此基本有一致的認同，這是面向終端使用者分析統計的，採用維度建模再好不過。
可因為對DW層建模方法的不同觀點，因此也就出來了所謂CDW的提法。想想，如果DW是按照第三正規化建模，而DM是按照維度建模的話，那麼它們之間該如何過渡？看上去，CDW確實也有存在的必要，在這個區域，需要形成滿足匯流排架構所需的一致性維度（Confirmed Dimension）和一致性事實（Confirmed Fact）。
但問題是，第三正規化和維度建模難道就真得水火不相容？筆者更相信一個道理—架構中沒有絕對的設計原則。所謂第三正規化，只是指出一種理想的ER（實體-關係模型）設計模式，但實際做設計時，設計師大多會去做一些平衡，他們也許會說，“為了效能、應用方便，會考慮適當的冗餘。”可這適當冗餘不也就破壞了第三正規化嗎？而且這個“適當”誰也說不準是多少。因此，可以理解EDW並不是絕對的第三正規化，而所謂維度建模又能夠和第三正規化有多少衝突呢？在其本身概念裡面，星型模式是一種不太符合第三正規化的ER結構，但只是不“太”，如果改成雪花模式，是不是也就是第三正規化了呢？
名詞與真義
具體要採用哪種分層方法還得視專案大小而言。對於大專案，或是大的整合商來實施，恐怕多會採用複雜的分層方法。其實分層越細，每層的功能也就越單一，它們之間的耦合程度也就越單一。當然這也是需要衡量的，因為分層多了，ETL過程自然也就複雜，那對於資料質量的控制也就變得麻煩——在多個層裡面可能都存在同樣意義的資料，需要保證它們是一致的。
像IBM、NCR這樣的廠商，他們大多走的Inmon路線。經過多年的經驗總結，都已有自己的企業概念模型，這也非常適合走分層明確、具有中心資料倉庫的路線。在Inmon的體系中，EDW是按照第三正規化建模的。之所以要強調這種思想，是因為第三正規化能夠讓資料模型變得簡潔、高度一致性。對資料倉庫的一個目的——統一口徑（Single Version of Truth），是非常有幫助的。
另一方面，Kimball的維度建模理論，即按照事實表、維表來構建資料倉庫、資料集市，也已經在很多實踐中被證明是非常有效的方法。可這種建模方法和第三正規化多少有點衝突。例如在維表中，不同粒度的資料放在一種表裡面，即存在大量的資料冗餘。但這種方法對資料倉庫四大特點之一的“面向主題”，又是有利的。
如此看來，大家提到的方法似乎都是從不同角度去看，沒有絕對的對錯，只是在為維護自己的觀點而爭論。具體採用何種分層，還得看專案投資大小、資料量多少以及業務邏輯複雜程度而定吧。
說句題外話，或許當概念太多的時候，我們最應該做的就是要拋開那些容易混淆視聽的名詞，去探察其真正的意義所在。