成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

第1期:多維分析的后臺性能優(yōu)化手段

企業(yè)動態(tài)
OLAP需要即時響應,對性能要求很高,而這個運算形式雖然很簡單,但數(shù)據(jù)量大時的計算量也不小,如果不設法優(yōu)化,效率就可能很差。下面我們介紹多維分析后臺建設時幾種經(jīng)常被采用的性能優(yōu)化手段。

[[191395]] 

多維分析就是針對一個事先準備好的數(shù)據(jù)立方體實施旋轉(zhuǎn)、切片(切塊)、鉆取等交互操作的過程,經(jīng)常也被直接稱為OLAP。它的后臺運算在結(jié)構(gòu)上很簡單,如果用SQL語法描述,大體形式為:

SELECT D,…, SUM(M), … FROM C WHERE D’=d’ AND … GROUP BY D,…

即對立方體按某些維度分組匯總某些測度。其中C是數(shù)據(jù)立方體,D,…是選出維度,M,…是聚合測度,聚合函數(shù)也可以不是SUM。D’是切片維度,切塊時條件為D IN (d,…),WHERE中還可以增加針對某些測度的條件,一般也就是選出某個區(qū)間內(nèi)的值。

多維分析就是針對一個事先準備好的數(shù)據(jù)立方體實施旋轉(zhuǎn)、切片(切塊)、鉆取等交互操作的過程,經(jīng)常也被直接稱為OLAP。它的后臺運算在結(jié)構(gòu)上很簡單,如果用SQL語法描述,大體形式為:

SELECT D,…, SUM(M), … FROM C WHERE D’=d’ AND … GROUP BY D,…

即對立方體按某些維度分組匯總某些測度。其中C是數(shù)據(jù)立方體,D,…是選出維度,M,…是聚合測度,聚合函數(shù)也可以不是SUM。D’是切片維度,切塊時條件為D IN (d,…),WHERE中還可以增加針對某些測度的條件,一般也就是選出某個區(qū)間內(nèi)的值。

OLAP需要即時響應,對性能要求很高,而這個運算形式雖然很簡單,但數(shù)據(jù)量大時的計算量也不小,如果不設法優(yōu)化,效率就可能很差。下面我們介紹多維分析后臺建設時幾種經(jīng)常被采用的性能優(yōu)化手段。

預先匯總

預先匯總是早期OLAP產(chǎn)品常用的手段,簡單地就是拿空間換時間。把部分或者全部維度組合(GROUP BY子句)的匯總值(SELECT中的聚合測度)先計算出來保存,以后的計算可以直接取出或從這些中間結(jié)果再計算,性能會好很多。

預先匯總占用的空間有點大。如果保存全部維度組合,一般應用場景下(十幾到幾十個維度,維度取值范圍在幾到幾十之間),簡單計算可知,空間占用會比原始立方體大數(shù)倍到數(shù)十倍((k1+1)*(k2+1)*…與k1*k2*…之間的比,還要考慮多種聚合函數(shù))。雖然要保證即時響應時立方體都不會太大,但再大幾十倍經(jīng)常也還是難以接受的。

折衷辦法是只保存部分維度組合。OLAP過程中在界面上呈現(xiàn)出來的分組維度(GROUP BY子句)不會太多,可以只匯總所有m個維度的組合,在m不太大時(一般不超過5),空間增長還可以容忍,而用戶的大多數(shù)操作都可以得到較迅速響應。

麻煩在于,部分匯總解決不了針對其它維度的切片條件,鉆取動作就是以切片為基礎的。而且,即使全量匯總也無法處理測度上的條件(比如銷售額超過1000元的統(tǒng)計),而多維分析時常常允許這些動作,甚至聚合函數(shù)也可能帶有條件(只合計100元以下的費用),這些都無法使用預先匯總的結(jié)果。

預先匯總只能解決小部分最常見的計算,更多的情況還是要靠硬遍歷。

分段并行

多維分析本質(zhì)上是過濾和分組匯總,這種運算很容易并行。只要簡單地數(shù)據(jù)拆成多段后分別處理,收集到結(jié)果再匯總。各個子任務之間沒有依賴關系,無論是單機多線程還是集群多機或者綜合有之,都不難實現(xiàn)。

多維分析的結(jié)果是要呈現(xiàn)給人看的,而人可以觀察的數(shù)據(jù)量遠遠小于現(xiàn)代計算機的內(nèi)存。可以放入內(nèi)存的小結(jié)果集不需要和外存交換,程序設計復雜度較低,運算性能也好。如果運算時發(fā)現(xiàn)結(jié)果集太大是可以直接報告給界面相應信息并中止。

實踐測試表明:多線程計算時,不要采用各子任務向同一個結(jié)果集匯總的方案,這樣看起來會減少內(nèi)存占用(各子任務共用一個最終結(jié)果集),但多線程搶占同一資源需要的同步動作會嚴重影響性能。

線程數(shù)也不是越多越好,顯然超過CPU核數(shù)就沒有意義了。如果數(shù)據(jù)在外存,還要考慮硬盤的并發(fā)能力,一般會比CPU核數(shù)小很多,具體合適的數(shù)值需要實際測試才知道。

在數(shù)據(jù)不再變化時分段也容易,按記錄數(shù)切分后設置分段點即可。數(shù)據(jù)可追加時要做到較平均的分段會有些麻煩,以后再另外撰文陳述。

對于單個計算任務,并行后常常有數(shù)倍的性能提升。但是,OLAP操作本身就是個并發(fā)性事務,即使用戶數(shù)不大,也足以抵消并行計算帶來的性能提升。

還要再想辦法。

排序索引

沒有切片的匯總運算總是要涉及全量數(shù)據(jù),如果不是預先匯總,也沒什么辦法再減少計算量了。但有切片運算時(鉆取動作),如果數(shù)據(jù)能合理組織,就未必要遍歷所有數(shù)據(jù)了。

如果我們?yōu)榫S度D建立索引(即把各記錄的D值及記錄位置按D值排序),那么涉及D的切片條件就可以迅速定位到相應的記錄上(簡單二分法),不需要遍歷全量數(shù)據(jù),計算量常常會有數(shù)量級的減少(取決于D的取值范圍)。理論上我們可以為每個維度都建立索引,這個成本并不算高,這樣只要涉及有切片時,性能就會大幅提升。

需要指明的是,為多個維度D1,D2建立的多字段索引用處并不大,它不能用于迅速定位只有D2的切片,只能用于對D1,D2都有切片條件的情況。在選擇取值范圍***的那個切片維度用于定位后,計算量減少已經(jīng)很多了,其它維度的切片可以仍用遍歷手段。

不幸的是,這種原始方案只適用于可以頻繁小量訪問的內(nèi)存數(shù)據(jù)。如果數(shù)據(jù)量大到必須放在外存中(而這是經(jīng)常發(fā)生的),按索引大量取出實際上并未連續(xù)存儲的數(shù)據(jù)時,性能并不會有明顯提高。外存數(shù)據(jù)必須被真實排序、保證相應切片的數(shù)據(jù)是連續(xù)存儲的,性能提升才會有效。

如果對每個維度都做排序,那相當于數(shù)據(jù)要被復制若干倍,這個成本就有點高了。

一個折衷的辦法是把做兩個,按維度D1,…,Dn排序一次,再按Dn,…,D1排序一次,數(shù)據(jù)量只是翻倍,還能容忍。總能找到一個切片維度在兩個維度排序列的前半部分,這樣該維度切片的數(shù)據(jù)還是基本連續(xù)的,性能提升仍會較為明顯。

列存壓縮

對付多維分析還有個大殺器:列式存儲。

多維分析的立方體中字段(維度和測度)常常都很多,幾十個上百個都很正常,但同時需要取用的字段并不多,如果不算切片維度,通常也就5個左右或更少。而切片可以用上面的索引方案解決,實際要遍歷的字段也仍然不多。

這時候列存就會有巨大優(yōu)勢了。外存計算的IO時間占比相當大,減少數(shù)據(jù)讀取量比減少運算量常常能更有效地提高性能。一個100個字段的立方體,如果只取5個字段時,IO開銷只有1/20,這會帶來數(shù)量級的性能提升。

列存還有個優(yōu)勢是可以壓縮數(shù)據(jù)量。如果按前述所說將數(shù)據(jù)按維度D1,…,Dn排序存儲,我們會發(fā)現(xiàn)D1在連續(xù)許多記錄中取值都相同,D2也是類似,但程度會弱一些,越往后的維度連續(xù)相同的程度越弱,Dn就會幾乎沒有相同連續(xù)值。連續(xù)相同的值沒必要重復存儲,可以只存一次并記錄個數(shù),這樣將可以進一步減少存儲量,也就是減少外存IO訪問量,從而提高性能。

當然,列存也并不全是好處。

因為不減少計算量,列存對于內(nèi)存數(shù)據(jù)用處不大。不過壓縮存儲方式仍然有意義,可以減少內(nèi)存占用。

使用列存會使分段并行及建立索引的處理變得更復雜,各個列需要同步分段才能并行處理,索引也需要同步指向所有列,而使用壓縮機制后同步更為麻煩。不過,總得來講,在數(shù)據(jù)已經(jīng)確定不再變化時,雖然麻煩,但難度并不算大,只是別忘處理了就行。

列存還會加大硬盤的并發(fā)壓力,在總字段數(shù)不多或取用字段較多時并沒有優(yōu)勢。對于機械硬盤,如果再使用并行手段進一步加劇并發(fā)壓力,很可能導致性能不升反降的結(jié)果,對于易于并發(fā)的固態(tài)硬盤使用列存較為合適。

責任編輯:杜寧 來源: 51CTO專欄
相關推薦

2017-09-26 09:23:07

大數(shù)據(jù)多維實踐

2016-10-16 13:48:54

多維分析 UVPV

2018-02-06 23:30:07

文件存儲數(shù)據(jù)

2024-08-26 14:54:54

2023-07-03 07:46:50

大數(shù)據(jù)計算平臺SuperSQL

2017-05-25 08:56:22

硬盤性能特征

2017-05-21 22:32:39

報表性能優(yōu)化

2022-11-11 08:16:02

java性能技術

2021-08-02 08:34:20

React性能優(yōu)化

2018-02-25 22:44:01

RDBNoSQL數(shù)據(jù)庫

2020-10-20 08:19:21

Web性能網(wǎng)絡

2023-10-26 06:55:17

風控系統(tǒng)應用

2023-08-01 09:09:05

崔紅保跨平臺開發(fā)

2011-09-02 10:59:02

大數(shù)據(jù)數(shù)據(jù)分析Hadoop

2024-04-17 12:58:15

MySQL索引數(shù)據(jù)庫

2022-07-15 08:52:03

Linux優(yōu)化

2024-03-14 08:17:33

JVMJava對象

2011-05-27 14:28:33

DB2

2023-02-01 18:31:03

陳峰 數(shù)倉寶貝庫

2011-10-14 18:38:51

Linux運維趨勢優(yōu)化電子雜志
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 不卡一区| 欧美精品乱码久久久久久按摩 | 懂色av一区二区三区在线播放 | 久久亚洲一区 | 激情国产在线 | 一级黄色录像片子 | 国产又色又爽又黄又免费 | 欧美一区二区免费视频 | www免费视频 | 国产在线小视频 | 成人一区二区在线 | 超碰97在线免费 | 2018国产精品 | 成人不卡| 六月婷婷久久 | 亚洲综合婷婷 | 黄色片网站在线观看 | 国产精品久久久久一区二区三区 | 91av亚洲| 欧美久久综合 | 日日做夜夜爽毛片麻豆 | 久久er精品 | 久热久热 | 精品一区二区三区在线播放 | 国产精品久久久久久久久免费相片 | 蜜臀91视频 | 美日韩免费视频 | 日韩三级视频 | 羞羞视频在线网站观看 | 日韩在线一区二区三区 | 国产精品乱码一二三区的特点 | 日韩成人免费视频 | 超碰成人av | 青青草一区 | 国产成人精品综合 | 欧美中文字幕一区二区三区 | 久久久精品一区 | 日韩精品在线一区 | 天堂在线免费视频 | 亚洲激精日韩激精欧美精品 | 成人毛片在线观看 |