hugues31/duckpad

如果你已经在用 DuckDB，并且想要给流水线加上血缘追溯和 Git 评审，值得看看；如果需要跨平台执行 SQL 或成熟生态，不妨再等等。

解决什么问题

你想把散落的 CSV、数据库表和中间查询整理成一条流水线，并且能解释最终数字是怎么来的。现在常见做法是一串 SQL 脚本、一个 notebook 再加一张电子表格，从最终收入数字倒推到产生它的那一行，只能靠手工排查。Duckpad 改的是这一步：数据源、连接和可复用组件变成节点，点击结果单元格就能看到参与计算的来源值。最终你得到的是既能当图看、又能当 SQL 看的流水线。

有什么不同

核心机制是把血缘和 SQL 执行绑定在一起，而不是事后补一层文档。README 单独链接了一份血缘覆盖说明，这意味着项目把“哪些结果能追溯”当作可度量的问题，而不是一概承诺全覆盖。实际好处很具体：两个人对某个数字有分歧时，可视化图和单元格级追溯能给出一个起点。

编写方式有两种。引导式表单让你不必全部手写 SQL 就能配置连接和连接操作，集成编辑器则允许在表单不够用时直接写 SQL。版本管理也带有明确主张：项目保存到 Git，可以开分支、可视化比较改动，并在应用合并前先评审。对工程师来说这很熟悉，对只想存个文件的分析师来说则是额外的流程负担。

主要取舍是环境约束。SQL 执行需要启用 Landlock 的 Linux，也就是说这个工作区围绕 Linux 部署设计，而不是先在其他系统上跑笔记本。可视化编排、血缘和 Git 评审本身也是一种特定的工作流选择；已经有成熟 dbt 式转换流程的团队，可能从可视化这一层得到的东西不多。

谁值得试

适合在 Linux 上、用 DuckDB 做本地或部门级分析的小型数据团队，希望有一个共享的地方来搭建流水线、查看血缘和管理版本，而不必自己拼几个工具。也适合想先看清流水线形状、再进入 SQL 细节的人。

不适合在 macOS 或 Windows 上、只想要一个快速本地查询客户端的个人分析师，也不适合需要把 SQL 执行放在开发者笔记本上的团队。Linux 要求让首次运行的环境选择变得很关键。如果团队已有基于 Git 的转换流程，应该先确认可视化合并评审带来的价值是否足以再引入一个工作区。

使用条件与边界

你需要 Python 3.11+ 和 Git；安装包已经包含界面，Node.js 只用于开发。更硬的约束是 SQL 执行：需要 Linux 且支持 Landlock ABI 2+，README 说明为 Linux 5.19+ 并启用 Landlock。安装本身不难，真正跑查询取决于这个内核能力是否可用。在让团队采用之前，先看安装与账户说明和快速上手。

运维方面，首次运行会从终端创建管理员登录；团队使用意味着管理项目权限和按环境配置的连接，单点登录另有文档。Git 项目要求团队理解分支和合并评审，而不只是会写 SQL。除此之外，README 主要是功能概览，没有详细说明性能特征、数据规模上限或连接器覆盖范围。项目也没有描述在非 Linux 系统上执行 SQL 的方式，因此应把它当作尚未解决的环境问题，而不是可移植性承诺。

HotRepo 点评

记录的快照显示，仓库当时只有 2 天，曾出现在 TypeScript 新项目榜第 12 名，共 267 颗星，观察日期为 2026-10-27。这只是一次带日期的榜单记录，不是每日增长序列，暂时无法判断热度能否持续。投入之前，先核对 Linux/Landlock 要求是否符合你的实际部署环境，并在连接器文档中确认你需要的连接器支持。