【清华IT群分享】OLAP后台技术专题讨论

发布时间:2017-04-12 分类:公司动态 Tag:,,,
4月10日晚7点,润乾软件创始人蒋步星,在清华IT群里发起并分享了一期关于《OLAP后台优化技术》的专题讨论,共有来自世界各地的60多位技术牛人,参与了本次微信直播讨论。

相关资料

【数据蒋堂】第1期:多维分析的后台性能优化手段

分享语音

微信群直播讨论,首先由蒋步星通过语音和图片分享了20分钟的讲座。为方便大家观看,已将语音和图片整理成视频,建议在wifi环境下观看。

问答摘录

基于蒋步星的讲述,针对该专题随后大家开展了更深入的交流,以下是部分问答摘录。


杰克:用列存得换数据库呀?

蒋步星:是要换数据库,甚至不能用数据库来做,数据库未必会做那样的压缩处理,也不会做双逆序的排序索引


老笨熊:今天讲的内容是基于单服务器的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的时候,是不可能实时交互分析的