企业官网建设流程全解析

先交代一个背景。做数据分析的人应该都有类似的经历：别人丢给你一个几个GB的Parquet目录，让你统计一下各维度指标；你把文件读进来，Pandas直接内存爆炸，或者卡到怀疑人生。你开始犹豫要不要拉个Spark集群，但就为了算个汇总，搭建集群的成本和精力又实在划不来。这个场景，就是DuckDB最适合解决的问题。

DuckDB是一个嵌入式OLAP分析型数据库，核心卖点就是列式存储、向量化执行引擎，外加一个非常夸张的“直接查询Parquet文件”的能力。它的定位并不是替代你现有的数据仓库，而是充当本地分析的高速计算引擎——没有独立服务，没有网络端口，就像SQLite一样跟着你的应用走，却拥有数仓级别的查询性能。这篇文章我会把DuckDB的底层原理、实操用法、性能调参和避坑经验一次讲清楚，适合正在用Pandas处理中大型数据、想用SQL做本地分析、以及需要轻量级数仓方案的开发者参考。

1. 为什么需要用DuckDB：你的数据工作流缺了哪一环

1.1 从一次卡死的分析任务说起

我先讲一个真实经历。有次业务方给了我一组用户行为日志，大概有30多个Parquet文件，加起来6GB左右，字段有80多列。我最初的方案是用Pandas做：pd.read_parquet("data/*.parquet")，结果程序直接卡死——内存占用瞬间冲到20多GB，因为Pandas读取Parquet时先要还原成完整的DataFrame，还要做类型推断、索引对齐，内存开销往往是文件大小的好几倍。

换成DuckDB之后，一行SQL查询直接扫文件目录：

SELECT channel, COUNT(*), AVG(duration) FROM 'data/*.parquet' GROUP BY channel;

整个过程只有几条执行日志，跑了几秒就返回结果。这背后就是DuckDB的杀手锏：它不把数据完整加载进内存，而是基于列式存储的统计信息做扫描，过滤掉用不到的列，只读取查询涉及的那部分数据。

这给我最大的触动是：数仓其实离我们很近，不一定非要Spark，不一定非要集群。

1.2 DuckDB与SQLite、Pandas的定位差异

很多人第一次听到“嵌入式数据库”，第一反应是SQLite。两者架构上确实类似——都是库文件随应用走，零配置零运维。但SQLite是行式存储OLTP数据库，擅长单行高频读写，而DuckDB是列式存储OLAP数据库，擅长大批量扫描和聚合分析。你让SQLite跑一个几十亿行的GROUP BY，它会很难受；你让DuckDB跑高并发单行更新，它也一样不合适。

DuckDB更合适的对标其实是Pandas + 本地分析。Pandas用内存里的DataFrame做操作，所有数据必须先“住”进内存；DuckDB则靠外部存储和向量化执行引擎，处理的体量轻松上一个台阶。更关键的是，DuckDB和Pandas不是竞争关系，而是互补关系——查出来的小结果集可以直接转成DataFrame继续做可视化、机器学习，两边配合非常顺手。

所以我的判断很明确：如果你的分析任务超过“Pandas能舒服处理”的量级，但又没到“必须上Spark”的程度，DuckDB就是中间那块最顺手的拼图。

2. 核心能力解析：列式存储、向量化与直接查Parquet

2.1 列式存储：为什么扫描Parquet特别快

DuckDB的存储和计算核心是列式的。所谓列式存储，就是把同一列的数据连续存放，而不是像行式数据库那样把整行数据放在一起。这两种布局对查询性能的影响是巨大的。

假设一张表有80个字段，你要算某个字段的AVG。行式存储会把这80个字段的整行数据都读进内存，哪怕你只关心1列；列式存储则只需要读取需要的1列数据块，I/O量直接缩小到原来的1/80。这就是为什么DuckDB查询Parquet文件时能“快得离谱”——Parquet本身就是列式格式，DuckDB把Parquet的列数据映射到自己的列式执行引擎上，天然契合。

另外Parquet文件在每个列块（Column Chunk）里都记录了min/max统计信息。DuckDB做过滤时，先看统计信息是否满足条件，如果不满足，整个数据块直接跳过，连解压都不用。比如时间范围过滤WHERE date >= '2024-01-01'，如果某个Parquet文件的时间范围全在2023年，这个文件在扫描阶段就被剪枝掉了，实际读取的数据量可能只有原始大小的10%甚至更少。

这就是“元数据驱动查询”的威力。用好这个特性，你甚至不需要对Parquet做任何分区规划，DuckDB自动帮你做了文件级别的裁剪。

2.2 向量化执行引擎：一次处理一批数据而不是一行

列式存储解决了I/O问题，向量化执行引擎解决的是CPU效率问题。

传统数据库的火山模型是一行一行地处理，每处理一行都要经历一次函数调用、类型判断、表达式计算，CPU的有效计算占比很低，大量时间耗在解析调度上。DuckDB采用了向量化的批处理模式：每次从扫描节点取出一个Batch，通常包含2048行数据，然后这一批数据在CPU的寄存器、缓存中流水线式计算，连续做过滤、聚合、投影，不再逐行跳转。

这种设计带来的好处是巨大的。你可以理解为：普通数据库在“一个一个搬砖”，向量化数据库在“用托盘批量搬砖”。对于大数据量的聚合计算，批量操作可以利用CPU的SIMD指令集（现代CPU的并行计算指令），进一步加速。这也是为什么DuckDB在TPC-H这种分析型基准测试中，单机性能能超过很多分布式数仓。

DuckDB的向量化不仅作用于Parquet扫描，它的整个执行管道——包括JOIN、GROUP BY、ORDER BY、窗口函数——全部是向量化实现的。这意味着你写的SQL越复杂，涉及的计算量越大，向量化的优势就越明显。

2.3 嵌入式架构：不用装服务的“数据库”到底怎么运行

DuckDB“嵌入式”的含义，是它作为一个库被加载进你的应用程序进程，不需要独立的数据库服务进程，不需要监听端口，不需要账号密码配置。

DuckDB的底层是基于C++实现的，官方提供了Python、R、Java、Node.js、Go等生态的语言绑定。你用Python调用DuckDB，本质上DuckDB运行在你的Python进程内部，数据直接在进程内流转，省掉了网络传输的开销。对比传统数仓或Spark，每一次查询都要经过“客户端->网络->服务端”的完整链路，DuckDB的本地零拷贝能力有着天然优势。

嵌入式架构还带来一个额外好处：部署简单。你在本地调试好的分析流程，放到服务器上，只需要装一个Python包或者拷贝一个可执行文件就能跑。没有依赖冲突，没有版本协调，不占额外资源。生产环境定时跑批任务，用DuckDB非常省心。

3. 实操：把DuckDB用起来（从安装到查询）

3.1 环境安装与基础连接

DuckDB的安装是我见过所有数据库中最简单的，没有之一。Python环境直接pip安装：

pip install duckdb

装完之后，在Python里创建连接（不需要指定路径的话，使用内存模式）：

import duckdb # 内存模式 conn = duckdb.connect() # 文件模式（持久化数据库文件） conn = duckdb.connect("my_analytics.db")

内存模式适合做临时查询，关掉连接数据就没了；文件模式会把数据Meta信息写到本地文件里，下次直接取用。

第一次用DuckDB的人可能会疑惑：既然是嵌入式数据库，为什么还要connect()？其实DuckDB的连接本质上就是启动一个数据库实例。文件模式创建的my_analytics.db，如果你在里面创建了表、视图、加载了扩展，这些对象定义都会被持久化，下次连接时可以直接复用，数据文件不丢失。

命令行方面，DuckDB也提供了一个CLI工具：

duckdb my_analytics.db

进去之后就是标准的SQL环境。CLI适合快速验证SQL语法，Python API适合嵌进实际脚本里跑批。

3.2 直接查询Parquet文件：单文件、多文件、分区目录

DuckDB最爽的功能，就是不用导入数据，直接对文件系统里的Parquet做SQL查询。先看单文件查询：

SELECT * FROM 'data/orders.parquet';

这个SQL直接扫描文件，不需要CREATE TABLE，不需要LOAD DATA，不需要告诉你文件在哪个库、哪个Schema。你可以把它当做一个“瞬时的表”——文件路径就是表名。

多文件查询用通配符：

SELECT * FROM 'data/orders_*.parquet' WHERE order_date >= DATE '2025-01-01';

通配符会匹配同目录下所有符合模式的文件。DuckDB会并行读取多个文件，并在查询层自动合并结果。

如果是按照年月组织的目录结构：

data/ 2025/ 01/ part-00001.parquet part-00002.parquet 02/ part-00001.parquet 2024/ 12/ part-00001.parquet

也可以用目录级别的通配符：

SELECT * FROM 'data/*/*/*.parquet' WHERE category = 'electronics';

这种按分区目录存储的Parquet文件，配合DuckDB的文件裁剪机制，查询时可以精确跳过无关目录。需要注意，DuckDB对Parquet的目录分区做得比较聪明，但如果你希望查询时自动获得分区列（比如从目录路径中自动识别出2025/01这种字段），最好还是显式创建视图或表，把路径字段抽出来。

更高级的用法是用read_parquet函数，它可以传递更多参数：

SELECT * FROM read_parquet( ['data/2025/01/*.parquet', 'data/2025/02/*.parquet'], hive_partitioning = true, union_by_name = true );

hive_partitioning = true表示自动识别Hive风格的分区目录（如year=2025/month=01/这种格式），并把分区字段自动映射成查询列；union_by_name = true表示如果多个文件的Schema有差异，按列名并集合并而不是严格对齐位置。这两个参数在实际数据湖环境中非常实用，强烈建议记下来。

除了SELECT，DuckDB也支持把查询结果写回Parquet：

COPY ( SELECT category, SUM(amount) AS total_amount FROM 'data/orders_*.parquet' GROUP BY category ) TO 'data/summary.parquet' (FORMAT PARQUET);

这样一整套“读Parquet->计算->写Parquet”的流程就闭环了。你可以把DuckDB理解成一个高性能的Parquet计算引擎，用来做ETL、数据清洗、指标汇总都非常顺手。

3.3 与Python生态互操作：Pandas、Arrow、Jupyter

DuckDB不会让你离开Python生态。它在Python里和Pandas、PyArrow、NumPy之间都有高效的互操作接口。

从Pandas的DataFrame注册成DuckDB表，有两种方式。第一种是直接在SQL中引用DataFrame变量名：

import pandas as pd df = pd.read_csv("sales_data.csv", nrows=10000) result = conn.execute("SELECT region, SUM(revenue) FROM df GROUP BY region").fetchdf()

DuckDB会自动识别df这个Python变量是Pandas DataFrame，直接在查询中把它当作表来引用。整个转换过程是零拷贝的，不需要先把数据灌进DuckDB内部存储。

第二种是注册成视图，方便多次复用：

conn.register("sales_view", df) result = conn.execute("SELECT * FROM sales_view WHERE revenue > 1000").fetchdf()

反过来，DuckDB的查询结果可以取回成Pandas DataFrame：

result_df = conn.execute("SELECT region, COUNT(*) FROM 'data/sales/*.parquet' GROUP BY region").fetchdf()

DuckDB的结果集还可以直接转换为Arrow Table：

arrow_table = conn.execute("SELECT * FROM 'data/sales/*.parquet'").fetch_arrow_table()

Arrow Table对于机器学习场景尤其友好，可以直接对接XGBoost、LightGBM、PyTorch的DataLoader。而且Arrow的内存格式本身就是列式的、零拷贝的，转换开销极低。

在Jupyter Notebook里，DuckDB还提供了一个魔术命令%sql，可以把查询结果直接渲染成表格：

pip install duckdb jupysql

%load_ext sql %sql duckdb:///:memory: %%sql SELECT category, COUNT(*) AS cnt FROM 'data/orders_*.parquet' GROUP BY category ORDER BY cnt DESC;

体验非常接近在数据库客户端里写查询，但数据源是本地文件，不需要建表、不需要导数据。

3.4 创建本地表与常规数据操作

虽然DuckDB的直接查文件能力很香，但当你需要反复查询同一批数据、或者需要做多表关联时，还是建议先把数据加载成库内的表。因为重复扫描外部Parquet文件，每次都要做文件解析和Schema推断，即便有缓存，也会有一定额外开销。加载为表之后，查询性能会有明显提升。

CREATE OR REPLACE TABLE sales AS SELECT * FROM 'data/sales_*.parquet'; -- 或者使用 INSERT 方式增量加载 CREATE TABLE sales (id INTEGER, region VARCHAR, revenue DOUBLE); INSERT INTO sales SELECT * FROM 'data/sales_2025.parquet';

DuckDB支持标准的SQL：SELECT、JOIN、WHERE、GROUP BY、HAVING、ORDER BY、窗口函数、子查询、CTE全都有。甚至还有PIVOT、UNPIVOT、QUALIFY这类分析型语法，和主流数仓的使用体验基本一致。

一个比较特色的功能是DESCRIBE和SUMMARIZE：

-- 查看Schema DESCRIBE SELECT * FROM 'data/orders.parquet'; -- 查看每一列的类型、唯一值数量、min/max、直方图等统计信息 SUMMARIZE SELECT * FROM 'data/orders.parquet';

这些元信息在数据探索阶段非常实用，能帮你快速了解一个陌生Parquet文件的“脾气”。

4. 性能调优与资源控制：别让内存成为瓶颈

4.1 设置内存上限与临时磁盘

DuckDB是内存数据库架构，虽然向量化执行引擎很高效，但如果查询的数据量远超内存容量，还是会遇到内存问题。DuckDB的默认内存限制是物理内存的80%，在实际任务中，如果数据量达到几个GB或者几十个GB，一旦聚合的中间结果集巨大，很可能触发内存溢出。

好在DuckDB允许我们显式设置内存上限和临时磁盘目录。当内存不足时，DuckDB会把中间结果溢写（Spill）到磁盘，而不是直接报错崩溃。

-- 设置内存限制为8GB SET memory_limit = '8GB'; -- 设置临时磁盘目录 SET temp_directory = '/tmp/duckdb_spill';

在Python API里对应为：

conn.execute("SET memory_limit = '8GB'") conn.execute("SET temp_directory = '/tmp/duckdb_spill'")

需要说明的是，memory_limit是DuckDB执行引擎的预算上限，包含所有查询算子（Hash Join、聚合、排序等）的内存占用。设置偏低会导致频繁Spill到磁盘，性能明显下降；设置太高，又可能影响同一进程内Pandas等其他库的内存使用。一般建议设置在物理内存的50%到70%之间，预留一部分给操作系统和应用本身。我自己的习惯是机器内存16GB就设8GB，32GB内存就设16GB，尽量不要让DuckDB把内存全吃光。

4.2 控制并行度与线程数

DuckDB是多线程并行执行架构，它会自动利用机器的多核CPU。默认线程数等于CPU逻辑核心数，但有些场景不一定越大越好。

在小文件特别多的情况下（比如几千个很小的Parquet文件），高并发线程数会导致频繁的文件打开/关闭、元数据解析调度，反而带来大量额外开销。此时限制线程数反而更快：

SET threads = 4;

如果单个查询涉及非常重的计算，核心数多则有利。实践中可以通过EXPLAIN ANALYZE查看查询计划中的算子耗时，动态调整线程数找到最优值。

另一个容易被忽略的点是：DuckDB的并行度是查询级别的，不是并发会话级别的。它更适合同时跑一个复杂查询，而不是多个请求同时高并发访问。如果你需要多人同时在线查询，这不是DuckDB的设计目标，还是应该上正式的数据库或数仓。

4.3 善用元数据过滤与列裁剪

前面提到Parquet自带min/max统计信息，DuckDB查询时自动做文件和数据块的裁剪。但这个机制要生效，需要满足几个条件。

第一个是过滤条件要能下推。看个对比示例：

-- 高效写法：过滤条件直接下推到扫描层 SELECT * FROM 'data/orders.parquet' WHERE order_date >= DATE '2025-01-01'; -- 低效写法：先全部读出来再过滤 SELECT * FROM ( SELECT * FROM 'data/orders.parquet' ) t WHERE order_date >= DATE '2025-01-01';

第一种写法，DuckDB会在扫描Parquet时就应用谓词，数据块裁剪生效；第二种写法，谓词在查询计划的上层执行，无法利用文件统计信息做裁剪。你在子查询里明明可以写过滤条件，就别把一个巨大的中间结果集搜出来再说。

第二个是尽量投影需要的列，而不是用SELECT *。DuckDB查Parquet时，会根据查询计划中实际引用的列，只读取对应的列块。比如一个80列的文件，你只需要3列，SELECT *会把全部80列都扫描进来，哪怕不做计算，解压和类型转换的开销都在。用显式列名或必要的列组合，扫描的数据量会大幅降低。

第三个是善用EXPLAIN看裁剪效果。在SQL前加上EXPLAIN，可以看到查询计划的扫描节点，能读出多少字节、读取了多少文件。如果Filter节点在ParquetScan节点之上，说明谓词没有完全下推，需要调整SQL写法。

4.4 压缩格式与文件大小对性能的影响

Parquet内部的压缩算法也会影响查询速度。常见的组合有Snappy、Zstd、Gzip。从压缩率和解压速度看，Zstd是很好的平衡点，DuckDB对Zstd支持非常成熟。如果是生产环境新增Parquet文件，建议优先考虑Zstd压缩，既能节省存储空间，解压性能也不错。

还有个细节：Parquet文件太小太碎（小于128MB的单文件），性能往往不好，因为每个文件都要经历打开、读取Footer（元数据尾部）、扫描列块的过程，文件数过多时这类开销非常明显。反过来，单个文件太大（超过2GB）也不是不行，但从HDFS生态迁移过来的大文件，DuckDB读取时也能利用列块级别的并行。一般建议单文件大小在256MB到1GB之间比较合适。

当你有几万个Parquet小文件时，一个比较实用的做法是先用DuckDB把文件重刷成分区合理、数量适中的Parquet集：

COPY ( SELECT * FROM 'data/raw/*.parquet' ) TO 'data/optimized/year=2025/' (FORMAT PARQUET, PARTITION_BY (year), COMPRESSION ZSTD);

这一步可以做预聚合、清洗、压缩，之后的查询性能会有一个质的提升。

5. 常见问题与实战避坑清单

5.1 查询报错 Out of Memory 怎么破

这是使用DuckDB时最常遇到的报错。看到Out of Memory时，分三步走：

第一步，先确认内存限制设置是否合理。把memory_limit调大一些，或者设置为较小值并配置temp_directory，让DuckDB以外的临时数据落盘。注意，DuckDB只有在确实没有配置临时目录时才直接抛出OOM，设置了临时目录后大部分内存超限场景会转为Spill。

第二步，看是不是GROUP BY的基数太大。比如按UUID做GROUP BY，中间Hash表非常大。这时可以考虑换成两阶段聚合（先粗粒度再细粒度），或者改写成DISTINCT+ 窗口函数来绕过一些高基数的聚合。

第三步，实在不行，就把数据量分片处理。比如按月加载数据，把月度聚合结果保存成Parquet，最后再汇总。这虽然多了一些步骤，但稳定可靠，不用跟内存较劲。

import duckdb conn = duckdb.connect() conn.execute("SET memory_limit = '6GB'") conn.execute("SET temp_directory = '/tmp/duckdb_spill'") # 分片处理示例 for month in range(1, 13): file_pattern = f"data/2025/{month:02d}/*.parquet" conn.execute(f""" COPY ( SELECT '2025-{month:02d}' AS month, category, SUM(amount) FROM '{file_pattern}' GROUP BY category ) TO 'data/monthly_summary_{month:02d}.parquet' (FORMAT PARQUET) """)

5.2 类型推断与Schema不一致问题

不同数据源生成的Parquet文件，可能同一个字段在一个文件里是INT64，在另一个文件里是DOUBLE，或者一个文件有某个字段另一个文件没有。直接通配符查询时，DuckDB默认按照第一个文件的Schema来推断，后续文件类型不一致可能报错或者产生类型转换问题。

这时候union_by_name = true能解决列对齐问题：

SELECT * FROM read_parquet('data/*.parquet', union_by_name = true);

如果字段类型直接冲突，建议先统一字段类型再合并。比较常见的是partition_key在部分文件里是字符串，部分文件里是整数。可以在查询时用TRY_CAST做兼容：

SELECT TRY_CAST(partition_key AS VARCHAR) AS partition_key, ...

5.3 读取S3或云端存储上的Parquet

DuckDB默认直接读本地文件，但通过HTTPFS扩展可以访问S3、Google Cloud Storage、Azure Blob等对象存储：

INSTALL httpfs; LOAD httpfs; SET s3_region = 'us-east-1'; SET s3_access_key_id = 'your_key'; SET s3_secret_access_key = 'your_secret'; SELECT * FROM 's3://your-bucket/path/to/data/*.parquet';

这个场景适合你本机/服务器已经配置好对象存储访问凭证的情况。需要注意，S3查询的网络延迟和带宽会影响整体性能，本地缓存和文件裁剪仍然有效，但如果文件在远端，首次扫描的延迟会比本地高不少。实际使用时，也可以把远端Parquet拉到本地或挂载目录后再查询，更稳定。

5.4 常见错误速查表

5.5 一个综合案例：用DuckDB做批量数据清洗

结合前面的内容，我给出一个比较完整的实战脚本：读取一批多目录Parquet文件，做清洗、聚合，最后导出结果，并且全程在内存受限的环境下稳定运行。

import duckdb conn = duckdb.connect() conn.execute("SET memory_limit = '8GB'") conn.execute("SET threads = 4") conn.execute("SET temp_directory = '/tmp/duckdb_spill'") # 1. 扫描多目录文件，指定hive分区和schema对齐 conn.execute(""" CREATE OR REPLACE TEMP TABLE raw_orders AS SELECT * FROM read_parquet( 's3://data-lake/orders/year=*/month=*/*.parquet', hive_partitioning = true, union_by_name = true ) """) # 2. 清洗：去重、类型转换、填充空值 conn.execute(""" CREATE OR REPLACE TEMP TABLE cleaned_orders AS SELECT DISTINCT order_id, TRY_CAST(order_amount AS DOUBLE) AS order_amount, COALESCE(customer_id, 'unknown') AS customer_id, order_date, year, month FROM raw_orders WHERE order_date IS NOT NULL """) # 3. 聚合计算 result = conn.execute(""" SELECT customer_id, COUNT(*) AS order_count, SUM(order_amount) AS total_amount FROM cleaned_orders GROUP BY customer_id ORDER BY total_amount DESC LIMIT 100 """).fetchdf() print(result) # 4. 写回清洗后的Parquet，供下游使用 conn.execute(""" COPY cleaned_orders TO 'data/clean_orders.parquet' (FORMAT PARQUET, COMPRESSION ZSTD) """)

这个脚本压缩了很核心的几步：远程数据读取、临时表中间处理、清洗聚合、结果导出。所有配置项都做了显式控制，避免了内存拉胯的问题。在实际生产环境中，把它包成一个每天定时调度的Python脚本，就是一个“个人版轻量级数据仓库ETL任务”。

5.6 关于多表JOIN和复杂查询的经验

DuckDB对复杂查询的支持相当强大，TPC-H的22条分析查询全部能跑。多表JOIN的性能也很优秀。但有一点值得提醒：DuckDB的优化器对谓词下推和列裁剪的时机处理得非常激进，所以在写复杂查询时，尽量不要自己手动“优化”子查询（比如用一堆子查询去限定数据集），先把业务逻辑写清楚，再通过EXPLAIN ANALYZE看哪些算子耗时高，再针对性地调整。

DuckDB对复杂查询的JOIN顺序会自动做基于代价的优化，比很多老牌数据库都靠谱。你不用担心SQL里的表顺序会影响执行计划，它自己会算。

一个常见的优化技巧是：如果JOIN时有一张大表、一张小表，可以把小表加载成DuckDB内部的表（或者用CREATE TEMP TABLE AS），这让优化器在做Hash Join时能更高效地构建哈希表。对于直接从Parquet实时扫描的小表，DuckDB也能处理，但内部表的性能明显更高。

6. 适合把DuckDB引入工作流的三个典型场景

说完技术和实操，最后聊聊选型判断。DuckDB不是银弹，但在以下场景里确实是极佳的选择。

第一个场景是本地数据分析师/数据科学家的日常工作。你从数据仓库导出几个GB的明细数据到Parquet，本地用DuckDB做探索性分析、生成报表、验证假设，比Pandas省内存、比Spark省资源、比Excel不知道高到哪里去了。

第二个场景是轻量级ETL/ELT管道。公司内部定时脚本需要从各种数据源拉数据、做清洗、汇总、写回结果表，用DuckDB做计算引擎非常合适，部署简单没有外置依赖，单机跑批稳定高效。

第三个场景是嵌入到你的产品中。如果你的应用需要内置分析功能，比如允许用户对上传的数据文件做即时统计，DuckDB作为嵌入库可以随应用发布，用户不需要额外装数据库。它和SQLite的思路一致，但擅长的是分析型负载。

反之，如果你的场景是：每天亿级新增数据的持续写入、多个用户高并发在线查询、需要ACID事务保证的OLTP应用——这些直接选正常的OLTP数据库或分布式数仓，DuckDB不是为这些场景设计的。

从我个人踩过的坑来看，嵌入式和向量化的组合让DuckDB非常独特。它不像Spark那样有一个庞大的集群要做资源调度，但分析性能又能匹敌甚至超过很多“重”方案。数据世界的工具选择，很多时候拼的不是谁更“厉害”，而是谁更“合适”。当你需要的只是一个能在本地快速分析大文件的引擎时，DuckDB可能是当前最让人舒服的答案。最后再分享一个小技巧：用DuckDB查询Parquet时，我习惯先跑一次SUMMARIZE SELECT * FROM '文件路径'看看各列的基数和分布，再写业务SQL。这一步能让你的查询更精准，也能帮你提前发现类型问题，省下不少排查时间。