Tag Archives: pFind

思考:如何开发应用平台

一、开发难度

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

  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. 最终,其实和技术团队一样,业务团队最大的挑战还是学习能力,建立独特的思考模型。

产品经理应该怎么起步

  在知乎上回答了一个问题“想成为产品经理,应该怎么起步?”

  1.找到一个有意义的项目,跳进去;

  2.把开发和测试同学不想做的活儿都做了。比如写文档、出席无聊会议、收集客户意见、写部署和测试用的一次性python小脚本、团队熬夜加班的时候给大家买夜宵……;

  3.花大量的时间,系统深入地思考你们正在做的产品(警告你,大多数人在这一步会卡壳,停留在协调人和团队秘书的角色上),整理成文字;

  4.向团队展示自己的思考逻辑和结果,说服他们做某事,给项目和产品的未来带来好处。

  我进入现在在做的ODPS组的方法是,在他们都在客户现场加班的时候,参加进去每天一起加班到半夜。要来上百页的用户手册,把里面几百条指令一条一条动手试用了一遍。然后花两天时间写了一个教新用户上手的《入门手册》,并且提交了若干个测试中发现的bug。

  再早,还在pFind蛋白搜索引擎的时候,去生物学家的实验室收集软件需求。就陪着他们杀老鼠,熬夜做实验,每2小时闹钟叫醒添加试剂并记录数据,在高辐射或剧毒环境下处理试验样品。最重要的,和他们一起体会,因为生物信息数据软件设计考虑不周导致前面的一切都必须再做一遍时,那种巨大的愤怒和无奈。

  别以为自己是当诸葛亮,掐指一算,羽扇一指,千军万马就冲杀上去了。产品经理,是一线领头冲锋的工兵,要给身后的兄弟们搭桥、排雷、探路。

  最近算法平台产品推进好纠结,我得拜一拜乔帮主。

jobs

准备休假

  这周在北京呆着,准备休几天假。像上次说的,春节之后这段时间太忙,需要充充电。

  刚收到邮件,我在pFind组时申请的商标刚获批准。组里还给我一笔奖金。知识产权的积累是对5~10年以后的长远投资。希望pFind越来越好。

  在工业界一段时间了,回过头看,学术界最大的问题是,常常感受不到哪些点是真实问题。这是过多知识和信息依赖文献阅读造成的。按照张五常的说法:某作者凭空想象给出一个案例,另一位引用,写下注脚,如是者转了三几次注脚,大家就把想象当作事实了!

  结婚纪念日。以往都是在百度上搜索“鲜花”,然后点进去购买。这一次跑到淘宝搜索,按信用排序,最终在一家天猫旗舰店订的。价格便宜了很多,服务体验也好得多。据说这99朵白玫瑰一送去,老婆的同事们就要求她必须请吃饭。一淘刚刚超过百度,成为国内最大的搜索广告商。这次亲身体验,不由冒出好多关于生态环境的感慨。

  上周“标签衍生”验收通过了,这是算法平台第一个大的关键业务系统落地。可是为什么没啥感觉呢?算法平台是个金子塔顶端的项目。无论是业务还是技术,如果没有周边诸多铺垫,肯定搞不成。我和sw说过,处在风口上猪也能飞起来,我特别害怕自己就真是那头猪,仅仅是在恰当的时机坐在了恰当的位置上而已,没有为这件事留下独特的贡献。产品落地了,恐惧却增大了。

  所谓战略,就是想清楚不做什么。真正动脑子思考好难,发现大多数情况下,自己仅仅在转述别人的思想而已。

  这两天和老大们交流。dh点拨我说,顺风顺水却开始焦虑,是因为又碰上台阶了,迈上去人就又成长一些。zn催促我实现说了好久的承诺,动手建个模。所以,休假回来啥事也不理了,就动手做这件事,给zn的承诺是六月底之前出结果。

Boss H这么说emily的工作

  上次提到yb和emily的论文发表了,那时候网上还搜索不到文章。现在已经正式出版,可以从pFind组的官方网站处下载

  周五的时候,我受邀去参加论文合作者的庆祝宴会。尽管已经从pFind离职了,还是很高兴能和大家再次分享和回忆这中间的故事。其实上次去上海的时候,我已经和emily吃饭庆祝了一次

  这次宴会里没有emily是大家的一个遗憾。Boss H在今天特别发了邮件:

     我想特别祝贺emily,无论从算法的创新还是软件上的工作量,都值得敬佩,毕业答辩的PPT也很认真、很精彩。pLink这篇文章是大陆科学家独立完成的第三篇Nature Methods文章,是蛋白质组学的第一篇。希望这个成绩鼓舞emily在未来的工作和生活中再放异彩。路很长,慢慢走。

  袖子曾经在一篇BLOG里提到过,他在离开后才意识到,自己已被打上了pFinder的烙印。这也是Boss H一向引以为傲的(你可以看看他的《致同学们》)。从这个组里出去的人能在新的岗位上承担大任,归功于在组里经受过高水平的训练,体验过什么叫做追求完美,什么叫世界前沿。当然,坦率地说,每人情况不同,有留下了终生痕迹念念不忘的,也有毕业第二天就不再是pFinder的。

  yb要出国了,zf要出国了(关于他,看这一篇这一篇),chf要出国了,某种意义上大家会渐行渐远。不过有些朋友,即使十年不联系,再打电话过来,也会马上去和他通宵喝酒。

  关于yb和emily这篇论文,以后就尽量不在BLOG上提了,我离开学术界了,一切从头开始。不过我会一辈子为自己是这篇论文的第13作者而感到骄傲,这是一项真正可以改变世界的科学发现,也圆了我好多年前的梦想(刚刚查了查时间,那篇写愿望的BLOG恰恰是认识yb前一天写的,挺有趣。BLOG是一笔财富)

yb和emily的论文发表了

  刚收到DMQ教授的邮件,yb和emily的学术论文An Integrated Workflow for Identification of Cross-linked Peptides from Complex Samples很快就要发表在Nature Methods上了。

  强烈祝贺。然后写点回忆,这是一个很长的故事。

  第一次见到yb是搬着服务器去BPRC测试的时候。他还是实验室里的一个低薪临时工,干着不擅长不喜欢的边缘工作。但jw和lz评价说:“yb这家伙的坚定理想就是献身科学”。后来DMQ教授回国,四处求贤,yb就成了最早一批加入dong lab的员工,拥有了至关重要的平台。

  yb想做cross link,最初周围反应不算积极。这是真正的重大创新。他的技术方案是把两个肽段粘在一起送进质谱。单肽运算量尚且很大,两个肽段的计算规模又变成了N*N,这自然涉及到大规模数据处理,于是国内唯一拥有自主蛋白质搜索引擎的pFind组就成了他的合作伙伴。具体负责pFind cross link版的程序员是宇宙超级无敌代码美少女emily。

  然后就是死磕,死磕,死磕……这个BLOG的大部分读者大概对技术细节不感兴趣,内幕很可怕,不细说。要想看整体,可以读yb的论文;想了解并行计算负载均衡调度有关的部分,可以看我的论文和专利

  这事做了很多年。yb孩子出生那几个月,还每天在实验室里熬夜。pFind组也付出了艰辛努力。发一篇影响因子超过20的顶级国际期刊,经过各国领军的同行评审并同意发表,哪有那么容易。投稿被拒不止一次。试验数据不断补充,最后增加到存储和传输都成了问题(中国没有亚马逊在美国的数据迁移物流服务,把一整卡车的硬盘安全送到另外一个州,且保证数据不损坏)。

  这事做了很多年。我和yb逐渐成了好朋友。我们两个年龄差不多,经历也很像,都曾经是实验室里打杂的二等员工,最后作出一些让旁人跌碎眼镜的成果。苦闷的时候,在一起喝酒。他说,有勇气的理想主义者不多。

  这事做了很多年。做到最后,emily写完所有代码,把所有能想到的东西都整理成文档,把自己曾经遇到过的坑都仔细说给接手人之后,就到上海当大摩金融女去了。最后的最后,因为pFind团队放弃创业,我也跳槽到阿里云来搞ODPS了。走前做的最后一次超级计算机上的大规模数据试验,就包括pFind cross link版的测试,确保几百核CPU的机器上加速效率依然超过80%(嗯,我那个负载均衡算法目前依然是世界第一,大大领先于美国同行)。

  我走的时候,好多人给我打很长的电话,yb也是其中之一。

  留下来把事彻底干完的yb,再见面气场肯定占优势。这个世界最棒的特点就是,能长久持续的幸福感都与物欲无关。我得抓紧时间让yb请吃饭。这家伙快去美国了,学术生涯的第一篇论文,起点真tmd高。

离职

  大家都知道了,所以就提前在BLOG上写一下。

  我将于今年12月底从中科院计算所生物信息研究组离职。到阿里云计算公司任产品经理。

  2003年5月,人脸识别课题组招聘软件工程师。当时正值非典,面试当天只有我一个人到场,其他应聘者都被隔离了。于是幸运地得到了这份工作。此后2005年6月调入生物信息研究组负责pFind引擎的产品和架构。算起来,在计算所服务了8年多,做pFind超过了6年。这期间,读取了在职学位,发表了两篇SCI论文,申请了若干发明专利、软件著作权和商标,还成了计算所内部培训师,买了房,买了车,结婚生子,交了一大堆朋友,由生涩的毛头小伙儿变成了三十岁大叔。

  我进入pFind组的时候,pFind还是一个学术demo,BOSS H对我的要求很明确:让它能真正在生物研究一线用起来。经过pFind Team这些年的努力,pFind Studio共发布6个重要版本,累计开发20万以上C++代码和10万行的python或Java代码,申请10项发明专利。到2011年年初,pFind引擎已经在国内外63所大学、研究机构和公司安装,其中包括Duke University, MIT, NIH, UCSF, LICR, Thermo等。在此基础上构建了“哪吒”云计算平台,为多家生物研究机构提供在线服务。在pFind组的大多数日子里,我都是“跳着踢踏舞去上班”的。不是所有人都能把兴趣作为职业,拥有pFind这样一个平台去施展才干,我对此心怀感激。

  另一方面,从2000年本科时代参加创业大赛接触风投开始,始终怀有创业理想。很早前就在pFind团队里明言:“如果pFind失去了创业可能,我会在第一时间离开”。最近两年pFind在学术领域进展顺利,我与BOSS H进行了坦诚交流。由于pFind在接下来几年内肯定不会创办公司,所以我选择重回工业界。

  我可能在阿里云参与研发离线计算平台,和科学计算有关联。所以还有机会与生物信息的朋友们继续合作。

  工作地点还在北京,手机和私人邮箱等联系方式都不变。祝大家新年快乐。我会继续写BLOG。

从卫生巾说到生物云计算

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

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

1024个CPU核下的测试

  正在单位加班。所里新建的平台上有96小时独占机时,可以跑一些1024个CPU核的测试。机器跑起来了,等结果的空隙就上来敲点BLOG。

  这次测试,对pFind来说只是重复以前在曙光500A和升腾7000上的试验结论。昨天pFind引擎刚启动,系统管理员就报告他那边的性能监控服务里面, 各个节点的CPU占用率都满了。首先跑了一个热身任务,在腾冲嗜热菌数据上,设置了包括磷酸化在内的5个修饰,开300Da的超大误差窗口,跑了4小时,看来很稳定。上次超龙一号超级计算机硬件插电测试,用pFind烤机,随便跑跑,就报警说CPU过热。

  pNovo是第一次走这么大规模并行测试,一开始IO有点阻塞,换了OpenMPI,效果就好起来,1024核情况下加速比甚至超过pFind。

  pLink还没跑,估计比较麻烦,对于这种谱少,搜索量重的情况,负载均衡是个问题。早上开车去NIBS找yb拿pLink测试数据,他也在加班做试验。看到dmq老板也在加班赶deadline。

  前天为试验做准备的时候,发现系统里面现有的MPI库都被损坏了,不得不自己安装;另外发现集群的文件系统句柄数上限只设置为1024个,改为65536个。不禁怀疑此前使用和测试的课题组的测试认真程度,这些基础设施都有问题,能测多大规模的并行任务呢。不管别人如何,我这里不放卫星扯淡。其实吧,技术上到底是不是有货,很容易感受到,例如一起汇报的时候,工程师的气场就不一样。

  感谢各位同志们的帮助。

  最近挺累,但心情不错。上个月有一天晚上疲惫地回到家,吃完饭,抱着女儿哄她睡觉,“等你长大了,会发现世界的不完美,会郁闷,但是要相信,总可以找到值得托付的人和事”。她眼睛瞪得大大的,突然咧开嘴冲我笑。一瞬间,绷得紧紧的神经就放松下来。第二天,接到了纠结期盼已久的重要电话,总算熬过了最低潮的阶段。女儿是我的小福星。