e-works数字化企业网  »  文章频道  »  基础信息化  »  运维管理

唯品会海量实时OLAP分析技术升级之路

2017/7/29    来源:运维派    作者:谢麟炯      
关键字:OLAP  唯品会  
首先来看一下我们在最初几年遇到的问题。第一就是大数据,听起来好像蛮无聊的,但大数据到底是指什么呢?最主要的问题就是数据大,唯品会在这几年快速发展,用户流量数据从刚开始的几百万、几千万发展到现在的几个亿,呈现了100倍以上的增长。

    Presto性能测试
 
    我们在用之前做了POC。我们做了一个尝试,把在我们平台上常用的SQL(不用TPCH的原因是我们平台的SQL更适合我们的场景),在GP和Presto两个计算引擎上,用相同的机器配置和节点数同时做了一次基准性能测试,可以看到结果是非常令人欢喜的。
 
    性能测试
 
    整体而言相同节点的Presto比GreenPlum的性能提升70%,而且SQL9到SQL16都从100多秒下降到10秒,可见它的提升是非常明显的。
 
    当我们做完性能测试时,我们一个专门做引擎开发的同学叫了起来,说就你了,用Presto替代GreenPlum。
 
    第3阶段
 
    数据
 
    在Presto引进来之后,我们发现整个数据架构变得非常顺畅,上层用拖拉拽的UI组件生成传给SQL到Parser,然后传给Presto执行。不管是流量数据,还是埋点,还是曝光数据返回非常快,同时我们也把场景扩展到包括订单、销售之类的事务型分析上。用了之后中位数返回时间5秒钟,平均返回时间15秒,基本上这段时间可以返回所有的OLAP查询。因为用了DW数据,维度更丰富,大多数的需求问题被解决。
 
    用了Presto之后用户的第一反应是为什么会这么快,到底用了什么黑科技。但是运行了一段时间后我们观察了用户的行为是什么样的,到底在查询什么样的SQL,什么维度和指标的组合,希望还能再做一些优化。
 
    最快的计算方法是不计算
 
    在这个时候我们突然发现,即使是用户自由组合的指标也会发现不同业务在相同业务场景下会去查完全相同的数据组合。比如很多用户会查同一渠道的销售流量转化,现在的方案会有什么问题呢?完全相同的查询也需要到上面真正执行一遍,实际上如果完全相同的可以直接返回结果不用计算了。所以我们就在想怎么解决这个问题?实际这里有一个所谓的理论——就是最快的计算就是不计算,怎么做呢?如果我们能够模仿Oracle的BGA,把计算结果存储下来,用户查询相同时可以把数据取出来给用户直接返回就好了。
 
    于是这里就讲到了缓存复用。第一个阶段完全相同的直接返回,第二个阶段更进一步,相对来说更复杂一些,如果说提出一个新的SQL,结果是上一个的,我们也不结算,从上一个结果里面直接做二次处理,把缓存的数据拿出来反馈给用户。除了这个亮点之外,其实缓存很重要的就是生命周期管理,非常复杂,因为数据不断地更新,缓存如果不更新可能查出来的数据不对,在数据库会说这是脏读或者幻影读,我们希望缓存的生命周期可以自己管理,不希望是通过超时来管理缓存,我们更希望缓存可以管理自己的生命周期,跟源数据同步生命周期,这样缓存使用效率会是最好的。
 
    Redis:成熟的缓存方案
 
    说到缓存要提到Redis,这是很多生产系统上大量使用的,它也非常适合OLAP。
 
    Redis
 
    首先我们想要的是SQL跟结果一对一匹配,它是非常符合这个需求的。其次我们希望缓存更快的返回,Redis是纯内存的存储,返回速度非常快,一般是毫秒级。第三个生命周期管理,它提供API,我们做二次开发,跟我们ETL调度系统打通,处理更新时就可以通知什么样的数据可以被用到。而缓存复用是不支持的,我们可以自己来做。
 
    第3.5阶段
 
Redis
 
    于是这时就把Redis的方案引入进来。
 
    引入Redis之后带来一个新的挑战,我们不是只有一个计算引擎,我们暂时先把Redis称为一个计算引擎,因为数据可能在Redis,也可能需要通过Presto去把数据读出来,这时我们在刚才生成SQL之后还加入了新的一个组件,Query Engine的目的就是在不同的引擎之间做路由,找到最快返回数据的匹配。比如说我们一个SQL发下来,它会先去找Redis,看在Redis找有没有这个SQL缓存的记录,有就直接返回给用户,没有再到Presto上面查询。上线了之后,我们观察了结果,结果也是非常不错的,发现平均的缓存命中率达到15%,意味着这15%的查询都是秒出。
 
    因为我们有不同的主题,流量主题、销售、收藏、客户,类似不同的主题,用户查询的组合不一样,特殊的场景下,命中率达到60%,这样除去缓存的返回速度非常快之外,缓存也有好处,就是释放了Presto的计算能力,原先需要跑一次的查询便不需要了。释放出来的内存和CPU就可以给其它的查询提供计算能力了。
 
    空间换时间:OLAP分析的另一条途径
 
    缓存的方案实施之后,看上去很不错了,这时候我们又引起了另一次思考,缓存现在是在做第二次查询的提速,但我们想让第一次的速度也可以更快一些。说到第一次的查询,我们要走回老路了,我们说空间换时间,是提升第一次查询一个最显而易见的办法。
 
    空间换时间,如果说OLAP ad-hoc查询从事先计算好的结果里查询,那是不是返回速度也会很快?其次,空间换时间要支持维度建模,它也要支持Join。最后希望数据管理简单一些,之前讲到为什么淘汰了GreenPlum,是因为数据同步复杂,数据的预计算不好控制,所以希望数据管理可以更简单一些。预计算的过程和结果的同步不需要二次开发,最好由OLAP计算引擎自己管理。同时之前讲到我们会有一个预先设计存在过度设计的问题,这个问题怎么解决?我们目前的场景是有Presto来兜底的,如果没有命中CUBE,那兜底的好处就是说我们还可以用Presto来承载计算,这让设计预计算查询的时候它的选择余地会更多。它不需要完全根据用户的需求或者业务需求把所有的设计在里面,只要挑自己合适的就可以,对于那些没有命中的SQL,虽然慢了一点,但给我们带来的好处就是管理的成本大大降低了。
 
    Kylin:eBay贡献的开源MOLAP引擎
 
    MOLAP引擎
 
    Kylin是由eBay开源的一个引擎,Kylin把数据读出来做计算,结算的结果会被存在HBase里,通过HBase做Ad-hoc的功能。HBase的好处是有索引的,所以做Ad-hoc的性能非常好。
 
    为什么是Kylin
 
    Kylin
 
    首先空间换时间,我们在刚开始引入Kylin时跟Kylin开发聊过,他们借鉴了Oracle CUBE的概念,对传统数据库开发的人来说很容易理解概念和使用。支持维度建模自然支持也Join。预计算的过程是由Kylin自己管理的,也开放了API,与调度系统打通做数据刷新。另外Kylin是在eBay上很大的、美团也是投入了很大的精力的有成功经验的产品,所以很容易地引进来了。
 
    第4阶段
 
    OLAP
 
    于是,我们进入了唯品会OLAP分析架构的第四阶段:Hybird:Presto的ROLAP和Kylin的MOLAP结合发挥各自优势,Redis缓存进一步提升效率。
 
    查询在Query Engine根据Redis-> Kylin再到Presto的优先级进行路由探查,在找到第一个可命中的路径之后,转向对应的引擎进行计算并给用户返回结果。Kylin的引入主要用于提升核心指标的OLAP分析的首次响应速度。这个状态可以看到Kylin的查询覆盖率平均15%,最高25%,大幅提升核心数据的查询。同时流量几十亿、几百亿的数据从Kylin走也大大地减轻了Presto。虽然说这样的架构看起来挺复杂的,但这样的一个架构出来之后,基本上满足了90%的OLAP分析了。
 
    OLAP分析的技术进化是一个迷宫而不是金字塔
 
    经过这么长一段时间的演进和一些摸索之后,我们觉得OLAP分析的技术是它的进化是一个迷宫,不是一个金字塔。过去说升级,像金字塔往上攀登,但实际上在刚才的过程大家发现实际上它更是像走迷宫,每个转角其实是都碰到了问题,在这个转角,在当时的情况下找最佳的方案。
 
    不是做了大数据之后放弃了计算,也不是做了大数据不再考虑数据同步的问题。其实可以发现很多传统数据仓库或者RBDMS的索引、CUBE之类的概念慢慢重新回到了大数据的视野里面。对我们而言,我们认为更多的时候,我们在做一些大数据的新技术演进时更多的是用更优秀的技术来做落地和实现,而不是去拒绝过去的一些大家感觉好像比较陈旧的的逻辑或概念。所以说对每个人来说,适合自己业务的场景方案才是最好的方案。
 
    3.唯品会在开源计算引擎上所做的改进
 
    接下来讲一下我们在开源计算引擎上做的改进。Presto和Kylin的角度不一样,所以我们在优化的方向上也不同。Presto主要注重提升查询性能,减少计算量,提升实时性。Kylin最主要优化维表查找,提高CUBE的利用率。
 
    Presto上的改进
 
    在提升查询性能上:
 
  • 新增Hint语法,首先做的也是最重要的改动是在Presto中增加了一个Hint的语法,可以在SQL Join级别动态设置策略,通过编译时让让join在replica和distribute两者之间设置,提高Join效率;
 
  • 监控告警JOIN数据倾斜,通过减少数据倾斜提高执行效率;
 
  • 增加多集群LOAD BALANCE,可平衡不同集群间计算量;
 
  • 经过改造,Presto的查询实时性大幅提升。
 
    在减少计算量上:
 
  • 新增Kylin Connector,通过CUBE探嗅自动匹配SQL子查询中可以命中Kylin CUBE的部分,从Kylin提取数据后做进一步的计算,降低查询计算量;
 
  • 经过改造,Presto升级为Hybird OLAP引擎,同时支持ROLAP和MOLAP两种模式。
 
    在提高实时性上:
 
  • 重写Kafka Connector,支持热更新Kafka中Topic、Message 和表/列的映射定义;
 
  • 支持Kafka按offset读取数据,支持PB格式,提高Kafka数据源的读取效率;
 
  • 经过改造,Presto不仅是离线OLAP引擎,准实时数据处理的能力也得到提高。
 
    Kylin上的改进
 
    在优化维表查找上:
 
  • 通过引入Presto解决Kylin亿级维表实时Lookup OOM的问题,通过Presto查询替换了原有复杂的维表映射值查找机制;
 
  • 经过改造,唯品会版的Kylin相比开源版本极大的扩展了对业务场景的支持程度.
 
    在提升CUBE利用率上:
 
  • 开发CUBE Advisor,通过统计分析总结合适的维度和指标组合辅助开发选择判断新建CUBE的策略,减少冗余和经验判断上的误差;
 
  • 提供CUBE命中率监控,形成CUBE新建、使用到总结升级的闭环;
 
  • 经此改造,CUBE命中率大幅提高,减少了资源的浪费提升了响应速度,经过这样的改造,开发不再只是根据自己的经验或者盲目建立,而是有数据可依。
 
    4.OLAP方案升级方向
 
    最后我们讲一下OLAP升级方向。
 
    对于Presto,我们将探索如何用RowID级别的索引的存储格式替换现有RowGroup级别索引的ORC File,在数据Scan级别尽可能精确的获取所需的数据,减少数据量,同时提高OLAP查询的并发度,应对大量用户并发OLAP分析场景。
 
    对于Kylin,我们会尝试Streaming Cubing,使得Kylin OLAP分析从离线数据向实时数据迁移,以及探索Lamda Cubing,实现实时离线CUBE无缝融合。
 
    最后,尝试探索下一代的方案,需要有更强的实时离线融合,与更强的原始数据和汇总的数据的融合,以及更强的数据处理能力,短期来讲没有更好的方案,希望跟大家一起讨论。
 
责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
兴趣阅读
OLAP  唯品会  
相关资料
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐