Tag Archives: 阿里云

[得到大学课程作业] “转型者思维模型”:阿里云,一次成功的转型

一、背景

  阿里云目前占国内云计算市场50%以上,全球三强,近几季度保持高增速。

  然而2010年常见说法是:百度擅长技术,腾讯擅长产品,阿里擅长运营。阿里的技术形象并不吸引人。

  如何从电商公司转型为数据公司?这期间,我恰好在阿里云大数据团队做产品经理,分享一点“转型者”的亲身体会。

二、做了什么

1. 明确“数据为王”,巧妙包容原有主力业务

  2010年马云在国外讲演,“我们的云和别人不一样,核心是数据。”今天看来,他在试图解释“大数据”概念,此时big data这个词还没有在美国诞生。阿里内部很早建立共识:判断一件事是否重要,标准是“数据”。

  “数据为王”的战略与“让天下没有难做的生意”企业使命不矛盾。同时新的价值体系能包容原有业务:什么业务能产生含金量最高的数据呢?淘宝、支付宝……因此原有主力团队也会兴奋的加入进来,重新从数据的角度讲故事。

2. 用各种方法保护新业务

  早期阿里云不成熟。广为人知的事是2012年内网几千层楼的帖子,对王坚博士万炮齐轰。当时公司做了几件关键的事:

  1> 把阿里云和其他团队隔开。(如果微信团队没和总部隔开会怎么样?)

  2> 培养生态系统。团队被反复强调的纪律是,如果客户在做同样的研发,不要抢饭碗,往后退,一直退到没人愿意做的苦活累活。只要他们愿意迁移到云上来。

  3> 最难的时刻动用组织手段。例如让陆兆禧当CDO(首席数据官),内部都知道老陆已被定为下一任CEO。

  最终,发动所有协作力量,把主要数据和业务都迁移到了云上。

3. 构建数据中台,上云没有回头路

  业务上了云,如何保证局面不后退?最关键的是建立数据中台。前台业务产生的核心数据,全部收拢到一处。业务只有留在云上,才能获得基础设施和关键数据的支持。具体内容媒体报道很多,搜索“5K项目”。

三、结论

  阿里云是一次成功转型。个人认为以下因素是关键:

  1> 明确“数据为王”的新价值体系,巧妙包容原有业务;

  2> 用各种手段保护新业务,建立协同;

  3> 建立数据中台,让业务没有回头路。

  转型的复杂性要高于初创。要谨慎设计,要耐心推进,要在艰难时刻顶住压力。

谈谈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的产品和业务。计划谈的主题可能包括:

ODPS对外开放!

  ODPS刚刚上线成功,在阿里云官网对外开放!一期还仅仅开放Sql,很快会开放Mapreduce、Graph和Xlib等更多功能。公测阶段,用户还需要经过人工审核才能开通服务。

  加入阿里两年。经历了这么多,俺把这件事做成了。

  上个月AWS进中国反响很大,发了一条微博:“AWS进中国,对阿里云和用户当然都是好事。有了EMR,我ODPS就不再寂寞。明年可以好好杀一场。从进阿里第一天起,我就只盯着ODPS对外开放这一件事,终于快等到了。亚马逊,来战!”

  2014年会很有趣,看ODPS如何把对手打得满地找牙!

转到CDO部门

  我随ODPS团队转到了集团CDO(首席数据官)部门,做的事情还是那些:分布式并行、海量数据分析、数据仓库、数据挖掘。

  感谢阿里云,这是一家有技术理想的公司。前几天参加年会,看到博士在台上泣不成声,有颇多感触。马云说整个公司从CEO开始全都是不善表达、西装配球鞋的工程师范。

  最近一周在杭州,每天参加各种肉身会和电话会到很晚。周末抽空去了一趟西溪湿地,景色真不错。半年多以来我到杭州出差十几趟,这是第一次有闲心出去玩。

由背包兔谴责盛大云说起

  盛大云故障的事好像越闹越大,背包兔今天在微博里谴责盛大说:

     同时我们严厉谴责盛大这种用普通无备份的虚拟主机来冒充能数据备份的云主机,是一种彻底的欺诈行为!

  对于云主机的磁盘技术,存在不同的方案和思路,做些分析。

  亚马逊EC2的方式是采用本地磁盘作为系统盘,然后再挂上S3云存储作为数据盘。这样做的好处是系统盘会有很高的IO性能,同时节省成本。但也面临着一些风险,如果系统盘损坏了就有可能无法恢复。盛大在技术方案的选择上,照搬了亚马逊。盛大云的本地磁盘应该是做了RAID,这次也确实比较背,同一个机器上多块磁盘都同时坏了。

  而阿里云ECS所有的存储都放在飞天分布式平台上,也就是说无论系统盘还是数据盘,都是云存储,会有多份备份。同时阿里云ECS还会定时自动备份镜像。这样做的好处是安全性得到很大的保证,一旦有磁盘损坏就能自动秒级迁移到其他副本上,如果运气很差多份拷贝都坏了(估计比被雷劈中概率还要小上百倍),还可以回滚到此前的历史镜像。也正因为这样,阿里云的市场运营团队才有胆子公开宣传:发生故障给予100倍赔偿。

  当然阿里云的技术方案是有代价的:首先系统盘的IO就不会那么出色,其次造成的成本压力比较高。技术团队一直在对云存储进行大量的优化,已经取得了很好的进展,申请了一些专利(完全自主开发的平台,相对拿来开源方案,就有这个好处,有一支队伍掌握自己的命运)。同时由于市场逐渐打开,销售额上去了,摊薄了前期投入的硬件成本,所以最近价格也逐渐降下来了。

  对于站长们来说,不管用的是哪一家云,还是建议能更深入吃透云背后的技术原理,设计自己的方案。例如这次事故,如果预先把应用程序和关键数据分开,把关键数据设置放在云磁盘里,可能受到的影响就小一些。有能力开发脚本的,还应该开发一些定时备份的工具。

流水帐

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

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

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

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

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

我将参加easyhadoop聚会,并做一个分享讲座

  我将在第三次easyhadoop聚会上做一个分享讲座,题目是《阿里云ODPS:云端数据仓库服务》。

  ODPS目前尚处在邀请试用阶段。金融、零售、现代制造业和电子商务企业的BI团队租用ODPS服务进行海量数据的分析和挖掘,。这次我将简单分享一下产品的特点和客户应用案例。期待与你交流。

  地点:北京市海淀区新街口外北京师范大学教7楼302教室。

  时间:2012年05月19日本周六13:30 – 17:00。

淘宝数据盛典和ODPS

  工作开始累起来,周五开电话会直到晚上22:30。周六又开了一整天的会,遗憾地错过了童小军组织的“EasyHadoop应用开发者聚会”。《伯罗奔尼撒战争史》的第二篇读后感又拖延了,罪过罪过。

  自从来到阿里云,总被问:“在干啥?”。答曰:“ODPS”。又问:“ODPS是什么,能吃吗?”……这个,其实,之前已经在博客上透露过了

  淘宝数据分析团队的同学们做了这个浅显易懂的邪恶视频,充分展示了Big Data的商业潜力。如果想要更一本正经的市场分析,可以看看麦肯锡的这份报告,以及《福布斯》杂志的这篇报道。再深入一些,想了解如何租用ODPS服务对自己的网站进行数据挖据?看子楠和文志的这篇软文