ORC 分区与分桶实战：数据湖查询性能的基石0. 问题引入：从大促用户行为分析的“慢查询”说起用户原始问题：“在生产环境中，如何设计 ORC 文件的分区策略和分桶策略？”在一次电商大促期间，我们的用户行为分析平台遭遇了严重的性能瓶颈。一个看似简单的 SQL 查询——“统计过去一小时内，来自上海地区的 iOS 用户的点击转化率”——执行时间从平时的 2 秒飙升到了 150 秒以上。经过深入排查，我们发现问题的根源在于糟糕的物理存储设计：无分区: 所有用户行为日志都写入同一个巨大的 ORC 文件。无分桶:user_id列是高基数字符串，但未进行任何预排序或分桶。这导致每次查询都需要扫描整个 PB 级的数据集，即使 WHERE 条件非常精确。这次事故让我们深刻认识到，再强大的计算引擎（如 Spark、Trino），也无法弥补底层物理存储设计的缺陷。分区（Partitioning）和分桶（Bucketing）是 ORC 文件在数据湖架构中实现高效查询的两大核心物理组织策略。它们并非 ORC 格式自身的特性，而是由上层表格式（如 Hive Metastore, Iceberg）或写入作业（如 Spark）来实施的。本文将基于ORC 2.3.0 【ORC】在生产环境中，如何设计 ORC 文件的分区策略和分桶策略？
ORC 分区与分桶实战：数据湖查询性能的基石0. 问题引入：从大促用户行为分析的“慢查询”说起用户原始问题：“在生产环境中，如何设计 ORC 文件的分区策略和分桶策略？”在一次电商大促期间，我们的用户行为分析平台遭遇了严重的性能瓶颈。一个看似简单的 SQL 查询——“统计过去一小时内，来自上海地区的 iOS 用户的点击转化率”——执行时间从平时的 2 秒飙升到了 150 秒以上。经过深入排查，我们发现问题的根源在于糟糕的物理存储设计：无分区: 所有用户行为日志都写入同一个巨大的 ORC 文件。无分桶:user_id列是高基数字符串，但未进行任何预排序或分桶。这导致每次查询都需要扫描整个 PB 级的数据集，即使 WHERE 条件非常精确。这次事故让我们深刻认识到，再强大的计算引擎（如 Spark、Trino），也无法弥补底层物理存储设计的缺陷。分区（Partitioning）和分桶（Bucketing）是 ORC 文件在数据湖架构中实现高效查询的两大核心物理组织策略。它们并非 ORC 格式自身的特性，而是由上层表格式（如 Hive Metastore, Iceberg）或写入作业（如 Spark）来实施的。本文将基于ORC 2.3.0