以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。