TL;DR
- 场景:海量明细(百 TB/千亿级)、高并发 SQL 分析,要求秒级响应与可视化接入。
- 结论:Kylin 以预计算 Cube/Cuboid + HBase 存储,实现 MOLAP 加速;实时能力取决于模型与构建链路。
- 产出:一套版本/组件选择矩阵 + 常见故障速查卡,帮助工程化落地与问题定位。

版本矩阵
| 模块/能力 | 已验证说明 |
|---|---|
| 数据源 | 批:Hive;流:Kafka(V1.5起引入,V2.4支持与Hive维表JOIN) |
| 计算/构建引擎 | 早期MapReduce;后续支持Spark;文档中亦提及Flink能力(以实际部署为准) |
| 存储引擎 | HBase持久化Cube;依赖RowKey设计与列簇布局优化 |
| 模型 | 星型/雪花(V2.0起);维度剪枝与Cuboid选择影响存储与查询命中率 |
| 查询接口 | SQL(Calcite解析);JDBC/ODBC/REST,对接BI(Zeppelin、Tableau等) |
| 实时/近实时 | V1.6引入NRT;V3.0标注Real-time OLAP,延迟与链路/聚合策略相关 |
| 构建策略 | 支持全量+基于时间分区的增量构建;支持合并与刷新 |
| 路由命中 | 查询引擎将逻辑计划路由至命中的Cuboid;未命中可能回落或性能下降 |

背景历史
Apache Kylin是一款开源的分布式分析引擎,专门用于处理超大规模数据集的多维在线分析处理(MOLAP)。该技术最初由eBay中国研发中心的工程师团队于2013年开发,旨在解决eBay日益增长的海量数据分析需求。
2014年10月,eBay正式将Kylin项目捐赠给Apache软件基金会,使其成为Apache孵化器项目。经过一年多的孵化过程,Kylin在2015年11月成功毕业,晋升为Apache顶级项目(Top-Level Project)。这个里程碑式的成就使得Apache Kylin成为首个由中国人主导并成功晋升为Apache顶级项目的开源大数据技术。
在技术发展过程中,Apache Kylin的核心开发团队于2016年创立了Kyligence公司(全称Kylin Intelligence)。这家初创企业获得了来自红点创投、宽带资本等知名投资机构的数千万美元融资,专注于商业化的企业级Kylin解决方案的开发和服务。
值得一提的是,Apache Kylin这个名字来源于中国古代神话中的"麒麟"神兽,象征着祥瑞和智慧。这个命名体现了中国开发者对传统文化的传承,也代表了项目团队对大数据分析技术的美好愿景。
发展历程
- 2014年Kylin诞生,支持Hive批数据源,从海量历史数据挖掘价值
- 2015年V1.5 首先支持Kafka数据源,采用单机微批次处理构建
- 2016年V1.6发布实时(NRT Streaming),使用Hadoop微批次消费流数据
- 2017年V2.0支持雪花模型和Spark引擎
- eBay团队开始尝试 real-time
- 2018年V2.4支持Kafka流数据与Hive维度表JOIN
- eBay开源real-time OLAP 实现
- 2019年Q1,经过社区Review和完善,合并Master
- 2019年Q4,V3.0发布Real-time OLAP,实现秒级数据准备延迟
Kylin提供多维数据分析(MOLAP)的秒级响应,目前国内很多公司都在使用。

项目特点
- 数据源和模型:主要支持Hive、Kafka
- 构建引擎:早起支持MapReduce计算引擎,新版本支持Spark、Flink计算引擎。除了全量构建外,对基于时间的分区特性,支持增量构建。
- 存储引擎:构建好的Cube以Key-Value的形式存储在HBase中,通过优化RowKey加速查询。每一种维度的排列组合计算结果被保存为一个物化视图,叫Cuboid
- 优化算法:Cube本身就是用空间换时间,也会根据算法,剪枝优化掉一些多余的Cubeid,寻求平衡
- 访问接口:支持标准SQL查询,可以对接Zeppelin、Tableau等BI工具,SQL通过查询引擎,可以被路由到对应的Cuboid上。
应用场景
特点:Kylin在亚秒内返回海量数据的查询结果
Kylin的典型应用场景如下:
- 巨大的数据量,单个数据源表千亿级别,且单个数据源达到百TB级别
- 巨大的查询压力(查询的高并发)
- 查询的快速响应
- 下游较灵活的查询方式,需支持带有复杂条件的SQL查询
Kylin的核心思想是预计算,将数据按照指定的维度和指标,预先计算出所有可能的查询结果,利用空间换时间来加速模式固定的OLAP查询。
基本术语
数据仓库
数据仓库是一种信息系统的资料存储理论,强调的是利用某些特性的资料存储方式,让所包含的资料特别有利于分析和处理,从而产生有价值的咨询,并可依此做出决策。 利用数据仓库的方式存放的资料,具有一旦存入,便不会随时发生变动的特性,此外,存入的资料必包含时间属性,通过一个数据仓库中含有大量的历史性资料,并且它可以利用特定的分析方式,从其中发掘出特定的资讯。

OLTP
联机事务处理,传统的关系型数据库的应用。
OLAP分类
OLAP(Online Analytical Process),联机分析处理,以多维度的方式分析数据,它是呈现集成性决策信息的方法,多用于数据仓库或商务智能。其主要功能在于方便大规模数据分析及统计计算,可对决策提供参考和支持。与之相区别的是联机交易处理(OLTP),联机交易处理,侧重与基本的、日常的事务处理,主要是事务的增删改查。
OLAP的概念,在实际应用中存在广义和狭义两种不同的理解方式。广义上理解与字面上的意思相同,泛指一切不会对数据进行更新的分析处理。但更多的情况下OLAP被理解为其狭义上含义,即与多维分析相关,基于立方体(Cube)计算而进行的分析。
OLAP有多种实现方法,根据存储数据的方式不同可以分为:
- ROLAP(Relational OLAP),细节数据,聚合后的数据都保存在类关系型数据库中,Hive、SparkSQL属于ROLAP。
- MOLAP(Multidimensional OLAP),事先将汇总数据计算好,存放在自己特定的多维数据库中,用户的OLAP操作可以直接映射到多维数据库的访问,不通过SQL访问吗,其实本质上是空间换时间。Kylin的本质是MOLAP
- HOLAP(Hybrid OLAP),表示基于混合数据组织的OLAP实现(Hybrid OLAP),如低层是关系型的,高层是多维矩阵型的,这种方式具有更好的灵活性。
事实表和维度表
事实表(Fact Table)是指存储有事实记录的表,如系统日志、销售记录、传感器数值等,事实表的记录是动态增长的,所以它的体积通常远大于维度表。
维度表(Dimension Table)或维度表,也称为查找表(LookUp Table),是与事实表相应的一种表,它保存了维度的属性值,可以跟事实表做关联。相当于事实表上经常重复的属性抽取、规范出来用一张表进行管理。
常见的维度表:日期表(存储日期对应的年月日、季度等)、地区表(国家、省、城市等)。维度表的变化通常不会太大。 维度表可以带来如下的好处:
- 缩小了事实表的大小
- 便于维度的管理和维护,增加、删除、修改维度的属性,不必对事实表的大量记录进行改动
- 维度表可以多个事实表重用
维度和度量
shell
userid,2020-10-01 09:00:00, produceid,shopid,orderid,299
维度是指审视数据的角度,它通常是数据记录的一个属性,例如:时间、地点等 度量就是被聚合的统计值,也就是聚合运算的结果,通常是一个数值,如总销售额、不同的用户数等。
分析人员往往要结合干个维度来审查度量值,以便在其中找到变化规律。在一个SQL查询中。GROUP BY的属性通常就是维度,而所计算的值则是度量。
sql
SELECT
part_dt,
lstg_site_id,
sum(price) as total_selled,
count(DISTINCT seller_id) as sellers
FROM
kylin_sales
GROUP BY part_dt, lstg_site_id;
以上查询中,part_dt、lstg_site_id是维度、sum(price)、count(distanct seller_id)是度量。
星型&雪花模型
星型模型(Star Schema)是数据仓库维度建模中常用的数据模型之一。它的特点是一张事实表,以及一到多个维度表,事实表与维度表通过主外键相关联,维度表之间没有关联,就像需要小星型围绕在一颗恒星的周围,所以叫星型模型。 另一种常用的叫雪花模型(SnowFlake Schema),就是将星型模型中的某些维度表抽取成更细粒度的维表,然后让维表之间也进行关联,这种形状酷似雪花,所以叫做雪花模型。
Cube和Cuboid
Cube即多维立方体,也叫数据立方体。

这个由三个维度(维度数超过3个,上图仅为了方便画图表达)构成了一个OLAP立方体,立方体中包含了满足条件的Cell(子立方体)值,这些Cell里面包含了要分析的数据,称之为度量值。
- 立方体:由维度构建出来的多维空间,包含了所有要分析的基础数据,所有的聚合数据操作都在立方体上进行
- 维度:观察数据的角度,一般是一组离散的值,对于N个维度来说,所有可能的组合有2的N次方个
- 度量:即聚合计算的结果,一般是连续的值
- Cuboid:特指Kylin中在某一种维度组合下所计算的数据
- 事实表中的一个字段,要么是维度,要么是度量(可以被聚合)
- 给定一个数据模型,可以对其上的所有维度进行组合,对于N个维度来说,所有可能的组合有2的N次方个
- Cube(或称DataCube),即数据立方体,是一种常用于数据分析于索引技术,它可以对原始数据建立多维度索引,大大加快查询效率。数据立方体只是多维模型的一个形象的说法
- Cuboid特指Kylin中在某一维度组合下所计算的数据

技术架构

基本介绍
ApacheKylin 系统可以分为:
- 在线查询
- 离线构建
在线查询模式主要处于上半部分,离线构建处于下半部分。 Kylin的技术架构如下:
- 数据源主要是Hadoop Hive,数据以关系表的形式输入,保存着待分析的数据,根据元数据的定义,构建引擎从数据源抽取数据,并构建Cube
- Kylin可以使用MapReduce或Spark作为构建引擎,构建后的Cube保存在右侧的存储引擎中,一般选用HBase作为存储
- 完成了离线的构建后,用户可以从查询系统发送SQL进行查询分析
- Kylin提供了各种RestAPI,JDBC、ODBC接口。无论从哪个接口进入,SQL最终都会来到Rest服务层,再转交给查询引擎进行处理。
- SQL语句是基于数据源的关系模型书写的,而不是Cube,Kylin在设计时,刻意对查询用户屏蔽了Cube的概念。只要理解了关系模型就可以使用Kylin,没有额外的学习门槛,传统的SQL应用也很容易迁移。
- 查询引擎解析SQL,生成基于关系表的逻辑执行计划,然后将其转换为基于Cube的物理执行计划,最后查询预计生成的Cube并产生结果,整个过程不会访问原始数据源
组件功能
- REST Server,提供Resutful接口,例如创建、构建、刷新、合并等Cube相关操作,Kylin的Projects、Tables等元数据管理,用户访问权限控制,SQL的查询等。
- Query Engine:使用开源的Apache Calcite框架实现SQL解析,可以理解为SQL引擎层
- Routing:负责将解析SQL生成的执行计划转换成Cube缓存的查询,这部分查询时可以秒级甚至毫秒级完成
- Metadata:Kylin中有大量的元数据信息,包括Cube的定义、星型模型的定义、Job和执行Job的输出信息、模型的维度信息等等。Kylin的元数据和Cube都存储在HBase中,存储的格式是JSON字符串
- Cube Build Engine:所有的模块的基础,它主要负责Kylin预计算中创建Cube,创建的过程是首先通过Hive读取原始数据,然后通过一些MapReduce或Spark计算生成HTable,最后将数据load到HBase表中。
工作原理
Apache Kylin的工作原理是对数据模型做Cube计算,并利用计算的结果加速查询,具体的过程如下:
- 指定数据模型,定义维度和度量
- 预计算Cube,计算所有Cuboid并保存为物化视图(存储到HBase中)
- 执行查询时,读取Cuboid,计算并产生查询结果
高效OLAP分析:
- Kylin的查询过程不会扫描原始记录,而是通过预计算预先完成表的关联、聚合等复杂运算
- 利用预计算的结果来执行查询,相比非预计算的查询技术,其速度一般要快一到两个数量级,在超大的数据集上优势更明显
- 数据集达到千亿乃至万亿级别时,Kylin的速度可以超越其他非预计算技术的1000倍以上
Kylin生态

- Apache Kylin的核心:Kylin的OLAP引擎由元数据引擎、查询引擎、任务引擎、存储引擎组成。另外,它还有一个REST服务对外 提供查询请求的服务
- 可扩展性:提供插件机制支持额外的特性和功能
- 与其他系统的整合:可整合任务调度器、ETL工具、监控及告警系统
- 驱动包(Drivers):提供ODBC、JDBC驱动支持与其他工具(如Tableau)的整合
错误速查
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| 构建任务长时间卡住/失败 | 源表倾斜、Shuffle巨大、字典编码过大 | 查看构建Job日志与Stage指标;检查维度基数与倾斜Key | 调整分区与并行度;对高基数维度降维/裁剪;启用倾斜处理与预聚合 |
| 查询偶发变慢/超时 | Cuboid未命中或RowKey设计不佳 | 启用查询剖析;检查命中Cuboid与Scan范围 | 追加关键维度组合Cuboid;重构RowKey前缀与列簇;热查询建副本 |
| 近实时延迟拉长 | Kafka分区/消费滞后,微批间隔与资源不足 | 监控消费滞后、构建队列与HBase写入速率 | 提升并行度与Executor资源;缩短微批;优化HBase写入(写缓冲/Region切分) |
| 结果与明细表统计不一致 | 维度字典/时间分区不一致、去重口径不同 | 抽样校验分区;核对DISTINCT/汇总口径 | 统一口径与时区;重建受影响分区;为DISTINCT指标单独建模 |
| 构建频繁OOM或RegionTooBusy | Cuboid过多、单Region过热 | 查看Region热点与内存统计 | 剪枝Cuboid;预分区与均衡Region;提升RegionServer资源 |
| "表找不到/权限拒绝" | 元数据未同步、权限/连接串错误 | 校验MetaStore、Kylin元数据与凭证 | 重新同步元数据;修正数据源/驱动配置;最小权限校准 |
| 查询回落明细导致慢 | 维度过滤不在索引前缀、缺关键组合 | 查询计划分析命中率 | 新增常用过滤维度的前缀;补充组合Cuboid;调序过滤条件 |
| 增量合并后结果异常 | 分区边界/水位管理不当 | 审核增量区间与合并日志 | 统一分区水位;先小分区验证再全量推广;必要时回滚并全量重建 |
其他系列
🚀 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案例 详解