DuckDB 1.4.3 LTS实战：嵌入式分析型数据库如何改写本地大数据处理

我做数据分析这些年，后端技术栈换了一茬又一茬，唯独对“本地处理几千万行数据还得快”这件事一直没找到特别省心的方案。直到把重心挪到 DuckDB 1.4.3 LTS 上，很多纠结才真正解开。这篇文章不聊概念包装，直接讲清楚它是什么定位、和 Pandas/SQLite/ClickHouse 这些常见选择差在哪、我实际拿它做了什么，以及升级到 1.4.3 LTS 之后遇到的兼容性问题和避坑经验。如果你想找一个轻量级分析型数据库来解决本地大文件查询、复杂聚合、甚至日常报表管道，这篇应该能帮你少走不少弯路。

1. 为什么是 1.4.3 LTS：从 SQLite、Pandas 到 DuckDB 的定位切换

1.1 分析型查询的普遍痛点

先说一个我反复遇到的场景：业务方扔过来一个 CSV，或者从数仓导出一张大宽表，几百万行起步，你要是用 Excel 打开基本就卡死。以前我的第一反应是用 Python + Pandas 去处理，read_csv() 然后 groupby、merge、pivot_table，听起来顺手，但数据量一旦到几千万行，内存立刻吃紧，一个 merge 可能把 16G 内存的笔记本直接干到 swap。

也试过 SQLite。SQLite 稳定、零配置、单文件，很优秀，但它的存储结构是行式的，定位是 OLTP 场景。拿它跑 SELECT region, SUM(amount) FROM orders GROUP BY region 这种分析型查询，数据量一大就会很吃力，因为引擎需要扫描整行数据，索引在聚合场景下能帮的忙也有限。你可以说“把聚合结果提前算好存成新表”，可现实里的分析需求永远是临时的、多变的，不可能每次都建一张物化表。

再往上就是 ClickHouse、Doris 这类真正的 OLAP 数据库。性能确实猛，但代价是组件变重了：要部署服务、管理集群、维护监控，一个人做数据分析或者小团队内部使用时，这个运维成本并不低。很多时候我们只是想快速验证一个想法，或者把一个十亿行以内的分析任务跑完，根本不想养一套分布式系统。

1.2 DuckDB 的定位：SQLite 的形态，OLAP 的能力

DuckDB 的定位非常精准：嵌入式分析型数据库。它和 SQLite 一样不需要独立服务进程，直接在应用进程内运行，数据库就是一个文件。但它的存储引擎是列式的，执行引擎是向量化的，查询优化器也是按 OLAP 场景设计的。你可以把它理解成“把 SQLite 的使用方式，套在了列存数据库的引擎上”。

这种组合带来的实际体验是：几乎零安装成本，却能在本地几千万行数据上跑出接近专用 OLAP 的性能。它既能在命令行里当分析工具用，也能作为 Python、R、Java、Node.js 的嵌入式库被调用。更重要的是，DuckDB 可以直接查询外部文件：CSV、Parquet、JSON，不需要先导入数据。这个能力在数据分析场景里太关键了，文件放哪就查哪，分析完了不产生额外的数据副本。

1.3 1.4.3 LTS 版本带来的稳定性信号

DuckDB 迭代速度很快，以前版本号更新频繁，对于要放进生产管道的团队来说，API 变动和存储格式变化都是顾虑。1.4.3 LTS 的意义在于：官方开始明确提供长期支持版本，承诺在 LTS 周期内保持接口兼容、持续发布修复补丁。这个信号对生产环境很重要，意味着你可以放心把基于 DuckDB 的分析任务写进调度系统，而不是每隔几个月就跟着主版本重构一次。

从我实际使用的感受来说，1.4.3 LTS 作为一个稳定版本，内存管理、Parquet 读取、窗口函数执行等核心路径都比较老练了，很少再遇到崩溃级的问题。加上官方扩展生态已经覆盖了 HTTP/S3 访问、PostgreSQL/SQLite/MySQL 互连、JSON/Parquet 处理，它已经完全能作为日常数据分析的主力工具。

2. 十分钟跑通：命令行、Python、CSV 直查与第一个分析任务

2.1 安装与三种使用入口

DuckDB 的安装是我见过最省心的数据库之一。官方直接提供一个静态编译的 CLI 二进制，下载解压就能用，无需系统依赖。我日常最常用的是 Python 接口，一条命令搞定：

bash复制pip install duckdb

如果你用 Homebrew，也可以：

bash复制brew install duckdb

装完之后，你实际获得的东西很轻：一个可以嵌入任何项目的分析引擎。不像装上 PostgreSQL 或 MySQL 那样要初始化数据目录、启动服务、配账号密码，DuckDB 默认就是“当前进程即数据库”。

使用入口有三个：

• CLI 模式：需要长期使用的数据就指定文件路径 duckdb mydata.db，临时分析就不带路径直接进内存模式。
• Python 嵌入式模式：import duckdb，在脚本里直接建连接、跑 SQL。
• R / JDBC / ODBC / Node.js：适合不同技术栈的团队复用。

2.2 命令行模式：不导入，先查文件

命令行是最能体现 DuckDB 风格的地方。拿到一个 CSV，不用建表、不用写导入语句，直接：

sql复制SELECT *
FROM 'orders.csv'
LIMIT 10;

引擎会自动推断列名和类型，这个推断在绝大多数场景下都是对的。如果是 Parquet 文件，也一样：

sql复制SELECT *
FROM 'orders.parquet'
LIMIT 10;

Parquet 列式文件天然适合 DuckDB，因为它能直接利用列裁剪、谓词下推，只读真正需要的列，所以查大文件时非常快。

这里有个很实用的组合：先摸清楚文件长什么样，再决定怎么处理。我经常上来就执行：

sql复制DESCRIBE SELECT * FROM 'orders.parquet';

当文件有几百列、你又只知道大概内容的时候，这个命令比 read_csv 后再慢慢看 schema 高效得多。

2.3 Python 里的三种执行方式

在 Python 里，DuckDB 的调用方式也很自由，我常用的有三种：

第一种，直接 SQL 字符串：

python复制import duckdb

conn = duckdb.connect('analysis.db')
result = conn.sql("""
    SELECT region, COUNT(*) AS cnt
    FROM 'orders.parquet'
    GROUP BY region
    ORDER BY cnt DESC
""")
print(result.df())

第二种，关系链式 API：

python复制rel = duckdb.read_parquet('orders.parquet')
rel.filter("amount > 100").group_by("region").aggregate("SUM(amount) AS total").show()

第三种，把内存里的 DataFrame 直接当表查：

python复制import pandas as pd
df = pd.read_parquet('orders.parquet')
result = duckdb.sql("SELECT region, SUM(amount) FROM df GROUP BY region")

注意这里第三种情况，DuckDB 不是把 DataFrame 拉进数据库再查，而是直接在 Pandas 的内存数据上做向量化操作，省掉了一次数据拷贝。这个能力让 Pandas 用户可以用 SQL 处理已有的 DataFrame，同时不用逃离熟悉的 Python 环境。

2.4 第一个完整分析任务

我拿一个典型的订单场景走一遍：文件里有日期、区域、品类、销售额、客户ID五个字段，目标是算每个区域、每个品类的月度销售额，并输出成 Parquet。

SQL 写出来很直观：

python复制conn.sql("""
COPY (
    SELECT
        strftime(order_date, '%Y-%m') AS month,
        region,
        category,
        SUM(sales) AS total_sales
    FROM read_parquet('orders.parquet')
    GROUP BY 1, 2, 3
) TO 'monthly_summary.parquet' (FORMAT PARQUET);
""")

DuckDB 的 COPY ... TO 可以直接把查询结果写成 Parquet，中间不需要经过 Python 对象，性能好又省内存。整个任务从“拿到文件”到“产出汇总结果”，没有手动建过一张表。

3. 向量化列式执行的加速原理与内存控制

3.1 列式存储为什么适合分析

很多人在接触 DuckDB 时会问：同样是嵌入式数据库，为什么它比 SQLite 更适合分析？核心差异在存储布局上。

SQLite 是行式存储，一行数据的所有列物理上放在一起，整行读完才会得到所有字段。对一个分析查询 SELECT region, SUM(amount) FROM t GROUP BY region 来说，如果表有几十个字段，行式存储也要把每一行的全部字段读出来，然后再丢掉不需要的列。数据量大时做的全是无效 IO。

DuckDB 是列式存储，同一列的数据连续存放在一起，查询引擎只需读取查询涉及的列。再加上列式数据在压缩上更友好，同类型数据放在一起压缩率往往比行式高不少。文件在磁盘上更小，扫描时的 IO 也更少。

这个差异在 Parquet 文件上体现得尤其明显。Parquet 本身就是列存格式，DuckDB 可以直接映射列块并做谓词下推，连“先把文件完整读出来”这个步骤都省了。这也是为什么 DuckDB 处理 Parquet 大文件时经常给人“秒开”的错觉，它只是在读必要的字节。

3.2 向量化执行引擎与批量处理

列式存储只是基础，真正让 DuckDB 快的是它的向量化执行引擎。传统数据库执行算子时通常是一次处理一行，走的是 Volcano 模型，每行都有大量函数调用开销。DuckDB 则是批量处理一批数据，通常一个向量包含上千行的同一列数据，然后对整个向量做操作。

批量处理带来的好处是：CPU 缓存命中率更高，函数调用次数大幅减少，更重要的是可以用 SIMD 指令做数据级并行。比如做累加求和，一个指令同时处理多个数值，吞吐量自然上去了。

对普通用户来说，不需要理解 SIMD 的具体实现，只需记住一个结论：DuckDB 是面向“几千万行到几亿行”这个区间设计的引擎。这个量级在单机上，SQLite 吃力，Pandas 吃内存，ClickHouse 杀鸡用牛刀，而 DuckDB 恰好能在毫秒到秒级返回结果。

3.3 内存控制：不会轻易把机器搞崩

Pandas 用户有个非常痛的体验：read_csv 大文件容易内存爆炸，因为 Pandas 默认把数据全部加载进内存。DuckDB 的设计从一开始就考虑了内存边界，关键参数有两个：

• memory_limit：控制内存使用上限，超出部分会走磁盘。
• temp_directory：指定临时数据落盘位置。

我在跑大查询前通常会先设一下：

python复制duckdb.sql("SET memory_limit='8GB'")
duckdb.sql("SET temp_directory='/tmp/duckdb_temp'")

有了这两个设置，即使一个聚合查询需要排序、Hash Join，DuckDB 也会在内存不足时把中间结果溢写到临时文件，而不是直接 OOM。我在 32G 内存的机器上处理过单表十几亿行的计数去重任务，只要给了合理的临时目录，DuckDB 都能稳定跑完。

这一点是与 Pandas 对比时的最大优势。Pandas 在做两个大 DataFrame 的 merge 时，只要 Key 基数高或者连接结果膨胀，内存很容易翻好几倍；而 DuckDB 的 Join 算子有外部内存支持，量级大了不至于整个进程崩溃。

3.4 扩展机制：从一个文件数据库变成数据连接器

DuckDB 的能力不止于查本地文件，它的扩展系统让它变成了一个轻量级“数据连接器”。常用的扩展包括：

举个例子，我经常直接查 S3 上的 Parquet：

sql复制INSTALL httpfs;
LOAD httpfs;
SELECT *
FROM 's3://my-bucket/events/year=2025/*.parquet'
LIMIT 100;

有了 httpfs，DuckDB 就像个本地分析终端，能直接扫云端对象存储，不需要先把文件下载到本地。这对于数据湖场景下的快速探查特别实用。

4. 从 Pandas 平滑迁移：API、互操作与代码改写模板

4.1 Pandas 用户迁移的心理门槛

很多搞数据分析的人不是不会 SQL，而是已经习惯了 Pandas 的链式操作。直接换工具确实有学习成本。DuckDB 的设计在这方面考虑得很周到，它允许你在不离开 Python 环境的情况下逐步迁移。

先在 Pandas 里加载数据，再用 DuckDB 查：

python复制import pandas as pd
import duckdb

orders = pd.read_parquet('orders.parquet')
result = duckdb.sql("""
    SELECT customer_id, SUM(amount) AS total
    FROM orders
    GROUP BY customer_id
    HAVING SUM(amount) > 10000
    ORDER BY total DESC
""")

这里的重点是，DuckDB 可以直接读取 Python 变量名对应的 DataFrame，不需要注册表。它会把 DataFrame 当作一个数据源，在内存中直接执行向量化查询。对于已经用 Pandas 做了一半处理流程的人，这一步迁移几乎无感。

4.2 常用 Pandas 操作与 SQL 对照

我做了一个常用的对照表，供团队内部培训用的：

实际迁移过程中，大部分人卡在 transform 和 apply 上。transform 在 SQL 里就是窗口函数，apply 则要看具体情况，有些能拆成普通表达式，有些涉及复杂逻辑可以先用 Python 函数注册成 UDF 过渡，后面再逐步改写成纯 SQL。

4.3 Arrow 互操作：不经过 Pandas 的数据交换

如果做数据分析时整个链路以 Arrow 为主，DuckDB 也有很顺滑的接口：

python复制rel = duckdb.sql("SELECT region, SUM(amount) total FROM orders GROUP BY region")
arrow_table = rel.arrow()

arrow() 方法直接返回 PyArrow Table，完全绕开 Pandas。在内存效率上，Arrow 列存格式和 DuckDB 更契合，接收方无论是做机器学习特征工程还是继续走数据管道，都能少一次格式转换开销。一般来说，能够避免 Pandas 转换就避免，尤其是大数据集。

4.4 什么时候继续留在 Pandas

DuckDB 虽然强，但我不主张把所有处理都搬到 SQL 里。以下几种场景我仍然用 Pandas：

• 机器学习模型的特征预处理：sklearn 生态和自定义 Python 逻辑更灵活。
• 复杂的文本清洗：虽然 DuckDB 支持正则，但极端复杂的 NLP 式清洗还是 Python 顺手。
• 小数据量的快速探索：几万行以内，Pandas 足够，不用引入新概念。

最佳实践是把 DuckDB 当作“重活累活”的执行引擎，把 Pandas 当作最终的交互层。数据量大的清洗、聚合、连接放到 DuckDB 里跑，结果变成小 DataFrame 后，再交给 Pandas 做可视化和后续建模。

5. 实战：千万级订单数据的四类聚合查询与 UI 可视化

5.1 准备测试数据

为了让方案可复现，我用 Python 生成了一张一千万行的订单表，包含订单ID、客户ID、日期、区域、品类、销售额、成本六个字段，然后存成 Parquet 文件：

python复制import pandas as pd
import numpy as np

n = 10_000_000
np.random.seed(42)

df = pd.DataFrame({
    'order_id': np.arange(n),
    'customer_id': np.random.randint(1, 200_000, n),
    'order_date': pd.date_range('2023-01-01', periods=n, freq='min'),
    'region': np.random.choice(['华东', '华南', '华北', '西南', '东北'], n),
    'category': np.random.choice(['家电', '数码', '服饰', '食品', '美妆'], n),
    'amount': np.round(np.random.uniform(50, 2000, n), 2),
    'cost': np.round(np.random.uniform(20, 1500, n), 2)
})

df.to_parquet('orders_10m.parquet', index=False)

这个文件在磁盘上大约是几百 MB，足够看出不同引擎处理大数据的差异。

5.2 四类典型查询与耗时记录

我在一台 16G 内存的 MacBook Pro 上分别跑以下查询，记录真实耗时。

查询一：按区域聚合销售额

sql复制SELECT region, SUM(amount) AS total
FROM 'orders_10m.parquet'
GROUP BY region
ORDER BY total DESC;

耗时约 0.8 秒。注意这是直接查 Parquet，没有导入数据库。

查询二：月度销售额趋势

sql复制SELECT strftime(order_date, '%Y-%m') AS month, SUM(amount) AS total
FROM 'orders_10m.parquet'
GROUP BY 1
ORDER BY 1;

耗时约 1.1 秒。strftime 对字符串格式化的开销不算大，引擎可以充分利用列裁剪和向量化处理。

查询三：客户消费排行（窗口函数）

sql复制WITH customer_stats AS (
    SELECT customer_id, COUNT(*) AS order_cnt, SUM(amount) AS total
    FROM 'orders_10m.parquet'
    GROUP BY customer_id
)
SELECT *, RANK() OVER (ORDER BY total DESC) AS rnk
FROM customer_stats
ORDER BY rnk
LIMIT 20;

耗时约 2.3 秒。这里有分组聚合加窗口排序，DuckDB 处理得很流畅。

查询四：区域×品类透视

sql复制PIVOT (
    SELECT region, category, SUM(amount) AS total
    FROM 'orders_10m.parquet'
    GROUP BY region, category
)
ON category
USING SUM(total)
GROUP BY region
ORDER BY region;

耗时约 1.5 秒。PIVOT 语法写起来很简洁，DuckDB 转成内部执行计划后性能依然稳定。

5.3 与 Pandas 对比的直观感受

同样的四个查询，如果全部用 Pandas 实现，总耗时大概在 10 秒以上，而且内存峰值会明显升高。最要命的是，当数据量超过内存时，Pandas 会直接报错或者疯狂 swap，而 DuckDB 由于有外部排序和流式聚合，很少出现这种情况。

所以我的建议很明确：如果你经常处理 GB 级表格数据，与其学一堆 Pandas 优化技巧，不如直接让 DuckDB 去跑 SQL。SQL 表达能力在聚合场景本来就比命令式代码更紧凑。

5.4 让查询结果拥有 UI：duckdb ui 生态盘点

很多人问数据分析结果怎么展示更轻松。DuckDB 官方没有像 pgAdmin 那样的重型 GUI，但生态里已经有不少组合方案可以用：

• 官方 Web Playground：DuckDB 官网提供基于 WASM 的在线运行环境，适合快速验证 SQL 逻辑，无需安装。
• DBeaver + JDBC 驱动：DBeaver 是桌面数据库客户端，通过 DuckDB JDBC 驱动可以直接连接 DuckDB 文件，浏览表结构、跑查询、看结果集。我把这个组合当成日常巡检 DuckDB 数据文件的可视化工具，体验接近成熟的数据库客户端。
• Streamlit + DuckDB：在 Python 里用 Streamlit 做界面，后端用 DuckDB 查询。这是我最常用的轻量数据应用方案，几行代码就能给业务方做一个可交互的报表页面。
• Observable + DuckDB WASM：前端可视化场景下，DuckDB 的 WASM 版本可以在浏览器里直接跑 SQL，配合 Observable Plot 做交互图表很顺滑。
• 社区 UI 工具：GitHub 上有一些专门为 DuckDB 做的桌面端 UI 项目，比如文件和 Schema 浏览、SQL 编辑、结果表格展示等。稳定性参差不齐，作为探索可以试试，生产环境我更推荐 DBeaver 或 Streamlit。

综合来看，DuckDB 的“UI”更多是嵌入到已有工具生态里，而不是自己造一个完整 GUI。这其实是好事，数据分析师可以基于熟悉的 BI 工具，同时享受 DuckDB 的高性能查询。

6. 升级到 1.4.3 LTS 后的兼容性整理与踩坑清单

6.1 版本升级带来的主要变化

从 1.2 系列升级到 1.4.3 LTS，我个人感受最深的是稳定性提升而不是新功能堆砌。对于生产环境来说，LTS 最大的意义是让依赖方可以锁定一个长期维护的基线，不用被迫跟进破坏性变更。DuckDB 1.x 系列的存储格式基本保持兼容，新的 LTS 版本可以正常打开旧版本生成的数据库文件。

如果你在调度系统里用 Python API，升级后的 API 调用基本没变化。我用到的 API 主要有 connect、sql、read_parquet、from_df、arrow、copy，在 1.4.3 上全部正常。扩展模块需要在升级后重新加载，我建议固定版本的 Python 环境使用 pip freeze 锁定 duckdb 版本，避免生产环境无意间漂移。

6.2 实际踩过的坑与解决方案

尽管 DuckDB 很顺手，但用久了还是会遇到一些需要小心的地方，我整理了几个高频坑。

CSV 类型推断不准确

read_csv 的自动类型推断在大多数时候可用，但遇到日期格式不统一、ID 列前导零、或者某列数据大部分为空时，推断结果可能不符合预期。解决方法是显式指定列类型：

sql复制SELECT *
FROM read_csv('data.csv', columns={'id': 'VARCHAR', 'date': 'DATE', 'amount': 'DOUBLE'}, auto_detect=false);

分区列没有自动过滤

DuckDB 读 Hive 风格分区目录时，如果直接 SELECT * FROM 'path/*.parquet'，会读取所有分区。要利用分区裁剪，需要指定 hive 分区：

sql复制SELECT *
FROM read_parquet('path/*.parquet', hive_partitioning=true)
WHERE year = 2025;

时间字段时区问题

TIMESTAMP 没有时区信息和 TIMESTAMPTZ 是两种类型。我在处理跨时区数据时踩过坑，TIMESTAMPTZ 在不同会话的 timezone 设置下显示结果不同。如果只是存储和展示，统一用 TIMESTAMP 通常会减少困惑；如果要做时区转换，用 convert_timezone 函数显式处理。

内存限制设置不及时

默认情况下 DuckDB 会尽量使用所有可用内存，在分析大查询时可能把机器内存吃满。不要等出问题才设置，在生产任务一开始就固定：

python复制duckdb.sql("SET memory_limit='80%'")
duckdb.sql("SET threads=8")

正则表达式不支持回看（lookbehind）

DuckDB 的正则基于 RE2，支持大部分常用语法，但不支持 lookahead 和 lookbehind。如果从 Python 迁移一个复杂的正则表达式，可能会报错。解决方法是把逻辑拆成多个 regexp_matches 条件组合，或者先按简单规则切分，再用 SQL 做二次过滤。

并发写限制

DuckDB 是单写者数据库，同一时间只允许一个进程写数据库文件。多个进程同时写会报错。实际使用时，如果有定时任务写 DuckDB，最好用 WAL 模式并避免多个任务并发写同一个文件。如果确实需要多写者并发，可以把数据写入独立的临时文件，最后用一个进程合并。

6.3 生产环境使用建议

把 DuckDB 放进生产环境之后，有几个习惯我觉得值得养成：

• 数据库文件定期做 CHECKPOINT，把 WAL 合并回主文件，避免 WAL 无限增长。
• 重要数据保留 Parquet 作为源文件，DuckDB 数据库文件可以作为中间计算层，这样即使文件损坏，也能从源文件重建。
• 使用 LTS 版本对应的小版本依赖，不要在生产环境随意升级到最新主版本。
• 数据量较大时，优先用 Parquet 作为持久化格式，DuckDB 只是查询引擎，而不是数据仓库的唯一存储。

6.4 升级后的一个实际收益

升级到 1.4.3 LTS 后，我遇到的一个明显改善是：大查询在内存与临时文件切换时的稳定性好了很多。之前跑 100G 级别数据集上的复杂连接查询，偶尔会出现临时文件清理不及时导致磁盘爆满的情况；在 1.4.3 上这个情况明显减少，临时文件会在事务结束后自动清理，磁盘占用回到正常水平。对于需要每天跑批的数据管道来说，这个细节能省很多事。

7. 我保留的几个使用习惯

最后分享几个我个人一直在用的操作习惯，不一定适合所有人，但至少帮我省了不少时间。

第一，数据分析时，我基本不建库表，直接把 CSV 或 Parquet 当作查询目标。这听起来像是绕过数据库，但配合 DuckDB 的列裁剪和谓词下推，效果很好，而且省去了建表、导入、维护 schema 这些步骤。只有明确要反复查询同一份数据时，我才会执行 CREATE TABLE t AS SELECT * FROM 'data.parquet'，把它落到 DuckDB 数据库文件里。

第二，和 Pandas 配合时，尽量用 duckdb.sql 直接查 DataFrame，返回结果后再转回 Pandas，避免手动循环做 agg。数据量大或者逻辑复杂时，统一用 SQL 表达，代码可读性和执行效率都会提升。

第三，写复杂查询时先用小文件验证逻辑，确认结果无误再切到全量数据。DuckDB 查询本地小文件很快，这个验证流程几乎不耗时间，但能极大降低大查询出错成本。

第四，如果你经常需要做 BI 展示，强烈建议把 DuckDB 作为查询引擎藏在 Streamlit 后面。一份百万行级别的数据，DuckDB 做聚合只要几百毫秒，Streamlit 只需要负责展示结果，整体交互体验比直接让 BI 工具查 CSV 好太多。

DuckDB 1.4.3 LTS 会不会取代 Pandas？不会。会不会取代 ClickHouse？也不会。它的价值在于补上了“本地轻量分析”这个需求空档，让没有多少基础设施的人也能跑出接近专业数仓的性能。从 1.4.3 LTS 开始，它也不再只是数据分析师手里的玩具，而是可以放进生产管道里长期依赖的组件。如果你正卡在“数据量大了以后，本地分析工具全都不得劲”的节点上，我建议你花一个下午试试 DuckDB，大概率会回不去。