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

相關(guān)資料

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

分享語(yǔ)音

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

問答摘錄

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

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

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

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

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

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

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

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

也可以采用列式存儲(chǔ)表

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

用spark會(huì)好很多

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

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

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

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

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

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

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

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

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

蔣步星：目前可能沒有吧，我不知道誰(shuí)能做這個(gè)。可以做到的是，把用戶查詢歷史記錄下來再分析，把最常用的匯總找出來，先算好，以后的查詢可能還是較大概率會(huì)用到這些匯總

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

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

彭晟：客戶端沒有意義，對(duì)嗎?

蔣步星：客戶端只管拖拉拽，不操心后臺(tái)怎么計(jì)算的

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

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

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

蔣步星：這個(gè)是可以做到的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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