Dogana：如何信任从其他系统复制的表？

一、Dogana 要解决什么问题

我见过太多这样的场景：从别的系统导出一张表，灌进自己的数据库，然后没有人能说清这些行到底是不是源系统在那个瞬间的全部内容。读方知道答案，写方只看到行。这个信息差我一直在意，直到看到 dogana 这个库。

加载一张表是两件事。一件读源：运行导出、查询或 API 调用，知道得到了什么、在什么瞬间、什么形状、多少行 来源：GitHub 仓库。另一件写表：只看到行。有时是不同的人、系统或供应商，有时是一个脚本。无论哪种，读方知道的东西在行落地后就没有了，除非被写下来。

dogana 让读方把这些信息写进 manifest，让写方在 ledger 里检查并记住 来源：GitHub 仓库。这个设计很朴素，但想得挺深。它不问“这张表对不对”。它问“这张表截至什么时候是对的”。

ledger 为每张表，或每列不变的范围（如订单日期），保存两个日期。complete as of 表示源在那个瞬间的所有行都在这；deletions as of 表示源在那个瞬间之前删除的行已经不在这 来源：GitHub 仓库。周日的全量导出可以证明两个日期，昨天以来变更的行只能证明第一个，因为被删的行不在其中。

二、仓库结构与技术细节

GitHub 仓库 fpiped/dogana 已经有 130 个提交 来源：GitHub 仓库。这个数字不大，但考虑到这是一个个人项目，能攒下这么多提交说明作者一直在推。

目录结构配得挺齐。src/dogana 放源码，tests 放测试，docs 放文档，scripts 放脚本，.github/workflows 放 CI 配置 来源：GitHub 仓库。文档用 MkDocs 构建，mkdocs.yml 在那儿；静态检查用 Vale，.vale.ini 和 .vale/styles/dogana 都在 来源：GitHub 仓库。这不是随手扔上去的实验代码，是当正式项目养的。

CHANGELOG.md 存在，说明作者维护版本历史 来源：GitHub 仓库。还有 AGENTS.md、CONTRIBUTING.md、LICENSE、NOTICE。一个人能把这些都配齐，至少说明他打算长期管这个项目。

三、HN 冷遇与项目活跃度的反差

在 Hacker News 上，这个帖子只有 1 分，0 条评论 来源：HN。1 分意味着只有发帖人自己点了。

一个设计如此完善的协议，在 HN 上几乎没有讨论。README 写“Make messy data integration trustworthy”，让混乱的数据集成变得可信 来源：GitHub 仓库，但 HN 读者似乎没有响应。我猜可能这个领域太冷门，或者问题太具体，大家觉得和自己无关。

HN 的 1 分/0 评论和 GitHub 的 130 个提交放在一起看，这个反差有点意思 来源：HN来源：GitHub 仓库。我的判断是：项目本身有质量，但它的价值要在真正被脏数据折磨过的人那里才能被看见。至于它能不能火，我不确定。

我看了这个仓库，觉得它把一件脏活想清楚了。它不解决“源系统漏了行”的问题。它解决的是“你知道漏了，但说不清漏了多少”的问题。这个边界划得对。

原文：

Dogana: A protocol for trusting tables copied from other systems · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月31日