生物数据处理和分布式并行计算

  写一点我对生物信息云计算的粗浅认识。首先,所谓云计算是一个商业模式的概念,其内涵里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模式。所以,生物领域的挑战也许可以反过来给计算领域一个发展的机会。

6 thoughts on “生物数据处理和分布式并行计算

  1. Pingback: joyfire 王乐珩 » 列书单.2011.4.25

  2. Pingback: joyfire 王乐珩 » LINPACK和WINE

  3. Pingback: joyfire 王乐珩 » Google投资个人基因数据服务

  4. Pingback: joyfire 王乐珩 » 从卫生巾说到生物云计算

  5. Pingback: Google为何进军生化领域?也许是因为老板要离婚。 | joyfire 王乐珩

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.