最近数据工程师圈子里有个项目在悄悄升温：Duckle，一个跑在 DuckDB 上的开源 ETL 工具，3 个月在 GitHub 攒下 1157 颗星，版本从 0 冲到 v0.6.1，主页 slogan 只有五个词——「Pipelines you own」（管道归你自己）。知乎截至 8 月 26 日，星标已进一步涨到 1230+，热度还在爬升。GitHub
这句话不是随便写的，是冲着 Fivetran、Airbyte 这类按行计费的云 ETL 说的，也是冲着刚被"判了死缓"的 Talend 说的。但热闹归热闹，一个只有 3 个月历史、提交记录几乎全来自单个开发者的项目，到底值不值得把你的数据管道交出去？我把能找到的资料、基准数据和风险点都翻了一遍，帮你把这件事拆清楚。
它是什么：画布上拖积木，底下全是 DuckDB 在干活
如果你已经在用 DuckDB，理解 Duckle 只需要一句话：它给 DuckDB 套了一层可视化管道壳。
画布左边是 384 个"积木块"（截至 v0.6.1，366 个可用），把「读 CSV」接上「过滤」「合并」，再接「写 Parquet」，一条管道就搭完了。关键是每个积木都会被翻译成明文 SQL 交给 DuckDB 执行，旁边「Plan」标签页能看到生成的每一句 SQL——没有黑箱。不会写代码就拖拽，程序员可以直接写 SQL 或用 Python API，三种方式的产物是同一个文件，可以互相转换。
还有两个对工程师胃口的设计：一是所有东西就是普通文件（管道是 JSON、配置是 Markdown），直接进 Git，分支、合并、diff 全套标准流程；二是部署时右键「Build Pipeline」，导出一个自包含可执行文件，拷到服务器就能跑，目标机器什么都不用装。
内置的 AI 助手 Duckie 也值得说一句：它完全在本地跑（默认 Qwen2.5-Coder 1.5B，通过 llama.cpp 运行，首次下载约 1.1GB），用大白话描述需求就能生成管道，断网可用，没有 API key，数据不出机器。知乎
为什么是现在：三股力量正好撞在一起
Duckle 出现的时机不是巧合，这是我看资料时最觉得有意思的一点。
第一，Talend 留下了真空。Talend Open Studio 曾是可视化 ETL 的"正规军"，但 2023 年 Qlik 收购 Talend 后，免费开源版在 2024 年 1 月底停更、不再提供任何补丁，据社区整理，商业版 Talend 7.3.1 的延长支持也将在 2026 年底彻底结束。知乎大量团队的现实处境是：管道还在跑，但维护它的工具死了。
第二，DuckDB 刚好成熟了。这个单机分析引擎在 2026 年 8 月初 GitHub 星标突破 4 万。知乎7 月下旬，它刚发布了 1.5.5 版本。DuckDB官网列式存储加向量化执行让它搬数据能快出数量级——Duckle 不需要自己造引擎，站在 DuckDB 肩膀上就有性能底。
第三，本地小模型刚好够用了。1.5B 级别的代码模型在普通 CPU 上就能跑，才有了 Duckie 这种"不出本地"的 AI 助手。这三股力量缺一个，都不会有 Duckle 这个形态。
还有个细节很说明问题：Duckle 作者 Sourav Roy 之前做的工具叫 taldbt，专门用 AI 把老 Talend 作业翻译成 dbt 项目。所以 Duckle 从 v0.6.1 开始内置 Talend 作业导入器不是顺带的功能——这位开发者就是吃"帮人逃离 Talend"这碗饭的。
基准数据很猛，但有三个折扣要打
先看数字。官方给了两个可复现的基准：
第一个，把 2000 万行的 CSV（2.49GB）灌进 DuckDB，Duckle 用 15.69 秒，几乎贴着裸 DuckDB 的极限（约 16 秒）——说明这层壳没给引擎拖后腿。知乎
第二个更硬：从运行中的 PostgreSQL 全量抽 9598 万行（14GB）写成 Parquet，Duckle 用 39.9 秒，同场对比 ingestr 120.8 秒、dlt 493.6 秒、sling 1897 秒。量级差距一眼可见。
但有三个折扣必须打。第一，这是项目自测，不是第三方审计；第二，测试条件不统一——对比里的 Talend 和 Informatica 跑在另一台更弱的 8GB VPS 上，Airbyte 的数字是推算的（官方注明 Airbyte 没有本地 Parquet 目标，没法同场比），各家压缩格式也没对齐（Duckle 用 zstd，其他家用 snappy）；第三，目前社区评价主要来自一篇布道文章和零星 Hacker News 评论，真实生产案例只有"一些创业公司在用"这种模糊说法。知乎
所以我的判断是：数字可信度中等偏上，方向大概率没问题——DuckDB 引擎本身的性能摆在那——但别把具体倍数当圣旨。
谁应该认真考虑，谁应该绕开
先说适合的人。
Talend 存量用户是优先级最高的。v0.6.1 的 Talend 导入器是它现阶段最锋利的卖点：官方实测在一个 44 个真实作业的语料上全部解析成功，216 个节点映射了 211 个；批量模式处理 125 个文件的仓库，42 个作业全部转换成功，加密密码会变成环境变量占位符而不是乱猜。如果你的 Talend 管道还能跑但工具已死，这是目前迁移成本最低的出路之一。
被云 ETL 计费模式劝退的中小团队。Fivetran、Airbyte 按搬运行数持续付费，账单像出租车计价器。数据量在一台机器扛得住的范围内（比如几十到几百 GB 级），Duckle 本地跑、免费、没有按行计费，成本模型完全不同。GitHub
已经在用 DuckDB 的分析师。你手里的 SQL 技能直接复用，管道产物就是文件，和你现有的 Parquet 工作流无缝衔接。
不适合的也很清楚：数据量超过单机上限的（Duckle 明确不做分布式，README 里写着"不假装自己是集群"）；需要多租户云服务的组织；以及"买了软件要厂商负责"的企业采购场景——它没有商业支持兜底。
风险清单：交出去之前先看这三条
第一，也是最该盯的一条：英雄项目风险。1018 次提交几乎全部出自 Sourav Roy 一人。知乎开源 ETL 工具历史上，单维护者项目停滞的例子不少。你托付的不只是工具，还有未来几年的维护预期。
第二，项目太年轻。3 个月、v0.6.1 仍标 beta，API 可能演进，生产环境踩坑要自己扛。
第三，单机天花板是硬边界。数据长到一台机器装不下时，它的价值就断了，到时候还得重新选型。
结论和值得盯的信号
我的整体判断：Duckle 是一个"时代产物"式的聪明项目——方向对、设计诚实（README 明确写了单机边界、基准可复现、为什么选 DuckDB 不选 Spark）、工程底子扎实（双许可、170+ 集成测试）。但它的成熟度还撑不起"无脑迁移"，更适合作为低风险场景的先行试验。
如果你符合上面"适合"的人群，合理的最小路径是：先拿一条非核心管道试跑，重点验证 Talend 导入器或连接器在你的真实数据上是否稳，同时不拆旧管道，留好退路。
接下来值得持续盯三个信号：一是 1.0 正式版什么时候出、API 是否稳定；二是提交者是否从一个人变成一群人（这直接决定项目寿命）；三是有没有第三方基准和公开生产案例出现。这三个信号凑齐之前，它值得关注和试用，但还不值得把身家性命放上去。
顺带一提：Duckle 不是孤例。DuckDB 星标破 4 万的这个夏天，围绕它的工具层正在集体冒头——这本身就是一个信号：本地优先的数据栈，正在从"一个快引擎"长成"一整套生态"。
