从 CSV 到 Parquet：用 DuckDB 搭建轻量分析工作流

很多本地数据分析的起点并不复杂：运营或业务同事导出一份 CSV，分析者需要尽快确认规模、口径和趋势。问题通常不在于能否读到文件，而在于文件会不断追加、字段会有空值或类型漂移，临时脚本也容易把清洗逻辑散落在各处。DuckDB 适合放在这段流程的中间：它直接读取文件，用 SQL 完成探索和校验；当规则稳定后，再把结果写成适合后续复用的 Parquet。

接收原始 CSV#

先把原始文件按批次保存在 data/，不要在原文件上手工改列或覆盖历史版本。文件名、导出日期和来源应能对应起来，方便发现某天数据突然变少或列名变化。首次读取时，可以抽样查看订单号是否重复、金额是否为非负数、时间列能否解析，以及状态值有哪些取值。把这些检查写进查询，比把结论留在聊天记录里更可靠。

CSV 仍然是入口格式，而不是长期分析层。它可读、可交换，却缺少稳定的类型信息，扫描大文件时也会反复付出解析成本。因此，原始层保持不变，清洗规则在 DuckDB 中显式表达，避免某次临时修改悄悄改变指标。

用 DuckDB 查询#

DuckDB 不需要启动常驻服务，打开本地数据库文件或内存连接即可对 CSV 执行 SQL。read_csv_auto 会根据内容推断列类型，适合先探索；对已知且易变的字段，则应在后续查询中补充转换和空值处理。下面的查询按支付成功订单汇总每日收入：

1
SELECT
2
  date_trunc('day', order_time) AS order_day,
3
  sum(amount) AS revenue
4
FROM read_csv_auto('data/orders.csv')
5
WHERE status = 'paid'
6
GROUP BY 1
7
ORDER BY 1;

这一步的价值不只是得到一张日报。可以把筛选条件、去重规则和金额口径逐项审视，再与业务的预期总额对照。确认口径后，将查询保存为脚本或视图定义；下次换一批 CSV 时，重复运行同一套规则就能定位数据差异，而不必重新拼接数据框操作。

输出 Parquet#

当字段命名、时间格式、状态映射和去重逻辑已经稳定，就把清洗后的结果写入 warehouse/。Parquet 按列存储并保存类型信息，后续只读取少数分析字段时更省扫描，也比重新猜测 CSV 类型更可控。Python 只需调用 DuckDB，就能把查询结果固化为一个本地数据集：

1
from pathlib import Path
2

3
import duckdb
4

5
Path('warehouse').mkdir(exist_ok=True)
6
con = duckdb.connect('warehouse/local.duckdb')
7
con.execute("""
8
COPY (
9
  SELECT order_id, order_time, amount, status
10
  FROM read_csv_auto('data/orders.csv')
11
  WHERE status = 'paid'
12
) TO 'warehouse/orders.parquet' (FORMAT PARQUET, COMPRESSION ZSTD);
13
""")

输出前应明确分区策略和覆盖方式。按日期分批的数据可以保留批次字段，避免新文件与旧文件混淆；需要重跑时，应先在临时路径验证行数、唯一键和汇总金额，再替换正式文件。Parquet 是清洗层的交付物，原始 CSV 仍应保留，以便规则修订后重新生成。

适用边界#

这套工作流适合个人、小团队或单机任务：文件在本地，分析以读取和批量转换为主，结果需要被 notebook、脚本或其他本地工具重复使用。它减少了为一次分析部署数据库服务的成本，也让规则和产物都落在可追踪的文件中。

但它不是高并发写入的替代方案，也不适合处理复杂的共享数仓权限。多个系统持续写入、多人同时修改同一数据集、细粒度授权与审计都需要专门的服务端数据平台。在这些场景中，DuckDB 和 Parquet 仍可作为导出、验证或离线分析环节，而不应承担中心事务库或共享仓库的全部职责。

从 CSV 到 Parquet：用 DuckDB 搭建轻量分析工作流

接收原始 CSV#

用 DuckDB 查询#

输出 Parquet#

适用边界#

评论区