大数据-162 Apache Kylin 全量增量Cube的构建 Segment 超详细记录 多图

简介: 大数据-162 Apache Kylin 全量增量Cube的构建 Segment 超详细记录 多图

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(已更完)

Spark(已更完)

Flink(已更完)

ClickHouse(已更完)

Kudu(已更完)

Druid(已更完)

Kylin(正在更新…)

章节内容

上节我们完成了如下的内容:


构建Cube 按照日期、区域、产品、渠道

Cube 优化方案

3e32f864238de1a789d8b024468dd0e7_439306727b4d44098dc6719301abde76.png 增量 Cube

在大多数业务场景下,Hive中的数据处于不断增长的状态

为了支持在构建Cube,无需重复处理历史数据,引入增量构建功能

Segment

Kylin将Cube划分为多个Segment(对应就是HBase中的一个表)


一个Cube可能由1个或多个Segment组成,Segment是指定时间范围的Cube,可以理解为Cube的分区

Segment是针对源数据中的某个片段计算出来的Cube数据,代表一段时间内源数据的预计计算结果

每个Segment用起始时间和结束时间来标志

一个Segment的起始时间等于它之前Segment的结束前时间,它的结束时间等于它后面那个Segment的起始时间

同一个Cube下不同的Segment除了背后的源数据不同之外,其他如结构定义、构建过程、优化方法、存储方式等完全相同

Segment示意图

例如:以下为针对某个Cube的Segment

量构建与增量构建

全量构建

在全量构建中:


Cube中存在唯一一个Segment

每Segment没有分割时间的概念,即没有起始时间和结束时间

对于全量构建来说,每当需要更新Cube数据时,它不会区分历史数据和新加入的数据,即在构建时导入并处理所有的数据

增量构建

在增量构建中:


只会导入新Segment指定的时间区间内的原始数据,并只对这部分原始数据进行预计算

相互对比

3d753c97b3c2c4463c82910a9871d01d_8473e09d603142ff9da28625154e6373.png 全量构建与增量构建的Cube查询的方式对比:

全量构建Cube:


查询引擎只需要向存储引擎访问单个Segment所对应的数据,无需进行Segment之间的聚合

为了加强性能,单个Segment的数据也有可能被分片存储到引擎的多个分区上,查询引擎可能仍然需要对单个Segment不同分区的数据进一步聚合

增量构建Cube:


由于不同的时间的数据分布在不同的Segment中,查询引擎需要向存储引擎请求读取各个Segment的数据

增量构建的Cube上的查询会比全量构建的做更多的运行时聚合,通常来说增量构建的Cube上查询会比全量构建的Cube上的查询要慢一些

对于小数据量的Cube,或者经常需要全表更新的Cube,使用全量构建需要更少的运维精力,以少量的重复计算降低生产环境中的维护复杂度。

对于大数据量的Cube,例一个包含较长历史数据的Cube,如果每天更新,那么大量的资源是在用于重复计算,这个情况下可以考虑使用增量构建。


增量构建Cube过程

指定分割时间列

增量构建Cube的定义必须包含一个时间维度,用来分割不同的Segment,这样的维度称为分割时间列(Partition Date Column)。


增量构建过程

在进行增量构建时,将增量部分的起始时间和结束时间作为增量构建请求的一部分提交给Kylin的任务引擎

任务引擎会根据起始时间和结束时间从Hive中抽取相应时间的数据,并对这部分数据做预处理计算

将预计算的结果封装成一个新的Segment,并将相应的信息保存到元数据和存储引擎中,一般来说,增量部分的起始时间等于Cube中最后一个Segment的结束时间

增量Cube构建

步骤:定义数据源 => 定义Model => 定义Cube => 构建Cube


SQL 语句

-- 数据结构类似,只是改为了分区表
drop table wzk_kylin.dw_sales1;
create table wzk_kylin.dw_sales1(
  id string,
  channelId string,
  productId string,
  regionId string,
  amount int,
  price double
)
partitioned by (dt string)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',';

-- 加载数据
load data local inpath "dw_sales20240101_data.txt"
into table wzk_kylin.dw_sales1
partition(dt="2024-01-01");
load data local inpath "dw_sales20240102_data.txt"
into table wzk_kylin.dw_sales1
partition(dt="2024-01-02");
load data local inpath "dw_sales20240103_data.txt"
into table wzk_kylin.dw_sales1
partition(dt="2024-01-03");
load data local inpath "dw_sales20240104_data.txt"
into table wzk_kylin.dw_sales1
partition(dt="2024-01-04");

生成数据

同样,我们先编写一个脚本来生成对应的数据:

import random

# 设置参数
dates = ["2024-01-01", "2024-01-02", "2024-01-03", "2024-01-04"]
num_records_per_file = 100

# 定义可能的值
channel_ids = ['C001', 'C002', 'C003', 'C004']
product_ids = ['P001', 'P002', 'P003', 'P004']
region_ids = ['R001', 'R002', 'R003', 'R004']

# 生成数据
for dt in dates:
    output_file = f'dw_sales{dt.replace("-", "")}_data.txt'
    
    with open(output_file, 'w') as f:
        for i in range(num_records_per_file):
            record_id = f"{i+1:04d}"
            channel_id = random.choice(channel_ids)
            product_id = random.choice(product_ids)
            region_id = random.choice(region_ids)
            amount = random.randint(1, 100)
            price = round(random.uniform(10.0, 500.0), 2)
            
            line = f"{record_id},{channel_id},{product_id},{region_id},{amount},{price}\n"
            f.write(line)
    
    print(f"{num_records_per_file} records have been written to {output_file}")

print("All data files have been generated.")

执行的结果如下图所示:

上传数据

通过你习惯的方式,将这几个txt上传到服务器上,准备执行:

执行脚本

hive -f kylin_partition.sql
• 1

执行结果如下图:

加载数据源

Load Table From Tree

选择刚才创建的表,wzk_kylin.dw_sales1:

定义Model

增量构建的Cube需要指定分割时间列,例如:将日期分区字段添加到维度列中:

Data Model:New Join Condition,需要配置好几个:

配置成如下的结果:

维度配置如下图所示:

度量选择 AMOUNT 和 PRICE,最后的设置:

定义Cube

填写名字等跳过,维度需要添加 DT、其他都要:

配置完的结果如下图:

度量配置如下:(Bulk Add Measures 快速配置)

剩余的信息都默认填写即可:

构建Cube

接下来构建Cube的时候,进行Build:

选部分的日期,就不选所有数据了:

继续等待构建完毕:

查看Segment

刚才我们构建了


2024-01-01 到 2024-01-02 的数据

我们继续build 2024-01-02 到 2024-01-03

完成后继续build 2024-01-03 到 2024-01-04

分段的进行build的任务,最后我们查看 Segment如下:

2024-01-01 到 2024-01-02 完成之后,我们继续任务:

2024-01-02 到 2024-01-03 完成之后,我们继续任务:

漫长等待,任务都完成之后如下图所示:

查询测试

第一部分:按日期和地区汇总销售数据

-- 第一部分查询:按日期和地区汇总销售数据
SELECT 
    t1.dt,
    t2.regionname,
    SUM(t1.price) AS total_money,
    SUM(t1.amount) AS total_amount,
    MAX(t1.price) AS max_price,
    MIN(t1.amount) AS min_amount
FROM 
    dw_sales1 t1
JOIN 
    dim_region t2 
ON 
    t1.regionid = t2.regionid
GROUP BY 
    t1.dt, 
    t2.regionname
ORDER BY 
    t1.dt;

运行的结果如下图所示:

另一部分:按日期、地区和产品汇总销售数据

-- 第二部分查询:按日期、地区和产品汇总销售数据
SELECT 
    t1.dt,
    t2.regionid,
    t2.regionname,
    t3.productid,
    t3.productname,
    SUM(t1.price) AS total_money,
    SUM(t1.amount) AS total_amount
FROM 
    dw_sales1 t1
INNER JOIN 
    dim_region t2 
ON 
    t1.regionid = t2.regionid
INNER JOIN 
    dim_product t3 
ON 
    t1.productid = t3.productid
GROUP BY 
    t1.dt,
    t2.regionid,
    t2.regionname,
    t3.productid,
    t3.productname
ORDER BY 
    t1.dt,
    t2.regionname,
    t3.productname;

查询结果如下图所示:

相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
目录
相关文章
|
7月前
|
机器学习/深度学习 算法 大数据
构建数据中台,为什么“湖仓一体”成了大厂标配?
在大数据时代,数据湖与数据仓库各具优势,但单一架构难以应对复杂业务需求。湖仓一体通过融合数据湖的灵活性与数据仓的规范性,实现数据分层治理、统一调度,既能承载海量多源数据,又能支撑高效分析决策,成为企业构建数据中台、推动智能化转型的关键路径。
|
10月前
|
SQL 分布式计算 大数据
大数据新视界 --大数据大厂之Hive与大数据融合:构建强大数据仓库实战指南
本文深入介绍 Hive 与大数据融合构建强大数据仓库的实战指南。涵盖 Hive 简介、优势、安装配置、数据处理、性能优化及安全管理等内容,并通过互联网广告和物流行业案例分析,展示其实际应用。具有专业性、可操作性和参考价值。
大数据新视界 --大数据大厂之Hive与大数据融合:构建强大数据仓库实战指南
|
8月前
|
存储 SQL 分布式计算
MaxCompute x 聚水潭:基于近实时数仓解决方案构建统一增全量一体化数据链路
聚水潭作为中国领先的电商SaaS ERP服务商,致力于为88,400+客户提供全链路数字化解决方案。其核心ERP产品助力企业实现数据驱动的智能决策。为应对业务扩展带来的数据处理挑战,聚水潭采用MaxCompute近实时数仓Delta Table方案,有效提升数据新鲜度和计算效率,提效比例超200%,资源消耗显著降低。未来,聚水潭将进一步优化数据链路,结合MaxQA实现实时分析,赋能商家快速响应市场变化。
378 0
|
5月前
|
人工智能 数据处理 API
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新,共筑基于 Apache Flink Agents 的智能体 AI 未来
Apache Flink Agents 是由阿里云、Ververica、Confluent 与 LinkedIn 联合推出的开源子项目,旨在基于 Flink 构建可扩展、事件驱动的生产级 AI 智能体框架,实现数据与智能的实时融合。
954 6
阿里云、Ververica、Confluent 与 LinkedIn 携手推进流式创新,共筑基于 Apache Flink Agents 的智能体 AI 未来
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。
521 0
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
|
7月前
|
SQL 人工智能 数据挖掘
Apache Flink:从实时数据分析到实时AI
Apache Flink 是实时数据处理领域的核心技术,历经十年发展,已从学术项目成长为实时计算的事实标准。它在现代数据架构中发挥着关键作用,支持实时数据分析、湖仓集成及实时 AI 应用。随着 Flink 2.0 的发布,其在流式湖仓、AI 驱动决策等方面展现出强大潜力,正推动企业迈向智能化、实时化的新阶段。
875 9
Apache Flink:从实时数据分析到实时AI
|
7月前
|
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 及状态管理,显著提升作业稳定性与资源利用率。
773 0
|
6月前
|
人工智能 运维 Java
Flink Agents:基于Apache Flink的事件驱动AI智能体框架
本文基于Apache Flink PMC成员宋辛童在Community Over Code Asia 2025的演讲,深入解析Flink Agents项目的技术背景、架构设计与应用场景。该项目聚焦事件驱动型AI智能体,结合Flink的实时处理能力,推动AI在工业场景中的工程化落地,涵盖智能运维、直播分析等典型应用,展现其在AI发展第四层次——智能体AI中的重要意义。
2202 27
Flink Agents:基于Apache Flink的事件驱动AI智能体框架
|
存储 人工智能 大数据
The Past, Present and Future of Apache Flink
本文整理自阿里云开源大数据负责人王峰(莫问)在 Flink Forward Asia 2024 上海站主论坛开场的分享,今年正值 Flink 开源项目诞生的第 10 周年,借此时机,王峰回顾了 Flink 在过去 10 年的发展历程以及 Flink社区当前最新的技术成果,最后展望下一个十年 Flink 路向何方。
994 33
The Past, Present and Future of Apache Flink

热门文章

最新文章

推荐镜像

更多