今天又有朋友遇到SSAS數據庫處理速度慢的情況，主要是由於數據聚合量確實很大，每次處理都要超過三十分鍾，有沒有什么方法能讓處理的時間少一些呢？
從事BI工作有七個年頭了，這樣類似的問題絕對可以排在職業圈內TOP 10的FAQ當中。這樣的問題往往都略有復雜，在此根據遇到過的一些場景，羅列一些自己的經驗。
由於篇幅限制，這里只介紹遇到問題時的解決思路，詳細的操作我會鏈接到我的其它隨筆供大家實際操作的時候參考，還有很多建議上的細節都盡量標出官方文檔的出處供大家獲取更多內容。
提升數據倉庫層相關表的查詢效率
SSAS數據庫在處理時，要向數據倉庫層拋SQL查詢。所以對相應的維表和事實表進行優化是這一步的關鍵。
我先前見過一個情況，就是有一個項目的事實表是一個視圖，而這個視圖里有比較復雜的運算和連接。所以每次處理多維數據集的時候，都要等查詢要准備好久才開始讀取數據。后來我建議定期把視圖里的數據放到一張表里，保證每次讀事實表的數據不用經過視圖而是直接讀已經處理好的數據。
這是最簡單直接的方法，將事實表的數據"實體"化，讓視圖中的數據計算一次然后將結果保存到表中，以保證后續的查詢分析應用都可以快速的得到結果。
剩下的就是基本的數據庫優化，比如索引優化等，此外還有大數據解決方案如HADOOP或者PDW等，這部分的內容已經遠遠超出了本文所描述的范圍，這里不再做詳細講解。
增量更新
這是最常用的一個方法。假如每個周期產生的數據量是100mb，那么在剛開始的幾個處理周期里可能不會有問題，但假如說你的處理周期是每周或者每天，那么隨着時間的推移你的歷史數據會越來越多，每次都全量處理就不是很明智。所以我們就需要用增量的方法來處理數據。
在SSAS中，增量處理需要指定增量查詢。也就是說，需要你有一個嚴格的數據流程。首先，增量處理之前，你需要把增量數據預備好，在增量處理完之后，還需要妥善的處理增量數據（比如在表或者視圖中），避免重復進行的增量處理導致數據翻番。
如果數據倉庫有更新的情況，可以在設計數據倉庫的時候考慮1-1+1的方案。具體方法這里只說一個思路，大家可以根據自己系統的情況進行設計。
具體的參考流程，可以參考我先前的一個筆記：
這篇將介紹如何生成測試數據然后利用這些測試數據演示如何做基本的數據增量更新，同時也會讓你對多維數據集的增量更新有一個了解。
建立分區
跟數據庫里的表一樣，SSAS的多維數據集也可以建立分區。理論上來說，建立分區對數據的處理速度不會有太大的影響，但是之所以放在這里，是由於，可以借助分區的方式，來間接的實現"增量更新"。
上一步對增量更新的介紹，你可以看到實際操作起來是有多復雜。借助分區的方式，你就可以多少偷一下懶。具體的思路就是，把多維數據集按照某一維度進行分區，時間或者空間的方式均可。比如按照時間的方式，以月為粒度進行分區。然后在每次處理的時候，只處理增量數據點所在的那個分區。
這個方法的關鍵點就是如何自動的識別出那個待處理的分區。我個人認為主要在於多維數據集的設計要完全按照一個嚴格的標准。比如對分區名稱有一個嚴格的命名規范，以讓代碼可以很容易的找到這個分區。
具體的操作方法，可以參考我先前的一個隨筆：
里面主要介紹了用編程的方法來根據指定的規則，找到待處理的分區，然后對其進行處理。
Cube的分區大小到底設置多大才合適，這個問題經常被問到。在這里文檔中有一處可以參考：
將超過 2 千萬行或大小超過 250 MB 的大分區拆分為較小的分區以改進性能
出處：
http://technet.microsoft.com/zh-cn/library/bb630302(v=sql.105).aspx
這里僅是一個大體的參考，數據行數還需要具體考察每一行的數據兩大小。
合理設置維度屬性
合理設置維度屬性關系，設置剛性或者柔性關系類型。這里主要摘錄微軟文檔中的內容進行簡單的介紹。
關於屬性維度屬性的關系，摘錄文檔中的一句話：
屬性關系具備以下優點：
減少維度處理所需的內存量。 加快維度、分區和查詢的處理速度。
提高查詢性能，因為存儲訪問速度更快而且執行計划更優化。
如果用戶定義的層次結構是沿關系路徑定義的，則聚合設計算法會選擇更有效的聚合。
引用地址：
http://technet.microsoft.com/zh-cn/library/ms174878.aspx
關於剛性和柔性關系的說明，摘錄文檔中的一句話：
指示成員關系是否隨時間而更改。 值為 Rigid 和 Flexible，前者表示成員之間的關系不隨時間而更改，后者表示成員之間的關系隨時間而更改。 默認值為 Flexible。 如果您將關系定義為 Flexible（柔性），則將刪除聚合並作為增量更新的一部分重新計算（如果只添加了新成員，則將不刪除聚合）。 如果您將關系定義為 Rigid（剛性），則 Analysis Services 會在增量更新維度時保留聚合。 如果定義為剛性的關系發生了實際更改，Analysis Services 會在增量處理過程中生成錯誤。 指定適當的關系和關系屬性，可提高查詢和處理性能。
引用地址：
http://technet.microsoft.com/zh-cn/library/ms176124.aspx
總體來說，通過屬性關系和關系類型的設置，雖然對處理時間的影響不見得最明顯，但這都是設計SSAS數據庫的一個很好的標准和習慣。
數據粒度提升
有很多項目為了能讓數據倉庫足夠"大"，會把數據的粒度收集的足夠細。比如某系統一天收集的數據量就有一個G。而瀏覽了所有報表之后，發現報表中大多數的時間粒度都是到月，只有部分是到天的。
當然，我不否認數據粒度越細，越容易發現更有用的信息。但是對於SSAS數據庫這層，對於通常的統計分析，對數據粒度要求不高，可以考慮將事實數據GROUP到上一級的粒度，比如秒到小時，或者小時到天，依次降低事實數據的數量。
對於確實需要小粒度統計分析的，建議只保留近段時間的數據就可以，這樣通常都可以滿足大部分需求。而粒度上升到什么層次才合適，建議根據實際的需求然后重新考察數據粒度的確定是否合適。
總之，原則就是，在資源有限的情況下，盡量"把錢用在刀刃上"，然后根據不同需求的不同特點，再去做單獨的設計。
數據樣本抽取
在開發和測試過程中，沒有必要直接把全部的歷史數據拿過來做測試。這主要是因為在各個環節中都可能要消耗很多時間等待，后續的開發和測試發現失敗或者有錯誤后，將流程進行修正，還需要再重新完整的跑一遍。
你可以認為，一個流程只要一個晚上能處理完，到第二天上班時能看到結果就可以了。但是，如果后續的測試驗證數據流程有bug，那么就意味着還要跑一個晚上，這樣項目進度很難保證。即使是一個要跑一個小時的流程，你可以算算一天有幾個小時可以反復的開發和測試然后又去驗證這個過程呢？
所以這里建議在開發和測試的過程中，只拿一小部分數據，比如在10年的數據中，只取一年或者一個月的，或者在所有產品品牌中，只取一個或者幾個品牌做整個項目的BI流程測試，最后驗證的也只是這一小部分數據，等這些小數據處理成功后，再去處理完整的數據。
數據的抽取方法，可以在數據源視圖中進行限制，也可以通過分區來動態控制。我個人建議選擇前者，操作起來比較容易些，不需要經常更改Cube的結構。
總結：
解決處理慢的問題，基本上就是從性能，方法和設計上下手，根據不同的場景可以選擇不同的方案。
此外，可以參考這篇《設計警告規則（Analysis Services - 多維數據）》
http://technet.microsoft.com/zh-cn/library/bb630321(v=sql.105).aspx
總之，解決問題的方法很多，這里只列舉一些比較常見的問題以及我個人的建議，其它有代表性的問題也歡迎大家列出來在這里做進一步的探討。
最后，希望這篇對大家有幫助。