我们有一个外部 Hive 表，用于处理原始日志文件数据。这些文件每小时一次，并按日期和源主机名分区。
目前，我们正在使用简单的 python 脚本导入文件，这些脚本每小时触发几次。该脚本根据需要在 HDFS 上创建子文件夹，从临时本地存储复制新文件并将任何新分区添加到 Hive。
今天，使用“ALTER TABLE ... ADD PARTITION ...”创建新分区。但是，如果另一个 Hive 查询正在表上运行，它将被锁定，这意味着添加分区命令将失败（如果查询运行足够长的时间），因为它需要独占锁。
此方法的替代方法是使用“MSCK REPAIR TABLE”，由于某种原因，它不会not似乎获取了表上的任何锁。然而，我的印象是，不建议在生产环境中使用修复表。
- 在并发环境中以编程方式添加 Hive 分区的最佳实践是什么？
- 使用 MSCK REPAIR TABLE 有哪些风险或缺点？
- 对于两个分区添加命令看似不一致的锁定行为是否有解释？ IE。它们对运行查询有不同的影响吗？
这不是一个好的答案，但我们有同样的问题，以下是我们的发现：
- 在 Hive 文档中，https://cwiki.apache.org/confluence/display/Hive/Locking https://cwiki.apache.org/confluence/display/Hive/Locking，锁似乎非常明智：“ADD 分区”将请求对创建的分区的独占锁，以及对整个表的共享锁。SELECT 查询将请求对表的共享锁。所以它should be fine
- 然而，至少在 CDH 5.3 中，它不是这样工作的。根据这个线程，https://groups.google.com/a/cloudera.org/forum/#!topic/cdh-user/u7aM9W3pegM https://groups.google.com/a/cloudera.org/forum/#!topic/cdh-user/u7aM9W3pegM这是一个已知的行为，可能是新的（我不确定，但我也认为，作为该线程的作者，CDH 4.7 上不存在该问题）
所以基本上，我们仍在考虑我们的分区策略，但我们可能会尝试提前创建所有可能的分区（在获取数据之前），因为我们确切地知道所有未来分区的值（可能不是您的情况） ）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
