Tag Archives: 云计算

思考:如何开发应用平台

一、开发难度

  和创造单个应用相比,创造应用平台的难度要高一个数量级:

  1. 架构难度:和特定应用不同,应用平台是开放性的,允许别人到系统肚子里自主编程,因此应用平台的用户边界本质上是API。设计一套干净强大、可拓展、安全、完整自洽的API,并在此基础上构建SDK、Console、GUI……是很难的。进一步,为了支撑第三方开发,需要有编程工具链。尽管程序员们都会用编程工具,但即使是计算机系科班出身的程序员,90%也不清楚DSL编译器和IDE的实现原理。

  2. 产品难度:应用平台的产品设计,需要抽象和分解能力。不仅仅满足某个具体用户场景,而是必须把握各种应用开发者在各阶段遇到的各种问题。这里面除了用户体验、E2E场景、还得注意统一的设计哲学和必要的分寸感。没经验的PD往往忽视谨慎思考和设计,强调快速迭代和重构。对应用平台而言,指望靠蛮力代替深思熟虑,行不通。

二、成长周期

  关于平台何时成熟,存在一些客观规律:

  1. 平台真正“立”起来至少需要4年时间。看那几本回忆Unix、Windows NT、NeXT、AWS初创的书,例如G.Pascal Zachary写的《观止:微软创建NT和未来的夺命狂奔》,这些系统前4年都跌跌撞撞甚至反复重构。

  2. 第2年最容易死。BAT三巨头几乎同时启动自主云平台:阿里的飞天系统、腾讯的台风系统、百度的C++重写Hadoop计划。但腾讯和百度的团队在第2年的时候都挂掉了。事实上,阿里云差不多也在那个阶段经历了惊涛骇浪,只不过运气好,马云这个老板异于常人。

  3. 关键是团队的成熟。阿里云最重要的行业贡献不在于其本身的IaaS业务,而在于那支从零开始把操作系统做出来的技术团队。现在飞天团队很多牛人跳出来创业,如果还是做平台的话,就会知道哪里有坑。

三、方法论

  1. 发布的节奏感非常重要。从阿里云辞职,老上级点拨我:如果只做一件事,就是保持发布节奏。一个里程碑一个里程碑下来,现在是Sprint 18。真是做对了。虽然前面说4年才能成熟,但是不可能有老板真能容忍你4年啥业务也不扛。这就意味着,得向客户和业务团队承诺产出,一旦承诺了就必须说到做到。这还意味着,必须现实主义,收敛战线,降低阶段性期望,为支持业务做些妥协。衡量一个技术团队的基本标准,就是持续交付能力。

(Intel曾经遇到过困境,CPU浮点运算部件有错误,不得不召回,AMD弯道超车抢先推出多核CPU。可惜AMD无法保证稳定交付,结果又坐失良机。再往前,摩尔定律其实不是客观存在的自然规律,而是Intel的明确战略,给客户承诺的交付节奏,给自己团队戴的紧箍咒。在撞到纳米墙之前几十年,Intel一直说到做到)

  2. 时刻关注平台架构。保持低耦合高内聚,保持模块之间的正交。否则越往后越痛苦。尤其是客户业务接进来之后,如果边界不清晰,到处插管子,就死定了。要理解著名的Conway’s Law: A design reflects the structure of the organization that produced it。这条定律的意思是:什么样的团队组织结构,最终就会开发出一模一样的软件架构。如果有四个小组合作开发编译器,系统最终一定会长成一个四阶段编译器。所以大型软件组织内,在重构系统之前往往先reorg团队。

  3. 好的软件工程实践,决定了技术团队的层次。Github用的怎么样、Bug管理怎么样、代码审核是否严格、发布升级是否自动化、有没有单元和集成测试……到一个技术团队里呆几个小时,鼻子闻一闻,就知道几斤几两。技术团队如果这些基本功不好,摩擦力会越来越大。

  4. 问题是什么,永远比解决方案更重要。最常见的错误就是:拿着个锤头,眼里看来满世界的问题都是钉子。必须花很多时间深入思考:客户有什么问题?我们能带来什么改变?逐渐建立对这个领域的独特洞见。

(仔细读了读巴菲特创业最初10年的信。他先建立了自己的独特benchmark,然后把投资对象分为4类,每类有不同的触发条件和行动。)

  5. 找到issue优先级明确roadmap才能减少焦虑。能砍事儿的才是合格的产品经理。做了太多客户不需要的事,团队总是加班,这是管理债,是耻辱,不是骄傲。

(讲到这里,顺便贴一篇两年前给pFind组的回信,最近Boss H又翻出来抄送给pFind团队)

  我已经离开pFind很长时间了,不了解细节。说错了大家拍砖。憋了好久,没憋住,因为pFind始终是我的产品。

  所谓战略,是明确不做那些“比较对的事”,只做一两件“非常对”的事情,壮士断腕才能做好产品,好产品才有资格进一步谈平台化和生态系统。

  客户需要精确的结果,客户需要飞快的速度,客户需要傻瓜式的安装和参数配置,客户需要全流程解决方案,客户需要在平台第三方开发的API和SDK,客户需要易用的界面、配图和表格……不从前面这些需求里砍掉90%,集中精力把剩下的一两项做到全世界第一,就没意义。

  不如每个人列两个单子:你认为pFind最该做的事,最该放弃的事。别写很多所有人都同意的真理,信息熵为0。如果为了防止互相影响,就单独发给BOSS H汇总。

  恕我直言,所有界面类的开发工作,pFind组都很不擅长,做得很苦、做得很烂。我们这些人离顶级UED差得太远,也未必有热情追求用户体验的卓越。也许更应该集中做算法、做流程框架、设计数据接口和API、向外界开发者提供API和SDK(这里的API也许是本地的,也许是Web Service)。至于界面也不是彻底不做,现有界面可以重构到前面说的API和SDK上去(以便吃自己的狗食,验证API、SDK的设计合理性)然后再开源出去。

四、BD和运营团队

  传统背景的业务人员面临挑战。因为他们要花一些时间才能意识到:推销的是通用平台,而不再是某种具体应用。

  1. toB销售,又面对专业技术话题,业务团队需要配备得力的业务架构师(BA)帮助技术交流,给解决方案。

  2. 找来了很多客户,仔细聊下来,有一半其实是需要Word(应用),而不是Windows和VC++(平台)。早期应该组建专门的技术小组,自己扑上去帮客户开发应用,也算吃自己的狗粮。后期再逐渐找外包商和集成商。CEO说,友盟的前70个客户,都是友盟自己的程序员扑上去帮他们写APP。

  3. 平台是前所未有的东西,是改变现状的创新。所以业务团队的目标不是销售数字,而是尽快立起标杆客户。

  4. 业务团队需要了解技术团队的发布节奏。知道有“水面以下”工作量存在,例如产品架构设计,例如重构偿还技术债。这些最终会影响到技术团队的持续交付能力。

  5. 业务团队有权要求更多后方的火力支援,理直气壮扯着产品经理的耳朵大喊客户需求,明确业务优先级,并监督技术团队的产出。

  6. 最终,其实和技术团队一样,业务团队最大的挑战还是学习能力,建立独特的思考模型。

健康大数据创业团队诚邀您的加入

  我们是一个健康大数据创业团队,已经拿到百万美元天使投资。创始成员包括前阿里巴巴数据科学家、前阿里云数据产品经理,核心团队长期工作于阿里、百度等业界知名公司。我们怀揣用数据技术推动健康领域革新进步的梦想,期待您与我们结伴前行。
  我们在北京。
  如果你是一个Geek,和我们一样渴望用互联网和数据技术改善自己和他人的生活质量,请无视下面的职位描述,直接把简历砸向 igenedock@gmail.com ,我们会在第一时间跟你联系。

系统架构师
我们希望您擅长根据业务需求构建和优化可扩展的计算系统,对分布式存储/分布式计算/并行计算系统架构如数家珍,并热衷跟进前沿计算技术发展。
工作职责:设计系统架构,带领团队实现面向海量数据的可扩展计算系统。
要求:
  1. 深入了解Mesos/Yarn或其他分布式资源管理系统
  2. 熟悉分布式计算领域作业调度、元数据管理、数据质量监控等方面
  3. 熟悉Hadoop生态环境,有系统级开发经验
  4. 优秀的沟通能力和团队协调能力
其他
  1. 熟悉亚马逊AWS或阿里云等公有云服务优先
  2. 熟悉Docker或其他虚拟化容器技术优先
  3. 熟悉Spark/MPI等计算系统优先
  4. 参与过开源项目优先
  5. 有github和技术博客展示自己以往技术沉淀者优先

前端工程师
我们希望你热衷于前端技术,对浏览器加载方式理解深刻,渴望实现多样流畅的用户体验,
工作职责:设计并开发web前端页面,完善报表展现、数据操作等功能,并能使用缓存和按需加载方式优化页面性能。
任职要求:
  1. 熟悉W3C标准,熟悉MVC模式
  2. 熟练掌握HTML/JavaScripts/CSS/jQuery等前端技术
  3. 对用户交互设计有自己的理解
  4. 良好的沟通能力和合作精神
  5. 熟练使用git工具进行代码管理,熟悉基本的软件工程方法论和工具,例如单元测试、版本管理、Bug管理等
其他:
  1. 熟悉主流Web框架优先
  2. 有数据可视化经验优先
  3. 参与过开源项目优先
  4. 有github和技术博客展示自己以往技术沉淀者优先

后端系统工程师
我们希望你对业务系统开发有丰富经验,擅长设计简洁易用的RESTful API,热衷于提高系统性能和可扩展性。
工作职责:开发后端服务,包括权限控制、元数据管理、任务调度等功能
任职要求:
  1. 熟悉Python/Java编程
  2. 熟悉MongoDB,Redis,memcached等存储技术
  3. 对后端业务流程搭建有丰富经验
  4. 了解Nginx配置,使用过主流Web开发框架
  5. 熟练使用git工具进行代码管理,熟悉基本软件工程方法论和工具,例如单元测试、版本管理、Bug管理等
  6. 良好的沟通能力和团队合作精神
  其他:
  1. 了解亚马逊AWS或阿里云等公有云服务者优先
  2. 有Hadoop开发经验者优先
  3. 参与过开源项目优先
  4. 有github和技术博客展示自己以往技术沉淀者优先

数据工程师
我们希望你热爱数据和算法,熟悉计算任务的开发和调度过程,对分布式数据存储和计算流程的优化实现有自己的心得。
工作职责:开发ETL过程,优化存储方案,设计并实现分布式计算任务,搭建数据处理流程。
要求:
  1. 熟练掌握Java/Python/C++至少一门编程语言
  2. 熟悉Shell Script和Linux操作
  3. 熟悉常用数据结构和算法实现
  4. 了解分布式系统构成,有Hadoop开发经验
  5. 优秀的沟通能力和合作精神
其他
  1. 有生物信息学/机器学习背景优先
  2. 有Spark/MPI等计算系统开发经验优先
  3. 参与过开源项目优先
  4. 有github和技术博客展示自己以往技术沉淀者优先

我们提供:
  1. 有竞争力的薪资和员工福利
  2. 员工期权激励
  3. 宽松自由的工作环境、工作午餐和无限零食

感兴趣请尽快发简历到 igenedock@gmail.com ,如果有个人作品和项目,也可以一并附上。

华大基因收购Complete Genomics

  美国基因测序公司Complete Genomics周一宣布,已同意接受世界最大的基因测序公司深圳华大基因价值1.18亿美元的收购要约。

  华大基因威武呀!这么坏的外部环境下,上市的脚步依然没有停。这次收购的财务顾问是花旗,应该是打算海外上市。

  搜索到了Complete Genomics上个季度的财报,销售八百七十万美金,亏损一千八百万。果然是撑不下去了。

  另外华大基因宣称明年花6000元人民币就可做全基因组检测。这个价格已经降到可以进入医院了。想当年人类基因组计划,多个国家科学家联合工作,耗资几十亿,才测出了一个人的基因组。这十年间基因组技术的进展,可比摩尔定律快多了。

  替各路“云”着急,只顾着价格战口水战,一点都不懂抬头看路。华大基因一家租用计算和存储的胃口,就能把国内云计算市场的座次完全颠覆。

近几年内,国内公有云会怎么发展?

  我在知乎上回答了一个问题:近几年内,云计算会有怎么的发展?

     只说说公有云。对私有云不了解。

     1.最近云计算领域的关键词是“落地”。国内共有云基础设施将逐步成熟,领先的公司有望收支平衡。随着价格战的展开,泡沫落潮,没穿内裤的游泳者会逐步出局。

     2.地方政府推动的所谓云计算项目,会找公有云商业公司合作。前者擅长出钱、征地、修机房、买机器,并拉上来一些当地客户。而拥有技术和运营能力的商业公司,负责提供品牌、开发软件、部署系统、运维。

     3.越来越多的天使投资人和风险投资人会要求互联网创业团队在创业初期租用公有云。这比一开始就买很多硬件和带宽放在那里日日夜夜产生折旧成本,风险更小。支出成本与业务量之间线性相关,一旦业务转型包袱比较轻,这更符合财务投资的原则。

     4.Saas类的产品会再次迎来机会。此前的一些RCM、ERP、SCM软件的Saas化尝试不算特别成功,原因是业务模式只改了一半:客户这边变成了按需租用,但支出成本这边却仍然不变, 需要自己建机房买机器,这导致现金流循环的周期太长。有了底层Iaas和Paas供应商,Saas从业者可以按需租用,节省运维费用,成本就降下来了。

     5.移动智能手机的进展会促进云计算的发展。

     6.电子商务从业者方面,用数据仓库、数据挖掘技术支撑运营,会逐渐变成默认标配。中小电商不会投资独立设施,会租用云计算。

     7.弹性计算、云存储、大数据处理,这三大主题陆续都会变成红海。业者需要寻找新的技术和业务模式的创新。

     8 传统意义上的高性能计算的非互联网客户,例如物理、天文、地质、材料,生化等计算的市场,会逐渐往云计算平台上转,但这是一个漫长的过程。曙光6000和天河1号这样的超算中心将来还是会活的很滋润。两边各自擅长于不同的市场(IO密集型和计算密集型)。

阿里云平台的介绍

  刚回到北京,下周一还要飞。最近要应付的事多,接下来我一定会保证博客的更新频率和质量。现在先随便敲两句。

  这一期《程序员》杂志的副刊发表了一系列文章,全面介绍了阿里云平台,包括弹性计算、云存储和CDN、应用托管、结构化存储和大规模离线数据分析等等一整套服务。感兴趣的同学们可以看一看。想更深入了解甚至试用,直接去www.aliyun.com吧。

从卫生巾说到生物云计算

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

  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领域的大词,总会很快过时。

LINPACK和WINE

  最近在忙哪吒提供在线服务的事。全都是配置集群节点SSH、NFS、MPI和编译安装各种库这种杂事。

  今天刚刚在集群上编译通了LINPACKATLAS两个数值计算的库。以前总在超级计算机排行榜的新闻里听到LINPACK的大名,这下有机会见识了。ATLAS编译时间好久,针对硬件做很多优化设置(Automatically Tuned)。本科学线性代数的时候总逃课去上网和编程,没学扎实。工作以后才发现,只要稍微涉及一点科研的事情,数值计算就缺不了。不懂这个的程序员,感觉工资都会少一截。连有关黑客电影都叫The Matrix。关于这个问题,参考孟岩2006年的经典BLOG《理解矩阵》

  移植工作的拦路虎之一是COM控件的问题。某质谱仪器公司的数据格式是私有的,必须用他们提供的控件去读。悲剧的是,他们只提供WIN32下的COM控件。上个月他们公司的软件部门负责人来中国访问,问他,答曰Win64很快会提供支持,但是Linux近期内不打算支持。悲剧呀。

  所以就在考虑如何在云平台里解决这个问题。一种方案是在用户的桌面导成公开的文本格式再上传,但是这样影响用户体验,尤其是对那些数据量很大的用户,数据导出(和校准过滤)本来就是他们使用云计算的可能原因之一;另外一种方案是在服务端放一台Windows,专门转换数据,或者更玄一点,用虚拟机伺候,以便维护和并行;最后一个方案是用WINE,这个能搞通,当然是最好的。

  还有若干软件的BUG等着解决。组里又都在忙着分析数据,四脚朝天,抓不到人手来帮我。哇哇哭。

  像上次说的,一旦干起来,就有大量实际问题要解决。奋力开路中。

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

  写一点我对生物信息云计算的粗浅认识。首先,所谓云计算是一个商业模式的概念,其内涵里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等等主力软件串联起来,无人值守的对海量数据进行尽可能全面的挖掘,我们希望听取各位的意见。

创业者加油!

  经济危机前有朋友创业,写过BLOG祝好运。这两年身边不断有人下海

  刚刚听说本科同班同学zp和xjm两人正准备创业。虽然表面上毕业后的发展路径有所不同(一个出国留学,一个进入大国企),但最终殊途同归。说到底,都是坚持做技术,同时又有自己想法的人。

  他们公司名叫引众科技,主要提供企业虚拟化产品。例如Instant Cloud 2.0可以用于搭建类似EC2的虚拟主机。

  个人关心的是针对软件研发测试的解决方案。从pFind Studio产品开发现状来看,最头痛的是测试不同平台环境,例如不同版本操作系统:Windows和Linux的各种版本,32位/64位,中英文等 等。反复把各种OS版本在物理电脑上安装或恢复,这个测试成本是不可接受的。结合虚拟化和集成测试(CI),用无人值守的方式依次调出各种操作系统的虚拟 机副本,安装软件测试最终生成报告,这是大势所趋。

  进一步,对许多小团队来说采购软硬件还是经费不足。如果能解决安全信任问题,就可以采用资源租用的方式在互联网上提供云服务。我和zp聊天时,他们已有这个想法,但必须先看市场需求。

  听到老朋友创业很欣喜,又是有技术含量支撑的,就更值得顶一下。加油!