针对 Apache Kylin 处理大规模复杂查询的场景，你会采用哪些查询优化策略？请说明其适用条件和原理。

回答思路

1. 【回答框架 1】Kylin 核心思想是空间换时间，通过预计算多维立方体（Cube）将聚合结果存储为 HBase 中的预计算表，查询时直接读取结果，避免对源数据的实时扫描。维度和度量的设计决定了 Cube 的粒度和查询能力。
2. 【回答框架 2】构建分层 Cube（如 Base Cuboid 和衍生 Cuboid）可平衡存储与查询效率。使用 Rowkey 设计优化查询过滤和聚合，将高基维度和频繁过滤的维度前置，利用字典编码压缩。
3. 【回答框架 3】查询优化策略包括：使用聚合组（Aggregation Group）和强制维度、层级维度减少 Cuboid 数量；通过 Cube 合并（Segment 合并）减少扫描文件数；启用查询下推（Pushdown）到 Hive 或 Spark 处理超高基/不规则查询。
4. 【回答框架 4】对于复杂查询，优先命中预计算结果；若无法命中，则考虑调整 Cube 设计（增加维度组合或构建衍生维度）或采用查询路由将部分计算下推。同时利用 HBase 的列族和过滤条件优化扫描范围。
5. 【回答框架 5】性能评估依赖构建时间和查询响应时间，需要权衡 Cube 构建成本和查询加速效果，通常以 99% 查询在秒级返回为目标，超时或高消耗查询需回源分析。
6. 【关键点 1】Kylin 通过预计算 Cube 将聚合结果物化，查询时直接读取预计算结果，避免实时扫描。
7. 【关键点 2】行键设计将高基维度和常用过滤维度前置，配合字典编码降低存储和加快扫描。
8. 【关键点 3】聚合组和强制维度可有效减少 Cuboid 数量，控制构建膨胀。
9. 【关键点 4】查询下推适用于难以预计算的高基维度或复杂 join 场景，但牺牲响应时间。
10. 【关键点 5】优化需权衡 Cube 构建成本与查询性能，通过监控命中率和膨胀率迭代改进。
11. 【易错点 1】不要无条件将所有查询预计算，超高基维度或极端复杂查询会导致 Cube 膨胀过高，应使用下推。
12. 【易错点 2】Rowkey 设计忽略查询模式会导致过滤失效，扫描全表降低性能。
13. 【易错点 3】忽略 Segment 合并会导致大量小文件，增加扫描开销。