BI應用中的矛盾（轉）

　　因為近期工作的變更，一直在忙一些雜七雜八的東西，工作交接、離職手續及對新工作的思路整理，目前還處在這個階段，所以可能近期沒有比較新的內容跟大家分享，最近的幾篇文章會以一些總結的內容為主，主要是對之前的工作中的一些感想。但相信之後會有更加豐富的數據分析相關的內容向大家呈上，因為我相信我要去的新公司是一個朝氣蓬勃、充滿創意和挑戰的地方，而最重要的是他們對數據的重視和理解。

　　看到文章標題，相信大家已經知道這篇文章還是關於BI方面的，其實這是我剛進現在所在公司的時候所寫的一篇文章，現在回頭看來即使一直努力地在協調好這些矛盾，但說實話最終沒有一個是真正完完全全的解決了的。我相信如果其他公司也是自己搭建BI系統的話，多多少少也會遇到這些問題，可能其中的一兩個矛盾現在也正困擾著大家，我這裡提供了我的解決方案，至於可行性和效果，有待大家去驗證。

矛盾一：業務部門對數據的理解與數據部門對需求的理解

　　把它放在第一位是因為這個直接影響著數據所能發揮的效用，或者說這個矛盾沒協調好的話，數據所能創造的價值將大打折扣。造成這個矛盾的原因就是業務部門無法了解數據的獲取、處理、計算整個流程，從而對數據的含義和用處產生了自己的理解；同時數據部門無法真正了解業務需求，不清楚數據到底用於何處，為了監控或評估產品的哪個方面，於是無法提供最優或最有效的數據。

　　解決方案：建立業務部門與數據部門間的介面。這個介面包括規範的流程、詳細的文檔、合理的數據展現，而最重要的還是能夠銜接起業務和數據之間的人。

　　首先是數據需求流程的規範化，也就是需求一般由業務部門提起，通過數據部門對數據的獲取和計算將結果返回給業務部門，這個流程中業務部門不僅要提供數據的規則，同時應該對獲取數據的目的、指標的定義、用處和價值做出詳細的描述；而數據部門不僅要給出最終數據，同時需要對指標的獲取途徑、計算方法作出解釋，最終的目的都是為了使雙方在理解上能夠達成一致。

　　其次是詳細的文檔。這個其實就是上面所說的流程中必然會產生的兩類文檔：數據需求文檔和數據解釋文檔（在數據倉庫裡面是元數據的重要組成部分，關於數據倉庫的元數據一直想整理一篇文章出來，希望在之後儘快貼上來），文檔的內容基本就是包含上面流程中提到的那些內容。

　　再者就是合理的數據展現。其實就是一個原則：讓每個人看到自己想看的數據，並能直觀地理解這些數據。無論是報表、Excel還是其他展現方式，每個指標都應該能夠有途徑去直接查看相應的數據解釋文檔，而數據應該以最直觀的方式展現出來以方便理解，藉助各類圖表結合的方式。

　　最後也是最重要的一點就是業務與數據的銜接者。這類人員應該對產品的戰略目標、業務流程十分熟悉，同時對數據的獲取途徑、計算方法也了如指掌，或許不需要涉及高技術難度的數據ETL處理、組織和優化，但必須具備自己去計算和獲取各類數據的能力。

矛盾二：業務需求的不斷變化與生成數據的複雜流程

　　業務需求是不斷變化的，尤其是身在互聯網這個發展迅速的環境中。所以我們往往會遇到每天業務部門都會有新的需求過來，或者幾天前某個指標的計算邏輯在幾天之後就發生了變化。而數據部門面對這些情況，往往會陷入困境，一方面由於數據獲取上的問題導致某些指標沒法計算得到，另一方面指標計算邏輯的改變可能需要改動到整個複雜的數據處理流程，令人頭疼。

解決方案：集成化的完整的底層數據與快速靈活的數據獲取途徑。

　　其實在關於數據倉庫架構的文章中就提到過數據倉庫盡量保存所有的底層細節數據，包括原始的日誌點擊流數據和前台資料庫的ODS數據以及其他來源的數據，其實我不太建議數據倉庫是單純根據需求建立起來的多維模型，因為需求始終會變，但多維模型在應對變化時有缺失靈活性。而如果保存的底層數據，其實在大部分時間內就能做到以不變應萬變，因為幾乎所有的指標都是從這些底層數據中計算得到的，擁有了底層數據相當於滿足了大部分數據的需求。

　　還有一個問題就是對需求改變時的及時應變，一種方法是建立面向不同主題的多維模型（當然是在底層數據的上層建的），因為多維模型能夠滿足從多個角度多個層面對數據的觀察分析，能夠從一定程度上解決數據的多樣需求；同時基於底層數據集成化的組織管理環境，使用標準化的統計語言，如SQL語句，藉助其強大的對數據的聚合、排序、分組等能力，加速數據的獲取和計算。

矛盾三：數據即時查詢的效率與海量數據的處理和建模

　　其實這裡又是一個權衡的問題，即如何在提供足夠豐富的指標的前提下保證數據的展現、獲取和查詢的效率能夠滿足數據需求方的要求。如果提供的指標不夠，或者數據的粒度不夠細，就無法滿足日常數據監控和分析需要；相反，如果每天計算和統計的指標過多或者數據分得太細，那麼顯然會增加伺服器運算的負荷，同時在數據查詢上的響應能力也會相應的下降。

解決方案：把握核心數據，建立合理的多維模型。

　　其實數據倉庫中海量數據的處理和查詢效率的問題本身就是一門很深的學問，涉及數據倉庫結構和ETL的優化、OLAP的優化（上一篇文章——OLAP的基本特徵有提到Oracle在這方面所做的優化），這裡不談論這些技術上的實現途徑，還是說應用上的。

　　核心數據，簡單說就是網站的目標、KPIs等，這些數據是從高層到基層人員都在時刻關注的數據，所以最優先的原則就是保證這些數據的查詢效率和及時響應。最簡單的做法就是這些指標獨立統計，不放入多維模型，只做每天的簡單聚合存入Summary表中直接供報表展現。

　　另一個就是建立合理的多維模型，說到合理這裡又要抱怨下，數據的需求方起初會漫無邊際地提各種需求，可能會有上百個指標，但一旦統計出來之後很少會有人真正去使用和分析這些指標（估計是因為看了會眼花），這個我在關於實時數據統計中提到過類似問題。因為在多維模型中增加一個維或維的層次加深一層，對於立方的數據是以乘積方式遞增的，比如增加一個100條記錄的維相當於立方的數據乘以100，或者時間維的粒度從天到小時，相當於數據量是原先的24倍，這個對於那些本身數據量就非常龐大的多維模型而言本身就是一場災難。所以建立多維模型時的原則是提供實際應用中需要的維和指標，同時把握好各個維的層次粒度。

　　上面就是我遇到的三大難題了，一下子又寫了這麼多，希望大家有耐心看完。其實之前的工作也較多地涉及了一些技術上面的東西，主要是Oracle和PL/SQL，由於對於那方面不是很擅長，另外博客主要面向網站數據分析方面的主題，所以很多總結的東西也不敢拿出來獻醜，如果大家希望也有這個方面的討論的，我可以分享幾篇上來，大家可以留言給我點建議