hadoop - Hadoop中Map Tasks的核心亲和性

Question

问题:Hadoop v.1.2.1 或 v.2 (YARN) 是否提供了一种方法来确定单个作业中不同映射任务的核心亲和性？换句话说，我能否以类似于 Linux 的 taskset 的方式将特定的 Map Task 固定到特定的核心，或者它是否不受 hadoop 的控制而取决于 Linux 调度程序？

我是 Map Reduce 编程的新手，我的项目涉及在不同参数(特定于机器或网络)发生变化时研究其性能。到目前为止，我已经阅读了它的官方文档 (v.1.2.1) 以及在线和 Stack Exchange 的众多主题。

下面我提供了两个不同的案例，以更好地说明我的问题，以及我目前的研究。

---

示例#1:假设我有以下配置:

• 输入:2 GiB
• HDFS block 大小:64 MiB
• 数据节点:2 个节点 x 32 个核心(处理器)
• 不需要 reduce task 。

根据 block 大小，将调用 2 GiB/64 MiB = 32 个 Map Task。如果 mapred.tasktracker.map.tasks.maximum 设置为 16 那么恰好 16 个 Map 任务将在节点 #1 上运行，16 个将在节点 #2 上运行，其中每个节点 16 个核心备用。 (链接:#1、#2)

据我所知，除了“机架感知”(link) 之外，没有办法直接控制“节点”亲和性，即如何将“映射任务”映射到特定节点 (link)。但是，在特定节点中，我可以...

问题 #1: ...“固定”每个 Map Task 到特定核心？问题 #2: ...保证每个 Map Task 都将留在它启动的核心上？或者它是否不受 hadoop 的控制并依赖于 Linux 调度程序？

---

示例 #2:假设示例 #1 的配置，但输入大小为 8 GiB，导致 128 个映射任务。

问题 #1:无论 mapred.tasktracker.map.tasks.maximum 的值如何，这 128 个 Map Task 是否会被同时调用？由于我总共有 64 个 Map 插槽(超过 2 个节点)，每个节点平均每个核心处理 2 个 Map 任务是否正确？

问题 #2:如果问题 #1 是正确的，我是否可以(在单个节点内)控制 Map Task 将在单个核心上停留“多长时间”，以及是否将被重新分配到同一个核心，还是它不受 hadoop 的控制而取决于 Linux 调度程序？

---

关于reduce tasks，我假设相关答案也成立，即核心亲和性也是可能的(或不可能)。

Answer 1

本文提供了一些关于任务核心亲和性的见解 - On the Core Affinity and File Upload Performance of Hadoop

论文提到 POSIX 标准定义了 sched_setaffnity() 系统调用来决定进程(或本例中的任务)与用户级别的核心亲和性。

但我希望有一种更简单的方法来定义任务核心亲和性。