从卫生巾说到生物云计算

  写一些技术感想,意识流,没中心,想到哪里写到哪里。   12月12日,淘宝又一次大促销。一天时间不到,卖出去了三亿片苏菲。这是一个很恐怖的数字。随着淘宝占全中国零售额的比例一路超过5%,电子商务已经开始影响传统主体经济。   体量足够大,就有数据可供挖掘了。   例子一,去年到上海参加软件开发SD2.0大会,淘宝的数据可视化讲座,给出了女性内衣的尺码数据统计,平均值从前几年的A罩,迅速增大,目前居然达到了C罩杯。因此得到两个结论:<1>中国人的营养水平和肥胖率不断上升,<2>上淘宝买东西的女性年龄在增大,已经越过了婚育年龄均值点。   例子二,2010年温总理去淘宝视察,马云的报告里说,由于阿里巴巴有真实的外贸订单数据,淘宝有真实的国内零售数据,所以可以据此预测未来半年的全国经济走势。那时候马云PPT里的预测,现在印证起来,相当准确。   屁股决定上层建筑,有了数据金矿挖掘的利益驱动,相关的技术投资就会被重视,然后就构建出新的技术平台和商业模式来。Amazon的营业收入中,越来越大的比例源于计算和存储能力的对外租用,也就是云计算。它已经不知不觉变成了云计算市场的领袖,甚至威胁到了伟大的Google。   回来再说我们pFind的事情。最近半年多lyz美女一直在开发pFind@hadoop。此前也讨论过生物信息云计算。   首先用MapReduce创建离子索引还挺顺利,然后就开始写查询这一块。方案是利用HBase进行存储,利用Thrift进行结构化和远程调用传输。但性能一直是问题,hchi用C++写的单进程处理程序(把数据索引分块,逐个载入查询),居然和Hadoop版的64核集群的速度差不多。进行了大量的优化,并请教了在搜索引擎公司的Hadoop牛人,依然达不到期望。   在很小的质谱数据集上,pFind就要发起接近百万次的离子查询,这种规模的并发,已经远远超出了HBase常见的应用方式。于是反思方案本身。HBase的特点是支持随机写入,引入了并发事务性管理机制。因此,它更合适需要增删改的online实时处理,其替代对象是传统的SQL关系型数据库。   而对于全文搜索类的应用场景而言,其预计算索引一般只需要顺序批量写入,不必支持随机改和删除。所以可以直接把索引存入HDFS,自己实现查询。由于不用支持随机写入和删除。也就是几千行代码而已。最新2011.12期的《程序员》刊登了推特Nathan Marz的文章《如何打败CAP定理》,他们的方案是采用Elephant和Voldemort read-only这一类可以直接从Hadoop MapReduce中导出key/value的数据库。这些数据库都不支持随机写入,简洁使其鲁棒性特别好。这种方式不能更新数据,每次都需要全局重做。但生物数据库对实时更新并没有太高要求。   (补:Guancheng大虾提示说,把Hadoop实现的版本跑在512甚至1024核上会不会比C++单线程版本快?把input size增加几倍的话Hadoop版本的Scalability会不会更好?)   再记录一件事。大红大紫的redis的维护者刚刚拒绝了微软提交的补丁。补丁的目的是让redis可以在Windows系统下运行。拒绝的原因是Linux completely won as a platform to deploy software(作为工作软件的部署平台,Linux已经完胜win32)。维护者认为应该把精力集中在真正重要的问题上。   这一期《程序员》杂志的企业软件专题里面,主编表达了与此相关的一些观点。最近五年以来,Java和C#这些语言逐渐不那么招人喜欢(看这个链接和这个链接)。企业级开发、Windows开发的形象变得过时。像我这种有点年纪的程序员,难免总会有点三十年水流东三十年水流西的感慨。   云计算是现在最热的buzzwords,小心,IT领域的大词,总会很快过时。

哪吒和太空镜子

  上月底哪吒第一次对合作伙伴提供在线服务。开始和hchi哥、lyz美女折腾pFind@MapReduce。   以前写过思路,pFind原本是一个计算密集型的应用,面对擅长IO密集型的MapReduce模型,不只是把MPI版本代码移植过去那么简单,要从根子上重新设计整个框架。刚好hchi哥经过近半年的思考和实验,在算法上有了突破性的点子,我们一拍即合,开始动手干。   如果成功,pFind 3.0的架构就与信息检索领域的那些典型应用(例如Google搜索引擎)很像了,把目前的第一代蛋白质鉴定搜索引擎落下半里地。当然,刚开始做,有不少算法和工程问题需要啃。等待我们的论文和专利吧。   晚上陪老婆在小区里散步,看天上的星星发呆。然后对老婆说:人类可以在太空里建立一面巨大的镜子,用来挡住北京城的阳光,天气就没那么热了;反过来,能挡住就能反射,可以向阴冷地区或夜间的灾区送光;再邪恶一点的话,能反射就能制造成透镜,当成武器,瞬间聚焦地面某个区域,甚至融化南北极……老婆没有照例说我是邪恶的理工科,而说,你该写本科幻小说赚钱。这念头并不新奇,估计已经有人写了,甚至申请专利也说不定(用Google搜索全球专利,会发现很多有趣的奇思妙想)。回来一搜,果然刘慈欣已经写了这篇《中国太阳》。   由这个链接,发现42qu已经上线新版本了。   说到刘慈欣的小说,还有一件事值得敲出来。小学二年级的外甥壮壮很聪明好学,喜欢读书。前两天发现他在读《三体》的第三本。刚开始觉得,对小朋友来说这是不是太黑暗绝望了。转念一想,别太低估他们的心智了。倒是发现周围有些成人很少深度思考,只顾着纠结眼巴前那点儿事,应该找机会跳出来读读超脱点的文字。   想上来列书单,最近忙,原以为不会看太多新书。没想到一整理有十几本,还是太久没写BLOG。懒,明天再说。

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

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

“哪咤”系统第一个milestone明天组内alpha发布

  最近半个月和zf双人编程,全力开发“哪吒”系统。   和Web搜索引擎不同,pFind有自己的专业特点,最大特点就是要求尽可能高的查全率和查准率:平常Web搜索,大多数用户很少翻看三、五页以外更多的搜索结果。而对我们这个领域而言,质谱仪器原本就有很高的精度,数据集里那些含量稀少信号相对较弱的蛋白质,却往往正是科学家和医生们最重视的研究对象。pFind引擎有几十个参数,虽然很多默认推荐值经受过数百万数据的考验,但是在具体数据集上总会有优化的空间。   也就是说,花费上万块钱成本得到珍贵实验数据,不能只拿pFind引擎常规参数“一搜了之”,需要进一步大量深入分析。例如过滤和校准质谱数据,极端情况下通过数据发现前端实验过程和仪器维护中的问题,回去重做实验;再如进行初次试搜之后,对鉴定结果进行统计分析,优化参数,改变选项,再进行迭代搜索;又如,利用多种搜索引擎交叉验证,甚至是多种方法结果的相互对比验证(例如常规的基因翻译蛋白序列库搜索引擎,最近新兴的谱库搜索,以及探索性最高的de novo算法)……   每年iPRG国际评测中,使用同样搜索引擎的人,有排名前十位的,也有结果完全不像样子的。蛋白质组学的领军人物发表论文说:“赛车好,还需要王牌赛车手。生物组学领域的瓶颈目前是数据分析,而分析成果又很依赖优秀分析人员的经验”。像rxsun,yfu,zf,hchi,cliu等虾米,都是江湖上知名的质谱数据分析专家了。   深入解析依赖人工工作大大降低了效率。随着pFind的进展,我们与越来越多国内外生物学家建立了合作关系。然而每月收到成T的数据,每周要提交的分析报告,海量的工作量,把所有人都压垮了,不得不放弃很多送上门来的合作机会和经费。   数据解析的全流程自动化,国际上都在全力探索。例如现在红得发紫的Maxquant就做得不错。pFind组有不错的基础,由于有牛人yfu和他那一帮超常的算法研究天才在,我们在谱图搜索、de novo、修饰发现等等方面也有自己的独特之处。至于工程能力,生物实验室那些非计算机专业作者用C#写的桌面级别代码,要进一步拓展到大规模集群,甚至通过云计算提供在线服务,还差得很远。而这方面是计算所的长项。在超级计算机并行加速方面,我去年论文成果数据的可拓展性达到了320核,不谦虚地吹嘘,超过了全世界竞争对手目前为止公开报告数据效果一个量级,其实我已经做到了1000核,马上要做2000核。   通过pFind云提供对外服务,这始终是我的梦想。为此努力了5年,今年终于开始着手了。也许,它能成为未来生物医药数据处理的基础构件之一。   要建立实用的平台,就需要把方方面面的工作集成起来,解决大量很有挑战性的难题,例如单从并行加速这一个技术需求来看,不再像加速pFind搜索引擎这一具体环节这么简单,需要考虑整个流程各个环节的不同特点:在海量数据吞吐的地方,如全基因组翻译和索引,用得到MapReduce这一套;而打分鉴定这种95%CPU的工作,需要精心设计MPI类的程序;另一些特别的算法,例如de novo里面的动态规划,也许得考虑GPU加速……其实,加速还是最好做的事。   加班很累,一写BLOG又兴奋了,也是最近密集开发,没空上网,想写的东西比较多吧。明天带“哪咤”的雏形出来见人,这个平台尝试把组里pFind、pBuild、pCluster、pMatch、pXtract、pParse、pNovo等等主力软件串联起来,无人值守的对海量数据进行尽可能全面的挖掘,我们希望听取各位的意见。

2006年BLOG列表

Todo List  SOAP、Ajax、REST和thick client  本周收藏.2006.12.22  Hey Jude  夜来思得千百计,白天还是磨豆腐  《寻找无双》和《红拂夜奔》  用Javascript实现《星际争霸》  《墨攻》  投稿和借书  界面和过渡技术  冲刺  今天emileyuan的BLOG  XP和项目管理  金山岭到司马台穿越  升级到CppUnit 1.12.0  Firefox2.0和Gem老大  本周收藏.2006.10.23  最难的是开头  暴走三环归来  纪念鲁迅先生  最近C++0x信息收集  本周收藏.2006.10.13  《圈子圈套》  《围棋》  推荐《三体》  新装备  本周收藏.2006.10.02  穴居和科研  《海鸥乔纳森》和《当代英雄》  Bigtable论文  本周收藏.2006.09.24  穿越归来  鹅肝、登山鞋、非法卖唱和世界无车日  旧作品  本周收藏.2006.09.16  头晕  TDD、椅子和简历  重返人脸识别,富士康的和谐社会  FDR实验完成  本周收藏.2006.09.02  喝到水了  质量精度  M和水蜜桃  本周收藏.2006.08.27  KernelTrap,晕  慎独  本周收藏.2006.08.20  客户亲和力和自组织型团队,还有某个幸福的Googler  算瑞是什么  开始用ICE写程序,组里来新人  本周收藏.2006.08.13  […]

流水帐.2010.10.4

  还没有确定是不是WordPress.com。办妥了会通告。先补前一段时间落下的内容。好久没写BLOG,不好意思。   9月份工作很紧张,终于把软件著作权、专利和商标的申请都搞定了。pFind并行版内容最终拆分为三个互相掩护的子专利,因为涉及到MapReduce技术,还特意和专利代理律师一起研究了有关资料,除了论文,还包括今年1月份刚刚公开的7650331号专利。这期间还注意到一条新闻:Google最新版引擎Caffeine已经放弃MapReduce架构。接下来补更多实验,要啃一个超过五百万张谱图的庞大数据集。偏偏碰到深腾7000停机修整,踅摸中……   最近不仅没精力写BLOG,也没空买书。前两天才抽出空来去了一趟中关村图书大厦,买到了爱德华·吉本的《罗马帝国衰亡史》、沈群的《美国也荒唐》、W.Bruce等的《搜索引擎》(也就是Search Engines: Information Retrieval in Practice的中文版)、周汝昌的《红楼小讲》、林语堂的《平心论高鹗》。

Sector&Sphere

  大约一个月前读了Sector and Sphere: The Design and Implementation of a High Performance Data Cloud这篇论文。后来在组会上做了文献讲评。一直想BLOG分享,今天抽空补上。   Sector/Sphere可以看作与GFS/MapReduce或Hadoop竞争的另一种云计算的基础设施。相对于Hadoop,它的特点是提供了更好的性能和安全性。如果云计算集群跨越不同地理位置的多个计算中心,Sector/Sphere的优势就能得到最大体现。从Terasort结果来看,同等条件下,其性能比Hadoop高出不少。   之所以能有这么好的性能效果,除了Sector/Sphere是用C++实现(而Hadoop是用Java)的天然优势以外,数据传输使用UDT协议(而不是常规的TCP)是一个独特之处。关于UDT协议的技术细节可以参考这篇论文,这项技术获得了2006、2008和2009三年的High Performance Computing, Networking, Storage, and Analysis会议的Bandwidth Challenge Winner。   因为有了UDT的独特创新,Sector/Sphere在数据吞吐方面就有了很强的核心竞争力。论文里提到:典型的Web应用,例如搜索引擎查询一个关 键词,尽管计算过程涉及很大规模的数据I/O查询,但是算法的输入和输出的消息尺寸本身是相对较小的。而对于典型的科学计算任务,输入输出数据本身往往也 很庞大,例如作者自己从事的天文学项目SDSS中,要先输入几十T的天文望远镜照片,再从中分析寻找褐矮星。这就要求面向这一类问题的云计算底层机制拥有更高的数据传输性能。   在基于串联质谱的蛋白质鉴定中,海量数据的传输同样是瓶颈。这也是pFind集群版将要涉及云技术时,我对Sector/Sphere产生兴趣的主要原因。   再列一些八卦信息。Sector/Sphere的第一作者Yunhong Gu拥有中国大陆的教育背景。而他所在的Oregon State University’s Open Source Lab被Network World杂志评选为美国10个最酷的网络实验室之一,入选原因就是研发出了Sector/Sphere。

断网断电话一段时间,还有pFind的千核并行进展

  从明天开始,我在一段时间内无法上网,也无法接听电话。   顺便说说pFind Studio进展。最近hf和xs在全力完善pBuild 2.0。稍后我们会向全球用户群发邮件,邀请大家试用最新版本。另外,于上个月在深腾7000超级计算机上刚完成的实验中,pFind千核并行取得了满意的加速比。瓶子哥正在拼搏(站好最后一班岗),在2048核处理器规模下试验更大规模的数据。   俺们算初步解决了多修饰海量谱图的高效并行加速问题。用户可以选定15种之多的修饰,或者把母离子误差开到500Da之大,pFind百核集群都能在常规时间内完成搜索鉴定。而现有的公开报道中,世界上其他竞争对手超过32核加速效率就会变差。大言不惭地说,俺们在并行加速方面获得领先。   但仅考虑海量谱图是不够的,如果面对超常的巨型蛋白质序列库(例如直接搜索人类基因组数据,或这两年很热的用恐龙化石中提取的蛋白质搜索全生物库的需求),主流搜素引擎目前还都无法做到有效并行。仔细分析可知,这种情况下搜索引擎的运算特点就从以计算密集型为主,转为计算密集型和I/O密集型兼有,接近Web搜索引擎。也就是说,Google MapReduce那一套有用武之地了。

头晕和踢踏舞

  最近我把pFind搜索引擎的并行版逐步由传统“单Master/多Slave”模式向多Master的机制重构,Master的模式很接近 MapReduce。这是为了提高千核CPU并行下的I/O效率。两周前又着手准备pFind Studio 2.4的发布。累坏了。上周六开始偏头痛,周一凌晨甚至从梦里疼醒过来,早上10点才爬起来。这几天脑袋一直晕晕的。硬扛。   经过周扒皮对长工们的剥削,pFind Studio 2.4的Bug逐渐消失。明天Release Candidate版,最后征集意见。   从昨天开始抓住瓶子双人编程,在集群跟同步异步消息反复纠结。今天下午结果终于对齐了。神清气爽,头也不晕了。晚上回来还停不下来,继续敲键盘重构代码。   (原来MPI也提供像MPI_Reduce这样的机制,和Hadoop比起来编程细节繁琐些,运行效率还不错,就是老土一点。)   最近一两年和人打交道比机器多,从Code里体会到的乐趣也没有高中时代写游戏、大学时代hack美女上网密码那么high了。不过我还是喜欢编程,还是为“软件工程师”的称号而骄傲。巴菲特说,只给那些每天跳着踢踏舞去上班的人投资。愿老天保佑俺们和俺们喜欢的工作吧。

容错、书单、pFind和pNovo的国际初show

  今天加班有点累。掐着点坐末班地铁回到家。喝水休息。又好一点了。上来随便敲点,放松一下。   wyj美女正在跑超大规模的实验,我要帮她完成一部分。但最近时间紧张。今天索性抓她一起完成,交叉检查避免疏漏。到晚上22点,384组实验的参数总算全设置完了,我们都接近崩溃。然而,跑起来,集群速度不正常。瓶子帮忙检查了好久。有些灯枯油尽,又要赶地铁,明天再继续。   感觉是硬件问题。最近某个节点似乎一直在“带病坚持工作”:也不彻底死机,就是超级慢。遇到这种问题Google系统的常规做法是把长时间“不归队”的节点放弃掉,将其任务重新平分给其他各节点。pFind目前对此还没啥特别措施,Mascot、SEQUEST和X!tandem等竞争对手的集群版也没考虑。   可用性应该是云计算设施的基本要求,也许比速度甚至精度还重要。算算概率,Intel CPU理论上连续运行10年出现一次浮点计算错误,这就意味着上千核的集群每2小时就错一次(还没考虑其他更容易出问题的部件)。也就是说,在大规模的廉价商业集群上长期运行的软件,必须把硬件错误当作常规事件,考虑对应的鲁棒性设计。Google就强调GFS、MapReduce和BigTable的最牛之处并不是峰值速度或数据吞吐量,而是其在廉价集群硬件上的稳定性和容错能力。   跑题,列点最近几天新买的书:《Search Engines — Information Retrieval in Practice》、《Out of Mao’s Shadow》、《一九八四》、《伊斯坦布尔——一座城市的记忆》和《一个人的电影》。发现前两本英文书居然看得最快。第二本书,是hchi去美国参加RECOMB Satellite Conference on Computational Proteomics 2010给带回来的。走之前他问我要带什么。我随口说:“带本书吧”。结果他就千里迢迢从美国带回来一本华人写中国的英文书。我该早预计到这个结果的。当然,书是好书,还是要感谢。            顺便自豪一下:这次rxsun老大参加iPRG 2010磷酸化数据鉴定评测,pFind引擎在全世界人民面前一鸣惊人了一把。而hchi哥的pNovo更是让de novo算法的主流人物服气了。(伟大的hchi哥进入de novo领域才半年,真快。)