TL;DR
- 场景:基于 Kylin 4.0,从零搭建日期/区域/产品/渠道 Cube,支持离线构建,实时能力可选。
- 结论:命中合适 Cuboid 可将复杂聚合降到秒级;通过 Aggregation Group/层级维度显著压缩存储与构建成本。
- 产出:端到端步骤、SQL 示例、优化策略与一份工程化错误速查卡,便于落地与后续迭代。

版本矩阵
| 项 | 版本/年份 | 已验证 | 说明 |
|---|---|---|---|
| Apache Kylin | 4.0(2025) | 是 | 文中完整演示离线 Cube 的建模、构建与查询命中。 |
| 数据源(离线) | Hive(3.x/同类) | 是 | 事实/维度来源;与示例 SQL 一致。 |
| 构建引擎 | Spark(3.x/同类) | 是 | 用于离线构建 Cuboid。 |
| 存储引擎 | HBase(2.x/同类) | 是 | 存放预聚合 Cuboid 与字典。 |

Cube 介绍
Apache Kylin 是一个开源的分布式分析引擎,专注于提供大数据的实时OLAP(在线分析处理)能力。Cube(立方体)是 Apache Kylin 的核心概念之一,通过预计算大规模数据的多维数据集合,加速复杂的 SQL 查询。下面详细介绍 Cube 的关键点:
Cube 的基本概念
Kylin 中的 Cube 是通过对一组事实表(通常是业务数据表)进行多维建模后,生成的预计算数据结构。Cube 涉及对多维数据的度量和维度的组合,从而可以在查询时通过检索预先计算的结果来显著减少计算开销。
- 维度(Dimension):数据中用于分组、筛选和切片的数据字段,例如时间、地区、产品等。
- 度量(Measure):通常是需要进行聚合计算的数据字段,例如销售额、订单数等。
- Cuboid:每个 Cube 由多个 Cuboid 构成,Cuboid 是一个特定维度组合的子集。Cube 中每种维度组合都会生成一个 Cuboid,每个 Cuboid 存储了该组合下的预聚合结果。
Cube 的创建过程
- 数据建模:首先在 Kylin 中创建一个数据模型(Data Model),这个模型定义了事实表和维度表之间的关系,类似于星型或雪花型模式。模型中也定义了需要聚合的度量字段。
- Cube 设计:基于数据模型设计 Cube,指定 Cube 的维度和度量。Kylin 会根据定义自动计算所有可能的维度组合(Cuboid)。
- 构建 Cube:构建过程会读取底层数据源(如 Hive、HBase、Kafka),然后根据指定的维度和度量生成每个 Cuboid 的预计算数据。这些预计算结果存储在 HBase 或其他存储引擎中。
Cube 的查询与优化
查询加速机制
当有 SQL 查询请求到达 Kylin 时,系统会通过以下步骤实现查询加速:
- 查询解析:首先解析 SQL 语句,识别查询涉及的事实表、维度列和度量指标
- Cuboid 匹配:根据查询条件中的维度组合,在预计算的 Cuboid 集合中寻找完全匹配或最接近的 Cuboid
- 结果返回:直接从匹配的 Cuboid 中获取预计算结果,避免了以下实时计算过程:
- 原始数据扫描
- 多表连接操作
- 聚合计算
典型应用场景示例:
- 电商平台需要实时查询"华东地区手机品类在2023年Q3的销售额"
- 广告系统要分析"不同年龄段用户在各时间段的点击率"
- 物流系统查询"各区域配送中心的准时送达率"
Cube 优化策略
为了平衡查询性能与存储成本,Kylin 提供多种 Cube 优化方法:
-
Aggregation Group(聚合组):
- 将相关维度划分为逻辑组,仅计算组内维度的组合
- 配置示例:将"时间(年/月/日)"、"地域(国家/省/市)"、"产品(品类/品牌)"分为三个独立组
- 可减少 Cuboid 数量从 2^n 降到 ∑2^m (m为各组维度数)
-
层级维度优化:
- 对具有层级关系的维度(如年-月-日)设置特殊处理
- 只计算完整层级路径,跳过非常用组合(如年-日)
-
必要维度设置:
- 标记必须出现在所有 Cuboid 中的核心维度
- 确保关键查询都能获得加速
-
联合维度:
- 将总是同时查询的维度绑定为一个维度组
- 例如"用户ID+设备ID"作为联合维度
优化效果对比:
- 未优化:10个维度会产生1024个Cuboid
- 优化后:分组配置可能仅需生成100-200个Cuboid
- 存储空间可减少60-80%,构建时间缩短50%以上
实际应用建议:
- 先分析高频查询模式
- 根据查询特征设计Aggregation Group
- 持续监控并调整Cube设计
- 对重要业务保留完整Cube,次要业务使用优化Cube
实时 OLAP
Kylin 4.0 引入了对实时 OLAP 的支持,使用 Kafka 作为实时数据流输入,构建实时 Cube。通过使用 Lambda 架构,Kylin 可以支持实时和批处理数据的整合分析。
Cube 的典型应用场景
- 大规模数据分析:Cube 适用于分析超大规模的数据集,通过预计算方式加速查询。
- 实时分析:实时 Cube 允许用户在近乎实时的基础上分析流数据。
- 商业智能(BI)工具的集成:Kylin 提供与 Tableau、Power BI 等常见 BI 工具的集成,用户可以使用熟悉的 SQL 查询语言进行复杂的多维分析。
创建Cube(按日期、区域、产品、渠道)
Cube设计
维度:日期、渠道、区域、产品 指标:销售总金额、订单总比数
结构图如下:
对应的SQL如下所示:
sql
select
t1.date1,
t2.regionid,
t2.regionname,
t3.productid,
t3.productname,
sum(t1.price) as total_money,
sum(t1.amount) as total_amount
from
dw_sales t1
inner join dim_region t2
on t1.regionid = t2.regionid
inner join dim_product t3
on t1.productid = t3.productid
group by
t1.date1,
t2.regionid,
t2.regionname,
t3.productid,
t3.productname
order by
t1.date1,
t2.regionname,
t3.productname
核心步骤
定义数据源 => 定义Model => 定义Cube => 构建Cube
操作步骤
创建Model
创建的时候,Lookup Table,配置成如下的内容:
配置维度为如下的结果: 
配置度量为如下的结果: 
创建Cube
选择维度,如下图所示:
配置完的结果如下图:
指定指标,如下图所示:
我们继续Build操作,对Cube进行Build:
漫长等待,构建完毕的结果: 
执行SQL
sql
select
t1.date1,
t2.regionid,
t2.regionname,
t3.productid,
t3.productname,
sum(t1.price) as total_money,
sum(t1.amount) as total_amount
from
dw_sales t1
inner join dim_region t2
on t1.regionid = t2.regionid
inner join dim_product t3
on t1.productid = t3.productid
group by
t1.date1,
t2.regionid,
t2.regionname,
t3.productid,
t3.productname
order by
t1.date1,
t2.regionname,
t3.productname
执行的结果: 
Cube 查询流程
当查询请求到达 Kylin 时,Kylin 通过以下步骤来确定如何利用 Cube 加速查询:
查询解析
当用户通过 SQL 提交查询时,Kylin 会先将 SQL 查询进行解析。解析的内容包括:
选择的维度(如 GROUP BY 和 WHERE 中使用的字段) 聚合操作(如 SUM、COUNT 等) 过滤条件(WHERE 和 HAVING 子句) Kylin 会将解析后的 SQL 查询映射到事先创建好的 Cube 上,并尝试根据查询所涉及的维度和度量,找到最匹配的 Cuboid。
Cuboid 匹配
Kylin 的核心是 Cube,它由多个 Cuboid 组成,每个 Cuboid 存储了一个特定维度组合的聚合结果。Cuboid 是基于事实表中的维度进行组合的子集,每个子集存储了预计算的度量值。
Kylin 通过如下步骤进行 Cuboid 匹配:
确定 SQL 查询需要的维度和度量。 查找与查询条件最匹配的 Cuboid。Kylin 会优先选择最小的 Cuboid,即只包含所需维度的子集,这样可以减少数据读取量,提高查询性能。 如果找到匹配的 Cuboid,Kylin 会直接从中提取预计算的数据。
查询执行
一旦找到匹配的 Cuboid,Kylin 会从 HBase 或者其他存储引擎中读取 Cuboid 中的数据,然后对数据进行最后的过滤、排序或聚合(如果查询中有其他未预先计算的内容)。因为大部分计算已经在 Cube 构建阶段完成,所以这一步的执行速度非常快,通常可以在秒级内完成大规模数据的查询。
Cube 优化策略
虽然 Cube 提供了强大的查询加速功能,但 Cube 的构建、存储和管理也存在一定的挑战。因此,Kylin 提供了一些优化策略,帮助用户最大化利用 Cube 的性能,最小化资源消耗。
维度裁剪(Aggregation Group)
Cube 的大小和复杂度与维度的数量密切相关,因为 Cube 中每个维度的组合都会生成一个 Cuboid,维度越多,Cuboid 数量呈指数级增长。为了避免不必要的 Cuboid 生成,Kylin 支持 Aggregation Group,它允许用户定义 Cube 中仅需要保留的维度组合,从而减少不常用维度组合的计算和存储。
举例: 如果某个 Cube 中有 时间、地区 和 产品 三个维度,用户可以根据业务需求定义只计算 时间-产品 和 地区-产品 的组合,而忽略不常用的 时间-地区 组合。
Cuboid 裁剪(Cuboid Pruning)
Cuboid 裁剪是进一步优化的手段,用于在 Cube 构建时减少不必要的 Cuboid。Kylin 会根据查询历史和配置规则,自动裁剪不经常使用的 Cuboid,减少 Cube 的构建时间和存储空间。这一过程称为 Cuboid Pruning。
Cuboid 裁剪的规则: 通过历史查询分析:Kylin 可以根据历史查询分析哪些维度组合更常被查询,从而决定哪些 Cuboid 需要保留。 通过手动配置:用户也可以根据业务场景,手动配置哪些维度组合重要,哪些可以被裁剪。
增量构建
在大规模数据环境中,全量构建 Cube 的代价非常高。为了应对这一问题,Kylin 提供了 增量构建 功能。增量构建允许用户只对新增或更新的数据进行 Cube 构建,而无需重建整个 Cube。
增量构建的好处: 提高构建效率:只处理增量数据,避免对整个数据集的重复计算。 实时更新:支持更快的响应时间,能够在较短的时间内更新最新数据的 Cube。
Cube 的层次构建(Layered Cuboid)
为了减少 Cuboid 的存储空间,Kylin 采用了 层次构建(Layered Cuboid) 策略。这个策略通过优先计算最小的 Cuboid(即包含较少维度的组合),再基于这些 Cuboid 逐层构建更大的 Cuboid。这样不仅可以减少存储占用,还能提高构建速度。
数据分区
Kylin 支持将 Cube 按照时间维度进行分区(如按天、按月等),从而使得查询和数据管理更加高效。分区可以帮助 Kylin 减少每次查询时的数据量,提高查询性能。
静态和动态优化
Kylin 提供了 静态优化 和 动态优化 两种方式:
静态优化:在 Cube 构建时进行优化,例如通过裁剪 Cuboid、定义 Aggregation Group 等手段减少 Cube 的体积。 动态优化:在查询时动态选择最合适的 Cuboid,尽可能避免过大的数据读取,提升查询效率。
Cube 的监控与调优
为了进一步优化 Cube,Kylin 提供了多种工具和功能用于监控和调优:
- 查询日志分析:通过分析查询日志,用户可以识别出哪些查询执行时间过长或未命中 Cube,从而针对性地调整 Cube 设计。
- 构建日志监控:监控 Cube 构建过程中的性能瓶颈,及时发现并优化构建效率。
错误速查
| 症状 | 根因定位 | 修复 |
|---|---|---|
| 查询走底表、耗时长 | SQL 维度/度量与模型不一致(函数、别名、精度) | 调整 SQL 与模型口径一致;必要时为常用表达式配置衍生度量。 |
| 查询不命中 Cube(仅差一列) | 模型维度与 SQL 选择不完全匹配 | 补齐常用维度到模型或调整 SQL;评估必要维度/联合维度。 |
| "维表 Join 不生效/行数放大" | Lookup 表未正确配置、Join Key 为空或类型不一致 | 对齐 Join Key 类型与大小写,清洗 NULL;确保维表标记为 Lookup。 |
| 构建时间异常长、Region 压力大 | 未做 Aggregation Group/层级维度,Cuboid 组合爆炸 | 切分 Aggregation Group、设置层级维度与联合维度,裁剪低频组合。 |
| 构建任务失败/卡住 | Spark 资源不足、并发与内存参数不当 | 提升 Executor/内存,合理并行度与分区;分段构建大时间区间。 |
| 增量构建有缺口 | 分区字段/时间水位不一致 | 统一分区列与时间格式;补建缺段并校验字典一致性。 |
| 字典编码不一致导致维度异常 | 历史与新构建字典不对齐 | 固定字典策略;必要时做一次全量重建以对齐字典。 |
| 实时与离线口径不一致 | Lambda 合并口径不同(聚合粒度/窗口/时区) | 统一时间窗口与聚合口径;增加回填与对账流程。 |
其他系列
🚀 AI篇持续更新中(长期更新)
AI炼丹日志-29 - 字节跳动 DeerFlow 深度研究框斜体样式架 私有部署 测试上手 架构研究 ,持续打造实用AI工具指南! AI研究-127 Qwen2.5-Omni 深解:Thinker-Talker 双核、TMRoPE 与流式语音
💻 Java篇持续更新中(长期更新)
Java-174 FastFDS 从单机到分布式文件存储:实战与架构取舍 MyBatis 已完结,Spring 已完结,Nginx已完结,Tomcat已完结,分布式服务已完结,Dubbo已完结,MySQL已完结,MongoDB已完结,Neo4j已完结,FastDFS 正在更新,深入浅出助你打牢基础!
📊 大数据板块已完成多项干货更新(300篇):
包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件,覆盖离线+实时数仓全栈! 大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT案例 详解