让我一步步帮你解答这两个问题：

1. Hive Metastore Partition的工作原理 #

Hive分区本质上是基于业务维度（比如日期、地域）对数据做物理拆分，用来大幅提升查询效率，而Metastore则是负责管理这些分区元数据的核心组件，具体工作流程可以拆解为这几步：

• 元数据存储：当你创建分区表时，Metastore会先记录下该表的分区规则（比如按dt日期分区）。之后每次添加分区（不管是通过ALTER TABLE ADD PARTITION手动添加，还是动态分区插入自动创建），Metastore都会把分区的关键信息——包括分区列值、对应的HDFS存储路径、分区创建时间、文件格式等——存入它的底层数据库（比如MySQL）中，形成一份权威的元数据清单。
• 数据与元数据的关联：每个分区在HDFS上对应一个独立的子目录（比如/user/hive/warehouse/db.db/tbl/dt=20240101），Metastore里的元数据就是Hive定位这些数据目录的“导航地图”。
• 查询时的作用：当你执行带分区过滤的查询（比如WHERE dt='20240101'），Hive会先向Metastore请求匹配的分区元数据，拿到对应的HDFS路径后，只扫描该路径下的数据，不用遍历全表所有文件，这就是分区能加速查询的核心原因。

简单来说，Metastore是分区元数据的“单一可信源”，Hive的所有分区操作和查询都依赖它来同步元数据与实际物理数据的状态。

2. 集群端与Metastore分区信息不一致的原因及查询影响 #

你遇到的show partitions显示数量少于Metastore中PARTITIONS表记录的情况，本质是元数据（Metastore）与实际物理数据（HDFS）的状态不同步，常见原因有这些：

• 手动操作HDFS分区目录：如果有人直接通过hdfs dfs -rm -r删除了某个分区的HDFS目录，但没有在Hive中执行ALTER TABLE DROP PARTITION命令，Metastore里的分区元数据不会自动删除。这时候show partitions会校验分区对应的HDFS路径是否存在，不存在就不会显示该分区，但Metastore的PARTITIONS表仍保留这条记录。
• 分区权限不足：如果某个分区的HDFS目录权限设置错误，当前执行show partitions的用户没有访问该目录的权限，Hive会隐藏这个分区，但Metastore里的元数据依然存在。
• 直接修改Metastore元数据：如果有人通过JDBC直接向Metastore的PARTITIONS表插入了分区记录，但没有在HDFS上创建对应的分区目录，也没有执行MSCK REPAIR TABLE同步，show partitions因为找不到实际的物理路径，不会显示这些“空元数据”分区。
• 旧版本Hive的兼容性问题：在某些早期Hive版本中，当分区数量超过阈值时，show partitions可能因为元数据加载分页、缓存同步等bug，漏显示部分分区，但Metastore里的记录是完整的。

对查询的影响 #

当你用WHERE子句指定分区时，会出现两种情况：

• 如果Metastore里有该分区，但HDFS路径不存在/权限不足：Hive会尝试扫描对应的路径，结果要么返回空数据集，要么抛出“文件不存在”或“权限被拒绝”的错误。
• 如果show partitions没显示但Metastore里存在的分区被写入查询条件：你可能会误以为该分区不存在，但实际上Hive会根据Metastore的元数据去查找路径，最终得到空结果或报错，同时这种不一致会导致Hive的统计信息失真，查询优化器可能做出错误的执行计划（比如预估数据量偏差），影响查询性能。

解决办法 #

• 优先用MSCK REPAIR TABLE <your_table_name>：这个命令会自动对比Metastore元数据和HDFS实际路径，删除那些HDFS上不存在的分区元数据，同时添加HDFS上存在但Metastore缺失的分区，一键同步状态。
• 手动校验异常分区：用DESCRIBE EXTENDED <your_table_name> PARTITION (dt='20240101')（替换成你的分区列和值）查看分区的存储路径，然后通过hdfs dfs -ls <path>检查路径是否存在、权限是否正确。
• 规范操作流程：禁止直接手动修改HDFS分区目录，所有分区的增删都通过Hive的DDL命令（ALTER TABLE ADD/DROP PARTITION）执行，从根源上避免元数据与物理数据脱节。

内容的提问来源于stack exchange，提问作者Dibakar Paul