第1章 认识DuckDB：定位与选型

第1章 认识DuckDB：定位与选型

本章要回答的三个问题：DuckDB 到底是什么，它凭什么在单机上做到数据仓库级别的分析速度？当手里同时有 SQLite、ClickHouse、Polars、Pandas 时，什么时候该选它、什么时候千万别选？以及——那个贯穿全书的交易明细案例，是怎么从这里出发的？

为什么会有这一章

选型错误是数据分析项目里最贵的一种浪费。用错了工具，后面所有优化都是在错误的地基上砌墙：有人给单机报表场景上了整套分布式数仓，维护成本压垮了产出；也有人硬用行式 OLTP 数据库去扫几十亿行的明细表，调了半年参数还是慢。这两类故事的反面，都是"先认清工具的定位，再做技术决策"。

DuckDB 的定位一句话可以说清：嵌入在进程内的分析型（OLAP）数据库。但这句话里的每个词——"嵌入""分析型"——都对应着一整套设计取舍。理解了这些取舍，你就能预判它在什么场景里如鱼得水、在什么场景里捉襟见肘，而不必等到生产事故才明白。本章把这层认知打牢，后面六章的所有机制讨论才有锚点。

读完能解决什么

对照开篇三问，本章交付四样东西。第一，你能用自己的话说清 DuckDB 的设计哲学：为什么它选择单文件、进程内、列式存储、向量化执行这一组组合拳，而不是别的组合。第二，你能完成一次有依据的选型：面对同一个分析任务，判断该交给 DuckDB、SQLite、ClickHouse 还是 Polars，并说出理由和代价。第三，你有一份"反例清单"——五类不适合 DuckDB 的场景，看到它们能直接绕行。第四，主线案例正式登场：一份交易明细 CSV 与一个当天要交的结论，全书剩下的篇幅都在推进它。四样东西里，头两样是"知识"，后两样是"装备"——知识让你说得清，装备让你走得快，本章之后两者都要随身携带。

本章知识点全景

各节怎么分工

四节的推进逻辑是"先立后破"：先建立对设计哲学的理解，再看这套哲学在历史中如何被验证，然后把它放到邻居们中间横向比较，最后用反例把边界标出来。读完这四节，选型问题在你这里应该从"凭感觉"变成"对着清单打勾"。这份确定性还有一个组织层面的价值：团队选型讨论中最耗时的从来不是技术对比，而是"我觉得"对"我觉得"的拉锯——当每个人都在用同一套取舍语言说话时，讨论会自动收敛到场景事实上。本章教的不只是选 DuckDB，更是把选型讨论变成可审计的过程。

先决条件

只需要两样：基本的 SQL 读写能力（会 SELECT、GROUP BY、JOIN 就够），以及在你自己的电脑上装好 Python 或有一个能敲命令行的终端。不需要任何数据库内核知识，不需要用过 SQLite 或 ClickHouse——需要对比的地方，正文会把对方的关键特征一并交代。

本章的读法也有讲究。四节里，1.1 与 1.4 是"决策型"内容，值得精读并留下自己的批注——它们回答的问题会在你每一次新项目启动时重新出现；1.2 是"背景型"内容，快速读过建立时间感即可；1.3 的选型对照表建议收藏，作为以后选型讨论时的共同语言。判断本章学没学好的标准很实际：随机给你一个分析任务和三种工具，你能在五分钟内说出选哪个、为什么、代价是什么，并且让听众信服。

往下走到哪

本章结束时，主线案例会完成第一次"从文件到结论"的快速通过：不做任何优化，先拿到一个粗糙但正确的答案。这个版本会作为后续所有章节的对照组——第2章的排错、第3章的文件格式改造、第4章的查询提速、第7章的最终复盘，都要回到它身上做前后对比。带着这个粗糙版本往下读，你会对每一项改进的价值有更具体的体感。