Cube Core、Cube、Cube Cloud、DAX、MCP 的关系
很多中文读者第一次接触 Cube 时最容易混淆的一点是：
“Cube 到底是开源项目、商业平台，还是 AI 分析产品？”
答案是：这几个层次同时存在，但不是一回事。
1. Cube Core：开源语义层
Cube GitHub README 把 Cube Core 定义为开源语义层。
你可以把它理解为：
- 开源；
- 可自托管；
- headless；
- 通过 SQL / REST / GraphQL 暴露数据；
- 负责建模、编译、缓存、预聚合、权限治理。
如果你的目标是：
- 自建指标平台；
- 自建嵌入式分析后端；
- 给 AI Agent 提供统一语义接口；
- 希望完全掌控部署与代码；
那么教程主线应当以 Cube Core 为中心。
2. Cube / Cube Cloud：商业平台
README 也明确说明：Cube 是建立在 Cube Core 之上的商业产品。
它在语义层之上增加了更多平台能力，例如：
- 托管部署；
- 协作建模；
- RBAC；
- 多租户增强能力；
- 仪表盘、工作簿、分析 Chat；
- 与 Tableau、Power BI、Excel、Google Sheets 等更完整的集成。
所以更准确的关系是：
Cube Core = 开源语义层内核
Cube / Cube Cloud = 在 Core 之上构建的商业化平台3. DAX API 是什么
Cube 文档中有单独的 DAX API 页面。
它的定位是：
- 让 Cube 可以更原生地连接 Microsoft Power BI；
- 面向 DAX / SSAS 风格消费；
- 文档说明中属于 Enterprise and above 计划能力；
- 并且 DAX API 只暴露 views，不直接暴露 cubes。
因此：
- 如果你写开源 Core 教程，DAX 不应作为主线；
- 但如果你面向企业 BI 平台集成，可以单独做“扩展章节”。
4. MCP 是什么
Cube 文档中也有 MCP server 页面。
它描述了两种模式：
Remote MCP
更偏平台托管能力，通过远程端点和 OAuth 让 AI 客户端接入 Cube。
Local MCP
文档写得很明确：本地 MCP server 运行在客户端，直接通过 API key 与 Chat API 通信，适合 self-hosted 或 development 场景。
所以如果你做中文教程，最好的写法是：
- 主线仍然写 Cube Core 的语义层能力；
- 把 MCP 放在“AI 接入方式”章节；
- 明确告诉读者：MCP 是连接 AI 助手的一种方式，不是 Cube 全部能力的代名词。
5. 为什么教程必须分层讲
如果不区分 Core 与平台能力，读者很容易产生几个误解：
误解 1：以为 Cube 自带完整 BI 前端
实际上 Cube Core 是 headless 的。
误解 2：以为所有 API 都是开源 Core 的同等主线能力
实际上 SQL / REST / GraphQL 是教程主线；DAX、Remote MCP 更偏平台集成能力。
误解 3：以为学 Cube 就是在学一个“智能问数聊天产品”
实际上 Cube 的根本价值还是语义层，而不是聊天界面本身。
6. 教程里建议采用的表达方式
为了避免混淆，建议在文档中用如下标签：
- Cube Core：开源主线；
- Cube 平台能力：商业版增值能力；
- 两者通用：语义模型兼容的概念与实践。
例如：
| 主题 | 建议标签 |
|---|---|
| cubes / views / measures / pre-aggregations | Cube Core |
| REST / SQL / GraphQL API | Cube Core |
| DAX API | Cube 平台能力 |
| Remote MCP | Cube 平台能力 |
| Local MCP 与 AI 集成模式 | 扩展章节 |
| 语义建模方法论 | 两者通用 |
7. 面向中文读者的推荐叙述顺序
最合适的顺序通常是：
- 先讲 Cube Core 是什么；
- 再讲为什么它在 AI 时代重要；
- 再讲商业平台是在 Core 之上增加了哪些能力；
- 最后再讲 DAX、MCP、Analytics Chat 等扩展集成。
这样读者会先建立“语义层”认知，而不是先建立“AI 聊天产品”认知。
一句话总结
Cube Core 是开源语义层，Cube / Cube Cloud 是基于该语义层构建的商业平台；中文教程应以 Core 为主线，把 DAX、MCP、Chat、Workbooks 等能力作为扩展说明。