網(wǎng)站數(shù)據(jù)分析教程:關(guān)于網(wǎng)站數(shù)據(jù)分析常見問題

申請免費試用、咨詢電話：400-8352-114

從事數(shù)據(jù)倉庫和數(shù)據(jù)分析相關(guān)的工作也有段時間了，其實很多問題一直縈繞在腦中，有些甚至已經(jīng)困擾相當長的一段時間，自己也在不斷學習和工作的過程中尋找各種解決方案或者不斷優(yōu)化和替換之前的方案。這些問題從宏觀層面到細節(jié)層面，很多問題其實沒有絕對完美的解決方案，我們只能一步一步地摸索，不斷尋找更優(yōu)的方案以其讓問題能夠更好高效地得到解決，但每個人掌握的知識有限，所以無論怎么樣每個人對問題的看法都會存在局限性；同時因為每個人的知識背景和經(jīng)歷的差異性，對各種問題又會觸發(fā)各種不同的見解，所以通過集思廣益往往能夠得到讓人眼前一亮的結(jié)論。

先說說博客，無論怎么樣我的博客只是想做些記錄和總結(jié)，只是表述一些個人的觀點，我想每個人在學習工作中總會有所積累，有自己在專業(yè)領(lǐng)域的一些收獲，每個人公平地享有相同的時間，每個人學到的掌握的都是有限的，沒有孰強孰弱之分，差別只在于愿不愿意將其分享出來；博客中整理的內(nèi)容，可能有些人認為不適合公開，畢竟有些東西還有些實用價值，但必須看到的是目前互聯(lián)網(wǎng)發(fā)展速度太快了，我之前發(fā)的文章等半年之后回去看就會發(fā)現(xiàn)當時自己的想法并不成熟，如果在現(xiàn)階段可能不會完全按照上面的思路去實現(xiàn)了，知識的更新和積累讓我們不斷選擇更優(yōu)的方法，不斷改進和升級自身的知識體系，更何況很多東西在一個業(yè)務(wù)體系下適用，到另外的體系下就不適用了，聰明的人不會完全照搬照抄原方法，而是尋找最合適的方法，或者使用更靈活變通的方式去使用方法，所以也不必擔心技能被“偷學”，因為只會模仿的人不知道怎么用好這些方法，而足夠聰明的人到哪里都能學到適合自己的方法，在這個信息膨脹的環(huán)境下無法阻止他們的“偷學”。

其實博客最大的收獲還是通過博客認識了很多朋友，尤其是網(wǎng)站分析領(lǐng)域的，相當一部分也有自己的博客，大家互相交流學到了很多東西，有些東西是互補并相互促進的，這些朋友都是樂意分享自己想法的人，每個人都有各自領(lǐng)域的專業(yè)和強項，這樣反而使我聽到和學到了很多耳目一新的東西，受益匪淺。所以如果你有時間寫寫博客，那么得到的收獲絕對要比你覺得可能會失去的多得多。

既然我在博客里面已經(jīng)寫了很多，所以這里想換一個角色，我想通過幾篇文章把之前遇到的諸多問題羅列出來，希望大家能夠不吝提出自己的看法和解決方案。其實我更希望在博客的評論中看到更多不同的看法或者通過文章的思路擴展衍生出在其他方向上有價值的應(yīng)用。另外，知乎真的是一個非常棒的知識分享和學習的平臺，潛藏了很多的大牛，我會把整理的每個問題都貼到知乎上面，這樣可以收集到更多牛人的看法，希望大家在知乎上有認識相關(guān)領(lǐng)域的大牛的可以積極地進行邀請。

這篇是第一篇，想重點羅列一些跟網(wǎng)站數(shù)據(jù)分析行業(yè)和數(shù)據(jù)分析師相關(guān)的問題。

Q1、 你因何會選擇網(wǎng)站分析或互聯(lián)網(wǎng)數(shù)據(jù)分析這個行業(yè)，你認為這個行業(yè)的價值何在，發(fā)展前景如何？

我的答案：互聯(lián)網(wǎng)是一個陽光行業(yè)，而數(shù)據(jù)分析本身又是一個非常有意思的工作，很多時候，它就像是一個偵探從細枝末節(jié)的線索中尋找那個唯一的真相，如果你喜歡這種探秘的感覺，那么你同樣會喜歡上網(wǎng)站數(shù)據(jù)分析這個行業(yè)。

其實我之前在《網(wǎng)站分析的應(yīng)用和價值》這篇文章中介紹過網(wǎng)站數(shù)據(jù)分析的價值（這里不引用鏈接了，大家可以搜一下），簡單地說就是“系統(tǒng)地幫助網(wǎng)站實現(xiàn)更加高效的運營”。

互聯(lián)網(wǎng)數(shù)據(jù)量的快速膨脹，急需對數(shù)據(jù)進行系統(tǒng)化的處理和分析，以便快速地發(fā)現(xiàn)信息，轉(zhuǎn)化價值，所以就目前來看，無論是國外的發(fā)展趨勢，還是國內(nèi)對這個行業(yè)的需求都是快速增長的，發(fā)展前景是比較樂觀的。

Q2、 作為網(wǎng)站的數(shù)據(jù)分析師，你完成的最有成就感的事情是什么，感到最糾結(jié)的事情又是什么？

　　我的答案：最有成就感的事情就是用數(shù)據(jù)實現(xiàn)價值，無論是通過數(shù)據(jù)排查問題進而解決問題，還是通過數(shù)據(jù)分析應(yīng)用優(yōu)化網(wǎng)站產(chǎn)品，其實都是創(chuàng)造價值的過程。

最糾結(jié)的事情其實不是整日需要維護和驗證數(shù)據(jù)的一致性、準確性，數(shù)據(jù)時常會存在諸多細節(jié)上的問題，因為這些基本是必然存在的，無論在哪個公司，網(wǎng)站從事何種業(yè)務(wù)，技術(shù)或者數(shù)據(jù)的環(huán)境如何，數(shù)據(jù)的問題還是無所不在，而保證數(shù)據(jù)質(zhì)量本身就是數(shù)據(jù)分析師最基礎(chǔ)的工作，也是開展分析的前提和基礎(chǔ)。

我最糾結(jié)的還是在于數(shù)據(jù)的需求和應(yīng)用，如果與數(shù)據(jù)的需求方在數(shù)據(jù)的理解上達不成一致，那么很多數(shù)據(jù)需求就會存在反復(fù)的調(diào)整變動，期間就會做很多重復(fù)的工作或者無用功，甚至有些時候數(shù)據(jù)分析師大費周章地提取的一份數(shù)據(jù)在需求方那里只是用幾秒鐘掃視一遍，沒有產(chǎn)生任何的價值，這也是令數(shù)據(jù)分析師最傷感的事情。所以數(shù)據(jù)分析始終要從獲取最終insight的角度出發(fā)，如果數(shù)據(jù)需求中無法說明獲取數(shù)據(jù)是為了試圖得出何種insight，那么這個需求基本就沒有實現(xiàn)的必要了。

Q3、 作為網(wǎng)站的數(shù)據(jù)分析師，你日常工作中最常做的是什么，需要與哪些同事交流，一般會用到哪些工具？

　　我的答案：數(shù)據(jù)分析師的日常工作很簡單，就是數(shù)據(jù)處理和觀察報表，而且這兩塊工作會占用每天的大部分時間。如果每天能夠準時提供準確的報表，及時地反饋數(shù)據(jù)異常，那么你已經(jīng)是一個合格的數(shù)據(jù)分析師了。

數(shù)據(jù)分析師要接觸的部門會比較多，可以是任何有數(shù)據(jù)需求的部門，運營、產(chǎn)品、市場、銷售、客服……甚至是各層級的BOSS。

同樣，數(shù)據(jù)分析師日常使用的工具其實也非常簡單，估計在90%的時間都在使用數(shù)據(jù)庫的SQL、Excel或者PPT，當然視每個公司的情況會有差異。所以如果你聽到某位數(shù)據(jù)分析師說他天天在研究什么什么樣的高級分析方法或者高深的數(shù)據(jù)算法，天天在使用R、SPSS、SAS，那么不排除有裝X的嫌疑。

Q4、 在你剛剛步入網(wǎng)站數(shù)據(jù)分析的工作，或者你曾經(jīng)新到一個公司或者網(wǎng)站從事數(shù)據(jù)分析師的工作，你是如何著手開始你的新工作的，你覺得你需要了解哪些東西，會從哪些方面優(yōu)先開始學習？

　　我的答案：“業(yè)務(wù) => 網(wǎng)站或產(chǎn)品 => 數(shù)據(jù)處理流程 => 指標和報表”，我的基本流程就是這樣的，當然這個也不絕對是前后的順序，可以是同時結(jié)合著看的。

數(shù)據(jù)分析的重點不在于數(shù)據(jù)而在于分析，分析針對的是業(yè)務(wù)，所以業(yè)務(wù)是首要了解的東西，就像一個人做事情，首先要明確的是要做的是什么事情；然后是網(wǎng)站或產(chǎn)品，它是實現(xiàn)業(yè)務(wù)的媒介，就像是做事情時使用的工作或方法；數(shù)據(jù)的處理流程包括了數(shù)據(jù)的獲取、處理和存儲模型，它是記錄信息，可以看做是日記，記錄了一個人做事情的整個流程；指標和報表就是為了將一個人做事情的整個流程復(fù)述出來，把握重點同時又不失關(guān)鍵細節(jié)，所以必須要了解指標的統(tǒng)計規(guī)則和報表的展現(xiàn)方式，以便更好地突顯重點，了解省略的細節(jié)，讓復(fù)述貼近事實。

很明顯，當你了解了這個人在做什么事情之后再去閱讀這個人在做事情時記錄的信息或聽取復(fù)述要遠比你直接通過復(fù)述內(nèi)容或者閱讀記錄信息來猜測這個人在做什么事情來得高效得多。

主要想羅列一些關(guān)于BI的問題。

BI（Business Intelligence，商業(yè)智能），先看一下維基百科上面對BI的定義：

Business intelligence (BI) is defined as the ability for an organization to take all its capabilities and convert them into knowledge.

BI提供大量有價值的信息引導企業(yè)尋找新的發(fā)展機遇，當企業(yè)認識到潛在的機遇并成功地實施相應(yīng)戰(zhàn)略決策的時候，BI就能幫助企業(yè)在市場建立競爭優(yōu)勢并維持企業(yè)持續(xù)地發(fā)展。BI時常跟決策支持系統(tǒng)（Decision Support System, DSS）聯(lián)系在一起，其實BI最主要的目標就是實現(xiàn)對企業(yè)的決策支持。

下面就探討幾個BI方面的問題：

Q1、BI與數(shù)據(jù)倉庫（DW）之間的關(guān)系是怎么樣的？

　　首先可以明確的是BI的重點在于對數(shù)據(jù)的應(yīng)用上，讓數(shù)據(jù)變成有價值的信息，而所有的基礎(chǔ)數(shù)據(jù)基本都是來源于數(shù)據(jù)倉庫。

BI有兩個方向的定義：廣義的BI是包含數(shù)據(jù)倉庫的，廣義的BI包括數(shù)據(jù)的獲取、處理、儲存，到之后的分析、挖掘、展現(xiàn)變成有價值信息的整個過程，組成了一套完整的系統(tǒng)，當然在這個系統(tǒng)中數(shù)據(jù)倉庫擔當著從數(shù)據(jù)獲取之后的處理和存儲的職責，是基礎(chǔ)組成部分；狹義的BI僅僅包括上層的數(shù)據(jù)應(yīng)用，包括數(shù)據(jù)的展現(xiàn)、分析、挖掘等，所以不包括數(shù)據(jù)倉庫。

因為BI的定義更側(cè)重于數(shù)據(jù)應(yīng)用，而隨著數(shù)據(jù)量的不大擴大，數(shù)據(jù)倉庫更多地被作為一項獨立的技術(shù)被抽離出來，所以當前BI和數(shù)據(jù)倉庫的定義更傾向于分離，整個系統(tǒng)被叫做“DW/BI”的解決方案。

Q2、BI系統(tǒng)主要是為了幫助企業(yè)解決什么樣的問題？

　　BI最初的目標就是優(yōu)化企業(yè)的決策支持，實現(xiàn)從數(shù)據(jù)到有價值的信息的轉(zhuǎn)化，輔助企業(yè)商業(yè)戰(zhàn)略和決策的制定。所以BI的最終目標是獲取商業(yè)的Insight。

BI首先實現(xiàn)的是企業(yè)數(shù)據(jù)的透明化，原始的數(shù)據(jù)報表就是為了從數(shù)據(jù)的角度定量地掌握企業(yè)的運營狀態(tài)，有了數(shù)據(jù)的支撐，很多決策的制定就會有了參考依據(jù)。隨著商業(yè)和信息技術(shù)的不斷發(fā)展，BI不再僅僅停留在報表的領(lǐng)域，數(shù)據(jù)除了展現(xiàn)以外被更多地用于商業(yè)分析，而商業(yè)分析的基礎(chǔ)組成就是統(tǒng)計、預(yù)測和優(yōu)化，這些對企業(yè)的運營決策起到了更加關(guān)鍵的作用。但隨著信息膨脹，數(shù)據(jù)量的劇增，BI也不斷面臨挑戰(zhàn)，我們需要花更多的成本去處理和存儲數(shù)據(jù)，需要花更多的精力去分析和應(yīng)用數(shù)據(jù)。我之前寫過BI應(yīng)用中的三大矛盾這篇文章，因為有段時間了，很多地方的看法可能有了變化，但這3個矛盾相信依然還是存在。

所以，最終還是要把握BI的輸出是有價值的信息，無論中間的處理方式是查詢、報表，還是分析、挖掘，最終要得出的是有價值的結(jié)論。

Q3、目前BI的應(yīng)用或組件主要有哪些？

這里簡單地歸納了一下，可能會有遺漏，希望大家能夠在評論中補充。這里僅僅包括狹義BI中基于數(shù)據(jù)應(yīng)用層面的一些功能，數(shù)據(jù)倉庫的數(shù)據(jù)處理方面的應(yīng)用不在這里羅列。

首先是報表、圖表和Dashboard，目前的報表和圖表除了更加豐富以外，跟傳統(tǒng)報表還有一個關(guān)鍵的區(qū)別就是可交互性。目前的報表基本都提供簡單的數(shù)據(jù)篩選、排序等功能，Dashboard的出現(xiàn)實現(xiàn)了按需整合報表和圖表的功能。

再則是OLAP，OLAP一度被當做BI的核心功能，不得不承認OLAP是分析數(shù)據(jù)最有效的手段，尤其是基于多個維度多個層面的分析，這些是一兩張報表圖表所無法做到的。OLAP一般都是基于已經(jīng)設(shè)計成型的多維模型以及存放多維模型的數(shù)據(jù)集市（Data Mart），數(shù)據(jù)集市和OLAP跟業(yè)務(wù)層面有著很多關(guān)聯(lián)，這個使數(shù)據(jù)集市跟底層的數(shù)據(jù)倉庫有了區(qū)分。

然后是數(shù)據(jù)的查詢和分析，有時基于既定的模型的OLAP無法滿足分析的需求，所以就有了數(shù)據(jù)查詢的需求，一般直接查詢數(shù)據(jù)倉庫的細節(jié)數(shù)據(jù)；BI中的Ad-hoc Query則是對既定多維模型的靈活查詢，可以自由組合維度和度量。

最后是報表的發(fā)布和數(shù)據(jù)預(yù)警，這都是屬于BI平臺的推送功能，一般可以通過郵件訂閱的形式定期把組合的報表推送給相關(guān)的人員，而通過預(yù)警的設(shè)定，可以監(jiān)控數(shù)據(jù)的變化趨勢，掌握數(shù)據(jù)可能出現(xiàn)的異常。

另外BI還有很多新奇的功能，如基于GIS的地圖數(shù)據(jù)、基于Flash實現(xiàn)的動態(tài)圖表及對數(shù)據(jù)挖掘功能的集成等。

Q4、BI中的多維數(shù)據(jù)模型和OLAP的實用價值在哪？

之前有關(guān)于多維數(shù)據(jù)模型和OLAP的介紹，可以參考數(shù)據(jù)倉庫的多維數(shù)據(jù)模型和數(shù)據(jù)立方體與OLAP這兩篇文章中的內(nèi)容。

其實多維數(shù)據(jù)模型和OLAP最主要的是解決了如何有效地觀察數(shù)據(jù)的問題，傳統(tǒng)關(guān)系模型很難直接對數(shù)據(jù)進行觀察分析，而多維模型為數(shù)據(jù)觀察者提供了清晰的視角，就如平常我們從多個角度看待事物一樣，多維模型維度的設(shè)計就很好地提供了這些角度的選擇。而OLAP的幾個操作形式正是體現(xiàn)了“分析”這個詞本身的含義，從總體到細節(jié)，結(jié)合多個維度的交叉分析，讓我們具備了對整個數(shù)據(jù)集進行全景觀測的能力。

OLAP最關(guān)鍵的技術(shù)除了多維模型設(shè)計還有就是預(yù)計算（Precomputation），或者叫預(yù)聚合，預(yù)計算解決了數(shù)據(jù)快速獲取的問題，基于一定的規(guī)則或者算法對數(shù)據(jù)集進行預(yù)計算之后，OLAP的操作性能可能得到有效地提升，從而使對大量數(shù)據(jù)的快速靈活的分析操作成為可能。

Q5、目前市場上主流的BI產(chǎn)品主要有哪些？

市場上主要的商業(yè)BI產(chǎn)品包括IBM的Cognos，另外IBM有自己的DB2可以建立數(shù)據(jù)倉庫，在2010年收購SPSS之后，讓其在數(shù)據(jù)分析和數(shù)據(jù)挖掘的領(lǐng)域也更加具有競爭力、SAP的Business Objects（BO），另外SAP有BW（Business Information Warehouse），作為傳統(tǒng)的ERP方案提供商在數(shù)據(jù)集成方面有獨特的優(yōu)勢、Oracle的BI（企業(yè)級的叫BIEE，Oracle Business Intelligence Enterprise Edition），Oracle借助其強大的關(guān)系型數(shù)據(jù)庫建立數(shù)據(jù)倉庫有獨特的優(yōu)勢。這3大商業(yè)BI都屬于整合型的BI，再加上微軟借助Sql Server數(shù)據(jù)庫提供的SSIS、SSAS和SSRS也是屬于整合型的BI解決方案。另外也有獨立的BI公司，如SAS，傳統(tǒng)優(yōu)勢在數(shù)據(jù)挖掘領(lǐng)域、Micro Strategy的BI解決方案、開源強大的BI系統(tǒng)Pentaho（之前幾年還有很多開源的BI系統(tǒng)，但因為BI在技術(shù)上有一定的門檻和成本，所以目前很多開源BI 都會包括開源版本和商業(yè)版本，Pentaho也不例外），國內(nèi)也有用友的BQ軟件也是屬于BI產(chǎn)品。

歸納一下就是目前的BI產(chǎn)品主要以商業(yè)產(chǎn)品為主，而且整套的BI產(chǎ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為主導的數(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ù)源計算聚合之后導入數(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)化存儲，一般存儲導入的原始數(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ù)解釋中解脫出來，無論是對后期的不斷迭代更新和維護還是培訓新的員工，都非常有好處，元數(shù)據(jù)可以讓數(shù)據(jù)倉庫的應(yīng)用和維護更加高效。

寫在最后：以上僅代表個人觀點，歡迎大家踴躍拍磚，更加希望高手們能在評論中給出寶貴的答案，任何角度的觀點和討論都可以，集思廣益。