并行I/O亟需敲定标准

早在20年前，诸如Thinking Machines和Kendall Square Research这样的公司就已经开始在研究项目中涉及到并行应用，这些公司现已终止运营，而并行应用如今却已非常普遍，不管是预测天气还是设计飞机和汽车的都无一例外的进行着并行应用。

搜索引擎如Google、开放源代码Hadoop等，数据库如Oracle 和DB2等以及其他许多应用都属于并行应用。

并行应用以两种不同的方式执行I/O操作：可写入一个并行文件系统，比如GPFS、Lustre 或Pan-FS；或可写入配置中每个服务器节点的本地文件系统。不过这其中存在一个问题：除了用于并行处理通信的MPI（信息传递接口）标准，以及用于并行I/O的MPI-IO标准，我们并没有其他的标准。而目前也没有任何改变的迹象，在笔者看来，现在控制着标准组织的厂商并不愿意改变现状，因为他们可以销售更多的专有解决方案，长期利润更加可观，还能锁定用户。对于用户来说，更换不同厂商的产品将会花费更多成本。

搜索引擎的开源替代选择（例如Hadoop）具有并行通信，但是在本地文件系统中执行I/O操作。对于I/O，这不是一个很好的长远计划，因此笔者发出急切呼吁。

为何我们都需要并行I/O

自20世纪80年代，UNIX标准被正式通过的时候，就已经存在针对主系统调用的标准（打开、读取、写入、关闭、移动文件指针）。这些系统调用被用来执行libc；也具有了库调用标准（打开文件、读取文件、写入文件、关闭文件、重定位文件指针）。

而20世纪90年代以来，在I/O领域中，除了少部分异步I/O系统调用标准，几乎没有任何用于用户应用的标准出现。这也意味着应用和操作系统到文件系统的接口几乎是不变的。

目标存储在以前看来是很具希望的，它具有丰富的接口，也允许改变应用接口。但这样的希望还是未能实现，广阔的市场并没能提供基于目标存储设备（OSD）标准，不是因为它并非是一个良好的技术理念，也不是因为存储厂商不能从中获益，真正的原因是所需的投资和全球经济衰退。

因此，应用I/O接口标准20年以来都无任何改变。

文件系统有限的接口限制了现有的并行文件系统提高应用I/O性能。当然，许多厂商向其文件系统添加了接口功能，以使其特定文件系统实现应用优化。但每个厂商提供的应用接口都不相同，这是可以理解的，因为还不存在并行I/O或并行文件系统标准，而几年前向OpenGroup提出的建议也被忽略。并行系统厂商仍需要遵循文件系统的标准要求和相关命令，这对测试标准和I/O性能产生了重大影响。

为什么事情会演变成现在这样，是什么导致这种状况的出现？比如，为什么Hadoop要以本地文件系统的方式执行搜索引擎？其中有一个很简单的原因：设计人员必须为性能着想而执行本地I/O。并行文件系统的并行I/O相比本地I/O要缓慢一些，因为所有管理需求都需要满足POSIX标准。即使每个应用从每个线程或任务打开一个独立文件，并行文件系统也比本地文件系统要慢。这个过程通常被称为“N to N（N任务至N文件）”。而对于“N to 1（N任务至单个文件）”，情况就会更加糟糕，甚而一些文件系统无法实现，在有成百上千或至百万的任务打开文件的时候，这是至关紧要的。

而Hadoop执行本地I/O的另一个重要原因在于存储通信网络的成本。每个节点采用本地硬盘是符合成本效益的，而鉴于并行I/O和并行文件系统的性能问题，采用本地I/O就理所应当了。

不管是数据库、搜索引擎、HPC（高性能计算）或者是综合应用，都会运用并行I/O。在HPC领域（一般应用MPI来进行通信），人们已经意识到并行I/O的必要性，而控制MPI的标准组织也增加了一个被称为MPI-IO的并行I/O标准。

MPI-IO的部分功能可使小写入或读取合并为更大的写入和读取，并允许高速通信网络来处理这一合并。如果使用MPI编程模块，所有这些功能都将实现。若不具备MPI，则不能实现，这就意味着这些功能是永远都不会实现，因为MPI只用于HPC应用环境，而不会用在数据库或搜索引擎。