今天又有朋友遇到ssas資料庫處理速度慢的情況，主要是由於資料聚合量確實很大，每次處理都要超過三十分鐘，有沒有什麼方法能讓處理的時間少一些呢？
從事bi工作有七個年頭了，這樣類似的問題絕對可以排在職業圈內top 10的faq當中。這樣的問題往往都略有複雜，在此根據遇到過的一些場景，羅列一些自己的經驗。
提公升資料倉儲層相關表的查詢效率
ssas資料庫在處理時，要向資料倉儲層拋sql查詢。所以對相應的維表和事實表進行優化是這一步的關鍵。
我先前見過乙個情況，就是有乙個專案的事實表是乙個檢視，而這個檢視裡有比較複雜的運算和連線。所以每次處理多維資料集的時候，都要等查詢要準備好久才開始讀取資料。後來我建議定期把檢視裡的資料放到一張表裡，保證每次讀事實表的資料不用經過檢視而是直接讀已經處理好的資料。
這是最簡單直接的方法，將事實表的資料"實體"化，讓檢視中的資料計算一次然後將結果儲存到表中，以保證後續的查詢分析應用都可以快速的得到結果。
剩下的就是基本的資料庫優化，比如索引優化等，此外還有大資料解決方案如hadoop或者pdw等，這部分的內容已經遠遠超出了本文所描述的範圍，這裡不再做詳細講解。
增量更新
這是最常用的乙個方法。假如每個週期產生的資料量是100mb，那麼在剛開始的幾個處理週期裡可能不會有問題，但假如說你的處理週期是每週或者每天，那麼隨著時間的推移你的歷史資料會越來越多，每次都全量處理就不是很明智。所以我們就需要用增量的方法來處理資料。
在ssas中，增量處理需要指定增量查詢。也就是說，需要你有乙個嚴格的資料流程。首先，增量處理之前，你需要把增量資料預備好，在增量處理完之後，還需要妥善的處理增量資料（比如在表或者檢視中），避免重複進行的增量處理導致資料翻番。
如果資料倉儲有更新的情況，可以在設計資料倉儲的時候考慮1-1+1的方案。具體方法這裡只說乙個思路，大家可以根據自己系統的情況進行設計。
bi筆記之---增量方式處理多維資料集
這篇將介紹如何生成測試資料然後利用這些測試資料演示如何做基本的資料增量更新，同時也會讓你對多維資料集的增量更新有乙個了解。
建立分割槽
跟資料庫裡的表一樣，ssas的多維資料集也可以建立分割槽。理論上來說，建立分割槽對資料的處理速度不會有太大的影響，但是之所以放在這裡，是由於，可以借助分割槽的方式，來間接的實現"增量更新"。
上一步對增量更新的介紹，你可以看到實際操作起來是有多複雜。借助分割槽的方式，你就可以多少偷一下懶。具體的思路就是，把多維資料集按照某一維度進行分割槽，時間或者空間的方式均可。比如按照時間的方式，以月為粒度進行分割槽。然後在每次處理的時候，只處理增量資料點所在的那個分割槽。
這個方法的關鍵點就是如何自動的識別出那個待處理的分割槽。我個人認為主要在於多維資料集的設計要完全按照乙個嚴格的標準。比如對分割槽名稱有乙個嚴格的命名規範，以讓**可以很容易的找到這個分割槽。
bi筆記之---cube增量處理的乙個場景的處理方案
裡面主要介紹了用程式設計的方法來根據指定的規則，找到待處理的分割槽，然後對其進行處理。
cube的分割槽大小到底設定多大才合適，這個問題經常被問到。在這裡文件中有一處可以參考：
將超過 2 千萬行或大小超過 250 mb 的大分割槽拆分為較小的分割槽以改進效能
出處：這裡僅是乙個大體的參考，資料行數還需要具體考察每一行的資料兩大小。
合理設定維度屬性
合理設定維度屬性關係，設定剛性或者柔性關係型別。這裡主要摘錄微軟文件中的內容進行簡單的介紹。
關於屬性維度屬性的關係，摘錄文件中的一句話：
屬性關係具備以下優點：
減少維度處理所需的記憶體量。 加快維度、分割槽和查詢的處理速度。
提高查詢效能，因為儲存訪問速度更快而且執行計畫更優化。
如果使用者定義的層次結構是沿關係路徑定義的，則聚合設計演算法會選擇更有效的聚合。
關於剛性和柔性關係的說明，摘錄文件中的一句話：
指示成員關係是否隨時間而更改。 值為 rigid 和 flexible，前者表示成員之間的關係不隨時間而更改，後者表示成員之間的關係隨時間而更改。 預設值為 flexible。 如果您將關係定義為 flexible（柔性），則將刪除聚合並作為增量更新的一部分重新計算（如果只新增了新成員，則將不刪除聚合）。 如果您將關係定義為 rigid（剛性），則 analysis services 會在增量更新維度時保留聚合。 如果定義為剛性的關係發生了實際更改，analysis services 會在增量處理過程中生成錯誤。 指定適當的關係和關係屬性，可提高查詢和處理效能。
總體來說，通過屬性關係和關係型別的設定，雖然對處理時間的影響不見得最明顯，但這都是設計ssas資料庫的乙個很好的標準和習慣。
資料粒度提公升
有很多專案為了能讓資料倉儲足夠"大"，會把資料的粒度收集的足夠細。比如某系統一天收集的資料量就有乙個g。而瀏覽了所有報表之後，發現報表中大多數的時間粒度都是到月，只有部分是到天的。
當然，我不否認資料粒度越細，越容易發現更有用的資訊。但是對於ssas資料庫這層，對於通常的統計分析，對資料粒度要求不高，可以考慮將事實資料group到上一級的粒度，比如秒到小時，或者小時到天，依次降低事實資料的數量。
對於確實需要小粒度統計分析的，建議只保留近段時間的資料就可以，這樣通常都可以滿足大部分需求。而粒度上公升到什麼層次才合適，建議根據實際的需求然後重新考察資料粒度的確定是否合適。
總之，原則就是，在資源有限的情況下，盡量"把錢用在刀刃上"，然後根據不同需求的不同特點，再去做單獨的設計。
資料樣本抽取
在開發和測試過程中，沒有必要直接把全部的歷史資料拿過來做測試。這主要是因為在各個環節中都可能要消耗很多時間等待，後續的開發和測試發現失敗或者有錯誤後，將流程進行修正，還需要再重新完整的跑一遍。
你可以認為，乙個流程只要乙個晚上能處理完，到第二天上班時能看到結果就可以了。但是，如果後續的測試驗證資料流程有bug，那麼就意味著還要跑乙個晚上，這樣專案進度很難保證。即使是乙個要跑乙個小時的流程，你可以算算一天有幾個小時可以反覆的開發和測試然後又去驗證這個過程呢？
所以這裡建議在開發和測試的過程中，只拿一小部分資料，比如在10年的資料中，只取一年或者乙個月的，或者在所有產品品牌中，只取乙個或者幾個品牌做整個專案的bi流程測試，最後驗證的也只是這一小部分資料，等這些小資料處理成功後，再去處理完整的資料。
資料的抽取方法，可以在資料來源檢視中進行限制，也可以通過分割槽來動態控制。我個人建議選擇前者，操作起來比較容易些，不需要經常更改cube的結構。
總結：
解決處理慢的問題，基本上就是從效能，方法和設計上下手，根據不同的場景可以選擇不同的方案。
此外，可以參考這篇《設計警告規則（analysis services - 多維資料）》
最後，希望這篇對大家有幫助。
BI筆記之 SSAS庫Process的幾種方案
本文綜合描述ssas庫的處理的幾種方案，並簡單介紹各種方案的應用場景。環境約定 sql server 2008 示例庫 adventure works dw 方式一 直接在專案中process 這種方法在開發階段和測試階段是經常使用的。如圖這種處理方式通常是第一次的全量處理，如果ssas庫猶更新的話...
SSAS自動更新處理資料庫的最佳實踐
ssas sql server analysis services 建好分析資料庫以後，需要自動更新處理資料庫。常見的方式有以下幾種 推薦使用tmsl，一種基於json格式的指令碼語言。具體步驟如下 1.在ssms啟動ssas所在伺服器的資料庫引擎，在 sql server 下建立新的作業 2.在作...
python筆記6 資料處理之匯入資料
coding utf 8 資料一般儲存在檔案 csv txt excel 和資料庫中 1.匯入csv檔案 第一行是列名 from pandas import read csv 檔案的編碼格式也應該是 utf 8 才行，否則報錯 df read csv d python workspace pytho...