4月10日晚7點(diǎn)，潤乾軟件創(chuàng)始人蔣步星，在清華IT群里發(fā)起并分享了一期關(guān)于《OLAP后臺優(yōu)化技術(shù)》的專題討論，共有來自世界各地的60多位技術(shù)牛人，參與了本次微信直播討論。

相關(guān)資料

【數(shù)據(jù)蔣堂】第1期：多維分析的后臺性能優(yōu)化手段

分享語音

微信群直播討論，首先由蔣步星通過語音和圖片分享了20分鐘的講座。

問答摘錄

基于蔣步星的講述，針對該專題隨后大家開展了更深入的交流，以下是部分問答摘錄。

杰克:用列存得換數(shù)據(jù)庫呀?

蔣步星：是要換數(shù)據(jù)庫，甚至不能用數(shù)據(jù)庫來做，數(shù)據(jù)庫未必會做那樣的壓縮處理，也不會做雙逆序的排序索引

老笨熊：今天講的內(nèi)容是基于單服務(wù)器的OLAP優(yōu)化吧?

蔣步星：單服務(wù)器和多服務(wù)器沒本質(zhì)差別了，單服務(wù)器優(yōu)化好了，多服務(wù)器自然也就好了，OLAP運(yùn)算相對比較容易集群，因為沒有JOIN，也都是小分組

彭晟：那么OLAP跟以前關(guān)系型數(shù)據(jù)庫的關(guān)系是什么

蔣步星：早期的OLAP服務(wù)器是自己做的CUBE，一般用開始說的那種預(yù)先匯總的方式。后來就直接用關(guān)系數(shù)據(jù)庫了，因為數(shù)據(jù)庫的性能也提上來了，而且容量能大許多，但現(xiàn)在數(shù)據(jù)量逐步加大，關(guān)系數(shù)據(jù)庫很多也撐不住，用戶體驗變惡劣，有些用戶就開始自己想辦法，或者有些廠商開始再做專門的OLAP服務(wù)器

老笨熊：多服務(wù)器的話，如果采用Hadoop Hive，數(shù)據(jù)自動分片在很多服務(wù)器上

也可以采用列式存儲表

蔣步星：HIVE可以用集群和列存，但不會自主采用我說的雙倍排序索引，關(guān)鍵是HDFS把數(shù)據(jù)打亂了，你也搞不清它在硬盤上到底是不是連續(xù)存儲的，結(jié)果只能憑運(yùn)氣了，而且HIVE實(shí)在太慢了，HADOOP整個設(shè)計目標(biāo)就不是面向即時運(yùn)算的，而OLAP是個即時運(yùn)算

用spark會好很多

老笨熊：您說的雙倍排序索引是對同一列或者幾列進(jìn)行升序和降序排序么?

蔣步星：不是，就是按D1,D2,…Dn排個序。再按Dn,…,D1排個序。數(shù)據(jù)冗余兩份。然后切片時選擇其中一份數(shù)據(jù)用，可以保證切片后數(shù)據(jù)的連續(xù)程度仍較高，在外存訪問時性能較好

老笨熊：我嘗試一下Oracle是否支持建這樣的索引

老笨熊：組合索引D1。。。。Dn

老笨熊：然后再看看能不能建反向的Dn 。。。。。D1

老笨熊：不過在查詢中SQL優(yōu)化器能不能只能用到那是另外一回事了

蔣步星：oracle可以建索引，也會智能的選擇，但這個事是要智能的選擇表，而不是索引

蔣步星：ORACLE不會的，正向和反向，對ORACLE來講是兩個表。對于一個表，它知道用哪個索引再合適

彭晟：專有名詞不懂了。我們問點(diǎn)科幻的。那就是說還是要從查詢需求出發(fā)，會不會發(fā)展到后來具備一定的智能了，自己閑著沒事時，就在某個地方計算一些維度結(jié)果擱那，等哪天有人來查詢了，效率賊高。讓其遍歷查詢條件，計算空閑時處理和存儲，還是說已經(jīng)實(shí)現(xiàn)了?

蔣步星：目前可能沒有吧，我不知道誰能做這個?？梢宰龅降氖?，把用戶查詢歷史記錄下來再分析，把最常用的匯總找出來，先算好，以后的查詢可能還是較大概率會用到這些匯總

彭晟：那這些都是在服務(wù)器端搞定的吧

蔣步星：是服務(wù)器端

彭晟：客戶端沒有意義，對嗎?

蔣步星：客戶端只管拖拉拽，不操心后臺怎么計算的

彭晟：反正遍歷條件嘛，數(shù)據(jù)庫里加了新數(shù)據(jù)了，就再算一遍，還是可行的

蔣步星：預(yù)先遍歷，沒辦法預(yù)測所有情況，如果把測度條件都考慮上，那空間會無窮大的

彭晟：好像是的，你剛才說的根據(jù)客戶查詢頻率來搞更靠譜

蔣步星：這個是可以做到的

蔣步星：現(xiàn)在應(yīng)當(dāng)是沒有數(shù)據(jù)庫把這些手段都用上了，我們自己在做這方面工作，但實(shí)際情況比文章中寫的要復(fù)雜，我要考慮數(shù)據(jù)還要追加時的分段并行，要麻煩很多

老笨熊：你的產(chǎn)品有demo么?要是可能的話，做個視頻的demo演示環(huán)境

蔣步星：我不是專門為OLAP做，這些能力倒是大部分都有，但沒有組合成一個直接可用的成品，下一步是考慮專門整理出一個OLAP的服務(wù)器，所以今天的內(nèi)容，其實(shí)很大多數(shù)應(yīng)用軟件開發(fā)商沒多大用處，大部分應(yīng)用廠商只是用，不會也不該去琢磨后臺怎么優(yōu)化，這些優(yōu)化也都要涉及到較低層的東西，應(yīng)用開發(fā)商也不該做了

蔣步星：OLAP這個話題，是在清華IT群中有同學(xué)問起來，我剛好還算有些經(jīng)驗，就接過來講了。坦白地說，我認(rèn)為現(xiàn)在這種實(shí)際上是多維分析的OLAP，其實(shí)并沒有多大的業(yè)務(wù)意義，所以我們對于做它的興致也不太高，順便能組合出一個也還行，專門搞它劃不來

老笨熊：考慮過OLAP工具么?

蔣步星：OLAP什么工具?前端工具?Cognos?BIEE?

老笨熊：就是OLAP工具對你的這種優(yōu)化技術(shù)的支持

蔣步星：那大概就是這些前端東西了，這些東西，有些得基于自己CUBE的，那只能看它的CUBE是不是會采用這些優(yōu)化技術(shù)了。有些是基于SQL的，這樣只要封裝出SQL接口倒是可以。我不知道現(xiàn)在還有沒有基于MDX的了，似乎都過時淘汰了?

李晨：我在加州。剛剛聽了講座。謝謝!有個簡單問題，現(xiàn)在有沒有好的開源OLAP產(chǎn)品?市場需求大不大?

蔣步星：開源產(chǎn)品很多，不過主要是都是在前端，后臺做得深入的不多，如果說市場容量，我個人覺得，至少在國內(nèi)，不是很大，OLAP從字面意義上說希望在線分析，但能做的事實(shí)在太少了，立方體過于死板，稍微靈活些的查詢都會出圈，業(yè)務(wù)意義并不算很大。這個話題其實(shí)可以找機(jī)會再仔細(xì)講一把，死板式的OLAP，各種敏捷BI產(chǎn)品都提供得有，EXCEL的透視表也都不錯。目前就是數(shù)據(jù)量特大的情況不好處理，能提供出大數(shù)據(jù)量高性能的OLAP，會有一定市場需求。

Randy：I/O的確是OLAP和其它數(shù)據(jù)分析的瓶頸，尤其在大數(shù)據(jù)應(yīng)用中。群系統(tǒng)使得這個問題更加具有挑戰(zhàn)性，因為數(shù)據(jù)不僅可能在外存，還可以在其它節(jié)點(diǎn)上。一個基本原則是盡量保證計算和數(shù)據(jù)在本地匹配。業(yè)務(wù)邏輯不再負(fù)責(zé)I/O，數(shù)據(jù)由平臺或框架獲取，然后驅(qū)動用戶定義的計算。M/R 和 Spark 都是這個模型，同樣的原則也可以應(yīng)用到OLAP上。

蔣步星：OLAP的計算結(jié)構(gòu)很簡單，小結(jié)果集分組匯總，各分段任務(wù)無關(guān)，很容易集群。用M/R的術(shù)語來說，它不需要shuffle階段。集群時主要解決的問題是數(shù)據(jù)分布和負(fù)載均衡，有時需要用數(shù)據(jù)冗余來實(shí)現(xiàn)均衡負(fù)載，也不是很難

蔣步星：不過OLAP的優(yōu)化手段就這些，也不容易想出更多，所謂大數(shù)據(jù)量也大不到哪里去。特別是因為OLAP的業(yè)務(wù)意義不夠大，如果讓用戶花很多錢建設(shè)一個集群系統(tǒng)只為解決OLAP需求，我覺得大多數(shù)用戶是不肯的。如果有某個計算體系能順便把大數(shù)據(jù)量OLAP的事也解決掉，那還可以，用戶買單的原因更多是計算體系?，F(xiàn)在用戶其實(shí)就愿意用RDB來作OLAP，而不愿意專門搞個只能跑OLAP的產(chǎn)品，因為RDB不止干這一件事。

大數(shù)據(jù)李：國云魔鏡就是olap的前端產(chǎn)品

蔣步星：前端情況其實(shí)也有點(diǎn)類似。單純只做OLAP功能的，估計也很難賣得掉，大多數(shù)前端產(chǎn)品都有一整套敏捷BI功能，OLAP只是其中一部分。用戶不大會單純?yōu)橐粋€OLAP功能去買單

李晨：做基于集群數(shù)據(jù)庫之上的OLAP中間件怎么樣?位于前端和數(shù)據(jù)庫之間。市場怎么樣?

李晨：我現(xiàn)在正在做一個開源的并行數(shù)據(jù)庫Apache AsterixDB，以及一個支持OLAP的中間件。如果大家感興趣，我可以找時間講一下，聽取大家的寶貴意見。

蔣步星：并行數(shù)據(jù)庫是有意義的，但單純的OLAP中間件，我認(rèn)為意思不大，在早上已經(jīng)表達(dá)過這個觀點(diǎn)了。如果并行數(shù)據(jù)庫順便把OLAP問題解決了，那是可以的，用戶感興趣的更多的還在于這個并行數(shù)據(jù)庫

卡車：剛剛聽完，獲益匪淺，之前沒接觸過olap，有幾個問題想請教一下…1. 數(shù)據(jù)的規(guī)模和響應(yīng)時間。您可不可以給一些數(shù)字，讓我們對olap處理預(yù)期處理的數(shù)據(jù)規(guī)模和工業(yè)界當(dāng)前能夠做到的性能有個概念…2.對于并發(fā)用戶使得thread變?yōu)関irtual thread的問題，應(yīng)該很好解決，多臺服務(wù)器前面加個load balancer…假設(shè)5臺機(jī)器，每個機(jī)器每一時間只處理一個請求，平均一臺機(jī)器處理一個請求需要10s，用戶能夠容忍的最長的response time是30s…這樣這個系統(tǒng)就能夠處理大約15個并發(fā)任務(wù)，并且只要后續(xù)請求小于每秒一個，就不會有請求被拒絕…假設(shè)用戶高峰時期最多會有1/4的并發(fā)，那么這樣的系統(tǒng)基本可以滿足60人的用戶團(tuán)隊…我們公司做金融數(shù)據(jù)分析，后面計算服務(wù)完全是不同的路子，但是處理請求是這樣的…

蔣步星：2的辦法是可以的，相當(dāng)于限制并發(fā)數(shù)，能改善用戶體驗，不過這不是后臺優(yōu)化該考慮的事情了。后臺優(yōu)化就是努力做到更快，實(shí)在快不了時如何限制用戶使用范圍，那是應(yīng)用層面的事情了。

對于1，響應(yīng)時間和硬件環(huán)境相關(guān)性很強(qiáng)。大多數(shù)情況只是簡單的SUM/COUNT這種統(tǒng)計，可以這樣粗略地估算：CPU時間可以忽略掉(實(shí)際上是CPU時間相對少，在硬盤訪問的間隙中就夠了，看起來好象不需要時間)，只看涉及數(shù)據(jù)量的硬盤時間，機(jī)械硬盤我一般按100-150M/s去計算，SSD會翻個倍。這比硬盤廠商公布的指標(biāo)要低很多，原因是操作系統(tǒng)下訪問文件(數(shù)據(jù)庫自己訪問硬盤也差不多)做不到那個極限值。然后再看你的陣列中有多少塊盤，做一下除法就大概知道了

蔣步星：這樣估算的出來的是個上限，不可能比這個數(shù)更快了。

蔣步星：如果全量數(shù)據(jù)都能裝進(jìn)內(nèi)存，現(xiàn)代服務(wù)器的CPU(核)很多，并行起來基本上都能做到秒級返回，用戶不會有明顯的等待感。

卡車：數(shù)據(jù)量會是決定解決方案的一個很重要的參數(shù)…進(jìn)一步想，我覺得olap應(yīng)該是用來分析人產(chǎn)生的數(shù)據(jù)而不是機(jī)器產(chǎn)生的數(shù)據(jù)的，因此數(shù)據(jù)量不會大到需要之前有人提到的hbase，hadoop的程度…

蔣步星：OLAP分析機(jī)器產(chǎn)生的數(shù)據(jù)也是可能的，但會經(jīng)過一輪匯總處理變小一些。大到需要hadoop的時候，是不可能實(shí)時交互分析的