OLAP工具與商業智慧

企業為了確定經營戰略和市場戰略所進行的經營活動，在BI項目的分析決策過程中，需要基於多種報告和報表進行分析。理想的行銷活動展開，大多需要各個營業點的銷售報告，每種商品按季節銷售的業績圖表等，這就需

要大量準確的並且易於判斷的資料。

然而，對於作為使用者的一般員工或者IT部門員工來說，這是一個很大的工作量負擔。因為資料的分析需要先獲得必要的資料資訊，這就必須預Crowdsourced Security Testing道資料擷取和資料加工計算的方法。當然，還有必要掌握資料庫構成和資料存取語言的一些專門的知識。

 

因此這些工作以前全都是由IT部門人員用OLAP產品來完成的。資訊管理部門要根據使用者的要求把報表格式設計好，然後根據使用者的目的，開發出應用程式以及建立資料庫等來完成這項工作。

 

OLAP報表工具是指什嗎？

 

在報表市場上，有一個奇特的現象：IT部門的技術人員是企業所有部門中最不熟悉使用報表工具的部門人員，但報表的資料來自IT部門。IT部門往往利用OLAP的概念建設資料模型，根據資料模型來製作報表，因此對IT部門而言，報表工具是指OLAP工具中的報表展現部分，比如Crystal Report等等。

 

而在使用報表操作的業務人員眼裡，報表工具是代表報表本身功能（排版、計算、統計、圖形等）的產品，它目前只有一個產品來代表了，就是EXCEL。

 

OLAP報表產品最大的痛點在哪裡？

 

目前報表工具最大的痛點不在於報表的樣式（如斜線等），樣式雖較繁瑣但並非本質困難。最根本的痛點在於業務部門知道報表代表的真正含義，卻不知道報表的資料統計模型模型；而IT部門通過理解業務部門的描述，在資料庫端進行設定資料統計模型，卻對報表本身所代表的價值很難理解。

 

這樣的現狀，導致報表工具無法兩者兼顧，OLAP報表工具產品一直在資料模型設計層面（OLAP層面）和報表本身功能層面做出平衡。

 

目前OLAP報表產品製作複雜，報表一般會有什麼癥狀？

 

首先，由於IT部門建立的資料統計模型不完全適應，導致報表製作經常需要編寫代碼、準備資料（如幾十甚至上百行的SQL或預存程序），而且動輒就要進行繁瑣的子表拼接，即使這樣仍有許多報表無法完成，需與使用者商量改變，運算效能也很差。

 

其次，由於IT部門根據業務部門進行報表製作時，對報表樣式理解不專業，大部分報表採用拖拽式編輯，使報表樣式繪製麻煩。

 

最後，業務部門報表的變化很頻繁，導致IT部門模型設計和報表製作的滯後，業務部門工作受限，白費時間。

 

因此，在目前OLAP產品的設計下，BI項目變成日常統計系統，業務模型來自於諮詢專家，企業發展過程中業務模型的變化因為OLAP工具而無法快速實現，使企業丟失對BI的信心。可以毫不誇張地說，OLAP產品正在毀掉BI。

 

OLAP錯了還是使用者錯了？

 

這是一個困惑！其實我們可以從E.F.Codd博士定義的OLAP概念中找一找這個困惑的答案。OLAP是關聯式資料庫之父E.F.Codd於1993年提出的一種資料動態分析模型，它允許以一種稱為Cube的多維度結構，訪問來自商業資料來源經過彙總和組織整理的資料。以此為標準，OLAP作為單獨的一類產品同聯機交易處理（OLTP）得以明顯區分。

 

說起來有點深奧，其實並不複雜，OLAP最基本的概念只有三個：多維觀察、資料切入、CUBE運算。

 

關於多維角度：我們在平時工作中，會遇到各種問題，在分析問題的時候，同樣的現象，我們會從多個角度去分析考慮，有時我們還會從幾個角度綜合起來進行分析。這就是OLAP分析最基本的概念–從多個觀察角度的靈活組合來觀察資料，從而探索資料內在規律。

 

OLAP將資料分為兩種特徵，一種為表現特徵，比如一個銷售分析模型中的銷售額、毛利等；還有一種為角度特徵，比如銷售分析中的時間周期、產品類型、銷售模式、銷售領域等。前者是被觀察的對象，OLAP術語稱之為”度量資料”，後者為觀察視角，OLAP術語稱之為”維資料”。

 

如果建立這樣一個模型，我們就可以根據業務需求，從產品類型角度，去觀察各個銷售地區的銷售額資料（以產品類型和銷售地區為維、以銷售額為度量）；或者我們還可以從銷售模式的角度，去觀察各個銷售地區的銷售額資料（以銷售模式和銷售地區為維、以銷售額為度量）。

 

關於資料切入：在分析過程中，我們可能需要在現有資料基礎上，將資料進一步細化，以獲得更為精確的認識。這就是OLAP中資料切入的概念。

 

比如，在銷售分析中，當我們以產品類型和銷售地區為維、以銷售額為度量進行分析的時候，可能希望進一步觀察某類產品的不同銷售模式在各個銷售地區的表現，這時我們就可以在產品大類這個資料維下面，再加上一個銷售模式維，從而獲得相應的資訊。

 

關於CUBE運算：OLAP分析所需的未經處理資料量是非常龐大的。一個分析模型，往往會涉及數百萬、數千萬條資料，甚至更多；而分析模型中包含多個維資料，這些維又可以由瀏覽者作任意的提取組合。這樣的結果就是大量的即時運算導致時間的延滯。

 

我們可以設想，一個1000萬條記錄的分析模型，如果一次提取4個維度進行組合分析，那麼實際的運算次數將達到4的1000次方的數量。這樣的運算量將導致數十分鐘乃至更長的等待時間。如果使用者對維組合次序進行調整，或增加、或減少某些維度話，又將是一個重新的計算過程。

 

從上面的分析中，我們可以得出結論，如果不能解決OLAP運算效率問題的話，OLAP將是一個毫無實用價值的概念。那麼，一個成熟產品是如何解決這個問題的呢？這涉及到OLAP中一個非常重要的技術–資料CUBE預運算。

 

一個OLAP模型中，度量資料和維資料我們應該事先確定，一旦兩者確定下來，我們可以對資料進行預先的處理。在正式發布之前，將資料根據維進行最大限度的聚類運算，運算中會考慮到各種維組合情況，運算結果將產生一個資料CUBE，並儲存在伺服器上。

 

這樣，當終端使用者在調閱這個分析模型的時候，就可以直接使用這個CUBE，在此基礎上根據使用者的維選擇和維組合進行複運算，從而達到即時響應的效果。

 

從以上OLAP三點基本概念出發，我們可以在實踐中發現問題的所在，OLAP概念沒有錯，使用者也沒有錯，錯在目前業內的OLAP產品的設計思路上！

 

從OLAP產品來看，由於”多維角度”的變化來自於使用者部門，而IT部門採用的OLAP產品使”多維角度”轉化成資料庫設計，但為了實現”CUBE運算”，”度量資料”和”維資料”需要提前固化，這樣限制了業務部門對”多維角度”快速變化的要求，使BI項目變成了日常統計報表專案，使OLAP分析變得無法實現。

 

OLAP產品需要新一代工具

 

新一代OLAP工具設計的思想，不應該關注報表工具本身功能：IT部門不要製作報表，僅關注OLAP的功能，不需要做OLAP的報表展現，報表完全由業務部門來實現。主要基於以下兩點：

 

一．從案頭報表的使用能力和使用量來描述，業務部門的人員已經遠遠超過IT部門的人員，因此，IT部門目前不太可能提供出一個報表工具，來取代業務部門使用的案頭報表工具。

 

二．報表本身的含義需要業務部門用精湛的業務知識來詮釋，如果報表由IT部門來製作的話，會出現知識傳遞過程中的誤差，這是OLAP實施中最大的問題。

 

基於以上兩點，新一代OLAP工具設計思想就是：如何使OLAP工具和Excel報表工具能夠無縫交流，應該有一個”分析角度”的技術，來實現業務部門和IT部門對”多維角度”的各自表述。讓業務部門自己來做”分析角度”，自己來做報表，讓IT部門利用OLAP概念來設計基礎資料。