去Intel测试、下一版的昵称

  连续加班。筋疲力竭,死扛,晚上总做噩梦惊醒。今天全天开会,16人次讲PPT。晚上聚餐,算是告一段落了。   前天应邀去Intel公司测试pFind并行版。是国贸旁边的那个实验室,就在央视新楼对面。公司的落地窗正是看焰火的好地方。ch博说,09年元月十五,他就在办公室。   pFind表现正常。因为时间所限,测试参数不能设置得过“重”。以前提过,随着并行规模的扩大,pFind集群开始出现I/O密集型应用的特点。下一步的千核集群,Master节点应改成异步模式,很多步骤要用MapReduce。    从08年底开始做pFind并行计算,逐渐加深理解。现在看来,要兼顾“减少流程冗余”,“均衡负载”和“提高I/O效率”三个要素,才能获得好性能。其实,明确这三个问题,比解决它们更重要。如果RCM论文搞定了,就在BLOG里写写我们的解决方案。   这次跟着高手学到不少。比如以前不知道用make -j参数,每次编译ACE,都得用三四十分钟。再如这次ch博推荐的paratera.com工具,对分析集群实时状态很有用。   下一版的pFind内核还没规划,但是已经开始琢磨“昵称”了。按照我们的惯例,需要是科幻或动画角色。我强烈要求用Leonopteryx,《阿凡达》中的红色大鸟。

这一期小姬看片会很好玩

  前瞻研究实验室年终考核。自己的总结一般般。倒是从别人的报告里收益不少。本想在BLOG上记录一些。周末在家始终无法正常访问live.com,刚刚才恢复。要休息了,稍后再说。长时间不更新BLOG很不好,所以上来随手敲点,想到哪里是哪里吧。   2009科学嘉年华如火如荼。这一期的小姬看片会的主题是“爱情和性”,嘉宾里有动物所的科学家,也有老罗这样很好玩的老男人。推荐。科学松鼠会有文字版全文。土豆有视频。   Tinyfool提高BLOG更新的频率了。为了证明真有订阅者“嗷嗷待哺”等着看BLOG,鼓励他坚持下去,不跳出来推荐一下不行呀。当然,他的分享本来就值得推荐。   最近Resys第三次聚会的材料陆续放出来,更后悔没抢上名额了。个人很关注的是MPI和MapReduce的不同应用场合。上次Hadoop大会也听百度的工程师提过类似的话题。好像计算密集型的应用还是更适合MPI。明年我准备pFind实际对比一下。   一年快过去了。私事稍后专门写BLOG。关于公共领域,发生了很多好的和坏的,有些事让人愤怒。不过我自己觉得还好。之所以保持乐观,是因为大家还拥有幽默感。无论网络、报刊、电视、短信,人们仍然在拿自己、拿这个社会开涮。下面这个链接是网易的年终总结。   接下来一周(正确的说,是4天)打算努努力,让工作有些进展。

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 […]

流水帐.2009.11.11

  压力很大,有段时间没有写BLOG的心境。修养不够,乱发火,还需要磨练,还需要反省,还需要成长。   投稿Journal of Proteome Research,被传说中的副主编不经同行评审直接拒稿。yb打电话聊天,安慰:有些人就是怀疑,认为中国大陆做不出那么出色的科研成果。其实还好,还好。宁愿相信是自己做得还不够牛。即使真涉及技术外的因素,是不是歧视,取决于你最终到底做成什么样。姚明得分超过30,巴克利就该kiss驴屁股,否则人家就是有先见之明。短暂抑郁,转投Rapid Communications in Mass Spectrometry。这次遇到的责任编辑还是06年投稿的那位,很快就进入peer review了。fy老大催着赶紧申请专利,否则文章一发表,就来不及了。   瓶子哥在曙光5000A上测试,320核条件下,加速效率达到80%。欣慰。这段时间的交流,意识到随着分布式规模的扩大,pFind集群的特点逐渐向I/O密集型靠拢。也就是说越来越像web搜索引擎。明年要搞点MapReduce的尝试。另外购买4000块的昂贵显卡。一直在关注GPU在科学界的应用。生物制药、物理航天、天气地质、游戏娱乐……短时间出现了爆炸性的增长。计算机行业的一个有趣的特点就是,工业界常常跑在前面,搞出一些破坏性创新,给学术界造成了很大的压力。   雪下得好大,积雪没过了鞋帮,咯吱咯吱的。大家注意身体,别H1N1。今天见到了好久没联系的jw。原来是班车11点还因为大雪堵在路上,他索性下车到我们这里交流。忙过这一阵,要去看看朋友们。当然,还是会逼着大家给pFind引擎提意见。   在各种场合听到关于创业的讨论。创业当然主要跟钱有关,但是必须有一点钱以外的东西。Boss H说得对,一时的热情最容易消散。必须有点功利以外的理由,让自己在最痛苦时平静下来,坚持下去。   douban.com在测试“豆瓣电台”,根据你的历史行为推荐音乐。上来就给我推荐了几首没听过的张震岳、周杰伦和涅磐。查了查,豆瓣在招聘“算法和数据挖掘专家”。应聘要求包括:“热爱探索和钻研,相信算法能够改变人们的生活;极佳的逻辑分析能力和学习能力,善于应对各种智力挑战;熟悉海量数据处理和挖掘的基本算法, 或有高性能科学计算的相关经验”。

Beta技术沙龙:利用SNMP进行服务监控

  昨天参加Beta技术沙龙,霍炬讲银杏搜索利用SNMP作服务监控的系统实现。   架构很简洁清楚,容易理解。上层包装也有不少好玩的,例如直连GTalk,无论管理人员的物理位置在哪里,都能实时监控服务状态,进一步手机短信也不难了。   报告摘要里,对需求的解释很到位:“运营大规模SAAS,对所有服务的状态进行管理和监控是难点之一……”。这正是我感兴趣的原因。日后pFind提供在线云计算服务,必然要考虑这方面的基础设施。其他听众包括,鲜果,有道,还有做安全检测的,看来都是有目的而来。   (顺便提一下,查了查我BLOG的订阅分布:Google Reader、鲜果、抓虾、豆瓣九点……Google Reader还是占压倒性优势)   银杏主要针对十几种服务进行监控。我想,也许还能支持更细粒度的监控。例如在大规模集群环境中,监控每个节点上的计算进程,以保证MapReduce形式的大规模云计算服务的可靠性。会后交流时,我就此问了霍炬的想法,他没有明确的同意或反对。   这是第一次见到霍炬真人版。果然是好工程师。逻辑清晰,思路活跃,解决方案明快有效,没有拖泥带水的废话和掩饰。   会后又和tinyfool、nzinfo聊天(主要是他们说,俺听)。nzinfo第一次见,大侠居然在自己的iPhone上安装gcc和vi,更过分的是还装git版本管理。这么牛,怪不得有资格做tinyfool的竞争对手。nzinfo演示了几种iPhone上最著名的金融终端,包括布隆伯格(Bloomberg)的,各种分析工具还真挺全面。   tinyfool刚发了一篇BLOG,谈谈对双人编程、单元测试、重构的理解,说得很到位,推荐。   奇怪,这帮注重实战的工程师,全都开始踅摸起数学、折腾起matlab。难道是传说中的天下武学殊途同归。

推荐Resys Group

  误打误撞,发现牛人团伙。   原本打算参加这期Beta技术沙龙,听霍炬讲的报告《大规模软件服务的管理和监控》。结果粗心大意,把时间记错了一天,今天下午就闯到奇遇花园咖啡馆去了。   也幸亏记错了,才能遇到Resys的牛人们线下聚会,正在讲数据挖掘和推荐系统的算法(collaborative filtering),于是就买了饮料,蹭听了一场。   讲演者是The Ensemble团队的中国成员,传说中的xlvector大侠。具体内容,当然是他们拿到Netflix Prize比赛leaderboard头名的比赛经验。   下面开始八卦,给没听过Netflix Prize的火星人科普一下:   美国DVD在线租赁商Netflix于2006年发起的竞赛,悬赏100万美元,只要提交比其现有Cinematch效果好10%的新算法,就获得巨款。Netflix公开了四十八万多用户对一万七千多部电影的上亿条评分记录,要求算法推测另外三百万条记录。同时,100万美元存入银行,每年5万利息作为年度进步奖,发给当年取得最好效果的参赛者。   Netflix Prize产生了轰动效应。大概是因为,这让公众亲眼目睹,靠数学和编程是如何挣到真金白银的100万美元的。主流媒体,例如《纽约时报》对此给予了大量报道(2009年7月27日的报道是:Netflix Challenge Ends, but Winner Is in Doubt)。技术领域的超女选秀?你终于明白了。对Netflix来说,得到了性能超群的数据挖掘算法,还做了广告,名利双收。   回来再说xlvector的讲座,八卦内幕相当精彩:一开始你追我赶;接着合纵连横,世界各地的独立的技术和参赛者逐渐融合,成为团队;最后,居然涉及复杂的商业谈判,大鱼吃小鱼,直到非此即彼,参与两个巨型阵营的团战……   伴随比赛过程,发表了大量的高水平论文,也申请了不少的算法专利,还有不少好玩的讨论:   比如有人研究了参加者的性别,发现一开始有很多女性参赛者,而且成绩很不错,但最后两个“超级大国”团队里没女性。研究结论是:女性不会投入两三年时间去做一件根本不可能成功的事;男性相对单细胞一些,杀红眼了就钻进去出不来了。   参赛者Bill Bame在BLOG写到,他发现团队里都是两种人,一种是数学家,一种是工程师,思维方式行事风格截然不同,但两种人都发挥了至关重要的作用。   The Ensemble团队最后30天工作中,租用了EC2云计算平台进行模型的训练与融合,每小时0.2$。MapReduce模式比较适合离线推荐算法。   OK,八卦写完了。很久没遇到这么好玩的东西。推荐Resys Google Group。这篇BLOG中链接和引用,都是我回来刚搜索出来的,未必全面准确,大家继续挖掘吧。另外,明天的Beta技术沙龙,我也很期待,号召大家参加。   最后赞一下奇遇花园咖啡馆。今天交流到最后,xlvector跑到墙边(整堵墙是一块巨大的黑板),用粉笔演算方程。一帮怪人在下面长吁短叹,其他客人头也不抬,继续喝咖啡上网。 照片来自wentrue的flickr   BTW:只是咖啡馆附近的西直门地铁,实在让人恼火。感觉自己是实验小白鼠,在八卦阵里撞来撞去,难道就没有专业人士稍微做些优化吗。

重读Google老三篇

  昨晚会议结束得太晚,没赶上末班地铁,只好打车回家,俺的银子呀wuwu~   最近在读文献。上周过了几篇蛋白基因组学(proteogenomics)的天书,实在抓狂。这周的主题回到软件领域:大规模分布式计算。昨晚是Google老三篇(GFS、MapReduce和BigTable)的文献讲评,瓶子哥顺便讲了讲Google Cluster,我又带了几句Chubby论文。讨论很热烈,结果就说多了。   我负责主讲BigTable,这次细读,发现以前读的时候忽略了很多细节。   比如,BigTable使用bloom filter算法进行元数据cache加速。bloom filter有单边特性(它说不存在的,必然不存在;它说存在的,也许有小概率错误),这的确最适合cache这种场合。   再如,google的分布式锁服务Chubby,在GFS和BigTable中都起到关键作用。在同步控制方面,GFS和BigTable设计思路几乎一致,都是用Chubby对master节点的元数据条目加锁,但具体数据服务节点(GFS叫chunk seriver,而bigtable叫tablet server)的同步正确性,需要客户端自己来保证。这样设计的目的很明确:尽可能保证全局服务的简洁高效,防止master节点成为瓶颈,这对大规模的分布式场景是非常重要的;当然,副作用就是客户端程序的要求更高。   BigTable的一个重要应用是Google Analytics。另外进展很快的个性化搜索也用BT来存储用户历史和参数。之前发布的Google App Engine的python存储API,有很明显的BigTable痕迹。   身边已经开始有人从Amazon和Google租用云计算能力了,新概念被接受的速度超出我的想象。

Google App Engine视频

  Google App Engine不顾俺三番五次申请,就是不给试用帐号。郁闷呀。   这里有一段视频,演示了简单的Google App Engine开发步骤。尤其是用GQL调用传说中的MapReduce海量分布式存储,看得俺直掉口水。趋势不可逆转,很快多数软件都会以ASP(Application Service Provider)方式提供服务。我很想知道微软首席架构师Ray Ozzie看到这东西是什么感觉。   按一般观点,类似俺们pFind这种计算密集型应用,核心模块必须使用C/C++ API,否则慢得难以忍受。然而,一旦基础架构的分布式规模达到Google所谓的“云计算”这种级别,就算有几十万张谱,也可以充分地分而治之,被分解到巨大的PC Farm里,让集群节点一对一PK,甚至进一步按蛋白数据库再细分任务。这种情况下,即使单个节点的线性效率稍差,也可以接受,可能用Python就够了(对比:按我们现在的经验,没经过精心优化的Matlab代码鉴定一张质谱大约5分钟,当然可以进一步采用各种优化加速手段,例如psyco)。到时候,最主要的速度限制也许就来自网络带宽,上传多少即时鉴定多少。   未来某天的软件创业故事:逃课的小孩在大学宿舍里编写了一款网路游戏(比如,也许是跑在iPhone或Android上的多人联机MMORPG),上传到Google App Engine,再到常去的论坛发个帖子,邀请大家来试玩,结果这个游戏一炮而红,Google和中国电信作为基础服务提供商,对利润进行分成。这个故事不会很快变成现实,但是也不会很慢,技术演化总是被低估。

多核时代

  年初Intel发布了试验性的80核CPU。16核龙芯正在计划投入实用。其实尚在开发中的最新一代龙芯(GodsonT)走得更远。春节前,生物信息组的代码在上面试跑过一次,都把我吓傻了,他们居然还觉得“达不到期望”,还在大改。IBM的千核CPU(Kilocore)也披露了。   自从C++委员会主席Herb Sutter发表The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software,JAVA神童Rickard Oberg表示赞同后,软件业似乎一瞬间就进入了多核并发时代。从纯技术角度看,近五年最激动人心的创新是什么?不,不是.net或AJAX,而是GFS和MapReduce。

Bigtable论文

  Google labs里刚贴出了Bigtable的论文:Bigtable: A Distributed Storage System for Structured Data。立刻引起很多讨论。很关注这个话题。在Blog发表了不少与此有关的讨论,搜索了一下,感觉这些观察和思考是有连续性的。把它们都列出来: 2005/11/9:推荐书籍资料 2005/11/23:技术和应用 2005/12/11:Google你的基因 2006/2/15:BigTable和生物信息 2006/4/10:Google的算法 2006/6/11:几篇关于MapReduce的中文资料   最近会看看Google Map卫星地图上的中关村,所有标志性建筑都清晰可见,也能找到我住的小区单元楼和工作的大厦。原来每天就活在这么一个格子里。