現代計算機一般都有多CPU核，而日益廣泛應用的固態硬盤也有較強的并發能力，這些硬件資源都為并行計算提供了有力的保證。不過，要實現并行計算還需要有較好的數據分段技術，也就是能方便地把待計算的數據拆分成若干部分，讓每個線程(或進程，這里以多線程為例討論，多進程情況是類似的)分別處理。

一

設計數據分段方案時，有這么幾個目標：

1. 每段的數據量基本相同

并行任務的最終耗時是以那個最慢的線程為準的，而同一機器中各線程的處理能力基本相當，因此數據分段要能做到盡量平均，使各線程的計算時間基本相同。

2. 分段數可靈活動態指定

在數據準備階段經常并不清楚實際計算用機器的CPU數，而且即使知道，線程數也不能簡單地按機器CPU核數去算，因為硬盤的并發能力常常小于CPU;并且，在有并發計算時，能有多少CPU核用到本計算任務也不能事先預知。實際計算用的線程數***是根據當時場景動態決定，范圍從幾個到幾十個都有可能，這要求能夠按隨意的數量將數據分段。

3. 每個分段是連續緊湊存儲的

因為硬盤不適合頻繁隨機訪問(即使固態硬盤也不適合頻繁小量的隨機訪問)，為了保證遍歷性能，我們希望每個線程要處理的數據在硬盤上要盡量連續存儲，而不是頻繁跳躍。

4. 允許數據追加

數據并不是固定不變的，會隨著時間不斷增長，我們當然希望每次追加數據時不必重新整理所有數據，只需要把追加的數據補上即可。

二

使用文本文件存儲數據時，可以同時保證這4個目標。只要簡單地按總字節數把文件分成多段，每個線程讀取其中一段即可。

文本中用回車作為記錄(行)的分隔符，文本記錄的數據本身中不可能出現回車字符，所以用它用為記錄的分隔符不會產生歧義。按文件字節數分段時，分段點可能會落到某一行的中間，這時使用去頭補尾的方法進行調整，即就是每個分段從分段點繼續讀到一個回車符才開始，而越過下一個分段點繼續讀到一個回車符時才結束，這樣就可以保證每個分段都只包含完整的記錄(行)，這也是HADOOP常用的方法。

但是，文本本身的解析實在太慢了，我們還是要考慮二進制的存儲方案。

三

二進制數據中沒有回車這種可用于分隔記錄的字符，任何字節數值都可能是數據本身，這時就無法識別出記錄何時結束。如果一定要人為制造一個分隔符，那就要足夠長才能避免和數據本身重復的可能性，每條記錄上都增加這么一段字節，會增加大量無意義的數據量，降低性能。而且，這也只能降低出錯率而不能徹底杜絕。

改進的方法是使用區塊，把數據存入若干相同大小的區塊，分段時以區塊為單位，只要總區塊數量足夠多，每個線程分配到的區塊數量也就相對比較平均，也就能滿足目標1和目標2了。不過目標3卻有些問題，區塊大小是存儲數據之前就確定的，不大可能正好和記錄長度匹配，如果要求每個區塊中都存儲完整的記錄，就可能造成區塊中的空間浪費(剩余空間存不下一條完整記錄時只能作廢)。在區塊較小且記錄字段較多時這個浪費會很嚴重，影響目標3希望的緊湊性。如果允許一條記錄被拆分到兩個區塊，那又不能按區塊為單位來分段了，否則可能造成某個分段將只處理半條記錄的情況。

這時候可以借鑒文本的去頭補尾方案，允許同一記錄拆分到兩個區塊，在讀取分段的***個區塊時跳過***條(可能是半條)記錄，而讀取***一個區塊時再繼續讀下一個區塊把當前區塊中***的記錄讀完整，這樣可以保證數據的緊湊性了。這種方法要求在區塊中有個標記表明本區塊中***條記錄是否是上一區塊記錄的延續以及***一條記錄是否完整，空間成本不算高，但在遍歷數據時總要被這些標記打斷，處理起來麻煩不少，會影響性能。

四

數據庫一般也使用區塊方案，但由于數據庫將所有表的數據存儲在一起，它的區塊分配算法不會去保證同表數據所占用的區塊之間的連續性。而為提高數據的連續性，就要讓區塊更大，這和區塊多又有點矛盾。如果再考慮到數據的可追加性，則還需要一個不斷變大的索引表來管理這些區塊，在區塊數量很多時，這個索引表本身的連續性也不容易得到保證(它的長度事先不知道，在數據追加過程中動態增長)。