【清华IT群分享】OLAP后台技术专题讨论
相关资料
分享语音
微信群直播讨论，首先由蒋步星通过语音和图片分享了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的时候，是不可能实时交互分析的