簡介： 簡單的比較了一下數據中臺架構與數據倉庫、BI、DSS之間的關係，並對比了一下Bill Inmon和Ralph Kimball架構的差異。
1. 數據中臺與DW/BI/DSS
個人認爲數據中臺本質上是一種新的適配大數據技術發展的新的“數據倉庫-決策支持（商業智能）”架構。這個架構是構建在傳統的架構基礎之上，對傳統架構的一種新的發展。
數據中臺從企業的視角出發，要求企業在構建數據倉庫到決策支持系統的過程中構建一個服務型的架構。數據中臺希望構建在數據倉庫基礎上的決策支持系統的建設能更加迅速敏捷，縮短業務需求實現過程中的數據開發過程的時間。數據中臺把應用的共性需求沉澱在中臺，做厚數據服務層，這樣應用前臺在構建的時候可以大幅度的利用已沉澱在中臺的各種能力，可以做到快速搭建，形成大中臺小前臺的層次架構。
1.1. 數據倉庫（DW）/商務智能（BI）/決策支持（DSS）
數據倉庫之父比爾·恩門（Bill Inmon）在1991年出版的“Building the Data Warehouse” （《建立數據倉庫》）一書中所提出的定義被廣泛接受，數據倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策。
數據倉庫是一個過程而不是一個項目；數據倉庫是一個環境，而不是一件產品。數據倉庫提供用戶用於決策支持的當前和歷史數據，這些數據在傳統的操作型數據庫中很難或不能得到。數據倉庫技術是爲了有效的把操作形數據集成到統一的環境中以提供決策型數據訪問，的各種技術和模塊的總稱。所做的一切都是爲了讓用戶更快更方便查詢所需要的信息，提供決策支持。
商業智能（Business Intelligence，簡稱：BI），又稱商業智慧或商務智能，指用現代數據倉庫技術、線上分析處理技術、數據挖掘和數據展現技術進行數據分析以實現商業價值。
決策支持系統（Decision Support System）是一個基於計算機用於支持業務或組織決策活動的信息系統。 DSS服務於組織管理、運營和規劃管理層（通常是中級和高級管理層），並幫助人們對可能快速變化並且不容易預測結果的問題做出決策。決策支持系統可以全計算機化、人力驅動或二者結合。
從概念上來講，BI與DSS都是一組概念的概括性的總稱，可以有很多定義。從歷史沿革上來說，先有的決策支持系統，利用計算機來輔助人做決策。後續商務智能的發展，爲決策支持提供了數據分析預測的能力，商務智能（BI）提供的數據分析能力是現代決策支持系統（DSS）的基石。
（概念引用：商務智能與分析-決策支持系統）
1.2. 先賢的一些詞彙與觀點的爭議
數據倉庫行業內容的兩位觀點部分相左的先賢，分別是Bill Inmon與Ralph Kimball。
1.2.1. 定義與用詞
在數據倉庫支撐的分析型系統的用詞上：
Bill Inmon-數據倉庫是體系結構設計環境的核心，是決策支持系統處理的基礎。(The data warehouse is the heart of the architected environment, and is the foundation of all DSS processing. )
Ralph Kimball-數據倉庫和商業智能(Data Warehousing and Business Intelligence, DW/BI)系統
顯然BI與DSS是有區別的，但是DW無疑是可以支撐BI和DSS。BI是手段是能力，而DSS是BI的目標。
在數據倉庫的定義上，因爲Bill Inmon是數據倉庫之父，他對數據倉庫的定義獲得了廣泛的認可。而Ralph Kimball並未對數據倉庫概念有單獨的定義，但是從架構與實現上來看，其實還是有區別的。
1.2.2. 架構設計
在數據倉庫架構的設計上：
Bill Inmon - 全局視角，要先構建企業級數據倉庫，然後再基於企業級數據倉庫之上去構建數據集市。數據的整合是的企業對數據有一個真正企業範圍級的觀察，業務分析人員是從整體而不是局部進行數據分析。
數據倉庫前期的需求是不明確的，業務人員是先要看到數據再去構建探索真實需求，所以數據倉庫是不斷的迭代構建。採用3RD模型來構建一個企業級的業務模型，確保數據的完整性與一致性。
Ralph Kimball -需求視角，以業務需求驅動，面向分析。事實要構建在最細的粒度上，不同的業務需求之間靠一致性維度來確保數據的一致性。
- DW/BI架構
- 輻射狀企業信息工廠（CIF）
- 混合輻射狀企業信息工廠與KimBall架構
從上面幾張圖上我們可以看到，之所以在Kimball的書中會有與Inmon組合的混合架構，是因爲這幾張架構圖中的層次基本是一致的。而Kimball架構中並未去描述如何去做數據的規範化、完整性、一致性，只是要去做，而Inmon的架構中恰好可以實現這個部分。對於後面數據展現區的數據模型，又都一致的認爲是以維度模型來建模。
從實際構建方式上來看，Bill Inmon架構強調數據倉庫應該是統一構建，業務模型是企業級的。這個出發點是更具有宏觀意義，假設企業有30個交易系統，建設的時候就需要都納入需求分析範圍，然後按需分階段完成企業級的數據倉庫模型。Ralph Kimball架構強調以業務需求爲導向，構建維度模型，後續的需求只要確保整個企業範圍內一致性維度，就可以構建更加高效的數據倉庫。Ralph Kimball認爲Bill Inmon的架構太過於龐大，可能會讓企業投入巨大但是看不到回報。而Bill Inmon則認爲維度模型構建的數據倉庫，很容易變成鬆散的多個不一致的數據集市。雖然Ralph Kimball也強調獨立集市架構是不可取的。
其實綜合實踐與現實中數據倉庫的案例來看，在以Teradata\IBM\Oracle等公司構建的企業級的數據倉庫架構，全部都是以Bill Inmon的架構來構建了一個3RD的企業級的數據倉庫模型，並且在一些規模宏大的銀行、保險、電信等行業取得了比較巨大的成功。尤其是國內Teradata的金融模型，幾乎佔據了國內全部的大銀行、保險機構的市場。而Ralph Kimball的架構，在銀行、電信、零售電商等行業也是受到了廣泛的好評。
這兩種架構各有千秋，各有側重。並且從兩位先賢相互指責的問題來看，問題都是真實存在的。Ralph Kimball架構雖然強調不能建設成獨立集市架構，要採用全局一致性維度，但是，業務部門分頭建設且以需求爲導向的結構，很容易失控就走成獨立集市架構。Bill Inmon的架構因爲有一層數據倉庫層，從機能上就會去協調，避免這種情況的產生。但是Bill Inmon的架構，因爲構建投入巨大，也只是在金融業獲得了巨大的成功。在一些業務相對簡單規模不大的客戶場景中，因爲交易型系統本身就是3RD模型，所以，本身並沒有需求再去構建一個數據倉庫的3RD模型，ODS系統就基本替代的這一層。
在數據集市、數據應用的分析型場景中，Ralph Kimball與Bill Inmon都應該使用維度模型來構建。
1.3. 綜合的選擇
從Bill Inmon與Ralph Kimball的書中，我們可以看到兩位先賢的觀點。個人認爲在不同的場景可以有不同的選擇，在業務複雜、業務變化不頻繁、數據倉庫上游的交易型系統特別多、能接受足夠長時間大投入的企業級數倉建設的場景，Inmon的架構（或者說是CIF與DW/BI混合架構）顯然是更好的選擇，這種架構更加宏觀，且具有企業級視角，只有在這種視角下才能實現數據中臺的設計目標。而在業務模型簡單、業務變化頻繁、難以接受企業級架構構建的時間成本的場景，最好使用DW/BI架構。
如果可以放眼眼前的數據倉庫的案例，就會發現這是一種比較現實的選擇。
本文爲阿里雲原創內容，未經允許不得轉載。