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

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

2017/7/29    来源:运维派    作者:谢麟炯      
关键字:OLAP  唯品会  
首先来看一下我们在最初几年遇到的问题。第一就是大数据,听起来好像蛮无聊的,但大数据到底是指什么呢?最主要的问题就是数据大,唯品会在这几年快速发展,用户流量数据从刚开始的几百万、几千万发展到现在的几个亿,呈现了100倍以上的增长。
    1.海量数据实时OLAP场景的困境
 
    大数据
 
    首先来看一下我们在最初几年遇到的问题。第一就是大数据,听起来好像蛮无聊的,但大数据到底是指什么呢?最主要的问题就是数据大,唯品会在这几年快速发展,用户流量数据从刚开始的几百万、几千万发展到现在的几个亿,呈现了100倍以上的增长。
 
    对我们而言,所谓的大数据就是数据量的快速膨胀,带来的问题最主要的就是传统RDBMS无法满足存储的需求,继而是计算的需求,我们的挑战便是如何克服这个问题。
 
    慢查询
 
    第二个问题是慢查询,有两个方面:一是OLAP查询的速度变慢;二是ETL数据处理效率降低。
 
    分析下这两个问题:首先,用户使用OLAP分析系统时会有这样的预期,当我点击查询按钮时希望所有的数据能够秒出,而不是我抽身去泡个茶,回来一看数据才跑了10%,这是无法接受的。由于数据量大,我们也可以选择预先计算好,当用户查询时直接从计算结果中找到对应的值返回,那么查询就是秒出的。数据量大对预计算而言也有同样的问题,就是ETL的性能也下降了,本来准备这个数据可能只需40分钟或一个小时,现在数据量翻了一百倍,需要三个小时,这时候数据分析师上班时就会抱怨数据没有准备好,得等到中午分析之类的,会听到来自同事不断的抱怨。
 
    长迭代
 
    数据量变大带来的第三个毛病,就是开发周期变长。两个角度:第一,新业务上线,用户会说我能不能在这个新的角度上线前,看看历史数据,要看一年的,这时就要刷数据了。刷数据这件事情大家知道,每次刷头都很大,花的时间很长。旧业务也一样,加新的指标,没有历史趋势也不行,也要刷数据,开发就不断地刷数据。因为数据量大,刷数据的时间非常长,数据验证也需要花很多的时间,慢慢的,开发周期变慢,业务很急躁,觉得不就是加个字段吗,怎么这么慢。这样一来,数据的迭代长,周期变慢,都让业务部门对大数据业务提出很多的质疑,我们需要改进来解决这些问题。
 
    业务部门的想法是,不管你是什么业务,不管现在用的是什么方法,他们只关心三点:第一,提的需求要很快满足;第二,数据要很快准备好;第三,数据准备好之后,当我来做分析时数据能够很快地返回。业务要的是快快快,但现在的能力是慢慢慢,为此,我们急需解决业务部门的需求和现状之间的冲突。
 
    2.唯品会大数据实时OLAP升级过程
 
    第0阶段
 

唯品会

 
    这是我们的初始状态,架构比较简单。底层的计算、存储和OLAP分析用MDB的数据仓库解决的,上层用Tableau的BI工具,开发速度比较快,同时有数据可视化效果,业务部分非常认可。GreenPlum是MPP的方案,它的高并发查询非常适合我们这种OLAP的查询,性能非常好。所以我们在这个阶段,把GreenPlum作为数据仓库和OLAP混用的实现。
 
    这样一个架构其实是一个通用的架构,像Tableau可以轻易被替换, GreenPlum也可以替换成Oracle之类的,这样一个常用的工具、一个架构,其实满足了部分的需求,但也有个问题,就是像GreenPlum这样的RDBMS数据库,在面对海量的数据写入时存储和计算的资源快速地枯竭了, GreenPlum的水平扩展有限,所以同样碰到了大数据的问题。
 
    第1阶段
 
    架构
 
    所以很快我们就进入了第一阶段。这个阶段,我们引入了Hadoop/Hive,所有的计算结果做预计算之后,会同步到GreenPlum里面,接下去一样,用GreenPlum去做分析。OLAP讲聚合讲的Ad-hoc,继续由GreenPlum承载,数据仓库讲明细数据讲Batch,就交给专为批量而生的Hive来做,这样就能把OLAP和数据仓库这两个场景用两个不一样技术栈分开。这样一个技术方案解决了数据量大的问题,ETL批量就不会说跑不动或者数据没法存储。
 
    但问题是增加了新的同步机制,需要在两个不同的DB之间同步数据。同步数据最显而易见的问题就是除了数据冗余外,如果数据不同步怎么办?比如ETL开发在Hadoop上更新,但没有同步到GreenPlum上,用户会发现数据还是错误的。第二,对用户来说,当他去做OLAP分析时,Tabluea是更适合做报表的工具,随着我们业务的扩展和数据驱动不断的深入,业务不管分析师还是商务、运营、市场,他们会越来越多地想组合不同的指标和维度去观察自己的数据,找自己运营的分析点。传统的Tabluea报表已经不能满足他们。
 
    我们需要一个新的BI解决方案
 
    对我们来说数据不同步还可以解决,毕竟是偶然发生的,处理一下就可以了。但是BI工具有很大的问题,不能满足业务已经进化的需求。所以我们需要一个新的BI解决方案:
 
    1.首先它要足够灵活,不能发布之后用户什么都不能做,只能看,我们希望它的维度和指标可以快速整合。
 
    2.第二,门槛要低,我们不可能希望业务像BI工程师学习它的开发是怎么做的,所以它要入门非常简单。其次,要能够用语言描述自己的需求,而不是用SQL,让商务这种感性思维的人学SQL简直是不可能的,所以要能用语言描述他们自己想要什么。
 
    3.第三就是开发周期短,业务想看什么,所有的数据都需要提需求,需求分析,排期实施,提变更又要排期实施,这时候虽然说业务发展不是一天一变,但很多业务试错的时间非常快,数据开发出来黄花菜都凉了。所以希望有一个新的BI方案解决这三个问题。
 
    我们看了一下市面上的商业工具并不适合,并且这样灵活的方案需要我们有更强的掌控性,于是我们就开始走向了自研的道路。
 
    第2阶段
 
架构
 
    我们进入了OLAP分析的第二个阶段,这时前端开发了一个产品叫自助分析平台,这个平台上用户可以通过拖拉拽把左边的维度指标自己组合拖到上面,组成自己想看的结果。结果查询出来后可以用表格也可以图形进行展示,包括折线、柱状、条形图,这里面所有的分析结果都是可保存、可分享、可下载的。
 
    利用这样的工具可以帮助分析师或者业务人员更好地自由的组合刚才我们所说的一切,并且灵活性、门槛低的问题其实也都迎刃而解了。而且像这样拖拉拽是非常容易学习的,只要去学习怎么把业务逻辑转化成一个数据的逻辑描述,搞懂要怎么转化成什么形式,行里面显示什么,列显示什么,度量是什么就可以了,虽然有一点的学习曲线,但比起学习完整的BI工具,门槛降低了很多。
 
    SQL Parser
 
    前端是这样的产品,后端也要跟着它一起变。首先前端是一个拖拉拽的UI组件,这个组件意味着用传统的选择SQL,直接形成报表的方式已经不可行了,因为所有的一切不管是维度指标都是用户自己组合的,所以我们需要一个SQL Parser帮助用户把它的数据的描述转化成SQL,还要进行性能的调优,保证以一个比较高的性能反馈数据。
 
    所以我们就开发了一个SQL Parser用来承接组件生成的数据结构,同时用SQL Parser直接去OLAP数据。还是通过预计算的方式,把我们需要的指标维度算好同步到SQL Parser。这样的模型一旦建立,可以多次复用。
 
    但我们知道这个计算方案有几个明显的缺点:第一,所有的数据必须经过计算,计算范围之外的不能组合;第二,还是有数据同步的问题,第三是什么?其实预计算的时候大家会经常发现我们认为这些组合是有效的,用户可能不会查,但不去查这次计算就浪费掉了。是不是有更好的办法去解决这种现状?
 
    我们需要一个新的OLAP计算引擎
 
    从这个角度来看GreenPlum已经不能满足我们了,就算预先计算好也不能满足,需要一个新的OLAP计算引擎。这个新的引擎需要满足三个条件:
 
    1.没有预计算的模型。因为预计算的缺点是没有传统意义上的数据汇总层,直接从DW层明细数据上的直接计算。而且我们所有的业务场景化,只要DW层有这个数据就不用再开发了,直接拿来用就可以了。之前我们讲到数据先汇总,有些缓慢变化是需要刷数据的,这个头很疼,也要解决。
 
    2.速度要足够快。数据平均10秒返回,看上去挺慢的,不是秒出,为什么当时定这样的目标?因为刚才讲到之前的开发方式业务要排期等,这个周期非常长,如果现在通过一个可以随意组合的方式去满足它90%以上的需求,其实它在真正做的时候对性能的要求并没有那么严苛。我们也不希望这边查询的时候因为等待数据把自己分析的思路或者日程打乱了,10秒可能是比较合适的。然后,因为我们的数据仓库DW层用维度建模,所以这个OLAP引擎必须支持Join。
 
    3.最后是支持横向扩展,计算能力可通过计算节点扩容获得提高,同时没有DB同步的问题。这里面东西还是挺多的,怎么解决这个问题呢?我们把需求分解了一下。
 
    数据模型
 
    首先查询速度要快,我们需要一个SQL内在的高并发。其次用纯内存计算代替内存+硬盘的计算,内存+硬盘的计算讲的就是Hive,Hive一个SQL启动一下,包括实际计算过程都是很慢的。第二个是数据模型,刚才讲到数据仓库才是维度建模的,必须支持Join,像外面比较流行的Druid或者ES的方案其实不适用了。第三个就是数据不需要同步,意味着需要数据存在HDFS上,计算引擎要能够感知到Hive的Metadata。第四个是通过扩容提高计算能力,如果想做到完全没有服务降级的扩容,一个计算引擎没有状态是最好的,同时计算的节点互相无依赖。最后一点是方案成熟稳定,因为这是在尝试新的OLAP方案,如果这个OLAP方案不稳定,直接影响到了用户体验,我们希望线上出问题时我们不至于手忙脚乱到没办法快速解决。
 
    Presto:Facebook贡献的开源MPP OLAP引擎
 
    MPP OLAP引擎
 
    这时候Presto进入我们的视野,它是Facebook贡献的开源MPP OLAP引擎。这是一个红酒的名字,因为开发组所有的人都喜欢喝这个牌子的红酒,所以把它命名为这个名字。作为MPP引擎,它的处理方式是把所有的数据Scan出来,通过Hash的方法把数据变成更小的块,让不同的节点并发,处理完结果后快速地返回给用户。我们看到它的逻辑架构也是这样,发起一个SQL,然后找这些数据在哪些HDFS节点上,然后分配后做具体的处理,最后再把数据返回。
 
    为什么是Presto
 
    Presto
 
    从原理上来看,高并发查询因为是MPP引擎的支持。纯内存计算,它是纯内存的,跟硬盘没有任何交互。第三,因为它是一个SQL引擎,所以支持Join。另外数据没有存储,数据直接存储在HDFS上。计算引擎没有状态,计算节点互相无依赖都是满足的。另外它也是一个成熟方案,Facebook本身也是大厂,国外有谷歌在用,国内京东也有自己的版本,所以这个东西其实还是满足我们需求的。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐