连接数据源：Cube 适合接什么，不适合接什么

很多人学 Cube 的第一坑，不是模型写错，而是对数据源边界理解错。

1. 最重要的官方前提

Cube 官方文档明确写道：

• Cube is designed to work with data sources that allow querying them with SQL；
• Cube is not designed to fetch data from REST、GraphQL 或其他 API。

这句话几乎决定了你后续所有架构设计。

2. 什么样的数据源最适合 Cube

云数仓 / 湖仓

• Snowflake
• BigQuery
• Databricks
• Redshift
• Microsoft Fabric
• Firebolt

查询引擎 / OLAP 引擎

• ClickHouse
• Trino / Presto
• Athena
• Druid
• Doris / StarRocks（通过相应 SQL 接入思路）

应用数据库 / 事务数据库

• Postgres
• MySQL
• SQL Server
• Oracle
• SQLite

3. 如果底层不是 SQL 数据源怎么办

场景 A：只有业务 API

最常见做法是先同步到 SQL 可查询的数据层，例如：

• 同步到 Postgres / ClickHouse / Snowflake；
• 通过 ELT/CDC 管道入仓；
• 再由 Cube 建模。

场景 B：文件型数据

文档也提示了一种思路：使用支持的引擎先把文件查询能力“变成 SQL”，例如用 DuckDB 查询 S3 上的 Parquet。

场景 C：确实需要特殊接入

可以考虑编写 custom data source driver，但这通常不是第一选择。

4. 连接数据源时你要考虑的不是“能不能连”，而是“适不适合分析”

即使某个数据库技术上可以连接，也不代表它适合作为 Cube 的主分析源。

更适合的情况

• 数据已经过清洗和建模；
• 适合聚合与扫描；
• 有明确时间字段；
• 支持较大并发或可由预聚合弥补。

不太适合的情况

• 完全是高频 OLTP 场景；
• 数据非常原始、字段语义混乱；
• 表结构频繁无序变化；
• 没有稳定主键或时间字段。

5. 如何给中文读者解释“Cube 不是抓 API 的工具”

最容易理解的说法是：

Cube 擅长的是“分析查询治理”，而不是“业务接口采集”。

它站在 分析消费层 和 SQL 数据层 之间，而不是站在第三方 SaaS API 与 ETL 管道之间。

6. 多数据源与多租户不要混为一谈

官方文档对 multitenancy 和 multiple data sources 是分开描述的。

多数据源

更像：

• 同一个分析模型需要跨多个数据库取数；
• 或不同 cube 来自不同数据库。

多租户

更像：

• 不同客户 / 组织访问各自数据；
• 安全上下文、预聚合 schema、driver 配置可能按租户变化。

这两个特性可以一起用，但不要概念混淆。

7. 中文教程里建议的教学顺序

1. 先用 单一 Postgres 跑通最小例子；
2. 再讲 ClickHouse / BigQuery / Snowflake 等分析型数据源；
3. 再讲 multiple data sources；
4. 最后再讲 multitenancy。

这样读者不会在还没理解 cube 建模前，就陷入复杂连接拓扑。

8. 实战建议

先选一个你最容易控制的数据源

如果只是教学或 PoC，优先选：

• Postgres：通用、简单；
• ClickHouse：适合看 OLAP 性能；
• BigQuery / Snowflake：适合企业真实数仓场景。

一开始就保留这些字段

建议示例表一开始就具备：

• 主键
• 时间字段
• 状态字段
• 金额字段
• 一个常用 join 外键

这样后续示例更连贯。

一句话总结

Cube 的天然工作对象是 SQL 数据源；如果你的数据还停留在第三方 API 或文件散装阶段，应先把它变成适合分析的 SQL 数据层，再让 Cube 发挥语义层价值。