Tag Archives: MapReduce

怎么看待互联网公司进入医疗健康业?

  先看个好玩的。下面播放的这个名为Big genomic data on Google Cloud Platform的视频(在youtube上,得翻墙)简单介绍了如何通过Google的基础设施,例如Genomics API、BigQuery和 GAE Mapreduce ,在云端处理基因大数据。那个分析基因的BigQuery SQL代码例子你看懂了吗?

  知因上有个问题:昨日爆出腾讯7000万美元投资中国最大的医疗健康互联网公司丁香园;雅虎将于今年10月正式启动个体基因数据库“HealthData Lab”项目;不久前,Google X部门启动 “基线”研究项目绘制健康人体图谱。你怎么看待互联网公司进入医疗健康业?他们在未来的医疗健康行业会起到怎样的作用?随着互联网公司的涉足,未来医疗健康行业又将如何发展呢?(原文链接)我做了如下回答:

  算是和这个问题有点的关系的人。此前有好多年在科研机构里搞生物信息学。然后跳到互联网公司里做云计算。现在正准备跳出来创业,搞健康大数据和云计算。

  感觉最大的区别是人的思维方式。互联网是竞争和变化非常激烈的行业,追求高效、专注、开放,有很多应对资本和人才流动的游戏规则。而生物制药这边,套路还有点传统。

  举个例子,互联网出来的人创业,首先考虑的是怎么把自己做薄,把能放弃的都外包出去,专注于自己的最大优势。而传统健康领域出身的创业团队搞某件事,例如基因测序,思考方式似乎仍然比较宏大,停留在再造另外1个或者0.5个华大基因:测序仪,服务器,算法研发,数据分析,网络营销,地面推广,健康诊断,个性化医疗……

  再举个例子,我没看到基因测序行业特别担心一线技术人员流失和跳槽,至少他们没有采取很明显的激励措施:提高工资、赠送期权、鼓励和参与员工进行内外部再次创业等等。相关专业的毕业生,例如生物信息,平均士气并不高,找工作的时候对未来普遍很迷茫。

  未来会怎样?我不知道,至少目前阶段,互联网出身的人还处于劣势,他们不了解医药健康行业的特点和细节,缺少体系内的人脉和资源。但这些鲶鱼至少激发了整个行业的思考。让我们一起加油,看看两三年以后会变成什么样?

  顺便发点小广告,我们在招人:http://knowgene.com/article/136

KDD 2012第一天

  我现在在KDD 2012大会现场。由于今年的主题是Mining the Big Data,有趣的报告太多了。我主要在穿插着听以下三个Track:

  1.关于海量数据处理,基于MapReduce、Stream的数据挖掘算法实现的BigMine

  2.关于生物信息数据挖掘的BIOKDD,以及与健康信息有关的HI-KDD

  3.Yahoo专家的特邀报告Data mining in streams

  见到很多朋友,如果你也在现场请联系我或者微博上@我,大家多交流。

流水帐

  前天晚上紧急飞到杭州来,参加昨天早上的项目会议。此前邮件里,各方面虽然都推荐我是这项目最合适的pd,但又都认为工作将会很困难。会上,我把技术和业务瓶颈都说清楚了,等老大们斟酌。很多技术困难说到底还是商务问题。3个公司5个团队,需要大量协调。

  好一阵没写代码。这两天为给ODPS写用户文档,用MapReduce写个Join的例子。也算活动活动生锈的大脑部件。

  编程这手艺放下就会生疏。周围好多人都说要一直写代码到退休。而离开编程的人,受到各种鄙视,尤其是他自己的鄙视。

  昨晚11点下班的时候,跑到三层去看nh老大。他忙得都顾不上理我了。公司里一大坨人都在电脑上看欧洲杯(CNTV网站的底层租用阿里云的各项云服务,例如CDN,欧洲杯期间视频流量爆发性增长),nh这几天需要连续通宵值守。

  今天中午偏头痛又犯了,回宾馆睡了会儿,下午支撑着过来,终于调通了程序。还挺有成就感的,头居然也不疼了。刚订了飞机票,明天可以飞回北京了。

哪吒和太空镜子

  上月底哪吒第一次对合作伙伴提供在线服务。开始和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模式。所以,生物领域的挑战也许可以反过来给计算领域一个发展的机会。

流水帐.2010.10.4

  还没有确定是不是WordPress.com。办妥了会通告。先补前一段时间落下的内容。好久没写BLOG,不好意思。

  9月份工作很紧张,终于把软件著作权、专利和商标的申请都搞定了。pFind并行版内容最终拆分为三个互相掩护的子专利,因为涉及到MapReduce技术,还特意和专利代理律师一起研究了有关资料,除了论文,还包括今年1月份刚刚公开的7650331号专利。这期间还注意到一条新闻:Google最新版引擎Caffeine已经放弃MapReduce架构。接下来补更多实验,要啃一个超过五百万张谱图的庞大数据集。偏偏碰到深腾7000停机修整,踅摸中……

  最近不仅没精力写BLOG,也没空买书。前两天才抽出空来去了一趟中关村图书大厦,买到了爱德华·吉本的《罗马帝国衰亡史》、沈群的《美国也荒唐》、W.Bruce等的《搜索引擎》(也就是Search Engines: Information Retrieval in Practice的中文版)、周汝昌的《红楼小讲》、林语堂的《平心论高鹗》

重读Google老三篇

  昨晚会议结束得太晚,没赶上末班地铁,只好打车回家,俺的银子呀wuwu~

  最近在读文献。上周过了几篇蛋白基因组学(proteogenomics)的天书,实在抓狂。这周的主题回到软件领域:大规模分布式计算。昨晚是Google老三篇(GFSMapReduceBigTable)的文献讲评,瓶子哥顺便讲了讲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租用云计算能力了,新概念被接受的速度超出我的想象。

几篇关于MapReduce的中文资料

  收集到几篇关于Google MapReduce的技术资料,供参考。

  Tinyfool:什么是MapReduce? Google的分布运算开发工具!

  梦想风暴:MapReduce

  SQLiu:从Map和Reduce说起

  is03kyh:My Map Reduce

  田春峰:MapReduce:Google的人间大炮

  Xerdoc:Map Reduce – the Free Lunch is not over?

  IcyRiver:MapReduce与Database之争

Google的算法

  开始设计pFind系统的集群版本。今天在读Google的论文:MapReduce: Simplified Data Processing on Large Clusters。之前推荐过The Google File SystemWeb Search for a Planet: The Google Cluster Architecture两篇论文。

  Google的强大不只源于PageRank算法,用普通PC组成的高效集群也是一个杀手锏。李开复就提到过,MapReduce算法和GFS架构才是Google真正的核心竞争力。

  digg上热炒Google购买Orion算法的的事。引出一大堆各式各样的八卦议论,比如有关这个博士生的国籍。有个小伙这么写“After all Israel is just America III. Canada is America II.”,哈哈。

  有趣的是,现在,北京时间2006年4月10日22:30分,用Google Web Search搜索这个新闻,可看的内容很少,但用Google Blog Search搜索,就能找到世界各地用各种语言写的评论,很多都是20分钟前刚写的。