全量构建可以看作增量构建的一种特例:在全量构建中,Cube中只存在唯一的一个Segment,该Segment没有分割时间的概念,因此也就没有起始时间和结束时间。全量构建和增量构建各有适用的场景,用户可以根据自己的业务场景灵活切换
(注意更新俩字的含义,kylin是不保存历史状态的,如果是增量更新就是更新指定的时间区间)
整体来说,增量构建的Cube上的查询会比全量构建Cube上的查询做更多的运行时聚合,而这些运行时聚合都发生在单点的查询引擎上,因此,通常来说,增量构建的Cube上的查询会比全量构建的Cube上的查询慢一些。
对于小数据量的Cube或经常需要全表更新的Cube,使用全量构建可以以少量的重复计算降低生产环境中的维护复杂度,减少运维精力。而对于大数据量的Cube,如一个包含两年历史数据的Cube,如果使用全量构建每天更新数据,那么每天为了新数据而重复计算过去两年的数据会严重增加查询成本,在这种情况下需要考虑使用增量构建。
(这里对每日新增的描述,是每日新增,但是对于拉链表来说也是每日新增,那么应该如何选择)
并非所有的Cube都适合进行增量构建,Cube的定义必须包含一个时间维度,用来分割不同的Segment,我们将这样的维度称为 分割时间列(Partition Date Column) 。尽管由于历史原因该命名中存在“date”字样,但是分割时间列可以是Hive中的Date类型、Timestamp类型还可以是String类型。无论是哪种类型,Kylin都要求用户显式地指定分割时间列的数据格式。
满足了设计增量Cube的条件之后,在进行增量构建时将增量部分的起始时间和结束时间作为增量构建请求的一部分提交给Kylin的任务引擎,任务引擎会根据起始时间和结束时间从Hive中抽取相应时间的数据,并对这部分数据做预计算处理,然后将预计算的结果封装成新的Segment,保存相应的信息到元数据和存储引擎中。一般来说,增量部分的起始时间等于Cube中最后一个Segment的结束时间。
(对于动态分区表来说,我们并不遵守这规范)
在Web GUI上触发Cube的增量构建与触发全量构建的方式基本相同。在Web GUI的Model页面中,选中想要增量构建的Cube,点击“Action”→“Build”命令
>
以上就是关于定时任务调度——oozie总结全部的内容,包括:定时任务调度——oozie总结、为什么使用HiveHive提供了什么Hive支持哪些用户、Kylin#Apache Kylin Cube增量构建(四)等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)