【问题标题】:TEZ mapper resource requestTEZ 映射器资源请求
【发布时间】:2019-04-05 02:22:51
【问题描述】:

我们最近从 MapReduce 迁移到 TEZ,以便在 EMR 上执行 Hive 查询。我们看到了针对确切的 hive 查询启动非常不同数量的映射器的情况。请参阅下面的地图 3 阶段。在第一次运行时,它请求了 305 个资源,而在另一次运行时,它请求了 4534 个映射器。 (请忽略 KILLED 状态,因为我手动终止了查询。)为什么会发生这种情况?我们如何将其更改为基于基础数据大小?

运行 1

----------------------------------------------------------------------------------------------
        VERTICES      MODE        STATUS  TOTAL  COMPLETED  RUNNING  PENDING  FAILED  KILLED  
----------------------------------------------------------------------------------------------
Map 1            container        KILLED      5          0        0        5       0       0  
Map 3            container        KILLED    305          0        0      305       0       0  
Map 5            container        KILLED     16          0        0       16       0       0  
Map 6            container        KILLED      1          0        0        1       0       0  
Reducer 2        container        KILLED    333          0        0      333       0       0  
Reducer 4        container        KILLED    796          0        0      796       0       0  
----------------------------------------------------------------------------------------------
VERTICES: 00/06  [>>--------------------------] 0%    ELAPSED TIME: 14.16 s    
----------------------------------------------------------------------------------------------

运行 2

----------------------------------------------------------------------------------------------
        VERTICES      MODE        STATUS  TOTAL  COMPLETED  RUNNING  PENDING  FAILED  KILLED  
----------------------------------------------------------------------------------------------
Map 1 .......... container     SUCCEEDED      5          5        0        0       0       0  
Map 3            container        KILLED   4534          0        0     4534       0       0  
Map 5 .......... container     SUCCEEDED    325        325        0        0       0       0  
Map 6 .......... container     SUCCEEDED      1          1        0        0       0       0  
Reducer 2        container        KILLED    333          0        0      333       0       0  
Reducer 4        container        KILLED    796          0        0      796       0       0  
----------------------------------------------------------------------------------------------
VERTICES: 03/06  [=>>-------------------------] 5%    ELAPSED TIME: 527.16 s   
----------------------------------------------------------------------------------------------

【问题讨论】:

标签: hive amazon-emr apache-tez


【解决方案1】:

本文解释了 Tez 分配资源的过程。 https://cwiki.apache.org/confluence/display/TEZ/How+initial+task+parallelism+works

如果为拆分启用了 Tez 分组,则使用通用分组 在这些拆分上运行逻辑以将它们分组为更大的拆分。这 想法是在处理的并行程度和 每个并行进程正在完成多少工作。

  • 首先,Tez 尝试找出集群中用于这些任务的资源可用性。为此,YARN 提供了一个净空值(并且 将来可能会使用其他属性)。假设这个值为 T。
  • 接下来,Tez 将 T 除以每个任务的资源(例如 M),以确定一个任务可以并行运行多少个任务(即在单个波中)。 W = 时间/时间。
  • 接下来的 W 乘以一个波因子(来自配置 - tez.grouping.split-waves)以确定要使用的任务数。 假设这个值为 N。
  • 如果总共有 X 个拆分(输入分片)和 N 个任务,那么这将对每个任务的 X/N 个拆分进行分组。 Tez 然后估计 每个任务的数据基于每个任务的拆分数。
  • 如果此值介于 tez.grouping.max-size 和 tez.grouping.min-size 之间,则接受 N 作为任务数。如果 不是,然后调整 N 以使每个任务的数据与 最大值/最小值取决于超出的阈值。
  • 出于实验目的,可以在配置中设置 tez.grouping.split-count 以指定所需的组数。如果这个配置 指定然后忽略上述逻辑,Tez 尝试分组 分成指定数量的组。这是最好的努力。
  • 在此之后执行分组算法。它按节点位置分组拆分,然后按机架位置分组,同时尊重组大小 限制。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-02-21
    • 2016-05-24
    • 1970-01-01
    • 2018-09-18
    • 2016-08-24
    • 2017-08-06
    • 2018-03-06
    相关资源
    最近更新 更多