Category Archives: 0和1

生物信息和云

  云计算在生物领域面临几个问题:首先是计算密集型和数据密集型的平衡,其次是授权管理和安全问题,第三是T级别甚至P级别海量数据的实时传输和分发。最近读了几篇相关论文,分享一下。

  Clare Sansom刚发表在Nature Biotechnology上的Up in a cloud?这 篇文章分析了美国市场上生物云计算的问题和趋势。云计算包含多种商业模式,目前亚马逊式的“公用云”租用已逐渐普及,租用计算资源的用户中生物领域占到了 一定比例。相比传统的超级集群租用,这种形式优势更便宜更灵活,能做为对外服务的基础。但安全性和授权管理还是制药公司和生物研究单位的顾虑之一。

  与此相关,Eric E. Schadt等人在Nature Reviews Genetics刚发表了一篇题为Computational solutions to large-scale data management and analysis的综述,更深入地对生物领域的云技术进行了汇总,介绍了超级计算机、网格计算、云计算和异构并行(GPU)技术在生物计算中的成功案例,并对比了其不同的应用特点。

  同时,Joel T Dudley和Atul J Butte在Nature Biotechnology发表了一篇文章,题为In silico research in the era of cloud computing, 主要从另外一个角度展开讨论。由于生物学研究越来越依赖大规模计算,同行间重复别人的工作面临着很多软件和计算问题。而可重复性 (reproducible)是现代学术体系的基石。作者希望利用虚拟机技术提供同行评议时的可重复性,同时又能保护必要的知识产权和技术机密。

  另外几篇,Michael C Schatz发表在Nature Biotechnology上的Cloud computing and the DNA data race,以及Monya Baker发表在Nature Methods上的Next-generation sequencing: adjusting to data overload,都主要涉及新的测序技术导致的数据剧烈膨胀。

  还看了Sector/Sphere作者在SC09(The International Conference for High Performance Computing Networking, Storage, and Analysis)上的论文Lessons Learned From a Year’s Worth of Benchmarks of Large Data Clouds。如果看过Sector/Sphere最早的论文, 再读这篇就比较轻松。这篇文章对Hadoop和Sector进行了更详尽的对比。相对源于Web搜索引擎的Hadoop,源于科学计算领域(在海量天体照 片中搜索可能存在的褐矮星)Sector先天具有一些特点:例如C++比Java的性能优势;例如可跨数据中心运行的安全机制;再例如UDT协议(UDP-based Data Transfer Protocol)比TCP协议在海量数据传输分发方面的优势……

  Sector/Sphere作者刚刚创业,建立了verycloud.com公司,提供云计算领域的咨询和定制开发。

  一直希望建立pFind“专有云”,向Google一样提供行业数据处理的在线服务引擎。因此,除了领域算法,还需要掌握一整套软硬件维护和运营能力。这很难,但如果成功,则不可替代性很强。不仅仅可以避免传统软件的桌面维护,避开盗版,让反向工程模仿成本大大增加。

  游戏产业放弃单机版转向网络云技术是一次成功的突围。生物信息能重复这个故事吗?

Sector&Sphere

  大约一个月前读了Sector and Sphere: The Design and Implementation of a High Performance Data Cloud这篇论文。后来在组会上做了文献讲评。一直想BLOG分享,今天抽空补上。

  Sector/Sphere可以看作与GFS/MapReduceHadoop竞争的另一种云计算的基础设施。相对于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。

章文嵩的技术报告

  上周末,淘宝网基础软件研发部的负责人章文嵩来计算所做技术报告,一直想记录一下。最近三天在家里照顾病人,所以没顾上写BLOG。

  大约是十年前在AKA的网站认识了章文嵩和他的LVS。 那时候我刚刚接触开源,正在阅读Linux内核源代码,积累俺的《joyfire linux笔记》。当时LVS正在争取成为第一个汇入Linux内核的Made in China项目,我等粉丝狂热崇拜,《joyfire linux笔记》里有专门一章收录LVS技术资料。

  隔了这么久,章文嵩的外貌似乎没啥变化。这次报告主要介绍淘宝网的基础设施,例如分布式文件系统(TFS)、K/V缓存系统(TAIR)。细节可以参考幻灯

  章文嵩提到他们正在踅摸倒排索引等技术,研发上千亿规模的全文检索功能(淘宝网站现有40亿条目,每年翻一番)。另一个设想是图片搜索,预计2年初步可用:女孩子们可用3G手机拍摄商场里的衣服和鞋子,然后发送到淘宝网站,搜索类似的商品信息。

  章文嵩认为,在网络服务基础中间件领域,商业专有产品性能无法令人满意,淘宝正在实施开源战略,一方面用开源产品把现有平台逐步替换掉,另一方面也对自主研发的基础设施进行开源。他们的TAIR刚刚开源,TFS 预计会在9月份开源。

  目前淘宝网平均一笔交易耗费0.4度电,可以煮熟4个鸡蛋。因此和Google一样也开始关心能耗问题,希望定制 低功耗的服务器。考虑到Memory Cache和Web Service等模块大都是I/O密集型的,对CPU主频要求不高,没必要安装最强悍的CPU。章文嵩抱怨INTEL只看重利润,漠视环保:淘宝希望大规 模采购ATOM处理器,得到的回答是“不符合公司战略”,不愿意ATOM挤占高端芯片的市场。最终选用了VIA处理器,关闭不必要的主板模块如USB,能 耗大大降低,实现了无风扇,依然有不错的处理吞吐量(单机柜6Gbps)。

pFind集群的论文正式发表

  俺和瓶子的pFind集群论文:An efficient parallelization of phosphorylated peptide and protein identification已在英文期刊RAPID COMMUNICATIONS IN MASS SPECTROMETRY (2.772)正式发表。

  论文主要论述了我们在并行加速方面的研究。实验表明:pFind搜索引擎对一个含有100个Raw文件的磷酸化公共数据集进行鉴定,在100个处理器核 上,加速比为83.7;对另一个更大的、共含有1,366,471张质谱的磷酸化数据进行鉴定,在320个核上,加速比为258.9,加速效率达到 80.9%。

  目前pFind并行版已经投入一线分析实用。俺们正在千核条件下继续研发。

pFind引擎内核建立Trace机制

  必须上来写点,否则对不起订阅BLOG的读者了。

  这周我们封闭开发,重构pFind引擎内核引入Trace机制。我预研了Log4cppACE_TRACE的源码,还是决定自己动手实现底层机制,更贴近pFind系统的实际要求。

  像pFind这样的复杂系统,不免有大量输出信息,有些是给用户看的,有些是程序员调试时用来追踪进度和现场情况的。传统做法,调试信息会被用宏开关控制,产品发布时被关掉,以免输出过于庞杂导致用户体验变差,但这又会增大事故现场诊断Bug的困难。要调和这对矛盾,就需要灵活的Trace机制,通过设 置参数实时控制输出,例如范围(指定的算法模块、线程或集群节点)、级别(过滤或保留debug信息)和目标(命令行输出或写入日志文件)。

  这种基础设施涉及到整个系统,大部分模块都需要重构,工作量不小。在Win32下开发调试比较顺利,移植到曙光大机的64位Suse Linux时,出现了一些动态链接问题,调整了模块划分。(为了解决这个问题,去查阅俞甲子、石凡和潘爱民的《程序员的自我修养——链接、装载与库》,的确是好书。)

程序员的自我修养

  遇到了Gcc 3.4.5的这个Bug,编译STL总会出现大量Warning。从GNU Bugzilla上的讨论来看,Gcc 3.*系列的维护已经停止了,推荐升级到4.*系列。一直想升级pFind的默认编译器,但之前尝试时,ACE在Gcc 4.4(MinGW)下无法正常编译(刚刚搜索,貌似今年1月份刚刚有人把这个Bug解决掉了)。像陈硕这篇BLOG说的,ACE很值得学习借鉴,但代码臃肿,有很多使用问题。

  在重构后期,大家已经开始利用Trace本身进行调试。“吃自己的狗食”是个好现象。

  建立Trace机制、升级Gcc消除Warning,都是为单元测试(Unit Test)和持续集成(Continuous Integration)做准备。自动化测试是我今年的重点目标。衡量一个团队有多精锐,不在于统计技术牛人的个数,而要看它是否拥有超出平均水平的制度 平台。我发现凡是不用版本管理(SVN、CVS或VSS均可)的软件开发组都很烂,甭管团队里有多少能工巧匠。前瞻研究实验室年度汇报,听到浩哥讲Godson-T的开发,他们就构建了很强大的自动化测试平台,让人不服不行。

  还在考虑为pFind引擎构建“黑盒子”机制,把一段时间内的系统实时状态都记录下来,用以重现事故现场。云风做过类似的设计。不过这样一来,如何保证运行效率就成了关键问题。

  这周很累,但有成就感。接下来折腾RCMS论文,19日deadline。大家的批改纷纷返回,多谢,汇总中。

参加Beta技术沙龙,主题是推荐系统

  周日去奇遇花园参加Beta技术沙龙,这次主题是“推荐系统在大型网站中的应用”,是和Resys合办的(说起来俺也起了点儿牵线搭桥的作用,哈)。推荐系统果然很热门,参与的人比以前都多。

  第一个主讲人是dangdang网的技术总监王洪涛。从产品经理的角度介绍了dangdang的推荐系统。从业务需求的视点去看,实现什么算法反而不那么重要了,关键在于整体把握。网站做到什么程度需要引入哪一类的推荐系统?如何评价系统的效果?另外对用户体验的拿捏也是个重要问题,必须既给用户惊喜,又不讨人烦。

  接着讲座的是付超群,以前在新浪音乐开发推荐系统。他从技术上介绍了推荐算法和工程实现。主要涉及了关联分析、slope one和SVD三种算法,内容很足,言简意赅没废话,我个人很喜欢这个报告。

  国内评价和推荐做得最好的应该是豆瓣。有人问dangdang是否考虑在书评挖掘方面深入做些事。我想,豆瓣的领先地位,除了源于技术,更重要的是来自 “第三方”的超然位置所带来的高质量评价内容,以及这些评价数据背后的深度参与人群。王洪涛回答时也说,dangdang上的书评,很多是抱怨送货和售后服务的,而豆瓣就没有这个包袱了。其实单个企业很难全面覆盖产业链条,合作共赢才是正理。

  顺便提一下,企业的技术形象很重要。dangdang站内搜索的口碑不好。结果每次圈子里交流,他们的工程师总是有点尴尬,心虚郁闷的样子,忍受周围的朋友拿各种雷人的搜索结果开涮。物质待遇以外,工程师还很需要专业上的自豪感和认同感。

Hadoop in China 2009印象

  昨天Hadoop in China 2009在计算所召开。有主场之利,就混进去听了。把印象最深的内容写一写。

  总体感觉规模很大,组织相当严谨,内容具有多样性。一方面,Hadoop in China前身是开源社区的线下技术沙龙,骨子里带有草根性,相当多的报告都是年轻的一线工程师在讲实实在在的最新项目;另一方面,这次又请来一些拥有行业视角的大公司技术高层,分享了不少全局信息。

  第一个超出期望的是中国移动研究院院长黄晓庆。原以为礼貌上请赞助单位发言,不差钱的央企,“大云”肯定是炒概念。没想到还真讲了些好玩的研发内容,甚至对Hadoop内核做了不少改进。正因为有实际工作而且打算开源,所以就有深入的思考: “下面是我对开源社区的建议。首先,Hadoop应该更全球性。很高兴看到72%的贡献来自Yahoo!,但这对Hadoop长远发展并不是最好的,Hadoop用户应该提供更多贡献。另外,希望建立基于开源社区的云计算规范标准,使应用不只绑定在某个特定平台上。”报告英文很流利,讲得台底下的 Yahoo!技术高层直点头。

  来自Facebook的报告特别吸引人。除了技术本身,数据仓库这种应用场景也很酷。底层设施需要按照 ETL、数据挖掘和决策支持的特性进行调整,例如利用Hive支持SQL,以便商业分析人员使用。查了一下,已经有三篇论文引用Hive,都是比较顶级的会议。相对我个人而言,以往关注都限于搜索引擎范围内。这次意识到Hadoop已经被用于很多领域。

  Cloudera帅帅的创业者(长发,山羊胡子,真的很Geek)列出了Hadoop的应用领域:像NTT KDDI和中国移动这类的电信公司用Hadoop分析用户信息,优化网络配置;美国供电局用Hadoop分析电网现状;包括VISA和JP摩根在内的金融公司用Hadoop分析股票数据;包括Amazon和ebay在内的零售商和电子商务公司也开始使用Hadoop……他还特别提到生物公司用Hadoop 进行DNA测序和分析。

  有事错过了Google公司的报告Challenges in Data Processing in the Cloud。

  下午Track很多,在分会场来回转移。之后主要听了下面几场:

  • Hadoop at Facebook: Past, Now and Future (Zheng Shao@Facebook)
  • Mumak — Using Simulation for Large-scale Distributed System Verification and Debugging (Hong Tang@Yahoo!)
  • Monitoring Hadoop (Yunsong Huang@IBM)
  • The Distributed Storage in the Search Engine (Kun Zhang@Netease)

  前几个报告都能在网上搜索到相关技术资料,不多写。

  后一个报告介绍网易的封闭项目,也算是与Hadoop对照。网易在国内算是技术布局早的,几乎是一看到Google老三篇就立刻照着实现。报告前半部分讲如何选择不同的分布式存储设施。把分布式存储系统分为三类:类似GFS的,类似BigTable的,还有Key-value方式的。对于GFS这一类,提供接近Unix文件的API,适用于必须对数据进行顺序全扫描的应用场景;对于BigTable这一类,提供分字段索引排序,适合需要随机查找的应用;而对于Key-value这一类,强调响应速度,更适合当cache用。报告后一半都是案例,分享重点是解决问题的思路,而不是问题本身。

  大会最后的Panel Discussion。从听众提问看,在国内Hadoop还有待普及,很多技术人员甚至不太熟悉开源基础。百度的Ruyue Ma提出,不要指望万能药方,每种技术方案都有适用区域,传统的MPI也有自己的独特优势,未必所有应用都必须移植到云平台上。多位嘉宾强调,第一关注点应该在于可拓展性,而不是性能。

  顺便提一下,国内企业今年突然都开始投入分布式技术的研发。很多家公司同时打算或正在开发自己的GFS、MapReduce对应产品。我倒觉得,现在才动手的话,不如选择成熟的开源方案,这样招聘、培训和合作的成本较低。

狗血时代、百年老店和Objective-C

  昨天早上偏头痛,晚起了一小时,因为有些工作放心不下,还是强令自己去上班。午饭和晚饭都没吃。下午和领导谈工作的时候,已经有点灯枯油尽了。晚上10点回来,吃了点东西,包裹在被子里喝啤酒,看“游戏风云”频道演示《猪兔大战》。

  以前看到北京女病人BLOG这篇《被隐藏的时光》,和朋友笑言,俺的狗血时代终于过去了。好像很多功成名就的人物都说过,最快乐最令人怀念的时光,正是那默默无闻、野心勃勃、累死累活、年轻气盛、大喜大悲的几年。

  前天开会,fy大虾最后讲,他的PPT里写“什么是百年老店,就是人死了,店还在。”

  点开09年10月的TIOBE编程语言榜。趋势很明朗。Java和C/C++语言稳占鳌头;PHP、C#和JavaScript稳步提高;而随着iPhone所向披靡,尤其是App Store模式的猛烈发展,Objective-C像坐着火箭一样猛烈崛起,相信很快就能闯入前10。

Joel 12条和2006年

  Tinyfool刚刚发了一篇关于著名的Joel 12条的BLOG。我很有成就感。

  一直用Joel 12条作为软件工程实践的基本底线。这12条很朴实,我也实践得很朴实:时不时在PPT里把这12条拿出来给现状打分,不停唠叨直到他们养成习惯,这样坚持了4年。刚开始只有3分。现在超过10分。

  事实证明效果很好。不谦虚的说,这个学生为主,还要兼顾大量科研任务的团队,工程效率超出了很多软件公司。双人编程、重构、代码审核等高级的软件工程实践,是建立在SVN版本管理这类基础设施之上的,这是常识。

  这些年pFind Studio各个软件不断上演龟兔赛跑的故事:刚进入某领域时总是显得缓慢笨拙,等过了2.0版,团队协同的平台效益就明显起来;而很多同行系统越大越纠结,一旦核心牛人的热情和投入减弱,很快就成了焦油坑,演进陷入停滞。

  说到水面以下的积累,前几天“超龙一号”评审,有个院士表扬我们组,举了一个美国国内的统计:持续专注少于8年,团队人数少于8人的科研团队,全部失败,没有一个团队能持续搞出牛的科研成果。

  到现在为止,pFind团队坚持了7年半。

  最难的时光?也许是2006年。那一年,整个组没发表一篇论文,没拿到一分钱,没申请专利和软件著作权,每次例会都有种沉重的气氛。

  但也是那一年,团队下了决心把pFind彻底推倒重来,静下来,老老实实打磨,一次次反复跑实验。现在回头看,个人记忆里,那是困惑挣扎的一年,也是幸福充实的一年。从那以后,开始对pFind变得自信,对自己变得自信。

  BTW:北京、山东、天津、上海又一次集体输球。这次我彻底服了,不知hchi哥服不服。

用户易用性就是容忍犯错和偷懒

  如今无论哪种软件产品都在强调用户体验。本质上,AJAX这一类近乎变态自我折磨的界面技术的热门,不是Geek式的炫耀,而是为了提高用户易用性。

  用户易用性的核心,就是容忍用户犯错和偷懒,就是摆正心态:软件是仆人,而且要达到英国贵族管家的档次。

  举个例子,微软Office到底好在哪里?录入一篇英文文章,不慎把三个字母的常用小词,例如and或the,敲错了顺序,弄成了adn和teh,一敲单词后面的空格或标点符号,MS Word就会自动帮你纠正过来。

  别小看这个功能。一方面,对需求边界的把握是一门艺术:刚刚好有用,又避免算法自作聪明,用户常用到它,却意识不到它的存在。另一方面,实际也有很高技术含量:只有adn和teh才纠错,而其他字母排列不纠错,这是进行过“双手盲打”的人机工程学研究统计的。

  设计者对产品的态度,就可以了解其职业能力和素养。总认为“这是用户该保证的”,不愿意完善异常处理的人,总是抱怨“请给点建设性意见,别老挑刺”的人……都命中注定做不出伟大的产品。记得《项目幸存手册》里说,听到程序员说出“哪来的这么笨的用户”这种混蛋话,就想跳起来骂人。

  “傻瓜式的相机”成就了日本电子产业。对软件和网络行业来说,马太效应更加明显,Jobs式偏执狂席卷一切,拙劣的山寨仿制品,中国式的小聪明,走捷径,长久不了。

  pFind的用户群都是科学家,极有条理和耐心的铁人,主观摸索欲望很强,不喜欢抱怨。对产品来说,这并不是什么好事。年底将发布pFind Studio 2.4版,会集中解决用户易用性问题,不是泛泛改善,要做出吓人的惊喜来。敬请期待。(正在收集改进意见,欢迎被我们软件痛苦折磨过的小白鼠们发邮件来控诉和诅咒。我们准备设立一个奖金,年底颁发给抱怨最多最毒的用户)

  08年初放出“把Mascot打得满地找牙”的口号,现在看来实现比预想快。今天Boss H问两年后,我说“如果pFind免费,拿到50%的份额;如果不免费,拿到33%的份额”,他们说新一版狂言诞生了。真的只是狂妄自大吗,拭目以待。

  BTW:hchi哥今天的PPT引起俺的赞同。要追求完美,不作自甘平庸的笨蛋;又要平常心,不抱怨,不喜怒无常,保持幽默感和倾听能力。同志们,遵从hchi哥的教导,勇敢前进了。