DuckDB 查询远程 Parquet 为什么要关注分区和行组大小

查询远程 Parquet 时，Hive 分区和 row group 解决的是两层不同问题：目录分区先帮助 DuckDB 判断哪些文件不必读取，文件内部的 row group 再利用列统计和谓词下推跳过不匹配的数据块。远程场景还要付出对象存储元数据请求、文件打开和传输的成本，所以“分区越多、行组越小”都不是无条件的优化。

官方地址：https://duckdb.org/

一、分区裁剪和 row group 裁剪不是一回事

可以把一份数据看成三层：目录决定文件集合，Parquet 文件由多个 row group 组成，每个 row group 又包含各列的 column chunk。查询条件先可能命中目录键，随后才进入文件内的列投影、统计信息和 predicate pushdown。前一层减少“要不要打开这个文件”，后一层减少“打开后要读哪些数据块”。

例如，目录使用 year=2026/month=11，SQL 带有对应过滤条件时，DuckDB 可以跳过不相关目录。即使文件已经打开，row group 仍可能因为时间列的 min/max 范围与条件不相交而不被扫描。两个层次叠加，才是远程扫描中更完整的过滤路径。

二、先用 Hive 分区减少远程文件访问

Hive 分区适合稳定、常用、基数可控的过滤列，例如日期或租户区域。DuckDB 可以从目录名恢复分区列：

-- 目录形如 orders/year=2026/month=11/*.parquet
SELECT order_id, amount
FROM read_parquet(
  'orders/*/*/*.parquet',
  hive_partitioning = true
)
WHERE year = 2026
  AND month = 11;

这里的 year 和 month 来自目录结构，不是每个文件都必须重复存储的普通数据列。分区键不宜随意选择高基数字段：目录过深、文件过碎，会增加列目录发现和远程请求的管理成本。写出数据时也应保持分区字段和业务过滤习惯一致：

-- 先补出分区字段，再按目录键写 Parquet
COPY (
  SELECT *, year(event_time) AS year, month(event_time) AS month
  FROM events
)
TO 'events'
(FORMAT parquet, PARTITION_BY (year, month));

三、row group 大小决定文件内的取舍

row group 不是目录分区的替代品。它是 Parquet 文件内部的行块，DuckDB 可利用每个块的列统计判断是否需要读取。较大的 row group 通常有利于压缩和顺序扫描，也能减少元数据块数量；较小的 row group 更容易形成窄的统计范围，并给并行读取和选择性查询更多切分空间，但会增加元数据管理和调度开销。

-- 用明确的行组大小写出示例文件；实际值应结合查询形态测量
COPY (
  SELECT * FROM events ORDER BY event_time
)
TO 'events-sorted.parquet'
(FORMAT parquet, ROW_GROUP_SIZE 122880);

如果经常按 event_time 过滤，写入前按该列组织数据，有助于让相邻 row group 的范围更集中；如果主要是全表聚合，过度缩小行组反而可能让元数据和调度成本变得明显。官方文档给出的默认值和建议范围是参考起点，不应替代你自己的数据分布、线程数和远程存储测试。

四、按查询形态决定数据布局

落地时可以先检查四件事：过滤条件是否真的包含分区键；文件大小和数量是否适合远程存储；row group 是否能覆盖足够的查询并行度；同一数据是否会被反复查询到值得先导入 DuckDB。没有实测数据时，不要把某个固定行数或固定文件大小宣传成普遍最优。

相关问题

只有 row group，没有 Hive 分区，可以吗？

可以。文件内裁剪仍然有效，但查询可能需要先发现或打开更多远程文件；按日期等稳定条件筛选时，目录分区通常更直接。

分区越细，远程查询就越快吗？

不一定。分区过细会带来更多目录和小文件管理成本，应让分区键服务于真实过滤条件，并观察文件数量和查询模式。

row group 应该固定成多少行？

没有脱离数据分布和查询形态的通用答案。以 DuckDB 文档建议作起点，再用选择性过滤、全表聚合和远程读取分别测量。