提到SQL Server 2012的分析服務，那么不得不先說下商業智能，它是一個由數據轉換成知識的過程。此篇將對SQL Server 2012的分析服務（Analysis Services）以及跟其相關的商業智能做一個簡要的介紹，將以一個普通開發人員的角度去闡述和介紹分析服務以及商業智能。
分析服務是SQL Server的一個服務組件。作為一個應用程序開發人員，你已經很熟悉數據庫和表，這些在SQL Serer的服務組件中是屬於數據庫引擎的范疇。還記得你每次打開Management Studio嗎？
這個啟動界面，也許您還不太清楚SQL Server跟Visual Studio有何關系，看完此篇您就明白了。
每次打開的時候都會讓你選擇Server type。除了你常用的Database Engine之外，其余的幾個組件，集成服務，報表服務和分析服務，它們加起來就構成了SQL Server端商業智能中的核心組件。
如果你選擇全部安裝了SQL Server的組件，也就是下面的勾全部勾上。（當然，如果你只是做應用程序開發，那么只推薦你單獨安裝數據引擎服務就可以了，因為其它的服務你安裝后運行起來確實很占資源。）
SQL Server 2012里特殊的地方就是分析服務中多了一個Tabular Mode模式，在安裝過程中，如果選擇安裝了分析服務，那么在分析服務配置過程中會出現下面一個界面選擇安裝分析服務的哪種模式。
在SQL Server 2012下同一個分析服務示例只能以一種方式存在。如果你想使用兩種模式，那么只能選擇安裝兩個分析服務實例。
在安裝完畢后，就可以在服務列表里看到類似如下已經安裝好的服務。
如你所見，平時不用的服務我都是關閉掉的，尤其是報表服務，它們都很占系統資源，即使我筆記本安裝的系統內存擴充到了8GB，那我也會選擇平時盡量關閉掉它們，然后需要的時候再打開。
可以看一下微軟文檔中各組件的結構圖。
中間的集成服務，主要負責ETL的工作，它貫穿着其它幾大主要的服務，這是一個數據的清洗加載和轉換的過程（也就是折騰數據的過程），經過ETL的過程之后，數據由OLTP加載到OLAP中。這里面提到的OLTP是聯機事務，通常說的某系統都可以歸屬到這個范圍，比如程序員們經常開發的財務管理系統，人力資源管理系統，進銷存系統，客戶關系管理何辦公自動化等，它們主要在數據庫這層的工作就是增刪查改。OLAP是聯機分析處理系統，從字面上可以看出這一層主要的任務就是分析，比如報表系統，數據統計和分析以及數據挖掘。
此外還有一個數據倉庫的概念，數據倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策(Decision Making Support)。說簡單些可以理解為，這一層是把各個業務系統的數據整合到了一起，並且結構會被轉換成適合分析的結構的一個特殊的數據庫。
也許很多人在此不會很明白（包括早些年剛開始接觸BI的我），既然有OLTP了，那么為什么還需要ETL到OLAP呢？想要什么查詢一個SQL語句不就搞定？
首先，數據單獨傳輸到OLAP層，可以有效的防止分析系統跟業務系統搶占資源。對於很多大型系統來說，業務系統會非常的繁忙，而分析數據的語句往往都很復雜而且要消耗掉很多資源。分開后可以避免相互之間的影響。
其次，ETL是個很重要的過程，因為在OLAP端通常是整合了多個業務系統的，經過ETL整合到一起后，更方便統計查詢。
最后，是為了降低查詢統計分析的復雜度。經過聚合的數據通過MDX進行查詢，將比直接用SQL語句查詢更簡潔明了。
在工作的過程當中，也有同事問我為什么不自己建立一套根據維度自己算聚合的方法，直接將其保存到表中。這種方法在一定程度上來說是可行的。但往往在項目正式結束之前，維度模型往往都是要變化的，比如加了一個維度，那么如果自己用表來聚合的話，每加一個或者減少一個以及更新一個維度那么就意外着聚合的方法需要重新改寫。
再就一個行業內流傳很廣的一個事實是：寫SQL的不如用Excel的賺的多，用Excel的不如用ppt的人賺的多。如上面所說，這個道理換成我也是好幾年之后才明白。
此外，在baidu百科中找到一個表，可以更詳細的了解二者之間還有什么差別。
| OLTP |
OLAP |
|
| 用戶 |
操作人員，低層管理人員 |
決策人員，高級管理人員 |
| 功能 |
日常操作處理 |
分析決策 |
| DB 設計 |
面向應用 |
面向主題 |
| 數據 |
當前的， 最新的細節的， 二維的分立的 |
歷史的， 聚集的， 多維的 集成的， 統一的 |
| 存取 |
讀/寫數十條記錄 |
讀上百萬條記錄 |
| 工作單位 |
簡單的事務 |
復雜的查詢 |
| DB 大小 |
100MB-GB |
100GB-TB |
從上表中，我們就可以看到為什么微軟會提出列式存儲以及PDW（並行數據倉庫）的產品。
下圖是一個最簡單的BI流程。
從上到下，可以看到通過BI的流程，首先將各個不同業務數據整合到一起到數據倉庫中，然后數據倉庫的數據經過聚合或者處理到分析服務中，最后通過前端工具展現出來。
中間那層，包含多維數據集，Tabular和數據挖掘這一層，對應的就是SQL Sever分析服務。
此外，我先前寫過一個關於BI通用流程的隨筆：
http://www.cnblogs.com/aspnetx/archive/2010/03/06/1679896.html
還有，關於BI項目的具體技術方案，也可以參考我的這兩篇隨筆：
http://www.cnblogs.com/aspnetx/archive/2011/10/10/2206713.html
http://www.cnblogs.com/aspnetx/archive/2011/11/30/2268886.html
以上簡單的介紹了分析服務以及商業智能和數據倉庫的一些概念，並且引用了我先前的幾篇隨筆供詳細參考，下面詳細介紹SQL Server分析服務的各個部分。
多維數據集
多維數據集是目前很多BI項目中都在用的，它根據維度的定義將事實表里的數據進行聚合運算，從而在犧牲處理時間和額外的聚合存儲空間來換取統計查詢的相應速度。
多維數據集可以理解為是一個立方體，比如下圖：
我們看到在圖中，立方體有三個軸分別對應三個維度：時間，空間和運輸方式。實際的多維數據集可以簡單的理解成這個模式，只不過，在定義問題的時候，可以定義出好多的維度。
再如下面的一個立方體，三個軸分別為客戶時間和產品，魔方里的每一個小塊兒代表某一客戶某一時間點購買某一產品的多少。
當然，在實際的分析中，在透視表里我們不一定非要用上三個維度才叫立方體(Cube)，更多的時候我們會用任意多的維度組合來分析問題，而在分析過程中，同一個軸也可能會包含更多地維度，比如從客戶維度下鑽到產品維度等。實際的操作都是一個基於維度的相當靈活的過程。
關於如何創建簡單的多維數據集，可以參考我下面的一篇隨筆：
http://www.cnblogs.com/aspnetx/archive/2013/03/16/2963965.html
此外，入門的朋友我建議詳細的看一下微軟SQL Server文檔中的教程。
http://technet.microsoft.com/zh-cn/library/ms170208.aspx
查詢多維數據集是用MDX，跟SQL一樣，它也是SELECT FROM WHRER這樣的結構，比如：
WITH
MEMBER Measures.[Amount Change Rate] AS
IIF(ISEMPTY(([Measures].[Internet Sales Amount],[Date].[Fiscal].CurrentMember.PrevMember)), "",
[Measures].[Internet Sales Amount]/
([Measures].[Internet Sales Amount],[Date].[Fiscal].CurrentMember.PrevMember) -1
), FORMAT_STRING = '0%'
SELECT
{[Measures].[Internet Sales Amount], Measures.[Amount Change Rate]} ON 0,
[Date].[Fiscal].[Month].MEMBERS
ON 1
FROM [Adventure Works]
查詢結果：
關於 MDX更詳細的知識請參考微軟的官方文檔：
http://technet.microsoft.com/zh-cn/library/ms145506.aspx
Tabular Mode模式
多維數據集這種方式是由IT人員開發的，適合處理大量數據，默認情況下聚合后的文件是獨立放在文件目錄下。缺點是每當業務人員提出一個問題或者需求的時候，都需要等待IT部門長時間的響應，所以，針對這種需求，微軟在SQL Server 2012中提出了Tabular Mode模式，在這種模式下，業務人員在Visual Studio中就可以自己來制作簡單的分析模型，而操作的界面跟業務人員平時用的Excel和Access是非常像的，所以可以看到Tabular Mode就是微軟專門為業務人員為了快速解決問題而提出的一個工具。
此外，Tabular Mode模式默認是把數據放到內存中，這樣數據往往不需要經過特殊的優化就可以獲取非常高的查詢性能。
不過無論如何，我個人的觀點，Tabular Mode還是無法取代多維數據集和IT人員的工作，因為Tabular Mode的數據畢竟是放在內存中的，所以要受到服務器的內存以及企業內部IT 管理策略的限制，而且很多數據還是需要IT人員經過ETL的整合，業務人員在Tabular Mode中拿過來用才有意義。不過，我更願意以后看到兩者的結合體出現，比如多維數據集把數據聚合到內存當中。
關於如何用Tabular Mode創建簡單的分析模型，可以參考我下面的一篇隨筆：
http://www.cnblogs.com/aspnetx/archive/2013/02/21/2920459.html
入門的朋友，建議一定要看一下微軟文檔中的教程：
http://technet.microsoft.com/zh-cn/library/hh231691.aspx
跟多維數據集不同的是，多維數據集定義一個計算成員用的是MDX，而Tabular Mode用的是DAX。這種結構更接近於Excel里的用法。
Days in Current Quarter:=COUNTROWS( DATESBETWEEN( 'Date'[Date], STARTOFQUARTER( LASTDATE('Date'[Date])), ENDOFQUARTER('Date'[Date]))) 比如如上的一條語句定義了一個命名成員。
關於DAX的參考，可以查看微軟的官方文檔;
http://technet.microsoft.com/zh-cn/library/gg413422.aspx
Excel中的透視表
在多維數據集和Tabular Mode模型建立完畢后，就可以在其之上做一些數據分析。Excel被微軟介紹為其中一個強力工具，因為很多業務部門都很熟悉它，相對來說容易上手，而且更直觀。
在Excel的透視表中，可以很方便的進行上鑽下鑽以及切片和切塊等操作。
此外，還可以根據透視表切換成透視圖。
數據挖掘
關於分析服務另外一個比較有意思的就是數據挖掘，在商業智能中，數據挖掘是其中最高的一個層次。現在流行的大數據，最終往往也要靠數據挖掘來體現其價值。
如果說，BI的過程可以看成是數據的昨天，今天和明天，數據的昨天，通過報表告訴你的業務之前發生了什么，數據的今天，通過多維分析等工具告訴你這些為什么會發生，那么數據的明天，就是通過數據挖掘算法，對已有的海量歷史數據進行挖掘，從而讓你知道你的業務未來會是什么樣。
微軟的數據挖掘工具包含了很多算法，比較常見的比如貝葉斯，決策樹，關聯規則和時序分析等。
數據挖掘會分析樣本數據，從中發現規則，然后用於對未來未知數據的預測。通常用來比如電商網站的商品推薦，潛在客戶分析，以及客戶分類等問題之上。
數據挖掘不是專門搞算法的工作人員的專利，作為開發人員，大家也可以一起來玩轉一下SQL Server分析服務中的數據挖掘功能，我這里有一系列完整的介紹SQL Server分析服務數據挖掘的文章，通過電商網站中的商品推薦功能，介紹如何建立挖掘模型，然后在前段程序如何使用數據挖掘功能。此外，還有在Excel中進行數據挖掘的演示，以及如何通過DMX創建挖掘模型。
http://www.cnblogs.com/aspnetx/archive/2013/03/16/2963965.html
在這篇系列中，您可以跟我一樣，作為一個不了解底層算法數學公司的開發人員，來玩轉數據挖掘功能。而作為開發人員，除了基本的DMX需要掌握之外，還需要知道，什么樣的挖掘模型適合解決什么樣的問題。
關於SQL Server分析服務中數據挖掘各個模型的介紹，可以參考微軟的這篇文檔。
http://technet.microsoft.com/zh-cn/library/ms175595.aspx
此外，還是建議打算入門的朋友看一下微軟的教程。
http://technet.microsoft.com/zh-cn/library/bb677206.aspx
數據挖掘的過程，跟其它IT項目一樣，大概可以划分為如下幾個過程。首先，定義問題，然后准備和瀏覽數據，然后生成和驗證模型，最后部署和更新模型。
這個過程不一定是一口氣道底的，比如在模型中發現沒有需要的數據那么就需要重新對數據進行准備，或者在模型驗證階段發現有問題那么可能需要重新定義模型。
數據挖掘用到的查詢語句是DMX，它可以用來創建和處理挖掘模型，並且做預測查詢。可以參考我的這篇隨筆來了解更多信息：
http://www.cnblogs.com/aspnetx/archive/2013/03/23/2976661.html
開發工具
SQL Server分析服務的開發都是通過Visual Studio的一個Shell。對於Visual Studio很多應用程序開發人員應該再熟悉不過，但是很少有人知道它也可以用來開發商業智能項目。
在安裝完SQL Server Data Tools之后，在Visual Studio里就可以看到相應的項目模版，如下圖：
可以看到在項目模版里安裝了三大類項目模版，分別就是分析服務，集成服務和報表服務。而在創建分析服務項目中，也可以看到分析服務被分成了多維模式和Tabular模式兩種類型。
前面提到過，分析服務和數據引擎一樣，下面也是各種數據庫。傳統.net開發數據庫應用通過ADO.NET接口，分析服務是通過ADOMD.NET 接口。這兩樣接口不僅是名字比較像，由於它們繼承自同一接口，所以當一個熟練的程序員操作ADOMD.NET的時候會感覺這種方式似曾相識。
關於ADOMD.NET的使用方式，大家可以參考我在數據挖掘商品推薦系列隨筆的第二篇：
http://www.cnblogs.com/aspnetx/archive/2013/02/24/2924091.html
里面會有詳細的介紹，會告訴你如何新建一個asp.net的web services然后找到ADOMD.NET 組件的所在位置以及如何使用它。
總結
上面對於分析服務進行了一個簡短的介紹，在BI項目中的各個組件中，這確實是一個比較有趣而且也很有挑戰的一部分。但這只是BI項目中工作量的一小部分。在一個BI項目中，大多數的工作都是在ETL之上，這是一個很復雜需要耐心和細心的過程，這項工作的工作量往往要超過整個BI項目工作量的60%，而一個企業內部的BI團隊中，可以看到超過一半的人都是ETL這一層的開發人員。分析服務的工作往往都在ETL工作之后，並且很大程度上要受到這一層工作質量的影響。
在商業智能項目當中，最關鍵的就是數據，數據決定了一個商業智能項目的成敗。這里面數據要滿足三個層次，首先，就是要有數據可用，"巧婦難為無米之炊"用來形容這個再不為過。其次，數據量要達到一定的規模，只有數據越多才越容易發現其中的規律，好比一個剛畢業的醫生和一個干了一輩子的醫生的經驗。最后，就是數據的質量，這是最重要的一個方面。很多系統盡管已經有了海量數據，但由於IT系統操作的不規范，所以導致積累了很多年的數據都無法發揮出價值。當然還有一個跟技術不太相關的一個因素也會影響着商業智能項目的成敗，那就是高層領導的重視程度，商業智能當初設計就是為決策層服務的，而且實際項目過程中有很多問題都要靠行政的手段去解決，這個沒有高層領導在身后的"撐腰"都是很難操作的。
至此，分析服務里的幾個重要組件已經基本介紹完畢，包括多維模式，Tabular Model和數據挖掘，此篇分別對它們進行了簡要的介紹，並且提供了筆者相應的鏈接資源作為引申參考。這篇隨筆也算是我將之前掌握的知識和寫的隨筆做一個總結，相關的詳細內容大家都可以去看我所提供的鏈接。
希望通過這篇簡單的隨筆，能夠讓更多的人了解SQL Server Analysis Services分析服務以及商業智能這個概念。