使用互为子集的 Hive 列/分区是否可以提高查询性能？答案

【问题标题】：Does using Hive columns/partitions that are subsets of each other improve query performance?使用互为子集的 Hive 列/分区是否可以提高查询性能？
【发布时间】：2016-04-06 01:52:26
【问题描述】：

我正在使用按年、月和日分区的 Hive 表。例如

year=2015 AND month=201512 AND day = 20151231。

根据我对 Hive 工作方式的有限了解，这些可能设置在一个文件夹结构中，其中“2015”文件夹包含 12 个月的文件夹，每个月的文件夹里面有 28-31 天的文件夹。在这种情况下，使用

WHERE year = 2015 AND month = 201512 AND day = 20151231

只会沿着目录结构向下爬到 20151231 文件夹。我认为仅使用 WHERE day = 20151231 会触发相同的遍历，因此本质上是相同的查询，但我们得到了使用 year AND month AND day 格式的示例代码（即引用所有 3 个分区）。

我使用这两个选项运行了一些基准测试（昨晚和今天早上，当服务器负载非常轻到不存在时），所用时间基本相同。我怀疑示例代码是错误的，我可以使用天分区，但我想确定一下。

在 Hive 查询中使用多个互为子集的分区是否有任何性能优势？

我知道 Hive 分区被视为列，但对于未分区的列是否同样适用？

【问题讨论】：

标签： hive partitioning hiveql query-performance

【解决方案1】：

当您在分区表上运行这样的查询时，hive 将首先查询元存储以查找哪些目录必须包含在 map/reduce 输入中，就像您看到的那样，它们如何并不重要安排（日=20151231 与年=2015/月=12/日=31）。如果您使用 mysql 作为元存储，这意味着 hive 内部将对其数据库运行 sql 查询以仅检索要查询的分区。此 SQL 查询的性能差异也可以忽略不计，尤其是与 map/reduce 作业的持续时间相比。使用非分区列时则完全不同，因为它们不存储在元存储中，但需要对数据进行全面扫描。

【讨论】：