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

本文转载自公众号 DBAplus社群 ， 做者：谢麟炯

谢麟炯，惟品会大数据平台高级技术架构经理，主要负责大数据自助多维分析平台，离线数据开发平台及分析引擎团队的开发和管理工做，加入惟品会以来还曾负责流量基础数据的采集和数据仓库建设以及移动流量分析等数据产品的工做。

---

海量数据实时OLAP场景的困境

大数据

首先来看一下咱们在最初几年遇到的问题。第一就是大数据，听起来好像蛮无聊的，但大数据究竟是指什么呢？最主要的问题就是数据大，惟品会在这几年快速发展，用户流量数据从刚开始的几百万、几千万发展到如今的几个亿，呈现了100倍以上的增加。

对咱们而言，所谓的大数据就是数据量的快速膨胀，带来的问题最主要的就是传统RDBMS没法知足存储的需求，继而是计算的需求，咱们的挑战即是如何克服这个问题。

慢查询

第二个问题是慢查询，有两个方面：一是OLAP查询的速度变慢；二是ETL数据处理效率下降。

分析下这两个问题：首先，用户使用OLAP分析系统时会有这样的预期，当我点击查询按钮时但愿全部的数据可以秒出，而不是我抽身去泡个茶，回来一看数据才跑了10%，这是没法接受的。因为数据量大，咱们也能够选择预先计算好，当用户查询时直接从计算结果中找到对应的值返回，那么查询就是秒出的。数据量大对预计算而言也有一样的问题，就是ETL的性能也降低了，原本准备这个数据可能只需40分钟或一个小时，如今数据量翻了一百倍，须要三个小时，这时候数据分析师上班时就会抱怨数据没有准备好，得等到中午分析之类的，会听到来自同事不断的抱怨。

长迭代

数据量变大带来的第三个毛病，就是开发周期变长。两个角度：第一，新业务上线，用户会说我能不能在这个新的角度上线前，看看历史数据，要看一年的，这时就要刷数据了。刷数据这件事情你们知道，每次刷头都很大，花的时间很长。旧业务也同样，加新的指标，没有历史趋势也不行，也要刷数据，开发就不断地刷数据。由于数据量大，刷数据的时间很是长，数据验证也须要花不少的时间，慢慢的，开发周期变慢，业务很急躁，以为不就是加个字段吗，怎么这么慢。这样一来，数据的迭代长，周期变慢，都让业务部门对大数据业务提出不少的质疑，咱们须要改进来解决这些问题。

业务部门的想法是，无论你是什么业务，无论如今用的是什么方法，他们只关心三点：第一，提的需求要很快知足；第二，数据要很快准备好；第三，数据准备好以后，当我来作分析时数据可以很快地返回。业务要的是快快快，但如今的能力是慢慢慢，为此，咱们急需解决业务部门的需求和现状之间的冲突。

 

惟品会大数据实时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工具，门槛下降了不少。

前端是这样的产品，后端也要跟着它一块儿变。首先前端是一个拖拉拽的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引擎

这时候Presto进入咱们的视野，它是Facebook贡献的开源MPP OLAP引擎。这是一个红酒的名字，由于开发组全部的人都喜欢喝这个牌子的红酒，因此把它命名为这个名字。做为MPP引擎，它的处理方式是把全部的数据Scan出来，经过Hash的方法把数据变成更小的块，让不一样的节点并发，处理完结果后快速地返回给用户。咱们看到它的逻辑架构也是这样，发起一个SQL，而后找这些数据在哪些HDFS节点上，而后分配后作具体的处理，最后再把数据返回。

为何是Presto

从原理上来看，高并发查询由于是MPP引擎的支持。纯内存计算，它是纯内存的，跟硬盘没有任何交互。第三，由于它是一个SQL引擎，因此支持Join。另外数据没有存储，数据直接存储在HDFS上。计算引擎没有状态，计算节点互相无依赖都是知足的。另外它也是一个成熟方案，Facebook自己也是大厂，国外有谷歌在用，国内京东也有本身的版本，因此这个东西其实仍是知足咱们需求的。

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。

首先咱们想要的是SQL跟结果一对一匹配，它是很是符合这个需求的。其次咱们但愿缓存更快的返回，Redis是纯内存的存储，返回速度很是快，通常是毫秒级。第三个生命周期管理，它提供API，咱们作二次开发，跟咱们ETL调度系统打通，处理更新时就能够通知什么样的数据能够被用到。而缓存复用是不支持的，咱们能够本身来作。

第3.5阶段

因而这时就把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引擎

Kylin是由eBay开源的一个引擎，Kylin把数据读出来作计算，结算的结果会被存在HBase里，经过HBase作Ad-hoc的功能。HBase的好处是有索引的，因此作Ad-hoc的性能很是好。

为何是Kylin

首先空间换时间，咱们在刚开始引入Kylin时跟Kylin开发聊过，他们借鉴了Oracle CUBE的概念，对传统数据库开发的人来讲很容易理解概念和使用。支持维度建模天然支持也Join。预计算的过程是由Kylin本身管理的，也开放了API，与调度系统打通作数据刷新。另外Kylin是在eBay上很大的、美团也是投入了很大的精力的有成功经验的产品，因此很容易地引进来了。

第4阶段

因而，咱们进入了惟品会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之类的概念慢慢从新回到了大数据的视野里面。对咱们而言，咱们认为更多的时候，咱们在作一些大数据的新技术演进时更多的是用更优秀的技术来作落地和实现，而不是去拒绝过去的一些你们感受好像比较陈旧的的逻辑或概念。因此说对每一个人来讲，适合本身业务的场景方案才是最好的方案。

 

惟品会在开源计算引擎上所作的改进

接下来说一下咱们在开源计算引擎上作的改进。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命中率大幅提升，减小了资源的浪费提高了响应速度，通过这样的改造，开发再也不只是根据本身的经验或者盲目创建，而是有数据可依。
 
OLAP方案升级方向
 
最后咱们讲一下OLAP升级方向。
对于Presto，咱们将探索如何用RowID级别的索引的存储格式替换现有RowGroup级别索引的ORC File，在数据Scan级别尽量精确的获取所需的数据，减小数据量，同时提升OLAP查询的并发度，应对大量用户并发OLAP分析场景。
对于Kylin，咱们会尝试Streaming Cubing，使得Kylin OLAP分析从离线数据向实时数据迁移，以及探索Lamda Cubing，实现实时离线CUBE无缝融合。
最后，尝试探索下一代的方案，须要有更强的实时离线融合，与更强的原始数据和汇总的数据的融合，以及更强的数据处理能力，短时间来说没有更好的方案，但愿跟你们一块儿讨论。

 

 

若是以为本博客对您有帮助，请 赞助做者 。

转载自：lxw的大数据田地 » 惟品会海量实时OLAP分析技术升级之路