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

相關資料

【數據蔣堂】第1期：多維分析的后臺性能優化手段

分享語音

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

問答摘錄

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

杰克:用列存得換數據庫呀?

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

老笨熊：今天講的內容是基于單服務器的OLAP優化吧?

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

彭晟：那么OLAP跟以前關系型數據庫的關系是什么

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

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

也可以采用列式存儲表

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

用spark會好很多

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

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

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

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

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

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

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

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

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

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

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

蔣步星：是服務器端

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

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

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

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

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

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

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

老笨熊：你的產品有demo么?要是可能的話，做個視頻的demo演示環境

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

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

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

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

老笨熊：就是OLAP工具對你的這種優化技術的支持

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

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

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

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

蔣步星：OLAP的計算結構很簡單，小結果集分組匯總，各分段任務無關，很容易集群。用M/R的術語來說，它不需要shuffle階段。集群時主要解決的問題是數據分布和負載均衡，有時需要用數據冗余來實現均衡負載，也不是很難

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

大數據李：國云魔鏡就是olap的前端產品

蔣步星：前端情況其實也有點類似。單純只做OLAP功能的，估計也很難賣得掉，大多數前端產品都有一整套敏捷BI功能，OLAP只是其中一部分。用戶不大會單純為一個OLAP功能去買單

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

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

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

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

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

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

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

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

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

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