原来 Kylin 的增量构建，大有学问！ | 原力计划

时间 2020-06-04 标签原来 kylin 增量构建大有学问原力计划

做者| Alice菌
php

责编 | 王晓曼安全

出品 | CSDN博客微信

Kylin增量构建应用场景运维

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

一、理解 Cube、Cuboid 与 Segment 的关系性能

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

一个 Cube，能够包含多个 Cuboid，而 Segment 是指定时间范围的 Cube，能够理解为 Cube 的分区。对应就是 HBase 中的一张表，该表中包含了全部的 Cuboid 。大数据

例如：如下为针对某个Cube的Segment。优化

二、全量构建与增量构建 ui

全量构建

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

增量构建

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

全量构建与增量构建的Cube查询方式对比：

（1）全量构建Cube

查询引擎只需向存储引擎访问单个 Segment 所对应的数据，无需进行 Segment 之间的聚合；
为了增强性能，单个 Segment 的数据也有可能被分片存储到引擎的多个分区上，查询引擎可能仍然须要对单个 Segment 不一样分区的数据作进一步的聚合。

（2）增量构建 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 文件愈来愈多，最终影响到系统的性能。

原文连接：https://blog.csdn.net/weixin_44318830/article/details/106154570

【END】

更多精彩推荐
☞我只是追个直播，结果被拉进大咖们的群面对面群聊……
☞微信公众号关闭iOS端虚拟支付业务；苹果「Apple 登陆」存安全漏洞；谷歌推迟发布Android 11 Beta| 极客头条
☞可怕！CPU 竟成了黑客的帮凶！
☞如何用NLP辅助投资分析？三大海外机构落地案例详解
☞这 10 个云计算错误，会让你的业务一蹶不振！
☞好扑科技结合区块链行业发展趋势，重磅推出“好扑区块链合伙人”计划
点击阅读原文，精彩继续。
你点的每一个“在看”，我都认真当成了喜欢