Category Archives: 科技评论

GeneDock研发团队的一些方法论

  逼着自己上来写BLOG。最近工作强度非常大,回到家吃完饭洗完碗,真的手指尖都不想动一下。不过工作有进展,人有成长,心情还不错。今天冒着大雨回家,浑身湿透,但是心里一动:“两年前的今天我心情很糟,现在虽然累得像条狗,却很充实,看来这次创业是对了。”

  创业以来,感觉还算顺利。所谓好运气,部分源于GeneDock团队有一套自洽的逻辑。创业和投资说到底拼的是世界观,你对现实世界的某个局部有独特的洞见。这里面有些关于技术产品,有些关于团队管理,有些关于商务销售。

  这篇BLOG再总结一下GeneDock研发的方法论。算是呼应一年前的那篇《思考:如何开发应用平台》,对其做一些补充或再次强调。

一、彻底信仰API

  Alex Iskold说:“API代表公司的业务本质……思考API实际上就是思考公司的未来……”

  绝对赞同,一年多前我在社交网络发过一条对国内一些所谓基因云的吐槽:“不是做个Web页面就有资格叫云计算的。前端若不提供RESTful API、编程语言SDK以及UNIX风格的CLI工具包,后端若没有可拓展的分布式架构、防单点故障的failover机制……就别觍着脸自称云计算了,这只是一个网站而已”。这话似乎刺痛了某些人。

  GeneDock刚刚对外开放了第一批Workflow和Task有关的11个API。欢迎大家试用,这里是API-Reference文档。如果单从Web Service的设计这一点看,我们的产品领先于国内外友商。

二、To B 的产品逻辑:别抖机灵

  To B 产品和 To C 产品有很多业务差异。To B 是给专家甚至专家团队用的软件,本质上在卖你对行业的独特洞见,在卖你的工作哲学。例如,当年SAP的ERP软件最成功,因为他们最理解德国制造的业务逻辑;再如,Salesforce在卖的是销售团队的方法论;而GitHub实际在卖他们对软件工程的理解:Bug管理、版本管理、Code Review……

  另一方面,To B 和To C 其实都是给人用的软件。从设计和研发的方法论来看,并没什么本质区别。GeneDock产品经理何荣惠(在阿里云的时候程序员们昵称“神仙姐姐”)在知乎回答过“to B 的产品经理和 to C 的产品经理有什么差别?”,我觉得写得很好。

  总之。To B 产品,抖机灵没用,保持克制和敬畏。躬身入局,琢磨清楚基因数据传输、存储、分析、应用的所有业务场景。

  我们刚刚上线的企业账号功能,对很多团队都有用。GeneDock官方BLOG对此有描述,推荐大家看一下。

三、坚守软件工程底线

  GeneDock只雇用最好的程序员。好程序员必须能熟练应用软件工程的成功方法论。

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

  不只是提高自己内部生产率,GeneDock还想把数据生产的最佳实践推广到整个行业,成为生物信息行业的GitHub。我们正在优化配置和调试的体验,总结GeneDock生信团队的流程规范。后面会不断放出软件工程培训文档和配套工具,让生物信息程序员们效率更高,更专业,工作更有价值。

GeneDock架构师介绍分布式基本原理

  GeneDock首席架构师陈昕刚刚在公司网站上发表了一篇BLOG,介绍了有关分布式系统的基本知识,例如一致性问题、FLP不可能性原理和CAP定理。推荐大家看一看,了解客观限制,免得试图制造永动机。

  原文地址如下:https://www.genedock.com/blog/2016/05/27/20160527_distributed_system/

Max Levchin

  继续八卦,这次是Max Levchin。他是Paypal黑帮的关键人物,23岁的CTO,重要性仅次于Elon Musk和Peter Thiel。

  之前在《支付战争》的读后感里提过他。我又去翻了翻Founder at Work,原来第一章就是对Levchin的采访。其他信息来源包括维基百科,以及他在Quora上回答的问题

创业者  支付战争

  Levchin 16岁从乌克兰移民到美国,数学天赋极高。他擅长安全加密算法,所以创立了Fieldlink公司,想做移动设备的安全技术供应商。后来找到Peter Thiel当合伙人和CEO(Levchin只喜欢和聪明人共事,Peter Thiel小时候得过加州数学竞赛第一名)。Levchin对Paypal创业的回忆很少涉及那些著名的运营手段(直接给新客户10美元补贴等),也没怎么提Elon Musk和Peter Thiel之间的宫斗戏(稍微说了说Elon Musk逼研发团队改用Windows,结果导致政变),他讲得最多的是如何对付金融欺诈,这在《支付战争》里几乎没被提到。

  2001年Paypal因为信用卡诈骗每月损失1000万美元,而且比率还在不断上涨。这引起了团队的恐慌。Levchin自己一度有些绝望,然后开始全力应对。最终Paypal开发出一整套防欺诈的工具,称为IGOR。很多今天已经习以为常的互联网防欺诈手段,都源于那时候Paypal申请的专利。例如现在常用的CAPTCHA技术:多次输入密码错误后,会显示一张只有人类可以识别的图片,要求用户按照图片内容输入验证码,防止黑客利用程序暴力破解密码。

  按照Levchin的说法,竞争对手eMoneyMail就是因为无法控制商业欺诈,损失比率达到惊人的25%,不得不退出。而《支付战争》的作者似乎没有意识到这一点,他认为Paypal就是业务增长速度正面碾压了eMoneyMail,所以对方放弃了。可能两边都没说错,技术团队和市场团队不同的视角而已。Levchin评价《支付战争》总体还是很有趣的,虽然个别地方错误。

  感觉最近新闻很多的Palantir的技术框架应该就源于IGOR。Palantir是Peter Thiel投资的创业公司,利用金融领域反欺诈的大数据工具,帮助美国政府进行反恐,据说在追杀本拉登的行动上出了力。大名鼎鼎的棱镜监控系统获取的海量元数据,需要有合适的数据技术进行处理。

  Paypal被收购后,Levchin花了很多年创业做Slide,不成功,最后卖给了Google。他又回到最擅长的互联网金融领域做了Affirm。他在Quora回答在Paypal积累的经验对Affirm创业有何帮助:“People underestimate the complexity of legacy payment infrastructure. Solid knowledge of that helps a bunch. More broadly, the greatest lesson is always the same: people is what makes or breaks every company.”

  去年他又推出了Glow,一开始还以为是类似“好孕帮”一样的助孕APP,好诡异。仔细一看:”夫妇可在备孕时每月连续往这笔基金内存钱,每月50美元,连存10个月。如果10个月之后Glow还没能帮助你成功受孕,这个基金则会资助你后续的检查和治疗……Levchin把Glow的未来定位为一家健康保险公司。而现阶段要做的就是收集数据、改进算法,帮助更多夫妇成功受孕”。 牛,原来还是玩金融,这智商税太有才。

思考:如何开发应用平台

一、开发难度

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

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

成长和决策

  创业以后就变得紧张,有时候睡不着觉,没有心情更新博客。其实工作量还好,GDers大都是出色的工程师,团队也采用了成熟的软件工程,尽管工作强度很大,却不太加班。

  紧张是为个人能力不足而焦虑。真刀真枪开始创业,挽起袖子一个个PK问题,以前养成的粗心和懒惰的坏毛病就跳出来了:竞品调研不深入,代码review不仔细,琐碎管理没耐心、文档和邮件拖延症、人际交流疏忽大意……运气好,合伙人和团队都是顶尖的,同伴互相帮忙扛了很多事。但是团队在进步,跟不上,你自己就是瓶颈。

  刚去德国休假调整了一下,静下来仔细想了想。接下来得更勤勉努力,也需要更有效的沟通。关键是执行!关键是执行!关键是执行!(重要的事情说三遍)。希望自己还能不断成长。在BLOG这里把当下的心情记录一下,日后印证。

  放几张德意志博物馆的照片,这里被称为“工程师的卢浮宫”。

  再聊聊决策。

  上周去计算所参加了一次创业沙龙。做了一点分享。除了介绍我们的产品,还聊了聊创业本身,尤其是关于决策,内容整理如下:

  1. 无论做什么事,关键都是决策和执行。
  2. 所谓高效的决策,就是在有限的时间内,凭借有限的信息作出正确的选择。这里面有很多重大选择,短期看无所谓好坏,然而涉及长远目标的取舍。
  3. 时间信息有限的情况下,要是没有一套自己现成的逻辑,就成了赌博,决策质量不会太高。
  4. 逻辑或者说方法论,源于系统化的阅读、交流、试验、学习和思考。
  5. 诺贝尔获得者那本《思维,快和慢》讲的就是这件事:人类的大脑有两种思维方式,一种是逻辑思维,很慢很费能量,但能应对复杂场景;还有一种是感性直觉,很快,但几乎是最原始的神经反射。系统很懒,总是不自觉地就切换到“省电模式”去了。而且关键时刻,在压力和情绪作用下很难静下心思考,往往是直觉占上风。正确的直觉并非天生,源自大量的自我训练和经验积累。
  6. 搜索引擎有离线和在线两套系统,离线系统很慢,但是负责抓取全网的数据,build索引。而真正查询过来了,在线系统直接查找索引,几句if else if else就快速返回答案。
  7. 平时对一个主题不涉猎没概念,没有构建牛B的索引,事到临头指望灵光一现,往往会进退失据。所谓机会给有准备的人,我在团队招聘时感触很深,很多人真的不懂创业,同时也没想清楚自己能做什么,想要什么。
  8. 在创业这件事上,很多朋友很有热情,但表达出来的逻辑很浅:迭代改进、不怕失败和挫折、独特的点子、找用户体验的痛点、点灯熬油加班拼搏……总之,基本来自网上鸡汤段子和《乔布斯传》的片段,却缺少详尽的调查和学习、深入独立的思考、清晰的自我认识、与众不同的洞见、以及细节上的取舍决策。
  9. 指望用蛮力代替深思熟虑,这不靠谱。读万卷书,行万里路,把精力集中在长远目标上,把自己训练成领域专家。
  10. 我选择厦戎这个老大,就是因为他的决策质量非常高。

  叭叭呜的知乎专栏最近有一篇文章,讲述了Segway公司早期和乔布斯的交流。 即使交流对象是乔神这样的偶像,没有独立思考和逻辑,被对方洗脑,也是很危险的。Segway这件事里,即使乔布斯说得全对,他们也许还是应该咬着牙继续坚持原有节奏。而不是丧失信心推迟发布计划,甚至要“做出一款让乔布斯尿裤子的产品再发布”(注意,连语言表达方式都被乔布斯影响)。

谈谈ODPS商业化(五):华大基因在ODPS上做的试验

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

  由于我正在着手做生物信息云计算方面的工作,很多信息不方便透露,这篇会很短。有兴趣的同学请找我线下交流。不过在阿里云上做基因测序创新的同学们不必担心,阿里云没有野心、也没有能力成为一个提供完整基因测序计算服务的公司。相反,ODPS等等产品一定是做底层通用平台该做的事,帮助生物信息应用上云更方便,和创业者们一起成长。

  回来开始说华大基因在ODPS做的试验。以前写过一篇博客提到过这件事。

  将基因测序仪输出的上亿条DNA片段拼接为基因组长序列,这个过程可以看作在一个超大规模的拓扑图上寻找欧拉路径。人类基因组包含30亿个碱基,目前基因测序一般会做30倍到50倍的扩增。利用典型的单机组装软件至少需要256GB的内存才可能完成基因组装,时间长达数天。

  ODPS Graph Task是面向迭代的拓扑图算法处理框架,提供类似Google Pregel的BSP并行编程模型。正适合支持一些超大规模拓扑图算法。

  去年10月5K项目测试期间,华大基因的生物信息专家基于ODPS Graph Task开发了一套基因拼接算法,在E.coli(大肠杆菌)、Bombus(熊蜂)和Yanhuang(人类)三个物种的测试集上均取得了非常高的加速比。

  此前一直关注Google在生物信息领域重兵投入。自从Google Genomics API推出,形势就更加明确了。另外一边,据称亚马逊AWS美国有1/4的客户来源于生物制药行业。生物信息显然是云计算的重要业务增长方向。随着全球第一张基因测序临床牌照的颁发,已经可以看到国内大量围绕基因测序的创业项目起来了。目前ODPS团队正在和多个生物信息领域的合作伙伴一起努力,把各种生物信息经典算法和数据处理流程搬到云上来。如果你正在做这方面的产品、创业,欢迎和我联系,阿里云会尽可能提供关键帮助。

  另外我刚刚在知乎和知因同时发起了问题:生物信息还需要云计算提供什么样的功能?生物信息应用上云,你碰到了哪些问题?现有的阿里云、亚马逊AWS云计算基础设施需要做哪些改进,为什么?目前你用的最多的云产品和Web Service API是哪些? 等待你的真知灼见:
  知乎:http://www.zhihu.com/question/24719395
  知因:http://www.knowgene.com/question/1639

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

谈谈ODPS商业化(四):2014阿里巴巴大数据竞赛

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

  几天前2014阿里巴巴大数据竞赛刚刚落下帷幕,第11名的F1分数、准确率和召回率是6.10%、6.28%和5.93%。前10名的成绩还未公布,他们会被邀请到阿里巴巴公司来,有机会和内部团队一起参与双11。选手们闲下来,开始在群里爆特征、开玩笑、交换联系方式。

  这次海内外共有7276支队报名。比赛分为多个阶段:S1是线下海选,从S2开始上ODPS,每月底淘汰末位的100支队,直到7月31日尘埃落定。选手们需要像阿里数据分析师一样工作,完全依赖云端的ODPS平台上的SQL、Mapreduce和Xlib/Xlab算法工具处理大数据,E2E完成建模全过程:划分训练集和测试集,选择模型,抽取特征,处理过拟合,采样正负样本(向上采样、向下采样),调参,特征和目标值的处理,模型融合……几个月下来,有不少同学分享了心得和感悟:

  来着如临高山,往者以观逝水
  成也solo,败也solo
  事非经过不知难
  大数据竞赛所历所思
  点说那些年参加过的竞赛
  STO_OTZ队的比赛流水账以及心得感悟
  那些在坑里翻滚的日子
  一场比赛、一组数据、一个梦想
  ODPS SQL 构建离线评估
  超级啰嗦版ODPS MapReduce入门
  第一季总结:LR入门
  阿里大数据竞赛season1总结

  有次看到阿里云后台的客服工单:“想实现逻辑回归分类算法,使用随机梯度下降算法来优化参数,怎么在大规模分布式系统下实现?你们的xlib已经有了,我就是想问问^_^”。阿里云的售后支持mm真心累啊。发了一条微博说:下次再有这种调戏就回答“想知道吗,给我们投简历吧。”结果第二天就有参赛选手分享了这篇博客: 在MapReduce中实现随机梯度下降法(这篇文章对算法实现原理写得很清楚了,但用Mapreduce编程模型实现迭代类算法性能是很弱的,大多数人还是直接用Xlib实现好了的逻辑回归、随机森林、GBRT等算法)。

  还有好玩的,有一位在台湾上学的参赛者利用S1的参赛队的排名信息深入分析了一番,写了这个:阿里大数据 – 中国好大学

  比赛筹备一年多,很辛苦,很成功,恭喜得福和一婷。对于即将毕业的学生来说,关注并参与这次比赛,能深入体会工业界数据分析师的工作场景。另外,除了比赛内容本身,我想提醒读者注意天池平台。数据交换的业务模式已经开始萌芽。

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

谈谈ODPS商业化(三):阿里金融的业务

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

  阿里金融是ODPS第一个用户,业务发展很快,备受关注。网上能找到很多报道,例如以前一篇BLOG引用过《 一笔B2B贷款的旅行》。近期又披露了A-GDS系统和水文模型,大家可以自己搜索(作为参与者,终于能把这些曾经保密的词写在公开渠道,真爽)。通过这些已经能大体了解到阿里金融如何利用海量数据挖掘信息,并据此确定信用风险和额度并发放贷款。所以这篇BLOG会短一些。

  阿里金融团队里,程序员和数据分析师占绝大多数。这些同学都在ODPS上忙什么?

  金融的核心是对风险进行量化评估。举个例子,发信用卡给某人,必须先拿到对方的信息,根据各种指标进行打分,估算出这个人赖账的概率,评估期望收益减去成本之后的盈利空间,并确定授信额度。通过特征计算信用额度是一门专业的金融建模技术,称为“信用评分卡”。大家可以到豆瓣上搜一些经典教科书。“信用评分卡”一般是由一系列的特征选择、回归统计和评价算法组成。

  传统金融行业能获得一个人的信息是有限的,几页纸的表格资料就填写好了:生日、性别、教育、婚姻、城市、单位、职称、收入、财产、负债、健康……所以传统的信用评分卡模型,输入训练集的特征矩阵也就上百列。同样的方法拿到互联网企业来用,嗯,我们能收集你这个人的一切数据:用iPhone还是Android,接收包裹的地址是高档小区还是地下室,在天猫旗舰店买首饰和包包有多腐败……如果你是淘宝或B2B卖家,支付宝里赚到的每一笔现金流都可以反映你的还债能力,甚至会测评你对假设情景的掩饰和撒谎程度。于是信用评分卡模型就必须能处理好几百万列的特征矩阵。而且,疯狂的数据科学家们想到,每月、每周甚至每天的授信额度都应该动态调整,就像江河里的水位一样随季节涨落,例如双11之前,根据往年的数据预测,模型会自动给电商卖家逐步调高额度,而春节之前又降到最低(这也是“水文”模型名字的来历)。

  业务需求如此,海量数据必须要存,要过滤,要计算,要建模,包括调度和监控、授权和审计、数据质量控制、元数据管理等重要问题都要有解决方案。于是神说,要有ODPS,要有水文模型,要有A-GDS。

  阿里金融的生产流程都在晚上跑,是典型的数仓场景:把上游数据定时拖进来,ETL清洗整理后进入数据仓库,然后针对上层业务提供垂直的数据集市。每天离线作业完成之后,数据就会被灌入OTS和RDS这类在线服务,为日常业务提供支持。而在白天,分析师们使用SQL进行数据探查,写程序或调用统计机器学习的工具包进行数据挖掘和建模,并把开发测试好的模型发布到线上生产。

  阿里金融在ODPS上每天处理30PB数据,800亿个信息项,运算100多个数据模型。ODPS上的信用评分卡模型(以逻辑回归为核心的十几个算法组成的建模流程)一般会跑上百万维特征,上亿行样本的训练集。有了强大平台的支持,阿里金融就可以给没有资产可抵押的小微企业发放贷款,每一笔贷款成本是传统银行的1/1000,且坏账率非常低。

  写到结尾,我终于可以像购物节目里面的亢奋主持人一样说点煽情的:“ODPS可以120%的满足你的所有梦想,现在打开电脑,登陆www.aliyun.com,展开你的神奇大数据之旅吧!”

  顺便提一下,其他金融类业务也都在用ODPS了。余额宝前两天在微博上发了一组好玩的数据统计,“广东、山东、河南男人们的私房钱最多”。

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

谈谈ODPS商业化(二):ODPS的计量计费模型

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

  ODPS正式商业化以后,微博上议论比较多的是计量计费模型。刚好这件事我全程参与,仔细写写。ODPS的计量计费规则和价格请以阿里云官方网站上的说明和数字为准。这里的内容只反映当前状态,不能保证实时更新。

  ODPS收费以项目(Project)为单位,对存储、计算和数据下载三个方面分别计费。存储和数据下载的收费形式与其他云产品很类似。而计算这边,目前ODPS仅开放了SQL任务,计费公式为:一次SQL计算费用 = 计算输入数据量 * SQL复杂度 * SQL价格。具体而言:
  1.计算输入数据量:指一个SQL语句实际扫描的数据量,大部分的SQL语句有分区过滤和列裁剪,所以一般情况下这个值会远小于源表数据大小。
  2.SQL复杂度:先统计SQL语句中的关键字,再折算为SQL复杂度
  SQL关键字个数 = Join个数 + Group By个数 + Order By个数 + Distinct个数 + 窗口函数个数 + analyze个数 + max( insert into个数-1, 1)
  meter
  例如,用户输入的SQL语句是:INSERT INTO TABLE out1 SELECT * FROM shop a JOIN sale_detail b ON a.shop_name = b.shop_name;则其SQL关键字个数是2,而SQL复杂度是1。
  再例如,用户输入的SQL语句是:SELECT DISTINCT total1 FROM (SELECT id1, COUNT(f1) AS total1 FROM in1 GROUP BY id1) ORDER BY total1 DESC LIMIT 100; 则其SQL关键字个数是4,而SQL复杂度是1.5。

  对于上面这个模型,大家常常提出各种问题:为什么只考虑数据量,而不引入CPU、内存、网络通信等直观的技术指标?进一步,为什么不引入计算时间,使用像“CPU*小时”或“内存*小时”这样的计量单位?为什么引入SQL复杂度这样一个稍微麻烦的概念?模型里包含的关键字和公式里的权重是依据什么标准确定的?从一开始,ODPS策略团队的数据分析师就在这些拷问中不断纠结和探索。

  由于ODPS在阿里内部已经大规模投入使用,每天生产上跑着几十个BU的上万个作业,吞吐上百P的数据。因此分析师先拿到日志,各种清洗,各种图表,各种统计探查,各种回归和分类,获得了很多好玩的发现。由此产生的结论是源于严谨的数据分析和产品逻辑,并通过各方面很多审核。

  下面就来说说建模的过程。由于保密原因很多具体细节不能公开分享,但总体思路也许值得大家看一看。

  首先,要明确什么是好的计量计费模型?计量计费模型是产品特征的重要组成部分,需要遵循的的几个原则:
  1.基于统计,简单,可解释:不拍脑袋YY,模型的逻辑源于统计事实;在可行范围内尽量简化;公式的输入参数都应该是用户可见的条件;
  2.可预期,可重复:在跑计算作业之前,用户能根据输入和环境配置算出这次计算底能花多少钱;完全同样的作业重复跑价格不变;
  3.正引导性:用户采用符合“最佳实践”的操作方式不会受到惩罚,最好受到奖励。
  关于以上这些计量计费原则,举一些类比的例子。
  例子一:手机话费的计量,两个人面对面用手机打电话,与一个在城南一个在城北打电话,实际成本肯定不一样,但是如果电信运营商直接按照通信链路经过了几个路由器,几次转发来计费,用户就要晕倒了。所以真实的计费就采用相对粗略的、阶梯的、区域的划分。因为这符合前文提到的3条建模原则。
  例子二:伊拉克战争中,由于基础设施匮乏,电力局收电费,不是按照电表算,而是到用户家里数灯泡和电器的个数,一个灯泡多少钱,一个空调多少钱。这个计费策略当然很粗略,但是它在这个特定场景下是行之有效的。仔细看看,你会发现它同样符合上面的3条建模原则。

  接下来,要考虑怎么衡量一个计算作业的成本?
  很常见的想法是:把一次计算占用的进程、内存,以及中间IO交换的数字都拿出来,分摊对应的硬件成本,也就是CPU、内存、网络设备和磁盘。
  这个思路是错的,因为实际运行的作业占用各种资源肯定不均衡,总有瓶颈。集群的计算节点是个有机整体,部件不能拆开单用,如果某瓶颈环节100%占满了(例如磁盘和网络IO能力),即使其他硬件空闲(例如CPU),也不可能拿去给其他作业使用了。
  所以正确做法应该是:先统计到底哪项功能指标是瓶颈,平均闲置率最低,然后以该指标直接换算整个节点全部成本,其他指标都可以忽略。当然,不同的计算作业瓶颈不一样,成本分摊的方式也会不一样,例如Mapreduce类作业一般是IO密集型的,磁盘和网络IO交换是瓶颈;而MPI类的算法一般是CPU密集型,CPU和内存是瓶颈。

  有了上面两项思考逻辑做为基础,回过头来,我们看看上文用户提到的问题。

  SQL计算的计量模型为什么引入输入数据量作为参数?
  很明显,因为SQL以及它背后的Mapreduce计算是典型的IO密集型运算。而且“输入数据量”符合上文计量计费原则1和原则2,用户可以自己查看、控制和预估。
  这样还有个好处,就是让用户时刻注意语句的写法。因为这里的“输入数据量”是指实际扫描的数据量,如果SQL语句有分区过滤和列裁剪,费用就会远小于源表数据大小:
  a) 列裁剪:例如用户SQL是select f1,f2,f3 from t1; 只计算t1表中f1,f2,f3三列的数据量,其他列不会参与计费。
  b) 分区过滤:例如SQL语句中含有where ds>”20130101”,ds是分区列,则计费的数据量只会包括实际读取的分区,不会包括其他分区的数据。
  有了这个游戏规则,精明的用户一定会尽量用select f1, f2, f3 from…替代select * from…,能用分区裁剪就尽量避免全局扫描。而这正符合数据仓库开发的最佳实践。很多成熟的数仓团队已经把它作为生产纪律强制执行。比如“不准使用select * from …”这一条,如果上游表追加了新的一列(这在数仓生产中很常见),使用select *的SQL作业往往运行失败。因此,我们的模型又符合了前文建模原则3,鼓励最佳实践,平台和用户都会因此获得好处。
  一个有趣的现象是,当我们用这个计量计费模型试算阿里内部不同团队的作业时,也发现了分化:有一些BU,例如阿里金融,拥有很多资深的数仓专家(这些家伙甚至能用SQL实现一个跳棋程序),这种团队的计算花费汇总下来,往往接近甚至低于平台的成本曲线,说明其主力生产SQL经过了精心优化;然而也有一些BU的团队,显然刚开始接触大数据分析业务,把ODPS当MYSQL用,于是产生的计算费用远远高于平台耗费的成本。我们可以推测,对外的场景下也会有类似的事发生,而且随着时间推移,用户行为会整体向更经济的方向移动。这也是平台团队想要看到的,因为我们可以腾出更多资源给新用户和新业务。

  为什么不引入CPU、内存、网络通信等更直观的技术指标?为什么不引入计算时间,使用像“CPU*小时”或“内存*小时”这样的计量单位?
  的确传统的超算中心是这么计费的。我们认为做错了。因为这样做违反了上文计量计费建模原则1和原则2。
  运行一个SQL作业占用多少CPU、内存、网络通信,完全是由平台方的具体技术实现决定的。这些参数其实和用户无关,用户也无法控制,无法预测。平台定义某条SQL很贵,用户也没办法跑来看代码,挑战说ODPS不应该用这么多内存。
  另外,参考前面说的,其实不需要那么好多个指标,只需要关注一两个关键的瓶颈指标。
  进一步,对于ODPS这样的离线计算场景而言,不可能保证每次运算的时间精确一致,更无法预测。如果以运行时间为依据收费,有可能第一次运算用了10分钟,第二次由于调度原因或者发生了failover,用了12分钟。如果完全相同的计算,今天收1块,明天收1.2块,用户就疯掉了。
  反过来说,采用这种计量计费模型,也会让平台技术团队丧失持续优化系统的动力。

  为什么引入SQL复杂度?模型包括的关键字和公式里的权重是依据什么标准确定的?
  由于ODPS支持强大的SQL语法。实际运行中除了显式输入输出,中间阶段还会进行多次临时文件磁盘交换(专业术语一般称为Shuffle)。例如:可以在一条语句里,join十几个表,套上七八个子查询,再加上各种全局分组和排序……这些操作都会导致IO的明显增多。问题是直接采用中间IO量或者Shuffle次数计费,又违反了上文的计量计费原则1,于是我们必须寻找替代方案。
  幸好能造成Shuffle的SQL关键词操作只有7个:Insert Into、Join、Group By、Order By、Distinct、 窗口函数和analyze。因此我们尝试用关键字个数来拟合中间IO,获得了不错的效果。公式里的权重值都是依据阿里内部实际生产的日志回归出来的,是科学和严谨的。

  说到这里。用户可以看看Google BigQuery是怎么收费的。他们甚至在官网上贴了一篇文字,描述其计量计费模型的“设计哲学”。Google BigQuery与ODPS商业化的进程一先一后,大家彼此完全独立思考,得出的方法论和最终模型却殊途同归,这实在是一件很好玩的事。至于Google BigQuery公式里不包括SQL复杂度,原因也很简单:他们的SQL功能比ODPS SQL弱很多,例如根本就不支持两个大表的Join。由于这个原因,所以其SQL基本就对应于ODPS SQL中,复杂度为1的那个子集。

  和ODPS类似的公有云产品还有AWS EMR。不过EMR本质上是租用虚拟机然后在上面搭hadoop,不是多租户的,也就是多个用户无法分享单节点上的计算和存储。因此大家的收费模型思路不同,针对不同的场景各有优劣。我很想看看接下来市场的反馈。

  当然ODPS还有很多需要做的,例如接下来会推出计费计算器:输入SQL,返回需要花多少钱。再例如会提供更多打包计费的方式,例如包年包月,以简化用户的智力负担。ODPS还支持SQL以外的更多功能,例如mapreduce编程模型、xlib机器学习算法,它们如何计量计费还在摸索中。

  总结一下。如果您是ODPS用户,希望这篇文章展示了ODPS计量计费模型的逻辑,能帮你优化作业节省成本,也希望您能体会到其中的诚意。如果您是同行,云计算领域的产品经理,期望这篇文章对你规划自己产品的收费策略有借鉴意义。我们在创新,要获得问题的答案,甚至定义问题本身,都需要洞察和思考。

  最后感谢ODPS策略团队,尤其是数据分析师@班马明,上面这些逻辑都是他被几百张图表痛苦折磨几个月之后逐步梳理出来的。事实不止一次证明,数据分析师要有一颗产品经理的心,反之亦然。顺便提一下,面对ODPS系统的海量日志数据,@班马明同学“吃自己的狗粮”,利用ODPS本身完成了数据的抽取、探查、挖掘和验证。

  这篇是ODPS商业化一系列文章之一,更多请点击这里……

谈谈ODPS商业化(一)

  首先深深道歉,居然五个月没有发BLOG。这几个月是我近年来最辛苦,心理压力最大的一段经历。也直接导致很多生活习惯被打破,例如早睡,例如定期备份工作目录,例如定期修改登录密码,再如逛书店,也包括每周写一两篇博客。这些习惯现在正逐渐恢复。感谢回来的读者。

  很多人可能已经知道了,ODPS在7月上旬终于实现了一期商业化,部分功能结束邀请试用,全网开放,开始收费。大家可以访问阿里云官网开通ODPS服务,并下载用户手册和SDK客户端。除了阿里云以公有云的形式对外租用ODPS的存储和计算能力,还有两个渠道可以使用ODPS:御膳房,是阿里数据平台事业部推出的大数据解决方案,可以支撑淘宝天猫大买家和ISV利用阿里丰富的数据;天池,是阿里技术发展部的平台,主要针对高校和科研单位进行合作,目前正进入冲刺阶段的2014阿里大数据竞赛就是基于这个平台举办。

  阿里对ODPS做了很多宣传,网上看到不少讨论。如果要了解ODPS的方方面面,我认为下面对子楠和常亮的采访是比较好的资料:

  汤子楠:飞天、ODPS经历了许多血淋淋教训

  徐常亮:ODPS的愿景、技术实现与难点

  还有不少朋友在知乎上问与ODPS有关的问题,我们也都尽可能做了回答。

  尽管刚刚对外开放,已经看到大量的第三方用户上来,在ODPS上做各种各样有趣的大数据业务。尤其是各个领域的创业团队给我留下了深刻印象:金融保险、电商营销,运动手环,手机游戏,基因测序……

  接下来我会写一系列的博客,从个人观点谈一谈ODPS的产品和业务。计划谈的主题可能包括: