DuckDB 为什么火？单机 OLAP 什么时候比集群更合适？
面试怎么回答
DuckDB 是嵌入式的分析型数据库，没有服务端，嵌在 Python 或命令行里就能用，列式存储加向量化执行，能直接查 S3 上的 Parquet、CSV，也能读 Iceberg 表。它火是因为单机硬件够强，而公司里大量分析任务数据量其实只有几 GB 到几十 GB，为此申请集群、等调度反而更慢。我会把它用在数据探查、数仓 SQL 的本地和 CI 测试、小表的轻量 ETL 和文件格式转换上。数据量超出单机、高并发多用户写、需要权限和资源隔离的平台场景，还是用 Spark 或 Doris、StarRocks 这类集群。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这两年 DuckDB 在数据圈很火，有人叫它「分析界的 SQLite」。面试官问这个，不是要你背功能，而是看你有没有「不是所有数据都需要上集群」的判断力。
DuckDB 是什么
DuckDB 是一个嵌入式的分析型数据库：
- 没有服务端，就是一个库，嵌在 Python、Java、命令行里直接用，
pip install duckdb就能跑； - 列式存储 + 向量化执行，一次处理一批数据，充分利用 CPU 缓存和多核；
- 直接查文件：Parquet、CSV、JSON 不用导入，
SELECT * FROM 's3://bucket/path/*.parquet'就能查，也能读 Iceberg、Delta 表； - 和 Pandas、Arrow 之间几乎零拷贝互转。
为什么火
- 单机能力变强了：一台普通服务器几十核、几百 GB 内存很常见，加上 NVMe 盘，几十 GB 甚至上百 GB 的数据单机几秒到几十秒就能扫完；
- 很多数据其实不大：公司里大量分析任务处理的是一个分区、一张维表、一份导出文件，为它申请 Spark 资源、等调度，比算本身还慢；
- 零运维：不用部署集群、不用排队，开发调试和临时分析效率高很多。
典型用法
- 数据探查和临时分析：直接查数据湖里的 Parquet，看分布、查问题；
- SQL 的本地测试：在 CI 里用 DuckDB 跑数仓 SQL 的单元测试，造几行数据验证逻辑；
- 轻量 ETL：小表的清洗转换、文件格式转换（CSV 转 Parquet）；
- 嵌入到应用里：给报表服务、数据产品做本地计算引擎。
什么时候不适合
- 数据量超过单机能力，或者需要多台机器并行的大作业，还是 Spark、Doris、StarRocks；
- 高并发、多用户同时写的场景：DuckDB 同一时间只适合一个进程写，不是拿来当线上服务数据库的；
- 需要权限管理、资源隔离、多租户的企业级分析平台。