alitrack

你的仪表盘,为什么不能是一个 .sql 文件?

停三秒想一下:你公司的仪表盘存在哪?

大概率在某个数据库里。Metabase 的 PostgreSQL 里,Superset 的 MySQL 里,Tableau Server 的仓库里。改一个图表要登录后台、点半天、保存。想回滚?不行。想 code review?不可能。想用 Claude Code 帮你改?做不到。

因为仪表盘的定义不在你手里。在数据库里。

Shaper 做的事就是把这个前提翻过来:仪表盘就是一个 .sql 文件。


● ● ●

把仪表盘还给文件系统

.dashboard.sql 跟你项目里的 .py、.tsx 没区别。

长这样:

SELECT '周活跃用户'::LABEL;
SELECT
  date_trunc('week', created_at)::XAXIS,
  count(DISTINCT user_id)::LINECHART
FROM events
GROUP BY 1 ORDER BY 1;

LABEL 是标题。XAXIS 是横轴。LINECHART 是折线图。没 JSON 配置,没 YAML DSL,就是在 SQL 里加类型标注。DuckDB 原生支持 ::TYPE 的 cast 语法,Shaper 把它当成了图表描述语言。

目前标注有二十多种:柱状图、饼图、仪表盘、下拉筛选、日期选择、自动刷新——常见 BI 组件都能用一行 SQL 表达。

但语法不是重点。重点是:当你把仪表盘定义放进文件的那一刻,你什么都没"做",却自动解锁了一整套能力。


● ● ●

文件带来的"免费午餐"

Git 管理。 仪表盘跟代码一起进仓库。PR 审查、版本回滚、分支管理——Git 怎么管代码就怎么管仪表盘。不需要学新工具。

编辑器打开。 VS Code、Neovim、任何能写 SQL 的地方就是你的 BI 编辑器。SQL 高亮、自动补全、格式化全是现成的。

AI 能写。 Claude Code、Cursor 这类 AI coding agent 可以直接帮你生成和修改仪表盘。你在 IDE 里说"加一个月度趋势图",它产出的是一个带 LINECHART 标注的 SQL 块。不是 JSON,不是 GUI 操作。

CI 部署。 改了 SQL,git push,GitHub Actions 跑 shaper deploy,仪表盘上线。跟部署代码一模一样的流程。

本地热重载。 shaper dev 跑起来,改了 SQL 文件浏览器秒刷新。所见即所得,不需要登后台、不需要点保存、不需要刷新页面。

这些不是 Shaper "发明"的能力。是文件系统本身就有的能力。Shaper 只是把仪表盘放回了它应该在的地方。


● ● ●

怎么跑起来

docker run --rm -it -p5454:5454 taleshape/shaper

打开 http://localhost:5454,就能用了。不需要 PostgreSQL、不需要 Redis、不需要单独的消息队列。

一个二进制文件包含了:API 服务器、NATS 消息队列、任务调度器、PDF 渲染引擎、前端页面。Go 编译时把 React 前端打包进去,所以 Docker 镜像 docker run 就完了。

背后做了两件事:

Shaper 架构

Shaper 架构

SQLite + DuckDB 双数据库。 SQLite 存系统元数据(用户、任务调度),DuckDB 跑分析查询。各司其职,都不需要独立进程。

NATS JetStream 做多节点同步。 如果你跑多个 Shaper 实例,仪表盘的变更会通过 NATS 实时广播到所有节点——跟 event sourcing 一个思路。单节点跑的时候 NATS 完全透明。


● ● ●

跟同类工具的差别

Shaper 的作者 Jorin Vogel 在 HN 上有个很坦诚的说明:

"Metabase 功能丰富,非技术用户也能自己拖拽出仪表盘。Shaper 把东西都定义在 SQL 代码里。不试图提供 self-serve。"

这也划出了 Shaper 跟 Evidence、Rill 的分界线:不做自助分析,就是让开发者用文件管仪表盘。

工具怎么定义仪表盘适合谁
MetabaseGUI 拖拽全团队
SupersetGUI + SQL数据分析师
EvidenceMarkdown + SQL技术作者
**Shaper****纯 SQL 文件****开发者**

● ● ●

几个要知道的坑

单人维护。 仓库 1,550 次提交全部来自 Jorin Vogel。代码质量不错,迭代极快(每 4 天一个 release),但 bus factor = 1 绕不开。如果你的核心分析能力要依赖它,想清楚。

不做自助分析。 设计决策,不是缺陷。但也意味着团队里非技术同事没法自己建报表。

NATS 有排查门槛。 单节点跑的时候无感,一旦出问题要查 JetStream 状态,需要一点学习成本。


● ● ●

所以——谁该用?

你团队用代码和 Git 管所有东西,现在想把仪表盘也纳进来;你需要把分析能力嵌入 SaaS 产品,白标 + JWT 行级安全是刚需;你讨厌拖拽,愿意写 SQL;你想用 AI agent 自动生改仪表盘——Shaper 是目前同类里最干净、迭代最快的选择。

如果不满足上面任何一条,它大概率不适合你。


项目地址:https://github.com/taleshape-com/shaper