微軟BI方案參考---來自這些年的工作經(jīng)驗
自我介紹：
在學校的時候從asp轉到asp.net從而接觸了c#和.net，期間為學校和社會做過很多的門面網(wǎng)站和一個BS的政務系統(tǒng)。畢業(yè)后從事BI的開發(fā)工作，主要關注SSAS往上的部分，包括復雜的動態(tài)報表的開發(fā)，后期發(fā)現(xiàn)Silverlight的優(yōu)勢所以研究RIA在BI中的應用，并把地圖數(shù)據(jù)也應用進項目。第一個項目就取得了意想不到的效果，也成為了在BI圈里應用RIA方案里比較早的一批吃螃蟹的人。先后經(jīng)歷過公安，保險，廣告以及電信行業(yè)的BI。
題外話：為什么博客園id是aspnetx而從事的確實BI以及silverlight相關的工作，大致的原因就是如此吧。
正題：
為什么BI，海量數(shù)據(jù)的統(tǒng)計和分析通過BI的方案，相比于純TSQL的統(tǒng)計，可以提高查詢和分析的性能，另外通過多維分析的方式可以幫助客戶更好的去理解數(shù)據(jù)。
最近總被問到相關的類似問題，所以平時就總結了一些，逐漸有了不成形的積累，大致記錄如下。
微軟可能受到些制約，所以很多產(chǎn)品在國內(nèi)的支持力度并不是很給力，從事相關開發(fā)的人也相對少一些。本文主要根據(jù)我這些年的經(jīng)驗總結，給各位做評估的項目一些參考。
根據(jù)情況的不同，文中提及的產(chǎn)品名稱沒有標注版本，但通常都指其最新版本。后續(xù)版本可能會略有變化，但根據(jù)筆者的經(jīng)驗不會出現(xiàn)在未來三年中。
微軟的BI產(chǎn)品體系：
SQL Server
BI的核心，其中從下到上包括三個部分，SSIS，SSAS，SSRS
SSIS負責ETL以及整體BI的調(diào)度。圖形話界面比較直觀。
SSAS，分析服務，包括Cube和數(shù)據(jù)挖掘。它也是跟我們通常所見的表和庫相同的另外一種獨立的庫。
SSRS，報表，包括訂閱和發(fā)布等功能，最新的版本集成了dundas的一些東西，比之前效果好那么一點。
以上三個模塊的開發(fā)都是通過visual studio shell。
附屬產(chǎn)品體系
Office
體現(xiàn)在Excel中，Visio也有一些，但未見過應用。
MOSS
Sharepoint的收費版本，微軟的門戶解決方案。
PPS被集成到了新版中，就是以前的普科。
按照微軟的產(chǎn)品架構的解決方案：
Windows Server
IIS
SQLServer->SSIS-SSAS-SSRA
MOSS->PPS
Office
優(yōu)點，全套微軟的解決方案，各部分無縫集成。前端客戶培訓成本低，都是其比較熟悉的Office工具。
缺點，完全依賴于微軟的體系方案。比如要用PPS的一個功能，那么就被迫要部署MOSS以及購買MOSS整個的授權，對MOSS的維護又是一定的成本。
建議，除非你已經(jīng)決定了采購微軟的這些產(chǎn)品，否則還是建議你閱讀完本文。
比較常見的方案：
Windows Server
IIS
SQLServer->SSAS
ETL層自定義框架
前端利用第三方組件自行開發(fā)
優(yōu)點，ETL和UI自己開發(fā)，可以解決比較復雜的需求。相對來說對于UI層差別很大，比如據(jù)說微軟內(nèi)部很多部門就是自己用Excel去連數(shù)據(jù)。
缺點，開發(fā)維護的成本高。
值得提一句的是，我所最近經(jīng)歷的項目ETL都是由團隊自己封裝的框架，完全不用SSIS。這個方案微軟美國總部的某些專家也有提到。而我之前團隊的兄弟們，除非數(shù)據(jù)量在1000萬以內(nèi)，否則都是寧可自己去實現(xiàn)ETL。
關于為什么舍棄SSIS，先前團隊的兄弟們曾反映過一個細節(jié)，就是在抽取Oracle數(shù)據(jù)的時候經(jīng)常半路死掉，一直找不到問題。后來咨詢過一些DBA，他們說是由于Oracle的驅動版本造成的問題。我相信這么一個比較折騰人的細節(jié)，就足夠讓很多兄弟拋棄SSIS這個平臺了。
我推薦的方案：
Windows Server
IIS
SQLServer->SSAS
ASP.NET->WebServices
Silverlight
GIS
這個是我一直推薦的BI+RIA+GIS的方案。也就是利用商業(yè)智能，加富客戶端比較強的展現(xiàn)能力，并通過地圖的輔組來為客戶更好的展現(xiàn)數(shù)據(jù)。
#p#
需要的知識體系：
操作系統(tǒng)，最基本的操作和維護安裝等。
數(shù)據(jù)庫，BI最基本的技能。
IIS，BS的方案現(xiàn)在已經(jīng)成為方案的首選，另外某些情況下SSAS也要依賴一下IIS
SQL，主要在ETL層用到，而且工作量要超過整個BI的一半以上。
MDX，這個是用來查CUBE的，如果可以數(shù)據(jù)挖掘，那么還需要DMX。
Powershell，某些東西用它來做會省很多事兒。
.net，Powershell依賴這個，而且下面幾樣也依賴這個。
C#，封裝服務，和silverlight開發(fā)用。
Silverlight，相比Flash的話，有經(jīng)驗的.net開發(fā)人員接觸這個更快。
項目里根據(jù)需要可能需要一些第三方商業(yè)組件的支持，比如silverlight的chart組件，這個購買一套現(xiàn)成的絕對比投入幾個人月去開發(fā)合算的多。
國內(nèi)BI 的現(xiàn)狀：
首先，數(shù)據(jù)質(zhì)量。這個在很多行業(yè)內(nèi)都存在，數(shù)據(jù)的質(zhì)量都比較愁人，比如外鍵的數(shù)值字段居然能出現(xiàn)全角的數(shù)字字段。IT力度實施不夠也是一個原因，就像教老婆記賬一樣，老婆不會或者不愿意去做，最后即使做了，得到的數(shù)據(jù)也是沒有意義的。
其次，需求。需求的混亂原因很多，對BI的不了解和對自己本身業(yè)務的認知程度。所謂知己知彼百戰(zhàn)百勝，但很多行業(yè)以及項目實際上并不“知己”。
總之，項目很多，成功的少，大多都是為了報表和面子問題而去BI。
微軟的方案適合你嗎?
相對于其它解決方案，可以說微軟的產(chǎn)品確實存在些不足的地方，但是，隨著SQLServer的版本演進，目前的版本來說這個差距應該已經(jīng)說很小了，當然也不存在其它產(chǎn)品解決的了，而微軟的產(chǎn)品解決不了的情況。
如果是遇到實在解決不了的問題，那么我覺得應該首先審視一下BI的建模，然后審視一下需求，因為大多數(shù)你費勁去解決的東西，實際上后來都不是用戶所關注的，后者是純粹的面子工程。
實現(xiàn)我的功能需要多長時間?
這個是經(jīng)常被問到的問題?？紤]這個問題主要還是要從幾個方面來分析：數(shù)據(jù)的情況，比如數(shù)據(jù)量和數(shù)據(jù)質(zhì)量等，此外還有需求的復雜程度以及業(yè)務的復雜程度，都決定時間的長短。當然這些確定了，項目才可以繼續(xù)做計劃。
另項目基本上都是以螺旋上升的形式來開發(fā)，很少說有第一版就成功的，這個過程是需要不斷探索和積累的。
相關人員好招聘否以及Team的構建
很少有直接就做BI的人，但基本上都有兩種情況，一種是從DBA轉過來的，一種是從開發(fā)轉過來的。我想我是后者。前者偏重底層，后者偏重表層。招聘的時候可以根據(jù)這個特點以及項目的情況來選擇。
關于Team的構建，我見過比較多的是后邊和前邊分開的那種。也就是說數(shù)據(jù)庫層的BI開發(fā)是管“后邊”的人，做.net開發(fā)的是“前邊”的人。我不反對這種劃分，但是按照我的經(jīng)驗來說，一定要注意前后的銜接，雖然兩個部分是兩個隊伍，但是一定要有一個認知就是大家是一個隊伍，共同承擔著項目的成敗。而這里也需要一個天平來做一些決策，有些東西通過后邊來解決，可以省很多前邊的人的事，而有些東西如果前邊稍微處理下，能給后邊的人少很多麻煩。
BI有比較合適的參考資源嗎?
我建議看SQLServer的Books on line，盡量看英文版吧，中文版有些細節(jié)翻譯的實在不敢恭維。此外，微軟的webcast也很值得在參考，雖然每節(jié)課都很長而且比較枯燥和抽象，但還是建議沒事看看。
總結：
從某一個產(chǎn)品的角度來講，也許微軟在這小的方面做的不是很好，但是整體來說跟其它方案已經(jīng)沒有什么太大的差距，對，是太大的差距，差距還是有的，但是他的某些優(yōu)點又足以彌補。此文從一個從業(yè)人員的經(jīng)驗角度出發(fā)，盡量不帶任何感情色彩。部分可能帶有本人在某些領域的短見，或者存在著錯誤以至于誤人子弟，還請各位高手們指出。BI是個有潛力的領域，是個有價值的領域，國內(nèi)也算個新生領域吧，圈子很小，還望有高人給予指點。
原文鏈接：http://www.cnblogs.com/aspnetx/archive/2011/10/10/2206713.html
【編輯推薦】
