網(wǎng)站數(shù)據(jù)分析:數(shù)據(jù)倉庫相關(guān)的問題(3)

 之前的文章——網(wǎng)站數(shù)據(jù)分析的一些問題2中主要整理了BI相關(guān)的問題，這篇文章主要想整理一些數(shù)據(jù)倉庫相關(guān)的問題。因為最近重新在看一些數(shù)據(jù)倉庫的資料和書籍，想把之前以及當前遇到的主要問題提出來(博客中有關(guān)數(shù)據(jù)倉庫的相關(guān)內(nèi)容請參閱網(wǎng)站數(shù)據(jù)倉庫這個目錄)，同時自己也對數(shù)據(jù)倉庫方面的知識進行下重新的整理和認識，而且很久沒有在博客發(fā)新的文章了，不能讓自己過于懶散了。

　　之前看過Inmon的《構(gòu)建數(shù)據(jù)倉庫》和《DW 2.0》，而另外一位數(shù)據(jù)倉庫大師Kimball的《數(shù)據(jù)倉庫生命周期工具箱》一直沒有時間閱讀，最近才有時間看完了大部分，就迫不及待想寫點東西了。其實數(shù)據(jù)倉庫領(lǐng)域普遍認為Inmon和Kimball的理論是對立的，兩者在構(gòu)建數(shù)據(jù)倉庫上方向性的差異一直爭論不休，誰也無法說服誰到底哪種方法更好。我的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

　　其實看了《數(shù)據(jù)倉庫生命周期工具箱》之后，發(fā)現(xiàn)兩者的觀點沒有那么大的本質(zhì)性差異，可能隨著數(shù)據(jù)倉庫的不斷發(fā)展，兩者在整體的架構(gòu)上慢慢趨同?；旧?，構(gòu)建統(tǒng)一的企業(yè)級數(shù)據(jù)倉庫的方向是一致的，而Inmon偏向于從底層的數(shù)據(jù)集成出發(fā)，而Kimball則趨向于從上層的需求角度出發(fā)，這可能跟兩者從事的項目和所處的位置有關(guān)。

　　有了上面這段高質(zhì)量的概括，第一個問題——你更偏向于以何種方式搭建數(shù)據(jù)倉庫(BOTTOM-UP or TOP-DOWN)，分別有什么優(yōu)劣勢?——其實就不用問了，所以下面主要提幾個在實際中可能經(jīng)常遇到或者需要想清楚的問題：

　　Q1、數(shù)據(jù)倉庫的技術(shù)解決方案有哪些，這些解決方案的優(yōu)勢在哪，瓶頸在哪?

　　隨著數(shù)據(jù)倉庫的不斷發(fā)展和成熟，“大數(shù)據(jù)”概念的風靡，有越來越多的相關(guān)產(chǎn)品出來，最常見的技術(shù)解決方案包括hadoop和hive，oracle，mysql的infobright，greenplum及nosql，或者多個結(jié)合使用。

　　其實歸納起來就兩類：一是用傳統(tǒng)RDBMS為主導(dǎo)的數(shù)據(jù)庫管理數(shù)據(jù)，oracle、mysql等都是基于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，優(yōu)勢就是有更嚴謹?shù)臄?shù)據(jù)結(jié)構(gòu)，關(guān)系型數(shù)據(jù)庫對數(shù)據(jù)的管理更加規(guī)范，數(shù)據(jù)處理過程中可能出現(xiàn)的非人為誤差極小，而且標準的SQL接口使數(shù)據(jù)獲取的成本較低，數(shù)據(jù)的查詢和獲取更加靈活和高效;但劣勢也很明顯，對海量數(shù)據(jù)的處理和存儲的能力不足，當數(shù)據(jù)量達到一定程度的時候就會出現(xiàn)明顯的瓶頸。而是基于文本的分布式處理引擎，hadoop、greenplum和nosql都是基于文本數(shù)據(jù)的處理和存儲，優(yōu)勢是強大的數(shù)據(jù)處理能力，分布式的架構(gòu)支持并行計算，并且具備超強的擴展延伸能力;劣勢就是上層接口不方便，因此Hadoop上層的hive和greenplum上層的postgreSQL都是為了解決數(shù)據(jù)接口的問題，并且數(shù)據(jù)的查詢和獲取很難做到實時響應(yīng)，靈活性不足。

　　Q2、數(shù)據(jù)倉庫是否就應(yīng)該保存聚合數(shù)據(jù)，細節(jié)數(shù)據(jù)不應(yīng)該放入數(shù)據(jù)倉庫?

　　其實這個問題基本已經(jīng)達成共識，如果是構(gòu)建企業(yè)級的數(shù)據(jù)倉庫，那么對細節(jié)數(shù)據(jù)的集成和存儲是必不可少的，但現(xiàn)實中還是存在很多直接從外部數(shù)據(jù)源計算聚合之后導(dǎo)入數(shù)據(jù)倉庫的實例。如果對數(shù)據(jù)倉庫只是輕量級的應(yīng)用，僅存放聚合數(shù)據(jù)也無可厚非，畢竟沒人規(guī)定數(shù)據(jù)倉庫一定要是怎么樣的，最終的目的無非就是滿足對數(shù)據(jù)的支持和需求。

　　但對于企業(yè)的長期發(fā)展來看，數(shù)據(jù)倉庫中存放細節(jié)數(shù)據(jù)有兩方面的好處：一方面從技術(shù)層面，數(shù)據(jù)倉庫存儲細節(jié)數(shù)據(jù)可以釋放前臺數(shù)據(jù)庫的查詢壓力，同時對于文本類數(shù)據(jù)和外部文檔類數(shù)據(jù)入庫之后管理更加規(guī)范，數(shù)據(jù)倉庫保留歷史和不可變更的特性可以讓信息不被丟失;另一方面就是從數(shù)據(jù)的使用上，數(shù)據(jù)倉庫讓數(shù)據(jù)的獲取和使用更加簡便，集成細節(jié)數(shù)據(jù)讓大量的文本型數(shù)據(jù)可查詢，可關(guān)聯(lián)，而面向主題的設(shè)計讓數(shù)據(jù)的展現(xiàn)和分析更有方向性和目的性，而且細節(jié)數(shù)據(jù)是支持數(shù)據(jù)分析和數(shù)據(jù)挖掘應(yīng)用所必不可少的。所以，如果數(shù)據(jù)倉庫要不斷地催生出更大的價值，細節(jié)數(shù)據(jù)的存儲是必不可少的。

　　Q3、你會把數(shù)據(jù)倉庫分為幾層，每層的數(shù)據(jù)作用是什么?

　　沒有標準答案，根據(jù)數(shù)據(jù)倉庫中數(shù)據(jù)的復(fù)雜性和對數(shù)據(jù)使用的需求程度，數(shù)據(jù)倉庫可以有不用的層級劃分。

　　我一般會把數(shù)據(jù)倉庫劃成三層：最底層的細節(jié)數(shù)據(jù)，管理策略是優(yōu)化存儲，一般存儲導(dǎo)入的原始數(shù)據(jù)，便于進行向上的統(tǒng)計匯總，因為數(shù)據(jù)量較大所以需要優(yōu)化存儲;中間層是多維模型，管理策略是優(yōu)化結(jié)構(gòu)和查詢，面向主題的多維模型的設(shè)計，需要滿足OLAP和數(shù)據(jù)查詢的多樣需求，同時保證查詢的便捷性，關(guān)鍵在與維表的設(shè)計和維度的選擇及組合，事實表需要關(guān)注存儲和索引的優(yōu)化;最上層是展現(xiàn)數(shù)據(jù)，管理策略是優(yōu)化效率，一般會存放每天需要展現(xiàn)的匯總報表，或者根據(jù)多維模型拼裝的視圖，展現(xiàn)層的數(shù)據(jù)需要以最快的速度展現(xiàn)出來，一般用于BI平臺的Dashboard和報表。

　　Q4、數(shù)據(jù)倉庫搭建中最繁雜的事情是什么，最容易缺失的是哪一塊?

　　一直覺得數(shù)據(jù)倉庫的核心不在于數(shù)據(jù)集成，當然數(shù)據(jù)集成是數(shù)據(jù)倉庫實現(xiàn)價值的前提，數(shù)據(jù)倉庫真正的價值體現(xiàn)在數(shù)據(jù)的有效應(yīng)用，數(shù)據(jù)源于業(yè)務(wù)反作用于業(yè)務(wù)。而搭建數(shù)據(jù)倉庫的核心在于數(shù)據(jù)倉庫的架構(gòu)和數(shù)據(jù)模型的設(shè)計，怎么權(quán)衡數(shù)據(jù)的存儲和數(shù)據(jù)獲取效率之間的矛盾是數(shù)據(jù)倉庫管理上的難點，這個難點任何數(shù)據(jù)倉庫都會存在，而大數(shù)據(jù)增大了這種權(quán)衡中的難度。而數(shù)據(jù)的集成和數(shù)據(jù)質(zhì)量控制是數(shù)據(jù)倉庫搭建中最繁雜的事情，尤其是數(shù)據(jù)清洗的過程，我之前也寫過幾篇數(shù)據(jù)質(zhì)量控制的文章，但現(xiàn)實中這個過程還要復(fù)雜得多，而且為了上層數(shù)據(jù)產(chǎn)出的準確性和有效性，這項工作又不得不做，而且要做得盡量細致。

　　搭建數(shù)據(jù)倉庫中最容易缺失的就是對元數(shù)據(jù)的管理，很少有數(shù)據(jù)倉庫團隊具備完整的元數(shù)據(jù)，當然搭建數(shù)據(jù)倉庫的工程師本身就是活的元數(shù)據(jù)，但無論是為了用數(shù)據(jù)的人還是數(shù)據(jù)倉庫自身的團隊著想，元數(shù)據(jù)都不可或缺。一方面元數(shù)據(jù)為數(shù)據(jù)需求方提供了完整的數(shù)據(jù)倉庫使用文檔，幫助他們能自主地快速獲取數(shù)據(jù)，另一方面數(shù)據(jù)倉庫團隊成員可以從日常的數(shù)據(jù)解釋中解脫出來，無論是對后期的不斷迭代更新和維護還是培訓(xùn)新的員工，都非常有好處，元數(shù)據(jù)可以讓數(shù)據(jù)倉庫的應(yīng)用和維護更加高效。