跑在你自己 GCP 项目里的无服务器 DuckDB
来源:dev.to — 2026-10-15
📋 概述
作者喜欢 DuckDB 的简单:在笔记本上嚼得动几十 GB 的 Parquet,不要集群、不要仓库、不要常驻服务;但数据搬进 GCS 涨到 100 GB 之后,笔记本就不是选项了,而现实里的选择只剩 BigQuery 或者一台需要人挑规格、启动、盯着、记得关掉的 VM。他想要的东西说起来很简单:在数据旁边、在一台足够大的机器上跑这个 SQL 文件,然后给我结果和这几分钟的账单——这就是 DuckLess。它只在你的项目里创建一台 VM,启动 DuckDB、跑文件、把指标与最后一个结果写在作业旁边,然后删掉 VM;作业 VM 没有外部 IP,通过 Private Google Access 访问 GCS 与镜像仓库。他拿 TPC-H scale factor 100(35.6 GB Parquet、6 亿行 lineitem)做了对照:DuckLess 用 n2-highmem-32 Spot 跑 47 秒加 58 秒启动,约 0.02 到 0.08 美元一次;BigQuery 按需用外部表 59 秒、1.78 美元,原生表 39 秒、1.53 美元。
🔑 核心要点
- 最核心的设计约束:一切都跑在你的 GCP 项目里,你和数据之间没有 DuckLess 的服务,账单来自 Google 而不是作者。
- 成本对比:DuckLess 每次约 0.02–0.08 美元,BigQuery 按需用外部表要 1.78 美元,但 BigQuery 在延迟上更好。
- 内存压力只会拖慢而不是弄坏作业:把 DuckDB 限制在 7 GB 而非 205 GB,同样查询从 47 秒变成 133 秒,靠本地 SSD 溢出。
- 写 Parquet 到 GCS 的默认方式很慢:单写者无论机器多大都卡在约 110 MB/s,换成 PER_THREAD_OUTPUT 后在 32 vCPU 上跑到 900 MB/s。
- 读一个大文件也有同样的问题:12 GB 的 CSV 只有约 90 MB/s,先用 64 路并行拷到本地 SSD,加载从两分多钟变成 15 秒。
💡 金句
我想要的其实很简单:在数据旁边跑这个 SQL 文件,在一台足够大的机器上,然后给我结果和它花掉的那几分钟的账单。
👍 0
👎 0
← 返回 dev.to 首页