BI筆記之—合理處理SSAS資料庫的幾點建議

來源:互聯網
上載者:User

今天又有朋友遇到SSAS資料庫處理速度慢的情況,主要是由於資料彙總量確實很大,每次處理都要超過三十分鐘,有沒有什麼方法能讓處理的時間少一些呢?

從事BI工作有七個年頭了,這樣類似的問題絕對可以排在職業圈內TOP 10的FAQ當中。這樣的問題往往都略有複雜,在此根據遇到過的一些情境,羅列一些自己的經驗。

由於篇幅限制,這裡只介紹遇到問題時的解決思路,詳細的操作我會連結到我的其它隨筆供大家實際操作的時候參考,還有很多建議上的細節都盡量標出官方文檔的出處供大家擷取更多內容。

 

 

提升資料倉儲層相關表的查詢效率

SSAS資料庫在處理時,要向資料倉儲層拋SQL查詢。所以對相應的維表和事實表進行最佳化是這一步的關鍵。

我先前見過一個情況,就是有一個項目的事實表是一個視圖,而這個視圖裡有比較複雜的運算和串連。所以每次處理Cube的時候,都要等查詢要準備好久才開始讀取資料。後來我建議定期把視圖裡的資料放到一張表裡,保證每次讀事實表的資料不用經過視圖而是直接讀已經處理好的資料。

這是最簡單直接的方法,將事實表的資料"實體"化,讓視圖中的資料計算一次然後將結果儲存到表中,以保證後續的查詢分析應用都可以快速的得到結果。

剩下的就是基本的資料庫最佳化,比如索引最佳化等,此外還有大資料解決方案如HADOOP或者PDW等,這部分的內容已經遠遠超出了本文所描述的範圍,這裡不再做詳細講解。

 

 

累加式更新

這是最常用的一個方法。假如每個周期產生的資料量是100mb,那麼在剛開始的幾個處理周期裡可能不會有問題,但假如說你的處理周期是每周或者每天,那麼隨著時間的推移你的曆史資料會越來越多,每次都全量處理就不是很明智。所以我們就需要用增量的方法來處理資料。

在SSAS中,增量處理需要指定增量查詢。也就是說,需要你有一個嚴格的資料流程。首先,增量處理之前,你需要把增量資料預備好,在增量處理完之後,還需要妥善的處理增量資料(比如在表或者視圖中),避免重複進行的增量處理導致資料翻番。

如果資料倉儲有更新的情況,可以在設計資料倉儲的時候考慮1-1+1的方案。具體方法這裡只說一個思路,大家可以根據自己系統的情況進行設計。

具體的參考流程,可以參考我先前的一個筆記:

BI筆記之---增量方式處理Cube

這篇將介紹如何產生測試資料然後利用這些測試資料示範如何做基本的資料累加式更新,同時也會讓你對Cube的累加式更新有一個瞭解。

 

 

建立分區

跟資料庫裡的表一樣,SSAS的Cube也可以建立分區。理論上來說,建立分區對資料的處理速度不會有太大的影響,但是之所以放在這裡,是由於,可以藉助分區的方式,來間接的實現"累加式更新"。

上一步對累加式更新的介紹,你可以看到實際操作起來是有多複雜。藉助分區的方式,你就可以多少偷一下懶。具體的思路就是,把Cube按照某一維度進行分區,時間或者空間的方式均可。比如按照時間的方式,以月為粒度進行分區。然後在每次處理的時候,只處理增量資料點所在的那個分區。

這個方法的關鍵點就是如何自動的識別出那個待處理的分區。我個人認為主要在於Cube的設計要完全按照一個嚴格的標準。比如對分區名稱有一個嚴格的命名規範,以讓代碼可以很容易的找到這個分區。

具體的操作方法,可以參考我先前的一個隨筆:

BI筆記之---Cube增量處理的一個情境的處理方案

裡面主要介紹了用編程的方法來根據指定的規則,找到待處理的分區,然後對其進行處理。

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

總之,解決問題的方法很多,這裡只列舉一些比較常見的問題以及我個人的建議,其它有代表性的問題也歡迎大家列出來在這裡做進一步的探討。

最後,希望這篇對大家有協助。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.