最近在折腾一个叫 DuckDB 的玩意儿，越用越觉得它把"轻量"这件事做到了极致。严格来说以前碰到几千万行的 csv 或 parquet，我第一反应是开 Spark 或者搭 Postgres，光配环境起服务就耗掉大半天。DuckDB 直接 pip install duckdb，就能在 Python 进程里跑标准 SQL，读 parquet、csv 跟喝水一样。它底层是列式存储加向量化执行，官方 benchmark 里对上亿行做聚合能压到秒级，单机表现已逼近 Spark。我拿一份三千多万行的日志试了下 group by，笔记本风扇都没怎么转就出结果了。最顺手的是跟 Pandas 双向打通，查询结果直接变 DataFrame，反过来也能把 DataFrame 丢进去当表查，探索数据比写一串链式 Pandas 直观太多。说白了它就是个嵌在进程里的分析型数据库，没 server、没运维、单文件带着走。当然它只做分析查询，高并发写入那套还得交给别家。中小体量数据的活儿，真心推荐试试，省下的时间够多听两首歌了。

听歌那句把我逗乐了 上周拿它啃两千万行的parquet 一杯咖啡没喝完数就蹦出来了

占个前排嘿嘿

楼主最后那句真戳我 省下时间多听两首歌 我太懂这种爽感了 平时最烦折腾环境 一看到要配这配那就想躺平
笑死服了
几千万行那个我是不敢想 我这老笔记本跑个网页都喘 还是楼主厉害

看到最后那句"省下的时间够多听两首歌了"忍不住点头。我这种人特别吃"不打扰"这一套，工具轻到风扇都不带转的，光想想就觉得省心。平时对付数据我那点法子笨得很，几万行就能让我对着屏幕发呆半天，所以你这种"装好就能跑、扔进去就能查"的描述对我还挺有诱惑力的。btw 你试的是日志类的数据对吧，那种一行行堆起来的确实最考验耐心。等有空我也去 pip 一下，万一真能省出两首歌的时间，四舍五入就是赚到啦。

楼主说的"单机表现已逼近 Spark"这句，我觉得得加个前提才站得住。
其实
DuckDB 官方那组 benchmark 我翻过，对比的其实大多是单节点 local mode 下的 Spark，查询也基本是 TPC-H 那类扫描加聚合。Spark 在 local 模式里照样要扛 JVM 启动、序列化、任务调度那套分布式框架的开销，单机跑本来就不是它的强项，DuckDB 赢在把这些 overhead 全省了。可一旦数据超出单机内存、需要真正铺到几十个节点的集群，两者的可比性就断了——DuckDB 没有分布式这一层，它解决的是"我笔记本上就能跑完"，Spark 解决的是"一台机器装不下"，定位根本不是一回事，拿单节点成绩去暗示能替掉 Spark 多少有点偷换维度。

更想补的是"上亿行聚合压到秒级"这个数字。它隐含了一个关键前提：工作集能进内存。DuckDB 列式加向量化没错，可内存放不下、得 spill 到磁盘时，延迟会明显抬起来。我之前拿一份两千多万行的导出行做 group by，数据能全驻留内存时确实快得离谱，风扇纹丝不动；另一次把可用内存压到只够装一部分，同样的操作慢了好几个数量级，和官方曲线完全两个故事。所以"秒级"更像内存充足这一特定条件下的结论，当普遍预期容易翻车。

Pandas 互转那块同意，体感就是直观。不过补一句：结果集特别大时，从 DuckDB 转回 DataFrame 这一步本身吃内存和 CPU，真到那个量级不如直接落盘成 parquet 再交给别的工具，全搬进 pandas 反而成了瓶颈。

中小体量、单机探索，它确实是近几年最舒服的工具之一。你们有拿它和 Polars 比过吗，那个也是 Arrow 内存模型、Rust 实现，想知道纯内存场景下谁更狠。

"把数据库装进笔记本"这个标题本身就够动人了。我停在"风扇都没怎么转就出结果了"那句上，心里浮起一种很私人的安心。在我们这个被工具环伺的时代，太多东西一上手就要你搭地基、起服务、配环境，仿佛不把日子过成一场运维就不算正经。DuckDB 的难得，倒不在它快，而在它不索取。没有 server 要养，没有进程在后台常年亮着灯等你负责，用完即散，像一位只在你泡茶时来坐坐的旧友，那种気持ちいい的轻松。

作者写"高并发写入那套还得交给别家"，我反而觉得是全篇最体面的一笔。多数软件拼命想成为一切，它却老实画了条边界，承认自己不是神。这种清醒的"不贪"，在如今什么都讲上云、讲分布式、讲 scale 的风气里，竟有几分逆流的温柔。

说到底，轻量真正动人的，也许不是那些指标，而是最后那句"省下的时间够多听两首歌了"

读到你写"风扇都没怎么转"那一句，心里忽然很静。如今不少工具都爱摆场面，仿佛不拉起集群、不亮起一排指示灯就算不上在做事；DuckDB 偏是反着来，闷声把活儿干完，像有人替你把灯熄了，只留窗外一点月色。

你说的"省下的时间多听两首歌"，倒叫我点头。轻的东西才经得起日日相见，重的再好，处久了也是负担。

你试的那份日志宽不宽？话说回来我有点好奇它在列很多的表上，是不是也这般从容。

三千多万行的日志风扇都不带转的，听着就让人松口气。你最后说省下时间多听两首歌，是呢，能把麻烦事变简单，剩下的功夫拿来发呆都开心。回头我也想装来试试看。

顺手记一个细节：你说"单机表现已逼近 Spark"，这个判断得加限定条件。DuckDB 自家 benchmark 对标的是单机单节点的 Spark，而且通常是默认配置、没做调优；真要跟分布式集群比横向扩展能力，它再快也拼不过多节点。从某种角度看，它本就不是要解决同一个问题——是在"不想配环境、不想起服务"这个场景里把单机分析压榨到极致。

我前阵子拿一份两千多万行的 parquet 做 group by，确实几秒出结果，但当时维度基数低；后来换成高基数聚合，耗时就不止一个量级了。楼主那个三千万行日志是 group by 哪个字段、基数大概多少？这点对"风扇没怎么转"的参考性影响其实挺大的。

关于你说的"单机表现已逼近 Spark"这点，我倒觉得值得商榷。DuckDB 和 Spark 其实不是在跑同一场比赛，前者是单进程、单机的嵌入式引擎，后者是分布式框架。在单机内存能装下的数据量上，DuckDB 往往不是"逼近"Spark，而是直接把本地 Spark 甩开，因为它根本不用承担分布式的协调开销，任务调度、shuffle、网络传输那一套全省了。我之前给一份大概两千万行的订单数据做聚合，本地 Spark 起 JVM 光预热就几十秒，DuckDB 冷启动几秒就出结果。

反过来，一旦数据量超出单机内存、或者你本来就需要横向扩到几十台机器，那 Spark 的分布式能力就是 DuckDB 给不了的。所以更准确的说法大概是：嵌入式、单机场景下 DuckDB 比 Spark 轻且快，二者不是谁逼近谁，而是适用范围根本不同。

补一个小细节，你说的"单文件带着走"默认是内存模式，要落盘持久化得显式连一个 .duckdb 文件，这点对新手稍微有点隐蔽。

补充一个容易被忽略的点：它读远程 parquet 不用先把文件拽下来，SELECT ... FROM 'https://xxx/big.parquet' 直接走 HTTP range 拉需要的列和行，再配合 S3 上的 Hive 分区目录做裁剪，几亿行的冷数据也能在本地现查现算。

我自己拿它理过两万多张 Raw 的 EXIF 元数据，group by 镜头型号和光圈区间几秒出结果，比手写 pandas 循环省事太多。

单写多读的限制得记牢，要多人同时写就换别的。另外官方 benchmark 是理想列，宽表加字符串字段多的时候内存占用别太低估。

顺带提一句，"逼近 Spark"得加个单机前提。Spark 的看家本领是横向扩展，真到集群规模二者就不是一个量级了。你那三千万行日志的体验倒是扎实。

鸭子db这名儿先乐一下 我前阵子也被几千万行csv折磨得够呛 eigentlich都准备老老实实搭postgres了 结果同事甩来句pip install就完事 省下那点功夫我真去听了首勃拉姆斯 楼主"多听两首歌"那句太戳我 回头也拿三千万行日志试下group by 顺便看看风扇转不转