原来Kylin的增量构建,大有学问!

写在前面: 博主是一名软件工程系大数据应用开发专业大二的学生,昵称来源于《爱丽丝梦游仙境》中的Alice和本身的昵称。做为一名互联网小白,写博客一方面是为了记录本身的学习历程,一方面是但愿可以帮助到不少和本身同样处于起步阶段的萌新。因为水平有限,博客中不免会有一些错误,有纰漏之处恳请各位大佬不吝赐教!我的小站:http://alices.ibilibili.xyz/ , 博客主页:https://alice.blog.csdn.net/
尽管当前水平可能不及各位大佬,但我仍是但愿本身可以作得更好,由于一天的生活就是一辈子的缩影。我但愿在最美的年华,作最好的本身web

        本篇博客,博主为你们介绍的是关于Kylin的增量构建的步骤过程,以及其与全量构建的差别对比!看完以后,相信你也必定可以感觉到这里面的大学问~
在这里插入图片描述
运维


Kylin增量构建

应用场景

        Kylin在每次Cube的构建都会从Hive中批量读取数据,而对于大多数业务场景来讲,Hive中的数据处于不断增加的状态。为了支持Cube中的数据可以不断地获得更新,且无需重复地为已经处理过的历史数据构建Cube,所以对于 Cube引入了增量构建的功能。svg

理解Cube、Cuboid与Segment的关系

        Kylin将Cube划分为多个Segment(对应就是HBase中的一个表),每一个Segment用起始时间和结束时间来标志。Segment表明一段时间内源数据的预计算结果。一个Segment的起始时间等于它以前那个Segment的结束时间,同理,它的结束时间等于它后面那个Segment的起始时间。同一个Cube下不一样的Segment除了背后的源数据不一样以外,其余如结构定义、构建过程、优化方法、存储方式等都彻底相同性能

在这里插入图片描述
        一个Cube,能够包含多个Cuboid,而Segment是指定时间范围的Cube,能够理解为Cube的分区。对应就是HBase中的一张表,该表中包含了全部的Cuboid学习

        例如:如下为针对某个Cube的Segment大数据

Segment名称 分区时间 HBase表名
201910110000000-201910120000000 20191011 KYLIN_41Z8123
201910120000000-201910130000000 20191012 KYLIN_5AB2141
201910130000000-201910140000000 20191013 KYLIN_7C1151
201910140000000-201910150000000 20191014 KYLIN_811680
201910150000000-201910160000000 20191015 KYLIN_A11AD1

全量构建与增量构建

        

全量构建

        在全量构建中,Cube中只存在惟一的一个Segment,该Segment没有分割时间的概念,也就没有起始时间和结束时间。全量构建和增量构建各有其适用的场景,用户能够根据本身的业务场景灵活地进行切换。对于全量构建来讲,每当须要更新Cube数据的时候,它不会区分历史数据和新加入的数据,也就是说,在构建的时候会导入并处理全部的原始数据优化

在这里插入图片描述

        

增量构建

        增量构建只会导入新Segment指定的时间区间内的原始数据,并只对这部分原始数据进行预计算。ui

        

全量构建和增量构建的对比

全量构建 增量构建
每次更新时都须要更新整个数据集 每次只对须要更新的时间范围进行更新,所以离线计算量相对较小
查询时不须要合并不一样Segment的结果 查询时须要合并不一样Segment的结果,所以查询性能会受影响
不须要后续的Segment合并 累计必定量的Segment以后,须要进行合并
适合小数据量或全表更新的Cube 适合大数据量的Cube

全量构建与增量构建的Cube查询方式对比:.net

  • 全量构建Cube

         ■ 查询引擎只需向存储引擎访问单个Segment所对应的数据,无需进行Segment之间的聚合3d

        ■ 为了增强性能,单个Segment的数据也有可能被分片存储到引擎的多个分区上,查询引擎可能仍然须要对单个Segment不一样分区的数据作进一步的聚合

  • 增量构建Cube

        ■ 因为不一样时间的数据分布在不一样的Segment之中,查询引擎须要向存储引擎请求读取各个Segment的数据

        ■ 增量构建的Cube上的查询会比全量构建的作更多的运行时聚合,一般来讲增量构建的Cube上的查询会比全量构建的Cube上的查询要慢一些。

        对于小数据量的Cube,或者常常须要全表更新Cube,使用全量构建须要更少的运维精力,以少许的重复计算下降生产环境中的维护复杂度。而对于大数据量的Cube,例如,对于一个包含两年历史数据的Cube,若是须要天天更新,那么天天为了新数据而去重复计算过去两年的数据就会变得很是浪费,在这种状况下须要考虑使用增量构建

在这里插入图片描述

        

增量构建Cube过程

        一、指定分割时间列

        增量构建Cube的定义必须包含一个时间维度,用来分割不一样的Segment,这样的维度称为分割时间列(Partition Date Column)。

        二、增量构建过程

  • 在进行增量构建时,将增量部分的起始时间和结束时间做为增量构建请求的一部分提交给Kylin的任务引擎
  • 任务引擎会根据起始时间和结束时间从Hive中抽取相应时间的数据,并对这部分数据作预计算处理
  • 将预计算的结果封装成为一个新的Segment,并将相应的信息保存到元数据和存储引擎中。通常来讲,增量部分的起始时间等于Cube中最后一个Segment的结束时间

增量Cube的建立

        建立增量Cube的过程和建立普通Cube的过程基本相似,只是增量Cube会有一些额外的配置要求

一、配置Model

        增量构建的Cube须要指定分割时间列。例如:将日期分区字段添加到维度列中
在这里插入图片描述

二、 设置日期范围

建立cube结束后,在build时设置计算数据的日期
在这里插入图片描述
注意事项

        注意构建Cube时,选择的分区时间为,起始时间(包含)、结束时间(不保存),对应了从Hive从获取数据源的条件

三、查看Segment

第一天同步成功
在这里插入图片描述
接着咱们想再计算下一个日期的数据
在这里插入图片描述

次日同步成功
在这里插入图片描述

根据层量同步方案,得出一个结论

        天天生成一个Segment,一年就有365个Segment。当用户查询时,系统不知道数据在哪一个Segment中,因此须要扫描全部的Segment(扫描356个表),扫描多个表/多个Segment会下降数据查询效率。【增量方案带来的问题】

补充:文件越多效率越慢。
1个文件10G和10000个文件共10G 读取一个文件更快(寻址开销、频繁发开关闭)
一个文件夹内的文件特别多,这个文件夹打开的时间就会特别长。
当系统愈来愈慢,愈来愈慢,愈来愈慢,愈来愈慢,有多是某一个目录中的数据没有及时的清空或删除。


总结

        本篇博客为你们介绍了Kylin的增量构建与全量构建的差别与适用场景分析,并为演示了如何进行kylin的增量构建。在文末的时候已经提到,增量构建会致使Segment文件愈来愈多,最终影响到系统的性能。下一篇博客,咱们就来讨论,如何解决这个问题~敬请期待!!!

        若是以上过程当中出现了任何的纰漏错误,烦请大佬们指正😅

        受益的朋友或对大数据技术感兴趣的伙伴记得点赞关注支持一波🙏

在这里插入图片描述