三个独立开发者互相不认识，但他们的工具拼成了一条完整数据栈

最近连续 deep dive 了三个 DuckDB 开源项目：Duckle（ETL）、DuckQuery（SQL 工作台）、Shaper（仪表盘）。写完报告之后发现一个巧合——这三个人互不认识，代码互不依赖，但把工具放在一起看，恰好是一条从数据源到报表的完整链路。

问题在于：它们彼此不知道对方的存在。没有共享配置，没有统一的 DuckDB 文件路径，没有一个地方告诉你"这三个工具可以一起用"。

DuckForge 做的事就这一件：给三个工具加了一条共识路径。 不是做新工具，是写胶水。

DuckForge 架构

● ● ●

三个工具，一条链路

先快速过一遍三个工具各自在哪。

Duckle 是数据 ETL。290+ 连接器，拖拽画布建管道，编译成 SQL，DuckDB 引擎执行。65MB 桌面 App，双击就能用，数据全程本地。

DuckQuery 是 SQL 工作台。AI 写 SQL，联邦查询下推（跨源 JOIN 不会傻拉全表），报错自动诊断。还有个 MCP Server，可以被 Claude Code 直接驱动。

Shaper 是仪表盘引擎。写 SQL 加类型标注（::BARCHART_STACKED
、::XAXIS
），自动出图。支持 JWT 行级安全、白标嵌入、PDF 导出。仪表盘就是 .sql
文件，能进 Git、能 CI 部署。

这三个工具全部跑在 DuckDB 上。这意味着 Duckle 写完的数据库，DuckQuery 直接查，Shaper 直接出图——零格式转换。

DuckForge 就是告诉它们"大家用的是同一个文件"。

● ● ●

怎么用

git clone https://github.com/alitrack/duckforge
cd duckforge
./forge init
./forge up

forge up
用 docker compose 起 DuckQuery 和 Shaper，共享一个 DuckDB 数据卷。Duckle 跑在宿主机上，管道输出指向同一个 data/warehouse.duckdb
。

用起来是这样的流程：

1. 01Duckle 打开桌面 App，拖拽建一条管道——"把 Salesforce 订单拉到本地 DuckDB"
3. 02管道跑完，./forge refresh
   ——通知 DuckQuery 刷新元数据，重新部署 Shaper 仪表盘
5. 03DuckQuery 打开 localhost:48000
   ，写 SQL 探索数据——"上周各渠道转化率对比"
7. 04查满意了，./forge sql2dash queries/conversion.sql bar "渠道转化率"
   ——一键导出为 Shaper 的 .dashboard.sql
   
9. 05Shaper 渲染仪表盘，localhost:5454
   就能看到图表了

一共 5 条命令。核心逻辑不到 200 行 shell。

● ● ●

它不是什么

DuckForge 不做数据同步、不做查询引擎、不做可视化。它只是一个编排层——路径约定、docker compose、格式转换。

它也不是生产级方案。三个工具都是 solo 项目，bus factor 都是 1。但如果你恰好三个工具都在用（或者想试试），DuckForge 把"手动对齐配置"的 20 分钟省掉了。

● ● ●

项目里有什么

duckforge/
├── forge                    # CLI
├── docker-compose.yml       # DuckQuery + Shaper
├── .duckforge.yaml          # 告诉三个工具 DuckDB 文件在哪
└── scripts/sql2dashboard.py # SQL → .dashboard.sql

六个命令：

● ● ●

为什么值得关注

DuckDB 生态有个趋势：工具不是越做越大，而是越做越专。Duckle 只做 ETL，DuckQuery 只做查询，Shaper 只做可视化——每个都是 DuckDB-native，每个都可以独立用，但共享同一个引擎让它们天然可组合。

DuckForge 是这个趋势的产物——它不做任何"自己的事"，只是把已有的三个工具对齐。200 行代码，说不上技术壁垒，但解决了一个真实问题：工具都很好，没人告诉你它们可以一起用。

项目地址：https://github.com/alitrack/duckforge