hive alter table concatenate 命令風險

Question

我一直在使用 tez 引擎來運行 map 減少作業。 我有一個需要很長時間才能運行的 MR 作業，因為我注意到我有超過 20k 個文件，每個文件都有 1 個條帶，並且 tez 並沒有根據文件數量而不是條帶數量均勻分布映射器。 而且我可以擁有一堆帶有 1 個文件但有很多條紋的映射器，並且一些映射器處理 15k 文件但具有與另一個相同數量的條紋。

作為一種變通方法測試，我使用了ALTER TALE table PARTITION (...) CONCATENATE以減少要處理的文件數量，每個文件的條帶分布更均勻，現在 map 作業運行良好。

我擔心的是，如果運行此命令和丟失數據存在任何風險，我沒有在文檔中找到，因為它適用於相同的文件。

我試圖評估在 MR 作業之前使用 concatenate 來減少文件數量是否更好，而不是使用讀取文件並將 bucketed output 放入單獨的位置的存儲桶。 如果發生故障，我不會丟失源數據。

連接每個分區需要 1 分鍾，而分桶需要更多時間但不會冒丟失源數據的風險。

我的問題：運行連接命令時是否存在數據丟失的風險？

謝謝！

Answer 1

它應該與從查詢中重寫表一樣安全。 它使用相同的機制：首先在 staging 中准備結果，然后將 staging 移動到表或分區位置。

串聯作為單獨的 MR 作業工作，在暫存目錄中准備串聯文件，並且只有在一切順利的情況下，才將它們移動到表位置。 您會在日志中看到類似的內容：

INFO  : Loading data to table dbname.tblName partition (bla bla) from /apps/hive/warehouse/dbname.db/tblName/bla bla partition path/.hive-staging_hive_2018-08-16_21-28-01_294_168641035365555493-149145/-ext-10000