之前的文章——網站數據分析的一些問題2中主要整理了BI相關的問題，這篇文章主要想整理一些數據倉庫相關的問題。因為最近重新在看一些數據倉庫的資料和書籍，想把之前以及當前遇到的主要問題提出來(博客中有關數據倉庫的相關內容請參閱網站數據倉庫這個目錄)，同時自己也對數據倉庫方面的知識進行下重新的整理和認識，而且很久沒有在博客發新的文章了，不能讓自己過于懶散了。
之前看過Inmon的《構建數據倉庫》和《DW 2.0》，而另外一位數據倉庫大師Kimball的《數據倉庫生命周期工具箱》一直沒有時間閱讀，最近才有時間看完了大部分，就迫不及待想寫點東西了。其實數據倉庫領域普遍認為Inmon和Kimball的理論是對立的，兩者在構建數據倉庫上方向性的差異一直爭論不休，誰也無法說服誰到底哪種方法更好。我的Evernote的筆記里面不知什么時候從哪里摘錄過來了對兩者觀點的概括性描述，非常簡潔明了而一針見血：
Inmon vs Kimball
Kimball – Let everybody build what they want when they want it, we’ll integrate it all when and if we need to. (BOTTOM-UP APPROACH)
Pros: fast to build, quick ROI, nimble
Cons: harder to maintain as an enterprise resource, often redundant, often difficult to integrate data marts
Inmon – Don’t do anything until you’ve designed everything. (TOP-DOWN APPROACH)
Pros: easy to maitain, tightly integrated
Cons: takes way too long to deliver first projects, rigid
其實看了《數據倉庫生命周期工具箱》之后，發現兩者的觀點沒有那么大的本質性差異，可能隨著數據倉庫的不斷發展，兩者在整體的架構上慢慢趨同。基本上，構建統一的企業級數據倉庫的方向是一致的，而Inmon偏向于從底層的數據集成出發，而Kimball則趨向于從上層的需求角度出發，這可能跟兩者從事的項目和所處的位置有關。
有了上面這段高質量的概括，第一個問題——你更偏向于以何種方式搭建數據倉庫(BOTTOM-UP or TOP-DOWN)，分別有什么優劣勢?——其實就不用問了，所以下面主要提幾個在實際中可能經常遇到或者需要想清楚的問題：
Q1、數據倉庫的技術解決方案有哪些，這些解決方案的優勢在哪，瓶頸在哪?
隨著數據倉庫的不斷發展和成熟，“大數據”概念的風靡，有越來越多的相關產品出來，最常見的技術解決方案包括hadoop和hive，oracle，mysql的infobright，greenplum及nosql，或者多個結合使用。
其實歸納起來就兩類：一是用傳統RDBMS為主導的數據庫管理數據，oracle、mysql等都是基于傳統的關系型數據庫，優勢就是有更嚴謹的數據結構，關系型數據庫對數據的管理更加規范，數據處理過程中可能出現的非人為誤差極小，而且標準的SQL接口使數據獲取的成本較低，數據的查詢和獲取更加靈活和高效;但劣勢也很明顯，對海量數據的處理和存儲的能力不足，當數據量達到一定程度的時候就會出現明顯的瓶頸。而是基于文本的分布式處理引擎，hadoop、greenplum和nosql都是基于文本數據的處理和存儲，優勢是強大的數據處理能力，分布式的架構支持并行計算，并且具備超強的擴展延伸能力;劣勢就是上層接口不方便，因此Hadoop上層的hive和greenplum上層的postgreSQL都是為了解決數據接口的問題，并且數據的查詢和獲取很難做到實時響應，靈活性不足。
Q2、數據倉庫是否就應該保存聚合數據，細節數據不應該放入數據倉庫?
其實這個問題基本已經達成共識，如果是構建企業級的數據倉庫，那么對細節數據的集成和存儲是必不可少的，但現實中還是存在很多直接從外部數據源計算聚合之后導入數據倉庫的實例。如果對數據倉庫只是輕量級的應用，僅存放聚合數據也無可厚非，畢竟沒人規定數據倉庫一定要是怎么樣的，最終的目的無非就是滿足對數據的支持和需求。
但對于企業的長期發展來看，數據倉庫中存放細節數據有兩方面的好處：一方面從技術層面，數據倉庫存儲細節數據可以釋放前臺數據庫的查詢壓力，同時對于文本類數據和外部文檔類數據入庫之后管理更加規范，數據倉庫保留歷史和不可變更的特性可以讓信息不被丟失;另一方面就是從數據的使用上，數據倉庫讓數據的獲取和使用更加簡便，集成細節數據讓大量的文本型數據可查詢，可關聯，而面向主題的設計讓數據的展現和分析更有方向性和目的性，而且細節數據是支持數據分析和數據挖掘應用所必不可少的。所以，如果數據倉庫要不斷地催生出更大的價值，細節數據的存儲是必不可少的。
Q3、你會把數據倉庫分為幾層，每層的數據作用是什么?
沒有標準答案，根據數據倉庫中數據的復雜性和對數據使用的需求程度，數據倉庫可以有不用的層級劃分。
我一般會把數據倉庫劃成三層：最底層的細節數據，管理策略是優化存儲，一般存儲導入的原始數據，便于進行向上的統計匯總，因為數據量較大所以需要優化存儲;中間層是多維模型，管理策略是優化結構和查詢，面向主題的多維模型的設計，需要滿足OLAP和數據查詢的多樣需求，同時保證查詢的便捷性，關鍵在與維表的設計和維度的選擇及組合，事實表需要關注存儲和索引的優化;最上層是展現數據，管理策略是優化效率，一般會存放每天需要展現的匯總報表，或者根據多維模型拼裝的視圖，展現層的數據需要以最快的速度展現出來，一般用于BI平臺的Dashboard和報表。
Q4、數據倉庫搭建中最繁雜的事情是什么，最容易缺失的是哪一塊?
一直覺得數據倉庫的核心不在于數據集成，當然數據集成是數據倉庫實現價值的前提，數據倉庫真正的價值體現在數據的有效應用，數據源于業務反作用于業務。而搭建數據倉庫的核心在于數據倉庫的架構和數據模型的設計，怎么權衡數據的存儲和數據獲取效率之間的矛盾是數據倉庫管理上的難點，這個難點任何數據倉庫都會存在，而大數據增大了這種權衡中的難度。而數據的集成和數據質量控制是數據倉庫搭建中最繁雜的事情，尤其是數據清洗的過程，我之前也寫過幾篇數據質量控制的文章，但現實中這個過程還要復雜得多，而且為了上層數據產出的準確性和有效性，這項工作又不得不做，而且要做得盡量細致。
搭建數據倉庫中最容易缺失的就是對元數據的管理，很少有數據倉庫團隊具備完整的元數據，當然搭建數據倉庫的工程師本身就是活的元數據，但無論是為了用數據的人還是數據倉庫自身的團隊著想，元數據都不可或缺。一方面元數據為數據需求方提供了完整的數據倉庫使用文檔，幫助他們能自主地快速獲取數據，另一方面數據倉庫團隊成員可以從日常的數據解釋中解脫出來，無論是對后期的不斷迭代更新和維護還是培訓新的員工，都非常有好處，元數據可以讓數據倉庫的應用和維護更加高效。
寫在最后：以上僅代表個人觀點，歡迎大家踴躍拍磚，更加希望高手們能在評論中給出寶貴的答案，任何角度的觀點和討論都可以，集思廣益。
網站數據分析的一些問題1
網站數據分析的一些問題2
來源：喜運達
加入賣家交流群
快速對接各種平臺優質資源
標簽：跨境電商補單平臺國際海運物流貨代航空空運貨運跨境電商代發貨源網海外倉的服務功能有哪些到貨運物流到馬來西亞集運國際快遞寄美國哪個快加爾各答港海運聯邦國際快遞公司