写一点我对生物信息云计算的粗浅认识。首先，所谓云计算是一个商业模式的概念，其内涵里Saas占很大比重，网络服务代替软件产品。另一方面，技术角度的个人观点，一个Web服务的后台涉及到了大规模分布式并行的基础设施，才有资格被称为“云计算”（当然，这一定义有争议）。这篇Blog先写技术观点，后面再加关于用户和服务的讨论。

　　技术上，大规模分布式并行计算被分为计算密集型和数据密集型两类。

　　很多物理、地质和气象等领域的科学计算都是典型的计算密集型问题，CPU是瓶颈，涉及到外存I/O量相对不高。对这类问题的解决思路就是传统的“数据找CPU”。具体一点说，目前编程实现的工业标准是MPI，利用MPI提供的Master/Slave模式启动和调度集群上各个节点上的进程，数据传输共享常利用NFS，底层可以用硬件手段提高数据I/O性能。像Fold@home这一类志愿计算项目，往往本质上也是计算密集型的，当然软件架构有所不同。

　　而Web领域的计算问题，例如搜索引擎的信息检索，主要是数据密集型问题（或者也称为IO密集型问题），这种情况下，CPU不再稀缺，海量数据的内外存交换的性能成了的焦点。对此MapReduce模式给出了很有效的解决思路，也就是所谓“CPU找数据”。具体来说，Hadoop是目前最热门的主流框架，先对查询对象进行索引，通过分布式文件系统备份到集群各处，再调度相对轻量的进程，分阶段执行查找和归并操作。

　　那么有没有这样的需求：输入输出的数据很海量，其处理过程的算法复杂性又很高，很占CPU。有的，例如现代天文学需要对成T甚至成P的哈勃望远镜图片进行搜索过滤……面对这一类的问题，MapReduce模型就不一定适用，其瓶颈出现在海量数据的传输性能上（Web搜索模型里，尽管是数据密集型应用，但被检索的关键词和输出结果是相对很小的，而在很多科学应用里，往集群提交的待查询本身就是海量数据）。Secter/Sphere在其论文和技术报告里总结，它对Hadoop有明显性能优势的原因之一，就是专门开发的底层传输协议UDT比后者使用的通用TCP/IP要高效。

　　对Hadoop这个特定产品来说，由于它是Java实现的，相对于C/C++有性能劣势，这个短板对CPU耗费型的应用来说很要命（这也是Secter/Sphere快的另一个原因）。有很多解决方案，例如Yahoo!开发了MPI on Hadoop，用MPI具体负责干活，Hadoop包裹在上层负责宏观调度和容错；而百度实现了Hadoop C++ Extension，把Hadoop里面的关键瓶颈部件都换成了C++的；前不久刚刚发布的Hadoop下一个版本的Roadmap里，也宣布要进行彻底重构，重点解决性能问题。

　　生物信息领域，无论是基因测序还是质谱鉴定蛋白，产生出来的数据量巨大，其处理运算又吃CPU。对现有的分布式计算模型是个挑战。其实分布式计算领域，从来都是应用拖着技术走的。例如是物理学家发明了集群运算，是信息检索工业逼出了MapReduce模式。所以，生物领域的挑战也许可以反过来给计算领域一个发展的机会。