hadoop/Spark Locality

以Spark为例，我们调用hadoopRDD = sc.textFile(path)告诉Spark开始读取path中的数据。这个path可能是一个本地文件路径，更常见的是HDFS路径。
为了分布式 处理的要求，hadoopRDD通常情况下是被切分的。那么，其partition的信息来自何处呢？答案就是HDFS中的split，更确切的说是 FileSplit，其在FileInputFormat中被用到。FileSplit就是这样一种程序和block之间的映射。

每个FileSplit都是一个block集合，里面的block会在同一个worker上的同一个程序读出，因此也理所当然作为一个 partition。为了保持同一个split中block的本地性，FileSplit花了大力气把合适的block放到一起。例如贡献度计算，以及 node-block、rack-block之间的双向链表等。现在我们把之前的程序-block映射问题退化成split-block的映射问题。

对节点集合进行排序有两种方法，分别是考虑rack的信息和不考虑rack的信息。
要想排序，先要确定准则，即什么才是“好”。参照上图，我们定义一个“effective size”的概念，这是说在本节点上，存在多少比特有效的数据可供读取。例如，Rack4有两个block，每个block的大小都是75，但Rack4的effective size只有75，并非150，因为这两个block具有相同的内容，他们互为副本。

考虑到rack的计算方式就是将rack看作跟node同等的位置，计算effective size之后，可得如下顺序：

1:Rack 2 (250)

h4 (150)
h3 (100)
2:Rack 1 (175)

h1 (175)
h2 (100)
3: Rack 3 (150)

h5 (150)
h6 (150)
4:Rack 4 (75)

h7 (75)
h8 (75)
因此，优先顺序是h4 > h3 > h1 > h2 > h5 > h6 > h7 > h8。

不考虑rack的方法更简单，节点排序的结果为：

h1 (175)
h4 (150)
h5 (150)
h6 (150)
h2 (100)
h3 (100)
h7 (75)
h8 (75)
其优先顺序为 h1 > h4 > h5 > h6 > h2 > h3 > h7 > h8。