Kylin 在每次 Cube 的构建都会从 Hive 中批量读取数据，而对于大多数业务场景来说，Hive 中的数据处于不断增长的状态。为了支持 Cube 中的数据能够不断地得到更新，且无需重复地为已经处理过的历史数据构建 Cube，因此对于 Cube 引入了增量构建的功能。1、理解 Cube、Cuboid 与 Segment 的关系Kylin 将 Cube 划分为多个 Segment（对应就是 HBase 中的一个表），每个Segment 用起始时间和结束时间来标志。Segment 代表一段时间内源数据的预计算结果。一个 Segment 的起始时间等于它之前那个 Segment 的结束时间，同理，它的结束时间等于它后面那个 Segment 的起始时间。同一个 Cube 下不同的 Segment 除了背后的源数据不同之外，其他如结构定义、构建过程、优化方法、存储方式等都完全相同。一个 Cube，可以包含多个 Cuboid，而 Segment 是指定时间范围的 Cube，可以理解为 Cube 的分区。对应就是 HBase 中的一张表，该表中包含了所有的 Cuboid 。在全量构建中，Cube 中只存在唯一的一个 Segment ，该 Segment 没有分割时间的概念，也就没有起始时间和结束时间。全量构建和增量构建各有其适用的场景，用户可以根据自己的业务场景灵活地进行切换。对于全量构建来说，每当需要更新Cube数据的时候，它不会区分历史数据和新加入的数据，也就是说，在构建的时候会导入并处理所有的原始数据。
增量构建只会导入新 Segment 指定的时间区间内的原始数据，并只对这部分原始数据进行预计算。对于小数据量的 Cube，或者经常需要全表更新 Cube，使用全量构建需要更少的运维精力，以少量的重复计算降低生产环境中的维护复杂度。而对于大数据量的 Cube，例如，对于一个包含两年历史数据的 Cube，如果需要每天更新，那么每天为了新数据而去重复计算过去两年的数据就会变得非常浪费，在这种情况下需要考虑使用增量构建。 增量构建 Cube 的定义必须包含一个时间维度，用来分割不同的 Segment，这样的维度称为分割时间列（Partition Date Column）。在进行增量构建时，将增量部分的起始时间和结束时间作为增量构建请求的一部分提交给 Kylin 的任务引擎
任务引擎会根据起始时间和结束时间从 Hive 中抽取相应时间的数据，并对这部分数据做预计算处理
将预计算的结果封装成为一个新的 Segment ，并将相应的信息保存到元数据和存储引擎中。一般来说，增量部分的起始时间等于 Cube 中最后一个 Segment 的结束时间。
创建增量 Cube 的过程和创建普通 Cube 的过程基本类似，只是增量 Cube 会有一些额外的配置要求。
增量构建的 Cube 需要指定分割时间列。例如：将日期分区字段添加到维度列中
创建 Cube 结束后，在 build 时设置计算数据的日期。注意构建 Cube 时，选择的分区时间为，起始时间（包含）、结束时间（不保存），对应了从 Hive 从获取数据源的条件。
每天生成一个 Segment，一年就有365个 Segment 。当用户查询时，系统不知道数据在哪个 Segment 中，所以需要扫描所有的 Segment（扫描356个表），扫描多个表/多个 Segment 会降低数据查询效率。【增量方案带来的问题】1个文件10G和10000个文件共10G 读取一个文件更快（寻址开销、频繁发开关闭）
一个文件夹内的文件特别多，这个文件夹打开的时间就会特别长。
当系统越来越慢，越来越慢，越来越慢，越来越慢,有可能是某一个目录中的数据没有及时的清空或删除。
本篇文章为大家介绍了 Kylin 的增量构建与全量构建的差异与适用场景分析，并为演示了如何进行 Kylin 的增量构建。在文末的时候已经提到，增量构建会导致 Segment 文件越来越多，最终影响到系统的性能。版权声明：本文为CSDN博主「Alice菌」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/weixin_44318830/article/details/106154570
更多精彩推荐
☞我只是追个直播，结果被拉进大咖们的群面对面群聊……
☞微信公众号关闭iOS端虚拟支付业务；苹果「Apple 登录」存安全漏洞；谷歌推迟发布Android 11 Beta| 极客头条
☞可怕！CPU 竟成了黑客的帮凶！
☞如何用NLP辅助投资分析？三大海外机构落地案例详解
☞这 10 个云计算错误，会让你的业务一蹶不振！
☞好扑科技结合区块链行业发展趋势，重磅推出“好扑区块链合伙人”计划
点击阅读原文，精彩继续。