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

Tue, 14 Jul 2026 00:00:00 GMT

很多本地数据分析的起点并不复杂：运营或业务同事导出一份 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 仍可作为导出、验证或离线分析环节，而不应承担中心事务库或共享仓库的全部职责。

让 LLM 参与数据分析前，先补齐这三道护栏

Tue, 14 Jul 2026 00:00:00 GMT

让 LLM 回答“上周华东收入为什么下降”这类问题，真正困难的并不是把自然语言翻译成 SQL。模型可以帮助理解问题、补全查询和解释结果，但它不知道指标口径是否更新，也不应天然拥有触碰全部数据的权力。把它放进数据分析流程前，先把数据、执行和结论三个环节约束清楚，回答才有被复查的基础。

可信的数据上下文#

模型看到的上下文应来自受维护的语义层，而不是临时拼接的表名清单。每个可用指标至少说明定义、时间字段、所属数据源、更新频率和常见过滤条件；维度的枚举值、主键关系与脱敏规则也要能被检索。这样，“收入”才能被解析成约定的已支付金额，而不会把退款前的订单金额当作同一件事。

上下文还应有版本和责任人。指标定义改动后，应同步更新可供模型读取的说明，并保留变更记录。模型可以引用这些定义，却不应自行发明口径；遇到名称相近、字段含义不明或数据新鲜度不足时，应要求澄清，或把不确定性写在回答里。

模型提议，执行权限归系统#

LLM 的职责是提出候选 SQL 和解释计划，不是获得数据库账号。服务端应解析候选语句，只允许受控数据集、已批准的表列和只读语法；禁止多语句、写入、导出、权限变更和绕过租户条件。执行器用独立的只读身份运行，并在网络、超时、扫描量和返回行数上设置上限。用户身份和数据域授权仍由系统验证，不能让提示词代替权限判断。

一个紧凑的流程可以写成：

1
用户问题 -> LLM 候选 SQL -> 解析 / 表列白名单 -> 用户与数据域授权策略门
2
-> 只读且限行、强制执行授权的执行器
3
-> 指标校验 -> LLM 解释

其中，解析阶段应把 SQL 变成结构化语法树，再检查表、列、函数和条件，不能只靠关键词拦截。白名单只界定可查询的结构；执行器必须在每次请求中按用户身份和数据域授权策略强制判定，不能由 LLM 或白名单代替。执行前还可自动补上时间范围、租户过滤和 LIMIT。审计日志应记录问题、经过审批的查询、执行身份、耗时和结果摘要，便于定位错误，但日志本身也要避免保存不必要的敏感明细。

结果必须可校验#

自然语言回答不能遮住查询条件。每次输出至少以符合访问策略的脱敏形式暴露时间范围、数据来源、返回行数和实际过滤条件；若用到了聚合，也要说明指标口径。这样读者可以判断“下降”是按自然周、滚动七天还是某个业务周期计算，也能知道结果来自正式宽表还是尚未完成刷新的明细表。

数值必须来自已执行的查询结果，模型不能补全缺失的小数、增长率或排名。对关键指标，系统可比较历史区间、总分项是否相加一致、空值比例和异常阈值；必要时再跑一条独立的对照查询。空结果、明显异常或执行超时都不是“没有变化”的证据，回答应明确说明无法得出结论，并给出可复查的状态，而不是把失败包装成业务解释。

同样要区分事实与推测。查询能说明某时间段、某筛选条件下的数值变化；“促销结束导致下降”属于待验证的假设，需要结合活动、价格、渠道或实验数据进一步检验。LLM 可以整理假设和下一步检查，但不应把相关性写成因果结论。

更稳妥的落地方式，是先选少量口径稳定、敏感度可控且已有人工分析流程的指标，限定在只读问答和结果复核场景中试运行。等到数据目录、授权审计和校验规则经得起日常使用，再逐步扩展范围；不应一开始就把所有数据资产交给一个会生成 SQL 的对话框。

Bugengxin