本文作者Henry Newman是Instrumental Inc.的首席技术官。他是一位行业咨询师,在高性能计算和存储领域拥有28年的工作经验。
DOSTOR存储在线3月4日国际报道：Hadoop执行本地I/O的另一个主要原因是考虑到存储通信网络的成本。在各个节点上配置本地驱动器是非常有成本经济性的，而且鉴于并行I/O和并行文件系统的性能问题，只有本地I/O才值得做。
因此，无论这个应用程序是一个数据库，搜索引擎，高性能计算（HPC）还是上面这三个的结合，并行I/O都有使用。在HPC的世界，应用程序通过MPI进行通信。人们意识到HPC需要并行I/O，因此控制着MPI标准的标准实体增加了一个专门针对并行I/O的叫做MPI-IO的标准。
MPI-IO的一些功能可以允许小型写入或读取合并成更大的写入或读取，并允许高速通信网络处理这种写入/读取合并。如果你是使用MPI编程模式的话，这一切都运行良好。但是，如果你没有MPI的话，就不行了。这意味着这种方式并不实用，因为MPI只用在HPC应用程序环境而不是用在数据库或搜索引擎上。
一个小小的建议
我觉得我们在并行应用上面临着先有鸡还是先有蛋的尴尬局面。HPC应用程序使用本地I/O，因为并行I/O到并行文件系统实在是太慢了。同样重要的是，我们在这些并行应用所能使用的I/O接口上没有一个标准，也使得并行文件系统厂商无法利用标准来进行各个层次上的优化。
我们需要重新通盘思考I/O。不幸的是，ANSI T10 OSD标准虽然在开始的时候为I/O提供了一个更新的框架，但是现在我认为这个标准基本上已经不能成为行业标准了。它的发布时机是错误的，同时，在我看来，存储行业也错误地忽视了I/O重新思考的重要性。即使ANSI T10 OSD成为一个行业标准，我们仍然还没有一个人讨论各个语言下的并行I/O框架。C++、C、Java、数据库和其他语言仍然使用标准的POSIX标准，没有机会进行并行I/O。
诚然，大多数搜索引擎之所以进行本地文件系统通信不仅仅是因为没有并行I/O标准，而且还以为并行文件系统的硬件成本比较高，不过在这些搜索引擎中，许多是利用节点上的多副本来解决节点故障问题。这种架构有刀片系统、本地网络、复制网络和电源/冷却成本。我不确定用户是否都明白这种架构的成本以及它们和并行文件系统成本的区别。不过这也不重要，因为现在还没有标准。
因此，我希望我们这个行业（标准实体、硬件厂商、数据库专家、计算机语言开发专家等）开发一个针对多种语言的并行I/O标准，并让这种标准支持MPI-IO所有的功能和特性。
这个新的并行I/O标准需要对POSIX进行一定的更改以便让应用程序写入能够将有关I/O的信息传递给文件系统从而提高性能。这个新的系统将要求调试器允许用户调试他们的并行I/O错误。这意味着控制着POSIX标准的OpenGroup将必须和各个ANSI委员会（有可能还要包括针对网络文件系统标准的IETF）做出一些重大修改。
所有人都必须协同合作以便我们可以最终获得一个拥有丰富接口的完美整合的I/O堆栈。这个I/O堆栈必须得到标准化，而且必须可以满足各种应用环境的要求–从数据库到搜索引擎到HPC–因为所有这些应用都（可能）要求并行I/O。
我最近曾和某个人谈起我的这个想法，结果他觉得我是在妄想。梦想是好的，不过就像我曾说过的，如果存储不能变得更加便于使用并随需扩展以满足带宽要求，那么存储的重要性可能会降低。可悲的是，我的想法能够实现的概率就和中强力球彩票的概率一样小，而且我还不买彩票。
