使用来自云存储的输入映射任务仅使用一个工作线程

Question

我正在尝试通过FileInputFormat将来自Google云端存储的文件用作MapReduce作业的输入。该文件格式为Avro。

作为一个简单的测试，我使用bdutil工具部署了一个小型Hadoop2集群，该工具由主节点和两个工作节点组成，每个节点有两个插槽。

运行作业时，文件会分成多个部分。可以通过查看使用偏移量来加载数据的日志来验证这一事实。结果，创建了多个地图任务。到目前为止没什么不寻常的。

但是那些映射任务不会在工作节点之间分配。相反，两个仅在一个节点上启动，而其他节点则处于Scheduled状态。

我预计每个工作人员都要运行两个map任务，因为数据在任何工作节点（云存储中）都不在本地可用，这使得它们都是相同的候选者。

为什么会这样？

Answer 1

看来你正在看到YARN如何运作的文物之一;与Hadoop 1不同的是，JobTracker同时有效地扮演Hadoop 2的AppMaster和ResourceManager的角色，在Hadoop 2中，ResourceManager（在主节点上运行）实际上按需为每个YARN容器打包一个全新的AppMaster。 MapReduce工作。

另外，另一个改变一点的概念是你从来没有“插槽”，YARN容器实际上在内存和CPU维度上进行调度。这意味着如果打包到YARN上的单个任务请求大量内存但只需要1个CPU，则可能会占用资源占用空间，否则可能包含多个map或reduce任务。

例如，假设您每个n1-standard-2部署了2个工作者，那么在运行mapreduce时，您可能会在http://<master-ip>:8088/cluster/nodes下的ResourceManager页面上看到类似的内容：

... Containers  Mem Used    Mem Avail   VCores Used VCores Avail    Version
...     1       5.50 GB     0 B         1           1               2.6.0
...     2       5 GB        512 MB      2           0               2.6.0

在这种情况下，从ResourceManager访问application_master链接显示ResourceManager确实打包到报告5.5GB Mem Used, 0B Mem Avail, 1 VCores Used的VM上。同样，我发现我的地图任务仅在报告2 VCores Used的工作人员上运行。

一般来说，这意味着如果你最感兴趣的是确保它随着工人数量的增加而扩大规模，你就不需要做任何特别的事情;您将最终得到您的地图或减少打包到NUM_WORKERS - 1个可能机器上的任务，而其中一个机器运行AppMaster以完成工作。

虽然取决于您的工作，但这可能会浪费。默认设置最适合非常大的作业，其中有一个非常大的AppMaster是有意义的，以确保它不会跟踪大量正在进行的任务的OOM。您可以通过覆盖自定义NODEMANAGER_MEMORY_FRACTION文件中的CORES_PER_MAP_TASK，CORES_PER_REDUCE_TASK，CORES_PER_APP_MASTER和*_env.sh来调整细粒度设置（或{{1但是，与维护像hadoop2_env.sh这样的文件相比，这更难以跟踪升级。 bdutil的my_overrides_env.sh中的注释解释了这些设置：

hadoop2_env.sh

特别是如果你升级到像n1-standard-4这样的大型机器，你可以考虑简单地将# Fraction of worker memory to be used for YARN containers NODEMANAGER_MEMORY_FRACTION=0.8 # Decimal number controlling the size of map containers in memory and virtual # cores. Since by default Hadoop only supports memory based container # allocation, each map task will be given a container with roughly # (CORES_PER_MAP_TASK / <total-cores-on-node>) share of the memory available to # the NodeManager for containers. Thus an n1-standard-4 with CORES_PER_MAP_TASK # set to 2 would be able to host 4 / 2 = 2 map containers (and no other # containers). For more details see the script 'libexec/configure-mrv2-mem.py'. CORES_PER_MAP_TASK=1.0 # Decimal number controlling the size of reduce containers in memory and virtual # cores. See CORES_PER_MAP_TASK for more details. CORES_PER_REDUCE_TASK=2.0 # Decimal number controlling the size of application master containers in memory # and virtual cores. See CORES_PER_MAP_TASK for more details. CORES_PER_APP_MASTER=2.0 修改为更小的值。