【賽迪網－IT技術報道】這篇論壇文章（賽迪網技術社區）深入探討了數據倉庫和數據集市的異同之處，更多內容請參考下文：
BI領域始終存在著建設數據倉庫還是建設數據集市、自上而下還是自下而上的爭論，而在實際建設中，自然不會有人完全按照某種理念去做，比如在電信公司的數據集市建設中，地市公司的特殊情況與總部規範之間的博弈就成了一大難題。
自上而下 VS自下而上
剛進入BI領域的時候，感覺到處都在說、都在做“數據倉庫”，而現在，很多地方又開始說建設“數據集市”了。只是，如何對數據倉庫和數據集市兩者做出一個明晰的區分，卻始終是個問題。
從字義上看， “倉庫”可以想像成一所大房子，高高的貨架，合理的出入路線，是一種集中存儲貨物的地方，一般顧客是不來參觀訪問的； 而說到“集市”，就容易聯想到空曠的場地，川流不息，大小商戶擺出攤子，賣衣物的、賣燒餅及賣藝的，是讓顧客來消費的地方。具體來說，數據倉庫僅僅是提供存儲的，提供一種面向數據管理的服務，不面向最終分析用戶；而數據集市是面向分析應用的，面向最終用戶。
如此理解比較簡易，但是用這樣的比喻來定義數據倉庫和數據集市之間的區別卻未免過於淺陋。比如數據倉庫也可以被直接訪問，而數據集市也提供存儲，而且這樣區分似乎就表明，數據倉庫和集市必須都存在才能為最終用戶所用。事實則並非如此。那麼，這樣看起來，它們的區別似乎僅在於規模大小不同了。但如此一來，又有問題了，比如多大才算大，多小才算小呢？這也得相對而言，譬如電信公司的數據集市恐怕就比一個玩具廠的數據倉庫大出幾千倍。
其實，換個角度來看的話，這兩者之間的區別正是自上而下和自下而上辯論的產物，也就是Inmon和Kimball兩派在產品應用中的具體體現。
理想的“自上而下”，即一個企業建立唯一的數據中心，就像一個數據的倉庫，其中數據是經過整合、經過清洗、去掉臟數據的、標準的，能夠提供統一的視圖。要建立這樣的數據倉庫，並不從它需要支援那些應用入手，而是要從整個企業的環境入手，分析其中的概念，應該有什麼樣的數據，達成概念完整性。理想狀況下，數據倉庫建成以後，因為數據是標準的，沒有太多冗余，數據品質得以保證。因此，報表、OLAP以及其他任何統計分析應用都可以從中獲取需要的數據。然而，這僅僅是理想，多少有點形而上的做法，有些過於追求事物的本質。
而“自下而上”的做法，則是強調應用決定數據，有什麼應用就獲取什麼數據。理想狀況下，一項分析應用只需要剛剛好的數據。例如人力資源部門的數據集市，就不需要市場推廣的數據，那麼這些數據將不被納入該集市中。很明顯，這也是理想化的，因為需求是不斷變化的，今天人力資源可能不需要市場推廣數據，但是如果哪一天需要分析員工做市場推廣的成本收益，恐怕就需要這些數據了。
當然，在實際項目的建設過程中，誰都不會傻呵呵地完全按照絕對的自上而下或是自下而上的方法去做。
就國外成熟數據倉庫廠商的理念而言，大多是以自上而下為主，採用Bill Inmon的方法，先建立一套完美的EDW（企業數據倉庫），並且他們通常針對行業已經設計出抽象程度比較高的概念模型，可以根據實際環境生成邏輯模型和物理模型。在構建完美的數據倉庫的時候，設計者會考慮最終有哪些應用，根據應用做取捨。一般來說，數據倉庫是分階段的，譬如第一階段主要服務於市場部門作市場分析，那麼，建設者就很可能“偷工減料”，像員工資訊、財務數據反正也沒人用，便捨棄它們。由此，一套完美的EDW真正落實下來，往往因為受到項目週期、人員經驗所限，最終會變得面目全非。
與國外相反，國內集成商的做法大多是自下而上。其中一部分原因在於週期和人員的原因，老闆要求儘快上線，客戶要求儘快看到結果，而這個時候恰好就是Kimball方法的用武之地。建設者會針對應用快速建立數據倉庫（注意，這裡仍然叫做數據倉庫，似乎大家也不願意叫做數據集市，可能那樣顯得有些小氣吧）。實際上，如果比較採用兩種不同理念完成的第一版本，我們會發現，這兩種交付版本竟是如此相像。
數據集市的建設難題
從前幾年電信行業的經營分析系統建設可以看出來：無論移動或是聯通，都不會將經營分析系統稱為是數據集市系統。可在一開始，這些系統恐怕都僅僅是服務於少數部門的。
幾年前，中國移動開始在全國少數幾個地市開始數據集市的試點，這才算真正有了個“數據集市”項目。之所以有這種項目，是因為經營分析系統不能滿足地市公司分析的需要。當然，也不排除廠商、集成商在其中煽風點火的作用。
其實，這對移動公司來說，幾乎可以算是一件很令人惱火的事情了！本來，建了幾年的數據倉庫，是要將數據集中起來，提供分析功能、輔助決策。可後來卻發現，數據量太大不說，地市公司人員訪問也不方便，甚至還繞開數據倉庫，直接去生產系統裏面取數據。此時，原來忽悠數據倉庫的那批廠商集成商又上門，開始忽悠起數據集市了。三年前，他們說，“數據要集中，提供唯一的數據視圖”，三年後，他們又講，“數據要分佈，便於用戶的訪問”。網界網消息
那麼，到底該怎麼看這個問題呢？事實上，如果辨證地來看，如此兩種看上去截然不同的言論也確實能找出一些“交集”。說集中，三年前有的省分公司已經達到BOSS系統的集中了；說分佈，不是有邏輯和物理數據集市之分嗎！所謂邏輯，就是在現有數據倉庫中建立一些視圖或表，專門給地市使用；而物理，就是將硬體、軟體放到地市，讓地市公司自己玩兒。總之，以前好不容易將數據從地市抽上來，如今經營分析系統裏轉了一圈，再還給他們，移動公司還真得仔細想想這是否值得。
從實際建設情況來看，有的地市有錢，就建設獨立的數據集市，有獨立的硬體、軟體；有的地市沒錢，那就和其他差不多級別的地市聯合起來，共用一個數據集市，建設所謂聯合型數據集市。招都想絕了，以至於差不多都忘了數據集市究竟是幹嗎的了。而對於地市公司的員工來說，他們本來就不是對技術很熟悉的人，好容易學會了從BOSS系統裏面用SQL統計點數，經營分析系統來了，於是重新學習從經分取數； 如今，數據集市又開始建設了，新一輪學習當然是少不了的。在具體應用上，如果這個集市能夠提取相應的數據當然好了，可就怕和經分一樣，想提取數據，告之要等兩個星期，那樣，數據集市還是沒有作用。
數據集市的另一重要功用是分析應用。雖然目前已經規劃出名目繁多的專題，諸如離網預警、競爭對手等，可要將它們在不同的地市用起來，問題就大了。專題的應用重在流程，和具體的組織結構要關聯起來，但各個地市公司情況並不一樣。比如有的地市市場部比較強勢，在數據分析中佔據領導地位，而有的地市則是IT支撐比較強勢；有的地市會為某個專題設定相應的組織結構，有的則不重視，因為那個專題要解決的問題根本不是自己最關注的，更談不上耗費寶貴的人力在它上面。網界網
不管移動或是聯通，都是總部出規範。如今，移動新的經營分析規範、數據集市規範都已出臺，這些規範都是挺大挺全，可並不完全適合所有的省分和地市公司。雖然讓省分公司自己去搞經營分析系統、省分公司讓地市公司自己做數據集市都存在難以控制的風險，但是，如果考慮到經營壓力和急迫的分析需求，地方公司的意見無疑正在越發得到重視。（責任編輯：盧兆林）
