一个65MB的桌面App，塞进了290+连接器和一个本地AI

如果你做过数据处理，你一定经历过这个：打开 dbt，写 YAML，配 profile，跑一遍——报错，改配置，再跑——还是报错。一个简单的 CSV 到 PostgreSQL 的同步，你花了一小时配环境，五分钟写 SQL，剩下的时间全在跟工具较劲。

这不是你的问题。现成的数据管道工具，要么是 SaaS（Airbyte Cloud、Fivetran），要付钱、要走网络、数据得先上传到别人的服务器；要么是命令行工具（dbt Core、Meltano），配置繁琐、没有可视化、出了错你得自己盯着日志排查。

Duckle 要打破这个局面。

它把 290+ 数据连接器、一个可视化管道画布、一个本地 AI 助手，全部塞进一个 65MB 的桌面 App 里。不需要服务器，不需要 API Key，不需要 YAML 配置。拖拽、连线、点 Run——管道编译成 SQL，DuckDB 引擎执行，数据全程不离开你的机器。

截至 6 月 19 日，GitHub 551 stars，33 forks，539 次 commits，项目只诞生了一个月。

section header

project stats

● ● ●

一个独狼的野心

你没看错——这几乎是一个人的项目。 Sourav Roy，在 GitHub 上以 SlothFlowLabs 的名义独立开发。不到一个月的时间里，他写出了 14 个 Rust crate、一个 Tauri 桌面壳、一个 React 前端、290+ 个连接器实现。平均每天 18 个 commit。

这种开发强度要么是天才，要么是拼命。考虑到连接器矩阵的覆盖面（从 Kafka 到 Snowflake，从 Salesforce 到 MongoDB，从 Iceberg 到 Telegram），我倾向于两者都是。

section header

● ● ●

Duckle 到底是什么？

一句话概括：Duckle 是 DuckDB 生态的「本地优先」可视化 ETL 画布。

它不是一个 SaaS、不是一个 CLI、不是一个 Python 库。它是一个你双击打开就能用的桌面 App。核心架构分四层：

第一层：可视化管道编辑器。 React 19 实现的拖拽画布，支持 74 种数据源、126 种转换、58 种写入目标、19 种流程控制、12 种数据质量检查。每个节点都能点开看生成的 SQL 和实时预览。

第二层：SQL 编译引擎。 画布上的管道图通过拓扑排序，被 duckdb-engine crate 编译成 SQL，然后交给 DuckDB CLI 执行。不是包装 Python 调用——是直接生成 SQL，你可以看到每一步的查询逻辑。

第三层：本地 AI 助手（Duckie）。 底层跑的是 Qwen 2.5 Coder 1.5B，通过 llama.cpp 运行，约 1.1GB 下载量。完全离线——没有 API Key，没有网络请求，没有数据上传。你用自然语言描述需求（"把这三个 CSV 合并，按日期分组，写入 PostgreSQL"），Duckie 直接生成管道 JSON，一键插入画布。

第四层：Git 友好的工作空间。 所有管道、连接配置、上下文信息全部存为明文 JSON/Markdown 文件。你可以 git diff 一个管道的变更，可以分支出两个版本对比，可以打一个压缩包发给同事——对方打开 Duckle 就能跑。

architecture

● ● ●

290+ 连接器，怎么做到的？

这是 Duckle 最反直觉的地方。一个月，一个人，怎么维护 290+ 连接器？

答案藏在架构里。Duckle 的连接器不是每个都从头写，而是做了分类分层：

• 文件类（CSV、Parquet、JSON、Excel 等）：主要靠 DuckDB 原生的文件读取能力，连接器只做格式检测和参数传递
• 数据库类（PostgreSQL、MySQL、SQLite 等）：通过 DuckDB 的 postgres_scanner、mysql_scanner、sqlite_scanner 扩展——Duckle 负责生成 ATTACH 语句
• 对象存储类（S3、GCS、MinIO 等）：DuckDB 的 httpfs 扩展原生支持，连接器只做认证配置
• SaaS/API 类（Salesforce、Stripe、GitHub 等）：薄包装——调用 REST/GraphQL API，拿到 JSON，丢给 DuckDB 的 read_json 处理
• 流处理类（Kafka、NATS、RabbitMQ 等）：通过专门的流引擎 crate 处理

这种策略意味着：80% 的连接器实际上是 DuckDB 原生能力 + 配置模板，只有约 20% 需要定制代码。 维护成本比你想象的低得多。

但你也要清醒——这种「薄包装」策略决定了 Duckle 的连接器深度有限。它擅长的是「把数据从 A 搬到 B，中间做常规转换」。如果 Salesforce API 有复杂的嵌套分页、需要处理 Webhook 回调、要做增量同步去重，Duckle 的薄包装是不够的。

section header

● ● ●

竞品对比：Duckle 到底在哪个位置？

comparison matrix

Duckle 的独特位置在哪儿？

它卡在了 dbt 和 Airbyte 之间的真空地带。dbt 擅长转换但不管数据抽取，Airbyte 擅长抽取但需要部署服务器。Duckle 用一个 65MB 的桌面 App 同时干了这两件事，还加了个本地 AI——这个组合在现有工具里找不到第二家。

但这不意味着 Duckle 能替代任何一个。Airbyte 有 300+ 人的团队，dbt 有 4000 万美元的融资和完整的治理能力，KNIME 有 20 年的学术积淀。Duckle 是一个快速原型和个人项目的理想工具，但企业级部署？那是一个完全不同的游戏。

section header

● ● ●

三个必须正视的问题

1. Bus Factor = 1。 535/537 个 commits 来自同一个人。如果 Sourav Roy 明天不干了，这个项目就死了。开源社区还没形成——33 个 fork 里，没有看到任何实质性的外部贡献。

2. 只存在了一个月。 Duckle 的第一个 release 是 2026 年 5 月 21 日。它没有经过大规模数据量的验证，没有经历过企业环境的安全审计，没有在生产环境跑过三个月的稳定期测试。v0.4.1 的下载量只有 14 次（不含自动更新）。

3. 连接器的「薄包装」是双刃剑。 大部分数据源只做了基础读写，没有增量同步、没有断点续传、没有 Schema 变更检测。你在实际使用中大概率会遇到「能连上但功能不全」的情况。

4. AI 助手的实用性待验证。 Qwen 2.5 Coder 1.5B 是一个不错的代码模型，但用它来理解自然语言并生成正确的管道 JSON——这个任务对 1.5B 参数来说太重了。复杂的数据管道描述（涉及多表 JOIN、条件分支、时间窗口）大概率会生成错误的配置。

5. 没有协作功能。 工作空间是文件的，但 Duckle 本身是单机 App。没有共享画布，没有权限管理，没有审计日志。Sourav 在 roadmap 里提到了「团队版」，但时间未定。

● ● ●

我为什么还是看好它

尽管有这些问题，Duckle 代表了一个正确的方向。

数据工具的未来是「本地优先」。 过去十年我们习惯了 SaaS 式的数据工具，把数据上传到别人的服务器，等他们处理完再下载回来。但 AI 时代的趋势在逆转——模型在本地跑，数据在本地存，管道在本地执行。Duckle 是第一个把这个理念完整落地到 ETL 领域的产品。

DuckDB 生态需要一个可视化前端。 DuckDB 本身的命令行体验已经很好，但可视化管道编辑器对非工程用户（数据分析师、业务人员、甚至 AI Agent）是刚需。DuckDB Labs 和 MotherDuck 都没做这块，Duckle 恰好补上了。

290+ 连接器的覆盖不是短期能做到的。 即使每个连接器只做薄包装，找到 290+ 个 API 的认证方式、测试基础读写、处理分页和速率限制——这本身就是巨大的工程量。Sourav 做到了，说明他对这个领域的理解很深，执行效率极高。

AI 辅助管道设计是大势所趋。 即使 Qwen 1.5B 现在不够好，但 Duckle 的架构已经把「AI 生成管道 JSON」这条路径打通了。换一个更大的本地模型，或者接入云端 API，这个能力会在 6-12 个月内质变。

section header

● ● ●

谁该关注，谁不用急

值得现在就试试的人：

• 你经常在本地做数据清洗和格式转换
• 你需要快速搭建一个概念验证的数据管道
• 你讨厌写 YAML 配置但需要可视化理解数据流
• 你在用 DuckDB 做数据分析，想要一个更直观的操作界面

可以等等再看的人：

• 你的数据量超过百万行，需要生产级稳定性
• 你需要增量同步、Schema 演进、数据质量监控
• 你的团队需要协作编辑管道
• 你对 AI 生成管道的准确率有较高要求

verdict

Duckle 官网： duckle.org

GitHub： github.com/slothflowlabs/duckle

这篇文章的数据来自 6 月 18-19 日的深度调研，包括 Duckle GitHub 仓库的完整代码阅读、issue/roadmap 分析、竞品对比研究。Duckle v0.4.1 于 6 月 18 日发布，内置 DuckDB 1.5.4、支持 Quack 协议读写、新增代理支持和自更新功能。