【问题标题】:hive alter table concatenate command riskshive alter table concatenate 命令风险
【发布时间】:2021-08-01 22:36:50
【问题描述】:

我一直在使用 tez 引擎来运行 map reduce 作业。我有一个需要很长时间才能运行的 MR 作业,因为我注意到我有超过 20k 个文件,每个文件都有 1 个条带,并且 tez 并没有根据文件的数量而不是条带的数量来平均分配映射器。我可以拥有一堆只有一个文件但有很多条纹的映射器,一些映射器处理 15k 个文件但条纹数量与另一个相同。

作为一种变通方法测试,我使用ALTER TALE table PARTITION (...) CONCATENATE 来减少要处理的文件数量,使每个文件的条带分布更均匀,现在地图作业运行良好。

我担心的是我没有在文档中找到运行此命令和丢失数据是否存在任何风险,因为它适用于相同的文件。

我正在尝试评估在 MR 作业之前使用 concatenate 来减少文件数量与使用读取文件并将分桶输出放到单独位置的分桶是否更好。如果发生故障,我不会丢失源数据。

连接每个分区需要 1 分钟,而分桶需要更多时间,但不会有丢失源数据的风险。

我的问题:运行连接命令时是否存在数据丢失的风险?

谢谢!

【问题讨论】:

    标签: hive mapreduce concatenation orc apache-tez


    【解决方案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
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-06-08
      • 1970-01-01
      • 2016-01-14
      • 2020-05-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-02-05
      相关资源
      最近更新 更多