很多数据工具要么太“表格化”，做几步清洗就开始吃力；要么一上来就是云服务、编排平台和一堆部署前置，明明只是想把几个文件、数据库表和 API 数据整理一下，却先把环境复杂度拉满。

今天想写的 slothflowlabs/duckle，走的是另一条路。它把 可视化 ETL / ELT 编排、DuckDB 执行、本地优先工作区 和 桌面应用体验 放在一起，目标不是替代大公司的数据平台，而是把很多单机就能完成的数据整理任务，做得更快、更透明。

发布时 GitHub 页面显示这个项目大约有 551 stars、33 forks，主语言显示为 Rust，仓库创建于 2026-05-21，最近一次 push 时间是 2026-06-19。GitHub 最新 release 目前是 v0.4.1，发布时间为 2026-06-18。README 把它定位为 public beta，并强调它是一个 local-first data studio。

项目概览

属性详情
仓库slothflowlabs/duckle
定位本地优先的可视化 ETL / ELT 桌面工具
Stars约 551
Forks33
主要语言Rust
运行核心DuckDB
当前状态Public beta
最新 releasev0.4.1

它想解决的不是“大数据平台问题”，而是“单机数据工作为什么还这么折腾”

我觉得 duckle 有意思的地方，在于它没有试图伪装成下一代分布式数据底座。README 写得很明确，它的目标是 single-machine 场景，也就是：

  • 本地文件和数据库之间的数据清洗；
  • 小团队的数据准备和导出；
  • 把多个来源接进同一条 pipeline；
  • 在真正上线大平台前，先把逻辑快速跑通。

这个判断很务实。很多数据处理任务其实并不需要先上 Airflow、dbt Cloud、托管 warehouse 或一整套 SaaS 流程，真正卡人的反而是：

  • 工具切换太多；
  • 中间状态不透明；
  • 临时脚本很快失控；
  • 最后想让别人复现时，只剩一堆散落 SQL 和导出文件。

duckle 的做法是把这些环节压回一个本地工作区里，让你在画布上组织 pipeline，再把执行交给 DuckDB。

核心卖点不是“低代码”，而是“图形界面也能保持工程可读性”

很多可视化数据工具的问题，是一旦离开作者本人，别人就看不懂里面到底做了什么。duckle 在这点上明显想避免黑盒。

README 反复强调几点：

  • 画布会编译成 SQL；
  • 每个节点有 live preview；
  • 工作区是 plain files；
  • 可以直接进 Git 做 diff、branch 和 review。

这其实比“拖拽式编排”本身更重要。因为对工程团队来说，图形界面不是目的，可审计和可复现 才是目的。如果一个 pipeline 只能在某个 GUI 里点开看，那它很快就会变成组织债务。

duckle 至少在设计方向上，是把可视化作为入口，把文件化和 Git 友好作为长期落点。这一点让我觉得它更像开发工具，而不只是数据玩具。

DuckDB 是真正的执行层，不是宣传页上的装饰

这个项目的另一个关键点，是它不是拿桌面 UI 包一层“伪数据流”，而是真正把执行压到 DuckDB 上。

README 里写得很直接：

  • pipeline graph 会编译到 SQL；
  • 执行通过 DuckDB 完成；
  • 支持列式、本地、向量化的执行路径；
  • 大量连接器和格式都围绕 DuckDB 生态来接。

这让它和很多“拖拉拽生成脚本”的工具区分开来了。它不是帮你生成一段最后没人维护的 glue code，而是尽量把数据处理留在一个已经很强的分析引擎里。

最新的 v0.4.1 release 里，作者还专门提到把托管 DuckDB 引擎升级到了 1.5.4，并且加入了 in-app self-update。这说明项目在认真处理桌面分发和本地执行环境，而不只是做一个 demo UI。

连接器和节点数量很猛，但更值得注意的是“本地优先”这条主线

README 当前给出的能力面板相当大：

  • 300+ 节点；
  • 290+ connectors；
  • 文件、数据库、对象存储、API、消息系统、向量数据库等都覆盖到；
  • 还带 scheduler、MCP server、headless runner 和 build pipeline 能力。

单看这个数字容易觉得有点“全都要”，但我更在意的是它背后的取向没有跑偏。项目一直在强调这些能力是围绕本地工作站展开的：

  • 应用是单文件桌面程序；
  • workspace 存在你自己选的目录里；
  • 数据不会默认上云；
  • 适合用 Git 管工作区；
  • 超出单机规模后，再把输出接去真正可扩展的系统。

这点很重要。因为不少工具会一边标榜 local-first，一边偷偷把关键能力放到云端账户、托管元数据或者闭源后端里。duckle 目前给人的感觉，是想尽量把“先在自己电脑上完成工作”这件事做扎实。

内置 AI 助手不是主角，但放在这里反而合理

我一般对“每个产品都塞 AI 助手”这件事比较警惕，但 duckle 这里的做法至少是连贯的。

README 里说内置助手 Duckie 默认跑在本地，使用 Qwen 2.5 Coder 1.5B 配合 llama.cpp，主要职责是根据自然语言描述生成 pipeline JSON，再一键插入画布。它被刻意限制成只能输出文本，不直接拿文件系统或工具权限。

这就让它更像“本地 pipeline 草图生成器”，而不是一个什么都能碰的 agent。对这种产品来说，这个边界是对的：

  • AI 帮你起草结构；
  • 你再看节点、预览和生成 SQL；
  • 真正执行仍然在本地引擎里完成。

换句话说，AI 在这里不是替代数据流程，而是加速把想法落到可检查的 pipeline 上。

对小团队很实用的一点：它在 GUI 和 CLI 之间留了退路

如果一个桌面工具最后只能靠桌面点按钮，它很难真正进入团队流程。duckle 在这方面给了几个明显的出口：

  • 可以把 pipeline 工作区放进 Git；
  • 有 embedded headless runner；
  • 可以把 pipeline 构建成可在服务器或 CI 上运行的可执行文件；
  • README 里明确提到支持 GitHub 和 GitLab 的 CI / CD 流程。

这意味着它不是把桌面界面和自动化世界切开，而是试图让两边能接上。你可以先在画布上搭流程，再把结果放进审查、构建或定时执行链路里。对很多“分析脚本总是停在个人电脑里”的团队来说，这比单纯多几个连接器更有价值。

当前边界也很清楚，这反而是好事

我比较喜欢这个项目的一点，是它没有装作自己已经覆盖了所有数据平台场景。README 很直白地说：

  • 它是 single-machine, embedded studio；
  • 如果超出一台机器的能力，应该把输出送去 warehouse、object store 或 lakehouse；
  • 它不打算假装自己是集群。

这种边界感对工具项目非常重要。因为真正可用的产品，往往不是“无所不能”，而是清楚知道自己在哪些任务里最顺手。

如果你的场景是：

  • 需要经常整理 CSV、Parquet、SQLite、Postgres 或 API 数据；
  • 希望可视化，但又不想牺牲 SQL 可读性；
  • 希望工作区可以进 Git；
  • 更关心本地执行速度和低部署门槛；

那 duckle 很可能会比一整套重量级数据平台更适合起步。

小结

slothflowlabs/duckle 最值得看的，不是它列出了多少连接器，而是它把几个本来很容易分散的需求收拢到了一个方向里：本地优先、可视化编排、DuckDB 执行、文件化工作区、Git 友好。

它现在还是 beta，但方向已经很明确了。对于那些不想一上来就把数据整理工作推到一整套云平台上，却又不想继续靠零散脚本硬撑的人，这个 stars 还不算高的项目很值得认真看一眼。