Hive 外部表在 EMR 上返回不一致的结果答案

【问题标题】：Hive External table returning inconsistent results on EMRHive 外部表在 EMR 上返回不一致的结果
【发布时间】：2022-01-15 19:51:28
【问题描述】：

我遇到了一个问题。就我而言，这种行为是随机的。加载 hive 外部表并成功运行 msck repair（作业 1）后，我们有一个后续的 spark 作业，它从这些表中提取数据并加载到其他表（作业 2）。随机，Job 2 正在从 Job 1 中加载的表中检索 0 条记录。一些事实：

这方面的任何帮助都会非常有帮助。我们一直在四处奔波，没有解决办法。

【问题讨论】：

使用 say select * 但是你的 where 子句呢？
您的表是在 S3 还是 HDFS 中？
你可以在作业 1 之后添加等待，然后再运行作业 2 吗？
@MattAndruff：我的答案 1) 有一个 where 子句选择该分区中的所有数据。 select 语句被验证可以工作，事实上它在某些工作的情况下做得很好，并且在其他工作的情况下获取零记录（为此我正在写这篇文章）。 2）我们的数据位于 S3 上。 3）最终，如果我们发现它是一个与时间相关的一致性问题，我们可能需要这样做，但现在最好不要这样做。我们仍在努力了解为什么会发生这种情况。
您找到问题了吗？

【解决方案1】：

对于“0”的结果，有 3 种可能的解决方案

Hive 定义不断变化。 Hive 日志知道一切。在 hive 日志中找到有问题的查询，然后上下查找以查看在此期间该表还发生了什么。这也将帮助您缩小查看 HDFS 的窗口
没有数据。使用 Ranger/HDFS/S3 审核日志查看运行查询时发生的情况。 S3现在应该一致并且一直是使用 hadoop 的一致问题来源。
一个错误。这真的不太可能，我保持开放的心态，这是可能的，但在我们查看 1 和 2 之前，我真的不看这个。

当我说“无数据”时，我的意思是文件夹/文件在被要求时不可用。这并不意味着数据消失了，只是不在请求时根据文件系统应该在哪里。（S3 非常适合长期存储，但一致性一直很困难，而且数据并不总是在以后报告它应该在的位置。）

仅供参考MSCK REPAIR TABLE runs slow on S3（使用大量目录列表），因此需要很长时间才能完成或有时会超时。这可能会导致所描述的不一致。

Use Add Partition 代替 MSCK REPAIR 表。

【讨论】：

谢谢马特。我们已经进行了一些挖掘，并将问题归零到您提到的第一点。但是在这种情况下，Hive 定义在数据加载到 S3 存储桶后通过 MSCK 修复进行修复，但即使修复后我们也看不到分区。我们正在尝试更深入地挖掘日志。给你一个问题：你知道在 EMR 中哪里可以找到 Spark 连接到 Hive 元存储的日志吗？同样，我们从哪里可以获得 Ranger 访问的此类日志？提前感谢您的帮助。
我可以在某一时刻找到它们。现在我得查一下。根据亚马逊的说法，Ranger 记录在 CloudWatch 中。(aws.amazon.com/about-aws/whats-new/2021/05/…)
我确实看到了一个有趣的评论，其中提到了使用 Glue 处理 hive 元数据，并暗示减轻了不同帐户写入数据的问题。有什么要调查的。（一个帐户写入数据而另一个帐户读取数据吗？）
我查看了 MSCK（在 S3 中），果然这是一个已知的性能问题。这可能是您的问题，请参阅我的更新答案以了解如何解决它。