Duckle 评测：把 ETL 管线装进单个二进制文件，跑在你自己的服务器上
该项目围绕「Open-source ETL/ELT on DuckDB. Write, wire, or draw one pipeline: 350+ components, 160+ connectors, dbt, CDC, data quality, a Python API, and MCP for AI agents. Runs anywhere, no lock-in.」构建，适用于实际场景的开源实践，提供可复用的工具链与集成方式。
秒懂
- 它是什么？
- Duckle 是一个基于 DuckDB 的开源 ETL 平台，用画布、Python 或 SQL 编写管线，编译为 SQL 后在本机或自建服务器上执行。本文梳理它的架构、运行方式、局限，以及它和 Fivetran、Airbyte 的实质差异。
- 适合谁用？
- Duckle 适合那些不想按行付费、不愿意把管线数据交给第三方云的中小型团队，尤其是已经在用 DuckDB 或 dbt 的用户。它不适合需要分布式执行、多节点弹性扩容或托管 SLA 的场景，README 自己也承认这一点。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 4 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是哪一类问题
Duckle 面向的是不想被托管 ETL 平台按行计费、又不想把管线元数据锁在 SaaS 里的团队。README 里写得很直白：一个开源、免费、单引擎的替代品，用来替代 Fivetran 和 Airbyte 这类按行收费的托管平台。它的核心承诺是「一条管线，一个文件」，你在笔记本上画好或写好的管线，部署到服务器上时不需要重写。每个管线是一个 git 文件，可以 diff、可以 review、可以分支。这解决的是数据工程里一个很实际的痛点：管线逻辑散落在各种平台里，人走了就没人懂。Duckle 把管线变成普通代码文件，至少从形式上解决了可追溯性问题。
画布、Python、SQL 三种写法，最终都编译成 SQL
Duckle 的机制很清晰：你在画布上拖拽 source、transform、validator、sink 节点，连起来，点 Run，它把整个图编译成 SQL，然后在 DuckDB 上执行。每个节点都有实时预览标签页，生成的 SQL 可见，没有隐藏状态。这意味着你看到的画布不是黑盒，每一步都能检查实际执行的语句。除了画布，它还支持用 Python 或 SQL 直接编写管线，三种方式最终都落到同一个编译流程。README 强调「每个节点都有实时预览」，这对调试很有用，尤其是当你从 Postgres 拉数据、做清洗、再写入 Parquet 时，中间每一步的数据形态都能即时看到。
单文件二进制，引擎按需下载
Duckle 的交付形态是一个自包含的二进制文件，大小在 73 到 110 MB 之间，取决于平台。它内嵌了 headless runner 和 MCP server，但 DuckDB 引擎在首次启动时才下载，AI 引擎则是可选的。这意味着你拿到的是一个可以审计的二进制，没有捆绑数据库，没有隐藏的服务。工作区是普通文件，放在你指定的文件夹里。部署方式也很直接：在服务器上运行 duckle-runner serve，它就以 headless 模式按计划执行管线，支持 Docker 或裸机。这个设计对运维友好，因为你不需要维护一个独立的数据库实例来存放管线状态，所有东西都是文件。
内置 AI 助手 Duckie，默认本地运行
Duckle 附带一个叫 Duckie 的 AI 助手，它可以用自然语言描述管线，然后生成 JSON 并放到画布上。关键点是它的默认运行方式：模型在 Duckle 进程内运行，不需要 API key，没有遥测，没有外部请求。如果你不想让它跑在进程内，可以指向自己的 OpenAI 兼容端点。README 强调「你的提示词和数据始终留在你的基础设施内」，这确实是一个隐私上的优势，尤其对处理敏感数据的团队。但要注意，进程内模型的能力可能有限，如果你需要更复杂的推理，换成外部端点会更好，但那又引入了网络依赖。这是一个权衡，不是纯粹的优点。
组件数量与连接器覆盖，但需要核对清单
README 声称有 360 多个组件和 160 多个连接器，覆盖文件、数据库、数据仓库、对象存储、SaaS API、NoSQL、流式 broker、向量数据库，甚至 FTP 和 IMAP。这个数字看起来很诱人，但你要意识到，组件多不等于每个都成熟。README 说「每个组件都有测试覆盖」，但没有给出测试的具体范围。对于实际选型，你需要去查文档里的具体连接器列表，确认你用的 SaaS 服务的认证方式（OAuth、API key 等）是否被支持。另外，Duckle 明确说自己是「单机嵌入式」设计，不是用来替代分布式数据仓库的。如果你需要跨节点并行处理 TB 级数据，这个工具可能不适合。
性能声称：9600 万行导出 39.9 秒，但要看上下文
README 首页给出了一个性能数字：从 Postgres 导出 9600 万行到 Parquet，用时 39.9 秒。这个数字很亮眼，但它没有说明测试的硬件配置、网络带宽、Postgres 版本、是否用了并行连接等条件。它强调的是「用上你给机器的每个核心」，意思是更大的实例会更快。这符合 DuckDB 的列式向量化执行特性，但实际效果取决于你的数据分布和查询复杂度。对于小团队来说，这个性能方向是对的，但不要直接拿这个数字去预估自己的生产环境。你应该在真实数据规模上做一次基准测试，尤其是当你的源数据库和 DuckDB 不在同一台机器上时，网络会成为瓶颈。
版本节奏与维护成本
Duckle 的版本更新比较频繁，最近三次发布是 v0.7.0（2026-08-20）、v0.6.1（2026-08-10）和 v0.6.0（2026-08-08），间隔只有几天到两周。这显示项目处于活跃开发期，但频繁发布也意味着 API 可能不稳定，升级时需要关注 changelog。README 提到了「路线图」和「贡献指南」，但没有详细说明升级兼容性策略。对于采用者来说，你需要考虑维护成本：二进制会更新，DuckDB 引擎也会更新，你的管线文件是纯 JSON，理论上可以 diff，但升级后可能需要重新验证所有节点。许可证是 Apache-2.0，允许商用和修改，但如果你要重新分发修改版，必须保留版权声明。这不是法律建议，但你应该让法务确认。
与 Fivetran、Airbyte 的实质差异
Duckle 把自己定位为 Fivetran 和 Airbyte 的替代品，但差异是结构性的。Fivetran 是托管服务，按行计费，你不需要管基础设施，但数据经过它的云。Airbyte 是开源但通常需要自己部署，它的架构是分布式 worker 模式，支持多种引擎。Duckle 完全不同：它只有一个引擎，就是 DuckDB，运行在单机上。这意味着你没有分布式扩展的能力，但换来了极简的部署。另一个差异是 dbt 集成：Duckle 可以在同一个工具里运行 dbt on DuckDB，这让你不需要单独维护一个 dbt 环境。对于已经在用 DuckDB 的团队，Duckle 可以成为 ingest、transform、load 的统一入口，但对于需要多引擎支持或跨云同步的场景，Airbyte 的连接器生态可能更广。
编辑结论
Duckle 适合那些不想按行付费、不愿意把管线数据交给第三方云的中小型团队，尤其是已经在用 DuckDB 或 dbt 的用户。它不适合需要分布式执行、多节点弹性扩容或托管 SLA 的场景，README 自己也承认这一点。采用前先验证三件事：第一，你的数据源是否在 160 多个连接器列表里，特别是 SaaS API 的认证方式是否匹配；第二，单机 DuckDB 引擎能否承受你的数据量，官方给出的 9600 万行导出用时是在特定硬件上测的，不代表你的机器；第三，Duckle 的 AI 助手 Duckie 默认在进程内运行，如果你要换成外部 OpenAI 兼容端点，确认网络策略允许。最后，检查 Apache-2.0 许可证对你公司内部使用和分发的影响，虽然它允许商用，但如果你要修改后重新分发，需要保留版权声明。
社区笔记