现代计算机一般都有多 CPU 核，而日益广泛应用的固态硬盘也有较强的并发能力，这些硬件资源都为并行计算提供了有力的保证。不过，要实现并行计算还需要有较好的数据分段技术，也就是能方便地把待计算的数据拆分成若干部分，让每个线程（或进程，这里以多线程为例讨论，多进程情况是类似的）分别处理。

设计数据分段方案时，有这么几个目标：

1. 每段的数据量基本相同

并行任务的最终耗时是以那个最慢的线程为准的，而同一机器中各线程的处理能力基本相当，因此数据分段要能做到尽量平均，使各线程的计算时间基本相同。

2. 分段数可灵活动态指定

在数据准备阶段经常并不清楚实际计算用机器的 CPU 数，而且即使知道，线程数也不能简单地按机器 CPU 核数去算，因为硬盘的并发能力常常小于 CPU；并且，在有并发计算时，能有多少 CPU 核用到本计算任务也不能事先预知。实际计算用的线程数最好是根据当时场景动态决定，范围从几个到几十个都有可能，这要求能够按随意的数量将数据分段。

3. 每个分段是连续紧凑存储的

因为硬盘不适合频繁随机访问（即使固态硬盘也不适合频繁小量的随机访问），为了保证遍历性能，我们希望每个线程要处理的数据在硬盘上要尽量连续存储，而不是频繁跳跃。

4. 允许数据追加

数据并不是固定不变的，会随着时间不断增长，我们当然希望每次追加数据时不必重新整理所有数据，只需要把追加的数据补上即可。

使用文本文件存储数据时，可以同时保证这 4 个目标。只要简单地按总字节数把文件分成多段，每个线程读取其中一段即可。

文本中用回车作为记录（行）的分隔符，文本记录的数据本身中不可能出现回车字符，所以用它用为记录的分隔符不会产生歧义。按文件字节数分段时，分段点可能会落到某一行的中间，这时使用去头补尾的方法进行调整，即就是每个分段从分段点继续读到下一个回车符才开始，而越过分段点继续再读到一个回车符时才结束，这样就可以保证每个分段都由完整的记录（行）构成，这也是 HADOOP 常用的方法。

但是，文本本身的解析实在太慢了，我们还是要考虑二进制的存储方案。

二进制数据中没有回车这种可用于分隔记录的字符，任何字节数值都可能是数据本身，这时就无法识别出记录何时结束。如果一定要人为制造一个分隔符，那就要足够长才能避免和数据本身重复的可能性，每条记录上都增加这么一段字节，会增加大量无意义的数据量，降低性能。而且，这也只能降低出错率而不能彻底杜绝。

改进的方法是使用区块，把数据存入若干相同大小的区块，分段时以区块为单位，只要总区块数量足够多，每个线程分配到的区块数量也就相对比较平均，也就能满足目标 1 和目标 2 了。不过目标 3 却有些问题，区块大小是存储数据之前就确定的，不大可能正好和记录长度匹配，如果要求每个区块中都存储完整的记录，就可能造成区块中的空间浪费（剩余空间存不下一条完整记录时只能作废）。在区块较小且记录字段较多时这个浪费会很严重，影响目标 3 希望的紧凑性。如果允许一条记录被拆分到两个区块，那又不能按区块为单位来分段了，否则可能造成某个分段将只处理半条记录的情况。

数据库大多就是使用区块方案，但由于数据库将所有表的数据存储在一起，它的区块分配算法一般不会去保证同表数据所占用的区块之间的连续性。而为提高数据的连续性，就要让区块更大，这和区块多又有点矛盾，除非数据量非常巨大才能让区块又大又多。如果再考虑到数据的可追加性，则还需要维护一个不断变大的索引表来管理这些区块，在区块数量很多时，这个索引表本身的连续性也不容易得到保证（它的长度事先不知道，在数据追加过程中动态增长）。所以数据库中做并行数量较多的外存计算时效果常常不会很好。