我有一些从 spark 和 hive 插入覆盖的 hive 表。分析师也可以在 presto 上访问这些表格。自然，我们会遇到一些时间窗口，因为 presto 忽略了锁，所以用户会遇到不完整的数据集。
我能想到的选项：
- 叉出 presto-hive 连接器以适当地支持 hive S 和 X 锁。这并不算太糟糕，但是要正确执行会很耗时。
- 插入覆盖完成后，交换 hive 元存储上的表位置。这没关系，但有点混乱，因为我们喜欢在数据库级别存储显式位置并让表继承位置。
- 停止在这些表上执行插入覆盖，而只需为已更改的内容添加一个新分区，然后在写入新分区后，更改配置单元表以查看它。然后我们就可以在数据之上拥有能够正确协调每一行的最新版本的视图。
- 停止在 s3 上执行插入覆盖，该 s3 具有从配置单元登台到目标表的复制窗口很长。如果我们将所有插入覆盖都转移到 hdfs，我们仍然会遇到问题，但是在执行 hdfs mv 所需的时间跨度上，速度要快得多。（可能很糟糕：仍然有一个窗口可以让我们获得不完整的数据）
我的问题是人们通常如何处理这个问题？这似乎是一个有明确解决方案的常见场景，但我似乎错过了它。对于任何可以查询 hive 元存储并直接与 hdfs/s3 交互而不考虑 hive 锁的第三方工具，通常都可以要求这样做。