Apache Kylin权威指南2.4 构建Cube

简介:

2.4 构建Cube


本节将快速介绍构建Cube相关的操作说明和设置,因受到篇幅的限制,许多具体内容无法深入展开,读者可以从后续的第3章和第4章中获得更详细的介绍。

新创建的Cube只有定义,而没有计算的数据,它的状态是“DISABLED”,是不会被查询引擎挑中的。要想让Cube有数据,还需要对它进行构建。Cube的构建方式通常有两种:全量构建和增量构建;两者的构建步骤是完全一样的,区别只在于构建时读取的数据源是全集还是子集。

Cube的构建包含如下步骤,由任务引擎来调度执行。

1)创建临时的Hive平表(从Hive读取数据)。

2)计算各维度的不同值,并收集各Cuboid的统计数据。

3)创建并保存字典。

4)保存Cuboid统计信息。

5)创建HTable。

6)计算Cube(一轮或若干轮MapReduce)。

7)将Cube的计算结果转成HFile。

8)加载HFile到HBase。

9)更新Cube元数据。

10)垃圾回收。

以上步骤中,前5步是为计算Cube而做的准备工作,例如遍历维度值来创建字典,对数据做统计和估算以创建HTable等;第6)步是真正的Cube计算,取决于所使用的Cube算法,它可能是一轮MapReduce任务,也可能是N(在没有优化的情况下,N可以被视作是维度数)轮迭代的MapReduce。由于Cube运算的中间结果是以SequenceFile的格式存储在HDFS上的,所以为了导入到HBase中,还需要第7)步将这些结果转换成HFile(HBase文件存储格式)。第8)步通过使用HBase BulkLoad工具,将HFile导入进HBase集群,这一步完成之后,HTable就可以查询到数据了。第9)步更新Cube的数据,将此次构建的Segment的状态从“NEW”更新为“READY”,表示已经可供查询了。最后一步,清理构建过程中生成的临时文件等垃圾,释放集群资源。

Monitor页面会显示当前项目下近期的构建任务。图2-19显示了一个正在运行的Cube构建的任务,当前进度为46%多。

 

图2-19 任务列表

单击任务右边的“”按钮,展开可以得到任务每一步的详细信息,如图2-20所示。

如果任务中的某一步是执行Hadoop任务的话,那么会显示Hadoop任务的链接,单击即可跳转到对应的Hadoop任务监测页面,如图2-21所示。

如果任务执行中的某一步出现报错,那么任务引擎会将任务状态置为“ERROR”并停止后续的执行,等待用户排错。在错误排除之后,用户可以单击“Resume”从上次失败的地方恢复执行。或者如果需要修改Cube或重新开始构建,那么用户需要单击“Discard”来丢弃此次构建。

接下来将介绍几种不同的构建方式。

 

图2-21 MapReduce任务监测页面

2.4.1 全量构建和增量构建

1.?全量构建

对数据模型中没有指定分割时间列信息的Cube,Kylin会采用全量构建,即每次从Hive中读取全部的数据来开始构建。通常它适用于以下两种情形。

事实表的数据不是按时间增长的。

事实表的数据比较小或更新频率很低,全量构建不会造成太大的开销。

2.?增量构建

增量构建的时候,Kylin每次都会从Hive中读取一个时间范围内的数据,然后进行计算,并以一个Segment的形式进行保存。下次再构建的时候,会自动以上次结束的时间为起点时间,再选择新的终止时间进行构建。经过多次构建,Cube中将会有多个Segment依次按时间顺序进行排列,如Seg-1, Seg-2,…,Seg-N。查询的时候,Kylin会查询一个或多个Segment然后再做聚合计算,以便返回正确的结果给请求者。

使用增量构建的好处是,每次只需要对新增数据进行计算,从而避免了对历史数据进行重复计算。对于数据量很大的Cube,使用增量构建是非常有必要的。

图2-22是构建一个Segment的Cube时的输入框,需要用户选择时间范围。

 

图2-22 提交增量构建

在从Hive读取源数据的时候,Kylin会带上此时间条件,如图2-23所示。

 

图2-23 增量构建的SQL

增量构建抽取数据的范围,采用了前包后闭的原则,即包含了开始时间,但不包含结束时间,从而保证上一个Segment的结束时间与下一个Segment的起始时间相同,但数据不会重复。

下一次构建的时候,起始时间必须是上一次的结束时间。如果使用Kylin的Web GUI触发,那么起始时间会被自动填写,用户只需要选择结束时间。如果使用Rest API触发,用户则需要确保时间范围不会与已有的Segment有重合。

2.4.2 历史数据刷新

Cube构建完成以后,如果某些历史数据发生了改动,那么需要针对相应的Segment进行重新计算,这种构建称为刷新。刷新通常只针对增量构建的Cube而言,因为全量构建的Cube只要重新全部构建就可以得到更新;而增量更新的Cube因为有多个Segment,因此需要先选择要刷新的Segment,然后再进行刷新。

图2-24是提交刷新的请求页面,用户需要在下拉列表中选择一个时间区间。

 

图2-24 刷新已有的Segment

提交以后,生成的构建任务与最初的构建任务完全一样。

在刷新的同时,Cube仍然可以被查询,只不过返回的是陈旧数据。当Segment刷新完毕时,新的Segment会立即生效,查询开始返回最新的数据。老Segment则成为垃圾,等待回收。

2.4.3 合并

随着时间的迁移,Cube中可能会存在较多数量的Segment,使得查询性能下降,并且会给HBase集群管理带来压力。对此,需要适时地将一些Segment进行合并,将若干个小Segment合并成较大的Segment。

合并的好处具体如下。

合并相同的Key,从而减少Cube的存储空间。

由于Segment减少了,因此可以减少查询时的二次聚合,提高了查询性能。

HTable的数量得以减少,更便于集群的管理。

下面来看看合并的操作步骤,图2-25中的Cube有两个Segment。

现在触发一个合并,单击Actions →Merge;选择要合并的起始Segment和结束Segment,生成一个合并的任务,如图2-26所示。

 

图2-26 提交合并任务

合并的时候,Kylin将直接以当初各个Segment构建时生成的Cuboid文件作为输入内容,而不需要从Hive加载原始数据。后续的步骤跟构建时基本一致。直到新的HTable加载完成后,Kylin才会卸载旧的HTable,从而确保在整个合并过程中,Cube都是可以查询的。

合并完成之后,此Cube的Segment减少为1个,如图2-27所示。

相关文章
|
消息中间件 数据挖掘 Kafka
Apache Kafka流处理实战:构建实时数据分析应用
【10月更文挑战第24天】在当今这个数据爆炸的时代,能够快速准确地处理实时数据变得尤为重要。无论是金融交易监控、网络行为分析还是物联网设备的数据收集,实时数据处理技术都是不可或缺的一部分。Apache Kafka作为一款高性能的消息队列系统,不仅支持传统的消息传递模式,还提供了强大的流处理能力,能够帮助开发者构建高效、可扩展的实时数据分析应用。
1107 5
|
消息中间件 存储 监控
构建高可用性Apache Kafka集群:从理论到实践
【10月更文挑战第24天】随着大数据时代的到来,数据传输与处理的需求日益增长。Apache Kafka作为一个高性能的消息队列服务,因其出色的吞吐量、可扩展性和容错能力而受到广泛欢迎。然而,在构建大规模生产环境下的Kafka集群时,保证其高可用性是至关重要的。本文将从个人实践经验出发,详细介绍如何构建一个高可用性的Kafka集群,包括集群规划、节点配置以及故障恢复机制等方面。
562 4
|
存储 人工智能 数据处理
Apache Doris 2025 Roadmap:构建 GenAI 时代实时高效统一的数据底座
秉承“以场景驱动创新” 的核心理念,持续深耕三大核心场景的关键能力,并对大模型 GenAI 场景的融合应用进行重点投入,为智能时代构建实时、高效、统一的数据底座。
681 10
Apache Doris 2025 Roadmap:构建 GenAI 时代实时高效统一的数据底座
|
存储 数据挖掘 数据处理
巴别时代使用 Apache Paimon 构建 Streaming Lakehouse 的实践
随着数据湖技术的发展,企业纷纷探索其优化潜力。本文分享了巴别时代使用 Apache Paimon 构建 Streaming Lakehouse 的实践。Paimon 支持流式和批处理,提供高性能、统一的数据访问和流批一体的优势。通过示例代码和实践经验,展示了如何高效处理实时数据,解决了数据一致性和故障恢复等挑战。
438 61
|
消息中间件 Java Kafka
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
822 1
|
8月前
|
人工智能 数据处理 API
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新,共筑基于 Apache Flink Agents 的智能体 AI 未来
Apache Flink Agents 是由阿里云、Ververica、Confluent 与 LinkedIn 联合推出的开源子项目,旨在基于 Flink 构建可扩展、事件驱动的生产级 AI 智能体框架,实现数据与智能的实时融合。
1376 6
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新,共筑基于 Apache Flink Agents 的智能体 AI 未来
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。
623 0
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
|
10月前
|
SQL 人工智能 数据挖掘
Apache Flink:从实时数据分析到实时AI
Apache Flink 是实时数据处理领域的核心技术,历经十年发展,已从学术项目成长为实时计算的事实标准。它在现代数据架构中发挥着关键作用,支持实时数据分析、湖仓集成及实时 AI 应用。随着 Flink 2.0 的发布,其在流式湖仓、AI 驱动决策等方面展现出强大潜力,正推动企业迈向智能化、实时化的新阶段。
1116 9
Apache Flink:从实时数据分析到实时AI
|
10月前
|
SQL 人工智能 API
Apache Flink 2.1.0: 面向实时 Data + AI 全面升级,开启智能流处理新纪元
Apache Flink 2.1.0 正式发布,标志着实时数据处理引擎向统一 Data + AI 平台迈进。新版本强化了实时 AI 能力,支持通过 Flink SQL 和 Table API 创建及调用 AI 模型,新增 Model DDL、ML_PREDICT 表值函数等功能,实现端到端的实时 AI 工作流。同时增强了 Flink SQL 的流处理能力,引入 Process Table Functions(PTFs)、Variant 数据类型,优化流式 Join 及状态管理,显著提升作业稳定性与资源利用率。
896 0
|
9月前
|
人工智能 运维 Java
Flink Agents:基于Apache Flink的事件驱动AI智能体框架
本文基于Apache Flink PMC成员宋辛童在Community Over Code Asia 2025的演讲,深入解析Flink Agents项目的技术背景、架构设计与应用场景。该项目聚焦事件驱动型AI智能体,结合Flink的实时处理能力,推动AI在工业场景中的工程化落地,涵盖智能运维、直播分析等典型应用,展现其在AI发展第四层次——智能体AI中的重要意义。
3023 27
Flink Agents:基于Apache Flink的事件驱动AI智能体框架

热门文章

最新文章

推荐镜像

更多