商業(yè)智能(BI)功能模組特性分析參考分享

拆解BI套件—主要BI功能特性分析近幾年來的BI市場雖然已經上演了很多的大魚吃小蝦事件，但仍然有不少的供應商，產品套件也是琳瑯滿目，SASEnterpriseBIServer、CognosBISeries、BusinessObjectsEnterprise、Hyperion、MicroStrategy、MicrosoftReportingServices但是，嚴峻的現(xiàn)實是，在通往 BI產品選擇和標準化的路上依然布滿荊棘，很少有人能夠理解這些產品中有哪些差別， 這些差別又會怎樣影響到可用性、 可管理性、成本以及最終的成功。當人們購買轎車的時候，他們知道污染、汽油價格等的影響，但是在 BI工具的選擇和標準化時，諸如“帶狀報表（ bandedreport）”或“multipassSQL”這樣的特性對不同的人就是不同的意思，取決于他是用戶、 BI專家還是 BI廠家。查詢首先來看查詢（Query）功能，也就是怎樣把數(shù)據(jù)從數(shù)據(jù)的大倉庫或運作的系統(tǒng)中取出來。在決定哪一個標準重要之前，企業(yè)組織首先必須回答幾個策略性問題：誰來制作大多數(shù)的報表，是業(yè)務強大用戶還是IT開發(fā)者？答案也許是“兩者”，但是對每組用戶的重要功能是截然不同的，這就迫使你或者選擇多種工具（盡管可能是來自一家廠商），或者要求一部分使用者犧牲功能。Web是制作報表的環(huán)境還是僅僅為一個發(fā)布機制？很多最初為桌面構建的 BI產品仍然與Web類產品有功能差異（雖然這個差距在縮?。?。需要指出的是，由于很多現(xiàn)實原因，使用者需要同時查詢多種數(shù)據(jù)資源，有時可能需要把兩種數(shù)據(jù)顯示為兩種不同目標形式，如，一個消費者收入的表格和一個消費者滿意度圖形同時顯示。另外的情形是，數(shù)據(jù)可能存儲在兩個不同地方，但使用者需要合并兩套數(shù)據(jù)并在一個表格中進行分析。理論上說，所有的數(shù)據(jù)都已經被清洗并存儲在數(shù)據(jù)倉庫之中，但實際上，在多數(shù)據(jù)庫的情況下可能存在不同的版本，包括個人電子數(shù)據(jù)表或部門的數(shù)據(jù)庫。所以收入可能出自數(shù)據(jù)倉庫，但消費者分組及產業(yè)分割可能是在MicrosoftAccess數(shù)據(jù)庫中。實際產品的功能表現(xiàn)也不盡相同。雖然BusinessObjectsuniverse只允許訪問單一數(shù)據(jù)庫，但個別的文件允許使用者同時訪問多種數(shù)據(jù)庫、存儲的程序以及個人電子數(shù)據(jù)表，這給查詢者制作報表提供了相當靈活性，也是WebIntelligence不具備的功能之一。CognosReportNet產品包通過ODBC為多數(shù)據(jù)資源服務。然而，一個報告只能查詢一個包，這給了管理者控制權但限制了使用者的靈活性。同樣，QueryStudio也只能顯示一個表格或圖表結果，但ReportStudio具有更大的靈活性。Informatica的PowerAnalyzer在管理者定義數(shù)據(jù)資源之后，允許一個報告訪問多種數(shù)據(jù)資源，結果只能顯示一個圖表。通過MicroStrategy7.5的新DocumentEditor(桌面)，你可以在一個項目中包含多種查詢，但項目只能訪問一種關系型數(shù)據(jù)庫中的數(shù)據(jù)，因為這種訪問只是在格式化的文件中進行，OLAP分析或鉆取(drill-down)對這種文件是不可用的。Microsoft的ReportingServices允許一個文件訪問多種數(shù)據(jù)資源，顯示結果可以是兩個或一個。報表坦白地講，報表的聲譽并不好。出自大型主機打印機的大量不鼓舞人的文件報表創(chuàng)造了那么多的原始數(shù)據(jù)，但很少對決策有用。把注意力放在文件報表上幾乎很難付諸行動。相反，分析卻很容易付諸行動，這也就是許多報告消費者努力的方向。令人振奮的消息是報表正在改變，如同轎車從單純的使用機器走向奢華、炫耀的工程之作一樣，今天的報表已經能夠服務于更敏捷的、更具有競爭性的行動。首先，隨著用戶期待指數(shù)的提升，對報表工具支持復雜文件、原始數(shù)據(jù)查詢以及在一頁或一個報表中以多種方法展現(xiàn)等的需求也隨之而來。例如，你可能需要在看到延期交貨訂單的詳細表列數(shù)據(jù)的同時，在其旁邊看到一個能顯示未決定、延期、準時出貨百分比分布的餅狀圖。是否要使用帶狀報表（bandedreport）去控制報表設計，也是廠商們最近爭論比較多的地方，他們的爭執(zhí)點是關于“怎樣”，而不是“什么”的問題。從一個用戶的立場，應該關注的是你是否能夠擁有分組、小計以及詳情等。不過，不同產品實現(xiàn)這些目標的方法也不同。像MicroStrategy的ReportServices使用了帶狀報表，需要你把小計放到報頭或尾部，在主體部分是詳情，圖表也必須出現(xiàn)在報頭或尾部。像BusinessObjectsEnterprise、CognosReportNet、MicrosoftReportingServices等其他BI產品，使用頁面設計概念，這樣你可以在任何你需要的地方放總計及詳情，它們只是獨立的對象，其位置你可以自由控制。概要圖表也可以出現(xiàn)在頁面上任何你需要的地方。兩種方法的結果很類似，但設計方法卻截然不同，帶狀報表結構可能對傳統(tǒng)大型主機報表開發(fā)者更熟悉，頁面設計概念則對Excel、PowerPoint或HTML開發(fā)人員更熟悉。下面說說圖表。圖表的表現(xiàn)價值勝過千言萬語。但不幸的是，很多報表開發(fā)者仍然使用傳統(tǒng)表列數(shù)據(jù)，其實圖表是最方便于分析的工具。所有廠商都提供同樣的基本圖表類型：柱狀、線形和餅狀圖，但只有少數(shù)提供map、bubble等獨特的圖表類型。在圖表類型中，使用者需要具備控制不同圖表屬性的能力，如min/max刻度、標志布置、3D效果、個別線條或條棒的顏色等。雙Y軸的能力是繪制多度量器時的必備條件。例如，如果你分析隨著時間推移價格對銷售量的影響，你就必須要有兩個Y軸。BusinessObjects在其桌面工具中提供這個功能，但在其WebIntelligence中并沒有提供。CognosReportNet也有類似的局限性。再看報表協(xié)作性。報表消費者（典型的商業(yè)業(yè)務使用者）能夠與報表相結合的程度也是一個重要的衡量標準。不能提供協(xié)作性的報表只不過是使分發(fā)“啞巴”紙質報表的過程自動化而已。發(fā)現(xiàn)一個趨勢圖中的異常只是商業(yè)洞察力的第一步；能夠研究這種異常才是關鍵性的第二步。即使BI工具提供了一定程度的協(xié)作性， 一些使用也會限制它。聰明的使用者會自動輸出數(shù)據(jù)到 Excel，創(chuàng)造多種版本的真相，這是目前一種更加危險的狀況。協(xié)作性有兩方面：單獨的報表協(xié)作性，跨越多種報表導航。在兩種情況下，報表和 OLAP鉆取之間的分界線正變得越來越模糊不清。BusinessObjectsWebIntelligence 提供了很好的單獨報表協(xié)作性； MicrosoftReportingServices 提供了模擬鉆取(出)的一個獨特大綱視圖，但它缺少過濾和分組。 CognosReportNet 在單獨報告協(xié)作性方面較弱，只提供了一個靜態(tài)頁面，但是 ReportNet 提供了很好的全面導航功能，允許在報告之間鉆取 (出)以及報告與其他應用之間的鉆?。ǔ觯?CognosPowerPlay 和Visualizer 。InformaticaPowerAnalyzer 的導航功能非常獨特。勝過從一個報告到另一個報告的鉆取， PowerAnalyzer 使用了“工作流（workflow ）”的概念，使用者看到一個可選擇報告的列表，而不是只能在一個靜態(tài)的子報告中挑選，一個主報告可以有多種工作流，靈活地提供了更多導航。需要指出的是，文件復雜性、圖表、協(xié)作性等只是各 BI廠家提供的一些主要差異性報表特性，諸如有條件格式化、相對定位以及格式紙等另外的一些特性也會影響報表設計。信息發(fā)布查詢和報表使你把原始數(shù)據(jù)轉變成能促進決策行動的強大的文件， 然而，除非你已經把那些文件放到決策制定者手中，否則數(shù)據(jù)間的鏈條仍然是斷開的。接下來就要依賴于信息發(fā)布（ informationdelivery ）功能了。兩種技術對企業(yè)信息發(fā)布有重大影響： Web和email。過去，信息遞送過程包括走向打印機、 拿到打印輸出，或者傳達室把報告遞到你手上。 在20世紀90年代后期，很多公司有了企業(yè)內部網絡，開始把標準報表輸出到內部網上，這些報表可能是電子數(shù)據(jù)表文件或以HTML保存的靜態(tài)BI報表。今天，BI報表按照BI工具賦予的文件格式存儲，擁有更多協(xié)作和更新數(shù)據(jù)的能力， Web和email也擴展了報表傳遞的范圍，盡管當初上百用戶執(zhí)行 BI就被認為是很大規(guī)模，今天所謂大規(guī)模已經是好幾萬的概念。這樣，可擴展性就成為衡量信息發(fā)布功能的一個主要因素：一個報表必須到達多少使用者以及怎么樣到達。評估各廠家BI工具的可擴展性并不容易，因為不同產品擴展方式不同，仔細查看公開的基準測試結果、查看消費者指南手冊、理解其架構是評估一個產品是否能按照你的期望擴展的必要步驟。按照信息發(fā)布來評估可擴展性要求， 你還必須考慮使用者怎樣與報表相互作用。 一種所謂的push（相對于pull）方法是，BI工具按照計劃產生報表，然后通過email或無線設備等門戶把這些結果推向最終使用者。乍看，push方法好像是管理可擴展性的理想方法，因為IT能夠預先決定什么時候處理大量BI作業(yè)。但是，就像一個執(zhí)行主管反映的，他經常被報表email所淹沒，現(xiàn)在他通常是刪除，因為他認為如果真的有問題的話，肯定會有人打電話給他。很顯然，并不在于說你推出去多少個報告，而要看多少人在做決策的時候真正使用了這些報告。而且，還必須考慮你強行推給用戶的是一種靜態(tài) PDF附件還是一個到 BI報告的URL，如果是PDF，擴展性需求并不是很嚴重， 因為PDF是預先制作好的，使用者在瀏覽報表的時候不會對 BI應用服務器造成壓力；但 URL情形則需要更多的擴展性，因為使用者要訪問 BI應用服務器。push方法還包含“bursting問”題，也就是拿到一個大型報告，并分解，以便不同使用者只能得到允許的或需要看到的數(shù)據(jù)，如，每一個人事主管只能看到其職工的薪酬。這種個性化無論從安全方面還是從管理信息超載方面都非常重要。在大多情況下，bursting能減輕RDBMS（關系型數(shù)據(jù)庫管理系統(tǒng)）的一些負荷，因為許多的人事主管并不需要運行許多的單獨查詢，而是，運行一個大型查詢，其結果被分為多個部分。然而，bursting的實現(xiàn)方法也不同，也不總是能提供這種優(yōu)勢。比如，在BusinessObjects提供的兩種bursting方法中，一種就是通過BroadcastAgentScheduler為每一組接受者運行查詢，這種技術允許公司使用獨立數(shù)據(jù)庫登錄，并具有安全性，但它會給RDBMS造成不必要的負荷。CognosImpromptu也使用這種方法。圖1BusinessObjects的InfoViewPortal允許使用者創(chuàng)建可作為dashboard使用的MyInfoView,內容包括報、WebURL等.不過，大多數(shù)的產品，包括BusinessObjectsBroadcastAgentPublisher及CognosReportNet，都是使用運行一個查詢、然后分裂為多個單獨報表的方法，這樣減少了查詢對RDBMS的訪問。久經考驗的pull方法是廣大最終使用者喜歡的方法，然而它對IT部門和廠商提出了更多挑戰(zhàn)。這種方法是使用者登錄到BI的工具，有選擇地尋找他們需要的報告。schedule-and-pull取代schedule-and-push方法的過程將是很緩慢的。有重現(xiàn)信息需求的使用者可能會把查詢更新的時間安排在非高峰時間，或者說，IT可能會將高使用率的報表安排為整晚更新，以便其結果能夠預先緩存給使用者。schedule-and-pull的方法減少了BI應用服務器的負荷，從而讓它能支持并發(fā)的查詢更新以及復雜文件的產生等。專門的BI門戶能夠讓使用者訪問標準的報表或個人報表。對于一些已經實現(xiàn)企業(yè)范圍門戶解決方案的公司來說，與Plumtree、IBMWebSphere或MicrosoftSharepoint等門戶產品集成是非常重要的。根據(jù)你不同的策略，你也許：把特定的BI功能嵌入企業(yè)門戶中；從企業(yè)門戶內部訪問專門的BI門戶；通過WebURL訪問專門的門戶。好的BI門戶允許使用者將門戶定制到諸如MyYahoo這樣的儀表盤中，顯示多種報表、Web站點、提示以及報表列表等。標準的報表通常以各種主題分組。完美的BI門戶允許一個報表以多種方式分組，而不會造成同一報表的多復制本。而且越來越多的廠商允許電子數(shù)據(jù)表、PDF文件等非BI文件存儲在BI倉庫中，并在門戶中展現(xiàn)。隨著BI內容的增加，使用者也需要簡單的方法來通過作者、關鍵字或其他方法來查詢報表。Excel集成在評估BI工具套件功能的時候，人們往往很容易沉浸在逐個功能的對比中，而忽略了執(zhí)行BI所要達到的商業(yè)目標。前文曾經把選擇BI工具與購買轎車相比擬，在購買轎車的時候，我們很少考慮將怎么使用它或有關正確的駕駛方法等，在為“它是如此酷、敞亮、時尚”激動之中，一些最好的實踐和使用往往被丟到腦后。在選擇BI工具的時候，有一個特別的功能是用戶非常需要的，我們這里也將直接深入研究，那就是Excel集成。盡管Excel可能是無可爭辯的最主要的BI工具，但它也是導致多種版本真相的主要原因。兩個使用者同時查詢一個中央數(shù)據(jù)倉庫，并把數(shù)據(jù)導入Excel，一個使用者在Excel中使用一組特殊的標準過濾數(shù)據(jù)，并用一些個人的公式來計算；另一個使用者過濾數(shù)據(jù)的方法稍有不同，或許在公式中犯一個小錯誤。誰的電子數(shù)據(jù)表是正確的呢？結果大量的時間花費在協(xié)調多種版本之上而不是考察業(yè)務發(fā)展。在每次查詢更新及產生結果報表以后都必須重復同樣的流程。盡管電子數(shù)據(jù)表存在正確性問題，但是還是有很多因素使得在 BI工具選擇中不能忽略 Excel集成：工具熟悉。使用者很少有時間獲得數(shù)據(jù)然后去分析， 通常最簡單的方法就是使用他們已經熟悉的工具?！鞍茨Γ╩assage）”數(shù)據(jù)的能力。“按摩”數(shù)據(jù)包括重新分類、過濾、創(chuàng)建公式，以及在某些情況下修理壞數(shù)據(jù)等。理論上說，所有這些都應該在 BI流程的早期完成。在報表部分我們提到，能夠讓使用者重新分類、過濾或在本地 BI工具中隱藏個人專欄的 BI工具協(xié)作能力，當這種功能失效或不存在時，使用者除了把數(shù)據(jù)導入 Excel外幾乎沒有多少選擇。在 Excel電子數(shù)據(jù)表中校正壞數(shù)據(jù)的巨大任務對于數(shù)據(jù)一致性來說顯然是一場噩夢。然而，如果流程不能適當?shù)貜母瓷闲蘩韷臄?shù)據(jù)或修改ETL錯誤，使用者無論如何也難以創(chuàng)建一個有用的報表。較好的圖表。Excel圖表以及所有對比例、坐標軸、標注的控制已經成為一種事實上的基準。如果BI工具不能提供強大的圖表功能，顯然使用者需要把數(shù)據(jù)輸出到 Excel來使用其圖表功能。摘要文件（Briefingbooks ）。Excel可以將多個工作表存儲在一個工作手冊（ workbook ）文件中。使用者可以離線訪問所有數(shù)據(jù)，這些數(shù)據(jù)可能是通過多種數(shù)據(jù)源或查詢組合成的一個文件。很少有BI廠家能夠很好地復制這個功能。盡管儀表盤功能提供了類似的替換選擇，但通常需要網絡連接。減少許可證成本。企業(yè)已經花費了Excel的許可證費用，如果他們能夠通過更好地利用Excel減少BI使用者的數(shù)量，那他們就可以節(jié)省BI許可證成本。不過，BI廠家也在逐漸加寬“使用者”的定義，一個BI使用者已經不再是某一個登錄BI工具的個人，而是所有能夠接到BI工具輸出（包括電子數(shù)據(jù)表）的人。既然限制Excel是不可能的，關鍵就是找到既提供Excel集成又能保證單一版本真相的方法。各個廠家實現(xiàn)這個目標的方法也不同。最差的，所謂“零支持”就是一次性輸出到Excel，既沒有對該輸出的查賬索引，也沒有連接到中央的查詢。所謂“良好的支持”是指，BI工具跟蹤Excel電子數(shù)據(jù)表的所有權及所做變化，然后把數(shù)據(jù)表存儲在BI倉庫中。Excel電子數(shù)據(jù)表可以隨著新數(shù)據(jù)更新，特別是能保持與原始查詢文件的連接。需要指出的是，沒有任何單一特性能夠保證單一版本真相，它的實現(xiàn)部分依賴于廠商提供的功能特性，部分依賴于你必須執(zhí)行的流程。例如，MicroStrategy 的Office 產品就是一個 Excel插件，可以使用戶查詢及更新一個存在于電子數(shù)據(jù)表環(huán)境或 PowerPoint 和Word 中的報表。當原始報表的定義或基礎數(shù)據(jù)變化時， 電子數(shù)據(jù)表也隨之變化。同樣的報表瀏覽可以通過 Web、桌面或電子數(shù)據(jù)表來完成，這樣使用者可以通過他們喜歡的界面來訪問，從而也保證了單一版本真相。把數(shù)據(jù)一次性輸出到 Excel是企業(yè)保持單一版本真相的最大挑戰(zhàn)，但好像也是最普遍存在的一種現(xiàn)象。如果你瀏覽的報表并不是按照你的需求過濾或分類， 你只是簡單地存儲數(shù)據(jù)到 Excel并在那里做分析，BI團隊必需事先有準備：如果很多使用者都這樣工作， BI團隊就必須在本地 BI工具中提供更好的協(xié)作性，或修改標準報表定義。不過，如果是個別需求，那另當別論。最后還要指出一點，在關注 Excel集成時，應該注意需要哪個版本的 Excel，以及跨越版本是否有功能上的差異。OLAP有些分析家認為 OLAP（OnlineAnalyticalProcessing ，在線分析處理）只對小部分用戶適用。但現(xiàn)在大家普遍認為，從斷斷續(xù)續(xù)的信息消費者到強大用戶（ poweruser ）都能從OLAP功能的不同方面獲益。不幸的是， OLAP體系結構和成本經常會阻止其廣泛采用。OLAPvs.報表早在20世紀90年代，Essbase（當時為Arbor 所擁有，現(xiàn)在是屬于 Hyperion ）被看做是另類，所以Arbor 雇傭關系數(shù)據(jù)庫之父 ——E.F.Codd 來澄清這一稱為 OLAP的新東西。Codd定義了12條準則，但以下 4條最能清楚地把報表和 OLAP區(qū)分開來：1. 多維的：用戶從多方位分析數(shù)值，如產品、時間、地理等。但一個報表一般都是基于單一尺度，如在某一個時間點上的產品價格列表。2.快速：當使用者在一個維度中操縱不同的維度及等級時， OLAP意味著快速——思考的速度。如果一個使用者雙擊以從年度到季度鉆取，為一個答案等待 24分鐘或24小時是不可接受的。當然，報表使用者也并不想要慢的報表，但實際中確實很多報表必須運行這么長時間。改變聚合的等級：為確?？深A測的查詢時間，OLAP供貨商以不同方法重新聚合數(shù)據(jù)。相反，報表至少是需要細節(jié)：除了按照產品的銷量外，對于特定順序的數(shù)據(jù)，其中可能還有單獨的排列項?？缇暥鹊挠嬎悖憾嗑S帶來了復雜的計算。在OLAP中，你可能需要分析百分比貢獻或市場份額，這些分析需要先做某一特定狀態(tài)的銷售小計，然后再計算對整個區(qū)域、國家或全球的百分比貢獻。使用者可能通過許多其他維度來分析這個百分比市場份額，如實際 vs.預算，今年 vs.去年，或為特定的一組產品等。這些計算經常必須以特殊的順序執(zhí)行 ，并包含使用者從來沒有見過的一些輸入數(shù)字。但是，詳細的報表經常依賴于簡單的小計或報表本身顯示的一些數(shù)值的計算。不過記住一點，我們僅僅是對報表和 OLAP加以區(qū)分，并不意味著使用者需要他們的分析工具和報表工具截然不同。OLAP使用者應該從多維數(shù)據(jù)中創(chuàng)建報表，相反，報表消費者也需要從前僅供 OLAP專用的高度形象的分析 和紅綠燈顯示。怎么滿足這些不同的需求，廠商們也已經奮斗了很多年。當你選擇一種或多種 BI工具時，你的工作是了解你最需要什么： OLAP，報表，還是兩者。如果答案是兩者都要，那么就需要仔細評估報表和 OLAP的集成。OLAP體系結構在選擇OLAP工具時，OLAP體系結構是需要理解的一個最重要的標準：它會影響很多其他單獨特征以及你部署系統(tǒng)的能力。最近人們認為MOLAP-ROLAP-DOLAP（多維OLAP-關系型OLAP-桌面OLAP）爭辯已經平息。我認為，只要廠商還提供這些不同的方法，爭論就會存在。MOLAP使用一種持久穩(wěn)固的立方體結構，與關系型數(shù)據(jù)庫是分離的。HyperionEssbase、MicrosoftAnalysisServices、CognosPowerPlay都是使用了這種方法。因為一個立方體包含一個預先計算好的數(shù)據(jù)子集，所以與DOLAP和ROLAP相比響應時間更快速且可以預測。MOLAP數(shù)據(jù)庫傳統(tǒng)上還具有更大程度的多維計算，比ROLAP中也更容易實現(xiàn)。例如，HyperionEssbase使用一個@DESCENDANTS 功能，讓你將一個特定級別中的成員指向同一層次（如，一月、二月、三月并列是第一季度的下一級）。盡管一些關系數(shù)據(jù)庫具有CASE功能，也可以使你在一個計算中指向這些行，但并不是所有都能做到，而且計算并不一定都是直截了當。MOLAP的大幅下降是因為它是需要IT支持、管理、維護的另外一種數(shù)據(jù)存儲。公司抱怨維護200個立方體需要很多努力，或公司擁有的是花費一個星期重新計算的設計不良的立方體，這都是很平常的。當一個維空間改變，如增加一個新的產品或改組業(yè)務單元，你可能就不得不重新計算整個MOLAP立方體。而關系型OLAP是使用關系型表格來提供多維分析，MicroStrategy和Informatica是主要的ROLAP廠商。MicroStrategy使用RDBMS中的分區(qū)和聚合表格來提供快速查詢;為實現(xiàn)復雜的OLAP計算，它使用了一個multipassSQL和臨時表格的結合體。ROLAP工具沒有單一立方體的限制，但卻因低的響應時間而苦惱。如果你公司沒有技術型DBA來熟練調整數(shù)據(jù)庫，獲取一個用戶鉆取的結果可能需要25分鐘的查詢。歷史上，在MicroStrategy中的一個鉆取經常會觸及最根本的關系表格。不過有了MicroStrategy的OLAPServices后，鉆取會訪問緩存，這也是對 “ROLAP先天就比MOLAP慢”的有力還擊。很多MOLAP廠商使用ROLAP和MOLAP相結合的方法，這種方法被稱為 hybridOLAP（HOLAP）。例如，MicrosoftAnalysisServices 就能夠使用ROLAP體系結構來對付大數(shù)據(jù)量； HyperionEssbase 也能在關系型表格中存儲大量維空間。 像其他ROLAP工具一樣，其響應時間還是要比嚴格使用MOLAP慢，所以很多執(zhí)行繼續(xù)使用MOLAP存儲來保證快速分析。DOLAP代表桌面OLAP，是因為很多處理需要在使用者的桌面來完成。也有人把它叫做動態(tài)OLAP（dynamicOLAP），以突出微小的立方體是如何動態(tài)創(chuàng)建的，也許在桌面上，但大多是在中間層的應用服務器上。與MOLAP不同，這種情況IT部門不需要提前創(chuàng)建大型立方體，而是當使用者運行查詢時動態(tài)創(chuàng)建立方體。相比MOLAP和ROLAP，其一個立方體中的數(shù)據(jù)量和維空間計算是有限的（盡管也可以達到GB級別）。這些立方體更適合看做是個人立方體。DOLAP的最大好處是靈活性和維護：立方體不需要提前創(chuàng)建，當你公司增加一個新產品或重組部門時，這些變化也將在你更新查詢的時候自動表現(xiàn)。不過，DOLAP工具同樣也遭受與ROLAP一樣的RDBMS性能的所有風險。由于具有從多種數(shù)據(jù)源中抽取數(shù)據(jù)的能力，MOLAP工具經常被成功應用于小數(shù)據(jù)倉庫的平臺。這對于企業(yè)信息架構來說顯然是不理想的。因此，來自多種數(shù)據(jù)源的數(shù)據(jù)最好能裝入一個中央數(shù)據(jù)倉庫中，然后才能用于組裝MOLAP立方體。盡管，在實際中一些公司沒有構建數(shù)據(jù)倉庫的能力和資金，但具有數(shù)據(jù)倉庫結構的 MOLAP立方體確實能受益于快速的立方體創(chuàng)建。對 BusinessObjects 的microcube 來說，一個立方體可以基于多種查詢、存儲的流程、 XML文件及電子表格等來創(chuàng)建，CognosPowerCubes 和HyperionEssbasecubes 也能從多種數(shù)據(jù)源創(chuàng)建。另外，對一個管理者來說，能夠很輕松地設計、構建并調整 OLAP平臺是非常關鍵的。對于最終使用者來說，諸如屬性分析、 假定性分析、紅綠燈顯示、時間周期分析等也是非常重要的。管理管理方面的特性可能并不會引起商業(yè)使用者的興趣， 但卻同樣重要。好的部署應該既考慮到最終使用者的需求，也考慮到 BI工具的管理問題。如果沒有全面考慮二者，企業(yè)最終所有的無非兩種結果：看似很好但需要相當?shù)?IT資源來維護的工具，或沒有人使用的系統(tǒng)。安全性我承認，我憎惡 BI安全。并不是說我沒有看到需求，而是厭惡跟蹤更多的用戶 ID和口令！沒有什么比當一個BI使用者很高興地訪問儀表盤時卻總被 “不正確的口令”所折磨能更快地扼殺 BI執(zhí)行。一個教訓是：你可能花費了大量時間來選擇 BI工具，但如果你沒有花費足夠時間計劃安全性，工具早晚會被破壞及登錄錯誤擊垮。安全可以分為兩個階段，首先是鑒定(authentication) ——一用戶名和口令的有效性； 第二步是授權（authorization ）——在鑒定以后允許其訪問什么。 LDAP(LightweightDirectoryAccessProtocol) 服務承諾將多用戶 ID和密碼問題減到最少。理論上，一個公司將擁有一臺目錄服務器來保存所有員工的用戶名和密碼。公司所有的系統(tǒng)，無論是網絡、BI或ERP，都使用該目錄服務器來鑒定?，F(xiàn)在，還沒有目錄服務的清晰標準。Sun的iPlanet、MicrosoftActiveDirectory、Novell的eDirectory是業(yè)界比較領先的產品。BI廠商會支持其中一些或全部。由于歷史的及實際的原因，大多BI工具繼續(xù)使用它們自己的鑒定機制。如果你公司還沒有實現(xiàn)目錄服務器，你就需要這些機制；如果你已經有了目錄服務器，你就需要BI工具來鑒別它。授權比鑒定更雜亂。在授權中，你可能需要限制一些用戶使用特定的業(yè)務瀏覽或元數(shù)據(jù)層、個別報表、軟件功能以及數(shù)據(jù)等。理想狀態(tài)，你需要定義角色（role）或用戶組（groupsofusers），以便這些授權能夠在組級實現(xiàn)，而不是直接針對上千的個人用戶。這里有一個很大的挑戰(zhàn)：即使你有一個LDAP服務器來做授權，你也不得不在BI工具中復制所有個人用戶的ID來為授權服務！這種復制會帶來風險——諸如用戶ID或密碼等一些東西有可能失去同步性。然而，如果你能夠在目錄服務器中定義組，并且BI工具能夠讀這些組，那還是有希望的。很明顯，很多BI廠商在向這個方向靠攏。元數(shù)據(jù)元數(shù)據(jù)集成（Metadataintegration）提供很多承諾。首先，它能減輕業(yè)務視圖的管理；其次，它能給需要對每個metric的來源、轉換以及計算有一致的、精確定義的業(yè)務使用者帶來更大的透明。不過，這些也僅僅是承諾。在實際中， BI基礎架構中的每個組件都有自己的元數(shù)據(jù)，并為不同的目標而使用。一方面，這種情況存在是因為元數(shù)據(jù)已經被當做每個組件的 “私有品”來對待，另一方面，也是因為每個組件都有自己的要素。使用BI工具的業(yè)務使用者需要業(yè)務術語，使用ETL工具的IT部門則需要知道確切的來源系統(tǒng)、表格名稱以及數(shù)據(jù)元素的起源地。是否要賦予數(shù)據(jù)元素一個商業(yè)術語對IT用戶來說并不重要。從BI套件來看，你應該考慮你需要共享什么元數(shù)據(jù)？在哪些組件之間共享？過去，BI廠商采取不同的方法來共享數(shù)據(jù)，經常是提供專有的API。隨著來自ObjectManagementGroup的CWM(CommonWarehouseMetamodel)被大家接受，廠商們很快就開始提供支持。后來，BusinessObjects和Cognos還使用了MITI(MetaIntegrationTechnologyInc.)提供的一種遵循CWM的元數(shù)據(jù)橋（metadatabridge）。SAS的EnterpriseBIServerversion9也在元數(shù)據(jù)交換方面做了創(chuàng)新。這些都是為元數(shù)據(jù)交換而走出的很好一步。影響分析影響分析（Impactanalysis ），是指當你改變或刪除一個數(shù)據(jù)元素的時候，能夠知道哪些報表將受到影響的這樣一種能力。影響分析在 BI架構的不同點都有關。如果是源系統(tǒng)中發(fā)生改變，你怎么能夠知道在業(yè)務視圖以及最終的報表中什么將改變？如果是在業(yè)務視圖中發(fā)生改變， 這種變化是否能夠自動傳達到報表中？至少，管理員需要有能力識別 BI套件中相互依賴的 BI元素。BusinessObjects 的ETL工具DataIntegrator ，就同元數(shù)據(jù)層或 universes 有很好的影響分析。然而，其元數(shù)據(jù)設計工具 Designer 內的影響分析卻很少。 MicroStrategy 的影響分析工具更進一步：當你試圖刪除一個對象時，它立即會警告你哪些報表依賴于該對象。使用監(jiān)測不能監(jiān)測BI系統(tǒng)的使用，就如同在夜晚不開前燈和儀表盤駕駛汽車一樣。最糟糕的情況就是你（或你的服務器）被撞壞，最好也不過你把汽油耗盡（或查詢失?。ｋS著BI廠商越來越把目標鎖定企業(yè)范圍的部署，它們也開始注重提供使用監(jiān)測功能。最初，廠商把BI行為記錄在log文件中，很少在分析應用中使用。理想的情況應該是當數(shù)據(jù)在關系數(shù)據(jù)庫中被捕捉到時，廠商提供預建報表；此外，管理員應該能決定哪些行文是要監(jiān)測的，從大量的注冊直到誰訪問哪個目標等。MicroStrategy通過其以服務器為中心的架構，在提供監(jiān)測BI使用的工具方面一直是領導者。BusinessObjects也從2001年就推出了其Auditor產品，隨后Cognos、Crystal、Informatica等都推出此功能。不過需要提醒的是，數(shù)據(jù)庫監(jiān)測和BI監(jiān)測并不相同。在數(shù)據(jù)庫層面，你可能會跟蹤數(shù)據(jù)庫領域ORDER.QTY被訪問的頻度；在BI應用中，卻需要知道哪些計算出的metric用戶最常訪問，還包括哪些標準報表、哪些展示格式以及最大負荷時間等。BI工具架構最后，我們來關注結構方面的一些考慮因素，以便能夠結合上下文幫助你找到適合自己企業(yè)的最好BI工具。BI架構的很多方面是從廠商的演示過程中得不到的， 如：是client/server 還是基于Web？使用了什么OLAP方法（MOLAP、ROLAP、DOLAP）？該BI工具是否能容易地定制或嵌入到其他應用中？該套件在查詢、報表、 OLAP、儀表盤以及分析應用等不同工具間使用的框架（元數(shù)據(jù)、安全以及基礎架構）是否是通用的？該服務是否能跨越多個服務器和平臺分布？很多 BI套件架構方面的不同，也許只有當你安裝、部署或定制產品的時候才能清晰體會到。SOA由于BI已經走向Web以及企業(yè)范圍部署應用，今天的 BI工具都具有服務導向的架構，即 SOA（ServiceOrientedArchitecture ）。SOA允許不同的 BI服務去執(zhí)行特定的任務，必要的時候還可以分布到多個服務器上。圖2BI工具的SOA7:BI 應用服務器可以運行在一個 Web服務器上，也可以運行在一個特定的應用服務器上。我們以三個可能的 BI服務舉例來說：查詢、展現(xiàn)以及時序安排。如圖 2所示，查詢引擎負責查詢數(shù)據(jù)源，可能是一個數(shù)據(jù)倉庫或 MOLAP立方體。當查詢完成后，展示部件必須將查詢結果轉換成有意義的報表，也可能是圖表和交叉表，而且還需要不同文件格式，如 HTML或PDF。如果一個用戶預定了某一個查詢的時間， 時序安排服務就會不斷地監(jiān)測是否到了已預定查詢的執(zhí)行時間， 并在準確的時間把它傳遞給查詢服務。查詢、展示以及時序安排之間如何溝通，這就是諸如 COM、CORBA、Webservices 協(xié)議等標準起作用的時候了。當然也有一些 BI廠商會使用自己專有的方法來處理這些部件之間的通信。COM和CORBA是支持SOA的比較老的方法，Webservices 標準正處在高速發(fā)展期，其接受度和功能都在不斷提升。可擴展性架構有趣的是，好像所有的BI工具都具有向上和向外擴展的能力：如果你添加更多強大的硬件（向上擴展），它就可以支持更多的用戶；如果你添加更多服務器（向外擴展）并分布服務，它也能支持更多用戶。然而，很多企業(yè)的目標是降低復雜性和成本。撇開對容錯的考慮，如果所有的東西都高效地運行在一臺服務器上，你就節(jié)省了硬件和管理的成本。很不幸，目前針對 BI工具還沒有供對比產品用的基準測試。而且，使用和部署產品的方法也會影響其可擴展性。如，更新BusinessObjects全部客戶機文件比更新其最新的瘦客戶機文件就要更耗費資源。對MicroStrategy來說，數(shù)據(jù)倉庫中聚合的表格越少以及一個報表模板中使用的過濾器越少，系統(tǒng)就越慢。不管如何，你也可以根據(jù)一些特性來初步觀察某一產品套件對資源的占用：OLAP體系結構、多線程的流程、查詢管理器、高速緩存等。查詢管理器可以使管理員防止飽和系統(tǒng)中的復雜及有害查詢。好的BI工具都提供查詢管理器，這樣可以方便控制并發(fā)查詢進程的數(shù)量、每一次查詢返回的行的數(shù)量、以及一次查詢運行的時間。理想狀態(tài)，這些限制應該在每個服務器、用戶組、不同任務或個別用戶等不同級別中被定制。另一種將這種服務器負荷風險減少到最小的方法是高速緩存。如果一個查詢更新的請求能夠通過高速緩存服務，那么并發(fā)查詢進程就會減少。高速緩存還可以幫助BI架構中的其他服務，如授權和展示服務。當然緩存的重要性也是由特定工具的架構決定的。如MicroStrategy提供廣泛的緩存，包括SQL、元數(shù)據(jù)甚至查詢結果。管理員對指定什么獲得緩存以及監(jiān)測緩存是否使用都可以有良好控制。總結本文的目的是幫助大家了解什么BI功能是重要的以及原因。逐個功能比較是選擇BI工具的一個方法，但并不是惟一方法。如同你購買轎車的時候，也許你購買福特的原因是你想購買美國品牌，而你選擇通用可能是因為你的鄰居就是其經銷商，或許你購買Hummer是因為你喜歡其形象。同樣的無形的及策略性的考慮也會出現(xiàn)在選擇BI套件的情形。每一個BI廠商都有一套獨特的BI策略。像BusinessObjects、Cognos、Hyperion這些主要競爭者都追求BPM（businessperformancemanagement，業(yè)務性能管理），但方法卻有截然不同。每個廠商也都有各自獨特的“最佳聽音點（sweetspot）”、歷史起源