考察点
Kylin 现在更多是「原理题」而非「选型题」。面试官想看你是否理解预计算这个 OLAP 重要思想流派，以及为什么它在实时引擎冲击下退守特定场景。讲清 Cube、Cuboid、维度组合爆炸这三个概念，再能分析其衰落的工程原因，就算答到位。
参考答案
核心思想：空间换时间的极致
Kylin 的出发点是一个朴素观察：分析查询的维度组合在业务上是有限的、可枚举的。既然如此，就把所有维度组合的聚合结果提前算好存起来，查询时直接查结果，响应就是毫秒级——这就是 MOLAP（多维 OLAP）路线，和 ClickHouse、Doris 这类现场计算的 ROLAP 形成两个极端。
术语体系要先立住。Cube 是针对一张星型模型（事实表 + 维度表）定义的多维立方体，N 个维度就有 2^N 种维度组合。每种组合对应一个 Cuboid（方体），比如（城市）、（城市，渠道）、（城市，渠道，日期）都是不同的 Cuboid。构建（Build）时用 MapReduce/Spark 把每个 Cuboid 的聚合结果算出来，按 RowKey 编码存进 HBase。查询来了，SQL 被解析成维度 + 度量的组合，定位到恰好覆盖的 Cuboid，从 HBase 按 RowKey 范围扫出预聚合结果——查询复杂度与数据量脱钩，亿级和百亿级响应时间差不多，这是预计算最迷人的性质。
工程上的关键设计
维度组合爆炸是头号敌人。10 个维度就是 1024 个 Cuboid，全算出来存储和构建都不可行。Kylin 的应对是一套裁剪机制：必含维度（mandatory，每个 Cuboid 都带上，组合数直接砍半再砍半）、层级维度（hierarchy，年月日这种下钻关系，只算最细的）、联合维度（joint，要么一起出现要么都不出现）。经过裁剪，实际 Cuboid 数量通常压到几十个。
度量层面，COUNT DISTINCT 用的是 HLL 近似去重（预计算没法存原始集合，只能存可合并的近似结构），这个思路后来被所有 OLAP 引擎继承。构建支持按分区增量，每天只构建新增分区的 Cuboid，再合并 segment。
为什么衰落了
理解衰落原因比背架构更有面试价值。四个硬伤：
一是建模重。改一个维度要重建 Cube，业务变化快的团队跟不上；分析师想自由组合维度查询，受限于预先定义的 Cube，不灵活。
二是实时性差。Cube 构建是批任务，哪怕流式构建也是分钟级，和「数据落库即可查」的现代引擎没法比。
三是技术栈重。依赖 Hadoop + HBase 一整套，运维成本高，而 ClickHouse/Doris 单机能干的事它要一个集群。
四是 ROLAP 引擎性能起来了。向量化 + 列存让现场计算也能亚秒级返回，预计算的响应优势被抹平，灵活性劣势被放大。Doris 的 Rollup、ClickHouse 的物化视图本质都是「引擎内置的轻量 Cube」，把预计算思想收编了。
现状：退守但没消失
Kylin 没死，只是退回了它最合理的生态位：超大规模 + 维度组合相对固定 + 要求稳定亚秒响应的场景，典型如互联网大厂的固定经营指标平台（几 PB 数据、几千个预定义指标、要求大促期间 P99 稳定）。Kylin 4/5 版本把构建引擎换成 Spark、存储换成 Parquet，去掉了 HBase 依赖，走云原生路线。另外它的度量语义层思想（统一定义指标口径）影响了后来很多 BI 产品。
面试收尾话术
可以这样收：预计算思想不会过时，过时的是「独立重型预计算系统」这个形态。今天的 OLAP 引擎普遍内置了物化视图、Rollup、Projection 这些局部预计算能力，让「空间换时间」变成引擎内部的一种索引选择，而不是一套独立系统——这是 Kylin 给行业留下的真正遗产。
可能的追问
- 10 个维度为什么要裁剪 Cuboid？怎么裁？—— 2^10=1024 个 Cuboid，构建和存储爆炸。用 mandatory/hierarchy/joint 三种维度约束表达业务语义，把有效组合压到几十个。
- Kylin 的 COUNT DISTINCT 为什么只能近似？—— 预计算要求结果可合并，精确去重要存原始集合不可行，用 HLL 这类可合并的概率结构，误差千分之几，换来存储和可合并性。
- 现在什么场景还会选 Kylin？—— PB 级数据、指标口径固定、要求大促级并发下响应稳定的指标平台；维度多变、Ad-hoc 为主、数据要实时的场景都不适合。