TEZ映射器资源请求
我们最近从MapReduce迁移到TEZ，以便在EMR上执行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
写回答
-
本文解释了Tez分配资源的过程。https://cwiki.apache.org/confluence/display/TEZ/How+initial+task+parallelism+works
如果为拆分启用了Tez分组，则会在这些拆分上运行通用分组逻辑，以将它们分组为更大的拆分。我们的想法是在处理的并行程度与每个并行流程中的工作量之间取得平衡。
首先，Tez尝试为这些任务找出集群中的资源可用性。为此，YARN提供净空值（并且将来可以使用其他属性）。让我们说这个值是T.
接下来，Tez将T与每个任务的资源（比如M）分开，以找出在一个任务中（即在单个波中）并行运行的任务数。W = T / M.
接下来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尝试将拆分分组到指定数量的组中。这是最好的努力。
在此之后，执行分组算法。它按节点位置分组，然后按机架局部性分组，同时遵守组大小限制。2019-07-17 23:34:00赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
