Tag Archives: Hadoop

easyHadoop、Resys以及追女生的行动次序问题

  最近不断参加各种非正式的技术沙龙,接触网站和创业者的运营团队和数据分析团队,也就是ODPS的潜在用户,了解需求和业务。工作比较累,BLOG更新拖延了,抱歉。这次先写点零零碎碎的东西,接下来会尽快补上此前没写完的东西,例如《伯罗奔尼撒战争史》读后感系列的收尾部分。

  4月中旬,参加了easyHadoop的第二次开发者聚会。后来还和暴风的童小军向磊做了进一步交流。easyHadoop是致力于普及Hadoop、HIVE等开源Big Data数据分析解决方案的志愿者组织,开源了phpHiveAdmin、HappyETL等一系列实用工具。如果你跃跃欲试想找实践机会,参加easyHadoop社团的活动是个好选择。

  5月份还打算去上海参加第二届中国推荐系统大会。推荐系统现在很受关注,Resys在北京的每次活动都爆满抢不到座位。我最早关注,还是因为那次记错时间到贝塔咖啡,误打误撞闯入了这帮极客的线下聚会。当时是xVector分享他参加Netflix数据挖掘大赛的经历。(什么,你没听说过Netflix百万美元的推荐算法大赛,欢迎来地球。那次比赛里,在截至时间只有20分钟的时候,xVector的算法痛失领先地位,没拿到100万美元的奖金)。xVector进入工业界以后,42qu请他又讲了一次。这次上海的会,他将做一次很有干货的会前培训。

  值得一提的是,当年Netflix大赛,各参赛队都是租用亚马逊的EC2弹性计算,部署Hadoop跑统计和拟合算法的。纽约时报对这此的连续报道,也给亚马逊的AWS做了免费的广告。希望未来ODPS能在纽约时报上获得同样的露面机会。

  最后写点非技术八卦。42qu上有个小伙儿怯生生问大家,他喜欢身边的一个女孩,怎么办。一帮技术宅男七嘴八舌给他出馊主意,例如给女孩子做个网站,或者上天涯发动网络舆论帮忙。我是这么回的:

     常规流程是:闲聊、邀请、吃饭、逛商场、看电影、逛公园、送礼物、表白、小亲密、推倒……你也可尝试倒序执行。

     别相信前面那些码农的雷人YY。以上任何阶段插入“网上舆论造势”和“编写网站”啥的,均会引发“女生不兼容”异常,进程将报错退出。

Do it yourself

  正在指导zk和wl在超龙一号超级计算机上安装配置pFind集群版。打算在960核情况下做一些加速比试验。和上次1024核试验很类似。很遗憾不能在龙芯CPU的节点上玩玩。

  哪吒系统在集群上全流程各环节并行。我一开始指望用点python有关的分布式并行框架,最后还是DIY。小马过河,有些地方挺困难(例如对虚拟机的管理和通讯),但总体来看,其实比想象简单。

  前几天提到,新版pFind核心使用了二级离子索引,但引入HBase不顺利。又发了些邮件开了些会,终于下定决心对查询部分推倒重来,抛开Hadoop等现有框架从头实现。方案确定,大家恍然大悟:原本就该这样做,花了半年证明HBase不行啊。

  上次BLOG最后写:“Java和C#逐渐不那么招人喜欢”,还链接了“Why do some people hate Java?"“Why we don’t hire .NET programmers”两篇文字,引来不少邮件和评论。俺的不少好友是Java和C#高手,并不想挑起语言口水战。那段文字也只是描述现象。具体从风格而言,这两种语言都是以“减少新手犯愚蠢错误”作为第一原则的,对初学者相当友好。不过也有点像乐高玩具,常规情况下简单易用,但面对更高的要求时(运行效率、开发效率等等方面),就不得不去了解大量水面以下的细节。相比起来,开源界的技术栈常常是哭着进去笑着出来。

从卫生巾说到生物云计算

  写一些技术感想,意识流,没中心,想到哪里写到哪里。

  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模式。所以,生物领域的挑战也许可以反过来给计算领域一个发展的机会。

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。

里程碑收尾,论文,雪季开始,理想主义和Hadoop的调度算法

  里程碑接近完成。这一版pFind Studio除了增强搜索引擎内核,也针对用户易用性进行了改进。需求列表很长,但很多问题需要微妙的权衡取舍,没想清楚之前不宜动手。因此在有限时间内,主要是集中解决几个重点问题,减小智力负担,提高用户体验。好几个月没上一线写代码了,都有点生锈。

  leo和hchi的论文一年内被拒两次,终于有希望了。加油!工业级软件、发明专利、国际期刊……一个都不少,科研创新的过程很完整,赞。然而,zhch牛人的新一代后缀树组索引算法,又将取代pFind内核里现有的倒排索引。把前浪拍死在沙滩上。我的论文还在under review。

  最近心情略好,给自己买了条新的单板滑雪裤,去乔波玩了两次。今天听说出事故了,中级道关闭,警察来来回回勘察。阿弥陀佛,大家还是要注意安全,科学练习,初学者最好请教练,不要傻大胆强行冲坡,练单板的人要戴好头盔和护具。自从08年初受伤以后,滑单板变得很谨慎。今年春季dmq老板委婉地说:“忒平稳了”;雪场教练的评价就直接多了:“专拣最没激情的那种动作”;现在,又被总雪龄少于10小时的小朋友在初级道上鄙视了。没办法,十年怕井绳,三十岁的老胳膊老腿了,安全第一安全第一。

  不过,静下心来,就把左右脚的落叶飘和换刃都练熟了。认识了一位不错的专业教练。原来八一队练冬季两项的。年纪很轻、人很帅、脾气不错、技术当然很牛。只可惜受伤提前退役了。我打算上难度的时候,就雇他教一天。

  最新《程序员》里有一篇张岩的自述。讲到考研和求职,讲到亲人突然去世,讲到公司重组,讲到challenge和沟通。文字很朴实。有些话值得年轻人体会,例如“做工程师永远要记住细节是魔鬼,只有在细节上充分积累,技术上才有成长的空间”;又如“请保持理想主义,相信我们做的事能改变生活。我们每天起床和上班,不是为了赚钱糊口,而是因为兴趣和使命感。”

  技术上最引起我注意的是《Hadoop集群作业的调度算法》,正好是下一步工作的重点。豆瓣王守崑的《走进个性化推荐系统》讲的是近期热点,也很有意思。(Resys召集聚会,就在豆瓣公司举办,可惜报名晚了没抢上名额,哇哇哭)

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对应产品。我倒觉得,现在才动手的话,不如选择成熟的开源方案,这样招聘、培训和合作的成本较低。