之前的文章——網站資料分析的一些問題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、資料倉儲搭建中最繁雜的事情是什麼，最容易缺失的是哪一塊?
一直覺得資料倉儲的核心不在於資料整合，當然資料整合是資料倉儲實現價值的前提，資料倉儲真正的價值體現在資料的有效應用，資料來源於業務反作用於業務。而搭建資料倉儲的核心在於資料倉儲的架構和資料模型的設計，怎麼權衡資料的儲存和資料獲取效率之間的矛盾是資料倉儲管理上的難點，這個難點任何資料倉儲都會存在，而大資料增大了這種權衡中的難度。而資料的整合和資料質量控制是資料倉儲搭建中最繁雜的事情，尤其是資料清洗的過程，我之前也寫過幾篇資料質量控制的文章，但現實中這個過程還要複雜得多，而且為了上層資料產出的準確性和有效性，這項工作又不得不做，而且要做得儘量細緻。
搭建資料倉儲中最容易缺失的就是對後設資料的管理，很少有資料倉儲團隊具備完整的後設資料，當然搭建資料倉儲的工程師本身就是活的後設資料，但無論是為了用資料的人還是資料倉儲自身的團隊著想，後設資料都不可或缺。一方面後設資料為資料需求方提供了完整的資料倉儲使用文件，幫助他們能自主地快速獲取資料，另一方面資料倉儲團隊成員可以從日常的資料解釋中解脫出來，無論是對後期的不斷迭代更新和維護還是培訓新的員工，都非常有好處，後設資料可以讓資料倉儲的應用和維護更加高效。