GitHub 事件数据质量实测:GH Archive 与 OpenDigger 还可靠吗?
阿里云 MaxCompute 文档里有一个案例:用 GitHub 公共事件数据,给开源数据库做热度和活跃度排名。我想在 Databend Cloud 上用最新数据复现它。
这次我没有手写 SQL:AI Agent Evot 通过 Databend 官方的 databend-cloud skill 操作 Databend Cloud,我用自然语言提要求,建表、导入和检查的 SQL 都由 Evot 生成并执行。
动手前,我让 Evot 先导入一个小时试试:2026 年 10 月 24 日 0 点(UTC)。
GH Archive(按小时归档 GitHub 公共事件的公开数据集)的这个文件里,一条 Push 都没有。换成 OpenDigger 的同名文件,有 288,431 条 Push——但按记录里的 created_at,没有一条属于这个小时,全部是前一天的。
两份数据导入时都是零错误、零重复,问题出在数据本身。这一小时的样本里,有三个会直接影响排名的问题:
- GH Archive 会整类缺失事件:这一小时没有 Push、Create、Delete。
- 归档小时不等于事件时间:OpenDigger 文件中只有 33.47% 的事件属于该小时;GitHub 官方 API 的响应里,也能看到同样的类型错位。
- 关键字段已被 GitHub 官方裁剪:事件里已经没有 commit 数、PR 语言和代码增删。
一句话结论:近期的 GitHub 事件数据适合观察趋势、发现线索,不适合直接做精确统计和排名。
范围说明:结论来自两个来源各一个完整小时文件,加上少量邻近小时和 API 抽查,不是全站长期审计。第 3 点有 GitHub 官方公告;前两点是实测现象,根因尚未完全确定。

Databend 云原生湖仓同时支持私有化和公有云两种部署形态,因此在写入方式上也共提供了4方式种选择。本文一方面通过性能测试认识不同形态的性能差异,另一方面也尝试理解这些设计背后的原因,进而体会如何结合业务场景选择最适合的写入方式。
在 AI 大火的背景下,数据库公司基本都在规划着如何与 AI 结合,也就有了这次活动。我想约一下同行朋友一起交流,看看 Data + AI 或是 AI + Data 这两个方向会碰撞出什么样的结果。本次活动邀请到: