应用场景
Kylin在每次Cube的构建都会从Hive中批量读取数据，而对于大多数业务场景来说，Hive中的数据处于不断增长的状态。为了支持Cube中的数据能够不断地得到更新，且无需重复地为已经处理过的历史数据构建Cube，因此对于 Cube引入了增量构建的功能
理解Cube、Cuboid与Segment的关系
Kylin将Cube划分为多个Segment（对应就是HBase中的一个表），每个Segment用起始时间和结束时间来标志。Segment代表一段时间内源数据的预计算结果。一个Segment的起始时间等于它之前那个Segment的结束时间，同理，它的结束时间等于它后面那个Segment的起始时间。同一个Cube下不同的Segment除了背后的源数据不同之外，其他如结构定义、构建过程、优化方法、存储方式等都完全相同。
一个Cube，可以包含多个Cuboid，而Segment是指定时间范围的Cube，可以理解为Cube的分区。对应就是HBase中的一张表。该表中包含了所有的Cuboid。
- 例如：以下为针对某个Cube的Segment
全量构建与增量构建
全量构建
在全量构建中，Cube中只存在唯一的一个Segment，该Segment没有分割时间的概念，也就没有起始时间和结束时间。全量构建和增量构建各有其适用的场景，用户可以根据自己的业务场景灵活地进行切换。对于全量构建来说，每当需要更新Cube数据的时候，它不会区分历史数据和新加入的数据，也就是说，在构建的时候会导入并处理所有的原始数据。
增量构建
增量构建只会导入新Segment指定的时间区间内的原始数据，并只对这部分原始数据进行预计算。
全量构建和增量构建的对比
全量构建与增量构建的Cube查询方式对比：
全量构建Cube
- 查询引擎只需向存储引擎访问单个Segment所对应的数据，无需进行Segment之间的聚合
- 为了加强性能，单个Segment的数据也有可能被分片存储到引擎的多个分区上，查询引擎可能仍然需要对单个Segment不同分区的数据做进一步的聚合
增量构建Cube
- 由于不同时间的数据分布在不同的Segment之中，查询引擎需要向存储引擎请求读取各个Segment的数据
- 增量构建的Cube上的查询会比全量构建的做更多的运行时聚合，通常来说增量构建的Cube上的查询会比全量构建的Cube上的查询要慢一些。
对于小数据量的Cube，或者经常需要全表更新的Cube，使用全量构建需要更少的运维精力，以少量的重复计算降低生产环境中的维护复杂度。而对于大数据量的Cube，例如，对于一个包含两年历史数据的Cube，如果需要每天更新，那么每天为了新数据而去重复计算过去两年的数据就会变得非常浪费，在这种情况下需要考虑使用增量构建
增量构建Cube过程
1、指定分割时间列
增量构建Cube的定义必须包含一个时间维度，用来分割不同的Segment，这样的维度称为分割时间列（Partition Date Column）。
2、增量构建过程
- 在进行增量构建时，将增量部分的起始时间和结束时间作为增量构建请求的一部分提交给Kylin的任务引擎
- 任务引擎会根据起始时间和结束时间从Hive中抽取相应时间的数据，并对这部分数据做预计算处理
- 将预计算的结果封装成为一个新的Segment，并将相应的信息保存到元数据和存储引擎中。一般来说，增量部分的起始时间等于Cube中最后一个Segment的结束时间。
增量Cube的创建
创建增量Cube的过程和创建普通Cube的过程基本类似，只是增量Cube会有一些额外的配置要求
- 1、配置Model
增量构建的Cube需要指定分割时间列。例如：将日期分区字段添加到维度列中
在设置中，配置分区列，并指定日期格式
2、 设置日期范围
创建cube结束后，在build时设置计算数据的日期
注意事项 - 注意构建Cube时，选择的分区时间为，起始时间（包含）、结束时间（不保存），对应了从Hive从获取数据源的条件
3、参看Segment
第一天同步成功
新计算下一个日期的数据
第二天同步成功
根据层量同步方案，得出一个结论。
结论：每天成成一个Segment，一年就有365个Segment。
当用户查询时，系统不知道数据在哪个Segment中，所以需要扫描所有的Segment（扫描356个表），扫描多个表/多个Segment会降低数据查询效率。【增量方案带来的问题】
补充：文件越多效率越慢。
1个文件10G和10000个文件共10G 读取一个文件更快（寻址开销、频繁发开关闭）
一个文件夹内的文件特别多，这个文件夹打开的时间就会特别长。【xxxxxx卫星应用中心】
当系统越来越慢，越来越慢，越来越慢，越来越慢,有可能是某一个目录中的数据没有及时的清空或删除。