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