可以。DuckDB 是 in-process（嵌入应用程式行程内）的分析资料库，能直接用 SQL 查 CSV、Parquet，也支援读取 .xlsx；不必先架一台资料库 server。它特别适合多个本机档案的 adhoc 分析与跨档 JOIN，但不是 nightly ETL、多人共用权限或企业数仓的替代品。
什么是 in-process analytical database？
传统 client-server 资料库需要一个长期运行的 server，使用者透过网路连线。DuckDB 则可嵌入 CLI、Python 或桌面应用，在同一个 process 内执行分析查询。对使用者而言，优势是少了 server 安装、帐号与连线管理，仍保留 SQL 的 filter、JOIN、aggregation 与 window function。
它不是「把 CSV 变成正式数仓」，而是让档案立刻成为可查询的来源。依 DuckDB CSV 文件，最简单的查法是：
SELECT *
FROM 'orders.csv'
LIMIT 20;
CSV 没有固定 schema，DuckDB 会抽样推断格式与型别；重要分析仍应检查推断结果，必要时明确设定栏位型别、分隔符或 sample size。
从资料夹、Excel 到 JOIN 的三个例子
一次读取一整个月份资料夹
DuckDB 支援 glob，可把多个同 schema 的 CSV 当成一张表：
SELECT region, sum(amount) AS revenue
FROM read_csv('exports/2026-06/*.csv', union_by_name = true)
GROUP BY region
ORDER BY revenue DESC;
union_by_name = true 会按栏名对齐不同档案，缺少的栏位补 NULL。这很方便，但也可能掩盖上游 schema drift；正式执行前应列出档案来源与缺栏比例。DuckDB 多档案文件 提供 glob、档案清单与 filename 栏位的完整用法。
查 Excel 指定工作表
DuckDB Excel 文件 的 .xlsx 范例是：
SELECT *
FROM read_xlsx('targets.xlsx', sheet = 'Q3 Targets');
官方 DuckDB read_xlsx 不支援旧 .xls。产品若宣称支援 .xls，通常代表它另外做了转换或载入层，不能把该能力直接算在原生 DuckDB 上。
把本机目标和订单 JOIN
WITH targets AS (
SELECT * FROM read_xlsx('targets.xlsx', sheet = 'Q3 Targets')
), actuals AS (
SELECT region, sum(amount) AS revenue
FROM 'orders/*.parquet'
GROUP BY region
)
SELECT
t.region,
t.target,
a.revenue,
a.revenue / NULLIF(t.target, 0) AS attainment
FROM targets t
LEFT JOIN actuals a USING (region);
这比手动 VLOOKUP 更容易保留计算逻辑；但仍要先确认两边 region 是否唯一、命名是否一致，否则 JOIN 可能重复放大。
DuckDB 最适合的四种人
- Excel 重度使用者：档案已多到公式与复制贴上难以重跑，但还不需要建数仓。
- 营运与分析师：常收到多个 CSV／Parquet，要快速合并、聚合与验证。
- 工程师与研究者：需要在本机或 notebook 直接查档案，不想先把资料载入 server。
- 小团队试点：要先证明指标与资料价值，再决定是否投入正式 pipeline。
判断方式很简单：如果问题是「我桌面上有十个资料档，今天要得到可重跑的答案」，DuckDB 通常很合适。
什么时候不该只靠 DuckDB？
如果需求是多人同时存取、中央身份与 row-level 权限、稳定 nightly ETL、持续服务 dashboard、资料品质 SLA 或跨区备援，应评估资料仓库、lakehouse、orchestrator 与 BI。DuckDB 可以是其中的查询或开发元件，但单一 in-process 工作环境不会自动提供完整平台能力。
另外，直接读档代表结果依赖档案版本与路径。档案被覆盖后，相同 SQL 不一定得到相同结果；需要稽核时要保存来源版本、更新时间、SQL 与限制。
Lantide Data 把 DuckDB 变成可审阅的分析工作面
Lantide Data 内建统一 DuckDB 查询层，使用者与 Agent 共用相同 SQL 管线。工作区可载入 CSV、TSV、JSON／JSONL、Parquet，以及 .xls／.xlsx 工作表；后者是 Lantide 的载入能力，不等同 DuckDB 原生 read_xlsx 支援 .xls。也可 ATTACH PostgreSQL、MySQL、SQLite，让本机档与外部表跨源 JOIN。完整格式见 使用者指南 §1.5。
持久 SQL 分页执行后可产生暂存快取，后续 SQL 以分页名引用；有上游依赖时可用 Source Run 按顺序重跑并查看 lineage。这些快取在切换工作区或重启后会清除，因此是分析中间结果，不是 durable warehouse table。详见 快取与 Source Run 与 统一查询层。
若让 Agent 参与正式分析，Lantide 的价值不是「AI 直接给一个数字」，而是先把分母、grain、JOIN 与 checkpoint 写进 Plan，由人核准 Execute，再把 SQL evidence 与 Report 留下。它仍不代替资料 owner 对口径与品质的判断。
结语
先拿两个 CSV 或一份 .xlsx 做小实验：用 SQL 完成 preview、group by 与一个 JOIN，并把查询存下来。如果需求开始出现固定排程、多人共享与权限 SLA，再把稳定逻辑搬到正式资料平台；在那之前，DuckDB 能大幅降低「只是想查档案却先要架系统」的门槛。