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

之前看過Inmon的《構(gòu)建數(shù)據(jù)倉庫》和《DW 2.0》，而另外一位數(shù)據(jù)倉庫大師Kimball的《數(shù)據(jù)倉庫生命周期工具箱》一直沒有時(shí)間閱讀，最近才有時(shí)間看完了大部分，就迫不及待想寫點(diǎn)東西了。其實(shí)數(shù)據(jù)倉庫領(lǐng)域普遍認(rèn)為Inmon和Kimball的理論是對立的，兩者在構(gòu)建數(shù)據(jù)倉庫上方向性的差異一直爭論不休，誰也無法說服誰到底哪種方法更好。我的Evernote的筆記里面不知什么時(shí)候從哪里摘錄過來了對兩者觀點(diǎn)的概括性描述，非常簡潔明了而一針見血：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者：?joegh （《網(wǎng)站分析實(shí)戰(zhàn)》作者）

來源：《網(wǎng)站數(shù)據(jù)分析的一些問題3》