Blog 专题：性能、SQL API 与生产可用性
这个专题聚焦 Cube 为什么不只是“会建模”，还要“能在线跑”。
先看推荐阅读卡片
Introducing Cube Store
理解 Cube Store 为什么是生产性能体系的核心部件。
Query pushdown in Cube’s semantic layer
理解 SQL API 如何在治理前提下承接更复杂的 BI SQL。
Deep dive: What the heck is the Semantic Layer
把语义层的建模、查询编译与预聚合放进一个完整闭环。
Where should a semantic layer be built?
说明为什么性能、成本与缓存，也属于 semantic layer 的价值。
这张图最能说明 Cube Store 的意义
这一专题回答什么问题
1. 为什么语义层还需要自己的性能层
Introducing Cube Store 说明：
- 仅靠内存缓存不够；
- 预聚合要有专用存储与查询引擎；
- 高并发和亚秒级响应是独立问题。
2. 为什么 SQL API 越来越重要
Query pushdown 说明：
- BI 工具会生成复杂 SQL；
- 语义层必须在治理内承接复杂表达力；
- SQL API 正在成为更强主线。
3. 为什么性能和成本也属于语义层价值
Where should a semantic layer be built? 强调：
- 语义层能提高缓存命中；
- 能做更高级的预聚合；
- 对云数仓成本控制有实际价值。
再看一张与 SQL API 相关的图
最值得记住的 5 个判断
- 预聚合不是附属优化，而是生产核心能力。
- Cube Store 让 Cube 从逻辑层变成 serving layer。
- SQL API 的难点不是 SQL 语法，而是 BI 工具生成 SQL 的复杂度。
- 开放表达力时，权限和 view 设计必须更严谨。
- 性能、并发、成本都应被视为语义层职责的一部分。
对应本教程主线
一句话总结
这个专题的核心结论是：现代语义层不只是治理层，也必须是高性能分析接口层。