Saiku 4.8：一个把 MDX 藏起来、让 Excel 和 AI 代理共用同一套多维模型的语义层

它解决什么问题：把多维模型从一个入口变成三个入口

Saiku 的核心主张是：你只需要维护一份立方体模型，就能同时服务 Excel 用户、浏览器拖拽用户和 AI 代理。传统做法是 Excel 走 XMLA/MDX，BI 工具走自己的查询语言，AI 代理则直接面对数据库表，三套口径很难对齐。Saiku 4.8 把 Mondrian 作为统一语义层，Excel 通过 XMLA 访问，浏览器通过 SPA 自动生成 MDX，AI 代理则通过 /rest/saiku/api/ai/* 的类型化 REST 接口，绕开 MDX 语法。这个定位和许多现代语义层项目不同，它不试图取代多维建模，而是把多维模型暴露给更多消费端。适合的团队是已经投资了 Mondrian schema、又不想为每个新消费端重写查询逻辑的人。

架构：Mondrian 换上了 Calcite 规划器，Arrow 当传输格式

Saiku 4.8 的底座是 Mondrian 4.8.1.x 的 Spicule 分支，这个分支在传统 SqlQuery 构建器旁边加了一个基于 Apache Calcite 的 SQL 规划器。默认启用 Calcite，想退回旧行为就加 -Dmondrian.backend=legacy。这意味着 Mondrian 生成的 MDX 不再直接翻译成固定 SQL，而是经过 Calcite 做关系代数优化，再落到目标引擎。仓库里给出了一个例子：Saiku 到 Mondrian 到 Calcite 到 Trino 再到 Iceberg 的完整链路。结果集用 Apache Arrow 作为 wire format，浏览器和程序化消费者共享零拷贝的 cellset 信封。服务端是 Jetty 12 EE10 加 Jersey 3.1 加 Spring 6 加 Spring Security 6.5，打成单个 JAR，用 Picocli 启动。前端 SvelteKit 5 的 SPA 被打进同一个 JAR，从 /ui/ 路径提供。这个架构的取舍在于：Calcite 规划器是否能正确处理所有 Mondrian 生成的多维语义，文档没有给出完整的兼容性矩阵，所以迁移到 Calcite 后端前需要针对你的 schema 做回归测试。

AI 查询 API：自描述、自纠错，但仍是 MDX 的皮影戏

AI 接口的设计是让代理通过 /ai/cubes 和 /ai/schema 发现层级、级别、度量和同义词，然后 POST /ai/query 提交一个 JSON 描述的问题，服务端把它翻译成 MDX 并执行，返回类型化的 {value, formatted, unit} 单元格。验证失败时返回 {status, field, available} 信封，代理可以根据 available 列表自我纠正，不用去翻日志。这个设计比让 LLM 直接写 MDX 安全得多，因为校验发生在服务端。但要注意，AI 接口并没有消除对 schema 注释的依赖，README 提到立方体需要用 saiku.semantic.* 注释命名空间来描述自己，这意味着建模工作量仍然存在。另外，SQL 侧还有一个孪生接口 /rest/saiku/api/ai/ossie/*，用于 Ossie 语义层建模的数据集，形状相同，但多了一个 POST /ai/ossie/ask 用于纯自然语言提问。这实际上暴露了双轨制：MDX 世界和 Ossie 世界并存，团队需要决定数据模型放在哪一边。

技能与空间：把权限和提示词变成配置文件

Saiku 允许管理员用 Markdown 文件定义 Skills，放在 saiku-home/skills/ 下，带 YAML frontmatter，可通过 /ai/ask 发现。用户可以用 /skill-name 前缀显式调用，或者让 LLM 根据技能目录自动路由。Spaces 是 JSON 文件，放在 saiku-home/agent-spaces/ 下，定义一个人设，包括系统提示词、立方体白名单和技能白名单。POST /ai/spaces/{id}/ask 会在服务端强制执行白名单，超出范围的立方体直接返回 403，用户无法绕过。这个机制把 AI 代理的权限控制从提示词工程层面提升到了服务端强制层面，是个务实的设计。但注意，Spaces 的粒度是立方体级别的，没有看到行级或单元格级的安全控制，如果你的需求是细粒度数据权限，这里可能不够。

上手与构建：30 秒跑演示，但源码构建有坑

最快体验方式是 docker run -d -p 8080:8080 --name saiku -e SAIKU_DEMO=true ghcr.io/spiculedata/saiku，然后打开 http://localhost:8080/ui/ 用 admin/admin 登录。演示模式自带 H2 和 FoodMart 立方体。真实部署时要去掉 SAIKU_DEMO=true 并设置 SAIKU_ADMIN_PASSWORD，否则 Saiku 拒绝在默认凭据下启动，这是安全上的硬性要求。从源码构建需要 JDK 21 和 Maven 3.9+，但有个明显的坑：Saiku 的 Mondrian fork、olap4j、saiku-query 和 Ossie 构件发布在 GitHub Packages 上，即使包是公开的，Maven 也需要认证 token。README 明确警告，没有 token 会得到裸的 401 Unauthorized，而且不会提示 token 问题。你必须创建 classic 个人访问令牌，只给 read:packages 权限，因为 GitHub 的 Maven 仓库不接受 fine-grained token。然后要在 ~/.m2/settings.xml 里加五个 server 条目，包括 github-mondrian-saiku、github-olap4j、github-olap4j-xmlaserver 等。这个流程对不熟悉 GitHub Packages 的开发者来说是个不必要的摩擦点，文档虽然写清楚了，但第一次构建很容易卡住。

可观测性：OTel 自动埋点，但覆盖范围有限

Saiku 通过 OTel Java agent 提供可观测性，设计是零代码改动，设置 OTEL_EXPORTER_OTLP_ENDPOINT 环境变量即可激活。它会自动埋点 Jetty、Jersey、JDBC（每条 Mondrian 生成的 SQL 都变成子 span）、出站 HTTP、JVM 指标和 DBCP2 连接池指标。trace context 会自动注入到 Saiku 日志格式里。不设置端点环境变量时 agent 根本不会加载，所以对性能零影响。但文档也承认 Tier 2 自定义 span 还没覆盖，比如 ThinQueryService 这类内部服务。这意味着你只能看到 HTTP 和 SQL 层面的调用链，看不到查询服务内部的详细步骤。如果你的排障需求是理解 MDX 到 SQL 的转换内部耗时，这个观测能力可能不够。另外，OTel 导出需要你自己部署 collector，Saiku 只负责生成 span。

局限与替代方案：双轨语义层是特色也是负担

Saiku 4.8 最明显的局限是双轨设计：MDX 世界和 Ossie 世界并存。AI 接口有两套，一套是 /ai/query 对应 Mondrian 立方体，另一套是 /ai/ossie/* 对应 Ossie 数据集。团队必须决定每个数据集放在哪条轨道上，这增加了架构决策成本。另一个局限是构建依赖 GitHub Packages 的认证，即使包公开，CI 环境也需要配置 token，这比从 Maven Central 拉依赖麻烦得多。替代方案可以考虑直接用 Mondrian 加自己写的 REST 层，或者用其他语义层项目比如 dbt 加指标层。但区别在于，dbt 的指标层是面向关系模型的，不提供 MDX/XMLA 接口，Excel 用户无法直接连。Saiku 的独特价值在于保留了 XMLA 兼容性，这是很多现代语义层放弃的。如果你不需要 Excel 连接，那么 Saiku 的多维模型可能反而是过度设计，直接用 Ossie 或 dbt 会更轻。

维护与许可：Apache-2.0 但依赖链复杂

项目采用 Apache-2.0 许可证，对商业使用友好，没有 copyleft 传染。但维护成本体现在依赖链上：Mondrian fork、olap4j、saiku-query 和 Ossie 都发布在 GitHub Packages 上，这些构件不在 Maven Central，意味着你的构建系统必须额外配置仓库认证。版本节奏看起来是活跃的，最近有 4.8.0-RC2、RC1 和 4.7.1，说明项目在持续迭代。但 RC 版本意味着 API 可能变动，升级时要注意 changelog。另外，前端 SPA 在独立仓库，但被打进同一个 JAR，这意味着前端发布和后端发布需要同步，否则版本不匹配。文档提到 OpenTelemetry 的 Tier 2 自定义 span 尚未覆盖，这暗示可观测性功能还在演进中，生产环境需要自行评估缺失部分的影响。

编辑结论

Saiku 4.8 适合已经熟悉 MDX 和 Mondrian 的团队，尤其是那些既有 Excel/XMLA 报表又要给 AI 代理开放查询入口的场景。它不适合没有多维建模经验的人，因为语义层仍然依赖 schema 文件，AI 接口只是把 MDX 生成过程藏起来了，没有消除建模成本。也不建议在需要细粒度权限控制或对 OTel 自定义 span 有强需求的环境中直接上生产，文档明确说 Tier 2 自定义 span 尚未覆盖。采用前先验证三件事：GitHub Packages 的 token 能否顺利通过构建，Mondrian 的 Calcite 后端在你目标数据库（比如 Trino 或 Iceberg）上的 SQL 生成是否正确，以及 saiku-mcp 在容器内的 stdio 通信是否符合你的 AI 工具链。最后确认 Saiku 拒绝默认 admin/admin 启动的机制是否符合你的部署流程。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes