OLAP 玩转KYLIN 步八 官方案列实战之创建Cube之数据刷新设置

紧接步七，我们就进入了cube数据刷新设置的界面，如图：

这里的设置目前包含“Auto Merge Thresholds”、“Volatile Range”、“Retention Threshold”、“Partition Start Date”。
“Partition Start Date”是指Cube默认的第一个Segment的起始时间。同一个Model下不同的Cube可以指定不同的起始时间，因此该设置项出现在Cube Designer之中。
“Auto Merge Thresholds”用于指定Segment自动合并的阈值。
“Volatile Range”，在自动合并触发的时候，指定最近多少天的segments不参与合并。默认0，所有segments自动合并。
“Retention Threshold”则用于指定保留最近多少天的segments，默认0，即保留所有历史segments。

---

这些设置，都是服务于cube的增量构建。
增量构建的Cube每天都可能会有新的增量。日积月累，这样的Cube中最终可能包含上百个Segment，这将会导致查询性能受到严重的影响，因为运行时的查询引擎需要聚合多个Segment的结果才能返回正确的查询结果。从存储引擎的角度来说，大量的Segment会带来大量的文件，这些文件会充斥所提供的命名空间，给存储空间的多个模块带来巨大的压力，例如Zookeeper、HDFS Namenode等。因此，有必要采取措施控制Cube中Segment的数量。
Kylin提供了一种简单的机制用于控制Cube中Segment的数量：合并Segments。在Web GUI中选中需要进行Segments合并的Cube，单击Action→Merge，然后在对话框中选中需要合并的Segment，可以同时合并多个Segment，但是这些Segment必须是连续的。单击提交后系统会提交一个类型为“MERGE”的构建任务，它以选中的Segment中的数据作为输入，将这些Segment的数据合并封装成为一个新的Segment。这个新的Segment的起始时间为选中的最早的Segment的起始时间，它的结束时间为选中的最晚的Segment的结束时间。
在MERGE类型的构建完成之前，系统将不允许提交这个Cube上任何类型的其他构建任务。但是在MERGE构建结束之前，所有选中用来合并的Segment仍然处于可用的状态。当MERGE构建结束的时候，系统将选中合并的Segment替换为新的Segment，而被替换下的Segment等待将被垃圾回收和清理，以节省系统资源。
合并Segment非常简单，但是需要Cube管理员不定期地手动触发合并，尤其是当生产环境中存在大量的Cube时，对每一个Cube单独触发合并操作会变得非常繁琐，因此，Kylin也提供了其他的方式来管理Segment碎片。

---

Cube的数据刷新设置界面可以帮助我们大大减少对Segment进行管理的麻烦。
“Auto Merge Thresholds”允许用户设置几个层级的时间阈值，层级越靠后，时间阈值就越大。举例来说，用户可以为一个Cube指定（7天、28天）这样的层级。每当Cube中有新的Segment状态变为READY的时候，就会触发一次系统试图自动合并的尝试。系统首先会尝试最大一级的时间阈值，结合上面的（7天、28天）层级的例子，首先查看是否能将连续的若干个Segment合并成为一个超过28天的大Segment，在挑选连续Segment的过程中，如果遇到已经有个别Segment的时间长度本身已经超过了28天，那么系统会跳过该Segment，从它之后的所有Segment中挑选连续的累积超过28天的Segment。如果满足条件的连续Segment还不能够累积超过28天，那么系统会使用下一个层级的时间阈值重复寻找的过程。每当找到了能够满足条件的连续Segment，系统就会触发一次自动合并Segment的构建任务，在构建任务完成之后，新的Segment被设置为READY状态，自动合并的整套尝试又需要重新再来一遍。

举例来说，如果现在有A~H共8个连续的Segment，它们的时间长度分别为28天（A）、7天（B）、1天（C）、1天（D）、1天（E）、1天（F）、1天（G）、1天（H）。此时第9个Segment I 加入，它的时间长度为1天，那么现在Cube中总共存在9个Segment。系统首先尝试能否将连续的Segment合并到28天这个阈值上，由于Segment A已经超过28天，它会被排除。接下来的B到H加起来也不足28天，因此第一级的时间阈值无法满足，退一步系统尝试第二级的时间阈值，也就是7天。系统重新扫描所有的Segment，发现A和B已经超过7天，因此跳过它们，接下来发现将Segment C到I合并起来可以达到7天的阈值，因此系统会提交一个合并Segment的构建请求，将Segment C到I合并为一个新的Segment X。X的构建完成之后，Cube中只剩下三个Segment，分别是原来的A（28天），B（7天）和新的X（7天）。由于X的加入，触发了系统重新开始整个合并尝试，但是发现已经没有满足自动合并的条件，既没有连续的、满足条件的、累积超过28天的Segment，也没有连续的、满足条件的、累积超过7天的Segment，尝试终止。

再举一个例子，如果现在有A~J共10个连续的Segment，它们的时间长度分别为28天（A）、7天（B）、7天（C）、7天（D）、1天（E）、1天（F）、1天（G）、1天（H）、1天（I）、1天（J）。此时第11个Segment K加入，它的时间长度为1天，那么现在Cube中总共存在11个Segment。系统首先尝试能否将连续的Segment合并到28天这个阈值上，由于Segment A已经超过28天，它会被排除。系统接着从Segment B开始观察，发现若把Segment B至K这10个连续的Segment合并在一起正好可以达到第一级的阈值28天，因此系统提交一个合并构建任务把B至K合并为一个新的Segment X，最终Cube中存在两个长度均为28天的Segment，依次对应原来的A和新的X。由于X的加入，触发了系统重新开始整个合并尝试，但是发现已经没有满足自动合并的条件，尝试终止。

从碎片管理的角度来说，自动合并是将多个Segment合并为一个Segment，以达到清理碎片的目的。保留Segment则是从另外一个角度帮助实现碎片管理，那就是及时清理不再使用的Segment。在很多业务场景中，只会对过去一段时间内的数据进行查询，例如对于某个只显示过去1年数据的报表，支撑它的Cube事实上只需要保留过去一年内的Segment即可。由于数据在Hive中往往已经存在备份，因此无需再在Kylin中备份超过一年的历史数据。在这种情况下，我们可以将“RetentionThreshold”设置为365。每当有新的Segment状态变为READY的时候，系统会检查每一个Segment：如果它的结束时间距离最晚的一个Segment的结束时间已经大于“RetentionThreshold”，那么这个Segment将被视为无需保留。系统会自动地从Cube中删除这个Segment。
如果启用了“Auto Merge Thresholds”，那么在使用“RetentionThreshold”的时候需要注意，不能将“Auto MergeThresholds”的最大层级设置得太高。假设我们将“Auto Merge Thresholds”的最大一级设置为1000天，而将“Retention Threshold”设置为365天，那么受到自动合并的影响，新加入的Segment会不断地被自动合并到一个越来越大的Segment之中，糟糕的是，这会不断地更新这个大Segment的结束时间，从而导致这个大Segment永远不会得到释放。因此，推荐自动合并的最大一级的时间不要超过1年。

至此，数据刷新设置讲解完毕，文字较多，需要学习者，慢慢消化。下一节，又是重点，需要掌握的知识点不少，革命尚未成功，诸君仍需努力。