DuckDB 月报：全球建筑扫一遍，只花 2 MB 流量
alitrack约 6 分钟DuckDB 2.0 后天发布。MotherDuck 赶在 10 月 18 日发了 10 月生态通讯，10 条更新里最有意思的是一个 OpenStreetMap 数据集：43 GB 的全球建筑文件，一条 GROUP BY 查询扫完 7.1 亿行，只从网上拉了 2.2 MB。
这个数字我昨天晚上在自己的机器上验了一遍，顺手把整个月的通讯也扒了一遍。
先把结论放这：列式 + 元数据跳过，让「远程查全球级数据集」从下载半天变成几 MB 流量的事——云厂商卖的那种「数据共享要建专线、要走清洗管道」的叙事，在 Parquet 统计信息面前正在失效。
● ● ●
一、OpenStreetMap 变成了一个大 Parquet
openstreetmap.us 的 Layercake 项目把 OSM 数据切成三个主题数据集，每周更新，转成 GeoParquet 放在 Cloudflare 上直接供下载：
（以上是博主 Mark Litwintschik 发文时的数字，我昨晚用 HTTP range 请求只读 footer 复查了一遍：buildings 已经涨到 42.95 GiB、710,454,594 行——这个数据集是活的，每周都在长。）
关键的一条查询：
SELECT COUNT(*), type
FROM read_parquet('https://data.openstreetmap.us/layercake/buildings.parquet')
GROUP BY 2
ORDER BY 1 DESC;
Mark 的机器上，这条查询扫完 6.57 亿行，HTTPFS 统计显示只下载了 2.2 MiB。为什么？三个设计叠加：
- 01空间排序
。数据按地理位置排序存储，同一段 row group 里的建筑都在附近，ZStandard 压缩率大幅提高。 - 02每 12.2 万行一个 row group
，每个 row group 每一列都缓存了 min/max 统计值。我用 pyarrow 远程读 footer 验证过：type 列全部 5782 个 row group 都带 min/max 统计。 - 03bbox 列比 geometry 列小得多
。按 bounding box 过滤时，DuckDB 只需读 bbox 列的统计值就能跳过不相关的 row group，不用碰几何数据本身。
一条查询要在老式行存数据库里完成同样的事，得把 39 GB 全拉下来。这里只拉了 2 MB——剩下的 99.99% 的字节，DuckDB 看了一眼统计值就决定不读了。
国内访问的坑我也踩了：Cloudflare 这个源从国内直连速度大约 0.16 MiB/s，只读 footer 的 28 秒还能忍，跑完整查询等了 8 分钟没出结果，我把进程杀了。Mark 用的是 560 Mbps 的线路，他说下载能跑满。同一个数据集，网络环境决定了它是「3 秒出结果」还是「8 分钟无响应」——但这个限制跟 DuckDB 无关，跟海底光缆有关。
39GB 文件只读 2.2MB 的机制
● ● ●
二、2.0 发布前夜，S3 读取快了 3 倍
后天（10 月 21 日）DuckDB 2.0 正式发布。生态里已经有人提前拿 alpha 版跑生产级测试了。
Matt Martin 在自己的 AWS 账号上做了个对照实验：生成 1 万个小 JSON 文件传上 S3，同一套聚合查询，1.5.6 平均 297.5 秒，2.0 alpha 平均 99.3 秒，快了 66.6%。1 千个文件的规模上是 34.8 秒对 10.6 秒。两边各跑 5 次取平均，脚本开源在 GitHub 上。
数字背后是 2.0 的异步 I/O：读远端文件时线程不再一个个等响应，而是把请求批量发出去。S3 这种高延迟存储上，等待时间本身就是大头。
这个测试我在本机没法复现——需要自己的 AWS 账号和桶。但 MotherDuck 官方此前发过一篇《Why DuckDB 2.0 is faster》，里面 async I/O 在 S3 上 2.4 倍的数字与 Matt 的独立测试对得上。
S3 读取性能对照
● ● ●
三、月报里其余值得记下的
Kelsey Hightower 说 DuckDB 可能是他的 SQLite 替代品。原话是「docs are amazing，内置 web shell 是个好东西，在浏览器里就能玩。This might be my SQLite replacement。」Kubernetes 时代最有影响力的布道者说这句话，分量不轻。
DuckLake 生产的维护姿势。Hoyt Emerson 写了一篇生产维护策略：快照 7 天过期（ducklake_expire_snapshots）、清老文件、删孤儿文件，三步循环。DuckLake 小写入会内联进 catalog，攒多了要 ducklake_flush_inlined_data 挪回 Parquet。这是 DuckLake 进生产后必然要面对的运维清单——湖不止要能查，还要会打扫。
浏览器里查 OneLake。OneLake Studio 用 DuckDB-WASM 加 Azure Entra 委托权限，在浏览器里直接查微软 Fabric 的 OneLake 数据，走 Iceberg REST catalog，后端一个服务器都不用。静态网页 + service worker 缓存（上限 512 MB），查询结果限 20 万行防止浏览器标签页崩掉。
原生 Mac 客户端 Datapuddle。作者 Haris 受够了 Electron 壳，用 Core Text 的 CTLineDraw 在绘制时直接从 DuckDB 列式 chunk 里读单元格，不做行对象转换。4100 万行的 Parquet 文件滚动浏览，内存占用保持平坦。App Store 卖 39.99 美元买断，仅 Apple Silicon。HN 讨论里作者自述开发花了 3-4 个月。
Hannes 的播客。DuckDB 联合创始人上了 Tech on the Rocks，讲了几个老故事：最初想改造 MonetDB，发现可用性需求会渗透进引擎设计，推倒重来损失了约三年；CSV 解析器、免 Hadoop 的 Parquet 读取、SELECT 末尾允许尾逗号，这些「小方便」才是采用率的来源。
● ● ●
这个月我看到的信号
10 条更新里有 4 条在讲同一件事：DuckDB 的边界正在从「你电脑里的分析库」扩张到「任何有 HTTP 的地方」。浏览器里的 WASM 版能查 OneLake，一条 URL 能扫全球建筑数据集，S3 上的万级小文件靠异步 I/O 提速 3 倍。
有意思的是这些都不是 DuckDB 团队做的——Layercake 是 OSM 社区的项目，S3 测试是个人博主管自己的 AWS 账号，OneLake Studio 和 Datapuddle 是独立开发者的产品。引擎方只提供了 read_parquet 一个函数，剩下的是生态自己在长。
后天 2.0 发布，这个系列的下一篇大概率是 2.0 本身。但这个月的月报让我更关心另一件事：异步 I/O、PEG 解析器这些地基打完之后，生态里的人会盖出什么样的房子。
参考来源
- 01
MotherDuck 生态通讯 2026 年 10 月 https://motherduck.com/blog/duckdb-ecosystem-newsletter-october-2026 - 02
Analysis-Ready OpenStreetMap（Mark Litwintschik） https://tech.marksblogg.com/layercake-openstreetmap.html - 03
Layercake 项目 https://openstreetmap.us/our-work/layercake/ - 04
DuckDB 2.0 and S3 File Read Performance（Matt Martin） https://performancede.substack.com/p/duckdb-20-and-s3-file-read-performance - 05
Why DuckDB 2.0 is faster（MotherDuck 官方） https://motherduck.com/blog/why-duckdb-20-is-faster/ - 06
DuckLake in Production: Maintenance Strategy（Hoyt Emerson） https://thefulldatastack.substack.com/p/ducklake-in-production-maintenance - 07
Datapuddle（HN 讨论） https://news.ycombinator.com/item?id=50005515 - 08
Falling Into Databases: The DuckDB Story（Tech on the Rocks 播客） https://techontherocks.show/31
10 月 DuckDB 月报。上面这些里你最想试哪个——浏览器查 OneLake，还是那条 2 MB 扫全球建筑的查询？用 DuckDB 查过公开数据集的话，评论区说说你拉了多少流量。