Question

我目前正在为我的所有表在加载数据后运行 MSCK HIVE REPAIR SCHEMA.TABLENAME。

随着分区的增长，这个语句在一张表上花费的时间要长得多（有时超过 5 分钟）。我知道它会扫描并解析 s3（我的数据所在的位置）中的所有分区，然后将最新的分区添加到 hive Metastore 中。

我想用 ALTER TABLE ADD PARTITION 语句替换 MSCK REPAIR。 MSCK REPAIR 在添加最新分区时效果很好，但是我在使用 ALTER TABLE ADD PARTITION 时遇到了分区中 TIMESTAMP 值的问题。

我有一个包含四个分区 (part_dt STRING, part_src STRING, part_src_file STRING, part_ldts TIMESTAMP) 的表。

运行 **MSCK REPAIR 后，SHOW PARTITIONS 命令给我以下输出

hive> show partitions hub_cont;
OK
part_dt=20181016/part_src=asfs/part_src_file=kjui/part_ldts=2019-05-02 06%3A30%3A39

但是，当我从 Metastore 中删除上述分区并使用 ALTER TABLE ADD PARTITION 重新创建它时

hive> alter table hub_cont add partition(part_dt='20181016',part_src='asfs',part_src_file='kjui',part_ldts='2019-05-02 06:30:39');
OK
Time taken: 1.595 seconds
hive> show partitions hub_cont;
OK
part_dt=20181016/part_src=asfs/part_src_file=kjui/part_ldts=2019-05-02 06%3A30%3A39.0
Time taken: 0.128 seconds, Fetched: 1 row(s)

它在时间戳值的末尾添加 .0。当我查询这个分区的表时，它给了我 0 条记录。

有没有办法添加具有时间戳值的分区，而不会在最后添加这个零。我无法弄清楚 MSCK REPAIR 如何处理这种 ALTER TABLE 语句无法处理的情况。

Answer 1

如果您插入动态分区，也会发生同样的情况，它会创建 .0 的新分区，因为默认时间戳字符串表示格式包括毫秒部分，REPAIR TABLE 查找新文件夹并将分区添加到 Metastore 并且工作正常，因为没有毫秒的时间戳字符串与时间戳非常兼容...

解决方案是使用 STRING 而不是 TIMESTAMP 并显式删除毫秒。

但首先要仔细检查您在单个分区中是否真的有数百万行并且确实需要时间戳粒度分区，而不是 DATE 并且这个分区列真的很重要（例如，如果它在功能上依赖于另一个分区列 part_src_file，你可以完全摆脱它）。分区过多会导致性能下降。

Apache Hive 使用alter table 语句

1 个答案: