Hive分区表transaction的计数与分区查询结果差异问题

你的操作完全没问题！出现这两个查询结果的差异，核心原因是Hive处理仅涉及分区列的查询和需要扫描数据文件的查询时，采用了两种完全不同的逻辑：

1. 为什么COUNT(*)返回0？ #

当你执行SELECT COUNT(*) FROM transaction WHERE DS >= "current date";时，Hive需要统计分区内的实际数据行数。虽然未来日期的分区文件夹已经存在，但这些是空分区（没有加载任何数据文件），所以扫描后发现没有数据，返回0是完全符合预期的。

2. 为什么DISTINCT DS会返回未来日期？ #

而执行SELECT DISTINCT DS FROM transaction WHERE DS >= "current date";时，Hive触发了元数据查询优化：因为你的查询只涉及分区列DS，Hive会直接去读取Hive Metastore（元数据存储）中已经注册的分区信息，而不会去扫描HDFS上的实际数据文件。

你提到ETL人员通过ALTER TABLE transaction ADD PARTITION (DS = '2018-05-13')预先添加了未来分区，这些分区信息已经被写入Metastore了。所以Hive会直接把这些符合DS >= "current date"条件的分区值返回给你，哪怕分区是空的。

补充验证 #

你可以执行SHOW PARTITIONS transaction;来查看所有已注册的分区，会发现那些未来日期的分区确实在列表里——这个命令同样是直接读取元数据，不需要扫描HDFS文件。

总结 #

这种差异是Hive的性能优化策略导致的：

• 涉及数据行统计/查询的操作，必须扫描实际数据文件，空分区自然返回0；
• 仅针对分区列的查询，直接读取元数据，返回所有已注册的符合条件的分区值。

内容的提问来源于stack exchange，提问作者Prashanth G B