Hadoop中Map Tasks的核心亲和力
Core affinity of Map Tasks in Hadoop
问题：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 块大小：64 MiB
- 数据节点：2 个节点 x 32 个核心（处理器）
- 不需要 Reduce 任务。
根据块大小，将调用2 GiB / 64 MiB = 32个Map Tasks。如果 mapred.tasktracker.map.tasks.maximum 设置为 16，则恰好 16 个 Map 任务将在节点 #1 上 运行，16 个将在节点 #2 上 运行，每个节点有 16 个核心备用. （链接：#1, #2）
据我所知，没有办法直接控制"node"亲和力，即如何将"Map tasks"映射到特定节点（link), apart from its "Rack awareness" (link）。但是，在 特定的 节点中，我可以...
问题 #1： ... "pin" 每个 Map Task 到一个特定的核心？
问题 #2： ... 保证每个 Map Task 留在 它启动的核心上？或者它是否不受 hadoop 的控制并依赖于 Linux 调度程序？
示例 #2：假设示例 #1 的配置，但输入大小为 8 GiB，导致 128 个映射任务。
问题#1：不管mapred.tasktracker.map.tasks.maximum的值是多少，128个Map Tasks会被同时调用吗？这是正确的吗，因为我总共有 64 个 Map 插槽（超过 2 个节点），每个节点平均每个核心处理 2 个 Map 任务？
问题 #2： 如果问题 #1 是正确的，我是否可以（在单个节点内）控制 "how much time" Map Task 将停留在单核，如果它会被重新分配到同一个核心，或者它是否不受 hadoop 的控制并且取决于 Linux 调度程序？
关于 reduce 任务，我假设相关答案也成立，即核心亲和力也是可能的（或不可能）。
本文提供了一些关于任务核心亲和力的见解 - On the Core Affinity and File Upload Performance of Hadoop
论文提到 POSIX 标准定义了 sched_setaffnity() 系统调用来决定进程（或本例中的任务）与用户级别的核心亲和力。
但我希望有一种更简单的方法来定义任务核心亲和力。
问题：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 块大小：64 MiB
- 数据节点：2 个节点 x 32 个核心（处理器）
- 不需要 Reduce 任务。
根据块大小，将调用2 GiB / 64 MiB = 32个Map Tasks。如果 mapred.tasktracker.map.tasks.maximum 设置为 16，则恰好 16 个 Map 任务将在节点 #1 上 运行，16 个将在节点 #2 上 运行，每个节点有 16 个核心备用. （链接：#1, #2）
据我所知，没有办法直接控制"node"亲和力，即如何将"Map tasks"映射到特定节点（link), apart from its "Rack awareness" (link）。但是，在 特定的 节点中，我可以...
问题 #1： ... "pin" 每个 Map Task 到一个特定的核心？ 问题 #2： ... 保证每个 Map Task 留在 它启动的核心上？或者它是否不受 hadoop 的控制并依赖于 Linux 调度程序？
示例 #2：假设示例 #1 的配置，但输入大小为 8 GiB，导致 128 个映射任务。
问题#1：不管mapred.tasktracker.map.tasks.maximum的值是多少，128个Map Tasks会被同时调用吗？这是正确的吗，因为我总共有 64 个 Map 插槽（超过 2 个节点），每个节点平均每个核心处理 2 个 Map 任务？
问题 #2： 如果问题 #1 是正确的，我是否可以（在单个节点内）控制 "how much time" Map Task 将停留在单核，如果它会被重新分配到同一个核心，或者它是否不受 hadoop 的控制并且取决于 Linux 调度程序？
关于 reduce 任务，我假设相关答案也成立，即核心亲和力也是可能的（或不可能）。
本文提供了一些关于任务核心亲和力的见解 - On the Core Affinity and File Upload Performance of Hadoop
论文提到 POSIX 标准定义了 sched_setaffnity() 系统调用来决定进程（或本例中的任务）与用户级别的核心亲和力。
但我希望有一种更简单的方法来定义任务核心亲和力。