first commit
This commit is contained in:
43
专栏/技术与商业案例解读/000开篇词突破技术思维,站在商业的角度看问题.md
Normal file
43
专栏/技术与商业案例解读/000开篇词突破技术思维,站在商业的角度看问题.md
Normal file
@@ -0,0 +1,43 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
000 开篇词 突破技术思维,站在商业的角度看问题
|
||||
开篇词 突破技术思维,站在商业的角度看问题
|
||||
|
||||
2017年6月,InfoQ的编辑联系我说希望能在“极客时间”中开个全年的订阅专栏,我收到邮件之后大约一半是诚惶诚恐,一半又颇欣欣然的感觉。
|
||||
|
||||
我从去年开始写公众号,最初只是把它当成梳理自己的知识和思维的一个方式。我陆陆续续写了很多方面的内容,从我最擅长和熟悉的大数据领域开始,写了大数据的发展史,到我不是那么熟悉的互联网行业的发展、职场就业、企业分析等多少都有涉及。
|
||||
|
||||
收到专栏邀请后,有一个问题就摆在了我的面前:我的专栏到底应该讲什么。和公众号不同,我希望给自己的专栏做一个相对明确而统一的主题。我的PhD训练教会了我一个非常重要的道理:选择比努力更重要。
|
||||
|
||||
屈指算来,我在互联网行业里摸爬滚打也差不多有二十年了。这些年里一半在求学,一半在工作。早年我非常希望自己可以成为一名教授,既能教书育人又可以做前沿的研究,后来阴差阳错进入了工业界,成了一名不折不扣的程序员。所谓时也命也,我做研究的时候主要研究数据库的基础架构问题,在工业界又赶上了大数据发展的早期,这让我比较早地进入了大数据这个领域。
|
||||
|
||||
但我觉得自己并没有选好赛道,因为我既没有进入谷歌这样的先驱企业,也未能站队Hadoop的生态圈。相反的我进了微软,从无到有地搭了一个内部大数据处理平台。这段经历让我在后来很长的一段时间里都在思考一个问题:在大数据领域,谷歌微软这样的大企业是怎样被Hadoop生态圈淹没的?
|
||||
|
||||
大约是所有博士生的通病,思考是常态。这个专栏我当然不想再谈大数据了,因为从那个问题开始,我慢慢地开始思考互联网这个领域里面的种种枯荣生息。我们常说,三十年河东三十年河西,这句话对于互联网企业来说就不适用了。
|
||||
|
||||
互联网这个行业的发展,以一种传统行业无法想象的速度在进行,三五年就可以造就一个大变化,20年就足够淘汰掉很多的优秀企业。君不见,20年前一些世界最知名的企业,比如RealNetworks,估计现在早就没有人知道了。再比如,15年前还以发明Java而享誉业界的Sun公司,现在早已破产,地盘被新起来的Facebook给买了。
|
||||
|
||||
我时常花时间去研究互联网行业的发展历史和趋势,这种研究让我渐渐有了一些心得体会。所以也就有了我在公众号上几篇影响力比较广泛的文章,譬如说我对Cloudera上市前的分析,以及对微软成功转型的分析。
|
||||
|
||||
这些文章和我之前的大数据系列有很大的不同,这种不同首先表现在受众上,有关企业生存发展、行业变迁的分析,只要言之有物,其受众面很广。无论你是互联网行业的从业者,想要创业的人,还是关注互联网行业的投资人,又或者希望了解互联网行业的发展并进而思考人生和世界的人,这个话题都是不无裨益的。其次是对我个人的挑战非常得巨大。
|
||||
|
||||
不过,偶尔写出几篇这样的文章来并不是最难的,尽管也需要花费我大量的时间精力,更难的是现在我要以此为主题写作专栏,做一年。
|
||||
|
||||
PhD们还是喜欢接受挑战的。我打算在这一年里,聊一聊互联网行业和企业的发展这个主题。确切一点儿来说,这个专栏的内容都会专注于这个主题,而这个主题又大致分为三块。
|
||||
|
||||
|
||||
第一块是从开阔眼界的角度出发,带你广泛而全面地了解互联网行业里的企业。我不但会介绍有特色的企业,还会分析一些有代表性的企业发展史,无论成功还是失败的。同时,我会关注一些成功企业的特质,比如亚马逊的领导力准则、谷歌对待创新的态度。此外,我还会聚焦特定领域的变迁和发展,比如大数据、办公软件、智能音箱等等。
|
||||
第二块来讲讲人。企业是由人构成的,互联网行业和其他任何行业一样离不开人的因素,尤其是那些有着特殊影响力的人。理解人在互联网行业发展和企业变迁中的作用,同样非常重要。
|
||||
最后一块内容是方法论。“授人以鱼,不如授人以渔”,我想和你聊聊我本人是通过什么方法去了解这个行业的发展和变迁,进而怎样得出这样或那样的结论的。
|
||||
|
||||
|
||||
非常感谢你。写这篇开篇词的时候,我本人正在德国慕尼黑参加数据库领域一年一度的顶级会议VLDB。去年去印度参加VLDB时我的公众号刚开,今年来德国开VLDB则恰逢为专栏写开篇词,事情有时候就是这样的巧合。而此时我正坐在驶离德国慕尼黑的高速列车上,去往奥地利的萨尔茨堡——莫扎特的故乡游玩。
|
||||
|
||||
开卷有益,希望你打开我的专栏时也能够有所收获,这就是对我写专栏最大的安慰了。
|
||||
|
||||
|
||||
|
||||
|
||||
67
专栏/技术与商业案例解读/001西雅图IT公司之RealNetworks:一个帝国的兴衰(上).md
Normal file
67
专栏/技术与商业案例解读/001西雅图IT公司之RealNetworks:一个帝国的兴衰(上).md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
001 西雅图IT公司之RealNetworks:一个帝国的兴衰(上)
|
||||
互联网行业的每一次泡沫,都代表了一场旷日持久的血战。一场战争里,很多公司活下来了,有的甚至还披荆斩棘,发展成了独角兽;但也有很多公司在竞争中倒下了,哪怕它曾经是一个帝国;也有的只剩下苟延残喘,甚至消失在浩浩荡荡的历史发展大潮中。
|
||||
|
||||
我们必须说,互联网行业里时间的流速是传统行业的十倍,所以十年的时间可以让一个企业兴盛,十年的时间也可以让一个企业衰败。甚至于再过十年,一切烟消云散,没有人会再记起。
|
||||
|
||||
但很多时候,如果我们回过头去看历史,命运女神其实并非没有给予过机会,只是在命运降临的伟大瞬间,天才者能够把握机会,而庸碌之人则会葬送帝国。
|
||||
|
||||
比如,曾经连续错失了搜索、社交、移动的微软,在命运女神给予的最后一次机会降临时,以大毅力、大决心全力而进,所以今天在云计算的光辉下活了下来。
|
||||
|
||||
今天我要说的主角,就是一个曾经兴起,最终又倒下的帝国。
|
||||
|
||||
在西雅图派克市场周围一个不起眼的楼宇里面,有一家叫作RealNetworks的公司。这家公司既不起眼,也不知名。很多人一直认为,西雅图知名的企业,特别是知名的IT企业,不是微软就是亚马逊了。今天很少有人还记得这个曾经改变了整个互联网的RealNetworks, 一个曾经在西雅图的名声绝不亚于前面两家,并且和微软战斗过多年的企业,一个本来可以取代今天的苹果,却已然倒下的大帝国。 对于我们中国人来说,如果提起所谓的RM或者RMVB视频格式,我想没有不熟悉的人吧?对,它们就是这家公司的产物。
|
||||
|
||||
RealNetworks创办于1994年,创始人是罗布 · 格拉泽(Rob Glaser)。在创办这家公司之前,格拉泽在微软已经效力了十多年。随着微软的上市和不断拆分,作为微软的早期员工,他已经赚够可以花大半辈子的钱。
|
||||
|
||||
我们常说,衣食无忧之后一个人最想做的事情,除了休息,可能就是实现人生理想了,格拉泽估计也是如此。
|
||||
|
||||
格拉泽当时迫切需要解决一个互联网上的问题:网页怎么可以没有声音和视频呢?
|
||||
|
||||
在互联网内容空前繁荣的今天,我们可能很难想象格拉泽那个时代的互联网,彼时的上网体验是非常恶劣的。一只“猫”拨号56 KB的速度,最多提供7 KB的下载速度,而7 KB还要被这样那样地消耗掉一点,因此留给视频和语音的带宽不是一般得可怜。
|
||||
|
||||
对于很多技术人员来说,那种情况下去做视频、语音的在线服务,无异于异想天开。而且,由于带宽的限制,互联网当时还处在艰难生长的状态,互联网上面的资源非常少。被誉为互联网第一股的雅虎在登录纳斯达克上市的时候,也就雇用一些人,手工编辑整理一下全球互联网的信息就可以了。
|
||||
|
||||
在那样一个全球互联网的资源都可以用人力服务的年代,实现视频和语音的在线传播,真的是一个非常超前的想法。然而,格拉泽决定做这样一件事情。而且不单是有想法,他还有了技术解决方案。
|
||||
|
||||
在那个时代背景下来看,这无疑是非常值得敬佩的一个人。当然我们还有一句话,到底是“风口上的猪”,还是真英雄,只有等风平浪静以后才见分晓。可格拉泽至少看起来像一位英雄。
|
||||
|
||||
RealNetworks凭借格拉泽的技术实现了在56 KB拨号的前提下,对音频和视频的在线播放。音频是首先实现的,然后是视频。当然,在那样的网络条件下,用户肯定无法体验到今天的大屏幕、高保真的画面和音质,他们能够看到的只是画面失真、音质一般的在线直播。
|
||||
|
||||
然而即便如此,这依然是一个非常了不起的成就。如果这件事情很容易做,为什么各大公司都没有办法提供类似的技术来实现呢?
|
||||
|
||||
RealNetworks公司早期非常成功,虽然它的技术在今天看来其实并不新鲜,但当时绝对是具有划时代意义的。它做到了以往其他公司都做不到的成就。
|
||||
|
||||
其技术上主要是两个方面比较独到:其一是压缩算法很强,虽然失真得厉害,但是压缩以后比其他格式小很多,这就为互联网传播,尤其是速度很慢的第一代互联网传播图像和音频提供了基础;其二是它第一次在互联网媒体播放上引入了流媒体的概念,RealNetworks的技术可以做到一边下载一边播放。
|
||||
|
||||
我们今天去看,这个流媒体的思想已经遍地开花了,但那时却绝对是创新性的一项技术。在这两项技术的基础上,RealNetworks还有一点特别厉害,它可以根据网络带宽的好坏,来动态地调整传输的视频、声音的质量。当网络带宽好的时候,用户就可以看到更清晰的视频,网络带宽不好的时候,那就只能将就了。这种自适应能力,在当时互联网发展早期是非常有利的,也是在很长一段时间里独此一家的技术。
|
||||
|
||||
RealNetworks凭借着他们精湛的技术,在1995年的时候就通过音频转播了西雅图水手和纽约洋基棒球队的比赛,这场比赛为这家公司赢得了巨大的声誉。在这之后,它又第一次在互联网上转播了NBA的视频比赛。我想这可能为格拉泽后来进入视频订阅打下了基础。NBA比赛的转播在当时非常轰动,其效应对于互联网的发展演进起到了巨大的推动作用。
|
||||
|
||||
在RealNetworks成立的前几年,这家公司的技术发展非常迅猛,之后这家公司迅速上市。然后,股票“飞”起来了,从1998年登陆纳斯达克以后到2000年大概涨了近40倍。2000年顶峰的时候,其市值超过现在Twitter的市值,这还没有算上通货膨胀的影响。
|
||||
|
||||
在当年来看,RealNetworks当然还比不上当时微软、英特尔、思科那么庞大,但却已经是一个不折不扣的大鳄了。据统计,在2000年的时候,整个美国互联网上有关视频直播的内容超过85%使用了RM格式。
|
||||
|
||||
然而,这是RealNetworks确立统治地位的一年,也是RealNetworks由胜转衰的一年,格拉泽从此以后再也没有见过这么高的股票了。
|
||||
|
||||
在RealNetworks如火如荼般开展业务的时候,格拉泽的老东家开始眼馋了。
|
||||
|
||||
有钱的地方大家谁都想要来插一脚,微软也不能免俗,于是转即杀入了媒体这一行,推出了后来著名的Windows Media Player。微软的手段在这场战争里也表现得淋漓尽致,如同对待网景公司一般,再次采用了一贯的免费加捆绑策略。
|
||||
|
||||
Windows Media Player推出来就是免费的,而RealNetworks最新的播放器则需要40美元来购买;微软的流媒体服务器也是免费的,而流媒体服务器在RealNetworks却是当时最重要的赢利点。当时市面上除了RealNetworks,就是微软的Windows Media Player和苹果的QuickTime,但是这两个竞品的策略都是免费。这大致就是当时的市场状态了,一个优秀但收费的产品,外加两个不算优秀却免费的竞品。
|
||||
|
||||
要是不出意外,就如同微软IE对网景公司的战争一样,前者靠着免费策略击垮了后者,然后占据了主流的位置,从此以后就可以横行天下开始收费。
|
||||
|
||||
这无疑是微软希望看到的,但不是RealNetworks想要面对的。
|
||||
|
||||
诚然,微软当时有司法部的压力是没错,只是那个时候的比尔 · 盖茨做生意也是相当得“野蛮”,似乎显得不给别人留活路。微软来势汹汹,格拉泽和RealNetworks也必须面对,这场战争的胜负对双方来说都非常重要。
|
||||
|
||||
当然,现在你我已经知道了结果,但可以换个角度想一下,如果你是那个时候的格拉泽,你会怎么应对呢?欢迎在评论区留言与我讨论。
|
||||
|
||||
|
||||
|
||||
|
||||
51
专栏/技术与商业案例解读/002西雅图IT公司之RealNetworks:一个帝国的兴衰(下).md
Normal file
51
专栏/技术与商业案例解读/002西雅图IT公司之RealNetworks:一个帝国的兴衰(下).md
Normal file
@@ -0,0 +1,51 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
002 西雅图IT公司之RealNetworks:一个帝国的兴衰(下)
|
||||
上回聊到微软决定进军RealNetworks的市场,像之前痛击网景浏览器那样,通过免费加捆绑的方式对攻RealNetworks。文章末尾,我给你留了个问题。我虽然不知道你是怎么想的,但我相信你的想法一定很精彩。而格拉泽和RealNetworks面对这场战争,又是如何应对的呢?
|
||||
|
||||
格拉泽的处境和当年网景公司有几分相似,而他也深知微软的强大。如果和微软正面冲突,面对财大气粗的竞争者,最后的结果只有一个,这一点在网景公司上已经呈现过一次,格拉泽肯定不希望自己和公司最后面临同样的下场。不过,大概因为格拉泽自己就是从微软走出来的,所以对于比尔 · 盖茨接下来会有怎样的套路很清楚。此外,格拉泽更深知自己的优势,以及微软不擅长的东西到底是什么。
|
||||
|
||||
格拉泽的应对主要体现在两个方面。首先,他和PC制造商合作预装了RealPlayer,这种预先安装的播放器是免费的,这样就在很大程度上抵消了Windows的捆绑。当然,为此公司也牺牲了一部分的收入,不过这也是没办法的事:收费对免费,在哪个国家都会失败。其次,他开始多元化的扩张。
|
||||
|
||||
格拉泽很清楚微软做软件很厉害,但是软件以外的东西就不一定了。因此,在做播放器的同时,RealNetworks公司也开始转身成为内容服务商。RealNetworks给用户提供按月付费的歌曲播放和视频点播订阅服务。可以说今天大行其道的月租模式,是RealNetworks在应对微软的进攻时就想到的。
|
||||
|
||||
RealNetworks就这样,成为了美国最早通过订阅服务向互联网用户收费的公司。与此同时,流媒体服务器的收入在下降,媒体订阅的收入却在上升。更重要的是,公司也开始做广告了,其形式有点类似于现在YouTube插播的广告。然而广告效果一般,这大概是公司做广告的时候用力过猛,大量的打广告,影响了用户体验。另外,大量的广告又导致播放器反应迟缓,经常出现卡顿等现象。这都说明RealNetworks进军广告市场的转型太过于激进了。但是不管怎么样,由于RealNetworks很早就开始进入订阅服务,因此它在播放器市场节节败退的情况下,在音频和视频服务市场上守住了战场,这让它安然度过了2000年网络泡沫以后艰难的几年。从这个角度看,格拉泽对于微软的套路和微软的软肋理解得极为深刻。
|
||||
|
||||
扛住了微软进攻的RealNetworks马上要迎来一次更大的机遇和挑战,然而很遗憾,这一次格拉泽却没能抓住机遇。如果说格拉泽对微软的理解是深刻的,他对媒体发展大势的认识则是浅薄的。所以他和他的公司即将错失一次壮大的机会,未能避免从此一蹶不振的局势。
|
||||
|
||||
命运女神让格拉泽手下一个叫托尼 · 法戴尔(Tony Fadell)的人敲开了格拉泽的大门,故事便从这里开始。现在,你知道法戴尔这个人非常有名,其中最有名的两个称号,一个是“iPod之父”,一个是Nest的创始人。而那时,订阅逐渐成为RealNetworks公司的盈利重点,并且帮助公司扛住了微软的进攻,法戴尔有了一个脑洞大开的想法:做一个硬件,它可以播放音乐,而且比市面上的MP3播放器容量都要大很多很多。这个播放器然后可以和RealNetworks的订阅服务结合起来,一定会大放异彩。
|
||||
|
||||
然而很遗憾,格拉泽这个时候犯了一个致命的错误——拒绝了这个年轻人。于是法戴尔决定辞职,去寻求其他的支持。他辗转反侧地找来找去,最后终于找到了当时在垂死挣扎中寻找生机的苹果公司。
|
||||
|
||||
苹果公司在1998年的时候股票跌到了1美元一股。创始人史蒂夫 · 乔布斯回到苹果做的第一件事情,就是去比尔 · 盖茨那边化缘。他和对方要了不少钱,卖了不少苹果股票。江湖传闻,比尔 · 盖茨投资苹果是因为:如果苹果破产,那么微软的视窗系统垄断就成真,微软就会立刻面临司法部的反垄断起诉。
|
||||
|
||||
咱们回过头来接着说。法戴尔找上门时,事情进展也远不能说顺利。那时,苹果公司基本上还没做过消费者市场,而且公司处于缺钱的境地,乔布斯从理智的角度思考后,并不看好这款产品。但无论如何,这位苹果的创始人最后还是说了yes,雇用了法戴尔作为临时合同工一年,而正是在此期间,他们研发出了著名的iPod。
|
||||
|
||||
接下来,iPod推出,然后很快就获得了巨大的成功。此时,苹果选择了和内容商一起推出订阅服务,当然它没有选择当时订阅领域的老大——RealNetworks。而至于为什么没有选择RealNetworks,相信你现在很容易理解了。接下来,凭借乔布斯在媒体领域的巨大影响力(顺便说一句,他还是迪士尼的大股东哦),苹果公司搞定了各大唱片公司,又推出了为它带来滚滚红利的iTunes。
|
||||
|
||||
从此以后,整个唱片界的革命来了,而RealNetworks再也没有办法阻挡苹果的洪流。iTunes给苹果带来滚滚红利的时候,也大量地分流了RealNetworks的订阅量。格拉泽这个时候开始着急了,他决定放手一搏,推出了叫作Harmony的技术,可以让自己的合法音频在iPod上播放。这个技术本质上来讲就是黑进了iPod的版权系统,给RealNetworks卖的正版音乐套上一个iPod能理解的头儿,伪装成iTunes上面购买的东西。从技术角度上讲,这算得上是“伪正版”,游走于灰色地带。然而,这种做法并没有给公司带来起色,相反却引来了官司。
|
||||
|
||||
在失去播放器市场和订阅服务之后,RealNetworks的日子显得更加艰难了。这个时候留给他们的最后的盈利点,无非是授权给各大公司的对RM和RMVB格式的解码技术。这项技术卖给了很多公司,包括高通的ARM芯片也支持对RM和RMVB进行硬解压。这就是国内的很多手机都支持硬解压RMVB格式的原因。
|
||||
|
||||
而在2012年的时候,公司把自己的多项专利技术打包卖给了英特尔,同时它授权的最大客户高通,在2012年也决定停止继续授权付费。而在中国,2012年的时候小米手机也突然不支持解压RMVB了,当时还闹出了很多问题,其主要原因是那个时候互联网已经不再是RMVB格式的天下,而高通不再愿意花钱了。总而言之,通过专利授权赚钱的这条路,在2012年以后也随着专利的卖出不复存在了。RealNetworks的日子显得异常艰难,股票价格也一跌再跌。
|
||||
|
||||
RealNetworks后来又尝试了若干次创新创业重启,然而世易时移,这世界已经不是当初的那个世界了。RealNetworks裁员又裁员,到后来在中国市场的招聘居然是只招合同工了。现在的RealNetworks在西雅图的办公室也越发得不起眼,新来西雅图的人大概已经不记得,西雅图曾经有一家占据互联网视频流媒体服务85%以上的伟大公司了。
|
||||
|
||||
而话又说回来,RealNetworks其实还有另外一个机会,他们可以做一个YouTube或者买下YouTube。在那个时候作为订阅领域的老大,他们有钱有实力。然而不管因为什么样的原因,格拉泽始终没有抓住机会。后来,他接受采访的时候总是语焉不详的。我想格拉泽是聪明人,知道自己犯了错误,又接连犯了错误。然而,这世上终究是没有后悔药的。
|
||||
|
||||
回过头去看,RealNetworks的领导人在互联网初期无疑是极具远见的,RealNetworks也的的确确改变了互联网的历史,创造性地引入了流媒体的概念。该公司因为是微软的资深员工创建的,对于微软可能的进攻很清楚,也非常清楚地知道微软不擅长什么,所以从播放器到内容订阅的转型,依然是非常正确而有远见的做法。不单如此,上天还给予了RealNetworks一个得天独厚的机会,iPod的原型是RealNetworks的一个员工想出来的。更甚者,当时RealNetworks具有领先世界的技术和内容服务,和远超苹果的现金流。假想下,如果iPod当时是被RealNetworks推出的话,西雅图的这家企业今天将会站在什么样的高度?
|
||||
|
||||
而退一万步讲,RealNetworks已经知道插播广告了,如果它们推出了类似于YouTube的视频网站,也同样具有得天独厚的优势。然而没有然而了。在RealNetworks错过了这场最重要的转型战争,而且是在各方面都有利的情况下错过了这场战争之后,它的衰退就是没办法的事情了。现在想来,IT行业无疑是非常可怕的,一家伟大的公司因为错失了几次机会,就无可避免地衰退了。更重要的是,衰退后,很快就没有人再记得了。这无疑是个悲哀。
|
||||
|
||||
一家IT企业可以一时领先,但是IT行业的风险如此之大,每家公司都是步履维艰,如果一步走错了,也许便不会再有第二次机会。回头看微软最近的转型,从搜索到社交再到移动,一步错步步错,值得庆幸的是,终于在云计算这一把上走对了。如果云计算也走错了,那么微软估计也会面临衰败的风险。
|
||||
|
||||
RealNetworks最初的发展战略毫无问题,对于自己老东家的进攻策略和软肋理解得也非常深刻。然而,在最关键的时候,它错失了iPod,我们应该说是上天眷恋苹果呢,还是乔布斯确实就是神一样的存在,看到了格拉泽所不能看到的未来呢?
|
||||
|
||||
必须相信的是,RealNetworks绝非一家小公司,其创始人格拉泽也绝对不是一个毫无远见的人。但是,我们依然看到了一个市值不到往日1%的残存的公司,缩在西雅图派克市场周围某栋楼的某一层里。看到这个结果,我的心里拔凉拔凉的。往者不可谏,来者犹可追,谁又敢说自己必然能够抓住未来的机会呢。在具备各种强烈优势背景的情况下,RealNetworks却一一败退,并沦落到如今籍籍无名的地步,你觉得是战略、创始人的眼界问题,还是大势已去呢?
|
||||
|
||||
|
||||
|
||||
|
||||
65
专栏/技术与商业案例解读/003以RealNetworks为例,谈谈初创公司如何应对巨头碾压.md
Normal file
65
专栏/技术与商业案例解读/003以RealNetworks为例,谈谈初创公司如何应对巨头碾压.md
Normal file
@@ -0,0 +1,65 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
003 以RealNetworks为例,谈谈初创公司如何应对巨头碾压
|
||||
前面说到微软推出Windows Media Player,利用一贯的免费加捆绑策略杀入媒体领域,开始抢占RealNetworks的市场。与此同时,苹果的QuickTime也同样采用了免费的竞争策略。而你是否已经站在当初格拉泽的角度,考虑了自己的应对策略呢?
|
||||
|
||||
今天,我就先来和你说一说RealNetworks公司在产品或市场遭遇商业巨鳄挤占或阻击时,所采取的应对举措。
|
||||
|
||||
RealNetworks遇到了大多数创业公司都会遇到的一个非常典型的问题:产品做得好,却被大鳄盯上了。大鳄来势汹汹,初创公司应该怎么办?这个问题没有固定的答案,有些对策在一个案例里面成功了,但在另外一个案例里面却可能失败。
|
||||
|
||||
对于各种事件,我们很容易“事后诸葛”地进行分析,但只有当事人才能在那个局面里做出决定。我从未经历过这样的时刻,因此也只能“事后诸葛”一回。
|
||||
|
||||
一家公司是否具备了应对商业巨鳄挤占或者阻击的资格,首先取决于这家公司的产品有没有不可替代性。如果这家公司的产品没有不可替代性,那么面对商业巨鳄,特别是当这家巨鳄本身能从自己的其他业务赚钱,补贴给替代产品,不需要通过替代产品盈利时,在烧钱这件事上,初创公司是不可能烧得过商业巨鳄的。
|
||||
|
||||
以RealNetworks为例,其产品在技术上比微软或者苹果的同类产品要好,但是这种好对于大部分用户来说,并非是不可替代的。如果竞争对手使用低价乃至免费倾销的策略,用户很多时候愿意免费使用体验相对次一些的产品。这在RealNetworks的经历中就有体现:面对需要付费的服务器,用户更愿意尝试质量虽然差一些,但却免费的服务器。
|
||||
|
||||
换一个例子来看,当谷歌大举进军社交领域的时候,Facebook一开始是非常紧张的。然而,谷歌在社交领域的攻城略地却显得非常失败。
|
||||
|
||||
实际上,这很容易理解:一个人的好友如果都在Facebook上了,再让这个人迁移出即有的社交圈,转而使用另外一个社交软件,其代价是巨大的,此事甚至是不切实际的。所以,在Facebook巩固了很多著名的高校社交圈之后,它就在很多人那里成为了一个不可替代的平台。和竞争对手比起来,这种优势是一家公司得以生存和发展的关键。
|
||||
|
||||
如果说,初创公司意识到了自己的核心产品并没有具备不可替代的特性,那么面对商业巨鳄的阻击,又应该怎么办呢?
|
||||
|
||||
RealNetworks采取了一系列的应对措施,概括来说就是:在自己比对方更擅长的相关领域开展业务,扩展战线。
|
||||
|
||||
RealNetworks的创始人自己就来自微软,他深知一旦微软盯上了一款软件并推出免费产品,正面反击会异常艰难。自身软件的特性固然比对方的要好,但绝没好到不可替代的程度。所以RealNetworks选择以播放器作为切入点,成为内容服务商。
|
||||
|
||||
RealNetworks认为,和自己比起来,微软作为传统软件大厂商,在做内容和服务这一块更加没有经验。所以一场战争如果延续到了相关的领域,而在相关领域里自己比大鳄更加得有优势,那么凭借软件开辟出来的先发优势,就有可能让自己站稳脚跟。
|
||||
|
||||
实际上,我想从一开始创业,到后来微软跳出来的种种变局,所有的策略,格拉泽在创立公司伊始应该就想过无数遍。这是他成功的关键。
|
||||
|
||||
我们还可以看到另外一种选择:面对大鳄的袭击,抱上另外一个大腿也不错。大腿和大鳄有竞争关系,但却往往对初创公司的产业或者产品兴趣不大。只是,有大腿可以抱,本身就不容易。很多时候,初创公司找不到合适的大腿去抱;更何况,即便初创公司能找到合适的大腿,大腿还得看得上自己。两者加起来,能够抱上大腿的初创公司终究是少数。所以这也只能说是一种运气。
|
||||
|
||||
然而在第二篇文章中,我们却也看到了令人唏嘘不已的事情:具备各种强烈优势背景的RealNetworks开始一一败退,并沦落到如今籍籍无名的地步。文末,我同样给你抛出了一个问题:你觉得这是战略、创始人的眼界问题,还是公司大势已去?相信你的思考一定很精彩。
|
||||
|
||||
为什么RealNetworks没能抓住时代的变革,反而成全了苹果?这个故事告诉我们一个道理,站在行业变革的前夜,唯有伟人才能够比别人看得更远。史蒂夫 · 乔布斯去世的时候,各大互联网公司都在自己的首页向这位伟人致敬。我想,这种崇敬是发自内心的,因为大家看到了一个可以比他人更早几年看到行业变迁的伟人。可惜,不是每个人都是乔布斯。你我不是,格拉泽也不是。
|
||||
|
||||
RealNetworks其实算得上是一步错步步错。格拉泽在技术上当然是有几把刷子的,他在出来创业前,也想明白了要面对的对手多半是自己的老东家微软。因为在老东家工作多年,所以估计也想明白了比尔 · 盖茨的套路,知道怎么去应对才能让自己的公司发展下去。
|
||||
|
||||
然而我们也必须说,作为一个很不错的创业者,格拉泽应该不具备比尔 · 盖茨对于PC软件的认识,或者乔布斯对于消费电子的认识。因此当一个全新的东西出来时,他就迷茫了。那个大硬盘播放器的东西,就让格拉泽迷茫了。
|
||||
|
||||
其实不仅仅是格拉泽迷茫了,当iPhone出来的时候,微软CEO鲍尔默看着这个没有按键的手机,也迷茫了,觉得这是个手机吗?
|
||||
|
||||
鲍尔默曾经很有信心赢得智能手机这场战争,投入巨资做Windows Phone,不惜购买诺基亚。然而不出几年,所谓的Windows Phone终究是被市场淘汰,最后被微软的新CEO萨提亚放弃了。我们是不是就此可以责怪鲍尔默呢?其实,鲍尔默做企业级软件的能力和实力,是得到业界公认的。但是这次他没看明白iPhone的影响力,在面对这样一次巨大的变革时,没能做出正确的判断。
|
||||
|
||||
所以在我看来,iPod的这个变革和变革后面的影响确实非常大。RealNetworks在成为媒体大亨之后没多久,就要面对iPod这种革命性产品的变革,格拉泽真的是运气不太好。那个时间点,若换作张三李四王五,乃至比尔 · 盖茨,是不是就会做得比格拉泽更好呢?我看也不一定。
|
||||
|
||||
所以iPod的原型机诞生在RealNetworks,而格拉泽却拒绝了这个创意,既在意料之外,也在情理之中。我想,我们不应该单就这个东西质疑格拉泽太多。所谓时也运也,大致也就是这个道理。
|
||||
|
||||
抛开iPod被格拉泽拱手相让这个事实不说,进一步思考RealNetworks的发展,你会发现更加有意思的地方。YouTube这样的免费视频分享网站,并没有在RealNetworks这个当时的媒体大鳄下面诞生或壮大,而这个媒体大鳄在那个时候却进入广告市场,并采取了非常激进的广告投放策略,哪怕影响用户体验也在所不惜。
|
||||
|
||||
后面两件事情放在一起,首先说明RealNetworks在那个时候是有盈利压力的。盈利压力一方面缘于它本身是上市公司,所以需要给投资者看到自己赚钱的能力,一方面我想也和互联网泡沫破灭以后的大环境相关。这个大环境下,免费的东西不被投资人看好。因此,这对已经上市的公司,尤其是面临盈利压力的上市公司就形成了阻力。
|
||||
|
||||
但是不管怎样,这方面我觉得格拉泽做得和亚马逊的总裁贝佐斯比起来要差得多。贝佐斯在他的领导力准则里面强调,公司的领导人应该旨在实现长远的目标,而不应该屈从于短期的利益。一家为了盈利而非常激进地投放广告,不顾用户体验的公司,怎么可能去支持一个短期内没有盈利希望的、类似于YouTube这样的视频分享网站呢?
|
||||
|
||||
从这一点我们可以看出,作为创业者的格拉泽,在技术上有其独到的地方,在商业上,也对微软的介入做了充分准备。但是,他毕竟不是一个目光长远的伟人,无法在短期盈利和长期发展之间找到合适的平衡点。如果你承认了格拉泽在这方面的缺陷,也就可以理解为什么类似YouTube的视频分享网站无法从媒体公司RealNetworks里诞生了。
|
||||
|
||||
而当iPod开始逐渐侵占RealNetworks的基本盘时,格拉泽选择游走于灰色地带,并让自家的媒体登上iPod的做法,那就不仅仅是眼光的问题了。格拉泽明显是顶不住压力才出此险招。而此险招是否曾在内部遭遇抵制已不得而知,但其终归是被RealNetworks整个高管团队通过,并最终实施。
|
||||
|
||||
更重要的是,RealNetworks当时居然没有意识到iPod的胜利其实就是一个平台的胜利。而战胜平台,唯一的办法就是建设自己的平台。RealNetworks已经有了足够多的内容,建设自己的平台肯定比让自己的内容以不怎么合法的方式进入别人的平台来得更有效也更安全。我实在是无法理解格拉泽为什么选择了这样的一个应对方式。我只能说,一个人的英明是有限的。格拉泽也不能免俗。
|
||||
|
||||
|
||||
|
||||
|
||||
73
专栏/技术与商业案例解读/004可视化分析鼻祖Tableau.md
Normal file
73
专栏/技术与商业案例解读/004可视化分析鼻祖Tableau.md
Normal file
@@ -0,0 +1,73 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
004 可视化分析鼻祖Tableau
|
||||
Tableau公司成立于2003年,总部位于西雅图,是全球领先的可视化分析软件的创建者,于2013年在纽约交易所上市。Tableau是这个领域的奠基人,并且在这个领域至今依然保持着全球最领先的研发态势。
|
||||
|
||||
在数据变得越来越重要的时代,不管是具备精湛数据分析技能的从业人员,还是对数据分析一无所知的小白群体,可视化分析都被证明是一种非常行之有效的手段,并对各行各业都发挥着非常重要的作用。
|
||||
|
||||
2003年,刚从斯坦福博士毕业的克里斯 · 斯托特(Chris Stolte)正值风华正茂的年纪,这之前的6年博士生涯,他一直在研究数据的可视化分析。
|
||||
|
||||
斯托特师从帕特 · 汉拉汉(Pat Hanrahan)。而汉拉汉是世界著名的计算机图形学研究专家,在正式成为教授之前,是史蒂夫 · 乔布斯的3D动画制作公司皮克斯的早期员工,并在这家公司工作了3年(1986~1989年)。1989年,汉拉汉作为计算机图形学的教授加入普林斯顿大学,之后又在1995年转到了斯坦福大学。
|
||||
|
||||
作为一个在计算机图形学方面卓有建树的学者,他敏锐地察觉到了数据可视化的前景,并认为将数据可视化用于辅助人进行数据分析这个研究方向,必会在未来产生巨大的影响。而当斯托特成为他的学生时,这也就顺理成章地成为了斯托特未来多年的研究方向。
|
||||
|
||||
“花开两朵,各表一枝。”你可能知道,Tableau这家公司有三个创始人,其中两个已经登场,分别是后来的首席开发官斯托特以及他的导师——首席科学家汉拉汉,接下来该第三个创始人出场了,他就是公司CEO克里斯蒂安 · 夏伯特(Christian Chabot)。
|
||||
|
||||
夏伯特先是在斯坦福这个校园里工作了几年,之后决定和他的本科校友兼老婆在斯坦福读硕士,然后他读了MBA,老婆则读了法学院。这一读就到了2000年,该毕业了。
|
||||
|
||||
众所周知,2000年的时候美国发生了一次经济危机,当时互联网泡沫破灭,硅谷遍地惨淡之气。作为斯坦福MBA在这个点儿毕业,确实不是好时机。现在回想,我2009年毕业时的境遇,与此颇为相似。
|
||||
|
||||
然而大家都是需要工作的,没有工作肯定是没办法活的。斯坦福MBA的胆量和我们比起来,肯定是大不一样:这个时候,夏伯特决定自己开公司了。
|
||||
|
||||
他找到的合伙人正是斯托特和斯坦福的另外一个教授玛尼什 · 阿格拉瓦拉(Maneesh Agrawala)。没有人知道当初这几个人是怎样因缘际会走到一起的,也没有人知道为什么这家公司的合伙人教授是另外一个搞计算机图形学的大牛,而不是后来斯托特的导师汉拉汉。
|
||||
|
||||
但无论如何,公司开起来了,工作也有了。夏伯特在经济危机以后毕业求职不果,决定自己干的励志故事也就这样诞生了。
|
||||
|
||||
更加有意思的是,夏伯特在若干年后的一次采访里面说,他们当初开这家公司设定的目标,就是把公司的技术做到一定规模,然后再把这家公司卖掉。
|
||||
|
||||
这个买卖很成功,很快他们就拿到了美国在线和另外一个做地图数据的公司Vicinity的收购邀约。他们选择了后者,大概是因为钱比较多一些,而后者之后又被微软收购,那就是另一个故事了。
|
||||
|
||||
我不知道是不是因为这次创业的成功,让夏伯特对下一次创业充满了期待。有关怎样使用数据可视化去帮助人们顺利地推进分析研究项目,斯托特和他的教授发表了一些论文,并且把做的东西整合进了一个叫作Polaris的系统。作为拿到基金资助的项目的一部分,这个系统本身是公开提供给大家使用的。
|
||||
|
||||
关于为什么会萌发出创业的想法,已经不可考了。当时斯托特,加上他的导师,以及曾经和他一起创业的夏伯特,三个人决定基于Polaris这个系统进行商用化开发,并创建一家新的公司。这家公司就是现在鼎鼎大名的Tableau。
|
||||
|
||||
Tableau在2003年1月创建于加州的山景城。大约10个月以后,公司的创始人们决定把公司总部从硅谷搬迁到西雅图。至于这背后的原因,后来有人问过他们,而创始人的回答是:这个地方更适合创业。
|
||||
|
||||
我们今天估计很难理解为什么。但是如果你知道当初微软在西雅图最为鼎盛的时候,其一家公司的市值,就超过硅谷很多大公司的市值总和的时候,就多少能理解一二了:在那个年代里,西雅图在引领IT业的发展。当然,现在看来这种引领其实也是盛极而衰的最后辉煌阶段。
|
||||
|
||||
而很有意思的是,Tableau这个软件,从斯托特开发第一个版本的时候,就构建在微软的开发环境下,地地道道是一个Windows平台上的软件。这一状态持续了很久,大约是直到Tableau上市一年以后,2014年的夏天,Tableau 8.2版本才开始正式支持Mac。而Tableau对于Linux的支持,直至今天公司依然在努力,但是还没有正式的版本出来。
|
||||
|
||||
此外,从公司的氛围上来讲,Tableau也是一家非常微软化的公司。我作为一个微软开发人员,进到这家公司来,基本上没有任何学习的难度,第一天就可以顺利地进行开发。Tableau公司所使用的工具,和微软内部的开发工具相差无几。我想这一方面与项目最初诞生的时候,就全面使用了微软的工具有关,一方面也表明了微软这个软件帝国对本地生态圈的巨大影响。
|
||||
|
||||
Tableau的发展,从技术角度上来讲,有几个非常重要的关键点。
|
||||
|
||||
首先是Tableau 1.0的成功发布。Tableau 1.0是从Polaris到一个成熟可用的商业软件的变迁。斯托特后来在回忆的时候说,他没有预想到需要一年的时间去修修补补,把很多的细节部分做好:一个商业软件和一个学校里面的科研软件差别是巨大的。然而,Tableau 1.0虽然在可视化分析方面已经表现得非常优秀,但是对各种数据源的支持、对各种计算函数的支持等其他方面,却不尽如人意。当然,1.0版本也从未卖出过多少钱。
|
||||
|
||||
严格意义上讲,两年以后发布的Tableau 2.0,才是Tableau历史上第一个真正可以商用的软件。而2.0的时候,Tableau也终于开始接到可观的订单。除去早期招到的几个能力很强的开发人员以外,销售队伍也开始建立起来。法律相关的人员也慢慢就位了。
|
||||
|
||||
2007年的Tableau 3.0是具有里程碑意义的一次发布。这次Tableau增加了一个产品——Tableau服务器。这个服务器尽管当初很简陋,但却使一个企业里面协同进行数据分析和共享数据分析的结果成为了可能。Tableau服务器的盈利能力很快就超过了Tableau本身。
|
||||
|
||||
Tableau的下一个里程碑式的发布,是三年后的Tableau 6.0,其中引入了后来称为Tableau数据引擎的新组件。这个组件实际上是Tableau自己开发的一个列式数据处理引擎,专门针对Tableau自己的应用优化过。这个引擎的到来让Tableau在数据处理能力上,终于迈上了一个新台阶。
|
||||
|
||||
从此以后,Tableau除了可以直连到各种数据源以外,还可以对数据源取一个镜像,把数据导进Tableau数据引擎里面,在本地进行分析,这大大加快了分析的速度。
|
||||
|
||||
更重要的是,因为这个引擎的引入,使得Tableau对非关系型数据库的支持都成为了可能,比如说对文本文件的支持,对Excel电子表格的支持,以及后来对PDF文件的支持等。只要Tableau可以把这些数据通过数据清理导进引擎,就可以进行有效地分析。数据引擎对Tableau的发展可谓至关重要。
|
||||
|
||||
Tableau此后的各个版本主要是围绕数据引擎的各种提高,以及对各种企业级应用的支持来提升。一直到上市以前,Tableau都没有再引入任何关键性的功能。下一次关键性功能的引入,便是2014年6月份对Mac的支持了。
|
||||
|
||||
Tableau于2013年正式在纽约交易所交易,股票代码为DATA。这个名字取得非常好,因为DATA既好记,又反映了公司最主要的服务市场。上市以后,Tableau开始了在各个领域的全面扩张,从云到ETL,从企业级服务到数据引擎,这种扩张使Tableau的开发人员迅速从不到200个扩充到了近1000个。
|
||||
|
||||
与此同时,因为外界的看好、股市的飙升,竞争对手,尤其是大鳄们,终于开始把眼光转向了这个市场。结果就是微软举着PowerBI的大旗大举进军这个市场,以其低廉的价格和大量的开发人员投入,迅速推出新版本。这无疑对Tableau造成了致命的打击,其股价在2016年初的财报后,一天之内发生“腰斩”。
|
||||
|
||||
这是Tableau迅猛发展史上一次巨大的打击。之后公司采取了很多应对措施,其中最为重要的是CEO和其他创始人退出,并从亚马逊的AWS请来了新的CEO亚当 · 塞利普斯凯(Adam Selipsky)。在新CEO的带领下,经过近一年的努力,销售和研发终于都稳定下来,股价也渐渐回升到了“腰斩”前的状态。
|
||||
|
||||
今天我带你回顾了Tableau这家公司的整个发展历史。在Tableau的发展历程中,有一些值得你我去深思的问题。我们都知道,要想在今天竞争激烈的环境下创业,一个好的想法很重要。而在学术圈里面的人,很多时候不缺有趣的想法,很多时候甚至以研究系统的形式得以实现。
|
||||
|
||||
然而斯托特自己也说过,他并没有想到需要那么久的时间,去填补一个研究系统和一个商业软件之间的差距。那么学术界研究项目的商业化,到底会遇到哪些拦路虎呢?学术界出身的人,和工业界出来的人走创业这条路,其优势和劣势到底在哪里呢?
|
||||
|
||||
|
||||
|
||||
|
||||
51
专栏/技术与商业案例解读/005从Tableau上市,看学术界和工业界人士创业.md
Normal file
51
专栏/技术与商业案例解读/005从Tableau上市,看学术界和工业界人士创业.md
Normal file
@@ -0,0 +1,51 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
005 从Tableau上市,看学术界和工业界人士创业
|
||||
上一次,我说到了Tableau的创业和发展史,它是一个非常典型的学术界人士出来创业并且成功的例子。这之前我们还看到了RealNetworks的故事,这是一个创始人在微软工作很多年之后,决定出来创业的例子。当然,后面我还会给你讲述许许多多这样的例子。
|
||||
|
||||
Tableau和RealNetworks的例子恰好可以代表现实中的两类创业者,他们在创业方式和模式上其实都有所不同,他们擅长和不擅长的地方也各不相同。那么,这两类创业者具体有何异同,分别又有什么优势和劣势呢?今天,我就和你聊聊这个话题。
|
||||
|
||||
在学术界发展的人,无论是PhD还是教授,都有一个明显的特征:他们做的项目,从技术层面上来讲,往往都是某个特定领域里面最新最前沿的技术。而且,他们很可能凭借在学术前沿的多年研究经验,开拓一个新的领域。因此,学术界的创业者,很多时候开创的都是高精尖,或者非常独特的技术领域。
|
||||
|
||||
我们其实可以列举很多这样的例子,无论是谷歌的搜索、Tableau的计算机可视化,还是当下很热的AI创业者,其显著的特点就是技术专家创业。而且很多时候,这些人是技术领域真正的弄潮儿。
|
||||
|
||||
以Tableau为例,Tableau的几个创始人在开创这家公司之前,已经是人机交互和计算机图形学领域的世界级专家。站在世界之巅的人,看世界的角度也就有所不同。所以这些人把计算机图形学、人机交互的技术,和数据的显示与分析结合起来,提出了数据可视化分析的概念。这个概念落地以后,才有了今天Tableau占据的这个新市场。因为这个新市场的出现,传统的BI领域在很大程度上被颠覆了。
|
||||
|
||||
而工业界出来的人,在创业模式上就完全不一样了。我们不排除工业界里面也有许多这样的人,他们数十年如一日地工作于一个领域,成为这个领域的专家。但是即便如此,这种专家依然和学术界的专家有所区别。
|
||||
|
||||
工业界的专家往往精通特定的技术,并且技术极为精湛,能实现一些一般人不能实现的东西,比如RealNetworks的创始人对视频语音编码解码的理解。
|
||||
|
||||
然而,工业界的牛人一般不会对超前好几年的技术,或者现在不能立刻产生实际价值的东西,有非常深刻的理解。
|
||||
|
||||
当然也有例外,大公司比如早年的IBM、王安,近来的微软、雅虎都成立了研究院,在研究院里面的人,做的是和学术界差不多的事情。这些人不需要直接对产品负责,做的也是超前的东西。这些人其实更应该归于学术界,而不是工业界。撇开他们不说,工业界的人在技术上创业,一般不太能见到改变时代的超前的东西。
|
||||
|
||||
但是,工业界的人对于商业模式的理解,往往比学术界的人要强很多。所以工业界的人创业,技术不一定是最新的,但更容易将新的商业模式和技术相结合。这种创业模式,在学术界人士的创业项目里几乎见不到。比如,我们从未听说过,一个学术界出来的人创建了一个旅游公司、房地产公司之类的事情。但是,出身于工业界的人更容易走这条路。这算得上一个巨大的差别。
|
||||
|
||||
工业界和学术界出来的人还有一个很不一样的地方。学术界的人典型特点是眼高手低,他们的眼光非常得高。但是其工程实践能力,和在工业界里耕耘很久的人比起来,就会差很多。
|
||||
|
||||
这种差距首先体现在代码的质量上:一个代码是否足够模块化、有没有足够多的测试、BUG数量多不多、代码的可扩展性有多高,等等。可以看到,学术界出身的创业人士,在保证代码质量方面,明显比不上工业界出来的人。
|
||||
|
||||
另外,当一个产品出现问题的时候,比如说性能不佳、有特别难解决的问题、在不同平台上表现出不一样的行为等,有多年工作经验的工业界人士往往可以轻易解决,而学术界出来的人,在最开始既没钱又没人的情况下,往往就会止步不前。
|
||||
|
||||
这种差距的根源是做研究和做产品的本质要求不同:做研究的人,只需要实现一个想法,做最核心、最精彩的那一部分;而做产品的人,有很多边边角角的事情需要解决。一个可以演示的学术产品,和一个可用的工业界产品,其质量差距是非常大的。
|
||||
|
||||
这种区别在公司的发展过程中,体现在多个方面。首先,学术界出来的人往往会低估软件开发的复杂度。结果就是软件总是开发不出来,需要不断地延期。其次,当公司规模足够大的时候,几乎所有代码都必须推倒重来,让有工业界开发经验的人来主导并重新开发。
|
||||
|
||||
这是很重要的一步。有些公司这一步开始得比较早,学术界出来的人能意识到自己的欠缺,这些公司所需要付出的代价就相对小一些。而更多的公司往往是等到发现不可收拾之后,才不得不开始被动地改动代码,这个时候往往要付出巨大的代价。这个代价,甚至可能是一家公司的垮台。
|
||||
|
||||
我有时候觉得,如果一个创业团队,既有学术界的人士保证对前沿技术的认识和眼光,又有工业界人士保证对商业的敏感度,更有扎实的具有多年工业界开发经验的团队,确保在早期就有一个比较坚实的基础,那么这家公司的发展肯定会顺利得多。
|
||||
|
||||
然而,这种情况在创业团队里比较罕见。这主要是因为在思维方式和交流方式上,学术界人士与工业界人士很不一样。这种不一样,语言上不太好表达。大体上是做学术的聊的都是前沿科技,工业界则对实用性和商业契机更有兴趣。把这两撮人放在一起,往往各自成群。
|
||||
|
||||
近些年来,越来越多的工业界人士开始参加学术会议,这是一个很好的现象,起码说明两者在融合。然而非常有意思的是,开会的时候更多还是工业界人士和工业界人士相谈甚欢,学术界人士与学术界人士自娱自乐。两者对于什么技术好,什么技术不好,观念差距非常大。
|
||||
|
||||
我早年在学术界很多年,而今在工业界也很多年,因此能深刻地感受到这里面的差异。但是英雄莫问出处,学术界和工业界都出现了很多创业成功者,也有很多创业失败者。对于创业者来说,如果知道自己更擅长什么,以及什么方面有缺陷需要弥补,我想肯定是不无裨益的。
|
||||
|
||||
对于学术界出来的人,在创业早期就能意识到一个产品的开发,除了自己能看到的那一小块有趣的东西外,还有无数非常无趣但是必需的东西,从而对产品开发的复杂度有更好的预期,对于开发一个好产品需要的时间有更好的认识,这是非常有必要的。这在很多时候,正是Tableau一路走来磕磕绊绊最重要的原因。
|
||||
|
||||
|
||||
|
||||
|
||||
77
专栏/技术与商业案例解读/006在线旅游帝国Expedia崛起的背后.md
Normal file
77
专栏/技术与商业案例解读/006在线旅游帝国Expedia崛起的背后.md
Normal file
@@ -0,0 +1,77 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
006 在线旅游帝国Expedia崛起的背后
|
||||
我会在这一年中介绍一些总部在西雅图,或者研发中心里面很重要的一部分在西雅图的IT公司。这其中除了微软和亚马逊这样的大鳄以外,还囊括了诸多在不同领域取得一定统治地位的公司们。
|
||||
|
||||
今天的主角是一家著名的在线旅游公司——Expedia,我将和你说说它的创业与发展史。
|
||||
|
||||
除了微软和亚马逊以外,Expedia可说是总部设在西雅图的IT公司中最知名的一家。当然,从某种程度上来说,Expedia与其说是家IT公司,不如说是一家在线旅游公司。
|
||||
|
||||
Expedia的创始人就是Zillow的创始人理查德 · 巴顿(Richard Barton)。我想任何一个人,如果一辈子可以创立两家都很优秀的上市公司,这个人显然就是一个“大神”了。
|
||||
|
||||
巴顿创立Expedia的时候还在微软。那大概是1994年的时候,微软打算做一个旅游指南的CD-ROM。巴顿觉得,只是搞个CD-ROM其实没什么意思,要干不如干一票大的。他是极少数在那个时候对互联网就有所了解的人之一,所以他想做一个在线的旅游信息提供商。
|
||||
|
||||
那个时候的微软还没有后来那么庞大,他很容易就见到了比尔 · 盖茨和史蒂夫 · 鲍尔默,并且说服了他们。于是他加班加点地干活,在1996年的时候,一个叫作Expedia的网站上线了。
|
||||
|
||||
1999年的时候,微软决定将Expedia拆分出去,这大概是比尔 · 盖茨觉得一家做软件的公司同时做旅游代理有点不伦不类吧。
|
||||
|
||||
这个网站被拆分出去时,正赶上了2000年之前的互联网泡沫,这恰是一个契机,它很顺利地就在纳斯达克上市了。这对Expedia无疑是个非常幸运的事情。巴顿就继续做CEO,这个CEO一做就做到了2003年。
|
||||
|
||||
这家公司的名字Expedia,按照巴顿在一次采访里面的解释是Exploration和Speed的组合,这两个词分别意为“探索”和“速度”,因此Expedia象征着“迅速查找旅游的线路”。这个名字不但应景,而且非常有特色,让Expedia的品牌旗帜非常鲜明。
|
||||
|
||||
2003年的时候,IAC决定花钱买下Expedia私有化。这次收购到底溢价多少,我无从查实了,但我有一点不太理解:为什么巴顿就想卖它了,而不是坚持下去、继续做下去?但是从后来的资料看,巴顿可能是一个更适合创业,而不是经营企业的人。Expedia到了2003年的规模,他也有点儿做不动了。加上互联网泡沫刚过,市场一片萧条。有人买,此时卖掉其实未必是件坏事。
|
||||
|
||||
买下来的结果就是让CEO拿了钱并退出了。巴顿估计是分到了让自己这辈子都衣食无忧的钱,他在拿着钱去完善自己下一个创业计划的同时,也度假休息了一年。
|
||||
|
||||
休息一年以后回到西雅图,他和从微软到Expedia一路同行的老同志罗伊德 · 福林克(Lloyd Frink)一起,开始了一段新的创业之旅。
|
||||
|
||||
这次创业一直处于保密状态,直到万事俱备只欠东风的2006年,Zillow才作为一家房地产信息整合和查询的公司暴露在大众面前。
|
||||
|
||||
后来接受采访的时候,巴顿表示自己的确在2003年的时候就有了新想法,打算做Zillow了。如果这个时间是真的,和Redfin创始人开始搞Redfin的时间其实也差不多。
|
||||
|
||||
所以说,牛人的观念总是惊人得相似。有关Zillow和Redfin的故事,我会在后面的文章里讲述,这里就不再展开了。
|
||||
|
||||
买下Expedia的IAC的董事长是巴里 · 迪勒(Barry Diller),而迪勒是一个企业经营和资本运作的高手。从这方面来说,Expedia是成于巴顿,但绝对是兴旺发达在迪勒的手上。
|
||||
|
||||
经过两年的整合,迪勒决定在2005年的时候让Expedia重新上市,并采用了同样的股票代码。
|
||||
|
||||
但是卷土重来的Expedia背后,不再是一个对旅游行业不熟悉的巴顿,而是有很多年经验的迪勒。
|
||||
|
||||
重组以后的Expedia包括了无数大大小小的品牌,除了著名的Expedia.com以外,知名的还有Hotels.com以及HotWire.com,加上2004年买入并专门做企业业务的Egencia,以及后世非常著名的做旅游社区的猫途鹰(TripAdvisor),等等。
|
||||
|
||||
这次重新打包上市后,Expedia在资本市场上受到了追捧。有钱在手,加上懂得旅游经营的管理团队,这让Expedia从此成为了全球最大的旅游代理,从此以后从未掉队过。
|
||||
|
||||
到2011年的时候,迪勒又决定把Expedia里面与旅游媒体相关的业务都重新打包上市,并保留了所有和旅游交易相关的业务,包括所有的酒店、机票、租车、游轮,等等。
|
||||
|
||||
这次拆分并独立上市的公司里面最重要的是猫途鹰,Expedia和猫途鹰就这样成为了两家公司。但是两者业务完全独立了,而董事长却都是迪勒。
|
||||
|
||||
这种资本运作和拆分壮大不仅需要眼光和远见,而且需要强大的资本运作能力,迪勒正是有这种远见的资本运作者。我们可以说,Expedia最初的成功离不开巴顿的远见,但是真正在资本市场上呼风唤雨,壮大成长,主要还是缘于身为资本运作高手的董事长迪勒。
|
||||
|
||||
我们不得不佩服迪勒的眼光,猫途鹰从Expedia剥离出来成为独立的旅游媒体社区以及评论中心之后,迅速发展成为全球当之无愧的第一旅游社区。
|
||||
|
||||
一个社区的力量,在社交网络没有出现之前可能不被大家理解,Facebook、Yelp之类给大家树立的榜样,使得猫途鹰这个旅游社区加评价的品牌影响力非常得巨大。
|
||||
|
||||
我想,如果当初这个品牌没有从Expedia剥离出去,那么因为既做裁判又做观众的缺陷,猫途鹰绝无可能发展到今天的地位。
|
||||
|
||||
作为旅游公司的Expedia就介绍到这里,而作为IT公司的Expedia就更有意思了。
|
||||
|
||||
前面说到,Expedia总部在西雅图这边,又是从微软分离出去的,所以其技术层面一方面保留了非常重的微软痕迹,并非是湾区或者其他初创公司的那一套,更多地基于Linux和Java。另外一方面,Expedia的董事长通过资本运作又收购了大大小小无数的品牌,而这些品牌们在技术上又都是各自为政自然生长的。
|
||||
|
||||
此外,Expedia还是一家商业地位在很大程度上远高于技术地位的公司。公司优先考虑商业决策,而对统一技术框架的实现兴趣不足。
|
||||
|
||||
经过多年的自然生长以后,Expedia公司里面组和组之间、品牌和品牌之间的技术五花八门。这种五花八门带来的副作用现在逐渐体现出来。
|
||||
|
||||
比如说,不同品牌之间的数据无法做到实时的共享。一个用户在不同品牌下面的账号的行为不容易做有效的关联分析。因为技术的不足反而拖累了商业的发展,这就是多年来重视商业而不重视技术的直接体现。
|
||||
|
||||
Expedia对技术的态度,说得好听一点,这是百花齐放,说得不好听一点,那就是在技术上没有足够的积累和底蕴。作为一家旅游公司,它的基础架构层面的建设是很值得商榷的,这也反过来在不断地阻挠其商业模式的进步。
|
||||
|
||||
Expedia的这样一个状态,也直接导致其IT工作人员很大程度上难有土壤成为一流的IT人员。或许,这也是一些朋友会有在Expedia过渡几年的想法,并在择业时往往优先选择其他公司的原因。
|
||||
|
||||
和商业的蒸蒸日上相比,Expedia在技术层面显得有些混乱。在西雅图,有些公司有些组的领导就私底下有Expedia出来的一律不给面试的潜规则。这种潜规则是不是公平暂且不说,但是这种潜规则实实在在地发生了,而其背后的原因,值得我们每个人去深思。
|
||||
|
||||
|
||||
|
||||
|
||||
77
专栏/技术与商业案例解读/007房产经纪的颠覆者Redfin:在“传统”与“现代”间徘徊.md
Normal file
77
专栏/技术与商业案例解读/007房产经纪的颠覆者Redfin:在“传统”与“现代”间徘徊.md
Normal file
@@ -0,0 +1,77 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
007 房产经纪的颠覆者Redfin:在“传统”与“现代”间徘徊
|
||||
我会在这一年中介绍一些总部在西雅图,或者研发中心里面很重要的一部分在西雅图的IT公司。这其中除了微软和亚马逊这样的大鳄以外,还囊括了诸多在不同领域取得一定统治地位的公司们。
|
||||
|
||||
今天的主角是房产经纪的颠覆者、“二手房电商”之父Redfin。这家总部位于西雅图,成立于2004年的公司,在历经十余年以后终于在今年7月份上市,也算是苦尽甘来。
|
||||
|
||||
上市以后,Redfin就以每天近10%的涨幅天天上涨,股价从IPO价格起在短短几天内就翻了一倍。这在美股市场上是非常罕见的。
|
||||
|
||||
说起来很有意思,在西雅图这边,很多IT公司都和房地产有关系,Redfin更是其中的翘楚。Redfin这家公司,严格意义上来讲,应该说是一家房地产公司而不是IT公司,只是IT在其中扮演了举足轻重的作用,所以我们也可以把它归类于IT公司。
|
||||
|
||||
要介绍Redfin,需要简单介绍一下美国房地产业。在美国,房地产拥有很多年的历史,是一个发达又很传统的行业:美国的民众要买房,只能通过买房代理去购买;卖方同样也只能借助于卖方代理。虽说有着自主买卖的可能性,但是代理和代理的交易依然是美国房地产交易最主流的方式。作为代理们,买卖双方各提房屋交易价的3%作为服务费。
|
||||
|
||||
房主卖房,需要把房子挂出来;买方,则要能看到房子挂在哪里。然而,除去那些服务于同一个协会有着内部数据交易平台的代理们,在2004年前后普通民众要想靠自己找一找市场上有哪些房子在卖,是不可能避开代理的。时至今日,由于有了Redfin,有了Zillow等公司的出现,当初那种不可能的事情早已是明日黄花。
|
||||
|
||||
Redfin由创始人大卫 · 伊瑞克(David Eraker)、迈克尔 · 道赫蒂(Michael Dougherty)和大卫・赛林格(David Selinger)创建。Redfin公司最初的想法来自于伊瑞克,他痛感买房不便并有感于美国落后的房地产业,作为有志青年,决定改变买房难的局面。
|
||||
|
||||
之后,他毅然决定从有着大好前景的华盛顿大学医学院退学,进入软件开发行业,和好友道赫蒂,一个耶鲁大学毕业的电子工程专业的人,一起开创新一代房地产公司。
|
||||
|
||||
他们的想法非常简单,就是要从落后的世界向电子化转变,在一个地图上把挂出售卖的房源信息都可视化,让买房的普通大众可以很方便地搜寻和买到房子。
|
||||
|
||||
这个想法,也许今天看起来稀松平常,但是在当时可是异常先进的理念。先进到了什么程度呢?他们的理念,早于现在大家耳熟能详的谷歌地图的出现。
|
||||
|
||||
所以用地图来显示房源信息,通过基于网页的服务来达到快速搜索找房的办法,在2004年无疑是前无古人的壮举。
|
||||
|
||||
先进的理念背后需要一个好的技术实现。坦白地说,两位创始人显然都是软件开发的小白,并没有足够的能力实现他们的想法。这个时候,第三位创始人赛林格就出现了,这位在进入Redfin之前在亚马逊做过数据挖掘研发部门的负责人。
|
||||
|
||||
2004年,西雅图地区高大上的IT公司还是微软,亚马逊还不像今天这样是个庞然大物,那时候亚马逊的领导当然也不如今天这样瞩目,所以找一个进来做创业公司远比现在要容易得多。
|
||||
|
||||
这三位是如何结识又如何聚集到一起去的呢,真实故事已经不可查了。但是不管怎样,赛林格选择加入,并成为了Redfin的CTO,顺利地帮助公司把这个想法落了地,使之成为产品。
|
||||
|
||||
任何一家公司都是要赚钱的,Redfin也一样。然而和使用地图与互联网提供搜索的想法不同,Redfin的赚钱途径就不是那么先进了。
|
||||
|
||||
Redfin和其他所有的房地产相关公司比如Zillow都不同,其他公司主要靠广告来赚钱,而Redfin这家公司本身就是一家房地产中介公司,它通过雇用代理作为全职员工,帮助用户买卖房子收取佣金来实现盈利。
|
||||
|
||||
我想这很可能是在2004年的时候,刚从学校毕业的几位创始人并没有理解到广告的魅力,终是被当时固有的认知禁锢了,进而后来让Zillow这样的公司有机可乘。
|
||||
|
||||
前文说过了,传统意义上买方和卖方的经纪都会抽取3%的交易费作为手续费。在传统的公司里,这就是经纪的主要收入来源。而Redfin的经纪因为是公司的全职员工,他们拿的是固定薪水,不管买卖多少套房子,3%的手续费归公司,不计入他们的收入。
|
||||
|
||||
而Redfin为了能够更好地招揽客户,采用了一个大招,就是“返点”,把原本规定的3%的手续费的一部分返还给买家和卖家。比如说卖房子只需要1.5%的手续费,买房子也给1%以上的返点,这样就相当于原来买家卖家要付更多的钱,现在就少了。加上在线的这套基于地图的搜索引擎实在厉害,这个模式倒也让它混得风生水起。
|
||||
|
||||
当然这个套路其实只能在美国人的圈子里行得通,在中国人的圈子里就不行了。中国的房地产代理,很早以前就开始主动给客户返点了,有的返点比Redfin还要狠。所以Redfin对中国人的帮助,更多的是它那个无比强大的搜索引擎。
|
||||
|
||||
只是当Redfin选择成为房地产代理公司以后,同时也就断绝了成为广告公司的可能,因为房地产代理公司是不能够通过给竞争对手或者其他人提供广告服务来赚钱的。
|
||||
|
||||
这样一来,一个做得特别好用的搜索引擎,无数的人在上面搜房,但是这些流量并没有能够变成真金白银,反而成就了诸如Zillow等公司。Redfin当初选择了这条路,到底是对还是错呢?
|
||||
|
||||
我们说回到创始人。创始人们想到了在地图上显示房源信息这个非常超前的想法,又想到通过降低买卖双方的佣金来让更多的用户通过他们购房来盈利,但这似乎已经是他们思维的极限了,公司的盈利之路走得并不顺利。
|
||||
|
||||
于是在2005年,第一次融资并从麦德罗纳风险投资集团(Madrona Venture Group)拿到100万以后,三位创始人在2005和2006年就纷纷离开了自己创办的公司。创始人在公司仅仅呆了两年,也是很罕见的事情。
|
||||
|
||||
之后就是资本战胜了创业者的故事了,新加入的CEO格伦 · 凯尔曼(Glenn Kelman)从此开启了他领导Redfin的十余年职业生涯。
|
||||
|
||||
Redfin在其漫长的公司发展过程中,有过若干次上市的传闻,最近的一次是2014年。这一年发生了一件大事,早就离开公司的两个创始人道赫蒂和赛林格把公司给起诉了。
|
||||
|
||||
起诉的原因是Redfin给两位寄了支票,说要买回他们手上的原始股,这两位一个有200万股,一个有约100万股。2004年两位创始人离开Redfin的时候,他们的股票也都被行权了。但是Redfin保留了用40美分一股买回这些股票的的权益。
|
||||
|
||||
这个买回的权益如果Redfin的所有权发生了变更就会失效。在2005年的一次融资过程中,新的资本获得了超过50%的投票权。因此从法律意义上来说,Redfin发生了所有权变更,也就不再享有以40美分一股买回这些股票的权益了。
|
||||
|
||||
于是当Redfin想浑水摸鱼在近十年后买回这些股票时,对方不干了,因为股票已经值十多美元一股了。这个官司一打,自然就把2014年Redfin的上市搅黄了。官司最后是和解了,但是任谁遇到这种事都会火冒三丈的吧。
|
||||
|
||||
无论如何,作为一个基于IT服务的房地产经纪公司,Redfin有着全美国访问量最高的房地产中介经纪公司网站,它在经历了房地产崩盘和井喷之后,将业务覆盖到了美国的各个地方。
|
||||
|
||||
官司和解后又三年,Redfin在2017年7月终于上市,其股票上市以后立刻暴涨50%。Redfin的CEO很有信心地发言说“我们就是房地产界的亚马逊”。
|
||||
|
||||
但是在美国,人们对于房地产买卖的需求毕竟没有日常消费品的需求大,而手续费只是用户选择经纪的诸多因素之一。所以房地产市场是不是需要一个“亚马逊”,是一件不确定的事情;Redfin是否能够成为房地产市场的“亚马逊”,也是一件不确定的事情。
|
||||
|
||||
Redfin的未来会怎样,这是很多人都在关注的问题。西雅图房市这几年走势非常好,Redfin作为房屋销售代理公司,其业务发展也非常不错。在房地产的春天里,Redfin的发展也同样进入了快车道。然而,如果哪天房市不好了呢,这家公司的业务又该如何走?
|
||||
|
||||
其实,谷歌、Facebook和阿里等一系列公司都证明了一点:数据才是真正赚钱的东西。而Redfin因为是家房屋代理公司,行业规则决定了它无法通过广告业务从数据里面赚钱,这是一个极大的限制。从这个角度看,Redfin的前途尚有值得担忧的一面。
|
||||
|
||||
|
||||
|
||||
|
||||
71
专栏/技术与商业案例解读/008房产经纪的“协作者”Zillow:一个地产数据平台.md
Normal file
71
专栏/技术与商业案例解读/008房产经纪的“协作者”Zillow:一个地产数据平台.md
Normal file
@@ -0,0 +1,71 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
008 房产经纪的“协作者”Zillow:一个地产数据平台
|
||||
我会在这一年中介绍一些总部在西雅图,或者研发中心里面很重要的一部分在西雅图的IT公司。这其中除了微软和亚马逊这样的大鳄以外,还囊括了诸多在不同领域取得一定统治地位的公司们。
|
||||
|
||||
今天的主角是Zillow。对于在美国购买房子的人来说,Zillow和Redfin是两个最常用的网站,但这两家公司的赢利模式完全不同,因为Zillow主要依靠广告和订阅来赚钱。
|
||||
|
||||
此外,Zillow的行事风格也非常有特色,简单地说就是买买买,再买买买,继续买买买。具体来说就是,Zillow通过不断收购自己领域相关的创业公司,来巩固自己的地位。
|
||||
|
||||
我们经常发现有些公司买着买着就撑不住了,消化不良了。因此,一个通过不断买买买来持续壮大自己,还不怕消化不良的公司,在整个IT界是很少见的。能够不断买买买而壮大自己,本身就是一种能力。
|
||||
|
||||
Redfin本身就是个房地产中介,它使用先进的IT技术来提升房地产销售业务,其竞争对手是全国各地各种各样的房地产中介公司,这些地产中介主要是传统的公司,有的甚至有上百年历史。
|
||||
|
||||
而Zillow本身并不是一家房地产中介公司,而是一家信息整合公司。Zillow的做法是把各地散落的房地产信息都整合起来,然后提供给美国各地的各大房地产中介公司使用。
|
||||
|
||||
理论上来讲,但凡是Redfin的竞争对手,包括Redfin本身,都可以是Zillow的衣食父母。
|
||||
|
||||
具体来说,Zillow的做法主要是把Redfin视为竞争对手的那些各大传统房地产中介公司们,都搬到Zillow这个平台上来,给它们提供类似Redfin的现代化IT工具,从而使之能够在和Redfin的竞争中活下去。
|
||||
|
||||
因此从这个角度来说,Redfin发展得越好,对传统的房屋中介公司们越有威胁,就有越多的公司和在公司工作的房屋经纪人来使用Zillow的服务,并给Zillow交钱。
|
||||
|
||||
Zillow成立于2006年,创办人是理查德 · 巴顿(Rich Barton)和劳埃德 · 佛林克(Lloyd Frink)。
|
||||
|
||||
其中,巴顿是一个非常著名的创业人。他创办或者联合创办的公司还有著名的旅游公司Expedia、招聘和企业评价公司Glassdoor等,并且创办了网上旅游招聘共享网站Trover。这是一个可以大书特书的人,他连续创业,不断成功,他的成功改变了很多行业,我想也许他以后还会继续成功。此外,他也拿过无数个奖。我很遗憾从来没有见过他本人,希望有生之年可以有这样的机会见见本尊。他的故事估计需要专门立文才能好好讲述,但是今天他不是我们的主角。
|
||||
|
||||
说回正题。在成立之初的几年中,Zillow做得老老实实、中规中矩,没有什么值得特别称道的地方。但是“房地产信息整合平台”这个光环,还是让Zillow赢得了一圈投资人的青睐。
|
||||
|
||||
于是在经过5年的发展以后,Zillow于2011年7月正式上市。由于之前就有诸多期待,上市当天,股票就被抢疯了。大家貌似都很看好它的业务模式。
|
||||
|
||||
但事实上,Zillow上市前做生意一直小心翼翼的,让人感觉不到它的可怕,也不希望别人察觉它的野心。而它的野心在上市之后很快暴露出来,Zillow一下子有钱了,也说不好是以前就定好的策略上市后开始执行,还是说上市以后发现可以大把花钱了,它展开了一条一般人难以理解的疯狂收购的扩张道路。
|
||||
|
||||
Zillow的收购道路是这样的:2011年刚上市就先收购了Postlets,也有一说是上市前就收购了;接下来到了11月,再次收购Diverse Solutions,这次交易价是780万美元;2012年,Zillow再次把手伸向了RentJuice,收购价高达4千万美元。
|
||||
|
||||
这个时候,地球上基本已经没有什么可以阻止Zillow继续收购各种各样大大小小的房地产创业公司了。一个月以后,Zillow又以1500万美元的价格买下了HotPads。
|
||||
|
||||
让人不解的是,Zillow到底是怎样做到收购了一个又一个的企业,然后又迅速地整合进自己的数据平台的?我想这个答案应该值1亿美金!
|
||||
|
||||
这次收购之后Zillow终于消停了一段时间,但时隔差不多10个月,就再次出手,这次是5千万美元买下了StreetEasy,创历史新高。
|
||||
|
||||
正当大家以为这可能是Zillow能买下的规模最大的公司时,Zillow开始甩出了历史上最大的一笔收购:宣布收购Trulia!
|
||||
|
||||
当时Zillow是美国房地产信息平台的老大,而Trulia则是老二。Zillow的竞争压力主要来自于Trulia,而这次合并估计是蓄谋已久。这两家公司的合并正式确立了Zillow在房地产信息和广告市场的寡头地位,其他竞争对手从此再无翻身之力。
|
||||
|
||||
Zillow花了大半年的时间完成了这次收购。而这次收购应该是Zillow历史上最大,也是整合最不易的一次,所以这次对外界给出了一个明确的整合完成时间。然而,半年对于这样大规模的整合来说依然是非常非常快。而在完成收购的同时,Zillow还顺便买了Retsly,把脚顺利插进了加拿大房地产市场。
|
||||
|
||||
合并完Trulia之后,Zillow变得越来越开心,又买了Dotloop和Naked Apartments。在大家觉得这场收购应该差不多的时候才发现,Zillow又买了一家叫作Bridge Interactive的公司。在买买买的路上,Zillow越走越远。
|
||||
|
||||
整个Zillow的发展史,在上市以后就是一部“买买买,继续买买买”的过程。借此,Zillow建立起了非常宽广的“护城河”。
|
||||
|
||||
这条“护城河”包括两方面,一方面是市面上做类似房地产数据的公司,都没办法逃离Zillow买买买的魔爪,另一方面是它由此建立起一个比很多传统的房屋买卖代理公司更强大的数据体系,更便捷的服务方式。而且,自从Trulia在市场上“消失”以后,Zillow已经不可能再让另外一个类似规模的竞争对手诞生了。
|
||||
|
||||
Zillow在不断构建“护城河”的同时,也在不断开拓新的市场,从房屋买卖发展到房屋租赁市场。
|
||||
|
||||
如果我们说Redfin的模式是自己做大,通过和其他传统的房屋买卖代理公司比拼,进而取得更多的房屋销售业绩来赚钱的话,Zillow的做法是想办法用类似于Redfin的计算机平台,去武装一个又一个传统的房屋买卖代理公司,让这些传统公司的业务有和Redfin匹配的工具去支持。
|
||||
|
||||
因此这些人其实都给Zillow交了钱,并且只要Redfin继续存在和扩张,这些传统的房屋买卖代理公司,以及房屋租赁公司等和房屋相关的方方面面,都必然要继续使用Zillow的业务来武装自己。Zillow的这种想法和商业模式,注定了它的受众要比Redfin大得多。
|
||||
|
||||
这让我想到了当年苹果和微软的战斗。苹果的机器很牛,而微软的操作系统一直很努力地追赶苹果的体验。然而架不住微软是给各大硬件厂商提供操作系统服务的,而苹果则是用自己优异的操作系统给自家的硬件服务。历史已经证明,这样做的后果是什么。
|
||||
|
||||
所以从这个角度来看房地产市场上的Redfin和Zillow,尽管比喻并不合适,我总觉得有点像苹果和微软当年的路线。
|
||||
|
||||
可以看到,这两家公司盈利模式迥异;而且,不仅仅盈利模式不同,盈利规模也很不一样。Redfin无论是盈利的速度,还是烧钱的速度,都远远落后于Zillow。而Zillow这种买买买,然后再买买买,然后继续买买买的发展道路,在整个IT领域内都是非常罕见的。
|
||||
|
||||
我们必须说,目前来看Zillow这家公司发展得很成功。加上Redfin上市以后有大把钱可以继续去和传统的房屋代理商斗,房屋代理商们别无选择,只能继续使用Zillow的服务。可以说Redfin发展得越好,Zillow越有发展的空间。这两家公司在实际发展过程中,是不是会有某种默契呢?
|
||||
|
||||
|
||||
|
||||
|
||||
71
专栏/技术与商业案例解读/009颠覆还是协作,房地产市场上Redfin和Zillow的抉择.md
Normal file
71
专栏/技术与商业案例解读/009颠覆还是协作,房地产市场上Redfin和Zillow的抉择.md
Normal file
@@ -0,0 +1,71 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
009 颠覆还是协作,房地产市场上Redfin和Zillow的抉择
|
||||
在美国,人们对于房地产的热情有几百年的历史。美国的房地产交易主要在买房经纪和卖房经纪之间进行,买房经纪和卖房经纪需要挂靠房地产经纪公司。在这个历史悠久的市场里,上百年来积淀下许许多多的房地产经纪公司,其中不乏横跨全国的大企业,和立足本地市场的地头蛇。
|
||||
|
||||
然而就像所有的传统行业一样,房地产交易很大程度上也是一个技术落后的行业,而将房地产交易和计算机技术结合起来,可以极大地提高房地产交易效率。要知道“效率就是金钱”,让房地产市场更有效地运转起来,意味着有更多的赚钱机会。
|
||||
|
||||
在房地产交易和计算机技术结合这个角度上,美国最有代表性的是Redfin和Zillow两家公司。其中,Redfin是一家用现代科技武装自己的新型房地产经纪公司,它的目标是成为房地产传统经纪公司的颠覆者。
|
||||
|
||||
Zillow则是一家房地产数据公司,通过现代科技打造了一个地产数据平台。然后,它用这个数据平台去武装所有的传统房地产经纪公司,并向这些公司收钱从而赢利。Zillow本身并不介入房地产交易。
|
||||
|
||||
这就形成了一个非常有趣的局面。到底哪家公司的经营模式更合理,更有利于自身的长期发展呢?
|
||||
|
||||
先假设第一种情况,市场上只有Redfin,没有Zillow。这种模式下,通过在线交易,买家找房子就是一件非常容易的事情。Redfin有低廉的收费和很强大的数据库,做事情肯定更加有效率。
|
||||
|
||||
Redfin的短板在于它的经纪队伍。因为经纪们只拿固定工资,而不是按照卖多少房来提成,那些传统意义上做得好的经纪,不一定愿意加入Redfin。
|
||||
|
||||
这个问题其实也可以解决,只要建立更合适的薪酬体系,总是有人愿意来的。因此,在只有Redfin的市场中,结合了现代科技和传统房地产经纪优势的Redfin有很大的优势去赢。
|
||||
|
||||
再假设只有Zillow的情况。这种模式下,Zillow的前景不如Redfin明朗。这是因为传统意义上房地产交易市场是个很保守的行业,保守的行业就没有太多改变的动力。Zillow的地产数据平台也许有很现实的意义,但是传统地产经纪公司是不是愿意付费使用这个平台,付多少钱才是合理的,这就不好判断了。
|
||||
|
||||
也许有些公司比较开明,愿意去尝试,并且从中受益了。而更多的可能是大房地产经纪公司联合起来,抵制Zillow,乃至出钱推出自己青睐的房地产数据平台。到最后,房地产行业确实是进步了,但是Zillow是否能够从这种进步里面受益是不得而知的。
|
||||
|
||||
再假设Zillow先来到市场,然后Redfin出现的情况。这种情况对于Zillow来说,依然存在着类似的问题:Zillow对传统房地产经纪公司的吸引力到底有多大。如果不够大,Zillow赚不到足够多的钱,那么在Redfin出现之前可能Zillow已经破产了。
|
||||
|
||||
当然我们始终可以说,Zillow不是第一个做地产数据平台的公司,即使Zillow倒了,还会有另外一个Zillow起来。
|
||||
|
||||
再假设Redfin先来到市场,然后Zillow出现的情况。和Zillow比起来,Redfin作为房地产经纪公司,是直接做客户生意的。它在市场上赚钱与否,和别人是不是用它的数据平台关系不大;促成了多少房地产交易,就能收到多少佣金,这是它赚钱的模式。
|
||||
|
||||
因此,Redfin比起Zillow来,开始更容易生存下去。而Zillow到来的时候,如果Redfin足够强大,大不了收购之,可能Zillow不会有机会成为今天这样一个大型房地产数据平台公司。
|
||||
|
||||
现实的情况是Zillow和Redfin出现的时间差不多。Redfin出现在市场上,用先进的科技武装自己,开始做房地产经纪公司,介入房地产买卖行业。因为使用了先进的技术,加上低廉的收费,高效率低成本很容易让Redfin短期内做成很多生意。一段时间内,Redfin让很多传统房地产买卖企业感到了压力。
|
||||
|
||||
“有人瞌睡,就有人送枕头”,Zillow就在此时出现了,它呼喊着:“来来来,我给你们准备新的武器,武装到牙齿。结合你们在这个领域里上百年的经验积累和我先进的数据平台,你们根本不用怕Redfin。”
|
||||
|
||||
传统房地产买卖企业在竞争的压力下,更容易去接受和使用新技术。它们也更愿意花钱去买Zillow的订阅。而被Zillow武装了的传统房地产经纪公司的经纪们,也就有了和Redfin分庭抗礼的能力。
|
||||
|
||||
所以美国房地产市场上出现Redfin,在差不多的时期里又出现了Zillow,这不一定是巧合。
|
||||
|
||||
今天这两家公司的格局很有意思。
|
||||
|
||||
一方面,Redfin在美国已经是一家很成功的房地产买卖公司,但是在美国房地产交易市场上的交易量占比还算不上庞大。在美国大部分地方,经手房地产交易的,主要还是传统房地产经纪公司。不过,Redfin依然在扩张。
|
||||
|
||||
另一方面,Zillow的扩张比Redfin还要厉害很多。大概是迫于Redfin的压力,传统房地产经纪公司订阅Zillow服务的比例增长非常快。到今天,Zillow赚得钱比Redfin还多,市值还要更高。
|
||||
|
||||
从创业角度看,在美国试图继续走Redfin道路的IT创业公司并不少,单西雅图本地,孕育出来的这类公司就不止一家。
|
||||
|
||||
比如说,西雅图成立的一家叫作外居乐的公司,主要就是服务中国国内的土豪到西雅图和美国其他地方购置房地产。它是一群做IT的人和做房地产买卖的人联合成立的。又比如说,最近刚拿到A轮融资的FlyHomes,是另外一个继续走Redfin道路的公司。
|
||||
|
||||
当然这些创业公司在Redfin的模式上都有更多改进。或者更细分人群,比如外居乐;或者有新的服务特色,比如FlyHomes可以在买家不能顺利贷款的情况下,以公司的名义把房子买下来,让卖家更安心。
|
||||
|
||||
另外一方面,在Zillow出道的初期,走Zillow路线建设地产数据平台的公司也有一些。但是这两年,这类公司就几乎看不到影子了。一方面是因为早期,Zillow一直疯狂地买买买,收购了很多这样的创业公司,一方面则是Zillow已经足够大,很难再有第二家获得市场机会了。Zillow现在已经是很多传统房地产交易公司的标配平台,再有公司做这种数据平台的创业,连找投资都是很困难事。
|
||||
|
||||
从这个角度看,房地产经纪公司因为直接接入房地产交易,所以赚钱更容易。因此总是有新陈代谢,新的公司以新的技术、新的服务,取代老公司是常态。
|
||||
|
||||
而房地产数据平台这个领域的竞争,赚钱的总量很大程度上取决于美国的房地产经纪需求的总量,有一个上限。但竞争没有那么激烈,Zillow一家独大的格局基本上已经形成。
|
||||
|
||||
现在,来回忆一下今天的故事。
|
||||
|
||||
房地产交易是一个传统行业,而新技术介入传统行业一般有两种方式。一种是直接成为传统行业的竞争对手,一种是成为为传统行业提供新技术武装的服务商。前者是进攻性的,而且利润率高,可以通过消灭后者来获得更多的成长空间。后者是支持性的,其发展很大程度上取决于整个行业的总量。
|
||||
|
||||
从发展上看,Redfin因为直接介入利润率高的房地产交易行业,其发展空间,尤其是赚钱的空间比较大。Zillow是收服务费性质的公司,其利润很大程度上受限于房地产市场的总量。所以Zillow发展到一定程度以后,就不会再有大规模发展了。
|
||||
|
||||
此外,类似Redfin的企业越多,Zillow这样的数据平台公司越不好过。因为这些新型的房地产经纪公司,自己都是用现代化科技武装的,不需要使用Zillow的数据平台。
|
||||
|
||||
|
||||
|
||||
|
||||
59
专栏/技术与商业案例解读/010应用交付网络大厂F5:“一招鲜”之殇.md
Normal file
59
专栏/技术与商业案例解读/010应用交付网络大厂F5:“一招鲜”之殇.md
Normal file
@@ -0,0 +1,59 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
010 应用交付网络大厂F5:“一招鲜”之殇
|
||||
我会在这一年中介绍一些总部在西雅图,或者研发中心里面很重要的一部分在西雅图的IT公司。这其中除了微软和亚马逊这样的大鳄以外,还囊括了诸多在不同领域取得一定统治地位的公司们。
|
||||
|
||||
今天的主角是一个著名的网络大厂F5。这家总部位于西雅图的网络设备公司,是全世界应用交付网络(ADN)这一领域最重要的厂商。
|
||||
|
||||
F5成立于1996年,这个名字来源于1996年的电影《龙卷风》。藤田博士根据风力及破坏程度将龙卷风分为F0~F5共6个等级,F5对应的就是藤田级数里面的最高等级,F5这个公司名就是最为猛烈的龙卷风的意思。
|
||||
|
||||
要理解这家公司的产品线,我们需要理解什么是应用交付网络。F5公司自己的说法是:F5 产品以及其运行的平台可确保你的应用快速、安全地部署在任何设备上使用。在介绍F5公司的产品线时,我会就这个说法详细展开。
|
||||
|
||||
1997年,在公司成立一年以后,F5发布了第一个产品,名叫BIG-IP的负载均衡器。这款产品主要被置于一群功能相同的服务器和客户端之间,当客户通过统一的IP地址请求服务时,负载均衡器可以根据背后各个服务器的负载情况进行动态的重定向。
|
||||
|
||||
在2000年互联网泡沫兴起的时候,大网站面对不同客户的访问提供唯一的公网地址,很容易就让服务器过载。而F5的这款产品,可以自动监控并且动态地把服务重定向到不同的内网服务器去,这一点非常实用。
|
||||
|
||||
BIG-IP系列的产品一直以来都是F5的拳头产品,即使在后来很多其他网络大厂商加入竞争行列以后,BIG-IP依然是F5最为重要的营收项目。比如说微软必应相关的数据中心的服务,在2010年前后依然跑在F5的负载均衡器上。
|
||||
|
||||
经过多年的发展,F5的BIG-IP平台已经发展成一个综合性平台,它不仅仅是个负载均衡器,同时还是一个网络代理,而且又增加了很多的企业安全功能。同时,这个体系还提供了对所有流量的监控,用户还可以制定策略对特定流量进行加密和解密。
|
||||
|
||||
F5的这款产品的核心,除去独家的硬件以外,还有自行研发的TMOS专有操作系统。TMOS是F5公司的核心知识产权,它最初基于FreeBSD,后来重新基于Linux开发过。它建立了一个包含高度可扩展、可靠,且可重复使用的服务的统一虚拟池,可动态适应数据中心、虚拟机和云基础架构环境的改变。
|
||||
|
||||
所谓的应用交付网络,在F5的定义下就是通过F5的TMOS构建的环境,让应用的开发和运行可以不用担心实际运行环境,不论是自家的数据中心还是使用公有云,因为TMOS构建的环境,在应用看来都是没有区别的。这就是F5从负载均衡器起家,逐渐发展起来的BIG-IP产品线。
|
||||
|
||||
因为BIG-IP系列的成功,F5于1999年成功在纳斯达克上市。上市以后股票就开始飙升,原因之一是.COM时代很多公司都需要F5的设备,投资者对F5网络的销售期望也很高。
|
||||
|
||||
然而在2000年互联网泡沫破灭以后,因为破灭的互联网公司们不再大量采购F5网络的设备,销售无法支持已经飙升的股价,这给F5网络带来了致命的影响。
|
||||
|
||||
市场环境的改变,导致产品的销路和股价都走低,此后很长一段时间里F5都处于比较低迷的状态。
|
||||
|
||||
而在BIG-IP系列产品上,F5又开发出了BIG-IQ系列产品。BIG-IQ系列产品比较好理解,它的主要作用是全面统一地管理部署在全球各地的BIG-IP系列的产品。这种管理包括了对网络的配置、监控,乃至升级等。BIG-IQ系列的出现让BIG-IP产品真正成为了很好用的产品。
|
||||
|
||||
iWorkFlow是F5的另外一款产品。顾名思义,这是工作流定义软件,它在BIG-IQ的基础上定义了一个工作流的操作过程。当企业里面的不同网络设备需要升级,而且这种升级部署之间有关联的时候,用这款产品定义好一个工作流,系统就可以自动按照定义好的工作流进行管理了。这款产品在数据中心这样的东西出现以后,显得至关重要。
|
||||
|
||||
随着云计算变得越来越重要,F5也推出了自己的产品Silverline。简单一点来讲,这是一款安全产品,主要作用在云上,可以和企业的云服务一起部署。它提供了防火墙、反DDoS攻击、反各种入侵等一系列功能。
|
||||
|
||||
随着云计算的铺开,F5公司的这些产品自2009年迎来了一波非常巨大的红利。某种程度上来讲,网络相关技术和应用的发展,在.COM时代是相对技术的一块。不管.COM时代怎样去追求点击率,不可否认,都需要合适的网络设备去支持这种规模效应,而F5网络的负载均衡器是这种技术的一个体现。
|
||||
|
||||
当云计算时代开启,移动互联网的App时代到来,对技术要求更高的互联网设备自然也就水涨船高,一波接一波的红利就此到来。从2009年开始,F5过上了一段非常幸福的日子。
|
||||
|
||||
然而有喜就有悲,基于这种硬件设备的解决方案挺好,就是比较贵。而有能力建设大型数据中心的企业,比如说微软、谷歌、亚马逊、Facebook,乃至国内的腾讯、阿里、百度,都不是吃干饭的。
|
||||
|
||||
大概在2010年的时候,软件定义网络的概念就出来了。这个东西说白了就是:原来由硬件厂商实现的那些功能,是不是可以在PC机上用软件来实现。
|
||||
|
||||
举个例子,微软组建了一个强大的网络技术小组,在自己的数据中心里面研发自己定义的网络,首先拿来开刀的正是这个F5独步天下的负载均衡器。
|
||||
|
||||
2010年初,微软就在自己数据中心内部部署自己的软件负载均衡器了。它的主要目标就是用廉价的数据中心的PC机集群和软件,去彻底取代昂贵的F5负载均衡器设备。初始阶段总是比较艰难的,只是这种艰难也没有难住微软这样的大公司。在若干年的积累之后,微软内部的新数据中心全面换成了自己开发的软件负载均衡器。
|
||||
|
||||
同样的现象在谷歌、亚马逊、Facebook,还有阿里巴巴等公司上演。失去了这些大企业订单的F5显得颇为尴尬:一方面是死不了,有足够多的中小企业需要它的产品;另外一方面,它也活得不太好,毕竟但凡有能力的都离开它了。
|
||||
|
||||
日子不好过了,首先CEO就要背锅。于是老CEO下台,经过一年左右的搜寻,2017年终于来了位新的CEO。其次就是裁员,效益不好,只能裁人,这也是没办法的事情。
|
||||
|
||||
“一招鲜吃遍天”的日子好像终于过去了。F5作为应用交付网络的先驱和现存的最大的厂商,除去这一招以外,也没有发明出另外一条可以持续盈利的产业链来。换掉CEO是不是就能拯救这家公司呢?我们只能拭目以待了。
|
||||
|
||||
|
||||
|
||||
|
||||
63
专栏/技术与商业案例解读/011在线差旅报销鼻祖Concur:在转型中获得发展.md
Normal file
63
专栏/技术与商业案例解读/011在线差旅报销鼻祖Concur:在转型中获得发展.md
Normal file
@@ -0,0 +1,63 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
011 在线差旅报销鼻祖Concur:在转型中获得发展
|
||||
我会在这一年中介绍一些总部在西雅图,或者研发中心里面很重要的一部分在西雅图的IT公司。这其中除了微软和亚马逊这样的大鳄以外,还囊括了诸多在不同领域取得一定统治地位的公司们。
|
||||
|
||||
今天的主角是Concur公司。事实上,它已经不是一家独立的公司了,在2014年的时候SAP以83亿美金的价格收购了它。然而作为全球性的、云上的在线差旅报销市场的领导者,Concur依然值得我们认真了解一下。Concur的故事对于很多创业公司非常具有借鉴意义。
|
||||
|
||||
Concur位于大西雅图地区的贝尔维尤市中心。在市中心公交车站旁的一栋大楼上,楼顶高耸着Concur的标牌,提醒着大家这家全球知名的差旅报销SaaS公司的存在。
|
||||
|
||||
Concur由史蒂夫 · 辛格(Steve Singh)于1993年创立,创立之初就开始做差旅报销的管理这个领域。Concur的发展经历了三个非常重要的阶段。在公司成立最初的两年间,Concur做了一款软件。和那个时代大部分卖软件的公司一样,Concur的套路也是出售CD,卖一套是一套。
|
||||
|
||||
因为差旅报销软件本来就不是每家企业每年都需要购买的软件,等到很多企业都买了这个软件以后,发展新的客户变得不再容易。生意做到1995年的时候,这个模式就无法持续下去了。创始人开始思索企业软件到底要怎么做。于是Concur在创立两年之后,开始了企业的第一次转型。
|
||||
|
||||
这次转型并不复杂。以现在的企业运作模式来看,做法和Oracle类似。软件是不卖了,Concur通过给企业级客户提供许可证,来按年收取费用。
|
||||
|
||||
但是许可证其实也不是一个很好做的生意,因为每家客户的需求都多少有些不同,所以Concur需要派人去给客户做培训。很多时候,因为Concur这种软件固有的原因,往往还需要为很多客户进行定制。这样一来,花在培训、定制以及维护这些定制版本上的开销一直居高不下。
|
||||
|
||||
尽管如此,1998年的时候,整个IT行业欣欣向荣,离互联网泡沫破灭还有两年时间,那个时候只要有好业务的IT公司上市都很容易。在创立5年之后,Concur顺利地在1998年上市了。
|
||||
|
||||
但2000年的互联网泡沫随之而来,所有IT企业相关的公司都受到了影响。虽然说Concur自己到2000年还只是一家卖软件和服务的公司,但起码属于IT服务业。于是覆巢之下没有完卵,Concur的股价也迅速下滑。公司因为财务状况恶化,无法继续像以前那样提供培训和定制服务了。
|
||||
|
||||
刚刚创立7年,并且已经有过一次转型,但上市两年就陷入经济困局,这对Concur无疑是当头一棒。那个时候,Concur的创始人应该是怎样地一番痛定思痛,站在风口浪尖寻找解决方案啊。
|
||||
|
||||
然而我们必须清楚一点,就是:开发定制软件,并且替用户维护定制软件,这是一个巨大而不可能量产的举措,虽然可以给公司带来一些利润,却无法让公司上规模。
|
||||
|
||||
也许互联网的迅猛发展提醒了Concur,这次创始人史蒂夫 · 辛格站在了时代的前沿,他决定做一家SaaS公司。
|
||||
|
||||
具体来说就是,软件部署在Concur自己维护的服务器集群上,而用户通过浏览器就可以访问Concur的服务。用户的付费模式并没有改变,改变的只是软件在哪里部署和维护。
|
||||
|
||||
我们都知道,一旦一个东西不需要去给用户安装,只需要在自己管理的机器上部署,那么维护和修理的成本就不可同日而语了。但是在2000年的互联网泡沫之后,一家企业如果转向纯粹的互联网服务,而本身不提供任何软件的话,是一件非常危险和反潮流的事情,一般人没有胆量做出这种举动。
|
||||
|
||||
所以我们应该为史蒂夫 · 辛格鼓掌了,他在这样一个关键时刻做出了一个高瞻远瞩的决定。接下来的发展变得顺风顺水,自从Concur切换到完全基于浏览器的服务之后,公司的维护运营成本迅速下降,公司的服务对象得以迅速铺开。仅仅两年之后,公司的盈利就开始了年复一年翻倍的局面,这种增长一直持续到公司被收购。
|
||||
|
||||
这个时候的Concur早已不是以前那个卖点软件卖点服务的Concur,它摇身一变成了SaaS公司。我们姑且不谈技术层面的问题,仅仅从商业上看,2005年成立的SaaS公司里,能够比Concur更成功的,找来找去也只有Salesforce一家。可以说,史蒂夫 · 辛格的眼界,在很大程度上决定了Concur的高度。
|
||||
|
||||
这里说个小插曲。2009年的时候发生了一件事情,它让Conur出名了。在公司提交给大众和交易所报备的文件里,Conur宣称公司创始人史蒂夫 · 辛格在密歇根大学获得了工学学位。然而事实并非如此,这个创始人在毕业前就决定自己开公司,学位都不要了。但是,事情就这样爆发了。
|
||||
|
||||
不要学位创业的大有人在,比如说比尔 · 盖茨,又比如说史蒂夫 · 乔布斯,正所谓英雄莫问出处。但是,没有拿到学位却谎称拿到了学位,就不对了。这种事情可大可小,当然主要还是看董事会了。
|
||||
|
||||
史蒂夫 · 辛格得到了公司全方位的支持。好在只要公司不追究,这也不是什么大不了的事情,公司修正了申报材料的同时,也发表声明表示:整个公司的董事会和管理层都信任这位领导人的能力,至于有没有学位,都不影响这位领导人对公司的领导;公司感谢史蒂夫 · 辛格这么多年来为公司的成功所做出的巨大贡献,公司也没有打算把他从CEO的位置上扒下来。
|
||||
|
||||
2010年对Concur来说是非常重要的一年,这一年Concur不但毛利率首次达到了72%的罕见高度,并且顺利实现了收支平衡。Concur的CEO兼创始人史蒂夫 · 辛格接受采访时就发出感叹,一家公司能够赶上两次变革,并且都能转型成功,实在是不容易的事情。
|
||||
|
||||
史蒂夫 · 辛格还说,Concur在很早的时候就实现了正现金流。然而慢慢地他就意识到,一家公司要成功仅仅靠正现金流是不够的,重要的是什么时候能够在大规模提高正现金流的同时,还保持收支平衡并且最好有盈利。他说,如果能够做到这两方面,公司将无懈可击。
|
||||
|
||||
“无懈可击”这话或许有些夸大。不过在很长的一段时间里,Concur确实同时做到了规模的扩张和收支的平衡。一家公司如果现金流是正的,同时能够平衡收支,在经济环境好的时候就可以继续扩张。如果经济环境不好,只要停止扩张,正的现金流和平衡并且有盈利的收支也可以让它很好地度过寒冬。从这一点看,史蒂夫 · 辛格的观点,无疑说明他是一位卓越的企业家。
|
||||
|
||||
2014年,SAP公司以83亿美元的价格收购了Concur。这个价格溢价不少,刚开始很多人都不看好这次收购,觉得SAP是犯傻了。其实,SAP作为一家非常成功的商业公司,几乎没有做过什么特别亏本的收购。
|
||||
|
||||
这也是SAP历史上最大的一次收购。SAP给予的答复是,并不是Concur本身值那么多钱。Concur作为一家非常成功的SaaS公司,对SaaS产品和产业的理解,对于SAP所需要面临的转型当中的不确定性,有着非常重要的参考价值。更何况,Concur的管理人员可以直接帮助SAP来实现向云的转型。
|
||||
|
||||
三年后的今天来看,SAP显然是赚到了。目前SAP在云端转型驾轻就熟的势态,都离不开Concur管理层背后的操刀。更重要的是,作为一个耕耘于大型企业的ERP厂商,SAP收获了无数中小型企业客户。这笔账随着SAP和Concur的打通,让SAP一下子就把脚插进了原来它看不上,但是在云时代会“蚁多咬死象”的中小企业里去。这对于SAP的发展有着不可估量的作用。
|
||||
|
||||
2017年,在这家企业成立24年以后,Concur正式登陆中国。我们必须说,中国的行情复杂,而Concur是不是会水土不服,还需拭目以待。
|
||||
|
||||
最后我也想问你一个问题,如果你是史蒂夫 · 辛格,在企业关键转型的时候,可否做出正确的选择并坚持下去呢?
|
||||
|
||||
|
||||
|
||||
|
||||
49
专栏/技术与商业案例解读/012漫谈企业转型:在市场变迁中寻找生机.md
Normal file
49
专栏/技术与商业案例解读/012漫谈企业转型:在市场变迁中寻找生机.md
Normal file
@@ -0,0 +1,49 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
012 漫谈企业转型:在市场变迁中寻找生机
|
||||
上一次,我说到了Concur的发展史,从卖软件开始,到销售许可证,再到今天转型做Saas服务,其转型可谓非常成功,随之它的市值也不断飙升,最后被SAP以83亿美元的价格收购了。
|
||||
|
||||
从Concur的历程来看,企业转型可谓救治企业、阻止企业走下坡路的良方。那么企业转型是否真如Concur所经历的那般容易呢?其实不尽然。
|
||||
|
||||
举例来说,IBM作为一家“百年老店”,早年是做自动制表机出身,后来才转做大型计算机,之后又在各个领域遍地开花,一度成为计算机领域的代名词,并在20世纪引领了个人计算机的发展。然而此后IBM就一蹶不振,郭士纳上台前几乎要倒闭,著名的前CEO郭士纳让IBM成功转型成为一家服务公司。可是伴随云计算的到来,IBM终于转不动了,“百年老店”也只能亦步亦趋走下坡路。今时今日,恐怕没有多少人还敢断言IBM能重回当年的辉煌。
|
||||
|
||||
再来看微软的例子,它从成立到奠定以Windows和Office“两条腿”为基础,全面开花发展的软件帝国,只用了20来年。但是进入新世纪,微软在努力转型的过程中,先后错失了搜索、社交网络、移动互联网和手机,最后终于在云计算这摊子上转型成功。这才让这个曾经称霸世界的软件帝国,得到了喘息之机。可见转型之难。
|
||||
|
||||
至于转型失败的例子,那就更加比比皆是了。惠普公司曾经是最早租用斯坦福大学土地,进入斯坦福高科技园区的企业之一。它成立之后一度非常领先,在大型机、医疗器械、打印机领域都做得很好。然而惠普后来选择了一条拆分自己优质资产,从企业级产品向消费级产品转型的道路,具体来说就是要成为个人计算机的领头羊,为此惠普还买了即将倒闭的康柏。但今天来看,惠普在计算机界已经没什么影响力了。
|
||||
|
||||
为什么有的企业转型成功了,有的企业却转型失败了?这里面有诸多因素。
|
||||
|
||||
首先,我们必须承认,领导人的作用是巨大的。Concur如果换上了另外一位CEO,能不能够连续转型成功,就不好说了。Concur的CEO有两个巨大的优势,第一是有眼光,知道应该往哪里转型;第二是有执行力,能够执行下去。
|
||||
|
||||
微软的转型也是在鲍尔默下台萨提亚上台以后才成功的。其实鲍尔默在台上的时候微软内部要转型做云计算已经有一段时间。但是鲍尔默始终无法有力的推动这个转型。而萨提亚上台以后,这个执行力才真正的体现出来。至于IBM,如果没有郭士纳的出现,可能早在20年前就轰然倒塌了。郭士纳的转型也是兼具了眼光和执行力。
|
||||
|
||||
有什么样的领导人,才会有什么样的企业。在计算机和互联网领域,我们很少看到什么样的企业成就了什么样的领导人;相反地,一旦领导人开始出问题,企业的发展也就不可预料了。
|
||||
|
||||
其次,我们也应该看到,任何一家能够转型成功的企业,都具备另外一个条件:企业尚未濒临死亡,有足够多的现金去做转型。很多时候,在合适的时间点做转型,往往非常关键。这个时间点里,企业的旧业务刚开始走下坡路,但是依然能够产生足够的现金流,毕竟企业的新业务需要时间来培养。
|
||||
|
||||
新旧交替之间,旧业务可以产生足够的现金流,才能够支撑到新业务可以造血。从这个角度上讲,倘若微软不是有Windows和Office一直源源不断地造血输血,那么屡次转型却失败的微软,它的命运也不会比惠普公司好到哪儿去。
|
||||
|
||||
可以这样说,企业当前造血能力越强,就越能够给企业转型上的尝试提供更大的空间、更久的时间。
|
||||
|
||||
盲目转型,尤其是在造血功能不健全的情况下做转型,只能是“转型是找死,不转型是等死”的状态。怎么都逃不过一个“死”字。
|
||||
|
||||
再次,企业转型还需要注意时机问题,时机不到,无论是过早还是过晚,都会导致转型失败。前者没人买单,后者已经有人先占坑了。但是企业转型的时机问题,很多时候和领导人的素质密切相关。F5公司就是一个典型的没有在合适时机转型的公司。
|
||||
|
||||
F5成名于互联网泡沫之前。它的产品非常有特色,可以说应用交付网络领域就是F5创造出来的市场。所以它当仁不让地坐着最大厂商的位置,一直在自己熟悉的领域里面发展。
|
||||
|
||||
然而,F5网络赶上了互联网泡沫的破灭,外界对其产品的需求急剧下降,所以它有过颇为艰难的日子。在那段日子里,收缩运营规模,满足核心用户的需求,从而保证公司有盈利可以活下去,我觉得无可厚非,F5在自己熟悉的领域里面扩张也没错。
|
||||
|
||||
后来,互联网的下一次高潮和发展,让F5迎来了一次新的飞跃。各大公司的数据中心以及云计算的发展,都让F5的相关设备和应用的销量得到了长足的发展。然而这是好的方面,很遗憾F5并没有预见到这次新的互联网发展,从而导致了少数寡头的诞生。无论谷歌、Facebook,还是亚马逊、微软,对于F5的设备都是既爱又恨。价格高不说,应用规模上去之后,到底F5的设备能不能够撑得住也是个问题。
|
||||
|
||||
寡头的诞生让F5面临一个巨大的危机,因为这些公司有能力、有实力,可以自己造F5的设备,并且显而易见,这种投入成本可控,长期利益很好。但是这些公司初期还造不出来这些设备,所以F5如果趁着卖设备红利还高,资金充足的情况下做转型,其实还是有成功的可能的。
|
||||
|
||||
等到各大寡头自己都把自己的设备研发得差不多的时候,F5不仅将面临各大公司订单的大量减少,而且将资金匮乏,直至失去转型的可能性。这样一来,F5就会自然而然陷入到“转型是找死,不转型是等死”的境地。
|
||||
|
||||
归根结底,一家企业要能成功转型,首先取决于领导者的眼光,其次取决于自己的造血能力。如果造血能力强,领导者眼光好,又能够挑准合适的时机,那么转型成功是可期的。否则企业往往会陷入“转型是找死,不转型是等死”的境地。而这种情况下是不是还有救,我觉得即便有,希望也是很渺茫了。
|
||||
|
||||
|
||||
|
||||
|
||||
55
专栏/技术与商业案例解读/013克雷公司沉浮录:行走在超级计算机市场.md
Normal file
55
专栏/技术与商业案例解读/013克雷公司沉浮录:行走在超级计算机市场.md
Normal file
@@ -0,0 +1,55 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
013 克雷公司沉浮录:行走在超级计算机市场
|
||||
我会在这一年中介绍一些总部在西雅图,或者研发中心里面很重要的一部分在西雅图的IT公司。这其中除了微软和亚马逊这样的大鳄以外,还囊括了诸多在不同领域取得一定统治地位的公司们。
|
||||
|
||||
互联网行业的发展如此迅猛,很多曾经鼎鼎大名的企业如今都默默无闻了,在西雅图的克雷公司(Cray)就是这样一家企业。
|
||||
|
||||
克雷公司以超级计算机之父西摩 · 克雷(Seymour Cray)的名字命名,它是做超级计算机的,在今天全球前400名的超级计算机里,大概占据了60%的份额。这个数字,大致上可以说明在超级计算机领域克雷公司的地位。
|
||||
|
||||
但是现在使用计算机的主流方式已经从一台超级计算机,过渡到了无数多台普通计算机构成的数据中心联合工作的方式。因此,超级计算机已然是一个小众市场,而克雷公司是这个小众市场里面举足轻重的公司。
|
||||
|
||||
克雷公司自从成立以后曾经在西雅图鼎鼎大名,但其后续发展可谓命途多舛,经历了很多次破产和合并。今天,我就带你看一看这家超级计算机制造公司。
|
||||
|
||||
最初,这家公司全称叫作克雷研究公司(Cray Research),是“超级计算机之父”西摩 · 克雷创建的第二家公司。克雷研究公司主要研发基于集成电路的超级计算机。这之前,西摩 · 克雷创建了控制数据公司,即CDC(Control Data Corporation)。克雷在CDC公司里面研发基于晶体管的超级计算机,代表系列有CDC 600、CDC 7600等。
|
||||
|
||||
20世纪60年代末70年代初,正是从晶体管走向集成电路的时候。半导体集成电路的发明,给计算机产业带来了一场前所未有的变革,这种变革连发明了集成电路的仙童公司也没有预见到。
|
||||
|
||||
然而克雷预见到了这个变化。克雷创立的克雷研究公司成为了第一家使用集成电路研发超级计算机的公司。当时仙童公司亟需证明集成电路有着广大的市场,并因为看到克雷的CDC公司曾经在晶体管超级计算机上取得巨大成功,决定和他合作。
|
||||
|
||||
整个合作计划里,克雷研究公司专门从事超级计算机的设计和研发,而仙童公司则给他们提供专门设计的集成电路。克雷需要什么,仙童公司就给设计什么。两者的结合,让著名的新型超级计算机Cray-1得已面世。
|
||||
|
||||
Cray-1是在整个计算机发展史上具有里程碑意义的超级计算机。它第一次使用了集成电路,重量轻到只有5吨;而克雷的设计也非常优雅。在1975年Cray-1发布的时候,作为超级计算机市场上的唯一重量级对手,IBM被耍得连边儿都找不到了。1975年,这可能也是克雷研究公司最具有历史意义的时刻。
|
||||
|
||||
因为这个计算机实在是太牛太强大了,订单纷纷到来。而订单带来的资金又让克雷研究公司的研发得以顺利开展下去。
|
||||
|
||||
克雷研究公司做的计算机越来越厉害,10年后的1985年,它们发布了Cray-2。Cray-2的计算能力使得美国国家航天局第一次可以进行航天飞机的模拟风洞试验。而这之前,因为计算机计算能力的限制,人类一直没有办法做这么大规模的计算。
|
||||
|
||||
由于克雷研究公司在技术上如此领先,对手们与它之间的差距非常巨大。此时全球在用的超级计算机的70%以上都是克雷研究公司研发的,IBM、NEC等竞争对手只能瓜分剩余的30%的市场。那个时候的克雷研究公司,无疑非常辉煌。
|
||||
|
||||
然而超级计算机有一个巨大的问题:它的计算能力很强,性价比却不高。占计算机市场大部分的企业和个人,并不需要如此强大的计算能力。换句话说,他们不愿意花冤枉钱买超级计算机。
|
||||
|
||||
进入20世纪80年代,以苹果和IBM为首的个人计算机发展得如火如荼,个人计算机的计算能力没有超级计算机那么强,但是大部分需要计算机的个人和企业,花更便宜的价格买个人计算机也够用了。
|
||||
|
||||
而克雷研究公司并没有预见到这种变化可能给自身带来的影响,准备相当不足。克雷研究公司继续投入钱和人力研发新一代的超级计算机Cray-3,却没有投钱进军个人计算机市场。
|
||||
|
||||
当新一代超级计算机Cray-3研制成功以后,克雷研究公司发现几乎没什么人理睬。那些买了Cray-1和Cray-2的人不需要新的计算机,而其他人则不需要那么快、那么贵的计算机。Cray-3和前两款机型相比,在商业上只能用惨败来形容。
|
||||
|
||||
和如火如荼不断发展的个人计算机市场比起来,Cray-3的惨败让新公司的管理层和克雷之间进一步产生了分歧。公司管理层认为应该进入个人计算机市场,而不是继续研究更快更强的新一代计算机,而克雷则坚持研究新的Cray-4计算机,不管商业上是否有前景,公司是不是能从新型超级计算机里面盈利。
|
||||
|
||||
这直接导致了克雷离开克雷研究公司。克雷又创建了新的公司,但不久就在一场车祸中去世。而那个克雷离开后的克雷研究公司,在经历了Cray-1和Cray-2的辉煌,以及Cray-3的惨淡之后,既没有克雷这样的天才来支撑研发,又没能够在个人计算机市场上有所斩获,慢慢地开始衰落。
|
||||
|
||||
1996年12月,SGI以7.5亿美元的价格买下了克雷研究公司。但是很不幸,这次合并一开始就不被人看好。SGI以图形工作站闻名,而克雷研究公司则擅长搞超级计算机,两者的基因并不是特别吻合。没有人知道为什么在那个时间点SGI要买下已经没有了克雷,又不断走下坡路的克雷研究公司。
|
||||
|
||||
SGI在经过了若干次尝试以后,于1999年把克雷研究公司作为独立的部门剥离出来。此后,成立于1987年,同样主要从事超级计算机研发的Tera Computer公司在2000年买下这个部门,并将自己改名为Cray,即克雷公司。
|
||||
|
||||
在整合了克雷研究公司的相关技术之后,克雷公司一直在推出自己的超级计算机,但是超级计算机在今天已经是一个非常非常小的市场,主要服务于研究机构、航空航天、军队等需要超级计算能力的地方。
|
||||
|
||||
无论如何,“克雷”作为一个品牌还是存活了下来。
|
||||
|
||||
|
||||
|
||||
|
||||
53
专栏/技术与商业案例解读/014“单一化”的隐忧:从克雷公司看“一条腿走路”.md
Normal file
53
专栏/技术与商业案例解读/014“单一化”的隐忧:从克雷公司看“一条腿走路”.md
Normal file
@@ -0,0 +1,53 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
014 “单一化”的隐忧:从克雷公司看“一条腿走路”
|
||||
上次我说到了克雷公司的发展历程,它最初是克雷博士为了研究新一代的基于集成电路的超级计算机而成立的克雷研究公司。
|
||||
|
||||
由于产品一度非常领先,克雷研究公司的生意非常不错。然而随着市场需求的变化,公司试图调整经营方向,但克雷博士的兴趣仍然聚焦在研发新型超级计算机上,两者最终分道扬镳。
|
||||
|
||||
没有了克雷博士,克雷研究公司的生意越来越走下坡路,最后不得不把自己给卖了。然而,卖完之后还被东家再度打包出售,其经历可谓惨淡。这个故事告诉我们,“一条腿走路”的公司是非常危险的。
|
||||
|
||||
克雷研究公司可谓成也克雷,败也克雷:克雷博士不愿意将就公司的需要去做个人计算机产品的开发,公司生意就不好做;克雷离开之后,公司更是止步不前,无以为继。作为只有“一条腿”,即超级计算机这个产品的克雷研究公司,一旦这个产品出了问题,公司本身就难以为继。
|
||||
|
||||
不仅仅是克雷研究公司,历史上很多公司的发展都表明了“一条腿走路”的危险性,因为这一原因而倒下的公司非常之多。
|
||||
|
||||
一个例子就是数据库大厂Ashton Tate——dBase的发明者,它曾经是个人计算机数据库市场当之无愧的第一,然而现在已经没有多少人知晓了。因为Ashton Tate只做了一个产品,即dBase。而这个产品的某个版本出问题之后,这家公司也就迅速从繁荣走向衰败,最后被收购,然后再次被卖出。这个故事和克雷研究公司的命运如出一辙。
|
||||
|
||||
另外一个是非常知名的Sun公司的例子。Sun公司以工作站闻名于世,而当个人计算机的计算能力越来越强,工作站越来越可以被替代的时候,Sun公司虽然做出了发明Java这样的举动,却始终没能够找到让自己稳定盈利的“第二条腿”。于是终于入不敷出,最终被甲骨文收购。
|
||||
|
||||
不过,也有很多公司因为认识到了这一问题,从而多方面寻求发展,并获得了成功。
|
||||
|
||||
微软在成就软件帝国的路途中,就尝试了很多东西:操作系统、应用软件、编程工具、数据库,等等。最后,真正成就微软软件帝国的是Windows操作系统和Office办公软件这“两条腿”。
|
||||
|
||||
企业级软件市场的大厂商甲骨文,起家于数据库产品,并且在企业级市场中做到了当之无愧的第一。但是甲骨文公司在数据库产品上取得了很多成就以后,也从未停止过在其他领域的探索。中间件和企业应用软件,比如ERP、CRM等,都是甲骨文扩张的空间。因为甲骨文公司懂得:一条腿走路并不安稳。
|
||||
|
||||
这些故事告诉我们,公司多元化很重要。但是公司应该怎样去多元化,寻找“第二条腿”呢?
|
||||
|
||||
纵观整个计算机软件和互联网行业的发展过程,很多公司寻找的第二条腿,和第一条腿的互补性都比较强。
|
||||
|
||||
举例来说,微软做操作系统,同时也开发企业级应用软件。因此,它既可以在操作系统里面给自家的企业级应用软件直接提供系统层面的支持,也可以给做企业软件的组提供调用操作系统API的技术支持,做企业级应用软件的优势非常明显。
|
||||
|
||||
再来看甲骨文公司的例子,它以数据库见长,它选择的扩张领域则是那些离不开数据库的企业级应用,比如说ERP软件、CRM软件。一方面,数据库本身可以给这些软件的查询提供更好的支持,另一方面公司也有数据库方面的专家,能够在最有效地使用数据库方面给软件开发人员提供支持。另外在销售方面,数据库和这些企业级应用软件的捆绑销售也很有利。甲骨文公司开发这些应用,配上自家的数据库,互补效应很明显。
|
||||
|
||||
还有一个例子就是,腾讯公司在社交上可谓非常稳固,于是它围绕社交做了很多事情。比如说现在当之无愧是腾讯公司最大现金流的游戏产业,之所以能够非常成功,和社交之间的互补作用是一个很重要的因素。
|
||||
|
||||
此外我也注意到,一家公司的“第一条腿”往往有很强的独创性。克雷公司的超级计算机就是一个很好的例子,甲骨文的数据库自然也是一个经典的例子。但是,我很少见到一家公司的“第二条腿”同样具有独创性。
|
||||
|
||||
往往公司“第二条腿”的发展,都出现在一个已经有竞争对手的市场里。因为这个“第二条腿”的产品,对该公司当前赖以生存的“第一条腿”有很强的依赖关系,所以公司选择从这方面去突破。此时,它可以有效结合自身优势,和行业里面已有的经验,因此往往更容易成功。
|
||||
|
||||
一个经典的例子是企业级应用,它是SAP的“第一条腿”。SAP的ERP系统在公司创立之初有非常强的独创性,但是它依赖于底层数据库,通常也就是IBM或者甲骨文的产品。而甲骨文的“第一条腿”是数据库,于是在意识到SAP的软件对自己有强依赖关系时,选择进军的下一个扩张方向,正是市场上已经有竞争对手SAP的企业级应用软件市场。
|
||||
|
||||
甲骨文的扩张很成功。而反过来,SAP也越来越意识到自己对数据库的依赖性,并于2009年前后开始发力进入数据库市场,推出了内存数据库HANA。SAP的这次扩张同样非常成功。
|
||||
|
||||
Sun公司的做法就是个反例,它不是不知道“第二条腿”的重要性,但是却把“第二条腿”放在了一个和自己的工作站关系不是很大的开发语言Java上。缺乏互动和互补效应的Java,没有成为Sun的另外一个支柱。
|
||||
|
||||
最后总结一下,“一条腿走路”的企业,即使短期内很辉煌,也很容易走入下降通道并面临生存危机,“两条腿走路”的企业要安全得多。
|
||||
|
||||
虽然很难就企业如何寻找“第二条腿”提供放之四海而皆准的通用办法,但是有两点非常明确:首先,一家企业的“第一条腿”往往是原创性非常强,在市场上占有统治地位的产品;其次,很多企业在寻求“第二条腿”时,不会再去寻求一个原创性非常强的东西,而是去寻求市场上已经有其他家的产品,同时对自己的“第一条腿”依赖性非常强的方向去突破。
|
||||
|
||||
|
||||
|
||||
|
||||
93
专栏/技术与商业案例解读/015Halo的开发者Bungie:与微软的聚散.md
Normal file
93
专栏/技术与商业案例解读/015Halo的开发者Bungie:与微软的聚散.md
Normal file
@@ -0,0 +1,93 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
015 Halo的开发者Bungie:与微软的聚散
|
||||
我会在这一年中介绍一些总部在西雅图,或者研发中心里面很重要的一部分在西雅图的IT公司。这其中除了微软和亚马逊这样的大鳄以外,还囊括了诸多在不同领域取得一定统治地位的公司们。
|
||||
|
||||
今天的主角是Bungie,一家总部位于西雅图地区贝尔维尤市的游戏公司,如今全球最大的游戏工作室之一。
|
||||
|
||||
Bungie工作室在国内玩家中知名度不高,但是其开发的游戏大作《光环》(Halo)系列估计就有很多人熟悉了,这款游戏在Xbox上首发,并占据了极其重要的游戏地位。可以说,正是这款游戏让Xbox的主机上终于有了一款在当时可以和索尼PlayStation 2竞争的扛鼎之作,从此以后Xbox从可有可无的游戏平台走向了辉煌的主机巨头行列。而Bungie与其游戏的发行方或者说公司的收购方微软的合合分分,也是Xbox发展史上浓墨重彩的一笔。
|
||||
|
||||
Bungie最初是一个人的传奇故事。1991年,在芝加哥大学就读的亚历克斯 · 瑟罗皮恩(Alex Seropian)创办了自己的游戏公司。其实在创办游戏公司之前,他就已经自己开发仿制了当时非常流行的一款乒乓球类街机游戏,奠定了自己的游戏开发之旅。
|
||||
|
||||
Bungie成立的1991年,计算机还是个新事物,美国的大部分大学还没有日后大红大紫的计算机科学系,而计算机专业则依托于数学或者电子系下面。所以那个时候做软件开发,尤其是游戏开发,想要获得投资更是非常不易。
|
||||
|
||||
瑟罗皮恩在亲朋好友的帮助下,自己组装硬件开发软件,在游戏开发的道路上越走越远。不过,他并没有赚到多少钱。据说是在上一门人工智能课程时,瑟罗皮恩遇到了Bungie的第二名员工杰森 · 琼斯(Jason Jones)。
|
||||
|
||||
琼斯也是游戏的狂热爱好者。他完成了一款叫作Minotaur的角色扮演游戏,这款游戏还运用了AppleTalk这种互联网联网协议,使不同的用户可以通过“猫”实现互联。这款以Buggie公司名义发布的游戏尽管本身销量在当时并不可观,但作为Buggie创立以来的第一桶金,为这两位游戏的狂热爱好者开发下一款游戏提供了资金支持。
|
||||
|
||||
当时射击游戏很流行,因此瑟罗皮恩和琼斯的下一款游戏,也转向了射击类,这就是在Bungie历史上第一款广受赞誉的《黑暗之路》(Pathways into Darkness)。这款游戏的开发在很大程度上奠定了Bungie此后多年的游戏开发模式:专注于射击游戏的开发,让其他人越来越难超越。
|
||||
|
||||
射击游戏并不罕见,比如《毁灭战士》(DOOM)当时就很火。然而这些游戏的普遍特点就是为了射击而射击,缺乏故事情节作支撑,让人很难感受到游戏的乐趣。Bungie在这个时候推出了整个游戏历史上都要浓墨重彩记上一笔的《马拉松》(Marathon)系列的首款游戏。
|
||||
|
||||
和以往的射击游戏比起来,《马拉松》的情节曲折连贯,引人入胜。而那个早在其他游戏里就尝试采用过的AppleTalk,也成为了这款游戏最为独特的一部分,《马拉松》成了第一款可以在不同玩家之间联网和交互的射击游戏。这都让Bungie在众多游戏公司中迅速脱颖而出。
|
||||
|
||||
Bungie的《马拉松》迅速占领了市场。毕竟,能够联网的射击游戏和不能够联网的射击游戏不可同日而语。
|
||||
|
||||
因为一望无际的好日子,Bungie的境况,尤其是财务状况蒸蒸日上,并且很快推出了《马拉松》的续集。
|
||||
|
||||
此时恰逢Windows 95降临的大潮,头脑活络的Bungie把《马拉松》续集移植到了Windows上。而Windows市场的销量远远大于Mac市场,这一波移植的成功让Bungie顿悟了“Windows才是未来”。
|
||||
|
||||
《马拉松》系列的新版本就在Windows和Mac上同步发行了。这几款《马拉松》游戏让Bungie在射击游戏领域一时声名鹊起,并且有了源源不断的订单和滚滚金钱。
|
||||
|
||||
好日子仍然在延续,而聪明的Bungie意识到应该新起一个系列了,毕竟单靠啃《马拉松》系列的“老本”过活,并不是公司长远发展的明智之举。
|
||||
|
||||
新游戏《神话》(Myth)应运而生,这是一款策略游戏,虽然很遗憾我没玩过,但从游戏玩家论坛中仍然可以看到,这款游戏当初是多么受欢迎。
|
||||
|
||||
《马拉松》和《神话》大获成功,让Bungie一跃成为世界顶级的游戏工作室和发行厂商。这时,Bungie再次回到了他们所擅长的射击游戏上来,新的一款游戏被命名为《光环》(Halo)。这款游戏在未来的几年让Bungie获得了大量声誉,但同时也带来了很多麻烦。
|
||||
|
||||
《光环》游戏最初于1999年宣布,同年苹果公司CEO史蒂夫 · 乔布斯在Macworld Expo的Keynote上公开做了演示。这也是Bungie在苹果公司那边获得的最高规格待遇。
|
||||
|
||||
但是Bungie显然已经从Windows和Mac同步发行上尝到了很多好处,《光环》最初的计划也是在Windows和Mac上同步发行,这种“一鱼两吃”的做法,Bungie已经驾轻就熟。
|
||||
|
||||
2000年6月,Bungie在E3 2000上公开展示了《光环》,获得了极大的好评。然而,正当大家都在翘首期盼《光环》正式发行的时候,出乎所有人意料,微软宣布Bungie被他们收购了,Bungie已经成为微软游戏分支的子企业。不久以后,微软决定,《光环》系列不在Windows和Mac中的任意一个平台发行,其唯一发行平台是微软的新游戏主机Xbox。
|
||||
|
||||
有关这场收购背后的故事有很多版本。但目前来看,比较靠谱的说法是《神话2》有一个巨大的Bug,可以删除用户硬盘上的所有资料。所以Bungie被迫在发行前进行召回,但这样一来就损失了几百万美元,让Bungie陷入了财务危机。
|
||||
|
||||
而此时的微软正需要为它的新业务Xbox主机的发展寻找一款很好的游戏大作。相对于索尼这个历史悠久的主机PlayStation 2上大作频出的局面,微软的Xbox当时要么是索尼的移植版,要么就是不值一提的作品,因此急需一款属于并且只属于Xbox的大作。
|
||||
|
||||
这样一来,陷入财务危机的Bungie和需要大作的微软一拍即合,微软买下了Bungie,同时让《光环》成为了Xbox的专属游戏。然而,收购价据说仅为5000万美元。
|
||||
|
||||
实际上,早在推出《神话》系列的同时,Bungie还成立了分支机构Bungie West。这个新成立的分支机构发行了一款叫作《奥尼》(Oni)的游戏。这款游戏算不上大红大紫,加上游戏发行的时候Bungie被微软收购了,因此最终没能够形成一个系列。
|
||||
|
||||
而作为并购的一部分,微软同时也获得了《神话》系列和《奥尼》一半的版权。《奥尼》的开发在2001年结束以后,就没再有续作了。整个Bungie工作室的重心从此转到了给Xbox开发《光环》系列上。这个转型,也为以后Bungie和微软之间的分道扬镳埋下了伏笔。
|
||||
|
||||
《光环》系列的首作取得了极其巨大的成功,发行量超过650万份,市场反应热烈,这是Bungie从未达到过的高度。当时,微软的高层比尔 · 盖茨和鲍尔默都忍不住要让Bungie尽快开发《光环2》。
|
||||
|
||||
这里插一句,考虑到这款游戏只在Xbox上发行,倘若它能在更多平台发行的话,数字可能更是无法想象。
|
||||
|
||||
我来西雅图以后正好认识了《光环》游戏系列的一位开发者,在某次听他讲述这段工作经历时才得知,《光环2》是整个系列里面开发最为辛苦的一版游戏:因为微软高层都对《光环2》的开发抱有很高的期望,而《光环1》又给游戏开发设置了一个很高的标准,这让《光环2》的开发一直不顺,期间多次推倒重来。好在最后《光环2》不负众望地上市了,并且因为和Xbox Live的对接获得了更大的成功。
|
||||
|
||||
Xbox Live是微软为Xbox主机创建的一个可以让全球各地的人联网战斗的平台。这个平台和以往联网游戏最大的不同是:以往的游戏往往都是在局域网内自行组团,而Xbox Live则提供了一个全球统一的平台,并且可以记录每个人自己的战绩和游戏历史,还具有一定的社交功能。
|
||||
|
||||
Xbox Live和《光环2》的对接,使得世界各地的《光环》爱好者们都可以在统一的平台上联网战斗,分享游戏体验,还可以看到排名等各种统计数据。因此,世界各地的游戏爱好者蜂拥而至,非常踊跃地参与进来。
|
||||
|
||||
《光环2》达到了一个新的高度。《光环》系列从此不再只是一款简单的射击游戏,还是一个社交平台。全世界的《光环》玩家都可以共享游戏体验。因为《光环2》的发行,Xbox的销量也迅猛增长。游戏带动主机的销售,这就是微软一直期盼的大作效应。
|
||||
|
||||
2007年发行的《光环3》让这款游戏更上一层楼。为此,Bungie还给《光环》系列发行了两个资料片。
|
||||
|
||||
但是《光环3》发行没多久,Bungie就和微软同时宣布拆分,Bungie脱离微软成为一家独立的公司,而《光环》系列的所有知识产权归属于微软。作为拆分计划的一部分,微软于同年成立了343工作室,替代Bungie制作和发行《光环》系列。《光环4》和《光环5》都是由这个工作室制作的。
|
||||
|
||||
若说当初的收购还有迹可循,这次拆分的缘由就一直不太明朗了。一直到十年后的今天,也没有多少资料公开谈论这次拆分。Bungie和微软的合作延续到了2010年,《光环3》第二部资料片的发布。
|
||||
|
||||
我和那个开发《光环》的工程师聊天时,感觉到在被微软收购的那几年里,公司的一切事务都围绕着《光环》系列进行,这让整个工作室都有点茫然失措。按道理,微软的收购很大程度上给Bungie提供了丰富的资源,这才使得《光环》系列获得了如此巨大的成功。
|
||||
|
||||
但是与此同时,Bungie丧失了自主权和独立性。Bungie存在的作用,对于微软来说就是开发《光环》系列。在被微软收购后的那些日子里,除去《光环》系列,Bungie竟然没有能够开发出任何一款新游戏。这对于Bungie的游戏开发者来说,肯定不是多么愉悦的事情。
|
||||
|
||||
更重要的是,游戏工作室讲究独立性,微软本身则越来越官僚,两者之间难免会在文化上有很多冲突,这种冲突可能可以控制在比较好的范围内,也可能会导致很多的问题。
|
||||
|
||||
我想到了后期,Bungie自己想做的事情,和微软需要它们做的事情,两者之间不仅仅没法沟通和妥协,很可能微软连听都懒得听Bungie的想法了吧。2007年的微软,是官僚主义很盛行的时候。
|
||||
|
||||
坊间另外一个传闻是5000万的价格收购Bungie,微软多少有些趁Bungie财务危机之虚而进入的嫌疑。这笔钱从今天来看,显然是便宜了。而连续不断地让Bungie只为Xbox开发《光环》系列,可能更是让Bungie觉得在微软下面毫无发展空间可言,并最终走上拆分之路。
|
||||
|
||||
拆分以后的Bungie继续扩张,并把新的总部设置在了贝尔维尤市中心。然后,它与全球知名的游戏制作和发行厂商动视暴雪展开合作,由后者替其出版发行下一款游戏大作《命运》。Bungie新发行的游戏《命运》是其独立以后的第一个游戏系列,但是无论人气还是名气,都远远未能达到《光环》系列的标准。
|
||||
|
||||
可以确定的是,离开微软之后Bungie未来的路会更加艰难。拆分十年过去了,现在的《命运》系列依旧无法和《光环》系列相比。它始终没能够像《光环》系列那样万众瞩目,受到玩家的极力追捧,在销量上也未能和《光环》系列媲美。
|
||||
|
||||
想必今天的故事,难免会让你一番感慨。亲爱的读者,如果你是Bungie的创始人,在2000年的时候会不会接受微软的收购?在2007年的时候又会不会选择离开微软?
|
||||
|
||||
|
||||
|
||||
|
||||
61
专栏/技术与商业案例解读/016“卖身”须谨慎:创业公司面临的抉择.md
Normal file
61
专栏/技术与商业案例解读/016“卖身”须谨慎:创业公司面临的抉择.md
Normal file
@@ -0,0 +1,61 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
016 “卖身”须谨慎:创业公司面临的抉择
|
||||
创业公司经常会思考一个问题,就是公司发展到一定规模之后,是否希望被大公司收购。但是被收购就一定万事大吉吗?未必。一个处理不好,就可能导致双方都不开心的局面,Bungie被微软收购的例子多少可以说明些问题。
|
||||
|
||||
那么,被收购是不是好的选择呢?这个问题虽然可以从多个方面去看,但是看是以什么样的方式被收购是一个更为有效的判断途径。一家公司收购另外一家公司的目的不同,被收购公司的退出机制也会不一样。
|
||||
|
||||
这个问题细究起来比较复杂,这里我给出一个简化版的分析,做一个简单的归类,就是看:收购完成之后,收购方到底想不想保留被收购公司的人员。
|
||||
|
||||
1. 最简单的情况:一锤子买卖
|
||||
|
||||
如果说一场收购主要不是冲着人才去的,而是在收购完不久,就将被收购方的工作人员大部分或者全部裁员,那么这种情况其实比较好处理。因为毕竟是一锤子买卖,卖完拿钱,后续的事情也就和这群拿钱走人的无关了。
|
||||
|
||||
这种情况下无非是一个买卖值不值的问题,值了就卖,不值就别卖。也有后来卖了后悔贱卖的,或者没卖而后悔怎么当初这么傻不卖的,但在我看来,这一类买家和卖家之间不会形成长期的不良关系,因此在“卖身”里面是最简单的一类情况。
|
||||
|
||||
拿甲骨文公司强行并恶意收购仁科公司来看,甲骨文公司经过一年多的努力搞定了仁科公司投资人手里的股票,获得了大部分的股权之后,就把仁科公司收购了,收购完就大规模裁员,不算全部裁掉,起码也是十之八九。这件事情对于仁科公司的创始人们来说,始终是咽不下的一口气,但是一锤子买卖,结束了也就一了百了了。
|
||||
|
||||
2. 人才的收购
|
||||
|
||||
如果一次收购是冲着另外一家公司的人去的,情况就比较复杂了。那么,“被收购的公司是不是作为一个独立的业务部门存在”是一个很重要的衡量指标。
|
||||
|
||||
第一种情况是被收购方的人员被收购方打散,并被安排去做其他事情。这种方式和第一种收购差别不是很大。被收购方的人员已经分散到各个项目中去,不再是一股合力,因此在很大程度上,这还是一锤子买卖。被收购方可能会后悔,但不会有什么实际的影响力。
|
||||
|
||||
第二种情况是被收购方作为收购方的一个独立业务部门存在,这种“卖身”需要非常谨慎。通常这种“卖身”甚少产生好的结果,而关键在于被收购的部门有多大的独立决策能力。
|
||||
|
||||
比较经典的收购案当属20世纪90年代IBM对莲花公司的收购。当时IBM陷入危机,郭士纳上台,决定收购莲花公司帮助IBM向软件服务业转型。当时莲花公司的办公软件,无论是电子表格Lotus 1-2-3,还是协同办公软件Lotus Notes,都是业界翘楚。而这场收购,IBM要的不仅仅是这些软件,还有整个研发团队。
|
||||
|
||||
在一段时间里,郭士纳都试图只用莲花公司的人来管理莲花公司的产品开发。但是不久以后IBM自己的产品需要和莲花公司的产品进行整合,双方不可避免地对莲花公司产品的看法有了分歧。而莲花公司的高层在被收购以后的决策力,并没有郭士纳开始许诺的那般强大。
|
||||
|
||||
慢慢地,莲花公司的文化被IBM公司的文化侵蚀和替代,Lotus Notes这款原本神器级别的产品,变得臃肿而难以使用。而在莲花公司里面开发软件的人,还有管理人员,也陆陆续续地选择了离开。
|
||||
|
||||
再来看一下微软对Bungie的收购,也是异曲同工。微软收购Bungie的目的非常明确,游戏主机Xbox需要大作,而Bungie的开发人员有能力也有实力做出大作来。所以收购不仅仅是需要收购资产,更需要收购人才去开发游戏。
|
||||
|
||||
最初的时候,Bungie和微软的目标尽管有些差异,但大方向是一致的,就是推出《光环》游戏。然而随着《光环》游戏大卖特卖,对于微软来说,把《光环》系列做成Xbox专属的大牌游戏显然是最高优先级的事情,这有利于Xbox主机业务的整体开发。
|
||||
|
||||
但是作为一家游戏工作室,数年如一日地开发并且只能开发一款游戏,那就比较痛苦了。没有独立决策能力去按照自己的意愿发展,这样的游戏工作室和游戏公司将没有灵魂可言;它们能够因为一款大作红极一时,却很难红一辈子。
|
||||
|
||||
Bungie的创立者,显然是对游戏事业很有想法、很有主见的人。在开发《光环》系列之前,他们就开发了多款游戏,进行了多方位的尝试。不可否认,这些尝试有成有败,但是不管怎么说,“多样化”更容易产生创新性的游戏创意;敢于尝试,是一家游戏公司生命力的体现。
|
||||
|
||||
微软和Bungie的矛盾在于:微软主要是想提高自己Xbox平台的优势,为此对Bungie的唯一要求就是:开发《光环》系列游戏;至于Bungie团队的创业志向、想法和尝试,不在微软考虑范围之内。
|
||||
|
||||
久而久之,即使Bungie的人知道自己独立出去要失去很多资源,并将失去《光环》游戏的知识产权,仍然选择分离。
|
||||
|
||||
还有第三种情况,这种收购是名义上出钱买了,但是整个公司实际上独立运营。这种收购可能最有利于被收购方长期、独立保持自己的企业文化。
|
||||
|
||||
微软对LinkedIn的收购,至少表面上看,是微软第一次尝试这种模式的收购;谷歌对于YouTube采取的策略也是让其长期比较独立地运营。
|
||||
|
||||
前者怎么样,还未可知,但后者的运营可谓非常成功。直至今天,YouTube在谷歌内部还是使用Google YouTube这个名字,独立运作,负责人直接向谷歌CEO汇报。
|
||||
|
||||
只有经营上的实际独立,才可以给被收购方一个长期的发展空间,但是愿意这样做收购的公司太少了。
|
||||
|
||||
最后总结一下,对于被收购方最好的选择有两个:第一个选择是做“一锤子买卖”,第二个是做独立运作的子公司。
|
||||
|
||||
如果被收购以后,被收购方不能继续发挥优势去独立地做项目,很可能会导致没有话语权,外行指导内行的情况,这种收购需要非常谨慎。尤其是当被收购方不能和收购方就工作的目标和方式、自由裁量权等方面达成一致并写入合同时,最后很可能是一场不欢而散。
|
||||
|
||||
|
||||
|
||||
|
||||
65
专栏/技术与商业案例解读/017亚马逊领导力准则之要有硬骨头.md
Normal file
65
专栏/技术与商业案例解读/017亚马逊领导力准则之要有硬骨头.md
Normal file
@@ -0,0 +1,65 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
017 亚马逊领导力准则之要有硬骨头
|
||||
亚马逊在美国公司里面是家非常奇特的公司,其中一点就是非常强调并且高度宣传它的领导力准则。亚马逊的领导力准则,一直以来都是大家研究这家企业的重点,并且有很多人还专门写书论述。而按照杰夫 · 贝佐斯的说法,这些领导力准则也是成就亚马逊的秘诀。
|
||||
|
||||
亚马逊对领导力准则的态度绝不停留在口号上。在亚马逊的每一天,每个人,不论层级高低,也不管工种是否相同,都需要熟练掌握并且运用领导力准则,它们是用来指导日常工作和交流的基础。
|
||||
|
||||
另外,在招聘的时候,亚马逊的每位面试官都需要针对面试人检查这些领导力准则。一个技术上需要进一步加强但是领导力准则突出的人,比一个技术上很强但是在领导力准则上表现得乏善可陈的人,更容易被亚马逊接纳。
|
||||
|
||||
亚马逊的领导力准则是否真的如同贝佐斯所说,是整个公司成功的灵魂呢?我觉得这是见仁见智的说法。但是探究这些领导力准则和准则背后的实际意义,有助于你理解亚马逊这家企业表现出来的一些与众不同之处。
|
||||
|
||||
今天我就来说一条领导力准则,即“敢于谏言,服从大局”,它的官方解释是:
|
||||
|
||||
|
||||
领导者必须能够不卑不亢地质疑他们无法苟同的决策,哪怕这样做让人心烦意乱、精疲力尽。领导者要信念坚定、矢志不移。他们不会为了保持一团和气而屈就妥协。一旦做出决定,他们就会全身心地致力于实现目标。
|
||||
|
||||
|
||||
这个翻译从“信雅达”上来说是差了点儿。但是作为亚马逊的官方翻译,应该是最准确的吧。
|
||||
|
||||
从字面上来看,这条领导力准则还是比较难理解的,因此我先引用下贝佐斯在亚马逊里面对员工做的解释。大体上贝佐斯的要求分为三部分。
|
||||
|
||||
|
||||
“领导者必须能够不卑不亢地质疑他们无法苟同的决策,哪怕这样做让人心烦意乱、精疲力尽。领导者要信念坚定、矢志不移。他们不会为了保持一团和气而屈就妥协。”
|
||||
|
||||
这一段往往是最容易理解的。在亚马逊里面,所谓的“领导者”并不是指有领导职务的人,而是亚马逊的全体员工。也就是说,亚马逊的每一位员工,都必须有坚定的信念,能够敢于说“不”,坚决说“不”,绝对不随便因为要维持一团和气,或者维持上下级之间的关系等而违心地说是。
|
||||
|
||||
“一旦做出决定,他们就会全身心地致力于实现目标。”
|
||||
|
||||
这是第二部分,它的意思是:服从大局。写得很简单,但是解释同样得多。这里的意思是:一旦一个决定做出来了,哪怕是讨论过程中存疑的一方,也需要从现在开始,完全地聚拢到决定上来,全力以赴地执行决定。
|
||||
|
||||
而贝佐斯特地强调的第三点,其实并没有出现在这段文字里。或者,你也可以将其理解为第二点的一部分。
|
||||
|
||||
这个第三点是说:当一个决定做出并且执行了以后,最后的结果如果是失败的,那么参与执行的所有人,都应该重新检查审视这个结果,但是绝对不允许“当初如果听了我的,就会怎么怎么样”的言论存在。
|
||||
|
||||
|
||||
那么我们来详细看一下这几点都反应了什么。贝佐斯给他自己挑选了一个S-team,这个团队由亚马逊里的一些高管组成。挑S-team的原因是贝佐斯希望这个队伍里的人对自己实施这条领导力准则。
|
||||
|
||||
贝佐斯相信没有人是天才,所以一旦要做重要决定了,大家都要能够坚持自己的观点。当然,所有这些观点都要基于合理的理由,而不仅仅是个人的喜好。
|
||||
|
||||
贝佐斯觉得,办公室政治是非常浪费公司时间和精力的。而为了维持上下级间的一团和气,从而不愿意说“不”,进而造成决策的失误,对一家公司来说要付出的代价很大。因此,在亚马逊,贝佐斯不喜欢也不希望大家因为办公室政治而失去了对真理的追求。
|
||||
|
||||
与其大家忙碌于维持和领导的关系,不如每个人都致力于对真理的追求。这样一来,一个重大决定在做出前就会被反复讨论,从而尽可能地避免或重大或微小的失误。贝佐斯对于S-team中每个人的要求,也是完全基于这样一个原则的。
|
||||
|
||||
这个准则的第二部分是:一旦参与项目的人经过了各种各样的讨论,或者通过讨论达成了一致,或者更有可能的情况是作为最高决策者,在大家互相不能说服的情况下,拍板做出了一个决定,那么在这之后,所有人都必须全力以赴地执行这个决定。而不是说有些人因为自己的意见看法没有得到实现,从而开始偷懒敷衍,或者在决定已经做出的情况下,对外界宣扬自己的不同看法,进而给外界造成一种不团结的印象。
|
||||
|
||||
也就是说,一个决定一旦做出,就要求不存在异类和不全力以赴的情况。造成不团结的言论和行为,都是违反这个领导力准则的。
|
||||
|
||||
第三部分,也是特意强调的一个部分,它是说这个决定的做出既然是集体反复讨论的结果,那么即便最后证明这个结论是不成功的,大家对于这件事情的检讨也应该仅限于就事论事。公司里绝对不允许把做出结论前个人的不同意见搬出来,并作为幸灾乐祸的理由。
|
||||
|
||||
这三条内容放在一起,某种程度上就反映了亚马逊的一种做事风格。亚马逊对于市场的反应速度是非常快、非常有效的。我们都可以看到,一旦市面上出现了一些新的动向,亚马逊相对于其他大企业来说,往往能够根据实际情况,非常迅速地做出反应,而且这种迅速反应很多时候都极为准确。和其他公司对比亚马逊所发布产品的成功率,就可以非常充分地说明这一点。
|
||||
|
||||
此外,亚马逊同样可怕的地方在于:这个机构一旦做出了决定,那么整个公司的机器就会被全面开动起来,不打折扣地执行决定。
|
||||
|
||||
这不像很多公司存在的官僚做派,被否决的一方给决定采纳的一方添堵。这种执行方式对于一家大公司来讲是非常值得赞扬的。集中所有的资源没有分歧地执行下去,一个庞然大物一旦开动了这样的机器,对于竞争对手来说,就很可怕了。
|
||||
|
||||
这条准则的最后一部分还彻底杜绝了所谓“秋后算账”的做法。这种做出决定以后大家一起承担责任,然后就事论事进行改进的态度,是有效杜绝办公室政治的好办法。贝佐斯作为一位卓有远见的领导,提出的这条领导力准则,确实有很多值得我们每个人思考的地方。
|
||||
|
||||
一家企业大了,官僚味儿就出来了。我们大凡能看到的企业,从IBM到微软到谷歌,其实都无法避免官僚化,亚马逊则在最高领导层上通过贯彻领导力准则,很大程度上避免了大公司病。从这个角度来说,我想贝佐斯的确做到了很多公司都没能做到的东西。
|
||||
|
||||
|
||||
|
||||
|
||||
70
专栏/技术与商业案例解读/018亚马逊领导力准则之决策正确.md
Normal file
70
专栏/技术与商业案例解读/018亚马逊领导力准则之决策正确.md
Normal file
@@ -0,0 +1,70 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
018 亚马逊领导力准则之决策正确
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天我要说的一条亚马逊领导力准则是“决策正确”,其中文官网解释为:
|
||||
|
||||
|
||||
领导者在大多数情况下都能做出正确的决定。他们拥有卓越的业务判断能力和敏锐的直觉。他们寻求多样的视角,并挑战自己的观念。
|
||||
|
||||
|
||||
这条领导力准则并不像它看上去那样浅显易懂。如果仅仅关注字面意思,你很容易陷入一种茫然不解的境地。
|
||||
|
||||
这种情况并非你我独有。在亚马逊里面,对于这条领导力准则同样感到困惑的大有人在。不过,亚马逊创始人贝佐斯在很多场合,都从不同角度解释过这条领导力准则。今天,我就来和你聊一聊他对这条准则的多重解释。
|
||||
|
||||
首先来看第一句话:“领导者在大多数情况下都能做出正确的决定。”从字面上来看,这比较容易理解。也就是说,在亚马逊里面,犯错误是可以的,但是如果一个人犯错误的比例高于正确决定的比例,那肯定是不被允许的。
|
||||
|
||||
在贝佐斯的观点里看来,一个领导者首先是一个人,因此不可避免地要犯一些错误。但是,一个领导者必须具备卓越的判断能力和敏锐的直觉,这样才能保证在大部分情况下都做出正确的决策。反之,如果一个人无法在大部分情况下保证决策正确,他就不符合亚马逊的领导力准则。
|
||||
|
||||
因此,能够做出正确的决策,是一个领导者必备的素质。亚马逊不会允许它的雇员常常犯错。犯错多了,考核自然不会好。考核不好的话,轻则奖金飞了,重则需要自谋出路。这就对一个领导者提出了较高的要求。
|
||||
|
||||
人非圣贤,不可能不犯错,但是亚马逊又要求领导者在大部分情况下都能做出正确的决定。那么,一个人如何才能够保证在大部分情况下做出正确的决定呢?这就是领导力准则的第二部分,也是对第一部分这个问题的回答:寻求多样的视角,并挑战自己的观念。
|
||||
|
||||
贝佐斯自己解释过他的见解。一个在大部分情况下可以做出正确决定的人,往往经常性地改变自己的想法。一个不善变的人,不一定是好的领导者。很多领导者都会呈现出这样一种状态:今天有这样的想法,明天却有一个和今天截然不同的想法。这种状态看起来很不合理,但是实际上不但是健康的,而且是值得鼓励的。
|
||||
|
||||
贝佐斯在自己和他人的交往过程中发现,最聪明的人都经常修正自己对事物的理解和决策。哪怕是一个已经考虑过的问题,他们也会拿出来重新思考。这样的人往往能够很好地接纳新的观点、新的信息、新的想法。哪怕这些想法和他们自己现有的认知是抵触的、矛盾的,他们依然会去接纳、思考和吸收。
|
||||
|
||||
然而需要注意的是,贝佐斯也强调,这并不意味着这个人不需要有自己的观点,或者说不需要让自己的观点足够完善。实际上,贝佐斯要求每个领导者在每次做决策的时候都经过深思熟虑。领导者应该基于现有的信息,谨慎地做出决策,因为这种深思熟虑本身,就是保证决策正确的基础。
|
||||
|
||||
如果决策以后就一成不变了,往往会出问题。所以,任何一个人,哪怕有了完善的观点,也应该把这种观点当作一个临时的,或者是一段时期内的,而不是永久的观点。因为新的信息会进来,情况会变,看问题可能会有新的角度与高度。哪怕领导者在一件事情上已经非常有经验,并且做得非常好,一旦他固化了思维,在新的条件下仍会产生错误的决定。
|
||||
|
||||
因此,如果一个领导者可以做到在大多数情况下都做出正确的决策,那么他必然不会拘泥于细节和自己熟悉的范围。
|
||||
|
||||
这个领导者需要审时度势,经常性地反思自己已经做出的决定和形成的观点;他还需要有随时随地接受新观点、新事物、新信息,乃至从新的角度去看待问题的能力;而且,在每个特定的时刻,他都需要基于现有的信息,经过深思熟虑来做出决策。只有这样,一个领导者才有可能在长期的、持续的决策过程中,在大部分情况下都做出正确的决策。
|
||||
|
||||
贝佐斯的观点有很多值得我们学习和深思的地方。从目的出发,一个人如果能够在大部分情况下都做出正确的决策,或者在当前已知条件下做出最好的决策,这个人确实很了不起。而一个公司如果是由这样的人组成的,也必然可以取得令人刮目相看的成就。这一点看起来非常有道理。
|
||||
|
||||
但是我觉得这只是目的,这条领导力准则精辟的地方在于,它还告诉了我们如何达到这个目的。
|
||||
|
||||
如何达到这个目的,需要一分为二地看:
|
||||
|
||||
|
||||
首先,每次做决策的时候,一个领导者需要形成一个经过深思熟虑的观点,这个观点可以被自己所掌握的东西有效地支持;
|
||||
其次,一个领导者又需要能够跳出自己已经形成的观点,随时吸纳新的东西。
|
||||
|
||||
|
||||
前者保证了每次决策都不是轻易做出的,每个决定都是深思熟虑的结果。后者又保证在下一次做决策时,他的信息得以更新,因而不会陷于自己已经形成的窠臼。
|
||||
|
||||
第一次看到这条领导力准则时,我感觉一头雾水,因为它真的非常不好理解。但是当我看到贝佐斯向他的团队进行的解释时,颇有一种恍然大悟的感觉。不得不说,任何一个人,如果既能够做到在决策时认真思考、慎重考虑,又可以保持开放的心态,随时随地更新自己的见地和信息,那么我真的很难想象他做出来的决定会错很多、经常错。
|
||||
|
||||
亚马逊出来的高管写过很多文章,其中或多或少都探讨过这条领导力准则。有些人把它放大到亚马逊这家公司的决策上来看,用来解释为什么亚马逊有很多明显不同于其他公司的地方。
|
||||
|
||||
举例来说,亚马逊作为一家公司,推出来的产品和服务失败的案例屈指可数。目前为止,大家熟知的只有一个Fire Phone。和其他公司比起来,这是亚马逊的一个显著优势。比如,谷歌推出并高调宣传的产品,失败的比例就相对高很多;微软的表现同样如此。
|
||||
|
||||
我们还可以举其他很多公司的例子,但恐怕在美国,的确很难再找到第二家公司,其推出来的产品和服务的成功率如此之高了。
|
||||
|
||||
亚马逊推出来的产品和服务大部分都很成功,这在一定程度上就可以论证:亚马逊在大部分情况下都做出了正确的决策。
|
||||
|
||||
为什么亚马逊可以在大部分情况下做出正确的决策呢?很多在亚马逊待过的高管都认为,这条领导力准则在其中起到了非常重要的作用。
|
||||
|
||||
因为亚马逊做决策的时候,一方面一定会非常慎重地基于已有信息,做出一个仔细思考过的决定,一方面又随时随地根据新信息来重新审视已经做出的决定。所以很多时候,一个产品或者服务尚未公开推向市场时,亚马逊已经在迭代的决策中,做出了最为符合市场预期的正确决策。
|
||||
|
||||
我必须说,这看起来就像一个神话。可是仔细想想,又尽在情理之中。我们要学习这条领导力准则,不但要理解其目的是尽量做出正确的决策,更需要明白:如何做才能达到这样的结果。
|
||||
|
||||
|
||||
|
||||
|
||||
70
专栏/技术与商业案例解读/019亚马逊领导力准则之客户至尚.md
Normal file
70
专栏/技术与商业案例解读/019亚马逊领导力准则之客户至尚.md
Normal file
@@ -0,0 +1,70 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
019 亚马逊领导力准则之客户至尚
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天我要介绍的这条领导力准则是“客户至尚”,其官方解释是:
|
||||
|
||||
|
||||
领导者从客户入手,再反向推动工作。他们努力工作,赢得并维系客户对他们的信任。虽然领导者会关注竞争对手,但是他们更关注客户 。
|
||||
|
||||
|
||||
“客户至尚”是亚马逊最为重要的行事原则。亚马逊的创始人贝佐斯曾在公开场合多次强调客户的重要性,并将其列为最基础的工作准则。换句话说,如果与其他准则相悖,则优先遵循“客户至尚”准则。
|
||||
|
||||
为什么贝佐斯将这条准则视作第一准则?如果你也不太清楚,2017年7月贝佐斯在给股东的年度公开信中再一次强调了“客户至尚”的重要性,或许你能从中一窥究竟。
|
||||
|
||||
公开信里大体是这样说的:
|
||||
|
||||
|
||||
有很多方法可以成为做生意的核心。企业可以以竞争对手为核心,也可以以产品为核心。企业还可以聚焦于技术,或者以业务模式为核心等等。但在我看来,以客户为中心是最为有利的方式。
|
||||
|
||||
为什么呢?以客户为中心的方法有很多优点。其中很大的一个优点是:客户总是非常不满足。即便他们说他们很满足,公司业务很好。客户总是想要更好的东西,甚至他们都没有意识到这一点。遵循着让客户满意的意图将驱使企业代表客户去发明和创造。没有客户曾经要求亚马逊创建Prime会员计划,然而我们发明了这项服务。最后确实证明客户是想要这个计划的。类似这样的例子,我可以列举很多。
|
||||
|
||||
|
||||
这封信里提到了亚马逊的Prime会员,这是一项定价95美元的年收费服务项目。这一项目的性价比很高,用户可以享受到包括免费隔日送达货物、免费视频等多项便利服务。
|
||||
|
||||
该项目在初推之时,亚马逊内部并不是一片和谐,很多人都提出了反对意见。反对Prime会员计划有很多原因,其中比较重要的有两点。
|
||||
|
||||
|
||||
第一点是这个计划成本昂贵。亚马逊做这个生意,非但不能赚到钱,还可能赔进去很多钱。比如说隔日免费寄送这项服务,用户每年只要下4单,邮费就超过95美元了。如果用户购买较多,亚马逊就会赔本。
|
||||
第二点是这一项目需要收取年费,用户是否愿意为此买单,也是未知数。万一投入大量成本去开发,用户却不买账,那么会前功尽弃。
|
||||
|
||||
|
||||
贝佐斯在推行项目之初,问了团队一个问题:“如果你是客户,是否愿意掏钱去享受这种服务?” 如果回答是肯定的,那么哪怕亚马逊会为此付出许多代价,甚至不能短期获利,这项服务也值得推出。
|
||||
|
||||
急客户所需,想客户所想,才是“客户至尚”的基本体现。坚持这样的理念,客户便会越来越愿意在亚马逊上消费,最后的规模效应才会形成良性循环。团队的回答当然是正面的,于是项目得以顺利推行。
|
||||
|
||||
事后的发展印证了贝佐斯的想法。Prime会员制度推行之后,亚马逊上的购物量迅速增加,亚马逊的会员们对两天内送达这一服务表现出极大的热情。因为制度的推出,亚马逊迅速战胜了eBay和沃尔玛这样的传统零售商。
|
||||
|
||||
亚马逊固然没有从邮费上赚到钱,但其规模效应带来的收入却远远大于在邮费上的支出。这种规模效应的结果是:亚马逊的各方面都得到提升,客户对亚马逊的忠诚度也极大地提高了。
|
||||
|
||||
贝佐斯多次引用这个故事,告诉员工,也告诉亚马逊的客户与投资人,“客户至尚”这一准则对于亚马逊到底意味着什么。
|
||||
|
||||
贝佐斯表示,在创新的时候,是不是真正以客户为中心,这一点至关重要。否则,所谓的发明创造必然会陷入对成本的计较和对利益的追逐,当这些成为创新的目的,客户也就不可能发自内心地满意了。
|
||||
|
||||
没有了客户支持的企业,即便短期内可以获得高利润,也不可能长久。换句话说,是不是真的对客户好,客户不是傻瓜,有鉴别能力的。
|
||||
|
||||
在美国各行各业里,创新并非为客户服务的例子有很多,将赚钱作为第一企业要义的案例也不胜枚举。
|
||||
|
||||
美国有一家非常有名的生物制药厂商吉利德科学公司(Gilead Sciences),以生产抗病毒药物著称,艾滋病的“鸡尾酒疗法”治疗药物就出自这里。这家厂商发明了一种可以彻底治愈丙型肝炎的药物,这在抗病毒技术上是一个极大的突破,在此之前,丙型肝炎最多也只能控制而不能被彻底治愈。
|
||||
|
||||
然而,人们对于这家企业一直有顾虑,他们不知道到底要花多少钱才能获得治疗。因为在美国的制药业里,新药开出天价来,是非常常见的敛财方式。所以在这个药出来之前,就有人觉得定价会很高,比如高达3万美元。
|
||||
|
||||
然而大家还是低估了这个数字。药价公布的时候,七万五千美元一个人的治疗费用,不但吓坏了“吃瓜群众”,也吓坏了媒体和保险公司。
|
||||
|
||||
这种高价“敛财”的手段甚至惊动了美国国会议员调查其企业定价的合理性。一些第三世界的国家,比如印度,看到如此高昂的价格,干脆就不想搭理这家企业,自己开始仿制药物。
|
||||
|
||||
最后的结果是,这家企业并没有获利很多,因为世界各地都在仿制这个药物。而且,很多得了丙肝却非特别严重的人,也不愿意花那么一大笔钱去治疗。我想,这就是一个非常典型的,不以客户为中心的例子。
|
||||
|
||||
“以客户为中心”并非放之四海而皆准的真理,但是在贝佐斯的观念中却是如此。贝佐斯要求他的每位员工,无论何时都必须将这条领导力准则执行到实处。这造就了亚马逊“客户至尚”的服务理念:任何事情只要是对客户有利的,哪怕暂时牺牲企业的一些收益,也应该去做。
|
||||
|
||||
外界对于亚马逊推崇的以客户为中心的这条准则并非没有争议,因为极端地以客户为中心,完全可能牺牲掉企业的全部利益。外界对其各种揣测,说到底拿不准的恰恰是这个度。
|
||||
|
||||
我们经常可以看到各种各样的讨论,不能否认,这种讨论有它合理的一面。在我接触到的亚马逊内部人员中,也有人心存困惑。在他们实际的工作中,以客户为中心这一服务准则的具体界限十分难以判断。但是,相信贝佐斯自己心中是有界限的,只是这个界限,并不容易表达。因此,他人是否真正能够做到通晓“客户至尚”准则,就要看各自的悟性了。
|
||||
|
||||
|
||||
|
||||
|
||||
61
专栏/技术与商业案例解读/020亚马逊领导力准则之勤俭节约.md
Normal file
61
专栏/技术与商业案例解读/020亚马逊领导力准则之勤俭节约.md
Normal file
@@ -0,0 +1,61 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
020 亚马逊领导力准则之勤俭节约
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天我要说的一条亚马逊领导力准则是“勤俭节约”,其中文官网解释为:
|
||||
|
||||
|
||||
力争以更少的投入实现更大的产出。勤俭节约可以让我们开动脑筋、自给自足并不断创新。增加人力、预算以及固定支出并不会为你赢得额外加分。
|
||||
|
||||
|
||||
这条领导力准则对于我们中国人来说非常熟悉了,通俗一点讲就是“勤俭致富”,用尽可能少的投入获得尽可能多的产出。对于高调宣扬勤俭的亚马逊来说,这条领导力准则确实表现不俗,这里我引用两个例子。
|
||||
|
||||
第一个例子是价廉物美的亚马逊电子商务。它的核心就是如何降低成本,从而尽可能地降低物价,来给广大用户提供实惠。
|
||||
|
||||
打个比方,亚马逊在美国是物流做得最好的公司,但是其做物流的原因之一,是公司认为物流做好了才能够做到“节俭”,才是真正的勤俭节约。
|
||||
|
||||
而做到了勤俭节约,自然就有可能做到价廉物美,从而让公司销售上台阶,让用户也得到实惠,形成非常良性的循环。
|
||||
|
||||
第二个例子,我想说说亚马逊目前最红火的、全球最牛的云计算。很多人都知道亚马逊的云计算牛,很多人都提到这种“牛”体现在了技术上,但亚马逊公认的“牛”有一点就是对成本的控制。
|
||||
|
||||
怎样做到既可以提供同等的虚拟化计算能力,同时又使自己消耗的物力资源最少,这个事情上只有亚马逊在多年如一日地努力。其结果就是,亚马逊的云计算平台相比其他厂商价格都更便宜;而更牛的是,虽然价格比别人更低廉,但是盈利却比别人多。能够做到这种程度的勤俭节约,不是一般公司可以轻易与其竞争的。
|
||||
|
||||
勤俭节约这条领导力准则的实行,当然也并非没有争议。
|
||||
|
||||
首先,其工作环境无法与其他公司类比。比如,谷歌和Facebook等很多IT企业都为员工提供了很好的午餐、晚餐、饮料等福利,而微软虽然不提供午餐、晚餐,但饮料起码是免费的。相较之下,亚马逊只提供很普通的水和咖啡,其他任何东西都要花钱购买。
|
||||
|
||||
有人会说,这其实不是真的勤俭节约,因为只有福利好了,员工才更愿意努力干活,形成良性循环。这到底是不是一种合适的勤俭节约方式,无论在亚马逊内部还是外部都存在争议。
|
||||
|
||||
相较于办公环境,仓库里面的勤俭节约争议性更大。曾有报纸报道,亚马逊在宾夕法尼亚州的仓库里没有安装空调,并因此导致了一次工人热晕,然后被送医院抢救的事件。此事之后被各大媒体争相报道,并受到了美国政府部门的控告,最后亚马逊不得不花钱在仓库里装上了空调。
|
||||
|
||||
此外,为了贯彻勤俭节约的准则,亚马逊还经常会研究公司在哪里成本高了,以及怎样能节约。
|
||||
|
||||
有人就发现,招聘本身就是一个非常耗费资源的事情。比如说,招人时会让这个人飞过来面试,还要提供酒店住宿,但是面试很多个人也许只能招进来一个,这让亚马逊的面试成本一直居高不下。再加上亚马逊非常高的人员离职率,如何降低招聘成本自然成了一个需要考虑的问题。
|
||||
|
||||
不知何时起,对于应届毕业生的招聘,亚马逊不再需要让人飞过来,而是先在网上做几个测试题,合格后再和招人的领导视频聊半小时,就可以了。这种招聘方法一推出,就受到了亚马逊领导们的表扬,毕竟能够迅速地节省招人成本,是一件很好的事情。只是慢慢地,弊端就开始显现了:这样招来的人很多是干不来活的,并不符合实际需求。
|
||||
|
||||
在节省成本上,亚马逊还有一个争议更大的行为。在美国,除非是开除,否则要辞退一个人的话,一般还要象征性地给几个月工资。而且美国的公司在开人上一向比较谨慎。那么,在这方面亚马逊又是怎么做的呢?
|
||||
|
||||
它创新地采用了一个早就有的办法:员工绩效提高计划。
|
||||
|
||||
这个计划的基本思想是,员工表现不好就要放到一个绩效提高计划里去,如果表现还是不行就要辞退了。在美国的公司里,亚马逊是对绩效考核计划用得最频繁的,无论其原意为何,这都为其“开人”降低了成本,也避免了公司按照惯例必须发离职包裹的情况。
|
||||
|
||||
当招聘的创新和绩效考评计划结合起来的时候,问题就来了。在亚马逊,有一段时间一个人入职还不到3个月,就可以被领导放进绩效考核计划。这件事情对于刚从学校毕业的大学生们来说,绝对是巨大的挑战。
|
||||
|
||||
于是有人想不开,跳楼了,万幸跳楼的人并没有死。但是事情闹大了。
|
||||
|
||||
被放入员工绩效提高计划的员工可能确实是不合格的,但是这也恰好暴露了招聘程序从简的弊端,即人员筛选不到位。而随后的绩效考核计划,又来得太早,两者相加共同导致了跳楼的悲剧。我们是不是可以说,这也是“节俭”导致的问题呢?
|
||||
|
||||
从实际情况来看,“节俭”这个领导力准则,让亚马逊在方方面面上都考虑成本问题。这种执着于不断优化和降低成本的态度,让亚马逊的很多东西都非常得价廉物美,这不仅仅对用户是好事情,对亚马逊占领更大的市场显然也是好事情。可以说,“节俭”在很大程度上促成了亚马逊的发展,给亚马逊带来了更多的客户。
|
||||
|
||||
但是,我们也能看到很多问题,而争议比较多的事情更多地发生在对待员工方面。员工本身很多时候都希望拥有很好的福利,而且不需要为工作以外的事情烦心。很多公司也都相信,好的福利有助于员工更好地工作和创造价值。但是在亚马逊里面,因为勤俭节约这个领导力准则,员工的福利成本同样被节约了。这其中的利弊,值得你我每个人深思。
|
||||
|
||||
然而不管怎样,勤俭节约的亚马逊给我们带来了方便的物流、便宜的货物和服务,价格优势是亚马逊战胜线上线下竞争对手的利器。而勤俭节约,对于亚马逊获得今天的市场地位同样功不可没。
|
||||
|
||||
|
||||
|
||||
|
||||
76
专栏/技术与商业案例解读/021亚马逊领导力准则之主人翁精神.md
Normal file
76
专栏/技术与商业案例解读/021亚马逊领导力准则之主人翁精神.md
Normal file
@@ -0,0 +1,76 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
021 亚马逊领导力准则之主人翁精神
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天我要介绍的一条领导力准则是“主人翁精神”,其官方解释是:
|
||||
|
||||
|
||||
领导者是主人翁。他们会从长远考虑,不会为了短期业绩而牺牲长期价值。他们不仅仅代表自己的团队,而且代表整个公司行事。他们绝不会说“那不是我的工作”。
|
||||
|
||||
|
||||
主人翁精神其实是一个老生常谈的话题。但是在亚马逊的领导力准则里,主人翁精神有比较明确的定义。简单来说,是两个方面:
|
||||
|
||||
|
||||
在长期利益和短期利益面前,要从长远考虑,不能因为短期利益杀鸡取卵,牺牲长期利益;
|
||||
在小团体和公司的整体利益面前,要代表整个公司的利益,而不是小团体的利益。
|
||||
|
||||
|
||||
细化成这两条内容之后,亚马逊的主人翁精神也就显得比较清晰具体了。
|
||||
|
||||
一、长期利益与短期利益
|
||||
|
||||
先看一下第一条,即长期利益和短期利益之间的关系。对此你应该并不陌生,我们的老祖宗早就已经用“杀鸡取卵”来形容这种做法了。但是不可否认,现实社会里杀鸡取卵的现象比比皆是,要做到为了长期利益去牺牲短期利益,是非常艰难的。
|
||||
|
||||
为什么会这样呢?其实很简单,因为人终究是利益驱动的,短期利益变现容易,而长期利益显得虚无缥缈。
|
||||
|
||||
从企业经营的角度来看,如果一项投入需要企业长期赔钱,即使未来一定会赚钱,这种投入对于很多企业来说也都是不切实际的。赚不到钱,可能直接就意味着破产,所以企业一定是要获得短期盈利,才能考虑长期发展的,这是做企业的正常逻辑。
|
||||
|
||||
当然有些企业已经有了可持续盈利的业务,所以可以拿出一部分盈利资金去投资未来可能带来收益的新领域,然而这依然没有摆脱企业坚持“短期利益为主,长期利益为辅”的路线。至少在亚马逊之前,我从来没见过一家企业不担心盈利问题的。如果盈利不好,那么股票就不好看,股票不好看,大家的日子也就不好过了。
|
||||
|
||||
这种做企业的“正常逻辑”在贝佐斯看来却并不正确。贝佐斯认为,企业就需要集中关注长期利益,而不应该为短期利益所左右,每个雇员作为企业的主人翁,都应该为企业的长期利益服务。所以,如果我们去看亚马逊的盈利模式,它长期十余年如一日不赚钱,每次有了钱之后就投入到新的领域里面去,这是一般人不能理解的企业经营模式。
|
||||
|
||||
在贝佐斯看来,如果一项投入是长期有意义的,那么五到七年不赚钱并不是问题,无法赚钱而导致公司股票短期内很难看,更不是问题。因为最终投资人会发现,集中精力去服务长期利益所带来的效益,将远远超过短期效益。
|
||||
|
||||
由于秉承这样的理念,一段时间里,华尔街并不看好亚马逊,他们的股价一度表现得不尽人意。然而随着亚马逊的长期效益不断体现,这种理念现在得到了投资人越来越多的肯定。
|
||||
|
||||
二、公司利益与团体利益
|
||||
|
||||
主人翁精神的第二条,要求每个员工代表整个公司的利益,而不是某个小团体的利益。这一点相对来说会好理解一些。
|
||||
|
||||
贝佐斯最不喜欢的就是湖对岸的老牌软件帝国:微软。在他看来,这个帝国里部门间各自为政,相互坑害,并不能为公司的整体利益很好地服务。
|
||||
|
||||
在某次采访中,贝佐斯说过早年他透过办公室望向外面的华盛顿湖,想着自己的公司如何才能避免重蹈湖对岸那家公司以及其他无数大公司的覆辙。
|
||||
|
||||
他能想到的,就是公司的每个员工在考虑问题时,都关注整个公司的利益,而不是只关注自己这个小团体的利益。他认为,部门之间不应该为小团体利益而互相倾轧。
|
||||
|
||||
主人翁精神就意味着,一个项目的主导者,不但要解决自己组内的问题,也要解决所有依赖关系中存在的麻烦。为了项目的推进和公司的整体利益,部门的局限不应成为一个人不推动项目前进的借口。
|
||||
|
||||
同样的,如果为了一个项目需要不同组织之间协调把事情做好,这个项目里涉及的所有人都要努力配合把事情解决好。大家都是为了公司整体利益、长期利益服务,而不是为了某个部门的小团体的利益服务,基于这个前提,没有解决不了的问题,只有不正确的解决问题的态度。
|
||||
|
||||
贝佐斯认为,只有所有的人都在为公司的整体利益服务时,才可能避免官僚主义,避免自己的公司最终成为湖对岸那个臃肿而又内耗严重的公司。
|
||||
|
||||
亚马逊一贯以来以执行力著称,任何事情在亚马逊里面推动,并不会受到莫名其妙的阻力。没有任何组织和个人可以以“这个事情是我的,不是你的”为由来阻止事情的推动。这些都是主人翁精神的体现。
|
||||
|
||||
当然,利益驱动始终都是组织和个人行动的基础,我们不能否认利益驱动的作用。如何构建一个合理的利益驱动体系,从而使大家都自觉地做主人翁,是这条领导力准则里面非常重要的一环。我想贝佐斯肯定反复思考过可行方案,最后才决定这样做。
|
||||
|
||||
既然是主人翁精神,那么个人所得必然和公司业绩的发展密切相关。而能够体现这种相关性的,首先必须是股票。公司业绩好了,股票价格上扬,所有的“主人翁”都应该受益,反之亦然。
|
||||
|
||||
基于这样一条原则,贝佐斯建立的薪酬体系和理念与很多公司都不一样:在亚马逊,现金作为整个薪酬体系的一部分,只占到了很低的比例;与之相反,个人股票在整个薪酬体系里占据的比例很高,对于亚马逊的高管来说,这个比例尤其高。
|
||||
|
||||
比如,贝佐斯自己只拿16万5千的现金,在众多CEO中这个比例不是一般得低,基本上可以说只有很多CEO的10%。这种做法为整个亚马逊的人员设置了一个现金上限。
|
||||
|
||||
在这样的薪酬体系设置下,一个人能够获得的收入和股票的价格就密切相关了。所以大家为了公司的长远利益和整体利益去考虑,公司的股票自然就会涨,进而会让每个人的收入增加。这种强调股票的重要性和比例的薪酬体系,可以说是亚马逊首创。
|
||||
|
||||
从实际结果上看,亚马逊的股票从2009年经济危机以来,现在已经涨了不止10倍。那些当年拿着股票的人,如果没有把亚马逊的股票卖掉,时至今日也是衣食无忧了。
|
||||
|
||||
贝佐斯认为,正是这种薪酬体系,把每个人的收益和公司的成长紧密地绑在了一起。这种方式会让人更加注重长期利益、整体利益,而不是局部利益、短期利益。这无疑是很聪明的一种做法,也是贝佐斯提出的主人翁精神对企业发展贡献的最直观体现。
|
||||
|
||||
理解主人翁精神在亚马逊里是如何指导企业发展和每个人的日常工作的,这对于理解亚马逊很多独特的企业文化与特质,都有着至关重要的作用。
|
||||
|
||||
|
||||
|
||||
|
||||
65
专栏/技术与商业案例解读/022亚马逊领导力准则之选贤育能.md
Normal file
65
专栏/技术与商业案例解读/022亚马逊领导力准则之选贤育能.md
Normal file
@@ -0,0 +1,65 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
022 亚马逊领导力准则之选贤育能
|
||||
能用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天这条亚马逊领导力准则值得我们仔细分析和研究,它就是“选贤育能”,其中文官网解释为:
|
||||
|
||||
|
||||
领导者不断提升招聘和晋升员工的标准。他们表彰杰出的人才,并乐于在组织中通过轮岗磨砺他们。领导者培养领导人才,他们严肃地对待自己育才树人的职责。领导者从员工角度出发,创建职业发展机制。
|
||||
|
||||
|
||||
亚马逊的招聘原则和很多公司不太一样。贝佐斯认为,新员工的加入应该有助于提高亚马逊员工的整体素质,新员工的水平需要高于整体员工的平均水平,只有这样亚马逊的员工素质才会越来越高。
|
||||
|
||||
贝佐斯在接受采访时曾经说过,那些上一年加入亚马逊的人应该为自己感到庆幸。因为如果晚一点来面试,他们很可能无法加入亚马逊。
|
||||
|
||||
简单来说,亚马逊招聘的都应该是最杰出的人才,这一点体现了这项领导力准则的核心思想。在亚马逊,一个员工只有是真正优秀的人才,才能在各岗位的轮岗中生存并且更好地发展。
|
||||
|
||||
亚马逊领导的职责是把这种“选拔天才”的思想,贯彻到每个方面,为优秀的人才创造最合理的职业发展途径。相反,那些并不优秀的人才,又无法在整体环境中得到提升的,随着亚马逊整体素质的渐渐提高,只能被淘汰。
|
||||
|
||||
亚马逊最初进行招聘的时候,贝佐斯严格审查了每一个被雇用的员工,他自己来拍板,来做是否聘用的决定。随着公司规模的扩张,这种办法变得不切实际。但是,贝佐斯在无法亲力亲为的时候想出了一个办法,他找到一群和他保持同样观念的人,然后让这些人按照他的标准参与面试做好把关。这就是亚马逊面试里面特别有特色的Bar Raiser。
|
||||
|
||||
这种做法,无形中拔高了面试的难度。在亚马逊的面试过程中,这些代表了创始人的面试官有很大的权限,包括可以一票否决整个面试结果。而且他们参与的面试,代表的是整个公司,他们并不对某个特定的组负责,只对公司负责。
|
||||
|
||||
这种做法的主要优点在于,这群人在客观上保证了面试选拔的是最优秀的人才。当然这种选拔并不是没有代价,有时甚至还很严重。比如说因为这种选拨机制,一个人有特定的专长,但综合素质不是太高,很有可能就无法进入亚马逊。因此,如果一个特定的组需要有技术专长的人,很快就会陷入有人却招不进来的状态。
|
||||
|
||||
Bar Raiser既然有这么重要的权力,要想成为一个Bar Raiser自然是非常不易的事情。不管是不是经理,他必须是各方面都非常优秀,并已在公司里面工作多年。除此之外,他需要充分理解创始人的选人标准,能够严格执行公司的招聘原则。所以在亚马逊,如果一个人可以成为一个Bar Raiser,是一种很大的荣誉。
|
||||
|
||||
Bar Raiser的一票否决制度,也决定了很多时候Bar Raiser会和招人的经理产生冲突,这就非常考验这个人是不是能够在压力面前真正代表公司,为公司招聘到合适的人选。
|
||||
|
||||
我认识很多亚马逊的人,包括在亚马逊里面做经理和总监的人,他们都抱怨过这条制度带来的弊端:招人不容易。在亚马逊,如果一个组刚成立,这时招人是相对容易的。因为很容易招到高于组内平均水平的员工。
|
||||
|
||||
但如果是一个在亚马逊已存在多年的工作组,组内本身已有了很多水平很高的人。在此基础上,要招聘一名高于平均水平的新员工,符合条件的候选人不会很多,而在这些本就不多的人里,通过层层筛选并且成功加入的,这个比例就更少。
|
||||
|
||||
在这种情况下,招人的经理如果严格按标准去做,就会面临无人可招的尴尬局面。而如果不严格执行标准,又违背了这条重要的领导力准则。
|
||||
|
||||
当然,“上有政策,下有对策”。有的领导者把平均水平的考量放到更大的环境下评价。如果说原来是在小组内测评,现在就直接讨论这个人进来对大组的平均水平的影响。所以实际上的问题是,在亚马逊里那些成名的大组,人才济济的,招人对于领导者的挑战非常大。这无疑是这条领导力准则带给领导者的烦恼。
|
||||
|
||||
那么这个制度是否执行得一切顺利呢?如果果真如此,那么现在亚马逊必然网罗到了世界上最优秀的人才,员工的平均水平与日俱增。
|
||||
|
||||
然而,实际情况却是,大家对亚马逊的评价更多集中在领导层面的战略眼光和执行力上;而一旦我们将目光聚焦到普通员工这一层面,大家通常都会认为谷歌、Facebook的基层人员在素质上要强于亚马逊。这又是为什么呢?
|
||||
|
||||
贝佐斯百密一疏,他没有考虑到优秀人才是会离开的,业务的扩张需要更多的新人补充进来。那么在这一走一留之间,是不是会产生一些问题呢?答案是肯定的。
|
||||
|
||||
因为亚马逊的领导力准则要求,不但要选拔最优秀的员工,而且这些最优秀的员工被招聘进来之后,在内部还需要面临非常严苛和高标准的竞争和培训。
|
||||
|
||||
我们可以想象,作为一个刚从学校毕业,初入职场的人来说,有很多的东西要学。这个时候直接被投入到高标准严要求的环境里,对很多人来说挑战过于巨大。因此进入亚马逊的人,在进去的前18个月离开的比例相当高,而且这个比例比全美国大部分互联网企业都高。
|
||||
|
||||
然而占据亚马逊底层员工主力的,很多就是这样一些入职不到18个月的员工。整体来说,这个标准不一定适用于衡量基层员工的质量,因为亚马逊里面一些有经验的人离职了,这导致整体队伍的质量自动下降了。招到高于平均水平的新员工,也不能弥补更为有经验更为优秀的老员工流失带来的问题。
|
||||
|
||||
不过,如果我们把这条标准提高一些,去衡量那些在亚马逊工作多年以上的,或者说级别较高的人的素质,会发现亚马逊的中高层领导鲜有庸才,更不用说是尸位素餐的人了。
|
||||
|
||||
中高层领导者素质高的原因是,亚马逊业务扩张非常迅猛,每天都有新的挑战出现,这就促使了新职位的产生。所以那些优秀的员工很大程度上被公司内部消化,在其中磨砺得更为出色,从而成为杰出的中高层领导者。而且相对于基层的流动性,亚马逊的中高层领导者的流动性就不是那么大了。
|
||||
|
||||
亚马逊领导力准则之选贤育能就介绍到这里。贝佐斯对于亚马逊员工的要求是每招进来一个新员工,都要在公司已有员工的平均水平之上。早年贝佐斯亲自参与招聘,后来公司也通过Bar Raiser来代表贝佐斯来完成亚马逊的招聘。
|
||||
|
||||
应该说这个领导力准则的初衷是非常好的,但是实际执行的时候则喜忧参半。一方面是这条严苛的制度会导致中低层的员工无人可招,所以就导致上有政策下有对策。另外一方面,人员会流失,优秀的人流失以后,这条制度并不能有效地保证员工素质不下降。
|
||||
|
||||
但是我们可以发现,主要的问题出在中低层的员工上,亚马逊的中高层领导者的素质的确是相当高的。亲爱的读者,如果你借鉴这条领导力准则招人的话,有哪些方面是你会吸取的,哪些方面是你觉得需要改变的呢?
|
||||
|
||||
|
||||
|
||||
|
||||
60
专栏/技术与商业案例解读/023亚马逊领导力准则之最高标准.md
Normal file
60
专栏/技术与商业案例解读/023亚马逊领导力准则之最高标准.md
Normal file
@@ -0,0 +1,60 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
023 亚马逊领导力准则之最高标准
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天我要说的一条亚马逊领导力准则是“最高标准”,是一条与之前提及的“选贤育能”有联系的领导力准则。其中文官网解释为:
|
||||
|
||||
|
||||
最高标准
|
||||
|
||||
领导者有着近乎严苛的高标准 — 这些标准在很多人看来可能高得不可理喻。领导者不断提高标准,激励自己的团队提供优质产品、服务和流程。领导者会确保任何问题不会蔓延,及时彻底解决问题并确保问题不再出现。
|
||||
|
||||
|
||||
这条标准从字面上理解,有两个要点:
|
||||
|
||||
|
||||
领导者要有近乎严苛的高标准,并不断提高标准;
|
||||
领导人要确保问题不蔓延,及时解决而且使之不会再现。
|
||||
|
||||
|
||||
关于什么是“高标准”,贝佐斯给了我们一个评判的基准:这条标准需要在大多数人看来高得不可理喻。
|
||||
|
||||
既然对于大部分人来说,这种标准高得不可理喻,那么普通人肯定不是那么容易达到的。上次讲到,亚马逊就是要选拔最优秀的人才来为己所用,其实这两者是相呼应的:如果没有最优秀的人,也就无法实现最高标准。
|
||||
|
||||
此外,这条领导力准则更要求领导者不断提高这个本来就高到离谱的标准,因为更严苛的标准可以敦促团队为客户提供更优秀的产品、服务和流程。
|
||||
|
||||
在常人看来不可理喻的高标准之上继续推进,这对领导者和团队成员无疑都是巨大的挑战。虽然我们常说“天外有天”,但也必须承认:人力有穷尽。尽管如此,对高标准的推进依然不可或缺,因为这与人才的选拔、培训以及淘汰机制都密切相关。
|
||||
|
||||
当我第一次读到这个领导力准则时,确实是一种非常严苛的感觉,这需要是一群多么优秀的人才能满足这条领导力准则啊。
|
||||
|
||||
因此,起初我对亚马逊能不能够真正实施这条准则也是感到十分好奇。但亚马逊的市值在过去十年间翻了十倍有余,我想亚马逊在坚持最高标准这条准则上也是卓有成效吧。或许,正是因为亚马逊坚持了最高标准,所以才发展得越来越迅猛。
|
||||
|
||||
而这条领导力准则,或许也可以解释亚马逊基层员工流动率很高的问题。贝佐斯在接受采访时多次提到,他并不在乎亚马逊的高离职率。他认为,只有那些符合公司价值观、自身非常优秀,且能不断提高自己以跟上公司发展节奏的人,才能够长期留在亚马逊;那些因为各类原因无法跟上公司发展节奏的人,在公司的发展过程中被淘汰,其实也是正常的事儿。
|
||||
|
||||
在贝佐斯看来,一个公司要壮大,就需要用到在大部分人看来无法理喻的严苛标准,并在这样的标准上持续提高,以保证公司的持续发展。更新血液,保持进步,这或许就是亚马逊发展势头迅猛的一个原因。
|
||||
|
||||
这条领导力准则的第二部分,专门针对遇到的问题进行了阐述,是很明确的“三步走”程序:领导者要确保问题不会蔓延,要及时解决问题,要确保问题不会再现。我觉得,这种方法非常高明。
|
||||
|
||||
|
||||
在问题发生之初,及时控制问题,使之不蔓延是非常关键的一步。如果我们对于云计算和互联网服务有实践经验的话,但凡出现问题,第一步都是先止血,而不是先追究问题的根源。这种原则同样适用于公司管理,概括来说就是:有问题,先止血,确保问题不蔓延。
|
||||
保证问题不蔓延的基础是解决问题。解决问题的方式五花八门,然而都离不开对问题的快速定位和反应。之所以这部分内容会出现在这项准则里,我的理解是问题的出现和解决,与标准的执行密切相关。越是严苛的标准就越容易避免问题;而问题出现以后能否迅速反馈,也体现了是不是有一套严苛的标准和成熟的问题解决方案存在。 然而我们都知道,当问题出现,尤其是复杂问题出现的时候,无论是控制它,还是迅速解决它,其实都是非常有挑战的事情。此时,标准和流程很大程度上决定了能否有效并迅速地诊断出问题在哪、如何解决。这种先控制问题,再解决问题的步骤,非常具有指导意义。
|
||||
最后一部分,是确保问题不会再现。如何才能保证问题不再出现?这需要深入分析、了解问题,获知出现问题的原因和内外部条件,找到制度上的疏漏、程序上的缺失,等等。这点其实和“决策正确”这条领导力准则密切相关,有异曲同工之妙。为什么这么说呢? “决策正确”是说在亚马逊,领导者可以偶尔错,但不能一直错,他们需要从一次错误里面吸取教训。没有人可以屏蔽问题,然而一个问题出现一次以后,亚马逊的领导者就应该有能力杜绝再发生同类问题。
|
||||
|
||||
|
||||
亚马逊的高标准体现在很多方面。举个例子,亚马逊AWS的存储服务S3在高标准的要求下,故障率比我们自己买一块磁盘存数据出故障的几率还要低。所以久而久之,用户默认S3是一个“永远都不会坏的东西”,根本不需要担心S3坏掉了应该怎么办的问题。
|
||||
|
||||
要在数目庞大的用户群中建立起“无故障”的印象,这意味着亚马逊要坚持十年如一日执行严格的标准,达到这一点可是相当不易。
|
||||
|
||||
但是很遗憾,亚马逊的S3在保持多年不坏的纪录后,终于还是出现了一次大面积的事故。一个程序员本来想关停一部分机器的服务,但是却关停了所有的服务。这次人为事故导致很多网站都无法访问。人们突然才意识到:原来S3也是可能出错的,原来“S3永远稳定”是潜移默化中形成的印象而已,他们在直觉上都把不可思议的事情当成了理所应当。这次事故让大家从这个状态里清醒过来。
|
||||
|
||||
然而正是因为这样,我才真正意识到,亚马逊在十余年如一日地稳定运行S3这个服务。这个在大部分人看来不可思议的事情亚马逊做到了。
|
||||
|
||||
按照亚马逊的这条领导力准则,S3这种问题出现一次以后,领导者就要采取措施避免同类问题再次发生。尽管我们还需要更多事实,来证明这条领导力准则真的被严格贯彻了,但我本人对此非常有信心。
|
||||
|
||||
|
||||
|
||||
|
||||
74
专栏/技术与商业案例解读/024亚马逊领导力准则之创新简化.md
Normal file
74
专栏/技术与商业案例解读/024亚马逊领导力准则之创新简化.md
Normal file
@@ -0,0 +1,74 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
024 亚马逊领导力准则之创新简化
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,而且可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天我要说的一条亚马逊领导力准则是“创新简化”,其中文官网解释为:
|
||||
|
||||
|
||||
领导者期望并要求自己的团队进行创新和发明,并始终寻求使工作简化的方法。他们了解外界动态,四处寻找新的创意,并且不局限于“非我发明”的观念。当我们开展新事物时,我们要接受被长期误解的可能。
|
||||
|
||||
|
||||
这条领导力准则主要由“创新”与“简化”两部分组成。具体来说,我们可以分解成下面几点:
|
||||
|
||||
|
||||
简化和创新是密不可分的;
|
||||
创新的时候不要受到局限;
|
||||
创新要接受长期被误解。
|
||||
|
||||
|
||||
在贝佐斯看来,创新的重要一步就是简化。假如创新产生了一个复杂的结果,这在创新刚起步时是被允许的;但如果在这种复杂的结果上停滞不前,就不是亚马逊所寻求的创新。
|
||||
|
||||
某位亚马逊前高管接受访谈时提到过这样一件事。在亚马逊网站成立初期,公司内部就如何为客户提供服务展开了讨论,讨论的主题是:亚马逊是否需要像传统零售商那样构建庞大的客服队伍?
|
||||
|
||||
公司内部觉得这种庞大的客服队伍不但消耗资源,而且不利于客户真正解决问题,所以亚马逊不构建庞大的客服队伍。亚马逊的创新理念是尽可能让一切自动化,从而达成简化工作的目的。
|
||||
|
||||
这种自动化体现在很多方面,比如在亚马逊的退货流程不需要客服参与,再比如在亚马逊上可以自动追踪货物的定位。这在今天的电商环境下司空见惯,但在亚马逊刚成立时绝对不是整个业界的主流解决方案。
|
||||
|
||||
这种方案的好处显而易见。
|
||||
|
||||
|
||||
首先,不需要客服,就降低了成本,亚马逊可以提供更加低廉的价格。
|
||||
其次,不需要客服,就没有了所谓的瓶颈,用户需要进行各种操作时,就不会因为联系客服而等待耽搁时间。因此,整个网站的吞吐量上升,亚马逊可以更好地服务客户。
|
||||
|
||||
|
||||
贝佐斯认为,不断简化,创造出更加简单的问题解决方式,才是创新的根本。任何创新,倘若无法让事情变得更简单、更自动化,就难免进入“为了创新而创新”的僵局。
|
||||
|
||||
这个观点其实非常值得深思。在创新或者强调创新的过程里,如何去判断创造出来的新事物是合理的?如果没有一些基本准则,难免陷入各执一词的状态。以“简化”作为创新的基本准则,是一个很有指导意义的做法。
|
||||
|
||||
亚马逊创新简化准则的另一部分,是要求员工可以做任何尝试,不局限于亚马逊内部的创意:任何好的想法,不论出处如何,只要它有益于亚马逊的发展,都可以拿来使用和尝试。这和微软的作风很不一样。
|
||||
|
||||
亚马逊的一位朋友告诉我,他从微软去亚马逊之后,明显感觉到了两家公司的很多差异。其中非常重要的一项是,当他尝试做一些创新的时候,在微软往往阻力重重,领导会问你这个创新是怎么来的,是不是符合微软的传统等等,在尝试之前他需要再三准备。
|
||||
|
||||
在亚马逊,这些从来不是问题。亚马逊鼓励创新、鼓励尝试,至于想法是外来的,还是内部诞生的,都不应该是阻止创新和尝试的理由。亚马逊的领导者鼓励每个人去创新,而且不愿创新是不符合领导力准则的行为,亚马逊并不喜欢这样的员工,也不鼓励这样的行为。
|
||||
|
||||
这条领导力准则还强调了一点:但凡是创新的东西,都可能在一段时间,乃至很长一段时间内无法让人理解。亚马逊认为这其实是很正常的,而且他们鼓励员工接受这种无法被外界理解的情况,并继续创新。
|
||||
|
||||
这种做法的好处是,亚马逊的员工可以不用局限在眼前的利益,能够做一些更加长远的、有变革性的创新。很多成功的创新不是小修小补,而是颠覆性的、变革性的,历史也告诉我们,很多时候“真理掌握在少数人手中”。如果说因为大众不能理解就停止创新,也就不会有颠覆性的变革出现了。
|
||||
|
||||
我曾经读过一篇亚马逊前高管写的文章,其中提到了亚马逊第一次从在线售书转向在线售卖家电的过程。在那个年代,只有大卖场里才能售出家电,因为每个人需要去现场触摸操作才愿意掏钱,毕竟家电和书比起来是一大笔消费。
|
||||
|
||||
那么在网上仅仅凭借几张图片和列表,能卖成家电吗?亚马逊内部的很多人心里都有这个疑问,这在二十年前也是很正常的反应。
|
||||
|
||||
亚马逊还是决定做了,不过在很长一段时间里,这种做法并没有客户买账。因为商品看不到也摸不到就寄到家里,客户总是有很多不安全感。家电生意在最初表现非常不好。
|
||||
|
||||
然而贝佐斯觉得,这其实是因为客户不理解创新。而创新,尤其是大的创新,一段时间内不被接受也是正常的。但如果因此就停止创新了,那才是真正的问题。
|
||||
|
||||
面对家电生意不成功一事,贝佐斯对他的队伍说,我们需要继续创新。
|
||||
|
||||
|
||||
首先,亚马逊专门对原本卖书的网站做了很多改动,包括在网站上提供从各个角度拍摄的高精度图片。
|
||||
其次,亚马逊构建了非常完备的货物追踪查询系统,让用户可以轻松查阅所购货物的位置。
|
||||
再次,亚马逊强化了退货体系,使网购产品和在店里买东西一样可以方便地退货。用户只要通过网上的服务,自助的生成包含运费的单据,就可以直接去邮局或者快递公司退货了,全程无需打客服电话,无需和亚马逊进行人工交流。
|
||||
|
||||
|
||||
久而久之,人们也渐渐发现了在线购买家电的好处:可以足不出户,而且物美价廉。亚马逊的家电售卖业务也就这样做了起来,而网购家电今天也早已不是一个让人存疑的问题了。但在亚马逊网上销售家电的整个过程里,我们可以明确地看到:他人对创新会存在误解,接受误解才能真正推动创新。
|
||||
|
||||
“简化创新”这条领导力准则就说到这里。亲爱的读者,你怎么看待创新和简化之间的关系呢?如果创新长期被人误解,你又能坚持下去吗?
|
||||
|
||||
|
||||
|
||||
|
||||
73
专栏/技术与商业案例解读/025亚马逊领导力准则之崇尚行动.md
Normal file
73
专栏/技术与商业案例解读/025亚马逊领导力准则之崇尚行动.md
Normal file
@@ -0,0 +1,73 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
025 亚马逊领导力准则之崇尚行动
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天我要说的一条亚马逊领导力准则是“崇尚行动”,其中文官网解释为:
|
||||
|
||||
|
||||
速度对业务影响至关重要。很多决策和行动都可以改变,因此不需要进行过于广泛的推敲。我们提倡在深思熟虑前提下进行冒险。
|
||||
|
||||
|
||||
贝佐斯认为对于业务来说,速度至关重要。有很多行动和决定,如果觉得是错的,在将来都是可以更改的。如果我们花费很多时间去研究、学习,可能因此耽误速度。而且很可能这一耽误,情况就发生了变化,让竞争对手跑在我们的前面,从而错失良机。所以经过适当考虑后,我们应该尽快采取行动,哪怕这些行动存有风险。
|
||||
|
||||
对于这条领导力准则,我们应该分三部分来看。
|
||||
|
||||
|
||||
速度对于业务的影响非常非常重要。很多时候业务错失良机,主要就是因为没有采取合适的速度。
|
||||
决定和行为都是可以改变的,只要行动足够快,就可以足够灵活。不要担心犯错,足够快了之后,犯了错也是可以迅速纠正的。
|
||||
冒险很有必要,尤其是在深思熟虑之后。在风险可控的情况下,冒险是非常有必要的。
|
||||
|
||||
|
||||
我们先看第一部分。我和亚马逊的朋友交流时得知,在亚马逊一个提案通常不会被反复讨论。哪怕这个提案还不明朗,大家甚至不知道最佳的执行方案,如果经过几轮论证,大家对比了风险和收益,觉得值得尝试,就会立刻转入执行阶段。
|
||||
|
||||
贝佐斯的名言是:速度就是一切。 能够迅速执行,本身就是成功的一个关键。
|
||||
|
||||
不可否认,现实中一些公司确实是在关键时刻通过深思熟虑来获得成功的,速度本身反而不是最重要的。但在互联网企业和电商的背景下,这种理念就容易理解了。
|
||||
|
||||
“反应迅速敏捷”有时正是特定行业成功的要义。互联网行业以前所未有的速度发展,任何新事物的出现到成熟,往往都远远快过传统行业。这条领导力准则首先就关注“速度”,因为一个企业能够迅速反应并行动,才是在互联网时代屡战屡胜的不二法门。
|
||||
|
||||
从这一点来说,我们必须承认贝佐斯领会到了互联网企业的精髓,并使其在亚马逊中传承。
|
||||
|
||||
亚马逊是一家非常崇尚实际行动的公司。在亚马逊里,“做出行动”重要无比,速度就是一切。所以一个方案能不能迅速从模拟讨论推进到具体实施,也是对亚马逊员工能力的一个衡量标准。
|
||||
|
||||
再来看第二部分,它是说在速度足够快的情况下,决策或者行动出现了错误可以纠正。只有执行了,你才能知道决策是正确的还是错误的,一开始讨论很多,也许并没有意义。具体来说,让市场告诉自己是不是犯错了,然后去纠正,是这条领导力准则很重要的组成部分。
|
||||
|
||||
我们放到整个互联网的大环境下来看。亚马逊作为一个互联网公司,其公布出来的产品的失败率非常低,而微软或者谷歌的产品失败率则明显高出一截儿。这是不是说迅速行动了,反而降低了错误呢?其实不是。
|
||||
|
||||
如果和亚马逊里面的人聊天就会知道,亚马逊会很快进入实施阶段,并在小范围内进行尝试。这种小范围的客户可能是内部的其他组,也可能是外部客户,而尝试的主要目的是迅速否定掉没有意义的错误想法和实现。我们看到亚马逊出来的产品成功率很高,其实是因为很多产品在实施阶段后就迅速夭折在内部了。
|
||||
|
||||
这种大量尝试,大量失败,然后纠正决策,继续前进的风格,是非常典型的亚马逊风格。 外面看见的失败率低,是以内部的大量失败为代价的。
|
||||
|
||||
然而我们应该清楚地认识到一点,一个产品迅速实施失败调整的成本,往往低于将一个产品反复论证后再拿出来,却发现重大缺陷的情况。所以从某种程度上来说,一个崇尚通过行动去证明对错,并能迅速接受反馈、调整行动的企业,本身是非常可怕的。
|
||||
|
||||
而这条领导力准则告诉我们,决策本身的正确性不是无比重要,我们应该提高速度多做尝试,要适当地减少论证。
|
||||
|
||||
第三部分同样值得深思,通俗点说就是:亚马逊鼓励冒险,但前提是心里有数。
|
||||
|
||||
这在某种程度上和“决策正确”这条领导力准则遥相呼应:犯错误是可以的,但是持续犯错误是不行的。领导者需要在大部分情况下保持决策正确。
|
||||
|
||||
换句话说,如果可以管理好风险,亚马逊鼓励冒险。
|
||||
|
||||
但是如何做到“管理好风险”呢?这既需要审视其他领导力准则的指导和对领导者的要求,又要深刻理解这条领导力准则里“行动比讨论更有意义”这一要义。
|
||||
|
||||
“风险管理”是每个领导者都需要思考的问题。亚马逊既然提倡行动力,那么在执行过程中如何能够迅速判断行动正确与否,并及时去纠正,其实又对领导者的其他能力提出了挑战。
|
||||
|
||||
我想,如何平衡“崇尚行动”和“思考的深度与广度”之间的关系,这是一个很大的挑战。
|
||||
|
||||
亚马逊领导力准则并不否定领导者的思维深度和广度,也未否定对决策能力的严格要求,而且明确表示任何决策都可能出错,所以无休止地讨论思索,还不如早点采取行动更为实际。
|
||||
|
||||
这些不同的要求放在一起,对于一个领导者的挑战是非常巨大的。能够做到这些的人,实可谓是领导者里面的精英了。
|
||||
|
||||
我经常想,如果这么多的要求加诸于我身上,我能做好吗?很难。人和人终究是不同的,每个人擅长的领域不尽相同,总有人更擅长严谨的思维,有人则能够从快速试错里面学习成长。
|
||||
|
||||
所以当你看待领导力准则的时候,不仅要理解亚马逊准则要求领导者如何去工作,更应该明白这个领导力准则其实更像是一个工具,用于筛选出贝佐斯需要的人才。
|
||||
|
||||
与其他领导力准则一样,“崇尚行动”这条准则罗列了亚马逊要的是什么,却没有说如何才能够做到。所以,我们需要结合自身的优缺点,以及已经学习的其他亚马逊领导力准则,去好好思考这样一个问题:亚马逊在找的到底是具备何种综合素质的一类人,这些人被亚马逊招进去以后,又会诞生什么样的企业呢?
|
||||
|
||||
|
||||
|
||||
|
||||
70
专栏/技术与商业案例解读/026亚马逊领导力准则之远见卓识.md
Normal file
70
专栏/技术与商业案例解读/026亚马逊领导力准则之远见卓识.md
Normal file
@@ -0,0 +1,70 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
026 亚马逊领导力准则之远见卓识
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
今天我要说的一条亚马逊领导力准则是“远见卓识”,其中文官网解释为:
|
||||
|
||||
|
||||
局限性思考只能带来局限性的结果。领导者大胆提出并阐明大局策略,由此激发良好的成果。他们从不同角度考虑问题,并广泛寻找服务客户的方式。
|
||||
|
||||
|
||||
这条领导力原则主要关注领导者的思维方式。贝佐斯要求领导者不拘泥于局限性的思考,要保持脑洞大开的状态。领导者可以从不同的角度去思考问题,发现别人不能发现的,想到别人不能想到的。这种远见对于一家公司的成长来说非常重要。
|
||||
|
||||
早在2004年,贝佐斯就开始思索一个问题:随着亚马逊业务的扩张,哪些企业会成为亚马逊最可怕的竞争对手?
|
||||
|
||||
请注意,这里使用了“最可怕的竞争对手”这样的表述,说明“普通的竞争对手”并不在贝佐斯思考范畴之内。这个问题在贝佐斯的脑子里徘徊许久,以至于他开始组织会议讨论这个问题。
|
||||
|
||||
当贝佐斯和他著名的S-team讨论竞争对手问题时,首先出现在讨论名单中的主要是包括BestBuy、Target在内的电商,当然也包括全球最大的连锁超市沃尔玛这样的传统零售企业。
|
||||
|
||||
这是大多数人的第一反应,S-team的人也不能免俗。然而在贝佐斯看来,这都属于局限性的思考。道理很简单,这种竞争对手,连一个亚马逊普通员工都能想到,作为杰出的领导层,其实根本不需要去关注。
|
||||
|
||||
贝佐斯认为,这些所谓的竞争对手,哪怕是最牛的沃尔玛,其实都会被亚马逊扫进历史的故纸堆里。毕竟传统的厂商们并不知道如何高效地进行经营和买卖,亚马逊的电商服务才代表了未来。
|
||||
|
||||
这样来讲,如果亚马逊最大的竞争对手还是他们,这不只是对自己缺乏信心,而是杞人忧天了。这显然不符合贝佐斯对亚马逊高管的要求,毕竟他对管理层要求非常严苛,肯定不会满足于只提供这类应答的领导者。贝佐斯对于S-team提出的竞争对手表示了不满,这不是他想要的答案。
|
||||
|
||||
这时,S-team中有人“脑洞大开”地提出了一家公司:谷歌。为什么说是“脑洞大开”呢?因为在2004年的时候,谷歌还远非如今这样知名。它作为一个搜索引擎提供商,虽然有全球最厉害的搜索引擎技术,但却一直专注于搜索引擎领域。
|
||||
|
||||
没有上市,又没有那么多钱,无论从什么角度来看,谷歌和亚马逊的电商都没有太多联系。如果一定要说有,谷歌和亚马逊更像是互补的关系,一个厉害的搜索引擎给亚马逊的用户提供了方便之门。正常的逻辑来说,这家企业其实有益无害。
|
||||
|
||||
S-team中的其他人望着提出想法的人一头雾水。只有贝佐斯像发现新大陆一样,让这个“脑洞大开”的领导者详细阐述他的看法。
|
||||
|
||||
这个人的看法大致上有这么几点。
|
||||
|
||||
|
||||
首先,搜索这个东西天然就具备了门户的特点,如果用户都使用谷歌去搜索要购买的产品,那么谷歌的导流作用就可以对亚马逊的业务产生实质的威胁。
|
||||
其次,谷歌在搜索的过程里面,掌握了大量的用户数据,这些数据足以让谷歌有效分析出亚马逊至关重要的商业机密。
|
||||
最后,谷歌作为需要给全球互联网提供搜索服务的公司,大规模计算和分析的能力非常强,所有的这些东西既为谷歌直接进入电商市场,提供了非常坚实的基础,又为谷歌给其他传统企业和电商提供增值服务,提供了非常有效的资源。也就是说,被谷歌技术武装起来的传统厂商们的杀伤力将不可忽略。若一时不慎, 亚马逊的根基都会被掀翻。
|
||||
|
||||
|
||||
至于谷歌会不会拿着这些技术和信息,自己进入电商市场,或者和其他企业结合,帮助其他企业一起发展业务对抗亚马逊呢?
|
||||
|
||||
这个问题其实很容易回答,谷歌的技术表明了这家公司的优秀水平,谷歌的扩展空间表明了谷歌一定会全方位出击,某天谷歌和亚马逊很可能会短兵相接。如果亚马逊不做好防范,对谷歌潜在的威胁视而不见,等到威胁真的发生时,在亚马逊购物的人已经严重依赖于谷歌的搜索功能了,亚马逊就很难有反抗之力,这显然会危及亚马逊的发展。
|
||||
|
||||
贝佐斯非常赞同这个“脑洞大开”的想法,尽管谷歌在当时看来那么人畜无害,它的搜索引擎又如此好用,帮助亚马逊获得了大量客户。但贝佐斯觉得,亚马逊网站对于谷歌的依赖性已经开始出现了,而有了这种依赖性,天知道会发生什么事情。于是,防范谷歌的威胁,减少亚马逊客户对谷歌的依赖,就成为了这次会议的决策。
|
||||
|
||||
在这个决策的基础上, 亚马逊开展了一项脱离谷歌的计划,这项计划的筹备长达数年。
|
||||
|
||||
|
||||
首先,亚马逊在它们的全资子公司A9上花了大价钱,A9的主要任务就是做亚马逊网站上商品的搜索和广告技术。 如果用户能够在亚马逊网站上方便地搜索想要的商品,就用不着额外使用搜索引擎了,所以提高自己网站的搜索能力是非常重要的一步。
|
||||
此外,亚马逊同时采取技术手段,避免搜索引擎随意抓取自己网站上的数据。 这样一来,谷歌这样的搜索引擎,就无法通过抓取为用户提供商品的精准数据,这也就杜绝了谷歌给亚马逊提供搜索的可能。 亚马逊觉得自己网站上商品的信息,有着重要的商业价值,如果搜索引擎可以随意获取到数据的话,无疑是把自己非常有价值的东西拱手送人,对于自家的长远发展是非常不利的。
|
||||
|
||||
|
||||
贝佐斯曾在内部将此事作为脑洞大开的例子提及。他认为,一个管理者只在舒适区内思考问题是不够的,管理者不应该局限自己的思维方式、角度和层次。
|
||||
|
||||
只有眼界足够开阔的管理者,才可能从不同的角度去思考问题,从而为公司的发展提供正确的决策和独特的竞争力。
|
||||
|
||||
这一点对于管理者的要求无疑非常高,因为每个人的思维都有局限性。能够脑洞大开走出思维局限的人,某种程度上不仅是一个管理者,更是具备很强创新能力的人,这在很多时候是种天分。
|
||||
|
||||
在我看来,这个世界上只有一个乔布斯,只有一个通过发明手机改变全世界的人,也只有一个苹果公司。
|
||||
|
||||
亚马逊要求领导者做到这些,却没有说明如何才可以做到。这也表露出贝佐斯的用人原则:我告诉你亚马逊需要什么样的人,如果你是,欢迎加入;如果你不是,无论是天资所限还是努力不够,那么也只能是无缘了。
|
||||
|
||||
这条领导力准则所提出的要求非常之高,并非是靠努力就能达到的。这也侧面反映了满足亚马逊领导力准则的不易。
|
||||
|
||||
|
||||
|
||||
|
||||
84
专栏/技术与商业案例解读/027亚马逊领导力准则之好奇求知与赢得信任.md
Normal file
84
专栏/技术与商业案例解读/027亚马逊领导力准则之好奇求知与赢得信任.md
Normal file
@@ -0,0 +1,84 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
027 亚马逊领导力准则之好奇求知与赢得信任
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
一、好奇求知
|
||||
|
||||
我在前面已经讲解了10个领导力准则,剩下的4个相对好理解一些,我分两篇文章来讲解,每篇讲两个。今天讲的第一个领导力准则是“好奇求知”,其中文官网解释为:
|
||||
|
||||
|
||||
领导者从不停止学习,并不断寻找机会以提升自己。领导者对各种可能性充满好奇并付于行动加以探索。
|
||||
|
||||
|
||||
我们大致上可以这样来理解这条领导力准则:
|
||||
|
||||
|
||||
持续学习,不断提升;
|
||||
对各种可能性都保持好奇心并且付诸行动。
|
||||
|
||||
|
||||
贝佐斯强调领导者要保持学习习惯,他自己就经常以身作则,不断进入新的领域展开新的业务。持续学习不仅是领导者的必备技能,从提高个人能力和素质的角度来说,它和不断提升一样也是每个人都应有的状态。
|
||||
|
||||
但是,持续学习作为一条对所有人都大有裨益的通用准则,在互联网公司里面尤为重要。互联网行业的技术和业务发展日新月异,你必须持续学习才能够跟上行业的发展,这对于每个互联网人都是一样的。以我个人经验来看,很多东西我不去接触,过个三五年就改头换面了,老旧的知识完全跟不上时代的需求。
|
||||
|
||||
“好奇求知”的第二部分又可以从两个方面来看,首先是充满好奇心,其次是要付诸行动。这就和其他亚马逊领导力准则相呼应了,比如说亚马逊要求领导者能够全方位、多角度地思考问题,从而做出决策,再比如亚马逊是一个崇尚行动高于讨论的公司,这两点在这条领导力准则上都有反映。
|
||||
|
||||
为什么行动比较重要?关于这一点,“崇尚行动”这条领导力准则可以给出启示。简单回顾一下,贝佐斯认为速度很重要,任何决定和行为,哪怕是不正确的,只要有速度,快速试错,是可以迅速纠正的。所以说,与其浪费时间细化决策,不如果断采取行动,这一点我觉得非常有道理。
|
||||
|
||||
充满好奇心又是对行动力的补充,它使领导者并不只专注于目前行动的某一种可能性,而是对其他事项都保持热情和求知的态度。两者共同组成了贝佐斯对“好奇求知”的完整认识。
|
||||
|
||||
此外,“创新简化”这条准则,其实也是和充满好奇心相呼应的:创新离不开好奇心,只有保持好奇心才能够始终保持创新精神。
|
||||
|
||||
亚马逊领导力准则是一个统一的整体,组成部分间此唱彼和、相得益彰。一条准则里经常可以连带出其他准则的内容,所以我们不应该孤立地解读。
|
||||
|
||||
“好奇求知”要求领导者不断对外部世界进行探索,学习外在的知识,充实自己并付诸行动。但这还不够,亚马逊领导力准则中的“赢得信任”,还要求大家通过“批评和自我批评”来不断反思自身以及他人已经采取的行动,反省内在,自我提高。
|
||||
|
||||
二、赢得信任
|
||||
|
||||
今天要讲的第二个领导力准则就是“赢得信任”,其中文官网解释为:
|
||||
|
||||
|
||||
领导者专注倾听,坦诚沟通,尊重他人。领导者敢于自我批评,即便这样做会令自己尴尬或难堪。他们并不认为自己或其团队总是对的。领导者会以最佳领导者和团队为标准来要求自己及其团队。
|
||||
|
||||
|
||||
这条领导力准则可以解读为三点内容:
|
||||
|
||||
|
||||
领导者能够倾听,坦诚沟通以及尊重他人;
|
||||
领导者善于自我批评;
|
||||
领导者对于自己和团队都要有高要求。
|
||||
|
||||
|
||||
“赢得信任”这条准则的第一部分主要是沟通的态度和方式,“倾听”是很重要的一部分。 贝佐斯非常痛恨办公室政治,他有次开会时提到,每次站在自己的办公室窗口,望着隔湖相对的微软就在想:当自己的公司壮大了,绝不能成为湖对岸那个政治气氛浓厚的公司。
|
||||
|
||||
他理想的状态是:公司的每个人都是领导者,每个人都能够倾听别人,坦诚沟通,并尊重其他人的见解。只有这样状态下的公司,才是高效率、低内耗的,才能够实现更好的发展。
|
||||
|
||||
达到这种理想状态非常不易。但是,贝佐斯觉得人和人之间的信任非常重要,没有了信任,公司就容易滋生小团体,就会因为人员各怀鬼胎而分崩离析。微软在从一个小软件公司成长为全球最大软件公司的过程中,小团体的内斗已经上演了。贝佐斯肯定是对这种文化十分了解,所以才会多次极力表示,他所创立的企业,不应该存在这种病态。
|
||||
|
||||
而具体到领导者,要赢得他人信任并学会坦诚和尊重十分必要,要能听进别人的意见。这在贝佐斯的谈话中反复被强调。
|
||||
|
||||
第二部分是“自我批评”。 中华文化的传统美德里比较强调自我批评,这些东西对于我们来说可能是习以为常了,但西方社会更强调个人价值的实现。所以如果在美国待久了,一个人往往会呈现出一种“自我表扬”的状态,我在微软工作时对此就感觉十分明显。
|
||||
|
||||
在职场上印度人非常成功,其中一个原因也是他们比较擅长自我表扬。在美国职场上,奖励自我表扬,而不奖励自我批评是常态。贝佐斯会把自我批评放进领导力准则,这一点实在出人意料。
|
||||
|
||||
不过,仔细想来,贝佐斯的做法也在情理之中。一个擅长自我表扬的环境坏处是很明显的,每个人都在讲述自己的功绩,展现自己的成就,没有人去审视自己做的事情,反省自己做得是否合适。
|
||||
|
||||
这样一来,企业难免会浮躁,管理层也很容易变得张扬。这种问题不仅仅在初创企业中出现,在大企业中也同样存在。谷歌上市之后就有一段时间自我膨胀,妄图在各个领域同时出击,以至于后来全方位败退以后,才开始考虑自己到底擅长什么。这说明即便是优秀的企业,如果失去了自我反省能力,也是非常可怕的。
|
||||
|
||||
在西方思维的大环境下,贝佐斯依然将“自我批评”这点写进企业的领导力准则,实在值得敬佩,这说明贝佐斯对于西方传统文化里的弊端有着深刻的思考和见解。这些领导力准则造就了亚马逊,使它有别于很多典型的西方企业。从某种程度上来讲,亚马逊在很多方面的成功,确实是很多西方企业所没有达到的。
|
||||
|
||||
第三部分,其实是对其他领导力准则的重复了。简单来说,导者对自己也好对团队也罢,都应该执行最严格的标准,这一点在亚马逊得到了全方位的体现。 作为领导者,严格要求自己和团队,也是必不可少的基础内容。试想,若无法以最严格的标准去要求自己和团队,一个领导者怎么才能获得工作伙伴的信任呢?
|
||||
|
||||
“赢得信任”要求你学会倾听与沟通,要在自我批评和自我审视中寻求改进的可能性,并通过严要求获得同事、下属以及上级的信任。
|
||||
|
||||
总结来说,领导者需要有“好奇求知”的精神,和“赢得信任”的能力,他需要不断探索外部世界,不断学习提高并能够付诸行动,在“批评与自我批评”中不断反思和完善自己。
|
||||
|
||||
亲爱的读者,如果你是一位领导者,你是怎么做的呢?关于领导者应该具备的个人素质,你有没有想和大家分享的故事?欢迎留言探讨。
|
||||
|
||||
|
||||
|
||||
|
||||
87
专栏/技术与商业案例解读/028亚马逊领导力准则之刨根问底与达成业绩.md
Normal file
87
专栏/技术与商业案例解读/028亚马逊领导力准则之刨根问底与达成业绩.md
Normal file
@@ -0,0 +1,87 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
028 亚马逊领导力准则之刨根问底与达成业绩
|
||||
用亚马逊创始人贝佐斯自己的话形容,亚马逊领导力准则是这家公司取得如此辉煌成就的基石。认真学习这些领导力准则,不但有助于理解亚马逊的企业文化,也可以帮助我们分析亚马逊如何取得了这样举世瞩目的成就。
|
||||
|
||||
这篇文章是亚马逊领导力准则系列文章的最后一篇,我来讲最后两个领导力准则:“刨根问底”和“达成业绩”。
|
||||
|
||||
一、刨根问底
|
||||
|
||||
今天讲的第一个领导力准则是“刨根问底”,其中文官网解释为:
|
||||
|
||||
|
||||
领导者深入各个环节,随时掌控细节,经常进行审核,当数据与传闻不一致时持有怀疑态度。领导者不会遗漏任何工作。
|
||||
|
||||
|
||||
“刨根问底”这条准则可以从3个方面来理解:
|
||||
|
||||
|
||||
领导者能够深入各个环节,掌握细节;
|
||||
领导者经常进行审核,数据和传闻不一致时要有怀疑态度;
|
||||
领导者不会遗漏任何工作。
|
||||
|
||||
|
||||
首先是领导者能够做到深入各个环节并掌握细节,这一点字面上不是很难理解。掌握细节让领导者看问题不会浮于表面,而是能够深入下去。
|
||||
|
||||
在微软、 IBM这样的大企业,一名员工一旦成为经理,往往只注重高层面上的东西而不愿深入细节。主要原因有两个,其一是他们距离细节比较遥远,其二是他的上级乃至更上级的领导只需要看到宏观的东西。所以深入细节对于他来说,没有实际的奖赏。但是,这对领导者管理公司却未必是好事。
|
||||
|
||||
关于这一点,贝佐斯给大家树立了一个很好的榜样。在亚马逊,每时每刻都发生着各种事件,比如网站运行慢了,再比如某个功能无法使用了等等。只要是与公司相关的事情,贝佐斯总是事必躬亲地参与进来。比如,他本人经常会出人意料,随机进入一个在开的会议,或是亲自给人发邮件汇报或解释事情等等。
|
||||
|
||||
很多人会奇怪了,贝佐斯是怎么知道这么多事情的?从公开的渠道来看,主要有两方面原因。
|
||||
|
||||
|
||||
一方面是,公司内部大大小小的邮件列表,贝佐斯都在里面。贝佐斯喜欢时不时地随机查看某个邮件组里的邮件。
|
||||
另外一方面是,公司内部给贝佐斯写Email的渠道很畅通,贝佐斯(或者其秘书)总能在最短的时间内,知道公司内部发生的大大小小的异常事件。
|
||||
|
||||
|
||||
贝佐斯在很多场合都强调过,领导者不应只限于大局。无论是处于什么位置的领导者,都需要有深入细节、随时掌控各个环节的能力。只有这样,公司才能够良好运作。
|
||||
|
||||
这条准则的第二部分是对审核的严要求。 要知道,亚马逊内部完全数据化了,具体到打开网站需要多少时间,直至每个功能最多允许出现多少错误等等,量化的体系使亚马逊非常依赖数据去做决策。使用数据来做决策本身不是坏事,这起码好过拍脑门儿做决策的工作方式。然而用数据做决策,很多时候也会出现偏差。
|
||||
|
||||
数据出错的原因有很多,但无论是数据本身出错,还是说实际状态才是错误的,只要最终数据结果与实际状态不符,领导者就需要彻查。在亚马逊这样的状况经常出现,这就需要领导者时刻保持警觉状态。
|
||||
|
||||
因此,可以说对任何事物都保持谨慎和怀疑的态度,是领导力准则很重要的一点。
|
||||
|
||||
关于这个领导力准则的最后一部分,即“不会遗漏任何工作”,与之前提及的“最高标准”其实是一脉相承的。 一个领导者应该面面俱到,不遗漏任何东西,这其实是以极其严苛的、常人看来不可思议的标准去要求自己和团队的结果。
|
||||
|
||||
亚马逊领导力准则里除了提出领导者要深入细节,不遗漏任何工作的要求,也强调工作时要能抓住工作的关键决定条件,并以最终完成工作、达成业绩作为判断工作好坏的指标。深入细节,绝非眉毛胡子一把抓。
|
||||
|
||||
二、达成业绩
|
||||
|
||||
今天要说的第二个领导力准则“达成业绩”,恰好反映了亚马逊对领导者在这方面的要求。“达成业绩”的中文官网解释为:
|
||||
|
||||
|
||||
领导者会关注其业务的关键决定条件,确保工作质量并及时完成。尽管遭受挫折,领导者依然勇于面对挑战,从不气馁。
|
||||
|
||||
|
||||
从字面意思来理解其实非常容易,“达成业绩”简单来说就是最后把东西做出来,有一丝“以结果论英雄”的意味。做企业不是请客吃饭,最终是要为股东创造利润的。所以在亚马逊领导力准则里,最后一条就是强调任何领导者都应达成业绩。
|
||||
|
||||
以“结果”来说明一个领导者到底是不是合格,这在何时何地都是毋庸置疑的硬指标。
|
||||
|
||||
贝佐斯在这一条准则中,不仅提出了要求,而且深入探讨了如何做到达成业绩。这包括两个方面:
|
||||
|
||||
|
||||
关注业务的关键决定条件,确保工作质量并及时完成;
|
||||
面对挫折不气馁。
|
||||
|
||||
|
||||
第一部分谈及了达成业绩的关键:工作质量和工作速度。掌握两者间的平衡,其实是一门很大的学问。但凡有过大项目开发经验的人都知道,要求质量了,速度不一定能上去,速度上去了,质量可能又会是问题。所以在不降低质量的前提下,更好地提高速度,是需要技巧和耐心的。贝佐斯能够指出质量和速度是业绩的关键,很有远见。
|
||||
|
||||
在这一条领导力准则里,贝佐斯特意强调了要面对挫折不气馁,想来他在创建亚马逊,以及达成业绩的过程中必然遭遇了很多挫折,所以他才要将这一点写入领导力准则。当然,这只是我一家之言,并没有特别的证据支持。
|
||||
|
||||
虽然说,以成败论英雄不一定正确,但在企业行为来看“结果”一定非常重要。
|
||||
|
||||
或许你要问了,亚马逊强调做决策要为长远目标而服务,不能为短期利益牺牲长远的规划和利益,但同时却又强调需要有业绩,那么远期目标和近期业绩之间的平衡点到底在哪里呢?
|
||||
|
||||
对此,亚马逊领导力准则并没有给出答案,贝佐斯也没有表述过他的看法。但是我想,领导力准则给出来的是纲领性的东西,而把纲领性的东西融会贯通,成为一个好的领导者,就需要看每个人的悟性和能力了。
|
||||
|
||||
至于这种平衡点到底在哪里,也许具体到每个问题上会有所不同。而能否做好远期目标和近期业绩之间的平衡,这正是一个优秀的领导者和一个平庸的领导者的区别。
|
||||
|
||||
亚马逊领导力准则这一系列,到今天就全部讲完了。它博大精深,而我个人的理解难免浅薄,我之所以会写作这个系列,一是希望传播一些伟大公司的管理理念,一是将其作为一个自我学习和不断进步的过程。这一套准则里面有很多关联和冲突,或许不是我能够一一理解和解答的,这个系列主要还是希望起到“领进门”的作用,希望我们一起领悟和不断精进。
|
||||
|
||||
|
||||
|
||||
|
||||
97
专栏/技术与商业案例解读/029智能音箱的战斗:亚马逊的硬件路.md
Normal file
97
专栏/技术与商业案例解读/029智能音箱的战斗:亚马逊的硬件路.md
Normal file
@@ -0,0 +1,97 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
029 智能音箱的战斗:亚马逊的硬件路
|
||||
在美国,亚马逊主要作为一个电商和云计算厂商为大家所熟知。这种印象最近两年因为一款智能音箱Echo的横空出世,得到了极大的改观,大家发现:原来亚马逊也很擅长制造硬件。
|
||||
|
||||
接下来,我想通过几篇文章和你说说智能音箱的发展历程。不过为让你更好地理解亚马逊是怎样首创了智能音箱这个硬件的,先来回顾一下亚马逊的硬件研发道路。
|
||||
|
||||
在做智能音箱前,亚马逊已经做了很久的硬件,其中最有名的两个产品是Kindle电子阅读器和手机Fire Phone。但是,Kindle的销售非常成功,Fire Phone却彻头彻尾地失败了。
|
||||
|
||||
亚马逊最初的业务是在网上卖纸质书,而且这块生意做得还不错。但是纸质书有很明显的问题,那就是体积大,又很重,需要仓储、运输等很多方面的支持。与此同时,软件下载已经很常见,MP3也已成为音乐的通行格式,iPod和其他MP3播放器大行其道。
|
||||
|
||||
这个基于数字产品的产业,不仅仅节省了大量的实体物品,避免了仓储、运输等一系列问题,更让整个产业的实体成本降低到近乎为零。加上数字产品更便携,所以很快受到了销售者和消费者双方的欢迎。
|
||||
|
||||
和软件、音乐等数字产品不同,电子书本身并没有一个很好的渠道去销售,主要是市面上不存在便捷的电子书阅读器,只能在电脑前看,用户对于只能在电脑前阅读的电子书购买欲望不强。作为网上售书平台亚马逊的创始人,2004年的时候,贝佐斯看到了类似于MP3播放器的便携式电子阅读器的便捷性和潜在的商机,打算做一个这样的产品,从而激发人们购买电子书的欲望,让亚马逊进军电子书市场。
|
||||
|
||||
贝佐斯对理想中的阅读器有几个要求。
|
||||
|
||||
首先,阅读体验应该和阅读纸质书很像。这个条件数字墨水技术就可以满足,数字墨水显示的效果和真书差不多。
|
||||
|
||||
其次,阅读器应该可以随时随地联网,这样用户就可以方便地从亚马逊下载电子书。鉴于美国的WiFi当时并没有那么普及,贝佐斯眼中的“随时随地联网”功能是指随时随地连接电信运营商的网络,而这个要求成为了制造阅读器的主要障碍。
|
||||
|
||||
在技术发展日新月异的今天,智能手机联网下载App和歌曲已经是常态了,但是2004年的时候因为网络带宽的问题,直接下载还是一件非常痛苦的事情。那时虽说有iPod这样的产品,可以让用户方便地携带出门,但是要下载歌曲还是需要一台电脑的。贝佐斯能够在2004年的时候提出这样的要求,彰显了他对未来发展趋势的准确把握。
|
||||
|
||||
但是对未来趋势把握准确,和能不能在既有条件下实现目标,就是两回事儿了。
|
||||
|
||||
Kindle的研发并不顺利,那时电信运营商提供的上网服务不仅带宽有限,而且更是按流量来计费的。同时,便携式设备上网用的元器件也不便宜。亚马逊在长达近三年的研发过程中,不仅仅需要解决电子阅读器的上网问题,更需要和某个或者某几个电信运营商达成协议。
|
||||
|
||||
最后亚马逊和美国的电信运营商Sprint谈下了合作,即使用Sprint的3G网络,允许Kindle随时随地联网。同时,基于电子墨水技术,并且随时随地可以连接电信运营商网络的电子书阅读器Kindle也研发出来了。
|
||||
|
||||
至于亚马逊为此向Sprint付了多少钱,那是商业机密,我们不得而知,但是每位Kindle用户可以完全免费联网,不需要为互联网流量买单的。第一批Kindle在2007年面世的时候,“随时随地免费使用3G网络”也是一个吸引眼球的卖点。
|
||||
|
||||
Kindle研发成功以后,贝佐斯为了解决制造问题,又亲自造访了中国。那时的亚马逊还不是今天这样如日中天、大名鼎鼎的企业,所以中国之行也非常艰难。据当事人后来回忆,当时中国最大的一个制造商“接见”贝佐斯一行人的时候,就在小黑屋里说:我生意很忙的,给你们半个小时吧。
|
||||
|
||||
贝佐斯在半小时内提出了自己的要求,但当对方问及这个设备的产量时,贝佐斯一时之间也不知如何作答,只是说“相信我,这个东西未来会大卖特卖的”。这家公司最后没有接单,这也很好理解,后来一家当时规模较小的制造商接了订单。
|
||||
|
||||
贝佐斯回忆时并没有具体提是哪家制造商,但想必那家制造商的老总也会因这段故事而心生悔意吧。
|
||||
|
||||
亚马逊能有今天,在很大程度上都离不开贝佐斯的眼光和远见。Kindle这种卖书方式,很快获得了各大出版社的支持。因为数字产品本身几乎不需要成本,需要的只是版权,因此这种方式卖书虽然价格更低,但是利润却更高。而且随之不断增加的销量,也让亚马逊和出版社对这个新生事物充满了期待。
|
||||
|
||||
我来事后诸葛一回,说说亚马逊的Kindle之所以大卖特卖的几个原因。
|
||||
|
||||
|
||||
首先,这个设备很轻,相较于携带纸质书更为方便。
|
||||
其次,这个设备的阅读效果和纸质书非常相近,阅读体验很好,用户不会感觉巨大的阅读习惯变化,这是其他电子设备,包括后来的iPad都不具备的。
|
||||
再次,用这款设备获取图书非常方便,随时随地可联网,而且可存储的图书数量也相当可观。
|
||||
|
||||
|
||||
亚马逊开始卖电子书的这段经历,让它积累了运营数字产品的经验,并进一步将业务延伸到了音乐、视频、游戏等各大领域。和苹果一样,亚马逊成为了很早就积累到丰富数字产品运营经验的少数互联网公司。
|
||||
|
||||
多年以后,亚马逊再次大张旗鼓介入硬件市场,这次它要做手机了。
|
||||
|
||||
亚马逊进入手机市场时,iPhone已经大卖特卖。贝佐斯见到乔布斯成功通过手机让苹果完美转型,从一个卖音乐的变成什么数字产品都卖的企业,加之他觉得亚马逊已经在数字产品领域有了不逊于苹果的积累,和其他公司比起来优势也相当明显,于是决定大力进军手机市场。
|
||||
|
||||
亚马逊做手机的动机有哪些呢?
|
||||
|
||||
|
||||
首先是亚马逊的电子产品生态圈尽管已经比较完善,却不是用户的首选。电子产品的生态圈往往和手机本身结合紧密,这就是谷歌和苹果都自己做手机的一个重要原因。为了在手机端推广电子产品生态圈,亚马逊也需要推出自己的手机。
|
||||
其次是亚马逊作为最大的电商,在互联网从PC端向移动端迁移的过程中,充分感受到了移动互联网入口的重要性。如果一款自己的手机可以让用户的日常行为和亚马逊的电商能够有更紧密、更无缝的整合,那对亚马逊的电商生态圈就会有很强烈的促进作用,这会帮助用户更好地伫留在亚马逊生态圈里。
|
||||
最后,亚马逊作为电商,一直苦于无法像谷歌那样有效地搜集用户信息,尤其是用户在亚马逊购物以外的信息,那么将手机作为一个媒介,有利于亚马逊补齐数据的短板,进一步促进亚马逊以大数据为导向的电商业务的发展。
|
||||
|
||||
|
||||
亚马逊的手机一直给人神神秘秘的感觉,时不时又会传出很多消息,但是却没有多少人知道什么是真的什么是假的。但这样一来,手机的研发一点都不像亚马逊对待其他产品的作风,往常都是非常保密,只有发布的时候大家才知道有这个产品。
|
||||
|
||||
2014年6月18日这一天,千呼万唤始出来的亚马逊手机终于隆重登场, 这款名字叫作Fire Phone的手机,伴随着亚马逊盛大而隆重的发布会和大家见面了。发布会上亚马逊总裁贝佐斯西装革履地走上台,向大家郑重地介绍了这款一直被热炒,却从未见过庐山真面目的手机。
|
||||
|
||||
亚马逊的Fire Phone一反往日价廉物美的传统,其定价和市面上当时最顶级的智能手机相当。作为一款如此定价的手机,肯定要有它突出的卖点,我们来看下。
|
||||
|
||||
第一个卖点是动态3D显示,即动态3D显示UI的功能。手机可以通过前置的4颗摄像头,识别出人到底是正面还是侧面地看手机,以及看手机时人的头部和眼球是怎样移动的,并相应地显示出不同的景深和位移。
|
||||
|
||||
据说为了研发这个动态3D显示功能,亚马逊研发部门耗费了数年时间。Fire Phone之所以一直推迟发布,主要就是因为这个问题。然而,用户拿到手机之后却发现,这个功能除了新鲜一点儿,并没有多大的实际用途,因此很快就失去了兴趣。
|
||||
|
||||
就我个人的理解,亚马逊之所以鼓吹动态3D,是因为高端手机总是需要某些高端炫酷的功能。而亚马逊选择动态3D这个功能作为它的高端炫酷的卖点。但是实际效果有点事与愿违,这个功能并未让用户买单。
|
||||
|
||||
Fire Phone的第二个卖点是Firefly功能,并专门设有实体按键,用于直接访问。Firefly能够自动读取电视节目台词或者歌曲,向用户提供亚马逊在线内容的链接;它可以扫描绘画和图书,向你提供维基百科和亚马逊书店的链接;它还可以扫描实体商品并显示亚马逊的价格。
|
||||
|
||||
Firefly功能的目标非常明确,亚马逊希望自己的手机可以和自己的电商业务有效整合,通过手机和电商业务的互动,创造一个利润增长点。
|
||||
|
||||
Fire Phone的第三个卖点是一个云端浏览器。简单地说,Fire Phone的浏览器不是让你直接访问目标地址,而是要先经过AWS的服务。亚马逊给出的理由是AWS的网络很强劲,利用AWS做缓存可以有效提高访问速度。
|
||||
|
||||
亚马逊之所以推出这个云端浏览器,它的主要作用是可以更好地搜集用户数据。亚马逊作为电商网站,有别于谷歌这样的门户网站,或者脸书这样的社交网站,用户在亚马逊网站以外的数据是很缺失的。通过强制所有浏览器都从亚马逊过一遍,可以有效地解决这个问题。
|
||||
|
||||
和Kindle比起来,作为亚马逊最高调发售,又走高端市场的Fire Phone,其销售情况可谓一塌糊涂,根本没人理睬,亚马逊之后不得不非常狠地打折清仓。在亚马逊的整个发展史上,如此惨败,无疑是第一次,也是目前为止唯一的一次。
|
||||
|
||||
为什么亚马逊会惨败呢?其实亚马逊的领导力准则给了我们答案。
|
||||
|
||||
亚马逊领导力准则里面强调“客户至尚”,而这款手机的研发,无论从价格还是功能上,没有一个地方体现出这条领导力准则:价格昂贵,动态3D华而不实。Firefly功能则是为了更好地让用户在亚马逊网站上进行消费,云端浏览器则是赤裸裸地搜集用户信息。当亚马逊自己都不遵循自己的领导力准则时,一个产品的惨败就是“必然”了。
|
||||
|
||||
这次惨败,让亚马逊的硬件研发团队、神秘的Lab126受到了重创。亚马逊的硬件研发和销售也因为Fire Phone的惨败有了质的变化,整个手机的产品线,和当时一直在进行的一款和虚拟现实相关的产品都被叫停了。亚马逊内部对这次惨败也进行了深刻的反思。
|
||||
|
||||
而这个时候,一个2011年就开始的研发项目,原本因为一再为手机让路而不断降低优先级,却迎来了一个历史性的契机。这个项目就是后来赫赫有名的那只音箱——Echo。
|
||||
|
||||
|
||||
|
||||
|
||||
83
专栏/技术与商业案例解读/030智能音箱的战斗:Echo攻城略地.md
Normal file
83
专栏/技术与商业案例解读/030智能音箱的战斗:Echo攻城略地.md
Normal file
@@ -0,0 +1,83 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
030 智能音箱的战斗:Echo攻城略地
|
||||
Fire Phone惜败,Echo获得契机
|
||||
|
||||
智能音箱Echo是一个自2011年起就一直存在的研发项目,但是优先级一直很低。Fire Phone作为硬件研发团队Lab126的重点研发项目却最终惨败,让亚马逊的Lab126士气低迷。
|
||||
|
||||
从后面披露的材料来看,Lab126为了对外界保密,文档通常用“项目A”“项目B”“项目C”“项目D”这样的代号来指代不同的项目。现在我们知道,A是指Kindle电子书,B是Fire Phone,C是一款AR/VR相关的产品,D则是当时低优先级,如今却大红大紫的智能音箱Echo。
|
||||
|
||||
据传闻,这里代号为C的产品和Fire Phone相关,并不是独立存在的。因此随着Fire Phone的惨败,这个项目也顺理成章搁浅了。而“硕果”仅存的“项目D”,也就是Echo因此获得了一次试水的机会。大约在Fire Phone失败半年之后,智能音箱Echo定型,亚马逊决定发布它。
|
||||
|
||||
大约是吸取了Fire Phone高调发布却惨败的教训,也可能是亚马逊自己心底里也没底,不知道结果会怎样,智能音箱的发布非常低调。发布的方式就是亚马逊开始逐步给它的Prime 会员推送信息,告诉他们可以购买这款音箱尝试一下。当时,音箱的库存量也很小。
|
||||
|
||||
然而,Echo却给亚马逊带来了意外之喜。
|
||||
|
||||
低调发布,为何却一炮而红
|
||||
|
||||
首先,作为一款音箱,Echo这个产品把分内事做得很好,那就是:发声,优雅地发声。Echo的音质达到了专业级音箱的入门水准。这对于一般用户来说,绰绰有余了。
|
||||
|
||||
其次,它还是一款智能音箱,你可以和它对话,然后静待奇迹发生。它可以做很多事情,包括基本的通过语音对话播放音乐,连接你自己喜欢的音乐服务,还包括设定闹钟、控制家里的智能电器等。
|
||||
|
||||
再次,Echo并没有任何屏幕或者键盘,因此注定了唯一的交互途径就是语音。这种前所未有的交流方式,让用户眼前一亮。当大家忙于手头的事情,不方便点击操作手机时,可以方便地和音箱交互。
|
||||
|
||||
最后,Echo最初的外形和颜色都让它显得比较高冷,后来的调查显示这种高冷的外观反而促进了一部分人的购买欲。
|
||||
|
||||
特意打造的用户体验结合外形与颜色设计,Echo很快就火了起来。亚马逊在网站上悄悄地卖,销量却蹭蹭蹭得往上涨。
|
||||
|
||||
Echo崛起的背后,值得你我深思
|
||||
|
||||
中国有句古话“有心栽花花不开,无心插柳柳成荫”,亚马逊重点扶持的手机项目很快废掉了,而没那么看重的智能音箱,却静悄悄地开始大火特火。
|
||||
|
||||
三年后的今天来看,亚马逊无疑是智能音箱领域的首创者和开拓者,但这是亚马逊自己都始料未及的。不知道亚马逊是不是内部检讨过,为什么智能音箱的研发长期以来都被列为低优先级项目呢?
|
||||
|
||||
不过,亚马逊有一点非常值得其他公司学习,那就是:非常忠于市场的真实反应。当一个产品在市场上反应平平,亚马逊能够真实面对;当一个东西在市场上反应出乎意料得好,亚马逊就立刻加大研发和宣传的投入,加班加点以最快的速度占领市场。这种忠于市场并迅速做出反应的能力,不是一般互联网公司所具备的。
|
||||
|
||||
当智能音箱卖得越来越好的时候,亚马逊的投入也越来越大,各种商业策略也顺利而迅速地跟进了。
|
||||
|
||||
亚马逊最初盯着的市场非常简单,就是传统的专业入门级音箱市场,外加一点语音加持,还有通过音箱进行购物的能力。
|
||||
|
||||
这场战斗非常顺利,199美元的定价,和市面上的入门级专业音箱等价,Prime会员还有优惠。同样的质量,更多的功能,新鲜的语音交互,没有理由不大卖。所谓攻城略地,从来没有如此舒坦过。
|
||||
|
||||
2015年,亚马逊总共卖出了超过250万只音箱,到2016年这个规模又翻了一番,达到了500万只。在短短两年的时间里,Echo智能音箱把市面上入门级的专业音箱打得落花流水,各种品牌被统统扫地出门。
|
||||
|
||||
专业音箱制造厂商们只能蜷缩在更高端的音箱上赚钱了,而高端市场的总量是没法和入门级市场相比拟的。
|
||||
|
||||
我想之所以亚马逊能够在智能音箱这个市场上取得巨大成功,一方面是因为Echo本身质量过硬,做到了专业音箱入门级产品的同等水准;另一方面是价格控制得非常好,做到了和专业音箱入门级产品的价格齐平或者更低。但是最重要的,还是这个脱离了手动操作,可以直接用语音交互的方式,在特定场景比如客厅和厨房里的确是一种创新。
|
||||
|
||||
任何创新的东西都有吸引人的地方。而这款音箱价格不怎么贵,语音交互功能又着实足够多,能够连接自己喜欢的在线云音乐服务,能够陪聊天,能够帮助设定闹钟,还能够控制家里的各种智能电器……这么多的附加功能,好玩、新鲜而且实用,不大卖特卖才真是怪。
|
||||
|
||||
在顺利把广大专业音箱厂商的入门级音箱“扫地出门”之后,亚马逊在智能音箱的道路上越走越远。2015年上半年,亚马逊给第三方厂商开放了技能平台。向来封闭的亚马逊,在智能音箱上却显得格外开放。
|
||||
|
||||
所谓技能平台,是指第三方厂商可以通过开发插件的方式,把自己需要支持的功能接入Echo。这个插件可以发布在亚马逊的技能平台里,用户在亚马逊搜索并安装这个技能插件以后,只要使用特定的语音命令,就可以执行这个技能。
|
||||
|
||||
举例来说,Echo不支持用Uber打车。Uber公司就可以开发一个打车的技能插件,发布在亚马逊的技能平台上,用户安装了以后就可以通过Echo来打车了。
|
||||
|
||||
时至今日,各大公司加入的技能很多,都有几万种了。比如说飞利浦做的所有智能家电,包括联网的电灯,都可以通过Echo来完成语音控制。至于开电子锁、开关窗帘之类的事情都是小意思了。
|
||||
|
||||
这些技能的加入,让亚马逊有了一个非常丰富的生态圈。围绕亚马逊生态圈的企业非常多,仅仅这点就让其他公司进入智能音箱领域非常困难。
|
||||
|
||||
而亚马逊对Echo智能音箱的开放性,还体现在另外一件事情上。音箱是用来放歌的,亚马逊的语音控制放歌功能最开始只支持亚马逊的音乐服务,这其实很好理解,就是自家的产品关联起来,促进自家其他产品的销售。而亚马逊在很多产品上都是这样关联而封闭的。
|
||||
|
||||
但是没过多久,Echo智能音箱就开始接入常用的第三方音乐提供商。要知道,如果Echo可以连接其他音乐提供商,亚马逊音乐本身就会少赚钱。那么,亚马逊为什么做出了这一举动?
|
||||
|
||||
这充分体现了亚马逊对于市场的快速反应能力,它意识到卖出更多的音箱,建立生态圈,会比自己的音乐服务短期内赚更多的钱更有利于亚马逊长期的发展。
|
||||
|
||||
经过这一系列的演变,在很长时间里亚马逊的智能音箱Echo都一骑绝尘,市面上完全没有敌手。
|
||||
|
||||
小结
|
||||
|
||||
智能音箱Echo的崛起有很多值得我们学习和思考的地方。
|
||||
|
||||
首先,最初这款音箱能否成功,其实亚马逊自己也不是太清楚。所以小范围内试水是一个保险的做法,如果行得通就继续加量,如果行不通就可以及时止损。万一失败,亚马逊也不会因为生产过多而导致成本失控。
|
||||
|
||||
其次,在发现这款音箱很畅销之后,亚马逊对市场的反应速度和能力都令人敬佩。亚马逊意识到开放的音箱生态系统是音箱得以发展的基础以后,就果断开放了第三方技能平台,允许音箱接入第三方音乐提供商。这种做法正符合亚马逊的领导力准则,就是领导者要有长远的眼光,不要只是拘泥于短期的利益。当然还有,就是做事情需要做到“客户至尚”。
|
||||
|
||||
总体来说,Echo的诞生本身有一些偶然因素,但是诞生以后亚马逊充分贯彻领导力准则,围绕Echo的发展采取了一系列策略,让它真正能够大红大紫。
|
||||
|
||||
|
||||
|
||||
|
||||
67
专栏/技术与商业案例解读/031智能音箱的战斗:语音助手Alexa.md
Normal file
67
专栏/技术与商业案例解读/031智能音箱的战斗:语音助手Alexa.md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
031 智能音箱的战斗:语音助手Alexa
|
||||
作为智能音箱核心功能的语音交互,或者更通俗的说是“语音助手”,对Echo来说是最重要的一个模块。在Lab126研发音箱的早期,Echo既是音箱的代名词,也是语音助手的代名词。由此可见,语音助手并非一开始就作为独立模块存在。
|
||||
|
||||
语音助手不是个新鲜事物,市面上早有独立的语音助手存在。在这个领域最有远见的,无疑是苹果公司的创始人史蒂夫 · 乔布斯。
|
||||
|
||||
Siri原本是在苹果上面大卖特卖的一款App,发布后没多久,被乔布斯看到。乔布斯很有远见地预见到了语音交互的重要性,迅速把这个公司的软件买下并整合进了iOS,成为iPhone非常重要的功能。
|
||||
|
||||
我有时候不得不感叹人生不逢时,或者是天妒英才。今天来看,乔布斯收购Siri的目的,肯定不仅仅是让它成为iPhone里面一种可选的沟通方式,他肯定在下一盘很大的棋,但是一切都随着他的去世而烟消云散了。
|
||||
|
||||
Siri作为iPhone上的语音助手,此后在蒂姆 · 库克(Tim Cook)领导下的苹果公司发展,可谓乏善可陈。而此后微软和谷歌都进入语音助手市场,无论是Windows 10还是安卓手机都实现了对语音助手的支持。
|
||||
|
||||
但是我们知道,这两年最红火的语音助手是Alexa,它属于亚马逊。
|
||||
|
||||
全力以赴打造语音助手
|
||||
|
||||
Alexa是怎么诞生的呢?这就要回到2015年8月,Echo智能音箱卖了大概10个月之后,亚马逊突然意识到自己的语音助手可以作为一个独立的云服务存在,并不一定要和Echo智能音箱捆绑在一起。
|
||||
|
||||
于是亚马逊悄悄地把那个叫Echo的语音助手改名为Alexa。Alexa原本是亚马逊旗下的一个网站分析工具,语音助手算是鸠占鹊巢。没过多久,谁也不再记得那个曾经的网站分析工具了,Alexa成了专门指代亚马逊语音助手的名词。
|
||||
|
||||
但是为了保证向后兼容,在Echo智能音箱语音助手的提醒词里,虽然默认是Hello Alexa,最初推出音箱时用的提醒词Hello Echo也依然保留着。只有从提醒词里,我们才能够看到过去的痕迹:原来Alexa曾经叫作Echo。
|
||||
|
||||
亚马逊最初研发音箱的时候,对语音处理技术的重要性并不是特别清楚,所以语音助手的技术水平很一般。当Echo音箱卖得很好时,亚马逊很快就意识到了语音处理技术的重要性,但是语音处理技术人才储备并不多。索性西雅图有一家在消费市场并不是特别知名,但是在专业语音处理领域非常著名的公司Nuance。
|
||||
|
||||
Nuance在西雅图有一个研发中心,中心里有很多专门做语音处理技术的人才,亚马逊就狠狠地高价在这家公司里面大肆搜罗了一番。最后,Nuance西雅图研发中心的很多核心人员都跑去了亚马逊。
|
||||
|
||||
为了进一步增强在语音处理领域的技术和人才储备,亚马逊又迅速出手,接连收购了Yap和Evi两家创业公司。至此,亚马逊终于有些安心,给Alexa储备了足够的语音处理人才。
|
||||
|
||||
用机器学习搞定语音识别
|
||||
|
||||
Echo首先是个音箱,而音箱的主要功能是放音乐。但有些活动,比如聚餐、舞会中会有很多其他声源,这类场景下和音箱进行交互就有一个很大的问题:音箱如何在这些嘈杂的声音里识别出真正的交互命令呢?
|
||||
|
||||
应用场景的不同,决定了Echo音箱上的语音助手Alexa和手机上的语音助手对技术的需求有很大不同。简单来说,如果手机上的语音交互难度是一颗星,那么深处嘈杂环境下的音箱的语音交互技术起码得是四颗星。这是Echo智能音箱必须解决的一个难题。
|
||||
|
||||
在一次公开的交流中,负责Alexa相关业务的首席科学家、著名的机器学习学者罗希特 · 普拉萨德(Rohit Prasad)在接受采访时简单提到过,Lab126团队因为这个问题一度让Echo智能音箱项目被搁浅,最后不得不在全公司范围内寻求帮助。
|
||||
|
||||
而之后的解决方式是机器学习。亚马逊曾经在网络上公开过一段音频,对比了在嘈杂环境上的原始声音,和经过机器学习处理的声音。在音频里你可以看到,经过机器学习处理的音频达到了近乎完美的噪音过滤,这是Echo在极其恶劣嘈杂的环境下,依然能够表现出非常良好的语音识别功能的主要原因。
|
||||
|
||||
Echo上市以后,无论在多嘈杂的环境里,语音交互的识别能力都非常好,这是Echo能够迅速脱颖而出最重要的原因之一。
|
||||
|
||||
亚马逊公司长期以来给人的感觉是商业决策优于技术,亚马逊的核心技术并没有让人觉得多惊艳。然而在这件事情上,亚马逊显现了用技术解决难题的能力,这颇让我对亚马逊的印象有了很大的改观。
|
||||
|
||||
语音平台促进成长
|
||||
|
||||
Alexa从Echo独立出去以后,就开始在亚马逊的各大设备上集成,比如说亚马逊的Fire TV就集成了Alexa。Alexa在亚马逊内部可谓大行其道,任何一个项目组的东西如果可以和Alexa整合,在亚马逊内部的优先级都会上升许多。
|
||||
|
||||
除了“内销”,亚马逊还把这个语音助手“出口”到了各行各业去,包括智能冰箱、汽车,乃至华为手机,等等。Alexa的遍地开花,让亚马逊作为一个语音助手市场的后来者,占据了很多有利位置。
|
||||
|
||||
从技术开发上,Alexa也有了自己独立的研发团队,而且目前已经非常庞大,有包括一个总监在内的很多人。在亚马逊,如果一个项目有总监级别的人参与,就代表着这个项目实在是一个非常重要的项目,是公司首席级高管(C-level)可以直接看到和关注的项目了。Alexa有了总监级人物以后,在亚马逊的地位也就突显出来,不再是Echo下面的一个附属项目了。
|
||||
|
||||
在亚马逊内部,很多人都相信语音交互是一个非常重要的、新的流量渠道,而且在未来会更加重要,占领了语音,也就在未来的新交互方式里占据了一块稳固的地盘。所以自从Alexa独立以后,这个团队就一直在膨胀。很有意思的是,我在LinkedIn上经常可以收到来自亚马逊招聘人员的邀约,其中为Alexa招人的比例一直居高不下。
|
||||
|
||||
如果说一开始Echo作为一款智能音箱,对于亚马逊占领客厅和厨房很重要的话,那么现在亚马逊的语音助手Alexa和它给第三方开放的技能平台,则是亚马逊的重中之重。如果说这之前,亚马逊更关注音箱,那么Alexa作为一个软件独立出来发展后,亚马逊关注的重点也就从硬件转向了软件和平台:硬件,包括智能音箱在内,都是为这个软件平台服务的。亚马逊今天发展的各种硬件,确实已经变为主要为Alexa平台服务,硬件本身的作用已经远远比不上这个语音平台了。
|
||||
|
||||
有了这个语音平台,亚马逊不但可以在自己的硬件上推广,还可以把语音平台开放给第三方。让第三方的硬件都进入这个平台。这里就有华为的手机、LG的电器,未来我们还可以预见到的,比如说车载系统等等。
|
||||
|
||||
对比硬件的影响力,语音平台的影响力要大得多,最终平台会造就一个生态圈,而任何生态圈都有很强的黏性。亚马逊也可以凭借平台把影响力扩大到自己的业务之外,让Alexa成为整个互联网和IT产业里面很多公司都愿意加入的生态圈,这种影响力是智能音箱不可能达到的,也是亚马逊从来都没有企及过,但是现在却有可能成功的。
|
||||
|
||||
从Echo音箱到Alexa语音助手的变迁,是优先级的一个巨大改变。这个变迁在亚马逊里面用了10个月,亚马逊对市场反应的这个速度,让我非常吃惊。通常在其他互联网或者软件公司,这种变迁花费三年五年也是很常见的。这样看来,亚马逊能够在语音市场占据一片天地,也是有原因的。
|
||||
|
||||
|
||||
|
||||
|
||||
55
专栏/技术与商业案例解读/032智能音箱的战斗:谷歌的杀入.md
Normal file
55
专栏/技术与商业案例解读/032智能音箱的战斗:谷歌的杀入.md
Normal file
@@ -0,0 +1,55 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
032 智能音箱的战斗:谷歌的杀入
|
||||
通过先发优势,亚马逊在智能音箱领域表现非常强劲,获得了近80%的市场占有率。在智能音箱诞生的最初两年里,尽管亚马逊一直在发力,其他公司却一直悄无声息,难道是因为智能音箱的研发比较困难?无论如何,这让亚马逊的先发优势持续了两年时间。
|
||||
|
||||
然而竞争终究会来。2016年10月,谷歌悄无声息杀入这个市场,战场开始硝烟弥漫。
|
||||
|
||||
谷歌杀入智能音箱市场,其实不是一件多么令人吃惊的事情,它对于智能家居市场的觊觎由来已久,很多年前就有过制造类似于音箱产品的经验。当时,谷歌推出了一个球状的自带音箱的播放器,它可以连接音乐播放设备,然后声音就会从球里发出来。
|
||||
|
||||
这个球的售价是299美元,“Made in America”是卖点之一,它完全在美国设计制造和组装。但是,这是个失败的产品,最后只卖出了500个左右,谷歌很快就取消了这个产品。但是不管怎样,这段经历肯定对谷歌后面做音箱有帮助。
|
||||
|
||||
此外,“占领客厅”一直是谷歌努力的方向。为此,谷歌很久以前就推出了谷歌电视,虽然一直都不红不紫,但是通过和很多电视厂商合作,谷歌在智能家居市场上有了进一步的积累。
|
||||
|
||||
在这两次尝试以后,终于诞生了一个非常成功的硬件产品Chromecast。Chromecast可以将其他视频播放平台的内容转送到电视机上播放,而且价廉物美,迅速占领了一大片家庭市场。
|
||||
|
||||
随着“占领客厅”计划的进一步实施,2014年谷歌重金收购智能温控器制造厂商Nest。Nest成立于2008年,是iPod之父从苹果公司辞职以后创立的公司。Nest之前研发了一款智能温控器,它可以联网,并且可以通过自我学习达到自动控制家中温度的目的,进而可以大大降低能耗。
|
||||
|
||||
Nest的温控器很多时候是高大上的科技爱好者家里必配的设备,一直销量很好。谷歌买下Nest,当然是希望在更加广阔的智能家居市场上谋求进一步的发展。而这为谷歌进军智能音箱市场提供了技术和经验的积累。
|
||||
|
||||
从产品上来看,谷歌推出的智能音箱和亚马逊的产品相比,能做的事情差不多,但是价格却要低很多:亚马逊的Echo最初卖199美元,后来降价到179美元,而谷歌的音箱一推出只卖119美元。一个以“便宜”著称的公司,居然被一个高科技公司在价格上打败了,挺有意思。
|
||||
|
||||
当然,为了保证更便宜的定价,谷歌在成本上做了控制。谷歌的音箱在播放效果上和亚马逊的差别并不大。但在收听方面,谷歌使用了两个麦克风,亚马逊的音箱则使用了七个。这相差的五个麦克风,就为其省下来很多钱。
|
||||
|
||||
亚马逊使用这么多的麦克风,主要还是为了保证语音命令的响应可以更流畅。因为亚马逊的机器学习技术要求必须有这么多个不同的音源,才能够根据音源的距离不同有效地过滤掉无关的音频。
|
||||
|
||||
但是谷歌在人工智能机器学习之类的黑科技方面素来积累深厚,绝对不是亚马逊可以比拟的。这不,我正觉得亚马逊解决了这个语音识别问题,因此在技术上多么了不起,我就被谷歌打脸了。
|
||||
|
||||
谷歌表示,因为他们的机器学习技术更优异,所以可以在两个麦克风收听的情况下,就达到亚马逊需要七个麦克风才能达到的效果。同样的效果,更少的硬件,价格便宜下来给用户实惠,这是谷歌宣传的卖点之一。
|
||||
|
||||
现场测试表明效果确实不差。可能比亚马逊的差一点,但是这种差距就算真的有,在日常应用场景下也是常人无法区分的。既然常人无法区分,也就无所谓差距了。
|
||||
|
||||
按照谷歌的宣传说法,谷歌的音箱设计比亚马逊的更加“和谐”。谷歌音箱外观相对更平和一些,没有那么高冷。另外,谷歌还给音箱配备了可以替换颜色的底座。从谷歌公布的演示视频来看,谷歌音箱在家居环境中的确没有亚马逊的那么显眼,也许这就是谷歌说“更和谐”的由来吧。
|
||||
|
||||
除此之外,依托谷歌强大的搜索引擎功能和强大的人工智能,在实际使用过程中,谷歌的音箱能够更加自然地响应用户的问题,也能够提供更加准确的信息和更为丰富的内容。
|
||||
|
||||
在谷歌的演示中,需要进行上下文相关交流的时候,音箱能够理解前后不同语音之间的相关性,并作出相对应的回答。而亚马逊的Alexa在理解上下文或者需要更多“智商”的时候,往往表现欠佳,我都替它着急。
|
||||
|
||||
网上有用户评价说,对着亚马逊的Echo智能音箱说半天,Alexa总是没办法听懂,换成谷歌的音箱以后这个问题就荡然无存了。我想这也算是一种证据吧,这就是技术差距所导致的了。
|
||||
|
||||
除此之外,谷歌有搜索引擎,有很多的云端服务,比如说邮箱、日历、通讯录等。这些东西和语音助手结合起来,加上强大的人工智能技术,让谷歌音箱可以做很多事情。作为一个个人助理一样的角色,谷歌音箱呈现的效果要好很多。
|
||||
|
||||
谷歌音箱和谷歌早年红极一时的产品Chromecast或者谷歌电视结合的时候,又有了一个独特的优势。通过这种结合,谷歌音箱可以把交互的结果显示在电视上,而Alexa显然没有这个能力。有些交互,使用大屏幕电视作为界面,比语音更合理。比如问音箱“今天的天气怎么样”,在屏幕上显示天气信息显然比用语音一句一句地读给用户更直观。
|
||||
|
||||
谷歌音箱一上市,就表现出不俗的销售业绩,很快就抢占了10%的市场。而谷歌的研发从来没有停止,2017年的谷歌IO年度大会上,音箱是热点之一。谷歌对它的音箱进行了巨大的升级,这些升级让音箱显得更加智能、好用。
|
||||
|
||||
当然,亚马逊仍然有一个巨大的优势,它是最先给第三方开放技能平台的。目前在亚马逊技能平台上的技能,是谷歌上面的100倍之多。凭借第三方厂商的众多技能,亚马逊的音箱也能够提供更多的整合和功能。
|
||||
|
||||
所以在这场智能音箱的角斗场上,尽管谷歌在技术上已经表现出明显优势,但在和第三方合作上,依然任重道远。
|
||||
|
||||
|
||||
|
||||
|
||||
55
专栏/技术与商业案例解读/033智能音箱的战斗:亚马逊的战略布局.md
Normal file
55
专栏/技术与商业案例解读/033智能音箱的战斗:亚马逊的战略布局.md
Normal file
@@ -0,0 +1,55 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
033 智能音箱的战斗:亚马逊的战略布局
|
||||
除了是最早进入智能音箱领域的企业,或者说是智能音箱的发明者,亚马逊还是一家对市场反应非常灵敏的企业,因此自然会有自己的战略布局。无论是否有其他竞争对手进来,亚马逊都是需要发展智能音箱的。
|
||||
|
||||
亚马逊在Echo上的布局,最初的做法也是遍地撒网,不算多高明。第一个出场的是便携式智能音箱Tap,这个音箱可以随身携带外出旅游。但是我们知道,出行的时候带个音箱其实还是小概率事件。更重要的是,Alexa需要联网才能工作,而Tap并未自带手机芯片,必须外接WiFi才能连接互联网,所以这个产品卖得一般般。
|
||||
|
||||
第二个出场的是Echo Dot,你可以认为它就是廉价版Echo。这个Echo Dot更新换代很快,半年不到就已经出到了第二代。这个产品倒是非常有意思,它有麦克风和扬声器,提供了Alexa语音助手,同时还可以连上其他高档音箱,把高档音箱变成智能音箱。
|
||||
|
||||
这样一来,就让那些喜欢更高品质音箱的人,可以兼得智能音箱的功能和高档音箱的音质。而对于在家里需要到处都有Alexa语音,但不一定都需要听歌的人,廉价的Echo Dot也是一个很好的选择。
|
||||
|
||||
你完全可以在不同的房间里面放个Echo Dot,并只在厅里放个Echo,通过“高低结合”形成一个完整的智能家居音控系统。亚马逊鼓励大家多买Echo Dot,所以在售价上,为同时购买多个Echo Dot的用户提供折扣。
|
||||
|
||||
既然谷歌通过Chromecast和Google TV在电视上提供视频交互的功能,亚马逊也提供了对应的策略,这就是另外一款产品:Echo Show。
|
||||
|
||||
Echo Show简单来说就是一个带屏幕的Echo,音箱质量还不错,有个小屏幕,Alexa可以提供视频和语音回答。这个产品出来以后,很多人都挺喜欢的。
|
||||
|
||||
谷歌在智能音箱上可谓来势汹汹,亚马逊在Prime Day的时候做了一次史无前例的促销。促销主要集中在亚马逊的智能音箱领域。Echo系列全面打折,其中Echo音箱的折扣更是高达50%,所以这一天很多很多的会员都买了。在我的朋友圈里,那天很多人都在贴自己买了音箱或者要剁手的照片。
|
||||
|
||||
当时有两种声音:一种说法是这是亚马逊通过大规模补贴来迅速占领市场,进一步巩固自己的霸主地位;另外一种说法是亚马逊在清仓了,因为很可能下一代的Echo产品要出来占领市场了。
|
||||
|
||||
最后证明果然是亚马逊出了Echo第二代产品。第二代Echo有Echo和Echo Plus两个版本。其中,Echo的高度只有原来的一半,而价格也很神奇地降到了99美元,比谷歌的智能音箱还便宜。不过,Echo据说虽然只有原来体积的一半,却比上一代有更好的音质,这主要归功于Echo二代里面新加的低音喇叭。
|
||||
|
||||
Echo Plus售价149美元,看起来更像是上一代的Echo,至少从高度上看很像。当然,149美元的售价也比上一代更加便宜。
|
||||
|
||||
Echo Plus最大的卖点是智能家居的控制。和一代产品不同,二代产品Echo Plus可以自动检测连接在同一个局域网里面的所有智能家居,并自动设置好。开箱之后,你就可以直接通过语音助手Alexa控制智能家居,完全不需要任何人工设置的过程。
|
||||
|
||||
这看起来的确是非常实用的一个功能。为了体现这个功能的价值,Echo Plus还自带了一个飞利浦智能电灯泡。至于效果怎样,可能就有待市场检验了。
|
||||
|
||||
亚马逊在发布会上还表示,经过对三年来用户行为的学习,亚马逊发现用户最喜欢Alexa做的三件事情是:开灯、启动咖啡机、读新消息。所以以后用户可以设定例行程序,比如在说“Alexa good morning”的时候,就可以让它把这些事情都做了。
|
||||
|
||||
亚马逊还发布了一个新的产品Echo Spot,这是个带圆形显示屏的2.5英寸大小的东西,比Echo Show要小。显示屏可以显示时间、天气,甚至可以实现和用户进行视频会议等诸多功能。作为一款屏幕如此小的产品,Echo Spot的售价在我看来并不便宜,高达129美元。
|
||||
|
||||
最后出场的是20美元一个的Echo Button。它的功能非常有限,目前也只能做一下语音交互,比如可以用作抢答问题的答题器。
|
||||
|
||||
亚马逊发布了新的Echo系列之后,我着实有些不爽。没错,我就是那个贪图便宜在Prime Day里面半价买了一代Echo智能音箱的人。“被清仓”的感觉真心不好。在我买了一代以后是不是要买二代,这个问题就显得很尴尬了。
|
||||
|
||||
面对谷歌咄咄逼人地进军智能音箱市场,亚马逊推出新一代产品,并主要解决了下面几个问题。
|
||||
|
||||
首先是谷歌的低价问题。作为一个把节俭写入了领导力准则,把成本控制看作生命,把低价看作核心价值的公司,在自己发明的智能音箱领域,居然被一个黑科技公司打趴下了,实在不是什么值得高兴的事情。所以,在Echo二代里,亚马逊大幅度降低了音箱的价格,性价比方面一下子就超越了谷歌。这样,亚马逊就在价格上占据了优势。
|
||||
|
||||
其次是对谷歌Chromcast和电视机结合的反击。谷歌通过音箱和Chromecast的组合,以及Chromecast和电视机的结合,提供了独一无二的体验。亚马逊的反击颇为迂回,主要体现在两个方面:一个是Echo Show,可以放在客厅之类的地方;一个是新的Echo Spot,小巧精致放书桌上正合适,还可以用来和他人视频通信,可谓一举数得。至于到底是大屏幕电视的体验更好,还是另起炉灶的新Echo硬件更好,我们很难判断。想来是各有千秋吧。
|
||||
|
||||
第三点,可能也是体现亚马逊战略的一点,就是亚马逊希望成为智能家居的“控制器”。为什么说是“控制器”呢?因为在上一代产品里,智能家居的控制是需要通过技能的设置来完成的。虽然设置好了以后也挺好用的,但是难免有人不懂或者不熟悉使用电脑。所以为了更好地占领智能家居市场,“让对智能设备的控制简单化、傻瓜化”也就提上了日程。这个Echo Plus的设备就是为此设计的。
|
||||
|
||||
更低廉的价格,更多的交互方式,对智能家居控制器的强化,基本上构成了亚马逊这次新产品发布的主要目的,亚马逊在商业上想得很清楚。
|
||||
|
||||
所以长期来看,亚马逊和谷歌在智能音箱领域的斗争依旧要延续下去。估计最后分庭抗礼的可能性比较大。
|
||||
|
||||
|
||||
|
||||
|
||||
55
专栏/技术与商业案例解读/034智能音箱的战斗:巨头纷纷入场.md
Normal file
55
专栏/技术与商业案例解读/034智能音箱的战斗:巨头纷纷入场.md
Normal file
@@ -0,0 +1,55 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
034 智能音箱的战斗:巨头纷纷入场
|
||||
在谷歌入场一年以后,另外两大IT巨头苹果和微软也宣布进军智能音箱市场。
|
||||
|
||||
苹果的入场始于2017年WWDC全球开发者大会,它们发布了一款叫作HomePod的智能音箱,原计划年底交货,不过目前已经推迟。
|
||||
|
||||
说实话,苹果杀入智能音箱市场如此慢,的确出乎大多数人的意料。因为Siri语音助手是苹果首先在iPhone上做出来的,苹果没有理由不知道语音交互的重要性。事实上却是苹果姗姗来迟,总给人慢几拍的感觉。
|
||||
|
||||
苹果在WWDC上推出的音箱HomePod售价是349美元,可以说是所有设备里面最贵的。其主要特点是有非常好的音质,是一个地地道道的音箱。其次,它可以连接Siri语音助手,做类似于手机上Siri语音助手可以做的事情。
|
||||
|
||||
WWDC上关于HomePod的演示非常有意思:主要是演示侧重于强调HomePod作为音箱的属性,而不是智能的属性。
|
||||
|
||||
在演示里,苹果公司首先高调强调了HomePod这款音箱的音乐播放功能。它内置7个扬声器、1个低音炮、6个麦克风以及苹果A8芯片,硬件是很高规格的。这款音箱具备“空间感知”功能,能够自动根据房屋的空间大小调节到合适的音量位置。这两者的结合给音箱提供了非常好的音质,让它比很多入门级的专业音箱音质都好。
|
||||
|
||||
于此同时,苹果公司在演示的最后说,HomePod内置Siri,用户可以和Siri交互从而完成特定的指令。但是苹果公司并没有花多少时间去演示到底能完成什么样的指令。整个发布会对音乐品质的强调,远远多于对Siri语音助手的强调。
|
||||
|
||||
在智能音箱市场上,无论是谷歌还是亚马逊,强调的都是智能的属性。而苹果的WWDC演示,却侧重于音箱的音质本身,无疑让大家感觉苹果公司没有明白智能音箱流行起来的主要原因。
|
||||
|
||||
结合349美元的高售价,喜欢高音质音箱的人,大可花钱去买专业级音箱,完全没必要掏这个钱去买一家非专业音箱制造商生产的,又没有多少智能属性的HomePod。大家都在努力拼智能的时候,苹果公司却来强调音质,只能说它一开始就走在了错误的道路上。
|
||||
|
||||
而在这之前不久,也就是2017年5月9日,传统音箱厂商哈曼卡顿(Karman Kardon)宣布和微软合作,推出一款搭载微软语音助手Cortana的智能音箱,这款音箱名为Invoke。
|
||||
|
||||
微软进军智能音箱领域的策略至此终于揭秘,它自己不生产音箱,而是选择和传统音箱厂商合作,自己提供语音技术。
|
||||
|
||||
这个做法和当年PC时代的做法比较像。微软当年只做操作系统,而具体的个人计算机则由其他厂商负责。但是这生意要能做好,首先要有足够多的音箱厂商愿意合作。倘若到最后只有一家厂商和微软合作的话,这个生意也未必有多好看。
|
||||
|
||||
而音箱和个人计算机不同,生产音箱的厂商明显更少。因此,试图用这种方式进军智能音箱市场的微软,究竟前景如何,还需要时间去检验。就我个人的判断,这个做法复制个人计算机的成功的可能性不大。
|
||||
|
||||
时隔半年,10月22日微软在自己的微软商城,以及BestBuy等合作伙伴那里正式开售这款Invoke智能音箱,售价199.95美元。而这个时候亚马逊的第二代智能音箱已经完成升级,Echo二代已经大大降价。
|
||||
|
||||
作为市场的迟到者,199.95美元的定价到底能吸引到多少人购买呢?我个人来说目前没有购买的欲望。
|
||||
|
||||
这款音箱有一个比较独特的功能,就是除了可以连接智能家居,还能够连接Skype。Skype是国外一个VOIP的产品,前几年被微软收购了。因此,微软技术造就的音箱,能够连接Skype打网络电话并不奇怪。
|
||||
|
||||
但是2018年了,智能音箱从2014年诞生以来,亚马逊已经卖掉了几千万台,谷歌也在不断出货,并且这两家的价格都比较低。三年后入场的微软,在这个领域还能有所作为吗?我个人不太看好,毕竟微软姗姗来迟。
|
||||
|
||||
当然,对于占领客厅来说,微软从来都不缺设备。即使没有音箱,微软还有它的Xbox。微软的游戏机经过近20年的耕耘,早已经是一个非常成熟的产品,有着很高的知名度,在北美的客厅里也是屡见不鲜。如果微软去使用自己的技术增强Xbox的语音识别能力,未尝不是一个好的突破途径。
|
||||
|
||||
进入智能音箱市场的,不仅有国外的企业,也有国内的企业。国内最著名也最早的是京东,它联合的是科大讯飞。科大讯飞作为中文语音技术的先驱,经过十余年的积累,对于中文语音处理和识别技术的掌握,基本上是全球最牛的了。
|
||||
|
||||
名为“叮咚”的音箱是科大讯飞和京东合作的产物,推出的时间不算很晚,功能上差强人意,生态圈做得不算好。总体而言,“叮咚”应该不是亚马逊和谷歌的对手。
|
||||
|
||||
除此之外,国内的智能音箱还有阿里巴巴旗下的天猫精灵X1、喜马拉雅的小雅AI音箱、联想推出的联想智能音箱、小米推出的小米AI音箱,等等。这些音箱在嘈杂的环境下都很难达到亚马逊或者谷歌音箱的水平,因此从这一点来看国内的产品目前还没有什么竞争优势。
|
||||
|
||||
智能音箱的未来会怎样,我想亚马逊通过Echo二代进一步巩固了自己的地位,谷歌则凭借在人工智能领域的积累,将在智能音箱领域牢牢占据第二梯队。至于苹果和微软,多少有点“陪太子读书”的感觉,怎样看都有点晚了。
|
||||
|
||||
国内的音箱我不太好评价,但是我想做好智能音箱对于很多技术的要求都很高,国内的音箱是不是能够一骑绝尘,目前来看还需要一段时间。一个比较好的方式其实是微软带着技术来和国内诸多的音箱生产厂商合作,这样倒是很可能创下一个双赢的局面。
|
||||
|
||||
|
||||
|
||||
|
||||
41
专栏/技术与商业案例解读/035智能音箱的战斗:白马非马.md
Normal file
41
专栏/技术与商业案例解读/035智能音箱的战斗:白马非马.md
Normal file
@@ -0,0 +1,41 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
035 智能音箱的战斗:白马非马
|
||||
有关智能音箱的故事就暂时告一段落了。记得中国古代伟大的逻辑学家公孙龙提出过一个著名的逻辑问题,就是“白马非马”,这个说法特别适用于智能音箱领域,即“智能音箱非音箱”。
|
||||
|
||||
智能音箱之所以能火起来,首先是因为以语音为媒介的交互手段有着天然独特的优势。通过语音的交互手段,人们可以很方便地做一些以前不能做的事情。
|
||||
|
||||
从这个角度看,智能音箱里面作为音箱的属性是不重要的,作为接受语音命令并进行交互的属性是很重要的。亚马逊最初推出智能音箱的时候,重点还是打造一款有语音控制功能的音箱,所以语音助手Alexa在最初的版本里是附属于Echo音箱的。
|
||||
|
||||
但是亚马逊很快就发现,市面上对智能音箱感兴趣的用户,播放歌曲只是其使用的很少的一部分功能,更多使用的功能包括对各种智能家居,比如智能灯泡、智能门锁、智能温控器,以及智能窗帘等等的控制。试想一下,你只要躺在床上,喊一声“关灯”,就可以美美地睡觉,是多么美好的一件事情啊。
|
||||
|
||||
所以亚马逊很快调整了战略布局。在新的战略布局里,亚马逊把语音助手独立出来,使之成为一个平台:一方面它可以存在于各种硬件上,这些硬件有亚马逊自己开发的,也有第三方开发的;另外一方面则是开放第三方平台,让第三方的应用和设备作为被控制方,接入到这个语音平台里来。
|
||||
|
||||
这个布局和转型的目标非常清晰,就是把握语音这个新的交互通道和入口,形成一个事实上的生态圈,在生态圈里有很多企业加盟,而以亚马逊的技术为主导。这个目标正在实现中,而且一旦真的实现了,就如同谷歌占据了搜索、Facebook占据了社交一样,必然是一个非常庞大又很有影响力的生态圈和入口。
|
||||
|
||||
从战略实施来看,亚马逊很成功。向它发起挑战的其实就只有谷歌。早年搜索的成功让谷歌明白,任何一个交互的入口,和这个入口下诞生的生态圈都是非常可怕的。即便不能成就谷歌或者Facebook如此庞大的市场,它起码也不容小觑,所以谷歌在智能音箱上的发力可谓稳、准、狠。
|
||||
|
||||
和亚马逊比起来,谷歌的优势就在于自己一直都是做入口做生态圈的,它不仅仅把握了搜索的入口,而且对智能家居觊觎已久。所以谷歌这方面是很有积累的,只不过一直没有找到正确打开这个智能家居入口的方式而已。等亚马逊机缘巧合地展示了这方面的打开方式,谷歌迅速杀入也就可以理解了。
|
||||
|
||||
智能音箱的交互对于人工智能的技术要求很高。而对于人工智能技术的积累来说,全世界没有第二家公司敢说比谷歌的技术储备更厉害更牛了。因此,谷歌的智能音箱在交互上也更自然。
|
||||
|
||||
但是亚马逊毕竟是耕耘生态圈那么久,而且本身是执行力很强的公司。亚马逊和谷歌两者之间最后谁能赢,还是各自占据半壁江山,都还是不好说的事情。
|
||||
|
||||
至于苹果公司,我有时候在想,领导人的决策真的非常重要。苹果公司真的是认认真真在做一只音箱,可是这世界上这么多专业的音箱制造厂商,苹果音箱真正的卖点在哪儿?
|
||||
|
||||
苹果公司很早就有了语音助手Siri,但是到今天都似乎未能明白语音入口和生态圈的意义。认认真真做最好的音箱,似乎像个笑话。如果看不明白“智能音箱非音箱”这个道理,就无法在这场战役里面真正分一杯羹。
|
||||
|
||||
微软可能是明白了智能音箱到底是怎么回事,但是对这个领域似乎不是那么上心,更像是玩票。给各大音箱厂商提供技术支持,自己不做音箱,这个套路怎么那么熟悉呢?当年PC机市场微软就是这样玩的,自己提供Windows,机器让各大厂商去做。
|
||||
|
||||
只是这个套路移植到“智能音箱非音箱”的智能音箱领域,我看多半悬。没有入口没有生态圈,靠着一堆只会做放音乐的音箱的兄弟们组团,和有着客户至尚、反应神速、对市场感觉极好的亚马逊,以及一直以来坐拥搜索入口、知道怎么建立生态圈,并且拥有世界最顶级人工智能黑科技的谷歌,微软这场战役,尚未打感觉就已经出局了。
|
||||
|
||||
在我看来,“智能音箱非音箱”,最后比拼的就是语音助手这个入口和围绕语音控制建立的生态圈。亚马逊有很好的客户群和先发优势,谷歌则有着做入口和生态圈的经验,以及强劲的人工智能技术的支持,双方都各有优势,也都各有需要提高的地方。
|
||||
|
||||
这很可能是一场持久战,最后的结果也就是楚河汉界,双方各自占一部分阵营,五五开或者四六开都是有可能的。苹果这家公司,或许连战争在打什么都还没看明白,若果真如此就只有出局的可能了。至于微软,“陪太子读书”的可能性最大。
|
||||
|
||||
|
||||
|
||||
|
||||
63
专栏/技术与商业案例解读/036如何透过一个领域去联合分析多家企业?.md
Normal file
63
专栏/技术与商业案例解读/036如何透过一个领域去联合分析多家企业?.md
Normal file
@@ -0,0 +1,63 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
036 如何透过一个领域去联合分析多家企业?
|
||||
有的时候,分析企业如果只看一家通常会有局限。如果联合多家企业一起分析,那么在对比这些企业的过程中,很可能产生有价值的新发现。
|
||||
|
||||
但是,如果我们不对被分析的企业们做一定的限制,联合多家企业进行的分析又可能变成泛泛而谈,因为即使都是互联网企业,企业和企业之间做的东西也会不一样。
|
||||
|
||||
那么,如何能够做到既避免局限,又避免泛泛而谈呢?结合一个特定领域去联合分析多家企业就显得非常有成效了。
|
||||
|
||||
因为结合一个特定领域去联合分析多家企业,既避免了分析单个企业时的局限性,又把这些企业的行为限定在了同一个特定领域,使得企业行为或多或少地对齐,有更好的可比性。
|
||||
|
||||
为了便于理解如何透过特定领域去联合分析多家企业,我以智能音箱这个领域为例,带你看看我是怎么分析亚马逊、谷歌、苹果、微软这几家公司的。
|
||||
|
||||
作为分析的第一步,我们首先要问一个问题:对于同样一件事情,不同的企业是怎么做的?具体到智能音箱这个领域,那就是问亚马逊、谷歌、苹果和微软分别是怎么做的。
|
||||
|
||||
亚马逊开始卖Echo时很成功,但有点误打误撞的味道。之后亚马逊从用户到底喜欢通过智能音箱来做什么这一反馈上迅速发现,在智能音箱上的语音平台很重要。于是,它把语音从智能音箱里面独立出来,让用户可以通过语音完成各种各样的事情,再把第三方厂商都接进来,最后做成了一个平台。
|
||||
|
||||
谷歌进入市场的做法和亚马逊很像。它也是强调智能音箱作为智能家居的控制中心,通过音箱让用户去完成各种各样的事情;它也在努力建立自己以语音为接口的平台,让第三方厂商都接入进来。
|
||||
|
||||
然而苹果进入市场的做法,和上面两家不同。苹果的音箱主打好音质,而不是音箱的智能性,因此在宣传和演示中一直在着重强调音质。至于用户如何通过语音控制去完成各种事情,反倒不是重点。
|
||||
|
||||
微软进入这个市场的做法,和上面几家又都不太一样,极具自己的特色。微软本身不做任何音箱,而是联合传统音箱制造厂商,结合微软的技术和传统厂商的硬件制造功能出品智能音箱。
|
||||
|
||||
接下来看分析的第二步,我们要进一步追问:这些企业为什么会这样做?
|
||||
|
||||
仍然以智能音箱领域为例,亚马逊的做法是因为它通过对市场的快速反应能力,判断出了“建立生态圈,以语音为入口”是正确的发展途径。而亚马逊之所以具备这种快速的市场反应能力,细究下去,主要是源于亚马逊企业的特质,并切实体现在亚马逊的领导力准则上。
|
||||
|
||||
谷歌为什么会这样做?原因就很不一样了。谷歌在智能家居领域的尝试可谓由来已久,从未间断。但是各种尝试却一直未能让它找到一个切实有效地切入这个市场的方式,直至看到亚马逊歪打正着的智能音箱,和由此带来的语音控制是切实有效的市场切入方式。于是,它迅速跟进了。
|
||||
|
||||
谷歌对于做生态圈比亚马逊更有先天优势。因为不管是搜索还是安卓,都是谷歌成功建立的生态圈。所以谷歌一上来就知道语音是入口,战斗的本质是建立另外一个生态圈。
|
||||
|
||||
苹果为什么会从音质的角度切入,其实颇不好分析。我个人的结论是,苹果因为自身的局限,没能够明白智能音箱里智能才是本质,音箱本身并不重要。事实上,苹果觉得播放效果这个传统音箱最重要的属性,在智能音箱里依然是最重要的。正是因为做出了不同的判断,苹果也就有了不同的发展。
|
||||
|
||||
微软在智能音箱上的策略,其背后的原因比较好分析。微软的这个模式和当年联合各大个人计算机制造厂商以共同对抗苹果机的做法如出一辙。那时,微软只做操作系统,各大个人计算机制造厂商做机器,现在微软把这个做法沿用到了智能音箱上而已。
|
||||
|
||||
作为分析的第三步,我们把这几家企业怎么做和为什么这样做放在一起做个比较。通过比较,你可以得出有关这个行业和这些企业的更深层次的结论。
|
||||
|
||||
同样拿智能音箱做例子。通过看几家企业不同的行为方式可以发现,至少亚马逊和谷歌在某些方面达成了一致看法。也就是说,智能音箱是一个以语音为手段的入口,用户通过语音来完成各种各样的事情。所以智能音箱的发展重点在于“智能”,目的是建立起一个生态圈,让第三方厂商都接入进来,以自己的技术为主导。
|
||||
|
||||
这个发展方向看起来是对的,但是苹果选择了另外一个方向。到底是亚马逊、谷歌的道路正确,还是苹果的道路正确,这是第三步里面需要分析的。
|
||||
|
||||
而微软采取了当年做PC市场的做法来做智能音箱。“新时代,老打法”能成功吗?这也同样是这一步可以去仔细分析的。
|
||||
|
||||
作为这一步分析的重中之重,你可以试着回答一下,这四家公司,到底谁会在这场战争里取得胜利。我在前面智能音箱系列里的结论是谷歌和亚马逊将平分天下,其他两家就没什么前途了。
|
||||
|
||||
总结来说,对一个特定领域的多家企业联合进行分析,主要分三个步骤:
|
||||
|
||||
|
||||
分析每家企业是怎么做的;
|
||||
分析每家企业为什么要这样做;
|
||||
把企业的做法放在一起对比分析,得出关于行业和企业的更深层次结论。
|
||||
|
||||
|
||||
作为第三步分析中比较重要的一个问题,我们要分析预测一下到底哪家企业会在这个行业里取得优势。
|
||||
|
||||
这种分析方法的好处是可以由浅入深、由窄到宽。不但可以通过对不同企业在一个领域内不同行为的分析,让你更好地理解这个领域,而且可以更深入地理解每一家企业。
|
||||
|
||||
|
||||
|
||||
|
||||
71
专栏/技术与商业案例解读/037管中窥豹之从面试看企业文化:微软.md
Normal file
71
专栏/技术与商业案例解读/037管中窥豹之从面试看企业文化:微软.md
Normal file
@@ -0,0 +1,71 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
037 管中窥豹之从面试看企业文化:微软
|
||||
窥一斑而知全豹。对于一个企业来说,能够为大众所知,展现给公众的东西总是有限的;然而这种有限的展示所暴露出来的,往往是一些非常深刻而意义深远的企业文化。今天,我带你从企业的面试这个环节,来分析一下北美互联网公司的企业文化。
|
||||
|
||||
今天的主角是微软。微软成立30余年,已经是世界上最为知名的软件开发公司了。尤其是在新CEO萨提亚的带领下,它成功实现了从软件开发公司向云计算公司的转型,焕发出了第二春。与此同时,微软有着深厚的技术积累和底蕴,在新出现的人工智能浪潮里自然也不甘落后。
|
||||
|
||||
研究这样一个有着历史积淀,取得了无数成就,又一度彷徨不知何去何从,最后成功转型的公司,注定会很复杂。但是,微软的面试流程可以用来揭示这个企业里一些本质的东西。
|
||||
|
||||
和大部分互联网公司一样,微软的面试分电面和现场面试两种。电面就是指电话面试,然后利用互联网的便捷性,在共享白板上让面试者做一道面试题。微软通常只有一轮电面,后面直接进入现场面试阶段,或者整个面试就此结束。微软的电面并无特色可言,我就不展开说了。
|
||||
|
||||
我着重说一下微软的现场面试,因为它透露着浓厚的微软特色。除去人力资源不算,一个面试者通常会见3~5个面试官。之所以是个不定数,这取决于面试者的表现。如果前4轮面试里面有3个人拒了,面试者就不会见到第5个面试官。
|
||||
|
||||
在5个面试官里,最后一个面试官很特殊,他这一面可以理解为终极面试。微软能够做终极面试的人不多,因为这需要在公司内部获得一个特殊资格,这个资格在微软还有个正式名称,叫作As Appropriate,简称AA。我不知道这个称呼中文怎么翻译合适,所以接下来我们姑且就简称为AA吧。
|
||||
|
||||
AA面试官有代表微软的权利,也就是说他有决定权,可以决定这个人是招还是不招。当然有些AA面试官会综合考虑前面几位面试官的意见,讨论之后再做决定。
|
||||
|
||||
理论上来说,AA面试官只要觉得这个人可以招,哪怕前面一堆人都说Weak Hire之类的话,也就无所谓了;反之,AA面试官只要觉得这个人不可招,前面面试打分都非常高也没有什么意义。所以,AA面试官就是“终极裁判”,一旦你进入了AA面试环节,那么前几轮面试官的意见也就不那么重要了。
|
||||
|
||||
那么,你可能会问了,其他面试官的作用是什么呢?主要有两个。
|
||||
|
||||
|
||||
一个是决定面试者能不能够见到AA。AA们可都是微软里面的大人物,时间非常宝贵,不是每个面试者都有机会见到的。微软的规定非常简单:前4个人里面有3个说了No Hire,面试自动终止。
|
||||
另一个作用是为AA提供材料。这样AA就可以参考前面的面试情况,结合自己多年来的工作经验,以及公司的需要等等,去决定如何面试,以及怎么给Offer。
|
||||
理解了AA这样一个角色之后,我们还要理解另外一点。在微软,不存在其他公司那样所谓的General Hire。General Hire是谷歌、Facebook等硅谷新竞公司常用的方式。简单来说,这种面试,并不是为某个特定的职位招人,而是为全公司以统一的标准招纳合格的人才。
|
||||
|
||||
|
||||
微软的招聘,AA面试官通常就是一个组的大领导,而其他面试官要么是面试者的同事,要么是隔壁组的老王。微软招进来的,实际上也就是要和这个组一起干活的人。
|
||||
|
||||
更重要的一点是,通常来说AA面试官会安排其他的面试官。不仅仅是当天前几轮的面试官,之前电面的面试官,通常都是由AA面试官来安排的。当然现实里,有可能是AA面试官下面某个部门的小领导代表AA面试官来安排。
|
||||
|
||||
综上,微软的面试环节,其实代表了微软文化里面非常重要的几个特点。我来展开说一下。
|
||||
|
||||
一、自上而下的管理风格
|
||||
|
||||
第一个特点是微软典型的自上而下的管理风格。什么意思呢?就是领导需要对上级负责,不一定需要对下级负责。很多时候,对下级负责的主要原因,只是满足对上级负责的需要。
|
||||
|
||||
领导选择只对上级负责的原因,很大一部分是因为上级对自己的职业发展,以及自己获得公司里面享有特定权力的资格有着决定权。举例来说,AA的资格表示可以代表微软招人,这个资格在微软内部是很重大的一项权益。但是,一个人要拿到AA的资格,在微软内部是一个非常漫长烦琐的过程,而且必须得到上级,乃至上级的上级的鼎力支持。
|
||||
|
||||
这个过程,首先是大领导需要开启一个培训计划,大领导需要在一个相当高的级别。这个培训计划被更高的级别批准以后,就会对要获得AA资格的申请人进行长达一年的培训和一系列的考核。
|
||||
|
||||
在这个考核过程里,要获取AA资格的人会实际上先需要在公司里已经带一个大团队,手下会有小领导汇报给他,同时这个人还会被专门配备导师从而获得专人辅导。这类导师,通常是在微软内部非常资深的,有多年大团队管理经验的人。在经过一年培训和一系列考核之后,候选人最终才有可能拿到这个权益。
|
||||
|
||||
但是,一个大领导之所以愿意花费这样大的力气去培训一个人,很多时候不仅仅是因为这个人有能力,更是因为这个人是自己人。因为具有了AA资格以后就有了很大的权力,所以大领导在让谁具有AA资格这件事情上,通常都比较谨慎。仅仅本人够牛还不行,候选人和大领导是不是一条心,也非常重要。
|
||||
|
||||
大家都希望从一个“阶级”跃迁到另外一个“阶级”,但是这种阶级的跨跃主要取决于上面的人怎么看。因此,一个领导对于下面的人怎么看自己,就不是多么注重了。除了要避开一些禁区,比如说性骚扰、歧视之类的事情,其他方面往往就有敷衍的成分。
|
||||
|
||||
比如说,在北美企业里,领导和员工往往每周有30分钟的一对一会议,简称one:one。理论上讲,one:one是领导和下属交流的重要时间,领导应该要花很多时间和他手下的人一个一个的one:one。但是实际上来说,你和大领导的one:one印象很可能就是:大领导其实根本不在乎你。无论你做得好或者不好,都不在他的视线范围内。他只是需要完成公司给予的、必须要有的one:one而已。
|
||||
|
||||
二、领导者极大的自由裁量权
|
||||
|
||||
第二个特点是在一定的级别和一定的资格下,领导有着无限大的自由裁量权。微软将这种放权发挥到了极致:一个项目一旦指定了负责人,那么这个负责人对于所负责项目在人事、资源等等的分配上,拥有极大的决策权。
|
||||
|
||||
这种权力在AA资格上的体现,就是微软很多地方都有典型的“任人唯亲”现象,有AA资格的“老板”,周围往往有很多的朋友和以前的下属。一个项目被抢下来,或者有AA资格的领导去了一个重要的新岗位,就需要招人了。在招聘的时候,他完全可以安排一个面试流程,顺利地让朋友通过面试见到自己,最后批下来。
|
||||
|
||||
久而久之,微软内部就形成了“一个圈子加一个圈子”的格局。每个牛人占据了一块地盘,然后就可以随心所欲地招聘自己喜欢的人,“面试的公平公正”在微软里面就被挤压了。
|
||||
|
||||
所以到微软找工作,要找到合适的、具有发挥空间的位置,你的领导到底和你是不是一个圈子的,你的领导愿不愿意挺你,非常重要。
|
||||
|
||||
如果这些都没有的话,那么在微软里面的发展空间会非常有限,无法成为公司里面重要的人。
|
||||
|
||||
在这样的环境下,在微软里面滋生出了无数个大大小小的团体。这种团体的领袖当然是那些有资格决定别人命运的人,而团体下面的各种人,或者是干活水平牛的,或者是和领导们关系不错的。还有在团体之外的人,往往就是干活很多,水平也不错,升级却很慢的。
|
||||
|
||||
综上所述,微软的招聘过程是自成体系很有特色的。在微软里面,具有AA资格的人有代表公司决定是否聘用的最终决定权。这套制度导致微软形成了一种自上而下的管理模式,领导主要对上级负责。而具备一定资格的领导人,在微软里面有着非常大的自由裁量权,进而导致微软内部小团体滋生的局面。
|
||||
|
||||
|
||||
|
||||
|
||||
63
专栏/技术与商业案例解读/038管中窥豹之从面试看企业文化:亚马逊.md
Normal file
63
专栏/技术与商业案例解读/038管中窥豹之从面试看企业文化:亚马逊.md
Normal file
@@ -0,0 +1,63 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
038 管中窥豹之从面试看企业文化:亚马逊
|
||||
上一次,我们聊到了极具历史积淀的微软的面试方式,以及从中折射出来的企业文化。今天,我想说说西雅图地区、华盛顿湖对岸的另外一家著名的互联网企业:亚马逊。
|
||||
|
||||
亚马逊的显著特点是它极为注重其著名的领导力准则,亚马逊的企业文化被它的创始人杰夫 · 贝佐斯(Jeff Bezos)以14条领导力准则的形式公布在了网站上。
|
||||
|
||||
亚马逊非常注重企业文化,它的领导力准则被贯彻到了企业运营的方方面面。作为企业运营非常重要的一部分,招聘面试自然也是时刻体现亚马逊的领导力准则,其面试过程成了以领导力准则为总纲的企业文化的缩影。
|
||||
|
||||
一个典型的亚马逊面试,大体上和其他企业差不多。首先,面试者会经历一到两轮的电话面试,以考察技术为主。通过电话面试以后,他就会被邀请到亚马逊的办公场所进行现场面试。现场面总共有五轮。
|
||||
|
||||
1. Bar Raiser:企业文化的守护者
|
||||
|
||||
上次我讲到,微软的面试有一个非常有特色的角色:具备AA资格的面试官。这个面试官出现在最后一轮,代表微软决定是不是要聘用这个面试者。在亚马逊的五轮面试里,当然不会出现微软具备AA资格的面试官,但是亚马逊的五轮面试官里面也有一个非常特殊的角色:Bar Raiser。
|
||||
|
||||
Bar Raiser的概念来自于亚马逊美国总部,原指在跳高比赛中,一次次将杆调高的工作人员。在亚马逊里,Bar Raiser则是一群在招聘过程中,负责从亚马逊的企业文化以及行为准则的角度考察应聘者,从而维护招聘质量的人。
|
||||
|
||||
亚马逊的五轮面试里,有四轮是由招人部门的面试官负责,一轮是Bar Raiser。Bar Raiser可以从公司的任何部门过来,可以出现在这五轮面试里面的任何一轮。Bar Raiser并不单独决定这个人是否可以被聘用,但是具有一票否决权。简单来说,哪怕其他四轮所有的人都想聘用面试者,如果Bar Raiser不同意,也是不可以的。
|
||||
|
||||
Bar Raiser体现了亚马逊领导力准则里的“选贤育能”,具体来讲是:领导者不断提升招聘和晋升员工的标准。这个角色起源于亚马逊早期的时候,贝佐斯亲自参与每个人的招聘环节。贝佐斯的观点是,每个新进员工必须高于亚马逊的平均水平。这样一来,亚马逊的员工素质就会不断被拔高。
|
||||
|
||||
但是后来亚马逊的规模越来越大,贝佐斯自然不可能有那么多的时间去参与每个人的招聘,于是Bar Raiser也就应运而生了。Bar Raiser代表着一批亚马逊人。他们在公司工作已久、经验丰富,对亚马逊的文化非常了解。他们的作用是代替贝佐斯去参与每一场面试。在这里,他们代表贝佐斯,对于那些可能降低亚马逊整体水平的人说不。
|
||||
|
||||
2. 领导力准则的面试
|
||||
|
||||
除去Bar Raiser这个很特殊的角色以外,亚马逊的面试过程,和很多互联网公司也大相径庭。其最为典型的不同之处在于,亚马逊的面试过程中,每一轮除了技术问题以外,都会针对亚马逊的14条领导力准则里面的一条或者若干条进行提问。
|
||||
|
||||
面试官会大量测试每个人在不同情况下会怎样处理事情,借此去判断这个面试者是否符合亚马逊的某些领导力准则,到底有多符合。在所有面试结束以后,这些面试官聚在一起讨论的时候,领导力准则是最为重要的一部分。
|
||||
|
||||
据我认识的做过亚马逊面试官的朋友讲,技术问题回答得不好,但是领导力准则表现非常突出,这样的人被亚马逊聘用的概率不低。相反的,技术问题回答得很好,但是领导力准则表现有很不好的地方,这样的人基本上亚马逊不会招。
|
||||
|
||||
现来来看亚马逊面试里体现亚马逊领导力准则的另外一个表现。2017年的时候,亚马逊对校招人员的面试方式进行了大规模的改革。具体来说,就是从两轮电话面试和五轮现场面试简化到了如下两步:
|
||||
|
||||
|
||||
第一步是去在线网站做一个测试,这里面会有几道题目;
|
||||
第二步是通过视频和招聘经理聊一聊,就其中的某道题讲一讲如何解答。
|
||||
|
||||
|
||||
这次流程的简化体现了两条重要的领导力准则:创新简化和勤俭节约。前者鼓励亚马逊的每个人尽可能地简化流程,后者则把“以更少的投入实现更大的产出”放到了企业领导力准则的高度。
|
||||
|
||||
3. 高离职率的背后
|
||||
|
||||
和很多企业不同,亚马逊的员工流动率很高。通常来说,如果一个人在亚马逊待了18个月,那就超过很大一部分的亚马逊员工就职时间,是不折不扣的老员工。而在其他企业,比如谷歌、Facebook、微软等,18个月还是不折不扣的新员工。然而贝佐斯并不担心这种高离职率。他觉得大浪淘沙,留下来的都是真正符合亚马逊企业领导力准则的人,是亚马逊真正需要的人。
|
||||
|
||||
因为这个特色,亚马逊每年都要招很多的人,有大量的面试,而在校生的面试比例尤其高,这让亚马逊在招聘方面的费用居高不下。我和亚马逊内部一些制定招聘流程的人聊过天儿,得知亚马逊内部对于简化校园招聘的想法由来已久。
|
||||
|
||||
之所以后来简化成了这样,有很多方面的考虑。
|
||||
|
||||
|
||||
一方面是刚从学校毕业的学生并无太多工作经验,所以只需要检测其基本的编程能力和对计算机知识的掌握程度即可。基于这个方面考虑,在线测试系统足矣,五轮现场面试并非必要。
|
||||
另外一方面是对刚从学校毕业的学生测试企业领导力准则是一件不易的事情。长期以来亚马逊的招聘也证明,与其花大精力测试领导力准则,不如大量招新人,然后自然淘汰,能够经受住考验留下来的自然是公司需要的人。 新生一张白纸,可塑性强。很多人即便是最初面试时领导力准则表现不佳, 在亚马逊的大熔炉里也可以迅速被改造,成为领导力准则的标兵。
|
||||
|
||||
|
||||
不过,这种做法并非没有弊端。2017年出现过多起入职3个月就被开除的事件,以及沸沸扬扬的亚马逊员工跳楼事件,都给亚马逊的这种粗犷式招聘和自然淘汰的模式带来了很多挑战。
|
||||
|
||||
总结一下今天的故事,亚马逊整个公司的行为准则以领导力准则为核心,而面试则是这种以领导力准则为纲的一个缩影。而另外一方面,亚马逊在校招面试流程上的创新,恰恰是亚马逊领导力准则的实际体现。
|
||||
|
||||
|
||||
|
||||
|
||||
71
专栏/技术与商业案例解读/039管中窥豹之从面试看企业文化:谷歌.md
Normal file
71
专栏/技术与商业案例解读/039管中窥豹之从面试看企业文化:谷歌.md
Normal file
@@ -0,0 +1,71 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
039 管中窥豹之从面试看企业文化:谷歌
|
||||
今天让我们把目光从西雅图转向湾区。在硅谷十余年的新兴企业里,谷歌无疑属于最早一批,也是最具有代表性的一个。这批企业实行的面试方式,或多或少都是“谷歌系”,或者照搬,或者是改良版。
|
||||
|
||||
因此,通过理解谷歌的面试方式,以及谷歌面试方式里面反映出来的企业文化,不仅仅对于我们了解谷歌很有意义,对了解谷歌之外的其他湾区企业同样有意义。那么,现在就一起了解谷歌面试和它揭示的谷歌企业文化吧。
|
||||
|
||||
谷歌的面试方式和微软、亚马逊的大不相同,主要体现在面试者和做决定发不发Offer的人之间是分离的。
|
||||
|
||||
与其他公司一样,谷歌也是先进行一到两轮的电话面试,然后再进行五轮的现场面试。
|
||||
|
||||
在谷歌,现场(Onsite)面试可能是做系统设计也可能是编程。谷歌内部有一个极其巨大的面试题库,其中包罗万象,题目众多,多到即使是谷歌内部的人也不一定能看完。此外,面试官也经常准备自己独有的面试题,而不从题库拿题。
|
||||
|
||||
谷歌面试的特点,简单说就是“非常难”,而且变化多端。有时候题目不但难,还很新颖,所以面试者必须足够聪明,否则在谷歌这种面试环节下,基本上没有可能成功。网上就有过业界著名开源软件的作者、公认的领域内辨识度很高、水平很牛的人去谷歌面试,然后被pass的例子。
|
||||
|
||||
谷歌的每个面试官在面试完后要准备一个面试评价报告,这个评价报告里会有整个面试非常详尽的流程,包括面试了什么题目、面试者在白板上写的程序具体是什么样的、面试者和面试官是如何交流的。这个报告很长,很多时候其撰写时间甚至比面试时间还长。每个面试官可以从“非常不想招”到“非常想招”这样的角度为面试者打分,具体分5等:非常不想、不想、中立、想、非常想。
|
||||
|
||||
5轮面试官的面试和评价都是独立的。这个过程里面,当5份“包裹”被送到HR手中时,HR基本上可以根据分数来决定到底要不要将“包裹”送去一个叫作委员会的地方。委员会是谷歌评价面试者的场所,在这里公司委员会成员定期开会,就每个面试者的这些“包裹”进行讨论,决定是不是要进入下一步。
|
||||
|
||||
委员会通常做出几种决定:招、不招、加面,或者“有条件的招”。招、不招、加面都好理解,“有条件的招”则涉及谷歌整个招聘流程里的另一个程序,我等下详细解释。
|
||||
|
||||
委员会做出决定的因素很多,包括面试者的面试表现,从什么学校毕业、是不是PhD等背景情况,以及有没有专长等,还有公司现在招人是有很多的预算还是没有。到后来,因为保证女性以及特定种族需要占足够多的比例的需要,这个人是男性还是女性,是什么种族,都有可能成为考量的因素。
|
||||
|
||||
如果一个面试者不止一次来面过谷歌,那么不仅仅这次面试的表现,过往面试的表现也同样会被考量。我就听说过有一次面试表现很好,但是过往面试表现很差的例子,那位面试者最后被加面了两轮编程,最终被拒。
|
||||
|
||||
委员会的决定并不是终审。这个决定还会送给公司的资深副总裁,早年的时候还不是资深副总裁,而是递交谷歌的两个创始人之一亲自审阅每个Offer。在这里,资深副总裁有权力改变委员会的决定,不招的可以招,招的可以不招。
|
||||
|
||||
如果说最后的结果是“招”或者“有条件的招”,那么会进入下一个环节。这个环节叫作“队伍匹配”。简单来说,所有候选者都会被放入一个内部的资料库,而那些需要招人的经理们则可以查看这个资料库,对候选者发出邀请。这种邀请包括了招人的经理再度和候选者聊天,然后确定兴趣的过程。
|
||||
|
||||
在这个过程里,有些人有多个队伍喜欢,所以自然也就有了选择权,有些人只有一个队伍喜欢,当然面试者可以等待合适的机会。“有条件的招”和“招”的区别在这个地方体现出来了,招的人可以慢慢匹配下去,谷歌有足够的耐心给很久的时间。
|
||||
|
||||
“有条件的招”的人,会给一个固定期限,比如说两到三个月,或者是到某年年底之类的。这个时间段内没有队伍要这个人,或者这个人挑三拣四的话,那发出去的Offer就作废了。
|
||||
|
||||
谷歌的面试是一个非常难的过程,难到什么程度呢?有个小道消息说,大约一万份简历里面,能招进去一个人。谷歌的面试也方方面面体现出了“难”,而我们要谈的“难”还体现在另外一个方面。如果谷歌的员工在离开后再次入职,只要级别不变,不需要再次面试,但是谷歌早就过了大规模扩张期。近几年来创业潮回落,而谷歌的待遇优良,每年都有很多谷歌前员工回谷歌,占用了不少招聘名额,这就导致了非谷歌前员工的名额进一步减少。
|
||||
|
||||
另外一方面,谷歌有着比其他公司更为苛刻的面试失败后的惩罚措施。和其他公司一样,一个人如果面试谷歌失败,也需要经历所谓的冷冻期,这个冷冻期一般是一年。和其他公司不同的是,如果一个人现场面试谷歌 3次,而这3次都失败了,谷歌会终身禁止这个人面试相同或者类似的职位。
|
||||
|
||||
是不是有例外,我想可能还是有的。毕竟如果一个人真的足够优秀,成为业界翘楚,而谷歌又缺乏这样的人才,咸鱼可以翻身;然而大部分的人,一旦三次失败以后,以前那些LinkedIn上和蔼可亲又有耐心的谷歌招聘人员将销声匿迹。如果你给谷歌网站投简历,10分钟以后自动拒你,这就是谷歌。
|
||||
|
||||
从谷歌的面试,我们可以看到这个企业的什么特点呢?
|
||||
|
||||
|
||||
首先,这个企业只要最优秀的人,整个面试过程就是为了招聘到最优秀的人所设计的。如果一个人能够过五关斩六将过了那么多轮,怎么样都不可能太差,所以“优秀”就是谷歌员工的代名词。
|
||||
|
||||
|
||||
据说早年,谷歌不但要看面试表现,还要看本科院校,以及高中升本科时各科考试成绩等等方面;而三次面试以后,你有可能终身失去面试谷歌的机会,简而言之就是三次以后可以断定这个人“不优秀”,谷歌没必要再浪费时间精力了。
|
||||
|
||||
|
||||
其次,谷歌的面试流程,是为了优化谷歌自己的利益。至于对于面试者是不是公平,那就不重要了。这句话怎么理解呢?我用一个说法来举例吧。因为谷歌面试的难度和随机性,即使最聪明的人也不能保证不被pass。已经进入谷歌的人,如果让他们重新走一遍面试流程的话,恐怕很大一部分是极有可能会挂掉的。
|
||||
|
||||
|
||||
但是回过头来看,连这样难度和随机性的面试流程都能够通过,说明这个人肯定足够优秀。否则,运气需要多好,才能让一个人在如此严苛的面试里蒙混过关呢。当然,“命好”同样是人“优秀”的一部分。
|
||||
|
||||
所以我们可以这样说,也许有无数多优秀的人被pass掉了,但是能够过关的,几乎不可能不优秀。这就是谷歌企业文化里面非常重要的一部分。
|
||||
|
||||
那么这些优秀的人被招进去,是不是都干着优秀的人应该干的活呢?这也未必,我想很多时候,这些人干的活也许不需要那么优秀的人去做;但是没关系,谷歌还是要招这样的人。
|
||||
|
||||
面试的队伍匹配过程也体现了谷歌对公司利益的优化。那些不是特别优秀的人,估计只有那么几个队伍会看上。从结果来看,为了进谷歌,这些人只能去做公司需要,自己却未必那么喜欢的项目了。
|
||||
|
||||
谷歌可以这样去招人是有一个大前提的。这个大前提是在可以大量得罪优秀人才的面试规则下,依然有无数多的优秀人才愿意前赴后继去谷歌面试和工作。
|
||||
|
||||
这个前提靠的是什么?谷歌这方面特别实在,特简单,就是:钱多。只要谷歌给的薪水足够高,那么就会源源不断地有人去投身谷歌。
|
||||
|
||||
实话实说,在薪水方面谷歌的确非常大方,与微软、亚马逊自然是不可同日而语。我想只要谷歌可以一直这样发钱发下去,那么谷歌这种万中挑一、队伍匹配、3次挂掉之后终身禁面的苛刻面试流程,就一定会有它的存在空间。毕竟,没有人和钱过不去。
|
||||
|
||||
|
||||
|
||||
|
||||
69
专栏/技术与商业案例解读/040管中窥豹之从面试看企业文化:甲骨文.md
Normal file
69
专栏/技术与商业案例解读/040管中窥豹之从面试看企业文化:甲骨文.md
Normal file
@@ -0,0 +1,69 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
040 管中窥豹之从面试看企业文化:甲骨文
|
||||
在前面的文章中,我们清楚了西雅图的两大著名IT公司的面试情况,也了解了湾区新贵代表者谷歌的招人方式和其背后的企业文化。
|
||||
|
||||
今天我们把目光转向湾区比较老的一家企业:甲骨文。这是和微软同时代的企业,非常具有代表性。湾区曾经的很多企业,比如思科都用过同样的招聘模式,但如今只有甲骨文还在坚守着这个古老的传统。
|
||||
|
||||
甲骨文招聘的鲜明特点主要体现在校园招聘上。和其他所有公司“英雄不问出处”的做法不同,在甲骨文其实是“唯出身论”的。
|
||||
|
||||
具体来讲,甲骨文里维护着一张名单,对世界各地不同学校不同班级的人进行了分类。人分两等,在那个名单里面是一种人,不在那个名单里面的,是另外一种人。
|
||||
|
||||
关于前者,比如我知道中国大陆地区上榜的有清华大学的本科、北京大学的本科、中国科技大学少年班和零零班毕业的学生。名单上的学校和项目特别少,美国本土可能也就不到20所学校。此外还有世界其他国家的高校。
|
||||
|
||||
其中某些学校则只允许特定的项目。比如说清华的都可以,但是中科大少年班的才可以。如果正好求学经历的某一段在名单上,那么恭喜你,进甲骨文的面试过程会非常顺利。可以这么说,凡是符合名单要求的人选,就拥有了在甲骨文全公司范围内自由面试的权利。这个过程里最痛苦的是那些实际要招人的经理们,因为HR转过去的必然是只属于这个范围的人,其他高校毕业者的简历都被筛掉了。
|
||||
|
||||
去面试的时候,这个面试过程也会让你身心愉悦,只要具备基础的编程能力,那么整个面试过程就是聊天谈心,然后等着很多组给发Offer。而基础编程能力往往就是一两轮简单的白板写程序的面试。这些面试题的难度和其他公司比普遍偏低。
|
||||
|
||||
当然也有一点不好。甲骨文的面试容易是容易了一些,工资却不高。和动辄18万美元的谷歌比起来,10万出头是比较普遍的价位;但是很多面试者依然禁不住“面试轻松,面试以后进公司工作更轻松”的诱惑。
|
||||
|
||||
那么对于名单外的人是一个怎样的世界呢?简单来说,原则上甲骨文是不会给任何面试资格的,不在名单上的人不会获得去甲骨文面试的机会。
|
||||
|
||||
对,就是这样,在21世纪的今天,还有这样的公司,对码农进行出身歧视。当然我们可以说,能够进到名校的人,肯定是比较优秀的,或者优秀的概率更高;而不能进到名校的,可能确实差一些,至少平均水平上确实有些差距。
|
||||
|
||||
甲骨文当然也没有把路给堵死。我是2009年毕业的,因为是做数据库的,所以很想面试甲骨文,但不是名单上的,怎么办呢?
|
||||
|
||||
我运气还算不错,开会的时候认识了一位甲骨文的经理,开始找工作时我给他发了一封信,说您看是不是给我一个面试机会?
|
||||
|
||||
大概是我亲身的经历,以及结合我的一个校友、清华大学本科毕业者的面试经历,让我对于甲骨文公司的奇葩面试方式有了深刻的体会。没有对比就没有伤害,我的校友迅速拿到面试通知,去面试的时候更像走过场,甚至可以在很多个组里自由选择。
|
||||
|
||||
轮到我的时候,经理先检查了一下我的学校,然后说,不好意思,你不在我们的学校名单里,原则上是不招人的;但是呢,比波士顿更北有个一年大概会有4个月下雪的城市,那里的甲骨文组正好有空缺。那地方招人难度比较大一些,如果你愿意面试那个职位呢,我可以给你走一个流程,开一个面试特例。至于这个特例能不能过,打铁还要自身硬。你自己够牛的话,就有希望。
|
||||
|
||||
于是我就这样开始了一场这辈子最为奇葩的面试历程。甲骨文的人首先让我提交了从本科开始的所有成绩单。幸亏我成绩表现不错,GPA 4.0的分数反正已经是最高分了,怎样划线都刷不掉我。
|
||||
|
||||
然后,甲骨文又让我准备了3封推荐信,其中包括我导师的一封。推荐信提交以后,大概过了一个月,我终于经历了一圈人的批准,被成功开了特例。
|
||||
|
||||
开了面试特例以后,甲骨文表示需要先进行背景调查,核实我个人提供的信息是否真实。这个核实从我的亲属关系开始,核实到了我户口在哪里、本科的毕业设计谁指导的、班主任是谁,以及我到美国后的各种经历。关键在于,甲骨文是真的去找国内的公司,给我的本科设计指导老师以及班主任打电话,一一核实了所有情况。
|
||||
|
||||
等到一切都调查清楚了,大概两个月过去了。终于甲骨文姗姗来迟地告诉我说,可以去面试了。
|
||||
|
||||
我有时候在想,人和人的差距在甲骨文的眼里可能比人和其他物种的差距还大。早知道要折腾两个月才能去面试,面试的那个地方又是那么渺无人烟的一个地方,想来想去也是不敢去的。
|
||||
|
||||
拿到甲骨文的Offer时,我早已身心俱疲。我不知道像我这样不在名单里面的人,就算进入了甲骨文,前途到底又在哪里。
|
||||
|
||||
我会有这种担心,很大程度上来源于我在面试过程中的曲折经历,与我同学的“简单轻松”形成鲜明对比。于是,面对这样一个并不尽如人意的Offer,我毫不犹豫地拒掉了。
|
||||
|
||||
甲骨文这个公司选择毕业生的方式,早年在硅谷很普遍。比如说IBM面试的时候,也会看一看学校出身。思科在它正当红的2000年前后,也维护着一个学校名单。只有那些学校毕业的人,才能够一毕业就去面试这些公司,其他人都只能先去社会上摸爬滚打,以后走社招的路进来。
|
||||
|
||||
我们固然可以说“英雄莫问出处”,但事实上甲骨文里面的很多领导确实都是名校出身。斯坦福的有之,威斯康辛的有之,常青藤的有之。作为美国教育体系里面更为庞大的州立学校的毕业者,在这些公司里面想要混得好,混得出彩,其实是相当不易。
|
||||
|
||||
我后来得知,那个给了我面试机会的领导,本人就是一个非名校背景的人。在面试时,他一直和我强调说不用担心非名校的出身,只要肯努力,一定会有出头的机会。
|
||||
|
||||
可是,“肯努力”这几个字背后究竟会是一个怎样的故事? 这个领导自己可能就是一个非典型进入甲骨文后慢慢发展起来的人。好不容易破除万难被招进去,进去以后被精英环绕,上升过程里一定是步履维艰。
|
||||
|
||||
精英文化,老的硅谷公司多少都有一些。坚定地选择从特定学校出来的所谓精英,在硅谷也是一个传统。比如说谷歌在成立早期,很多人去投简历,多半都是石沉大海,斯坦福毕业的人则非常容易拿到面试机会,这很大程度上也反映了这种精英文化。
|
||||
|
||||
但是,谷歌后来的招聘政策还是变了,虽然它依旧是以非常严苛且“不公平”的方式对待每个面试者,虽然它的招聘制度仍然会让很多真正的聪明人失去进入谷歌的机会。但无论怎么说,这都比一棍子打死,对于特定圈子以外的人连面试机会都不给,要进步和公平得多了。
|
||||
|
||||
甲骨文可能是极少数(如果不是唯一的话)、依然坚持这种面试方式的公司。即使到2017年,在甲骨文面试校招的时候,学校依然是一条红杠杠,一道天堑。
|
||||
|
||||
这种“学校为纲”的方式,自然也会在公司内部造就很多以学校为基石的圈子;所以很多人说甲骨文这个公司里面很多人很闲,人浮于事,但是政治斗争却非常严重,我想也是可以想象的。
|
||||
|
||||
如果要做一个选择,我是真心不喜欢这样的一种筛选方式。已经是二十一世纪了,我们的做事方式也应与时俱变才好。
|
||||
|
||||
|
||||
|
||||
|
||||
51
专栏/技术与商业案例解读/041管中窥豹之从面试看企业文化:Facebook.md
Normal file
51
专栏/技术与商业案例解读/041管中窥豹之从面试看企业文化:Facebook.md
Normal file
@@ -0,0 +1,51 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
041 管中窥豹之从面试看企业文化:Facebook
|
||||
从市值来看,Facebook是近年来仅次于谷歌的,在硅谷成长起来的大公司。作为一家新兴的互联网公司,它牢牢占据了社交网络的头把交椅。而从面试形式上来看,Facebook有模仿谷歌的痕迹;但是在模仿的前提下,也有它自己的特色。
|
||||
|
||||
那么我们先来看一下Facebook是如何面试的。总体上它和谷歌非常像,首先是电话面试,一般一到两轮;如果过了的话,就可以进行现场(Onsite)面试。Facebook的现场面试大概是这样一个过程:一般有四轮,第一轮是企业文化的面试外加编程考核,之后看面试者的经验,通常会有两轮的编程题和一轮的系统设计题。
|
||||
|
||||
Facebook面试结束以后,每个面试官也需要准备一个“包裹”递交到HR手中。这个“包裹”也和谷歌类似,但是不需要像谷歌那么详细。如果HR看到大部分面试官都表示“Hire”的话,整个面试材料就会被交给招聘委员会。招聘委员会确定之后,会给出“招聘”“不招聘”或者“加面”三个选项。
|
||||
|
||||
委员会决定后,也同样需要公司副总裁去审批的。这个过程里也会发生Offer出现变化的情况,但是Facebook里副总裁做出更改的概率相对低一些。
|
||||
|
||||
Facebook一个有别于谷歌的重要变化是,并不存在所谓的队伍匹配过程。招过来的所有人,会进入一个轮岗期,之后就可以自由选择自己要加入的队伍了。
|
||||
|
||||
这个过程可以说是相对于谷歌的创新。而且,这个创新举动被不少公司借鉴了,比如说著名的Airbnb。当然,因为不存在着所谓队伍匹配的过程,也就不存在“有条件的招聘”这一类型了。这一点改变对候选人其实是有利的,因为所有人只要招进来就一视同仁了,不存在着二次挑选的问题。
|
||||
|
||||
Facebook相对于谷歌面试最大的不同,其实体现在编程面试这个环节里。在谷歌,所有面试主要是挑战人的智商。说白了,谷歌是真正希望招到聪明的人,所以如果一道面试题被泄露出去,谷歌内部的题库会明确标注此题不可用。谷歌本身是刷题行为的反对者。
|
||||
|
||||
然而,对于时下非常流行的面试靠刷题的文化,Facebook不仅不反对,反而是支持的。在Facebook里面用来面试的题目,基本上都是网上大家用来刷题的原题。
|
||||
|
||||
不仅仅如此,在Facebook,如果你在45分钟内只能写出一道无Bug的题来,那就是不合格的;如果45分钟内包括聊天,还能写出两道题,那就差不多了;要是能写出三道题,那就是Facebook超级喜欢的好员工了。
|
||||
|
||||
在Facebook,哪怕你告诉面试官你是刷题刷出来的,无所谓,重要的是你能连续答对多少题。这是一个速度与熟练度的比拼,而不是一个智商和技艺的比拼。就是这样一个简单的变化,让Facebook和谷歌的面试形似而神不似。
|
||||
|
||||
那不刷题意味着什么呢?因为面试题目其实相当难,如果毫无准备的话,大部分人其实写出一题无Bug就基本上是不可能的了,更何况要两到三题。谷歌面试一般只有一道题,可能会很难,但牛人完全不需要准备也可以面试过去。一旦题目数量增长到两到三题,那么不刷题是不可能的。所以对于绝大部分人来说,刷题,并且把题刷熟练,是进Facebook的唯一选择。
|
||||
|
||||
但是我们知道仅仅靠刷题选出来的人,并不一定是最聪明的工程师。所以Facebook和谷歌在选人方式上的不同,代表着Facebook并不是要选出最聪明的人。但是能够刷熟几百题并且能够迅速做出来的人,不一定是最聪明的,但一定是既勤奋又有很多时间去刷题的。
|
||||
|
||||
所以从刷题的好坏来决定是不是录用一个人,反映了Facebook招人里面两条非常重要的筛选原则:人勤奋,有足够多的时间刷题(或者“工作”)。
|
||||
|
||||
从Facebook的实际工作强度,和相对于其他公司更严格的考评体系来看,也反映了Facebook用人的准则。Facebook的考评分7档,一个季度考评一次。其中最高档的奖金和最低档的差距非常大,前者可以是工资的好几倍,后者是0。连续两次考评不合格的会被解职。而一般公司一年会有一次正式的考评,在半年的时候会有一次简单的非正式年中考评。
|
||||
|
||||
Facebook更具特色的是,考评的好坏,有一项指标就是写的代码数量。也就是说,多写了程序的,总是要比少写程序的人得分更高。所以很多Facebook的员工,基本上一年四季,一周七天,一天10多个小时地工作。这种工作方式,不太像国外成熟的互联网软件公司,更像国内的成熟的互联网软件公司。
|
||||
|
||||
这种方式的好处是公司效率很高,产品迭代很快,整个公司整体的进化速度也非常具有竞争力。而这种方式的坏处当然也是非常明显的。对比谷歌和微软等公司,公司员工的工作和生活之间的平衡大大地向工作倾斜了。这让Facebook在硅谷企业里多少显得有些另类。
|
||||
|
||||
美国企业可能更讲究工作和生活的平衡,而中国企业则更讲究效率一些。到底是慢工出细活好,还是努力奋斗快糙猛强,是说不太清楚的。像谷歌这样的,做事情做得非常的细致深入,也可以成为一家改变世界的公司;像Facebook这样,以效率著称的,则在每次风口浪尖上很容易高效地转型。
|
||||
|
||||
当然Facebook的这种招聘方式和考核方式,也导致进入Facebook的人在年龄层次上有一个鲜明的特点。Facebook的员工普遍年纪较轻,管理层也如此。这是可以理解的,人年纪大了以后总是有家庭有孩子,而年轻的时候更容易去拼搏,可以更长时间地工作。
|
||||
|
||||
所以在年轻的时候,进入Facebook这样的公司,通过拼搏赚更多的钱,积累更多的经验,之后无论是创业还是去更稳定的公司,已经成为了现在湾区以Facebook为首的很多新互联网独角兽公司内员工的普遍想法。
|
||||
|
||||
不仅仅如此,在选人机制上,Facebook相比谷歌更受后起的互联网创业企业(比如Uber、AirBnb等)独角兽的认可。在湾区,现在创业企业里雇员的平均年龄,普遍要偏低一些。这也对年纪相对大一些的互联网软件开发人员的就职,提出了新的挑战。
|
||||
|
||||
我们知道勤奋和有很多时间工作与年龄其实没有必然的联系。但是我们也知道,勤奋和有很多时间工作,年轻人更容易做到。所以一直以来就有一种声音,Facebook的面试方式,实际上是企业倾向于使用年轻人的一种策略。而这种策略和做法,一直都有一定的市场。
|
||||
|
||||
|
||||
|
||||
|
||||
60
专栏/技术与商业案例解读/042透过企业用人之道看企业发展.md
Normal file
60
专栏/技术与商业案例解读/042透过企业用人之道看企业发展.md
Normal file
@@ -0,0 +1,60 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
042 透过企业用人之道看企业发展
|
||||
人才是企业的根本。企业认为什么样的人是人才,又如何对待和使用人才,是企业发展中很重要的一个环节。换句话说,如果我们可以知道企业是如何待人和用人的,就可以对这个企业未来的发展前景有一定的了解。今天,我就想和你谈谈如何通过企业的用人之道去看企业发展。
|
||||
|
||||
简单来说,对于人才可以简化到“才”和“德”两个考量维度。“才”代表能力,“德”代表信奉的文化和具备的品行。能力重要,品行同样重要,但是到底哪点更为重要,不同公司有不同的理解;而具体到哪样能力或者品行更为重要,不同的企业里又有不同的侧重点。
|
||||
|
||||
比如,谷歌有非常著名的工程师文化,并聚集了大量“天才”,动辄发布“黑科技”。但是谷歌对员工的忠诚度要求非常低,对离职以后回归的员工也是持非常欢迎的态度。
|
||||
|
||||
而阿里巴巴则更强调文化重于技术。在招聘上,阿里巴巴的人力资源部门有一票否决权;在公司的日常管理上,相信你还记得“月饼事件”,当时公司内部员工写自动脚本抢月饼,因为行为不符合公司价值观而被开除。
|
||||
|
||||
要知道,企业对于“才”和“德”的定义以及考量标准千差万别,不存在两个侧重点上完全相同的企业,而这也致使每个企业的发展各有特色。
|
||||
|
||||
今天这篇方法论文章中,我想回答两个问题:
|
||||
|
||||
|
||||
如何分析企业的用人之道?
|
||||
如何通过分析企业的用人之道,去判断企业的发展?
|
||||
|
||||
|
||||
1. 如何分析企业的用人之道
|
||||
|
||||
企业的用人之道, 可供我们分析的途径有很多。但是我觉得最合适的途径有两个:人才的招聘和晋升。
|
||||
|
||||
第一个途径是招聘。前面我用一系列文章分析了主流的几家公司是怎样招聘人才的,就不再重复了。这里我们要问的是:一个企业在招聘的时候到底看什么?
|
||||
|
||||
谷歌显然侧重于招聪明人,所以人员的工程能力非常重要;而亚马逊在整个招聘过程里面,其实都是在检验一个人对领导力准则的契合程度,即使是在面试技术题,考核的也不仅仅是技术题目能不能解出来,而是更看重这个人在和面试官的交流过程中是否体现出了领导力准则。
|
||||
|
||||
从面试考察什么,我们大体可以知道一个公司对“才”和“德”两个维度的考察程度,知道这个公司到底需要什么样的人才。
|
||||
|
||||
第二个途径是晋升。人员晋升是公司的内部事务,但是在消息发达的今天,大公司的级别和晋升方式早就不是秘密了。通常每个公司对于人员都划分有不同的级别,这些不同的级别又反映到不同的人员名称上。比如,软件工程师一般就有:软件工程师、软件工程师2、资深软件工程师、首席软件工程师,等等。
|
||||
|
||||
但是我们关注的重点显然不是这些级别,而是具体到一个公司对不同级别员工的要求上。换句话说,就是看人员晋升到底看什么。我举几个例子,比如在谷歌如果要升到资深软件工程师,你需要独立做出一些对公司有影响力的项目,而什么是“有影响力的项目”,这在很多时候体现在技术的难度、广度和深度上。
|
||||
|
||||
又比如说,在看重员工素质高于工程能力的亚马逊,软件工程师升到资深软件工程师是一件非常不易的事儿,但是做业务的人员(比如MBA们),被招进去后一般都是资深项目经理这一级别。在亚马逊内能够顺利升职的,多是对业务有深刻理解的人员,亚马逊对于一个人在业务理解能力上的要求,远远高于对其技术能力的要求,由此可见一斑。
|
||||
|
||||
我们从公司对员工的每个层级有什么要求,什么样的人在具体哪个公司能够更好地晋升进行细致分析,这又在另一个层面上反映了企业是怎样用人的。
|
||||
|
||||
2. 如何通过用人之道判断企业发展
|
||||
|
||||
“什么样的人决定企业会发展成什么样”这个问题怎么回答,是体现每个分析者综合素质的地方,考验的是分析者自身的水平。如果有人告诉你一个企业是怎样用人的,而你却无法从中看出来这个企业是如何发展的,那就是个人能力问题了。
|
||||
|
||||
理论上来讲, 我们都知道企业由人构成,一个企业里面的人可以决定这个企业会发展成什么样。但是具体到特定的某家企业,我却很难给出一个让你可以照搬照套的分析模式。这里,我举几个例子来说明一下如何从企业的用人之道去判断企业的发展。
|
||||
|
||||
谷歌这个企业有非常鲜明的特点,就是“网罗天下最聪明的人才”,这是一个重视智商远高于其他很多东西的公司。谷歌的产品,除去早年很成功的搜索和广告以外,成功的不多,有的还非常不好用,但是如果哪天有哪个公司能出一个黑科技,从此改变人类的话,我想大家都不会怀疑,这个公司很可能就是谷歌。谷歌不一定有最好的产品,却最具备从技术上改变人类的可能。
|
||||
|
||||
亚马逊同样有非常鲜明的特点:招符合亚马逊领导力准则的人。亚马逊的领导力准则,就像其公司文化的DNA,决定了公司内外的很多行为方式。亚马逊公司内部会议一旦出现了争执,需要做决定,或者需要面对不确定性因素等等问题的时候,大家也都是严格照着领导力准则的模式,很死板而程序化地执行。
|
||||
|
||||
亚马逊这家企业会有什么样的未来,其实都写在领导力准则里了。这个崇尚“客户至尚”的企业,一定会有最好的产品,一定会有最好的投资回报,但是如果我们指望它诞生改变人类的黑科技,可能就是一厢情愿了。
|
||||
|
||||
以上就是通过分析“企业怎么用人,需要什么样的人”,来了解企业特色以及企业发展前景的例子。
|
||||
|
||||
今天这篇文章当然只是抛砖引玉,通过看企业的用人之道带你管中窥豹,了解如何从小处入手去分析一家企业,希望能在企业分析上给你一些启发。最后再次提醒,透过企业的用人之道可以分析企业的方方面面,而且是一种非常行之有效的分析手段,但是它对分析者自身的分析能力和逻辑思维能力也是要求很高的,这将是一个不断修炼提升的过程。
|
||||
|
||||
|
||||
|
||||
|
||||
47
专栏/技术与商业案例解读/043办公软件的战斗:开篇.md
Normal file
47
专栏/技术与商业案例解读/043办公软件的战斗:开篇.md
Normal file
@@ -0,0 +1,47 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
043 办公软件的战斗:开篇
|
||||
如果说起老牌软件帝国微软赖以生存的两架马车,第一肯定是操作系统,也就是字符界面时代的DOS系列和图形界面时代的Windows系列,第二就是著名的Office系列办公软件。在很长一段时间里,这两架马车如同“印钞机”一般,给微软带来了滚滚财源。
|
||||
|
||||
因为是靠两架马车行进,微软比“一条腿走路”的很多企业,比如早年靠数据库起家的Oracle,以及后来靠广告起家的谷歌等互联网公司,发展得都更加稳妥。
|
||||
|
||||
但进入新世纪,随着手机和平板电脑的异军突起,微软在操作系统上的优势已经不再那么重要。Windows这架马车,也终于到了一个虽然依旧可以给微软提供很多的资金,却没有光辉未来的时刻。
|
||||
|
||||
然而,在微软向云计算转型的过程中,其办公软件,也就是著名的Office系列这架马车,不但没有失去活力,反而以Office 365的形式,在云计算的转型中扮演了不可或缺的角色。可以这么说,如果没有Office 365,也许微软的这次云计算转型要艰难得多;当然,如果没有Office,就根本不会有Office 365的诞生。
|
||||
|
||||
我们很多人一直以来有种错觉,觉得微软的Office软件是天经地义的行业标准,并一直为Office领域中微软的垄断地位感到一丝担忧。为什么这么说呢?
|
||||
|
||||
并非没人发起过对Office的冲击。事实上,不管是开源的Star Office软件,还是后来互联网新贵公司谷歌的产品Google Doc,都曾对微软统治的办公软件领域发起过进攻。
|
||||
|
||||
然而很遗憾,这些战斗最终都偃旗息鼓。这些进攻对于微软来说,甚至谈不上是战斗。历史总容易被遗忘,有一个事实是我们这一代人不知道或者不记得的,那就是:微软在办公软件领域确立统治地位还只是20世纪90年代中后期的事情,但办公软件的诞生可以再追溯到20世纪80年代个人电脑诞生的初期。
|
||||
|
||||
在那个年代,为了争夺办公软件领域的统治地位,一大批在文字处理软件、电子表格等领域颇有建树的企业崛地而起。在这些企业中,微软只是一个强有力的竞争者。当然,时至今天,微软除外的那些企业和产品绝大部分已经消亡,存活的已是寥寥无几。
|
||||
|
||||
但是不可否认,这些企业,包括微软在内,都真刀真枪地战斗过。在文字处理软件和电子表格两个市场上,最初微软都遇到了强劲的老牌对手和后起之秀,并且首次出击都以惨败告终。
|
||||
|
||||
比如说微软的电子表格软件Multiplan对准了当时世面上的电子表格霸主VisiCalc,本想通过更好的产品打败竞争对手,但竞争对手是被打败了,自己却也被同年莲花公司推出的Lotus 1-2-3轻松超越。“竹篮打水一场空”,微软直到在多年以后再次推出Excel才开始看到胜利的曙光。
|
||||
|
||||
再比如在文字处理软件领域,微软再次上演了瞄准市场霸主WordStar推出Microsoft Word的戏码,却被Corel公司新推出的WordPerfect给轻松超越。
|
||||
|
||||
微软在这一艰难的市场竞争中展现了顽强的战斗力,在十余年不断的屡败屡战中,取得胜利并最终统一了市场。
|
||||
|
||||
我曾经研究过微软是如何在云计算转型中取得成功的,并因此写了一系列的公众号文章。在研究过程中我发现,微软办公软件的统治地位极其牢固不可动摇,于是又对微软办公软件的统治地位到底是如何建立的,有了更深入研究的兴趣,写作“办公软件的战斗”这一系列文章的想法正是因此而来。
|
||||
|
||||
在这个系列里,我们将一起横穿近三十年的时间跨度,回到办公软件的最初期,一起回顾办公软件一路的发展,以及各大公司围绕办公软件展开的一系列搏斗。你会看到一些曾经非常有名,如今却已倒在故纸堆里的公司曾经经历了怎样一番挣扎;你还会看到,微软是怎样屡败屡战,最终确定了自己的统治地位。
|
||||
|
||||
这个系列里的诸多故事将告诉我们几个很重要的道理。
|
||||
|
||||
|
||||
首先是企业很多时候死于自己瞎折腾和内斗,不一定是外部环境恶劣。“No Zuo No Die”是真理。
|
||||
其次,另外一部分企业没有自己作死,却死在了没有跟上时代上。比如说,办公软件里的霸主企业在从字符界面向图形界面过渡的过程中,没能够推出图形界面版本的软件,结果被时代淘汰。
|
||||
最后,微软霸主地位的获得绝非轻易得来。这是微软十几年如一日地屡败屡战,厚积薄发的结果。这种厚积薄发,也为微软在新世纪里迎接新对手的挑战提供了坚实的底蕴。
|
||||
|
||||
|
||||
这个系列里面的大部分事件,都发生在我们现今熟悉的软件世界之前,所有的资料都是从故纸堆里翻查出来的。所以错漏之处在所难免,欢迎批评指正。同时,也希望你能够喜欢这个系列。
|
||||
|
||||
|
||||
|
||||
|
||||
67
专栏/技术与商业案例解读/044VisiCalc:第一个电子表格软件的诞生.md
Normal file
67
专栏/技术与商业案例解读/044VisiCalc:第一个电子表格软件的诞生.md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
044 VisiCalc:第一个电子表格软件的诞生
|
||||
如今的办公软件里,Excel对于很多人来说绝对是不可或缺的一部分,很多数据处理工作都要用它来完成。作为电子表格的集大成者,Excel达到了一个其他软件无法企及的高度,通过给Excel做二次开发而存活的公司也不在少数。Excel可说是为微软这个软件帝国带来了滚滚利润。
|
||||
|
||||
但是你可能不知道,Excel并非电子表格的首创产品。今天,我就来讲一讲第一个电子表格软件的故事。
|
||||
|
||||
让我们把时光调回1977年。那个时候,在哈佛大学就读的丹 · 布里克林(Dan Bricklin)突然就觉得烦了:他攻读的是工商管理硕士,天天就是做各种表格的计算,涉及非常单调的烦琐操作。
|
||||
|
||||
那个年代并没有什么好用的软件,能用的无非就是纸和笔。于是这位本就有编程经验,并且学习过Basic的同学灵机一动,跑进机房开始写一个软件,以便自己可以轻松完成作业。
|
||||
|
||||
为了显示自己的聪明才智,他把自己写了这样一个软件的事情告诉了导师。工商管理学院的导师通常都有商业嗅觉,他的导师自然也不例外,导师看到后眼前一亮,拍拍布里克林的肩膀说:“小伙子有前途,你这个东西就是为我们这样的工商管理人士量身定做的啊,要不你把这个东西好好包装一下,写得好一点,然后商业化了吧。”
|
||||
|
||||
布里克林听了以后深受启发,觉得这里有商机;但他当时还是个穷学生,电脑这个东西今天是每个人都买得起了,但1977年的时候还是非常昂贵的稀罕物件。一没钱二没电脑的布里克林,有点举足无措,不知该如何继续下去。
|
||||
|
||||
这时Personal Software软件公司的老板丹 · 费尔斯塔拉(Dan Fylstra )听说了这件事,于是非常慷慨地赠给布里克林一台个人电脑,也就当时著名的苹果二代。这台电脑,让有编程天赋的布里克林终于得以完善了自己的软件,第一款电子表格软件就此诞生。
|
||||
|
||||
这个软件是这样设计的,“行”是数字,列是字母,所以A1, A2, B1, B2, …这样就表示了整个电子表格。是的,没错,是不是很熟悉,很像Excel?现在大家熟悉的Excel其实就是抄袭了这种想法,当然Excel为什么要抄袭,我在这里买个关子,我将它留到Excel的故事中再讲。
|
||||
|
||||
但是,布里克林犯了一个在今天看来是常识性的错误:他没有替自己的软件设计申请专利。换句话说,如果他申请了专利,那么微软今天每卖出一份Excel都要向他交一份专利费,那么几十年里伴随微软在办公领域的扩张,布里克林也早就赚翻了。
|
||||
|
||||
“一失足成千古恨”,这句话真是太有道理了。但是退一步讲,在1977年的时候,计算机的普及程度也远非今天能比,那时写了软件却不知道申请专利,可能也是常态。如果你我回到1977年,穿越变身当时的布里克林,是不是能比他做得更好一些,也不好说。
|
||||
|
||||
然而这个用Basic写的软件还是有很多问题,主要就是软件太慢了。于是布里克林又把自己的好友鲍勃 · 弗兰克斯顿(Bob Frankston)给拉了过来。鲍勃是个编程高手,精通汇编语言。
|
||||
|
||||
鲍勃一出手,用汇编语言把软件重新写了一遍,性能大大提升了。和我们今天习惯用高级语言编程不同,在1977年的时候,在个人电脑上连C语言都没有特别好的编译器。所以个人电脑上高性能的软件,比如说电子表格,又比如说文字处理软件,都是汇编语言开发的。
|
||||
|
||||
两位开发人员把软件命名为VisiCalc,即将Visual和Calculation这两个单词各取一部分。他们同时成立了一家软件开发公司,叫作Software Arts,专门进行VisiCalc的开发。
|
||||
|
||||
与此同时,作为对当初获赠一台昂贵的苹果二代电脑的回报,这个VisiCalc的销售被委托给了Personal Software公司来负责。这是也因为那时软件开发人员还没有那么受人重视,所以软件销售一般会通过专门的销售公司去做。行规大致是这样的,软件销售公司给开发者的软件授权费一般不会超过销售盈利总额的18%。
|
||||
|
||||
但是Personal Software和Software Arts达成了一个不太符合业界规矩的协议,Personal Software给Software Arts支付的软件授权费用是销售盈利总额的1/3。至于为什么给予了这么高的比例,我不得而知,但正是这个软件授权费,为以后两者之间的矛盾埋下了伏笔。
|
||||
|
||||
VisiCalc作为给苹果二代个人机开发的软件,一开始反响并不大。然而后来不知道这个Personal Software怎么和苹果公司联系上了,于是苹果公司开始在机器中预装这个软件。
|
||||
|
||||
然后见证奇迹的时刻到了,这个软件就此出乎意料地成为爆款,获得了大家的喜爱,不到一年,便成为苹果机器上最为畅销的个人软件。更为奇葩的是,很多人买苹果电脑的目的,只是为了能够使用这个软件。
|
||||
|
||||
这样一来,情况就完全不一样了,软件居然大大促进了苹果机的销售。于是苹果越发重视VisiCalc了,有段时间甚至出现了“苹果机搭载VisiCalc”是最佳组合的宣传。这个时候,卖软件的Personal Software看到软件如此好用,赶紧就把自己的公司改名成了VisiCorp,以此来彰显自己就是那个卖VisiCalc软件的公司。
|
||||
|
||||
在河山一片大好的情况下,VisiCorp和Software Arts之间携手共进,迅速把这款软件往苹果以外的机器上铺开来。大家都有钱赚,这显然是一段美好的蜜月期。
|
||||
|
||||
但是我们知道的,很多时候可以共患难,但难以同富贵。这两家公司一家做软件,一家卖软件,到底谁的贡献更大呢?
|
||||
|
||||
从VisiCorp的角度来看,做生意的人,辛辛苦苦地铺进去很多成本,却要付出比行业基本价来说更多的利润,有种“宝宝心里苦,宝宝受委屈了”的感觉。
|
||||
|
||||
而Software Arts的两个哥们显然不是这样想的。这款爆款软件,赚钱赚到手抽筋。他们觉得自己才是更大的贡献者:没有人把软件做出来,拿什么东西去卖啊。这两方之间的龌龊,就这样开始了。
|
||||
|
||||
两者之间有过协议,在固定的时间内要提供新版的软件。Software Arts的人就经常故意拖着,因为他们希望VisiCorp给出更多的钱;而VisiCorp的人自然拖着不给钱,因为他们想通过拖钱的方式来再度谈判降低支付比例。
|
||||
|
||||
以上算得上是内忧了,外患则来源于同行。在VisiCalc横扫很多机器的时候,他们忘记了给CP/M做开发。而软件专利在那个时候都不是个事,何况还没申请专利呢?
|
||||
|
||||
CP/M是当时很主流的一款操作系统,VisiCalc忘记了这个重要市场,也因此赋予他人可乘之机。对手就可以以这个操作系统为基本盘,在其他系统上和VisiCalc竞争。即便这种竞争本身不至于冲击VisiCalc的市场占有率,也有可能冲击对VisiCalc的定价权。
|
||||
|
||||
事实上,1980年一家叫作Socim的软件公司迅速出手,开发出了一个叫作SuperCalc的软件。这款软件运行于CP/M,迅速占领了市场。而且,其软件功能比VisiCalc还强一些。
|
||||
|
||||
此时,VisiCorp和Software Arts已陷入长久的征战,对手在进攻,这两家公司却就钱的问题开始对簿公堂,一路折腾。对手很快从各个方面攻城略地,VisiCalc却依旧裹足不前。
|
||||
|
||||
VisiCalc的故事多少有些让人扼腕,所谓“可以共患难,却不能同富贵”这句话,非常适用于它的开发者和销售商。VisiCalc的失败,首先是窝里斗的结果。无论是开发者还是销售商都觉得自己亏了,双方却又没有真正地协商解决问题。此外,VisiCalc对于专利不够重视,没有为自己的发明申请专利,也是让竞争对手可以随意抄袭的主要原因。
|
||||
|
||||
总体来看,VisiCalc的故事倒是很好地印证了一句话:很多成功的公司都是自己作死。
|
||||
|
||||
|
||||
|
||||
|
||||
65
专栏/技术与商业案例解读/045WordStar:第一个字处理软件的故事.md
Normal file
65
专栏/技术与商业案例解读/045WordStar:第一个字处理软件的故事.md
Normal file
@@ -0,0 +1,65 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
045 WordStar:第一个字处理软件的故事
|
||||
20世纪70年代,王安电脑公司的字处理机应运而生。这是一种结合了电脑和打字机的机器,它可以让用户方便地在电脑上打字、修改,等文档成型以后再打印出来,这一过程节省了大量的纸张。这一功能类似于今天的字处理软件Word,但那是一台特殊的电脑,软件硬件一起卖。
|
||||
|
||||
当初,给著名的个人计算机厂商IMSAI打工的西摩 · 鲁宾斯坦(Seymour Rubinstein)决定离职创业,MicroPro公司由此诞生。西摩雇用了程序员约翰 · 巴纳比(John Barnaby)开发了一款主供研发人员使用的文字处理程序WordMaster,因此有了第一桶金,但远远不够发家致富走向幸福生活的。
|
||||
|
||||
作为一个生意人,他很快把目光投向了通用字处理软件市场。首先,他搞到一份研究报告,其中详细分析了IBM、王安电脑和施乐公司的字处理软件,各大厂商分别有一些什么功能一目了然。西摩开始让程序员巴纳比继续开发软件,补充添加各大软件厂商拥有的功能,并希望将产品打造成通用的字处理软件来销售。
|
||||
|
||||
因为当时最流行的操作系统是CP/M,这个软件也是专门为CP/M编写的。为了区别于老款软件,西摩把软件改名为WordStar。1977年,个人计算机上的第一款通用字处理软件就这样诞生了。
|
||||
|
||||
软件非常成功,西摩自己公布的数据显示,差不多8个月内就卖了5000份!当时的软件市场毕竟不能与今天同日而语,买得起个人计算机的在全美国也是屈指可数,5000份已经是个天文数字了。
|
||||
|
||||
1981年绝对是WordStar发展过程中很重要的一年。这一年IBM推出了自己品牌的PC机,西摩紧跟“蓝色巨人”的潮流,迅速推出了在IBM PC机上运行的WordStar,并将操作系统也换成了DOS。就是这一年,WordStar在个人文字处理市场上确立了统治地位。
|
||||
|
||||
WordStar有哪些独特的地方呢?有一点特别知名,就是它最早提供了其他编辑软件所不具备的“所见即所得”功能。当然,这一功能在那时还比较简单,只是可以即时在屏幕上显示出斜体和黑体。但即便如此,也让它比起其他软件,包括专门的文字处理机器更受欢迎。
|
||||
|
||||
1983年,一家相当于我们“全国报业十强”之一《计算机世界》的刊物,也就是著名的BYTE软件杂志宣称:WordStar毫无疑问是PC市场上最为著名,并且很可能是最为广泛使用的字处理软件。同年,新发布的WordStar 3.3,更让MicroPro占据了整个个人计算机软件市场10%的份额。
|
||||
|
||||
1984年,MicroPro上市,同时确立了自己在计算机软件市场的统治地位,成为全球公认最大的纯软件公司。这个名头后来被莲花公司和微软相继获得,但那是以后的事情了。1984年的个人计算机软件市场,属于MicroPro和它的WordStar。
|
||||
|
||||
俗话说得好,盛极而衰,这真的是“放之四海而皆准”的话。1984年,也正是WordStar由盛转衰的开始。
|
||||
|
||||
我在研究一个又一个企业的发展历史时,总会发现很多企业成为了某个领域的世界第一,然后却转而衰败。只有少数企业,在多重领域不断厮杀,最终奠定了软件帝国的地位。所以,世界第一,其实并不是那么好当的。
|
||||
|
||||
WordStar的烦恼首先来自于竞争对手。当时的竞争对手主要有两个:其一是成立于1979年的WordPerfect公司,它们的产品WordPerfect相当不俗;另外一个是在操作系统和编译器领域小有建树,想要进军应用软件市场的微软。
|
||||
|
||||
然而,WordStar的问题更多还是来自于自身。当软件从CP/M挪到DOS操作系统,MicroPro只是做了一个简单的移植:最初的版本并没有解决CP/M只能用64 KB内存,而DOS可以支持640 KB内存的事实。以至于用户发现,如果在内存里面创造一个虚拟磁盘,把文件复制进虚拟磁盘以后再用WordStar打开,速度要快无数倍,这让用户们很苦恼。
|
||||
|
||||
WordStar的另一个主要问题还是软件成型得太早。早期因为还没有鼠标,软件操作需要通过快捷键来进行,而键盘上的快捷键往往是两三个键的组合,非常难记。当然WordStar也没有所谓的下拉式菜单,所以用户无法用鼠标选择菜单完成操作。
|
||||
|
||||
早年的时候功能不是很多,WordStar的使用者也不需要记忆太多快捷键。但是等到WordStar的功能越来越丰富,要让WordStar顺利工作起来,使用者或者必须记熟所有的快捷键,或者只能随时查手册。而微软新推出的Microsoft Word已经开始支持鼠标和下拉式菜单,从而大大简化了用户入门使用的门槛。
|
||||
|
||||
伴随着竞争对手的产品越来越好入门,WordStar自己却陷入了内斗。内斗的标志事件是MicroPro的WordStar核心开发人员离开MicroPro,并创立了New Star公司。New Star公司做的正是类似于WordStar的产品,在市面上直接和WordStar展开竞争。
|
||||
|
||||
现在已经无法考据其核心人员的离开究竟是何原因,比较靠谱的说法是政治斗争。而且,为什么一家公司的核心人员可以创立新公司,开发类似的产品,却不需要承担法律责任呢?或许你可以去研究下。这多半又是一起之前没有申请专利,导致知识产权不明确的案例。
|
||||
|
||||
于此同时,另外一件更为尴尬的事情即将发生。AT&T当年作为美国最大的电话公司准备进军个人计算机市场。它打算推出一款基于UNIX操作系统的机器,并在自己的机器上配备一个办公软件。于是,AT&T找了当时著名的MicroPro,让其替自己开发一套基于UNIX的WordStar。
|
||||
|
||||
AT&T并不知情的是,WordStar的核心开发人员早就离开WordStar去开设New Star创业了,而MicroPro也毫无UNIX的开发经验。当时MicroPro找到了某个程序员,这个人开发了UNIX下的WordStar仿制版,于是西摩决定将他招至麾下。
|
||||
|
||||
这个UNIX下的WordStar版本和公司已有的WordStar版本在功能上并不完全重合,具备了一个字处理程序需要的大部分功能,因此交给AT&T使用还是绰绰有余的。西摩觉得,要让两者统一起来代价太大,不如就拿这个UNIX版开始销售吧,并将这个软件命名为WordStar 2000。
|
||||
|
||||
这款新软件是用C语言开发的,因为C语言在DOS和UNIX下均可以成功编译,所以WordStar 2000又同时出了DOS版,但正是这个决定让MicroPro陷入了两难的境地。
|
||||
|
||||
WordStar 2000和WordStar各自有一些用户喜欢的功能,各自又都缺一些用户需要的功能。面临两选一的问题,用户们也很纠结。而这种“二选一”也让公司内部的所有资源,从开发到销售都一分为二。
|
||||
|
||||
公司内部这两个产品之间的利益争斗自不必说,而西摩所领导的公司因为WordStar核心开发人员的出走,也不具备技术力量在老WordStar里开发WordStar 2000那些备受用户欢迎的功能。这种全方位的内斗,加之任何一款产品都无法让用户完全满意,用户又不愿意同时购买两款产品,致使WordStar的市场占有率逐年下降。
|
||||
|
||||
西摩看到情况不对,赶紧以收购New Star公司的方式把之前核心人员重新召了回来,然后让这些老核心人员在WordStar的源代码上开发新版本4.0。新版本的推出,让MicroPro暂时稳住了市场。
|
||||
|
||||
照理来说,接下来MicroPro应该开始整合WordStar和WordStar 2000两款软件,把优秀的软件功能都整合进一个新产品里去了。因为,这样既可避免用户的两难选择,也可以让公司的销售资源重新集中到一个产品下面。
|
||||
|
||||
但是事情并未这样发展,MicroPro准备开发WordStar 5.0。因为重新召回的那些核心开发人员,坚决抵制WordStar 2000的任何功能,并表示一定要推陈出新;即使不得不采用的合理功能,他们也要变着法子使用其他方式呈现给用户,并重新设计实现。
|
||||
|
||||
但是,原来这些功能在WordStar 2000里面的使用方式已经得到用户的普遍认可,WordStar 5.0却偏偏要“吃螃蟹”,换作未被用户认可而且很可能是更难用的方式呈现软件功能。这个奇葩的政治斗争的产物WordStar 5.0,后来因为极其难用,面市第一天就招来谩骂、恶评如潮。
|
||||
|
||||
WordStar就这样被用户抛弃了。卖不出产品了,曾经的“全球软件老大”MicroPro终于迎来了它破产的一天。MicroPro的失败,真是应证了一句话:No Zuo No Die。
|
||||
|
||||
|
||||
|
||||
|
||||
57
专栏/技术与商业案例解读/046微软:办公软件战场的螳螂.md
Normal file
57
专栏/技术与商业案例解读/046微软:办公软件战场的螳螂.md
Normal file
@@ -0,0 +1,57 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
046 微软:办公软件战场的螳螂
|
||||
中国有句话说得好,“螳螂捕蝉,黄雀在后”。奔走在办公软件帝国之路上的微软,就曾经一次次地成为了这样一只螳螂。
|
||||
|
||||
今天让我们一起回顾微软早年如何进入办公软件领域的战场,看它是如何一次又一次向对手发起进攻,却被第三者掀翻的。
|
||||
|
||||
1981年,微软离成为后来的软件帝国依然有巨大差距,但已在操作系统和编译器领域颇有建树,算是很成功的软件公司了。
|
||||
|
||||
在那个年代里,软件巨头很多,其中之一就是我们前面提到过的VisiCorp,这个发明了第一个电子表格软件VisiCalc的公司,另外一个则是文字处理市场的大鳄WordStar。
|
||||
|
||||
比尔 · 盖茨在成功建立了操作系统和编译器领域的地位后,决定进军办公软件市场。他选择的第一个对手,就是他认为的“软柿子”:电子表格软件VisiCalc。其实很难说比尔 · 盖茨做得对或不对,但从我对当时实际情况的了解来看,VisiCalc很受欢迎,并非一个好啃的骨头。
|
||||
|
||||
那时候,西雅图依旧是一片软件人员的荒芜之地,而硅谷则是各大技术人员的中心。当年最为著名的施乐PARC研发中心,则是数一数二的人才聚集之地,比尔 · 盖茨就到这里来寻找他需要的人才,为新成立的应用软件部门物色第一位员工。
|
||||
|
||||
我想那时比尔 · 盖茨或许也没底气,不清楚其他人是不是看得上这个公司,但他还是成功物色到了一位名叫查尔斯 · 西蒙尼(Charles Simonyi)的大师。 可能你对这位不太熟悉,但这个人值得介绍一下。
|
||||
|
||||
他是匈牙利人,博士学位,曾先后在加州伯克利大学和斯坦福大学学习深造。此人在微软做了很多事情,其中最有广泛影响力的是后来被命名为“匈牙利命名法”的变量命名法则,此法则在2000年前后广为流传。他的另一项伟大成就是:先后两次乘坐“联盟号”宇宙飞船登陆空间站。
|
||||
|
||||
1981年的查尔斯还没有后来那么英明睿智,但是已经动向到了要怎样开发电子表格。他的到来,让微软开始了一个名字叫作MultiPlan的计划。这个产品是一个早期的电子表格,最主要的功能是可以支持多个表,以及多个窗口。此外,它还得支持多个操作系统。
|
||||
|
||||
这些功能对于“大神”来说都不是问题,查尔斯想要发明的是一个新东西:菜单。“菜单”在今天已经是寻常的物件,一个软件要是没有个能用鼠标点点选选的菜单,简直不可思议。但是在那个靠快捷键操作、鼠标还没普及的1981年,查尔斯决定用菜单来为新软件保驾护航的做法,无疑非常聪明。
|
||||
|
||||
当1982年微软正式把Multiplan同时在多个平台上推出时,比尔 · 盖茨也是非常激动。这个软件比起VisiCalc,简直一个天上一个地下。然而命运总是弄人,市场上出现了一个新的软件:莲花公司的Lotus 1-2-3。
|
||||
|
||||
作为大牛的查尔斯决定亲自看看这个软件是什么,而比较结果让这位“大神”倍感挫败。很多年后查尔斯接受媒体采访时说,当他看到Lotus 1-2-3的时候,就知道自己的第一个产品完蛋了。对方实在是段位太高,完全不是他能想象的。除了认栽,他别无它法。
|
||||
|
||||
果然,时隔两年Multiplan占据了6%的市场,VisiCalc在两大对手的挤压下濒临破产,而Lotus 1-2-3则占据了整个电子表格市场的绝大多数比例。做了一次螳螂的微软,就这样被黄雀赶下马,Multiplan当然也不好意思再卖下去了。
|
||||
|
||||
在电子表格市场上败北的微软总裁比尔 · 盖茨决定再次出击,将目标转向了另外一个办公软件:字处理软件。字处理软件市场,此时正是WordStar横行的年代,其开发公司MicroPro在1984年成功上市,成为当时最大的软件公司,可谓风头一时无两。
|
||||
|
||||
但微软已经将鼠标在Multiplan里面运用得无比纯熟,比尔 · 盖茨很快察觉到了WordStar有欠缺的地方:这个软件需要用户记住大量快捷键,极伤用户体验。于是携着鼠标和菜单两大利器,比尔 · 盖茨和应用软件开发部的查尔斯自信能够在文字处理市场攻城略地。
|
||||
|
||||
最初,微软打算使用MultiWord这个名字,借此让产品和MultiPlan相得益彰,但是这个名字已经名花有主,于是才有了今天我们熟知的Microsoft Word。这是一个多么朴实的名字啊。
|
||||
|
||||
1983年,在Multiplan失败后一年,微软发布了Word软件,其最为显著的特点就是对鼠标的支持。软件一经推出,便赢得无数赞誉,大家都说,WordStar要倒霉了。
|
||||
|
||||
实际上,WordStar占据了整个文字处理市场老大的地位很长时间。如果不是自己内乱,后面的故事会怎样发展,还真不好说。但,历史终归无法改变和臆测。
|
||||
|
||||
微软还在Word里第一次使用了后来惯用的伎俩,就是软件可以读取其他竞争对手的格式,而这次它瞄准的就是WordStar。那时比尔 · 盖茨和查尔斯一定对将来的好日子充满希望,但几个月后的销量表现却相当惨淡。
|
||||
|
||||
于是微软开始调研,却发现原来有一家叫作WordPerfect的公司,开发了一款叫作WordPerfect的软件。该公司是由大学生和教授合开的,又雇用了一群群的大学生,挨家挨户上门去推销他们的软件,并为买了软件的公司提供无微不至的服务。比如说,购买了该软件的用户可以随时打免费的电话技术支持热线,由技术人员提供免费而无微不至的服务支持。
|
||||
|
||||
在微软大张旗鼓做广告的时候,WordPerfect却通过这种宣传方式和服务方式,一点一点地蚕食着WordStar的市场,并很快超过了Microsoft Word,成为市场上仅次于WordStar的字处理软件。
|
||||
|
||||
时间到了1986年,WordStar已经很久没有推出新品,又备受内耗之苦,市场占有率下降到了16%的份额,而WordPerfect则占据了整个市场销售份额的31%。至于Microsoft Word,在微软的各种努力下,却只抢到了11%的市场份额。
|
||||
|
||||
幸好,WordStar忙于内斗,WordPerfect虽然牛,但是显然没有Lotus 1-2-3那样统治整个领域,留给Microsoft Word的生存和发展空间依然很大。这次,微软进军办公软件市场的努力虽然被黄雀给堵了,却也没有落到一无所有必须放弃的地步。
|
||||
|
||||
两次战斗,却两次失败的微软,依旧没有放弃在办公软件市场的努力。微软这两次战斗失败的主要原因,并非是对当时市场上的霸主研究不够准备不足,而是没有注意到市场上也有和微软类似的竞争者,在打造类似的产品,并且产品更为强大。所以,眼观六路耳听八方,不仅仅要注意市场的霸主,观察周围潜在的竞争对手同样很重要。
|
||||
|
||||
|
||||
|
||||
|
||||
53
专栏/技术与商业案例解读/047WordPerfect:字处理软件的新秀.md
Normal file
53
专栏/技术与商业案例解读/047WordPerfect:字处理软件的新秀.md
Normal file
@@ -0,0 +1,53 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
047 WordPerfect:字处理软件的新秀
|
||||
今天的主角是WordPerfect。前面说到,微软在正面进攻WordStar的过程中,做了一回办公软件战场的“螳螂”,而背后的“黄雀”就是这个字处理软件WordPerfect,它一路攻城略地,成功战胜了微软的Word和MicroPro的WordStar,一举坐上字处理市场的头把交椅。
|
||||
|
||||
WordPerfect是美国杨百翰大学的学生布鲁斯 · 巴斯蒂安(Bruce Bastain)和教授艾伦 · 阿什顿(Alan Ashton)开发的。这个软件最初开发在Data General的个人计算机上。Data General作为一家个人计算机制造商,在那个个人计算机百花齐放的年代,并没有太大的知名度,所以WordPerfect最初推出来的时候也没多少人知道。
|
||||
|
||||
但是1982年,两位开发者把WordPerfect移植到了DOS系统,而DOS是IBM个人计算机及其兼容机上的操作系统,这让软件的影响力变得不可同日耳语。
|
||||
|
||||
在向DOS移植的过程中,WordPerfect的作者一开始打算用C语言开发。但是就像其他人遇到的问题一样,市面上尚不存在一个成熟的C编译器,于是他们选用了汇编语言。但是和WordStar以及Microsoft Word不同,布鲁斯决定绕过操作系统层,用汇编语言对屏幕直接进行绘画和操作,而竞争对手则是通过操作系统DOS的API来实现同类操作的。
|
||||
|
||||
这个决定在当时显得至关重要。虽然这显著增加了WordPerfect的开发难度,但却让它在当时的硬件条件下相较于WordStar和Microsoft Word表现出了超强的性能。性能直接会影响用户者的使用体验,WordPerfect因此甩了其他字处理软件一条街。
|
||||
|
||||
WordPerfect的另外一个创新,在于它给用户提供的服务方式。与竞争对手不同,它基本不做广告,而是把钱花在派人去客户那边进行培训和普及上,这种服务不仅仅被作为主要的营销手段,而且免费提供。相反,各大竞争对手对这种服务则要收取高昂的服务费用。
|
||||
|
||||
不但如此,为了让在电话线另一头等待的客户不至于无聊,WordPerfect还专门让接线员给客户讲笑话。如此贴心的服务,让客户一用上这个软件就觉得很安心。
|
||||
|
||||
当微软开始用大量广告费宣传Word软件的时候,WordPerfect公司把公司账单刊登出来,账单中有数额巨大的电话费。WordPerfect表示,我们不浪费钱打广告,我们只是全心全意为客户服务,高额的电话费用成了WordPerfect贴心服务的最好证明。微软的广告打水漂,WordPerfect则在这种贴心的客户服务模式下攻城略地。
|
||||
|
||||
不但服务很好,WordPerfect软件本身做得更是好用。1983年,具有里程碑意义的3.0版发布,它最大的突破是对各种打印机的支持:通过自带驱动的方式, WordPerfect当时支持了50多种打印机;接下来很短的时间内,这个支持数量又迅速增加到100多种,因此使用WordPerfect的用户完全不用担心打印问题。但对于使用其他字处理软件的用户,单单打印机的配置就是一个非常让人头疼的问题。
|
||||
|
||||
WordPerfect一直在努力提高产品的质量和功能。1986年的WordPerfect 4.2是这个软件最为重要的一个版本。在这个版本中,WordPerfect软件针对律师事务所重点进行了功能增强。它引入了页脚和页面编号、自动行号等功能,第一次让自己的产品登录对打字软件要求最为严格的律师事务所行业,而其竞争对手几年后依然不被律所采购。这让WordPerfect不但在功能上远远超过了Microsoft Word,更是第一次在市场份额上超越WordStar,成为名副其实的头号字处理软件。
|
||||
|
||||
此后WordPerfect再接再厉,不断推陈出新,在1989年推出的5.1版开始支持菜单、支持表,而且增加了打印预览功能,这是第一次有字处理软件可以让用户在电脑上预览文章的打印效果。
|
||||
|
||||
而1993年的WordPerfect 6.0,又在字处理软件里第一次增加了今天我们非常熟悉的“所见即所得”的编辑功能,让用户可以在打印预览模式下直接编辑文件,并立刻看到编辑效果。
|
||||
|
||||
同时代的WordStar忙于内斗,无所事事;微软则在不懈地、一步一个脚印地继续发行Word的新版本,但是这些版本和WordPerfect比起来功能差距太大,毫无竞争力。WordPerfect一度成为字处理软件的事实标准。
|
||||
|
||||
“花开两朵,各表一枝。”1990年开始,微软除了做字处理软件,还在开发一个新的图形界面, 就是后来著名的Windows。Windows 1.0虽然表现并不突出,但是却很重要。这个Windows版本实现了对办公软件,比如Excel和Word所需要的图形界面的支持,为微软的办公软件向图形界面系统迁移提供了基础。但当时Windows的市场占有率整体上还不是很高,DOS依然是最主流的操作系统。
|
||||
|
||||
WordPerfect 5.1的成功,让WordPerfect公司非常犹豫是应该继续巩固DOS市场,还是应该进军Windows市场。前者可以让WordPerfect继续完善盈利的产品,后者则有很大的危险性,因为WordPerfect并不清楚Windows 1.0作为一个操作系统是不是有未来,能不能成功。
|
||||
|
||||
而微软及时推出了Word的Windows版本。等到WordPerfect想明白,决定进军Windows市场时,Microsoft Word已经面市两年多,而且因为Microsoft Word是第一个可以在Windows下跑的字处理软件,随时Windows市场占有率在这两年里的不断攀升,它已经不容小觑。
|
||||
|
||||
醒悟过来的WordPerfect匆忙之中推出Windows版本,但因为匆忙,很多都是DOS代码的直接移植,没怎么测试过。WordPerfect的组合键和Windows自己的组合键产生了大量冲突,问题频出。更重要的是,Windows下的打印机驱动模式和DOS下有所不同,而WordPerfect最引以为傲的自带打印机驱动的功能到了Windows下居然罢工了。
|
||||
|
||||
可以说仓促推出的WordPerfect 5.2这个Windows版非常糟糕,用户抱怨连连。虽然后来WordPerfect公司显示出了强悍的开发能力,将这些问题在接下来的版本WordPerfect 6.0里逐渐修复,但是市场先发优势已去,伴随着Windows的普及,Microsoft Word在新时代里牢牢站稳了市场。
|
||||
|
||||
之后WordPerfect就命途多舛了,1994年被Novell公司收购,两年后又被Novell卖给了Corel。最后这个DOS时代的“王者”,慢慢退出了历史舞台。
|
||||
|
||||
WordPerfect在DOS时代几乎没有犯过什么错,但是在历史转型的时候,对于是否进入Windows市场犹豫了。等到看明白并匆匆入场,却因为推出了一个用户体验一塌糊涂的版本,而导致在Windows时代一步步被淘汰。
|
||||
|
||||
话又说回来,微软一边做操作系统,一边做办公软件,Windows下的软件开发人才又大都在微软。所以是不是微软在用Windows取代DOS的过程中,也通过Windows的先发优势帮助自家产品战胜了竞争对手呢?这也是有可能的。
|
||||
|
||||
无论如何,DOS时代的王者就这样倒下了,Windows时代的办公软件属于微软。
|
||||
|
||||
|
||||
|
||||
|
||||
45
专栏/技术与商业案例解读/048Lotus1-2-3:莲花公司的电子表格帝国.md
Normal file
45
专栏/技术与商业案例解读/048Lotus1-2-3:莲花公司的电子表格帝国.md
Normal file
@@ -0,0 +1,45 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
048 Lotus 1-2-3:莲花公司的电子表格帝国
|
||||
莲花公司曾经是20世纪80年代到90年代最大的软件公司,在美国软件发展史上具有非常重要的地位。它起源于一款电子表格软件,这款软件曾经占领整个电子表格市场超过80%的份额,并让电子表格软件的鼻祖VisiCalc两年内关门大吉,也让微软雄心勃勃推出的Multiplan搁浅。
|
||||
|
||||
提到莲花公司,我们不得不说下它的创始人米切尔 · 卡普尔(Mitch Kapor)。这位创始人就像一位特立独行的“叛逆者”,一向游走在主流文化之外,他早年特别喜欢摇滚乐,爱好吸毒,曾经进入耶鲁大学攻读心理学、语言学、计算机学,尤其是控制论,并开始对计算机产生兴趣。
|
||||
|
||||
毕业以后他的工作一度飘泊不定,做过电台主持人,当过滑稽戏演员,之后还远赴瑞士参加冥想学习,希望可以练出特异功能。再后来,他还曾在精神病院打杂。谁能想到,他在日后会成为与盖茨并称“美国软件业双子星”的变革者呢?
|
||||
|
||||
1978年,苹果二降到1500美元左右,他抵押自己的立体声音响设备,掏空腰包买了一台苹果电脑,之后一边自学,一边给人提供计算机技能咨询。再后来,他还跑到MIT读MBA,终究因为兴趣不在此处,很快跑去一家计算机公司上班。
|
||||
|
||||
上班期间他仍在寻求下一个机会,而恰巧VisiCorp的老板丹 · 费尔斯塔拉(Dan Fylstra)正有新的打算。VisiCorp就是被授权独家代理销售电子表格软件VisiCalc的公司,为了让VisiCalc更好用,VisiCorp的老板找到米切尔,让后者帮忙开发VisiCalc的画图插件。按照协议,插件的所有权双方各占一半。米切尔开发了两个插件,后来被以VisiPlot和VisiTrend的名义和VisiCalc一起出售给用户。
|
||||
|
||||
到1982年的时候,VisiCorp的老板想买断这两个插件的所有权,双方认为这两个插件总价值为120万美元,米切尔因此分到60万美元。这第一桶金让米切尔认识到,自己做老板,才是赚钱最快的途径。
|
||||
|
||||
1982年,米切尔决定自己开公司。大概是始终难忘当年冥想训练的那段经历,他把公司命名为“莲花”(Lotus),这个在佛教里面预示着“神秘而纯洁”的东西。
|
||||
|
||||
他想做的产品非常简单,因为自己前面做了两个画图插件,又接触了电子表格,后来不知又从哪里听说了数据存储和管理的重要性,于是决定将这些功能集中打包成一个产品,于是著名的Lotus 1-2-3诞生了。在这个软件名中,1代表VisiCalc的功能电子表格,2代表数据的存储和管理,3代表画图。
|
||||
|
||||
米切尔决定玩票大的,他花巨资请来了知名咨询公司麦肯锡做软件的推广宣传,这一软件推广方式是历史上非常著名的一次豪赌。麦肯锡在《华尔街日报》刊登了全版广告来宣传这个新产品,这种宣传做法在之前的软件发布史上从未有过,而且价格高昂,大大突破了以前软件公司在宣传上的预算。米切尔当时还在创业,没有多少资金,却大把撒钱搞宣传,如果宣传不成功,产品不能顺利卖出,等待米切尔的或许就只有破产了。
|
||||
|
||||
幸运的是,新产品神秘的命名、组合的功能,以及在《华尔街日报》的全版广告,给用户留下了非常深刻的印象。而此时微软对标VisiCalc出品的Multiplan才刚刚发布不过一个月时间,就这样被米切尔以非常规的宣传方式压制得毫无声响。
|
||||
|
||||
大肆宣传之余,这个软件的功能也绝对不弱,Lotus 1-2-3是第一款完全支持640 KB内存的电子表格软件。和CP/M只支持64 KB内存比起来,微软开发的DOS操作系统支持640 KB的内存,理论上来讲软件就应该能利用所有的640 KB内存吧?但微软自己开发Multiplan的时候,因为考虑到软件要在不同操作系统下都能运行,所以非常保守地使用了64 KB内存。而深知内存少性能差,没办法好好画图的米切尔,则采取了比微软激进得多的做法,那就是有多少内存用多少内存。这样一来,Lotus 1-2-3不仅品牌响亮、功能全面,更是速度一流。
|
||||
|
||||
Lotus 1-2-3还有一个特别的地方:在磁盘上,莲花公司不但存储了软件,还给用户存了一份软件使用说明书。这个做法和当时市场上动辄几百页的纸质说明书比起来,要先进得多,因为用户可以用电脑非常方便地检索所需信息了。
|
||||
|
||||
Lotus 1-2-3似乎注定要在市场上大放异彩,它迅速占领了市场,打得VisiCalc毫无招架之力,而发布不久的微软Multiplan更是一点声响都没弄出来就挂掉了。因为当时拥有电脑的人并不多,市场总量有限,买了Lotus 1-2-3的人自然就不会再去买VisiCalc,VisiCalc的新客户越来越少,VisiCorp渐渐入不敷出,三年后宣告破产。
|
||||
|
||||
Lotus 1-2-3的成功,也让当时PC机的主宰者蓝色巨人IBM开始心心念念起来。原来IBM和微软的合作,尤其是DOS方面的合作非常愉快,而VisiCalc也是IBM在PC机上主推的几个软件之一。但是Lotus 1-2-3的全方位领先,让IBM看到也许未来不属于VisiCalc,IBM觉得应该扶持一下这个新崛起的莲花公司,以免Lotus 1-2-3只专注于苹果机的开发,让IBM的PC机失去机会。于是,IBM也开始在机器上主推和预装Lotus 1-2-3。
|
||||
|
||||
米切尔创业第一年推出的软件Lotus 1-2-3,当年销售额就高达5300万美元,远超他几百万美元的预期,从而让莲花公司成功上市,这可说是史上最快的上市速度了。第二年,销售额就飙升到了1.5亿美元,第三年更是高达2.5亿美元。在此之前,从来没有任何公司凭借一款软件,以这样的速度在个人软件市场大爆发的。
|
||||
|
||||
公司成功了,米切尔的江湖地位也是急剧上升。1985年,他的影响力迅速超过比尔 · 盖茨,成为当年最为炙手可热的人物。然而他却在1986年选择离开,他表示自己并不适合经营公司,也不喜欢权力,而是偏爱做自己内行的事,现在的工作已然变了味。
|
||||
|
||||
退出商业圈子后,他跑去MIT找了份访问教授的工作开始教书育人。不过安稳注定与他无缘,一年后他还是觉得软件开发有意思,出来开了一家叫作On的公司,一干就是三年,只是这家公司却没有重现莲花公司的风采。
|
||||
|
||||
莲花公司的故事,让我们看到了一个别具一格的智者,米切尔无论是创业、打造软件、宣传产品,还是激流勇退,都透露着各种不安分。作为创始人,他对莲花公司极为重要,但是莲花公司却留不住他。那么,靠一款产品一炮而红的这家公司,怎么才能在没有领袖的情况下长久存活呢?
|
||||
|
||||
|
||||
|
||||
|
||||
57
专栏/技术与商业案例解读/049红狮会战:微软的反击.md
Normal file
57
专栏/技术与商业案例解读/049红狮会战:微软的反击.md
Normal file
@@ -0,0 +1,57 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
049 红狮会战:微软的反击
|
||||
在西雅图地区贝尔维尤的市中心,有一家红狮宾馆(Red Lion)。和市中心很多高大上的新式宾馆比起来,它并不显眼,却在办公软件发展史上占有一席之地。
|
||||
|
||||
连续做了两次“螳螂”的微软,屡战屡败。Lotus 1-2-3的成功,更是让微软的电子表格事业蒙上了阴影。比尔 · 盖茨这样心高气傲的人,自然不会甘心,1983年9月他召集了微软的很多精英人物,在红狮宾馆连续开了三天三夜的会议。会议主题只有一个:推出世界上最快、最好用的电子表格软件。目标也很简单,就是打败Lotus 1-2-3。
|
||||
|
||||
会议中,他们对Multiplan和Lotus 1-2-3做了详细比较,找出自己和对方的不足,来改进和增强自身,会议结果为以后微软的电子表格软件开发奠定了基调。会后,比尔 · 盖茨决定微软重整旗鼓开发一套新的电子表格,并命名Excel,其中文意思就是“超越”。至于要超越谁,答案显而易见。
|
||||
|
||||
Excel吸取了Lotus 1-2-3的很多优点,比如类似Lotus 1-2-3引入了宏语言。同时,它也吸收了Multiplan的优点,又融入微软新的思考,比如引入了智能重算的概念,即:在Excel中改动部分数据,只会导致相关的部分重新计算,而不是把整个电子表格都重新计算一遍。电子表格的性能因此大大提升,当然开发难度也不是高了一星半点。此外,微软Excel的界面毫不犹豫地仿造了Lotus 1-2-3。
|
||||
|
||||
这场战役聚集了微软很多优秀的软件工程师。大张旗鼓开发Excel半年多以后,比尔 · 盖茨突然召集大家开会,并宣布了一个重要决定:Excel的开发转向,从支持DOS作为第一目标,变成支持苹果公司的Macintosh为第一目标。
|
||||
|
||||
是不是觉得很奇怪,为什么比尔 · 盖茨会做出这样一个决定?当时微软的开发团队对此也是一头雾水。比尔 · 盖茨解释到,这是因为电子表格的使用体验,与硬件和操作系统都很有关系。只有在最新的图形界面下,微软的电子表格才可能战胜Lotus 1-2-3。
|
||||
|
||||
而当时微软Windows图形界面开发才刚刚起步,苹果电脑却已经可以提供世界上最好的图形界面支持。作为一个命名为“超越”(Excel)的电子表格软件,如果继续在DOS上面做开发,不足以打赢这场战争。
|
||||
|
||||
相信你还记得,微软在开发Windows时,也一直在开发基于Windows图形界面的Microsoft Word,此举让它战胜了WordPerfect。显然比尔 · 盖茨认识到,基于图形界面式操作系统来做开发,才是办公软件的未来。为此,他在Excel上甚至愿意先去为竞争对手的机器开发软件。
|
||||
|
||||
这无疑是极具眼光的行为。而且,这也可以解释为什么微软不遗余力地开发基于Windows的Microsoft Word,然而WordPerfect以及当时市面上大部分办公软件的开发者,无论他们是否领先于微软,都没有真正意识到办公软件的未来是什么。
|
||||
|
||||
团队并不理解这种决策,好在理解也要执行,不理解也要执行,开发的重心转向了Macintosh。
|
||||
|
||||
竞争对手莲花公司同样也没闲着,它在Lotus 1-2-3的基础上又增加了4和5,其中4表示文字处理功能,5表示通信功能,新版软件Lotus 1-2-3-4-5的开发代号是“爵士乐”。而且,莲花公司发现微软在苹果机上开发新的电子表格软件Excel,也宣布进军苹果机市场。
|
||||
|
||||
这让微软坐立难安,比尔 · 盖茨决定加快Excel的开发。1985年5月,他亲自带着研发团队到纽约,开始了Excel for Mac的发布会。
|
||||
|
||||
这次发布会非常成功,战斗以比尔 · 盖茨预期的方式展开了。Excel先发,莲花公司的“爵士乐”晚了三个月登陆苹果电脑,这三个月的先机让微软卖出了大量Excel。更重要的是,莲花公司犯了和WordPerfect一样的错误:它在苹果机上的软件只是简单的移植,Bug很多,性能很差。
|
||||
|
||||
一年后,在苹果机市场,微软Excel已经占据近90%的份额,而莲花公司的产品,虽然依旧占据DOS的大部分市场,却没能在苹果机上掀起风浪。
|
||||
|
||||
可这仅仅是局限于苹果机市场上的胜利,要想真正掌握整个市场,微软必须攻城略地,在Lotus 1-2-3已经占据统治地位的地方继续奋战。这场战斗注定不易,只是比尔 · 盖茨已经有了新武器Windows,这是微软自己开发的图形系统。
|
||||
|
||||
于是Excel for Windows成了微软攻城略地占领苹果机市场后的下一个任务。面向Windows的Excel开发难度更大,因为Windows系统本身也没有开发完善,这就需要Windows组和Excel组同步开发。
|
||||
|
||||
Excel for Windows开发又持续了两年。最初的Windows并不是一个完整的操作系统,而只是提供了跑Excel所必须的功能,但即便这样也够了,1987年Excel for Windows作为一个新星,已经开始冉冉升起。
|
||||
|
||||
Excel for Windows跑在386电脑上。而当时的个人计算机老大IBM为了延长自己286产业的生命线,拒绝使用性能更好的386。微软这个时候也抛弃了和IBM合作的一贯传统,站在了各大兼容机厂商的阵营,这个选择给Excel提供了更好的性能和显示能力,后来也被证明是Excel成功的一个重要原因。
|
||||
|
||||
比尔 · 盖茨还学习了当年Lotus 1-2-3的宣传手法,为Excel投入了数百万美元的宣传费用。产品好加之宣传到位,Excel for Windows迅速铺开,在一年后已经夺取了12%的市场份额。加上莲花公司对Windows这个新操作系统反应迟缓,几年后Excel彻底占领PC市场,让莲花公司越发惨淡。
|
||||
|
||||
接下来,微软还推出了一个软件合集Works,也就是后来Office的前身。Works集成了微软的字处理软件、电子表格、数据库,和通信软件,其目的是应对莲花公司的大杂烩产品“爵士乐”。
|
||||
|
||||
这款组合软件的推出备受欢迎,1987年底已经成为当年销售最好的办公软件。微软因此顺利超越莲花公司,荣登软件公司的头号交椅。
|
||||
|
||||
莲花公司意识到自己在电子表格市场上已经无法阻挡微软的进攻,它很可能会失去在电子表格市场的优势。于是,是继续和微软在电子表格市场竞争,还是另辟新战场,成了莲花公司的困扰。
|
||||
|
||||
深思熟虑之后,莲花公司悄悄转移了阵地,开始秘密开发一个“大杀器”Lotus Notes,这个在今天看来依然是整个软件市场上最为神奇、最牛的一款软件,更何况是在二十多年前呢?
|
||||
|
||||
微软进入办公软件市场可谓屡战屡败,但是比尔 · 盖茨却从来没有放弃过。“红狮会战”是比尔 · 盖茨总结失败经验后的又一次反攻。为了确保在办公软件领域取得胜利,他甚至将新品Excel先在苹果电脑和Mac操作系统上首发。这种锲而不舍的精神,和善于总结经验教训打硬仗的能力,值得我们每个人学习。
|
||||
|
||||
|
||||
|
||||
|
||||
61
专栏/技术与商业案例解读/050大杀器LotusNotes和被收购的莲花公司.md
Normal file
61
专栏/技术与商业案例解读/050大杀器LotusNotes和被收购的莲花公司.md
Normal file
@@ -0,0 +1,61 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
050 大杀器Lotus Notes 和被收购的莲花公司
|
||||
在电子表格市场大获成功,但并不甘于局限在电子表格软件里。1984年,公司CEO吉姆 · 曼兹(Jim Manzi)秘密开始了一项影响深远的开发计划:基于莲花公司的设计,委托Iris公司开发一个“大杀器”,也就是后来长期独霸企业协同市场的Lotus Notes系统。
|
||||
|
||||
Iris公司的创立者是雷 · 奥茨(Ray Ozzie),一个在计算机发展史上非常著名的人物。他曾是莲花公司的早期员工,但是对电子表格兴趣寥寥,对通过网络连接实现的企业协同软件却极有兴趣,因此1984年他离职创立了Iris来实现自己的梦想。
|
||||
|
||||
莲花公司之所以委托Iris公司来开发这款软件,一方面是奥茨是自己人,知根知底,他的兴趣和能力所在都很清晰;另外一方面是,莲花公司内部都沉浸在电子表格软件成功的喜悦中,将电子表格视为公司最核心的业务,因此大部分人对于开始一项全新软件的研发,持观望乃至反对态度。
|
||||
|
||||
然而微软节节胜利,尤其是推出Windows 2.0以后,基于图形界面的Excel可以同时跑在苹果机和PC机上,从而占据了非常大的市场优势,而Lotus 1-2-3却依旧基于古老的DOS字符界面。因此,莲花公司面临一个重要抉择:是继续全力以赴地开发基于图形界面的电子表格,还是集中精力做公司已经秘密投资的办公协同软件Lotus Notes?
|
||||
|
||||
选择前者,就意味着要在微软领先的战场与对方真刀真枪地竞争。然而,电子表格的灵魂人物米切尔 · 卡普尔(Mitch Kapor)已经离开,莲花公司CEO对自己能否战胜比尔 · 盖茨领导的微软缺乏信心。而如果选择后者,虽然这意味着公司要做大转型,但是公司CEO曼兹对奥茨这个人充满了信心。
|
||||
|
||||
曼兹最终说服了董事会,决定将公司主力投入新战场Lotus Notes,以避免和微软正面冲突。Iris公司和莲花公司联合开发的Lotus Notes在1989年推向市场,并大获成功。但是伴随时间的推移,这种联合开发方式造成了很多不便,最大的问题是作为项目总架构师的奥茨身在Iris公司,却要指挥莲花公司的大量员工。于是1994年莲花公司收购了Iris,让奥茨回归莲花并主导Lotus Notes的开发。
|
||||
|
||||
Lotus Notes这个产品,是一个主打企业级通信与协同办公的软件。简单来说,它是一个局域网内联网的客户端/服务器软件,客户端装在每个办公人员的机器上,服务器则用于存储和管理各种信息。
|
||||
|
||||
它主要针对让办公人员方便地交流文件、电子邮件,以及讨论问题等各种协同办公的场景,并集合了日历、邮件、通讯录、文件存储、定制化的审批流程等功能,同时提供大量的接口供用户进行定制化操作和二次开发。
|
||||
|
||||
整体来说,这个软件给人的感觉非常超前,就类似于在汽车还没怎么跑起来的年代里,混进了一辆跑车。所以有人笑称奥茨是从2004年穿越回1984年,主导开发了这样一套软件。因为其中的很多东西到了21世纪以后,大家才司空见惯,但是早在20世纪80年代后期,Lotus Notes就给企业客户开发出来了。
|
||||
|
||||
Lotus Notes不仅仅是最早的客户端/服务器软件,还可能是最复杂的客户端/服务器软件,而且还有一个很大的特点:封闭性。一但用上了这个系统,企业整个办公流程都被套牢在这套系统里,非常难从里面迁移出去。比如,华为公司就经过了十多年的努力,才终于于2015年迁移出了Lotus Notes系统。
|
||||
|
||||
这种集先进性和封闭性为一体的软件,既给莲花公司带来了大量客户,也把客户牢牢地捆绑在了莲花公司的战车上。莲花公司的盈利能力因此大大增强了。
|
||||
|
||||
莲花公司在缺乏电子表格的精神领袖米切尔 · 卡普尔的情况下,尽量避免和比尔 · 盖茨领导下的微软在电子表格战场正面厮杀,通过另起炉灶,在企业协同办公战场把众多企业捆绑进来,成功完成了转型。
|
||||
|
||||
然而这次转型并非没有代价。Lotus 1-2-3可谓莲花公司诸多员工乃至高层的信仰,虽然CEO说服了董事会进行转型,但对Lotus 1-2-3有着浓厚情感的高管们却没有被说服:在转型过程中陆陆续续就有12个副总裁离职。好在,Notes最终大卖特卖。
|
||||
|
||||
而与此同时,个人计算机市场发生了巨大变化,IBM这个发明个人计算机的企业正经历有史以来最严重的一场危机。这场危机起于微软和IBM的博弈,当时IBM在DOS时代失去了对操作系统的控制,试图在和微软联合开发的操作系统OS/2中重新取得统治地位。但祸不单行,此时的IBM因为采用了Intel 80286芯片而导致Intel壮大,失去了对芯片的控制权。
|
||||
|
||||
于是,当Intel再次推出80386芯片时,IBM放弃了支持这款芯片,自然地打起如意算盘,换用自己和摩托罗拉研发的PowerPC芯片。加之它在和微软开发的下一代操作系统OS/2中掌握主导权,IBM想着通过双管齐下,来巩固自己在个人计算机市场的控制力。
|
||||
|
||||
却不料聪明的比尔 · 盖茨和IBM玩起了虚与委蛇的游戏:应付着派几个人去开发OS/2,却自己秘密开发Windows。并且,盖茨还和其他兼容的PC机厂商合作,为对方推出的基于Intel 80386的兼容机提供DOS和Windows系统。
|
||||
|
||||
出现重大战略失误的IBM,不但没能够重新控制个人计算机市场,反而被各大兼容机厂商包围。在个人计算机市场,IBM第一的位置很快被兼容机制造厂商康柏超越。落后的IBM兼容机在1993年给IBM带来了80亿美元的亏损,很多经济评论家分析师认为IBM将在几年内破产。
|
||||
|
||||
此时,后来大名鼎鼎带领IBM转型成功的董事长兼CEO郭士纳临危受命,开始拯救IBM。他决定把IBM从一个硬件,尤其是个人计算机制造厂商,转变为以软件为高优先级,以企业服务为核心的企业。这就是IBM历史上非常有名的从硬件到软件和服务的转型。
|
||||
|
||||
为什么要做这样的转型,后来者众说纷纭。我的理解是,一方面IBM试图以自己的垄断地位,掌控个人计算机市场的操作系统和芯片的走势,并不明智地拒绝使用Intel更先进的处理器,从而导致被各大兼容机厂商超越,也在消费者市场让消费者失去了信心,无法继续攫取大量的利润,反而不断亏损。另外一方面,企业软件和服务市场是利润丰厚的行业,而且IBM一直都很有根基。舍弃亏钱又没太多希望的个人计算机行业,专注企业软件和服务市场,是迅速扭亏为盈走出困境的好选择。
|
||||
|
||||
IBM在企业级市场传统上有很多的市场份额,包括大型机、小型机、专用操作系统、数据库等都在企业市场有很高的占有率。这个转型既有利于IBM甩掉赔钱的业务,又有利于巩固利润丰厚且自己早有根基的企业软件市场。
|
||||
|
||||
为了成为企业软件和服务的主导者,IBM一边内部整合自己的软件体系,一边开始搜罗外界可以收购的对象。作为企业协同软件领域的唯一主导者莲花公司,很快进入了IBM的视线。1995年,IBM决定恶意并购莲花公司。当时莲花公司的股价32美元一股,IBM开出60美元一股的股价,后来又涨到了64.5美元一股。
|
||||
|
||||
但是莲花公司不想卖,还找到了AT&T求助。但AT&T对于莲花公司并非必须要收购,加之IBM又已经将股价翻倍,AT&T不想做“冤大头”。IBM历史上很少有这样强行收购的行为,那为什么当时郭士纳决定不惜成本收购呢?公开的说法是,郭士纳觉得莲花公司的Lotus Notes对IBM转型成为企业软件和服务公司至关重要。
|
||||
|
||||
收购之后,莲花公司CEO就直接辞职了,IBM非常担心其他核心开发人员和高管纷纷离职,于是花大价钱收买了高层,包括Lotus Notes的总架构师奥茨,同时对莲花公司员工保证说,收购之后你们公司依旧会保持独立运作。IBM最终通过种种措施稳住了员工,在一定时间里没有让莲花公司变成一个空壳。
|
||||
|
||||
然而,2001年IBM对莲花公司进行了一次重组。简单来说,就是把在剑桥的原莲花公司开发人员和机构,都重组到了IBM总部,从而结束了自1995年收购以来IBM承诺的莲花公司独立运作的历史。伴随重组,Lotus.com网站上也被悄悄抹去了莲花公司的痕迹,代之以IBM的商标。奥茨也离开了IBM。
|
||||
|
||||
失去首席架构师的Notes,在IBM的开发维护下开始呈现颓势,新功能增加得杂乱不堪,新版客户端有严重的内存泄漏问题。2008年我在IBM研究院实习的时候,使用过Notes,这个软件对内存的消耗到了令人发指的地步,机器经常毫无缘由地卡顿半分钟到几分钟不等。
|
||||
|
||||
Notes原本是一个功能上非常先进的产品,性能也很不错,后来被IBM硬生生做成了性能堪忧的产品。再后来,Notes在大部分公司里也渐渐消失了。我有时候在想,如果莲花公司没有被收购,继续独立发展的话,今天不知道会达到一个什么样的高度。
|
||||
|
||||
|
||||
|
||||
|
||||
57
专栏/技术与商业案例解读/051无敌寂寞的微软之为创新而创新.md
Normal file
57
专栏/技术与商业案例解读/051无敌寂寞的微软之为创新而创新.md
Normal file
@@ -0,0 +1,57 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
051 无敌寂寞的微软之为创新而创新
|
||||
一、 微软的垄断捆绑和一场旷世纪的反垄断诉讼
|
||||
|
||||
1995年,微软推出了历史上具有跨时代意义的操作系统Windows 95,从此整个世界正式进入Windows时代,此版系统的受追捧程度用“万人空巷”来形容绝不为过,与iPhone出新品时的抢购盛况有得一拼。微软还同时推出了著名的Office 95,这个包含了Word、Excel、Powerpoint和Outlook的办公套件,可谓微软办公软件的集大成者。
|
||||
|
||||
而纵观市场,因为Windows时代的到来,微软曾经的对手及竞品们已经败落:VisiCalc被Lotus 1-2-3击败退出市场;Lotus 1-2-3又被Excel全面赶超;文字处理市场的大鳄WordStar因内斗破产;另外一个大鳄WordPerfect没有跟上时代,在图形界面时期被微软挤掉。在办公软件领域,微软已经看不到敌人。
|
||||
|
||||
这是属于微软的一年,操作系统和办公软件齐齐开花,比尔 · 盖茨也达到了一个人生巅峰。他在一次受访中表示,整个软件行业很美好,只有一些杂音。他指的是Netscape、Oracle、IBM、Sun、EMC这五家企业。
|
||||
|
||||
微软四顾无敌,行事方式也变得更为大胆。当时正值美国互联网开始兴起,Netscape公司以互联网浏览器开始闻名于美国市场,雅虎也开启了它互联网第一门户的步伐。微软意识到Netscape可能是个威胁,但是收购对方的意愿被拒绝了,于是微软决定大举进军浏览器市场,开发了IE。
|
||||
|
||||
这场著名的互联网浏览器大战,是20世纪末的一场重头戏。Netscape的浏览器,在技术上更领先,但却是付费软件;微软则仗着家大业大不缺钱,免费兜售自己的IE,并借助Windows的垄断地位强行捆绑IE,最终导致Netscape破产。
|
||||
|
||||
1998年,美国司法部联合20个州政府起诉微软,起诉理由就是微软以垄断方式强行捆绑操作系统和浏览器致使Netscape破产。微软被要求进行强制拆分,就和当年拆分美孚石油公司和美国电话电报公司一样。
|
||||
|
||||
这场官司打了3年。2001年微软和司法部达成和解,拆分一事最终没有付诸实施,司法部只是要求微软确保和第三方公司共享API。此外,欧盟也对微软提起了反垄断诉讼,而且诉讼持续时间更久,要求更多。
|
||||
|
||||
反垄断诉讼大大牵制了微软的时间精力。加上2000年互联网泡沫破灭,公司股票跌去大半,又需要交巨额罚款,微软一时间变得小心翼翼,不敢大胆采取激进的商业行为了。但与此同时,公司的进取心也和2000年前不可同日而语。
|
||||
|
||||
二、Office时代之为创新而创新
|
||||
|
||||
与此同时,微软的Office部门在市场上没了竞争对手,陆续推出了1997、2000以及2003等版本,每个版本都有长足的进步。
|
||||
|
||||
其中,Office 2000是非常经典的一版,它功能齐全、Bug罕见、系统稳定,几乎可以完美满足用户需要的所有功能,一经推出就大受欢迎。但也正是因为Office 2000太出色了,Office 2003没有多少本质性的更新,因此销售得非常不理想。
|
||||
|
||||
然而,微软主要靠三年一次的Office升级来卖新版本盈利,Office 2003卖不动,就直接影响了公司营收。所以微软犯了难:到底怎样才能让用户继续购买自家软件呢?
|
||||
|
||||
办法总是会有的,Office 2007版上市时,微软开始了大力宣传,宣传重点是:微软经过多年研究发现,自己那个从DOS时代就有的菜单非常反人类,无助于提高大家的工作效率,不是最好的设计,而Office 2007会推出一种全新的UI,即Fluent UI。
|
||||
|
||||
Fluent UI在正式推出时改名Ribbon,Office从此告别了菜单的年代,Ribbon从2007年一直保持到了现在。
|
||||
|
||||
Ribbon的推出,给Office制造了一个非常大的热点。这是微软Office自诞生以来前所未有的创新,而且是微软在没有竞争对手的情况下,自己革了自己的命。Office 2007则是微软Office历史上极具争议性的一款产品,它的出现与微软的一贯做法非常不符。Office 2007非常激进,用户无法选择退回到经典菜单,这在微软的历史上可能是唯一的一次,即使是Windows 7也保留了用户回到经典Windows菜单的选项。
|
||||
|
||||
这款极具争议的产品,和其前任Office 2003在市面上的影响力非常不同。因为有了新的Ribbon UI,很多用户开始升级到新版本,当然持观望态度的用户也很多。但是一个企业里不可能长期存在两套界面和操作截然不同的版本,所以用户做出选择:要么保持2003及更低版本,要么全面升级到2007。但是微软逐渐停止了对Office 2003的技术支持,企业最终也就都切换到了Office 2007或者更高版本。
|
||||
|
||||
在Office 2007里,只有Word、Excel和PowerPoint三个产品采用了Ribbon,其他Office产品则延续了经典菜单,但三年后发布的Office 2010中所有产品都切换到了Ribbon。Ribbon的引入和这两个版本的推出,给微软的Office部门解决了一个当务之急:如何让用户继续掏钱购买新版Office。
|
||||
|
||||
这两版Office的销售历史一直不错,主导Ribbon开发的朱莉 · 拉尔森-格林(Julie Larson-Green)也接连荣升,直至微软副总裁的职位。
|
||||
|
||||
但2007年微软以如此激进的方式推进Ribbon,到底是为了用户好,还是为了解决Office 2003无人愿意购买的当务之急呢?Ribbon到底是有历史意义的创新,还是为了搞创收、为创新而创新?这些问题的答案,外人恐怕永远无法确切知道了。
|
||||
|
||||
以现在的眼光来看,2007年微软用Ribbon取代菜单,这到底是进步还是退步,是个见仁见智的问题。我个人的体会是两者其实都差不多,只是一套不同的界面而已。有一些研究表明,新版的Ribbon可以减少鼠标操作人员的点击,但是Ribbon的快捷键更为难用,所以Ribbon既有进步也有退步的地方。对初学者是更友好了,对熟练的老用户则更难用了。
|
||||
|
||||
我们知道,一般来说,办公软件的优化,不应该损害老用户的使用体验,而Ribbon却恰恰相反。由此来看,我更倾向于微软是在通过为创新而创新的举动,结合自己在Office市场的垄断地位,强行推出新的功能,从而引发新一波的购买潮,解决Office 2003产品那样叫好不叫座的局面。
|
||||
|
||||
这个解决方案当然是成功的,但是却没有解决根本问题。Office 2010推出以后,Office 2013再次面临了同样的问题。Office 2013和2010比,产品差别并不大,因此其销售也如2003版一样不理想。
|
||||
|
||||
亲爱的读者,你觉得Office软件销售时好时差的原因是什么?微软要怎样才能从根本上解决Office软件营收不稳定的问题呢?
|
||||
|
||||
|
||||
|
||||
|
||||
65
专栏/技术与商业案例解读/052办公软件的新时代:微软和谷歌的战斗.md
Normal file
65
专栏/技术与商业案例解读/052办公软件的新时代:微软和谷歌的战斗.md
Normal file
@@ -0,0 +1,65 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
052 办公软件的新时代:微软和谷歌的战斗
|
||||
屡败屡战的微软通过“红狮会战”取得了电子表格战争的胜利,莲花公司则另辟新市场,通过推出企业协作系统Lotus Notes领先时代多年。然而,时运不济的莲花公司在开发出这一“神器”之后,却遭到了IBM的恶意收购,“神器”也渐渐毁在IBM手中。
|
||||
|
||||
从历史上看,硅谷无疑是整个计算机发展的中心。只有2000年前后因为微软的崛起,让西雅图领先了几年。而微软成为整个软件业的霸主时,自然遭到了硅谷公司的抵抗。
|
||||
|
||||
谷歌作为互联网时代成长起来的第一家公司,也是迄今为止最重要的公司之一,其地位不言而喻。偏偏谷歌也有一个办公软件梦,毕竟这市场巨大,只要能入场,肯定有饭吃。
|
||||
|
||||
然而想要在这一市场掘金着实不易,一家家公司在这一战场上崛起又没落,无不证明了屡败屡战并最终奠定帝国地位的微软,是怎样一个实力强悍、久经沙场的“老司机”。进入“老司机”微软的帝国范围,一定非常危险。
|
||||
|
||||
谷歌决定通过一系列收购,完成在办公领域的出击。 2006年,它收购网络字处理软件厂商UPStartle,同年又买下在线电子表格制作公司2Web Technologies,2007年它又通过收购Tonic Systems收获幻灯片制作软件。这样一来,微软办公软件里面最重要的“三件套”Word、Excel、PowerPoint的替代产品,谷歌都具备了。谷歌在整合了这三家公司的产品后,又经历了长达三年的Beta测试,最终于2010年正式推出了名字叫作Google Docs的办公软件套餐。
|
||||
|
||||
Google Docs是包括了文字处理软件、电子表格和幻灯片的云服务,这里并不是传统意义上的软件,用户无需在本地安装任何东西,而是通过浏览器访问对应的网址就可以使用这些云服务了。从这个意义上来说,Google Docs和微软的Office有本质的不同。前者是基于浏览器的云服务,后者是需要本地安装的软件。
|
||||
|
||||
Google Docs这款软件有两个很有特色的创新。
|
||||
|
||||
|
||||
第一,它是基于浏览器的云服务,而不是传统意义上的软件。 这使得用户可以把资料保存在网上,随时随地通过不同的设备接入,进行编辑。
|
||||
第二,它支持网络协同办公。 多个人可以同时更改一个文档,互相之间都能看到对方的改动。
|
||||
|
||||
|
||||
这两大特色,让Google Docs一经推出就大受追捧。媒体们也纷纷表示,云服务是未来。
|
||||
|
||||
同时代的微软,日子过得则有点惨淡:在搜索领域,必应搜索引擎做得一塌糊涂;在社交领域,MSN Messenger、Space等社交软件做砸了;在移动互联网领域,Windows Phone也被苹果和安卓打得找不着北。
|
||||
|
||||
这时,微软最牢固的根基:办公软件领域,突然被谷歌杀了进来。入场方式还是极为吸引眼球、颇具杀伤力的云服务方式。那种随时随地可以和其他人一起编辑同一个文档的感觉,让大家都觉得微软本地安装Office的方式很落伍。
|
||||
|
||||
此时,无论是外部,还是微软内部,都觉得云服务才是未来。于是,微软秘密组建了一个叫作Office 365的部门。这个部门刚成立的时候,有两大任务,分别对应于Google Docs的两大创新点:
|
||||
|
||||
|
||||
第一,如何在浏览器里面实现对Office文档的编辑,包括Word、Excel、PowerPoint;
|
||||
第二,如何实现多人协同编辑同一个文档的功能。
|
||||
|
||||
|
||||
Office 365的研发部门意识到,如果要实现这两大功能,需要对Office的整个软件架构做一个大手术。简单来说,需要把Office软件的UI层,和实现UI对应的功能层分离开来。这样一来,Office 365的团队就可以在浏览器里通过复用底层的功能模块,用JavaScript重新实现UI。
|
||||
|
||||
与此同时,Office 365的研发部门还亟需实现一个网盘。因为只有能够把文件存在网盘上,才有可能做到让用户随时随地、通过不同的设备来编辑同一份文件。这个网盘最初叫作SkyDrive,但是因为已经被别人注册了商标,后来只能改名为OneDrive。
|
||||
|
||||
有了和UI分离的底层模块的复用,有了重新实现的UI,有了网盘,微软的Office终于可以在浏览器里进行编辑了。后来,协同编辑的功能也被加了进来。微软的办公软件终于在功能上可以和谷歌媲美了。
|
||||
|
||||
伴随功能的扩张,Office 365的队伍也迅速扩充。到后期,Office的高层意识到没有必要分传统Office和Office 365,于是要求Office全体成员开发的任何一个功能,都需要同时支持本地的软件和基于浏览器的云服务。至此,Office 365作为一个独立团队,完成了它的历史使命。
|
||||
|
||||
很多人曾经盼望Google Docs和Office 365之间有一场剧烈的交锋,而谷歌会拿下办公软件市场的大量份额。然而,此事并没有发生,Google Docs虽然来势汹汹,最终却没能够威胁到微软的统治地位。
|
||||
|
||||
谷歌的软件虽然是云服务,但是其实现的功能却比较简单。尤其是电子表格软件,其功能和Excel基本没有可比性。这就导致了大量的企业级用户,无法从微软的办公软件切换到谷歌的办公软件。
|
||||
|
||||
所以,谷歌虽然在云服务和多用户协同办公领域拔得头筹,却忘记了无论是云服务还是软件,用户最看重的还是其能够提供的功能。因为谷歌三件套的功能太过单薄,而微软又逐渐实现了谷歌三件套支持的云服务和协同办公,所以最终没有对微软造成实质性的伤害。
|
||||
|
||||
但是,聪明的微软却利用这一次转型,做了一次收费模式的创新。原来的微软是平均每三年推出一个新版本的Office软件,通过卖新版软件来赚钱。这种赚钱方式不但辛苦,而且需要不断地创新。而伴随着Office软件越来越成熟,创新也越来越艰难。
|
||||
|
||||
借助云服务模式,微软推出了Office 365服务,这个服务是按月收费的。有不同级别的套餐,每个月从几美元到几十美元不等。微软逐渐取消了用户购买软件的选项,所有使用微软Office的人,都逐渐地转型到了Office 365,只能通过office 365订阅付费了。
|
||||
|
||||
Office 365的这种收费模式,大大增强了微软的盈利能力和盈利的稳定性,同时大大减少了微软开发新版本的迫切需求。微软高层曾经在接受采访时表示,用户和营收的增长,已经超过了他们的预期。
|
||||
|
||||
谷歌作为一个竞争对手,给大家带来了耳目一新的云服务,却倒在了功能不够健全上。微软的Office部门,无愧于“微软最为强悍的部门”这一称呼,成功捍卫了自己在办公软件市场的统治地位,并借此转型成为云服务提供商,改变了自己的收费模式。
|
||||
|
||||
只是谷歌这个敌人的出现说明:敌人往往会在你意想不到的地方出现。微软赢得了这次战斗,那么接下来另一个敌人到来,故事又会如何呢?
|
||||
|
||||
|
||||
|
||||
|
||||
51
专栏/技术与商业案例解读/053异军突起的Slack.md
Normal file
51
专栏/技术与商业案例解读/053异军突起的Slack.md
Normal file
@@ -0,0 +1,51 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
053 异军突起的Slack
|
||||
2016年9月,微软华人副总裁陆奇宣布因身体原因辞职。据说此前,他作为Office部门的负责人做出了一项决定:收购一个叫作Slack的公司。这项决定后来被微软的CEO萨提亚和创始人比尔 · 盖茨否决了。
|
||||
|
||||
2016年11月2号,微软宣布了功能上与Slack超级雷同的Teams应用,而同一天Slack则买下《纽约时报》的整版广告表示欢迎微软来PK,他们有信心打赢这场战争。
|
||||
|
||||
这两件事都指向了一个叫作Slack的公司和软件。Slack到底是什么?陆奇想收购,陆奇离职以后微软又要大力推出类似软件。
|
||||
|
||||
Slack,是这两年来企业办公市场里最火爆的软件;它也是微软数十年如一日努力战胜Lotus Notes以来,在企业协同软件市场遇到的最为强悍的竞争对手。今天我们就一起来看看Slack这个异军突起的公司。
|
||||
|
||||
Slack的CEO是斯图尔特 · 巴特菲尔德(Stewart Butterfield),这位老兄最擅长的事情是做游戏。不过了解他的人都知道,他两次创业做游戏都失败了,游戏的副产品却都成功了。
|
||||
|
||||
第一次创业做游戏失败后,他发现游戏中的照片分享功能非常成功,于是将这个功能单独拿了出来,并命名为Flickr,2005年被有钱任性的雅虎出钱买下。作为收购的一部分,斯图尔特需要在雅虎工作一段时间,但按照他后来的说法,在雅虎工作实在是没什么意思,于是合同期满钱拿到手,他就离开了。
|
||||
|
||||
离开后,斯图尔特再次选择创业做游戏。当年一起创业的小伙伴们,此时已经分散到天南海北,于是为了方便大家沟通,这些程序员们决定开发一款内部通信工具。这个工具可以实现存档、检索等各种功能,以至于他们之间的沟通再也不需要邮件了。
|
||||
|
||||
但遗憾的是,这次开发的游戏依然失败了,所谓命运多舛,估计就是这个意思吧。按照之前做Flickr的经验,斯图尔特决定推广一下这个内部通信工具,并将其命名为Slack。
|
||||
|
||||
最初,他们几乎是连哄带求地说服了几家公司来试用,不过试用结果非常可喜,用户非常喜欢Slack。2013年8月,他们发布了Slack的测试版,之后用户便以每周3%到5%的速度开始增长。
|
||||
|
||||
公司转向经营Slack以后,开始迅速发展。2014年2月,Slack正式上线,当天就有8000家公司注册。在当月,Slack就以2.5亿美元的估值,获得了4275万美元的融资。更令人吃惊的是,同年10月Slack再次融资1.2亿美元,估值更是达到11.2亿。从内测到上线,短短一年时间Slack就成长为一个独角兽,这是绝无仅有的记录。
|
||||
|
||||
Slack为何如此火爆?在我看来,原因主要有以下几个。
|
||||
|
||||
|
||||
Slack有着非常强大的内部沟通功能,正好可以满足计算机和互联网行业从业人员的需求。
|
||||
Slack有着非比寻常的搜索功能。它支持在消息、文件、通知等项目内做跨类搜索,而且这种非常精准。
|
||||
Slack自带一个机器人。这是Slack的特色之一,它不但可以自动回答用户Slack的使用问题,而且还允许对特定企业的特殊需求进行开发和定制。Slackbot无疑是Slack里非常亮眼的一个特色。
|
||||
Slack有着非常强大的整合第三方应用的功能。Slack整合了现在流行的大部分应用,用户完全不用离开Slack,就可以直接操作其他软件。比如,Slack可以整合Outlook,让用户在Slack内直接收发邮件。
|
||||
Slack强大的应用整合功能,得益于它主推的应用商店App Directory。这个应用商店,类似苹果的iTunes、App Store和谷歌的Google Play应用商店。第三方通过Slack提供的API可以写APP,实现自己的软件和Slack之间的整合。现在Slack对第三方应用的支持,很多都是由第三方调用Slack提供的API自己开发的。
|
||||
|
||||
|
||||
作为Slack的忠实用户,我必须说,它非常适合计算机和互联网行业的从业人员使用。无论是使用习惯、界面布置、第三方应用的整合,还是强大的搜索功能,它都在个人办公方面给我带来了无穷帮助。我可以拍着胸脯说,这是我见过的、最好用的团队沟通和协作软件了,没有“之一”。
|
||||
|
||||
Slack不断发展,它的估值也在不断升高。2016年4月,Slack完成了新一轮融资,估值达到38亿美元。当时,陆奇作为Office的最高负责人,看到这个软件如此强大的信息整合能力和如此迅猛的增长速度,想以80亿美元的价格收购。然而世事难料,收购计划并未落实,陆奇却很快离开微软。
|
||||
|
||||
这前后的原因不得而知,但有一点是肯定的,Slack的这种信息整合和搜索功能,对微软办公软件帝国的地位造成了威胁。传闻,比尔 · 盖茨想利用好刚刚收购的Skype,将它发展成为微软在企业协同领域的王牌产品,与Slack进行竞争。
|
||||
|
||||
果不其然,2016年11月,微软发布了新的企业协同工具Teams的预览版,并于几个月后发布了正式版。遵照比尔 · 盖茨的意见,这个Teams是由原来Skype组的成员带头开发的。很明显,** Teams模仿了Slack,就是冲着Slack去的。**
|
||||
|
||||
截至2017年,Slack在企业协同领域,已经取得了丰厚的成绩,全球日活跃用户超过500万。尤其在中小型企业里,Slack更是首选。
|
||||
|
||||
虽然,现在Teams有着各种各样的问题,比如软件跑得很慢、能够连接的第三方应用很少等等,但是我们知道,微软在企业办公领域基本上是“屡战屡败,屡败屡战”,而且最后在不管多么艰难的环境下,都取得了最后的胜利。那么,面对这个一次又一次取得胜利的微软,Slack真的准备好了吗?
|
||||
|
||||
|
||||
|
||||
|
||||
43
专栏/技术与商业案例解读/054办公软件战斗的启示:内忧总是强于外患.md
Normal file
43
专栏/技术与商业案例解读/054办公软件战斗的启示:内忧总是强于外患.md
Normal file
@@ -0,0 +1,43 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
054 办公软件战斗的启示:内忧总是强于外患
|
||||
今天来看,微软作为办公软件领域的霸主当之无愧,它的Office系列是事实上的业内标准。但是办公软件的发展历史告诉我们,故事的开始并不是这样的。相反,无论是在字处理软件市场,还是在电子表格市场,微软不但不是初创者,而且在很长一段时间里,都有其他公司与其分庭抗礼,甚至比它强得多。
|
||||
|
||||
那么,为什么这些公司一个接一个地倒下了,微软却成了最后的霸主呢?是微软战斗力特别强吗?是这些企业的产品不行吗?
|
||||
|
||||
都不是。办公软件的战斗史告诉我们:这些公司大都死于内忧;而微软“屡战屡败,屡败屡战”,却几乎没有出现过内部问题。
|
||||
|
||||
内忧往往比外患更可怕。这个道理看似浅显易懂,但很多公司都败在内忧的问题上。在办公软件的发展历程里,你还记得有多少公司是因为这样的问题倒下的么?如果再扩展到办公软件之外的企业,这个比例又将是多高呢?
|
||||
|
||||
说到内忧在企业中的表现形式,主要有以下两种。
|
||||
|
||||
第一种是内斗。有些企业还没有站稳脚跟就开始内斗,MicroPro公司的WordStar就是一个非常典型的例子。因为内斗,MicroPro不同版本的WordStar开始互掐,甚至在用户面前都不能做到自圆其说。很难想象一个出道最早、占有率很高的软件,到最后被自己玩死了;而公司的创始人们,面对被自己窝里斗搞死的企业,又是一种什么样的心情呢?
|
||||
|
||||
企业发展过程中,这种内斗其实非常常见。举个例子,Twitter四位创始人之间的内斗,就是硅谷近年来广受关注的事情。CEO换了好几轮,Twitter却依然不死不活。最近几年杰克 · 多西(Jack Dorsey)成了CEO,没了新的内斗,Twitter才渐渐趋向稳定,终于开始盈利。
|
||||
|
||||
这里需要注意的是,我所说的是关系到公司生死存亡的、空耗型的恶性内斗。如果一个公司内部有多个团体做同一个产品,互相PK,那就不一定是坏事。事实上,很多成功的企业,尤其是“家大业大不缺钱”的主儿,往往在某些技术方向上,让企业内部不同的部门做类似的产品,并在最后进行优胜劣汰。
|
||||
|
||||
这在我看来是很有成效的一种做法。毕竟通过竞争,选择最合适的解决方案,往往会给公司提供最好的软件。但是很多时候内部竞争的发生和发展,并不一定可以控制在一定范围内。如果内部竞争的发生和发展到了足以影响公司经营的地步,那就非常危险了。一不小心,可能会搭上整个公司的前途。
|
||||
|
||||
第二种内忧可能更常见,那就是不思进取,不懂得居安思危。 有些企业在确立了垄断地位后,觉得自己一家独大就不需要担心未来了;有些企业,还没来得及确立垄断地位,就开始“休息”了。做企业,尤其是互联网行业的企业,属于高风险的事情,稍微在功劳簿上打个滚儿,可能回头就不知道被哪来的对手掀翻了。
|
||||
|
||||
居安思危是件很不容易的事情,对人、对企业来说都是。比尔 · 盖茨曾说,微软离破产永远只有18个月。可能这就是他在任期间,微软从来没有不思进取的原因吧。纵观办公软件的发展历史,无论是取得了成绩,还是遭受了挫折,微软一直都在前进。所以,最后微软活了下来,更多的同类企业却死得差不多了。
|
||||
|
||||
WordPerfect就是不懂得居安思危的典型,所以当操作系统进入图形界面时代后,它很快就被淘汰了。有人说,这是因为微软的操作系统Windows是自己开发的,有先发优势。然而在我看来,这个说法是不成立的。因为,微软在自己的Windows操作系统还没成熟的时候,就在给苹果开发Excel。WordPerfect如果想转型到图形界面的话,有足够的时间去开发新版本。
|
||||
|
||||
再比如,Novell是DOS时代著名的网络操作系统。在当时可谓:在个人计算机上,单机靠DOS,联网则用Novell。但是,伴随着从DOS到Windows的飞跃,Windows NT服务器自带网络,并且有更好用的图形界面,Novell就自然而然地消亡了。
|
||||
|
||||
当然,Novell并不是没有采取过自救行为。比如,Novell后来买下了WordPerfect,试图在办公领域和微软竞争。但是没过多久就发现这条路行不通,又把WordPerfect给卖掉了。总结原因,Novell大部分时间沉迷于DOS时代的霸主地位,忽视了潜在的危机,等变革真正到来的时候,就理所当然地被革了命。从这里可以看出,居安思危是一个企业持续成功必须具备的素质。
|
||||
|
||||
那么,如何避免内斗,又如何做到居安思危呢? 这个答案价值10亿。我想历史上很多人回答过,也有很多种答案,但是每个人的看法不同,这些答案也是“仁者见仁,智者见智”。
|
||||
|
||||
我在这里推荐一个“良方”:亚马逊领导力准则。亚马逊是一个很有活力的公司,它的很多条领导力准则都对保持企业的活力和发展、防止内斗和不思进取有莫大的帮助。这个专栏里,我也通过系列文章陆续分析讲述了这些领导力准则。
|
||||
|
||||
比如“要有硬骨头”,这条领导力准则说的是,讨论意见的时候大家可以畅所欲言,在做出决定以后所有人都遵循这个决定;事情做完之后无论成败,都不会秋后算账赖到某个人身上。这个原则就可以有效地防止企业内部发生剧烈斗争。
|
||||
|
||||
|
||||
|
||||
|
||||
47
专栏/技术与商业案例解读/055办公软件战斗的启示:敌人的出现常常出其不意.md
Normal file
47
专栏/技术与商业案例解读/055办公软件战斗的启示:敌人的出现常常出其不意.md
Normal file
@@ -0,0 +1,47 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
055 办公软件战斗的启示:敌人的出现常常出其不意
|
||||
微软在奠定了办公软件行业的霸主地位之后,很长一段时间里都不再有可以对其构成威胁的对手。这也许是它在办公软件领域耕耘太久,认识更为深刻,也许是它的软件成为了这一领域内事实上的标准。
|
||||
|
||||
谷歌这一竞争对手的出现似乎有些出人意料,它是从互联网办公的角度展开攻势的。谷歌出品的Google Docs,只需要一个浏览器就可以使用,而不需要安装客户端。这种新型的办公和协作方式显然让微软很懵,微软实在是没有料到敌人会从这个角度出招。
|
||||
|
||||
好在谷歌虽然对互联网的理解很深刻,但是对办公软件的理解还是过于浅薄。虽然Google Docs的新型办公和协作方式吸引了不少眼球,但是因为功能过于简单而未能满足用户的需求。
|
||||
|
||||
很快,微软就开始有模有样地学起了谷歌,搞起了Office 365。Office 365里面很多的功能,比如说浏览器可以打开Word文档、可以直接多人协同编辑等等,说白了都是效仿谷歌的。只不过微软后来做得还不错,而谷歌在办公软件功能本身的提升上却没什么进展,所以微软顺利度过了这次危机。
|
||||
|
||||
Slack的出现估计更是大大出乎微软的意料。这个协同办公软件迅速占领了很多中小型企业市场,大家不再需要零散的Email或者在线消息沟通方式,取而代之的则是频道的概念。
|
||||
|
||||
Slack的“频道”类似于常见的聊天室,一个频道就是一个聊天室,相关人员都可以加入,所以做同一件事的人可以集中在一个频道里面协同办公。
|
||||
|
||||
对于这个新出现的竞品,微软也只能模仿,做了个雷同的Teams应用。至于结果鹿死谁手,现在还很难预料。
|
||||
|
||||
办公软件的战斗告诉我们,敌人的出现,不一定在同一个领域,有时候一个领域、一个产品被颠覆,甚至可能是看起来毫不相关的产品。例如,相机领域颇有建树的尼康最终关闭中国公司, 主要就是因为智能手机的兴起,这就和相机本身关系不大了。
|
||||
|
||||
同样的故事也发生在GPS厂商那里。曾几何时,GPS厂商风光无限。无论是TomTom还是Garmin,在北美市场都占据了极为重要的地位。只是自从有了智能手机和谷歌这样的公司以后,智能手机实时更新的地图和导航,就迅速取代了GPS。实时导航结合离线地图几乎无所不能,既有传统GPS的优点,又可以随时更新交通状况,实时计算最佳路径。这显然是传统GPS厂商想都想不到的事情。但是当它发生了,GPS厂商倒闭了。
|
||||
|
||||
如果说这些变革看起来多少还有那么一点关系的话,那么最近口香糖厂商的日子不好过,竟是因为智能手机出现后大家开始沉迷于手机APP,这可能更让人吃惊。 以前大家排队无聊的时候,总会嚼块儿口香糖打发时间,很长一段时间里都如此。然而,智能手机的出现,以及随之而来的各种APP, 使排队变得不再无聊。
|
||||
|
||||
大家拿出手机看看微信、刷刷朋友圈,或者玩几把王者荣耀,消磨时间的方式更加先进有趣,更加让人沉溺其中。于是,无聊嚼块儿口香糖这件事情,就显得不那么重要了。那么,这次口香糖厂商的日子不好过,是不是腾讯公司也算背后推手呢?
|
||||
|
||||
前段时间我看到一条新闻,说杭州的治安比前些年好多了,小偷几乎不见了。因为智能手机的出现,移动支付开始普及,在杭州只要智能手机在手,消费几乎都可以用无现金的方式通过移动支付完成。小偷们还可以继续偷手机,但是却没有现金可偷了。而手机销赃相对于窃取现金来说更加困难,所以愿意通过偷手机销赃赚钱的小偷还是少数。这样一来,小偷少了很多。估计他们自己,也没有想到竟会这样失业吧?
|
||||
|
||||
这样的故事还有很多,但主旨都是一样的。人类社会发展到今天,很多时候一个行业、一个领域的变革,一个竞品的出现,都可能源自一个意想不到的角度。真正的敌人常常出其不意,所以在正面防守的时候,不要忘了“马奇诺防线”的故事,不要让敌人绕到背后占领根据地才好。
|
||||
|
||||
面对这样的情况,企业的生存难度无疑大了很多。所以,一个已经占据行业优势地位的企业,也应该时刻居安思危,不断拓展新领域。可以看到,大型互联网公司,除了在自己最擅长的领域里面做得非常出色,无不在非常努力地进行全方位拓展。
|
||||
|
||||
当然,这种全方位拓展带来的往往是大概率的失败。可即便如此,这些公司依旧毫不犹豫投入大量资金去拓展业务。只有不断尝试,才有可能抵御住不知会从哪儿冒出来的危机。这种方式是否高效尚不得而知,但目前看起来创新、全方位地创新,的确是面对不确定性最有效的方式。
|
||||
|
||||
此外,大公司还有其他两种常见的应对策略:收购有威胁的公司,或者仿造有威胁的产品。这两种策略,不同的公司在不同的情景下都实施过。当初陆奇还在微软的时候,就打算收购Slack,不过据说这个计划被比尔 · 盖茨和萨提亚否决了,随后微软就开始模仿Slack做起了Teams。
|
||||
|
||||
大公司之所以可以这样做,一方面是雄厚的资金支持,另外一方面是可以迅速调集很多资源。从后者来说,对市场的迅速反应能力非常关键,而目前在这方面做得最好的当属亚马逊了。
|
||||
|
||||
大公司面对不知将来自何处的威胁,基本上也就只有这些办法了。但换个角度看,这也侧面反应出,相对于10多年前的传统软件行业的发展,近些年兴起的互联网行业的变革实在是太快了。APP层出不穷,商业模式不断推陈出新。尽管有所谓的垄断,小公司乃至创业公司,也完全有从对手难以想象的角度去颠覆其垄断地位的可能性。
|
||||
|
||||
换句话说,小公司的机会是无穷无尽的。所以,找到合适的方式,是小公司成功的关键。每个行业都有可能被颠覆,每个垄断者的地位都可能被不知来自什么方向的对手撼动,如此精彩的行业和如此丰富的机会,也是每个互联网行业创业者的有利条件。
|
||||
|
||||
|
||||
|
||||
|
||||
59
专栏/技术与商业案例解读/056半条命的Dota帝国Valve:半条命.md
Normal file
59
专栏/技术与商业案例解读/056半条命的Dota帝国Valve:半条命.md
Normal file
@@ -0,0 +1,59 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
056 半条命的Dota帝国Valve:半条命
|
||||
今天我要说的是一家总部设在西雅图的知名游戏公司Valve Software,即维尔福软件公司。
|
||||
|
||||
早期在西雅图创业的公司,都有微软的背景,比如说Expedia、RealNetworks等,这源于微软在上市以后股票大涨几十倍,造就了一批衣食无忧又有想法的人。Valve的两位创始人也出自微软,他们是加布 · 纽维尔(Gabe Newell)和麦克 · 哈灵顿(Mike Harrington)。
|
||||
|
||||
这两位大神都是非常热爱游戏的骨灰级玩家。他们作为Windows操作系统的早期开发者,在微软混到衣食无忧之后,便决定自己创业开发游戏。两个毫无游戏开发经验的人,第一个创业想法居然是做一家游戏公司,实在有点不可思议。
|
||||
|
||||
更重要的是,他们并不想做那些相对简单的游戏,而是要做一款震撼全世界的游戏。当然,老司机虽然不懂游戏开发,基本功却相当扎实。要知道,能够写操作系统的人,写程序的能力肯定极强。
|
||||
|
||||
Valve公司名的由来已经不可考了,这个看似普通的名字,并不妨碍它成为这20年里最有影响力的游戏公司。
|
||||
|
||||
历经一圈考察以后,编程界的老司机,却也是游戏界“菜鸟”的两人决定实行“拿来主义”,用Quake的引擎开发了一款3D动作游戏。这款被命名为《半条命》的游戏,在未来的20年间红遍全球,吸引了无数的骨灰级粉丝。
|
||||
|
||||
游戏不只是开发这么简单,它还需要发行商,正好当时同在西雅图东区的游戏发行商Sierra Online打算发行一款动作游戏。于是双方达成了发行协议,Valve的两位创始人接下来可以专心打造游戏了。
|
||||
|
||||
这款游戏第一次亮相是在1997年的E3游戏展,当时只是个半成品,所谓“是骡子是马拉出来溜溜”这句话永远都是成立的。Valve的两位老司机虽然初入游戏圈,但雏凤清于老凤声,他们的游戏《半条命》一登场,就吸引了大量的目光。
|
||||
|
||||
这款游戏和当时流行的其他游戏有一个显著的不同,它既没有全场打打杀杀,也没有利用过场动画来讲故事这种老套的方式。反之,它的故事就发生在游戏的过程中,游戏就在故事中进行,极强的代入感让大家深切感受到了这款游戏的与众不同。
|
||||
|
||||
E3上一炮打响,让大家知道这注定会是一款大红大紫的游戏。然而,接下来的事情,就如同任何一款知名游戏一样,跳票发生了。本来预期1997年下半年能够发布的游戏,到了年底还是没有影子,Sierra Online开始怀疑这个公司是否真的有能力把游戏做完。怀疑的种子一旦种下,就慢慢开始成长。
|
||||
|
||||
游戏的开发并不顺利,老司机遇到新难题,确实没想那么多。于是游戏继续跳票,到了1998年春天仍然没有影子,夏天同样没有交付。在拖了一年以后,1998年感恩节附近,这款游戏终于上市了。
|
||||
|
||||
《半条命》游戏一上市,就吸引了大量的玩家,市场评价不是一般得好。这无疑是个传奇:两个毫无游戏开发经验的人,在经过两年多时间之后,通过第一款游戏一举站上了游戏界的巅峰。
|
||||
|
||||
公司之后的发展,和其他人预想的不太一样。大家觉得,成功以后他们应该会迅速发布第二个系列,很多游戏公司以往都是这样做的,然而Valve却有不同的想法。
|
||||
|
||||
MOD大法在游戏里是很常见的一个东西。也就是说,游戏公司开放一部分代码或者工具,其他游戏玩家在此基础上制作扩展包,有些时候这种扩展包甚至是一个崭新的游戏。有的游戏公司非常支持MOD,但也有强烈反对者。Valve的两位创始人虽然是游戏开发界的新手,但确实是游戏玩家里的“老司机”,他们对于MOD是非常支持的。
|
||||
|
||||
《半条命》成功以后,Valve公司走向了一条阳光灿烂的MOD大道。《半条命》的大量代码被开放,而社区玩家开始了MOD,这种MOD里很多游戏质量都不低,其中最负盛名的是《反恐精英》。
|
||||
|
||||
《反恐精英》完全颠覆了《半条命》的游戏玩法。和《半条命》的全员无差别大乱斗不同,《反恐精英》是一款多人回合制射击游戏,人物和人物之间也差异显著。从1999年推出Beta测试版后,它一直就非常受欢迎。
|
||||
|
||||
Valve很开心地把《反恐精英》团队买下,加入了自己的公司。之后《反恐精英》系列也发行了好几个续作,这不仅让Valve赚了大量的金钱,更收罗了很多游戏开发人才。虽然是大家都玩的MOD大法,只有Valve赚得笑开了花。
|
||||
|
||||
这个时候创始人之一的哈灵顿因为理念不合离开了团队,开始长假,并在此后创办了新的公司且被谷歌收购。其实,哈灵顿的离去始终是个迷,他自己没有谈过,纽维尔也没有谈过,我们在公开资料里也查询不到什么。但因为他的离去,2000年后的Valve,主要都是创始人纽维尔在管理了。
|
||||
|
||||
在MOD大法这条路上越走越远的Valve已经多年没有新作,市场上对《半条命2》的呼声也越来越高。时隔5年后的2003年,Valve终于展出了《半条命2》。然而时也运也,在游戏即将发行的时候,《半条命2》的源代码和其他相关素材被黑客窃取,公布在了网上。
|
||||
|
||||
更重要的是,这个被偷窃的版本是个未完成品。未完成的《半条命2》不仅难玩,而且有无数的Bug,让久久等待《半条命》续作的玩家大为失望。而这种失望直接反映在销售上,玩家们纷纷通过各种途径表示不会去买即将上市的游戏。最终新的游戏发行商Vivend Universal决定放弃在2003年发行《半条命2》。
|
||||
|
||||
Valve当然不是吃素的,而纽维尔和游戏玩家有着很好的关系。他决定出手,一边向FBI报警,一边让社区帮忙寻找那个罪大恶极的黑客。我常常这样想,上帝是公平的,有些人智商高了情商就比较低,这次黑了Valve的黑客也未能免俗。
|
||||
|
||||
黑了Valve并泄露了源代码的黑客主动现身,并且表示希望为Valve工作。而纽维尔则一边表示愿意提供职位,希望对方来美国,一边却和FBI联系,准备抓捕这个大胆的黑客。黑客终究是没来美国,就在德国被抓了。
|
||||
|
||||
于此同时,Valve和发行商也开始打起官司来。这场官司的主要争议在于,Valve觉得自己可以通过自己的渠道发行纯下载版本的《半条命2》,而不需要通过发行商,但是发行商则认为自己买断了所有的发行权限。
|
||||
|
||||
这场官司打了一段时间,已经严重影响到游戏的发行,再打下去,对谁都不好。双方庭外和解之后,这个屡次跳票,负面新闻不断的《半条命2》终于在2004年的夏天发行。此时,距离《半条命1》已经过去了6年。
|
||||
|
||||
Valve在所不惜也要打官司,希望保留数字下载的发行权,是和它正在做的一个东西紧密相关的。那就是被誉为游戏界iTunes的Steam平台,它比起Valve发行的游戏,在今天对Valve的影响更为重要。有关Steam平台和《半条命2》的后续情况,我们下回分解。
|
||||
|
||||
|
||||
|
||||
|
||||
53
专栏/技术与商业案例解读/057半条命的Dota帝国Valve:Steam平台.md
Normal file
53
专栏/技术与商业案例解读/057半条命的Dota帝国Valve:Steam平台.md
Normal file
@@ -0,0 +1,53 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
057 半条命的Dota帝国Valve:Steam平台
|
||||
上回说到经历了代码被偷,以及和发行商打官司的事件之后,《半条命2》终于发行了。这款游戏最终没有让人失望,Valve出品必属精品,这是必然的。
|
||||
|
||||
《半条命2》里面的NPC(即“非玩家角色”)有很高的人工智能属性,这和当时发行的很多游戏都不同。而《半条命2》使用了Valve后来非常著名的Source引擎,加上《半条命2》里面独有的物理引擎,一切都让这款游戏显得非常独特。
|
||||
|
||||
比如说,在《半条命2》里面因为有对重力的处理,枪支不但可以射击,还可以扔向游戏里面的任何人物或者物体,并且产生符合现实物理系统应有的反应。总之一切都很美好。
|
||||
|
||||
前面我提到Valve和发行商打官司,这其实是因为Valve公司注意到了一个很严重的问题:游戏发行靠发行商,而发行商不一定靠谱。因此,在开发《半条命2》的同时,Valve就开始打造一个叫作Steam的游戏下载和发行平台。
|
||||
|
||||
这个想法在当时是非常先进的,Steam平台就相当于游戏界的iTunes。此系统是BT协议的发明者布拉姆 · 科恩(Bram Cohen)亲自操刀开发设计的,它运用了和BT类似的点对点下载的思想,下载游戏的速度非常快。
|
||||
|
||||
Steam平台问世于2002年,和新版的《反恐精英:零点行动》一同发行,目前已经成为世界上最大的游戏发行和分销平台,无数公司在上面发行和更新各种各样的游戏。Valve公司希望从游戏制作厂商向游戏发行厂商的转型企图,在Steam平台上显现得淋漓尽致。
|
||||
|
||||
更重要的是,Steam的游戏发行方式和传统游戏发行商不同,它允许很多独立的游戏制作商通过互联网方便地发行游戏。而且,它的下载方式又非常先进,下载速度很快。所有的一切,共同造就了Steam系统今天全球最大游戏发行平台的事实。
|
||||
|
||||
Valve公司为了推行Steam平台也是不遗余力。《半条命2》的发行自然成为了推行Steam平台非常重要的举措,Steam平台允许玩家预先下载游戏《半条命2》,然后在发行日就可以直接玩,这让玩家们欢欣鼓舞。当然,游戏好是基本前提,否则自然无法帮助推广Steam平台。
|
||||
|
||||
《半条命2》是如此成功,以至于Valve公司把它移植到了各大游戏主机上。和一年前那个命途多舛的《半条命》泄密版比起来,这无疑彰显了Valve公司非常令人佩服的执行力。
|
||||
|
||||
按照Valve的传统,《半条命2》肯定是要继续走MOD路线的。作为对MOD最为友善的游戏公司之一,Valve在《半条命》上赚的不是一星半点,《半条命2》延续这个套路也是很自然的事。
|
||||
|
||||
眼看着如此成功的《半条命2》,Valve决定做点儿别的事来帮助推广Steam。Valve的第一次尝试是用《半条命2》的引擎做了一个非常简短的续集,称为《半条命2》的第一集。这个续集很短,所以售价很便宜,并通过Steam平台卖出去。
|
||||
|
||||
这个迅速出现的产品,既没有耗费Valve很多时间去开发,又让它延续了《半条命2》的热度,因此在推广Steam的道路上走出了很成功的一步。然而毕竟这个东西比较短,热度很快就过去了。
|
||||
|
||||
为了推广Steam,不遗余力的Valve决定祭出捆绑大旗。我们知道很多公司成名以后都喜欢用捆绑策略,因为这样做成本低,效果好。这次捆绑涉及5个游戏:《半条命2》《半条命2》续集第一集、续集第二集,还有《军团要塞2》,以及解密游戏《传送门》。这次捆绑销售总体来说是成功的,反正新游戏买了也没多花钱,能玩则玩,即使没意思也无伤大雅。
|
||||
|
||||
到2008年的时候,业界在猜测应该是推出《半条命3》的时候,Valve却决定推出一款新的游戏:《求生之路》。而《半条命3》至今依然遥遥无期,不知道是否还有出3的可能。
|
||||
|
||||
《求生之路》这款游戏又实现了一次跨越,它是一个可以联网四人组队的游戏。问题在于,这款游戏会根据玩家以前的表现来调整游戏的难度:简单来说,如果是新手,那么打游戏的时候敌人就会弱一些,而道具则会多一些;如果是高玩,那么对不起,等待你的是地狱模式。
|
||||
|
||||
这种游戏设定是以前没有过的,这让《求生之路》变得非常吸引人,于是全球的玩家们从对《半条命》续集的期盼,迅速转移到了《求生之路》上。可是正当大家都在为《求生之路》痴迷,觉得Valve公司肯定会大量开发资料片和开放MOD的时候,Valve公司却出人意料地宣布,《求生之路2》在一年后就开始开发。
|
||||
|
||||
这一下子就炸锅了。最主要的原因还是花了钱的玩家觉得受骗了,好端端地等待资料片的变成了等待续集,那么多钱买的游戏居然很快就没办法通过资料片继续扩展下去了,而是非要重新花更多的钱买新版。这次的事情闹得非常大,很多玩家宣布,就算《求生之路2》发布了,也绝不购买。
|
||||
|
||||
这场风波愈演愈烈,Valve公司也没什么良策。玩家最终分裂成了《求生之路1》和《求生之路2》两派,我想这是Valve公司始料未及的,而Valve应对这次危机的做法,就是让时间去缓解。慢慢地,《求生之路2》的队伍逐渐壮大,此事也就顺利蒙混过关了。不过,这确实是自《半条命》代码被盗以来,Valve公司经历的最大危机。
|
||||
|
||||
此后几年Valve公司不痛不痒地以一年一个的速度发行了几款游戏,这些游戏当然都多少引起了不少反响,但是和《半条命》比起来,始终都有差距。
|
||||
|
||||
同时Valve公司投入了很多精力去推广它的Steam平台,Steam平台做得是风生水起。Valve公司代表业界给很多小的游戏制作者和个人提供了很好的发行平台,这一点我们还是需要感谢Steam的。
|
||||
|
||||
时间很快过去,一晃又是4年,Valve公司的《半条命3》依然遥遥无期。这个时候一件很重大的事情进入了Valve的视野。这里涉及另外一个非常著名的游戏公司暴雪的一款非常著名的网游《魔兽世界》,和一个在《魔兽世界》里MOD的地图。
|
||||
|
||||
接下来就将是Dota的故事!Dota的出现,让Valve公司接下来几年的工作重心都围绕着它展开,至于《半条命》的续集,早就被抛诸脑后了。
|
||||
|
||||
|
||||
|
||||
|
||||
55
专栏/技术与商业案例解读/058半条命的Dota帝国Valve:Dota2.md
Normal file
55
专栏/技术与商业案例解读/058半条命的Dota帝国Valve:Dota2.md
Normal file
@@ -0,0 +1,55 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
058 半条命的Dota帝国Valve:Dota 2
|
||||
在Steam平台和游戏《半条命》之外,现在大家对于Valve关注度最大的是一款叫作Dota 2的游戏。
|
||||
|
||||
简单来说,Dota 2是由Valve开发的一款免费的多人在线竞技类游戏。基本的玩法是两支队伍各有5位成员,在游戏地图上对抗,每位成员可以从113位英雄里面选择一位作为自己的角色。游戏的最终目的是摧毁对方基地里面的关键建筑:遗迹。
|
||||
|
||||
Dota 2有遍及世界的专业比赛,其中最大的国际邀请赛则由Valve公司举办,每年一度在西雅图的钥匙球体育馆(Key Arena)进行。中国竞技队水平很高,但是传统上逃不过“奇数年输,偶数年赢”的命运。去年是2017年,输了。
|
||||
|
||||
Dota 2比赛的时候,西雅图吸引了无数的Dota迷,可谓一票难求。与此同时,比赛奖金也一直都是千万美元级别的。至于明星战队和明星成员们,在世界各地也是非常有名。美国各类竞技比赛的直播,当然也是让直播平台和相关选手赚到手抽筋。
|
||||
|
||||
在Dota 2比赛的那天,我的朋友圈里面到处都是相关信息。很多程序员要么请假,要么偷跑出去到现场围观比赛。在我办公的地方,那层楼空了一小半,90后全部失踪了。第二天回来他们一脸沮丧的样子,比输球还可怕。
|
||||
|
||||
我一直都觉得,一款游戏是如此火爆,实在是有点让我这样的伪游戏玩家不可思议。当然隔行如隔山,有喜欢打游戏的,有喜欢玩二次元的,有喜欢写文章的。重要的是,你只要知道Dota 2实在异常火爆就是了。
|
||||
|
||||
这款游戏为什么叫Dota 2呢?因为Dota本身并非是Valve开发的。Dota起源于2003年,最初是暴雪公司《魔兽争霸3》里面的一张自定义地图。在《魔兽3》的扩展包《冰封王座》发布以后,类似的自定义地图纷纷涌现出来,并以其独有的特色开始流行。这其中最著名的当属史蒂夫 · 菲克(Steve Feak)制作的Dota全明星地图。
|
||||
|
||||
后来这张地图的制作者菲克和他的朋友史蒂夫 · 梅思康(Steve Mescon)成立了官方的Dota社区,紧接着又成立了 Dota全明星有限责任公司。在2005年的时候,菲克从Dota项目上退了出来。他的另一位好友冰蛙(IceFrog)接替他成为了项目的负责人。
|
||||
|
||||
在2009年的时候,新负责人冰蛙和老创始人梅思康理念不合闹开了。此事最后导致冰蛙离开,并且自己搞了一个新的社区网站。
|
||||
|
||||
冰蛙的离开让Valve里面的Dota粉丝们有了些想法,Dota粉丝和Valve的创始人纽维尔交流之后,决定联系冰蛙。开始可能也只是随意聊聊,但是很快冰蛙就成为了Valve的雇员。Valve公司决定在冰蛙的领导下,使用Valve公司研发的起源引擎,开发一款类似的新游戏,游戏被命名为Dota 2。
|
||||
|
||||
所谓的Dota 2自然是一个类似Dota的全新游戏,但不再是暴雪《魔兽争霸》的定制地图,而是一款独立的游戏,可以不依赖于暴雪公司的《魔兽争霸》独立运行。同时,这款游戏也连接了Valve公司最为著名的Steam游戏平台,将在Steam平台上开放给广大玩家。
|
||||
|
||||
作为一个合格的商人,纽维尔看到了Dota这个名字背后的商机,他立刻注册了Dota的商标。这种行为其实多少是有争议的,因为Dota这个称呼并非Valve最开始使用的。果不其然,此事引发了史蒂夫 · 菲克和史蒂夫 · 梅思康成立的Dota全明星公司和Valve之间的一场官司。
|
||||
|
||||
Dota全明星公司几经转手以后,暴雪获得了授权,代表Dota全明星公司,对Valve的商标权的合法性提起申诉。于是暴雪和Valve这两个游戏界的庞然大物,在2011年就Dota的商标问题打起了官司。
|
||||
|
||||
这场官司前后持续了一年多,最后的裁决总体上有利于Valve,Valve公司得以保留Dota的商标权。但是作为裁决的一部分,第三方也可以使用Dota这个商标,只要不从事营利行为。
|
||||
|
||||
有人觉得这是一年以后Dota 2上线宣布免费玩的原因之一。因为如果说Dota 2自己不是免费玩的话,那么暴雪公司估计分分钟可以搞起一个免费的Dota克隆版来。这样一来Valve公司肯定赚不到好处。当然这也只是坊间传闻,不太可能从Valve公司内获得确认了。
|
||||
|
||||
Dota 2的第一次测试源于2011年的第一届国际Dota邀请赛,之后游戏长期处于Beta状态。等到2013年Dota 2正式发布的时候,游戏早就有超过300万的活跃用户了。根据一个不是最新的统计,如今Dota相关的用户流量,占全球互联网流量的3%。这些年来,Dota 2的游戏上线率一直维持在百万用户级别,一款游戏能够达到如此的高度,堪称游戏发展史上的里程碑。
|
||||
|
||||
Dota 2的基本运营模式非常有意思,就是所谓的免费玩模式。Valve在2012年就宣布了,它们开发的Dota 2将会永久保留免费玩的模式。这个免费玩和我们国内的网游模式并不相同。国内网游很多时候游戏是免费玩的,但是花了钱才可以拿到更强力的装备,所以人民币玩家可以轻松地打败免费玩家。而Valve并不给花钱的玩家提供额外的道具角色,免费玩家和花钱的,在战斗力上没有任何区别。
|
||||
|
||||
Dota 2主要的盈利模式来源于一个叫作Dota商店的东西。在这里,你可以买到游戏中可使用的装饰性道具。更重要的是,这个系统可以让玩家发布自己的创意。玩家创意如果入选,玩家就可以通过这种方式赚钱,这是Valve公司公布的现在Dota 2在线的主要赚钱方式。
|
||||
|
||||
至于以Dota 2衍生出去的世界各地的各种比赛,以及围观比赛所需要购买的在线或者现场的入场券,这些东西的收入则更是可观。一句话总结,虽然说游戏是免费玩的,作为竞技类游戏,Valve公司从来都没少在游戏里面赚到钱。
|
||||
|
||||
由于Valve公司是私人企业,从来不需要对外公布财务信息,因此它到底是通过卖东西赚到了更多的钱,还是通过组织竞技比赛赚到了更多的钱,大家只能猜测一下。
|
||||
|
||||
Dota 2本来是用Valve公司的起源引擎开发的,2015年的时候Valve公司宣布下一代引擎起源2代,这个引擎随即被用来重新开发Dota 2。在Dota 2的发展历史里,因为这次重新开发,导致了用户的大量流失。这是Dota 2有史以来第一次,也是唯一的一次大量客户流失。客户流失历经小半年,才逐渐恢复到起源2引擎改版发布前的水平。
|
||||
|
||||
Dota 2堪称现在Valve公司几年内的重心,而Steam平台由于Dota 2的加入,也让更多的游戏得以展现给更多的玩家。这种相辅相成的发展模式,给Valve公司的未来带来了无限可能,也让Valve公司越发成为一家在游戏界举足轻重的公司。
|
||||
|
||||
亲爱的朋友,你觉得当初Valve公司为什么要介入Dota后续项目的开发?冰蛙又为什么选择了Valve呢?
|
||||
|
||||
|
||||
|
||||
|
||||
49
专栏/技术与商业案例解读/059半条命的Dota帝国Valve:无领导管理.md
Normal file
49
专栏/技术与商业案例解读/059半条命的Dota帝国Valve:无领导管理.md
Normal file
@@ -0,0 +1,49 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
059 半条命的Dota帝国Valve:无领导管理
|
||||
前面我说到了最近几年大红大紫的游戏Dota 2,今天和你一起看看Valve公司在管理和招人上的故事。你会发现,Valve公司在人事方面可能是世界上最有特色的公司之一。
|
||||
|
||||
Valve公司的第一个原则是,公司里面没有任何一个人需要向他人汇报工作。当然这也就意味着公司内没有所谓的CEO、CTO、总裁、副总裁、总监、经理等等职位,员工之间没有上下级关系。在Valve里面,公司是彻底扁平化的。这种扁平化意味着每个人都可以做任何事,也意味着如果你想去问别人你到底要做什么的话,其实没人能给你答案。
|
||||
|
||||
我第一次听到这个公司文化的时候,真的是非常吃惊,因为在任何一个组织里,没有秩序就意味着没有产出。大家都是平级的,也就是大家都不需要负责人。Valve公司的新员工手册上写到:我们不需要任何人管,谁也不需要向谁汇报。
|
||||
|
||||
要去Valve公司参观并不难,如果你是个Dota 2的粉丝,报上你的账号,就可以预约。不过作为一个伪游戏迷,我就没有这份幸运了。但是我有幸听参观过的朋友说起,这个公司的开发环境非常奇特,也可以说非常得“奇葩”。
|
||||
|
||||
一个员工被招进来以后,他也不知道要干什么,别人也不会告诉他要做什么。Valve的办公桌下面有滑轮,所以员工可以把自己的桌子随便移动到一个项目组里去,听听别人聊天。聊出兴趣来以后,就进那个组里工作了。
|
||||
|
||||
基本上可以说,在Valve里面每个人想要干什么,兴趣最重要。员工可以加入他们认为自己最感兴趣最喜欢的组里去。有些员工非常厉害,可以在若干个组之间穿梭,有些员工则有办法拉起一波人开启新项目。从这一点来看,Valve招的都是那些主动意愿非常强的人。
|
||||
|
||||
这当然不是什么坏事情,但一定程度上或许也可以解释为什么Valve的游戏经常跳票。不管是为了质量还是为了创意,跳票可能都是Valve的文化里不可或缺的一部分。不然的话,员工的主观能动性没有发挥好,可能就做不出高质量的产品了。
|
||||
|
||||
但是我们知道,任何软件的开发,都有很多很有挑战的活,也有很多非常无趣的事情。Valve是怎么做到在让每个人都能发挥自己兴趣的同时,又确保那些脏活累活都有人妥妥地干掉呢?
|
||||
|
||||
Valve更有意思的是招人不拘一格。Valve公司招人的标准,很多时候是不确定的,似乎不管什么样的人才,只要有意义有特色,都可能被招。比如说我们打开Valve的网站看一看,迈克 · 安宾德(Mike Ambinder)这位老兄位列员工表第一位。他是计算机和心理学双学士、心理学博士。他在自我介绍中表示,自己在公司内的职责很模糊,但大体上是把心理学的知识和方法论运用到游戏里。
|
||||
|
||||
我突然之间就能理解了,为什么网上对Vavle的游戏评价总是“特别的引人入胜”“挑战人的极限却不过”,想来这与公司里有个心理学博士天天琢磨什么样的游戏才符合人的心理,一定是不无关系。
|
||||
|
||||
比如说莱斯利 · 里德(Leslie Redd)这位Vavle的前员工,如今的创业公司CEO。在加入Valve之前,她是某高中的管理员,因为使用了Valve游戏传送门来给学生上物理课,而被Valve的创始人相中加入了Valve。这算得上是非常得不拘一格招人了。
|
||||
|
||||
有关Valve公司用人最不拘一格的事情,莫过于雅典大学经济学教授亚尼斯 · 瓦鲁法基斯(Yanis Varoufakis)一篇博文里的故事了。亚尼斯是欧洲著名的经济学家,经常在网上写一些博文,分析欧洲经济形势、希腊经济危机等。
|
||||
|
||||
按照他自己的说法,某天他突然收到了一封信。通常情况下他收到的信太多,这种类似垃圾邮件的信都是直接删了不读的,但是那天却鬼使神差地读了起来。写信的人自称是一家叫作Valve的公司的President。由此看来,创始人在和外面联系时还是需要一个名称的:Valve虽然没有CEO,但是却有个President。
|
||||
|
||||
这位President,也就是Valve的创始人加布 · 纽维尔(Gabe Newell),在邮件里他大大夸赞了亚尼斯一把,然后表示要邀请他来西雅图访问Valve,顺便探讨一下在游戏这样的虚拟世界里面,经济学的规律是如何运作的。亚尼斯就这样跑到了西雅图,经过一番交谈,他决定通过兼职方式加入Valve,作为他们的驻站经济学家。
|
||||
|
||||
亚尼斯之所以对这份工作感兴趣,按照他自己的说法是,在虚拟世界里每一笔交易和行为都有详细的记录。从经济学的角度来说,虚拟社区的数据详尽,一点儿不差,任何分析都可以基于完整的数据做出来。
|
||||
|
||||
与之相反,现实中我们的经济行为不可能被完整记录下来。所以现实世界里面的经济学研究需要利用大量的统计学知识,做很多的假设。这样一来,对于现实世界的经济学研究难免做不到精确。而虚拟世界的这个优势,可以让经济学研究完全抛弃传统的基于统计的方式,使用绝对准确而完整的数据,做出传统经济学上完全无法做到的分析和研究。
|
||||
|
||||
当然,对于Valve公司来说,请一个经济学家来提供咨询,对于他们如何在数字世界里面赚钱,肯定是非常有意义的。然而我必须说,这种读了别人的博文以后就打算请人来面谈,面谈完了就让人来做自己员工的做法,除了Valve,我还没有听说过第二个公司。
|
||||
|
||||
以上都是这家公司好的一面,但是Valve其实也面临员工离职的问题。离职的原因大都指向了一件事情,就是创始人纽维尔既不愿意把公司卖掉,也不愿意上市。这样一来,那些指望着公司上市以后期权可以大量盈利套现的员工,自然会在等待中慢慢失望,直至离开公司。
|
||||
|
||||
Valve最初成立依赖的就是创始人自己的钱财投入,此后也从未向资本市场募集过一分钱。而且Valve公司盈利好,不缺钱。这样一来资本市场想要从Valve公司分一杯羹就比较难了。但是在Valve公司漫长的发展历史上,一直不缺想收购Valve的公司,收购价从最初的几千万美元,到近期报价10亿美元,收购价可谓诚意满满。然而纽维尔接受其他人采访时,态度非常明确,在他有生之年多半是不会改变这个念头了。
|
||||
|
||||
那么亲爱的朋友,你是不是愿意去一家没有老板,干活凭兴趣,招人看缘分,但是却永远上不了市的公司工作呢?
|
||||
|
||||
|
||||
|
||||
|
||||
53
专栏/技术与商业案例解读/060半条命的Dota帝国Valve:虚拟现实.md
Normal file
53
专栏/技术与商业案例解读/060半条命的Dota帝国Valve:虚拟现实.md
Normal file
@@ -0,0 +1,53 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
060 半条命的Dota帝国Valve:虚拟现实
|
||||
Pic Author:CULLEN STEBER
|
||||
|
||||
Valve公司其实还是一家以“创新”著称的公司。早年在《半条命》里面的创新主要在于游戏情节,但后来将Steam作为游戏分发平台打造,其开始时间比iTunes还要早。
|
||||
|
||||
最近这段时间,有两条消息值得你我注意。其中最为轰动的是苹果公司总裁蒂姆 · 库克(Tim Cook)访问了Valve,没有人知道两者达成了什么协议,但据我猜测,可能和硬件设备有关。而我们应该知道,Valve关注硬件领域的事情由来已久,库克的访问或许会让人感觉好奇,但不见得令人惊讶。我们只需要拭目以待,相信很快可以看到接下来会发生什么。
|
||||
|
||||
另外一则消息是:HTC把自己手机制造业务员工的一半,大约2000人“卖”给了谷歌。这个举动可以让谷歌获得手机制造能力,而HTC则可以集中精力去做虚拟现实硬件。HTC的这个举动同样不是让人特别吃惊,它早年以手机制造起家,然而这些年来手机业务却一年不如一年,市场占有率在任何一个国家都早已不在前三之列。相反,这些年里HTC在虚拟现实设备的世界里却是风生水起。一款叫作Vive的设备,为HTC带来了极高的声誉和大量的金钱。
|
||||
|
||||
这个名字叫作Vive的东西,正是Valve和HTC合作的产物。HTC在很大程度上是把自己的未来赌在了虚拟现实上,而Valve公司在游戏上的成功,为HTC的豪赌备好了很多必要条件。两者相结合,未来很可能会创造出一条一般人难以想象的大道。
|
||||
|
||||
Valve进入虚拟现实的时间同样很早,2012年就已经开发出一款头戴式显示器。但问题是Valve毕竟不是硬件公司,其技术积累有限,做出来的东西笨重,不适合玩家使用,不过作为开发虚拟现实游戏的实验设备是绰绰有余了。Valve里面的一个团队就在拿着这台原型机乐此不疲地开发游戏。
|
||||
|
||||
与此同时,Oculus的创始人帕尔默 · 洛基(Palmer Luckey)发起众筹开发著名的Oculus Rift,一款为电子游戏设计的头戴式显示器(即“头显”)。Valve自己的研发过程非常不顺利,但是Oculus的存在让他们看到了希望。于是2014年1月份双方宣布合作,共同推进虚拟现实技术的发展。
|
||||
|
||||
当时帕尔默对Vavle已经掌握的虚拟现实技术非常欣赏,认为这是世界上最牛的虚拟现实技术之一。此话是不是有夸张或者广告的成分,我们就不得而知了。
|
||||
|
||||
“花开两朵,各表一枝”,此时决定跨界尝试做虚拟现实设备的手机制造商HTC,在增强现实和虚拟现实之间游走了一段时间后,最终决定集中精力做虚拟现实。
|
||||
|
||||
但是很遗憾,手机市场的老对手三星已经发布了基于三星手机的虚拟现实附件,这让HTC对于自己的未来到底应该怎么走很是困惑。左思右想之余,他们决定脱离手机做一套完整而独立的虚拟现实设备,瞄准的正是Oculus的市场,决定趁早抢占高端市场,而不是像三星那样做手机的附件。也许正是因为这个原因,HTC的手机业务衰弱了。
|
||||
|
||||
非常戏剧性的是,1月份还在和Oculus相谈甚欢的Valve,到了同年3月份就开始和HTC勾搭,而被Facebook买下的Oculus不再提Valve有多牛了。据大家猜测,是Facebook对Oculus的这次收购让Valve和Oculus的合作出了问题。但无论如何,最牛的游戏公司Valve的虚拟现实梦因此变得崎岖起来。
|
||||
|
||||
俗话说“山不转水转”,一家不行还有另外一家。HTC和Valve合作的东西,就是后来非常有名的VR头显Vive。有些游戏开发厂商拿到了早期的原型机,据说Vive的最初版本颇有Vavle自己2012年做的那个头显的模样。但是做硬件的HTC加入以后,Vive不断改进和迭代,渐渐变得小巧而实用起来,慢慢成了今天我们看到的样子。
|
||||
|
||||
Vive的最初研发,保密工作做得非常好。这个项目后面涉及很多公司,其中有一些是开发应用和游戏的,还有一些是提供各种硬件的,但是自始至终都没有泄露太多信息。
|
||||
|
||||
之所以如此保密,我想一方面可能是敬畏于被Facebook收购以后Oculus背后强大的技术和资金支持,很多参与这个项目的公司觉得得罪不起。另外一方面,这些参与的公司,尤其是游戏公司,多半是脚踩两只船,准备自己的游戏同时登陆Vive和Oculus平台。对外保密也有助于他们和Oculus的合作或潜在合作不受影响。不管怎么说,种种原因都让这个项目非常低调,一点儿不符合HTC的传统。
|
||||
|
||||
Vive的亮相始于2015年的世界移动通信大会,这次发布会非常成功。两周以后,Vive又在游戏开发者大会上进行了展示。无论是哪场发布会,这个突如其来的虚拟现实产品,都惊艳全场。很多人都没有想到,在Oculus之外,会有一个做手机的厂商,和一个做游戏的厂商,一起合作利用这个虚拟现实的硬件设备上杀入市场。
|
||||
|
||||
Valve游戏背书,HTC硬件制造,让这款产品在2015年达到了相当的高度。在市面上,Oculus的设备是标杆,而Vive在很大程度上可以媲美Oculus的设备。加上Vive的定位就是高端设备,相对低廉的价格,而成本也是HTC等很多中国台湾企业比美国企业更擅长做的事情。所有情况加在一起,Vive注定将是一款非常畅销的产品。
|
||||
|
||||
到了2016年,Vive正式发布了消费者版本,且消费版和展示版变化不大。这个版本不仅价格低廉,和Oculus的设备售价比起来简直是良心价白菜价,而且有着良好的性能表现,因此深受用户欢迎。
|
||||
|
||||
但是在那一年,有一些游戏是Oculus上独家的,这让买了Vive的人很不开心。我们知道玩游戏的人,很多也都是黑客高手。于是在“宝宝不开心宝宝有情绪”的情况下,某个黑客高手把Oculus的限制给黑了。
|
||||
|
||||
事实证明,黑掉以后,便宜很多的Vive照样可以玩那些游戏,Oculus毕竟还是太贵了。此事后来也是闹得沸沸扬扬,Oculus推出了反破解手段,但是又再次被破解掉,如此循环往复。不管怎么样,这从侧面证明了价廉物美的Vive的确是市场上非常好的VR设备。
|
||||
|
||||
作为2016年以来市场上性价比最高的VR设备,Vive的出现给Vavle和HTC都赢得了大量的赞誉。Vive又再接再厉地迎来了新一代产品Vive Pre。新版本调整了很多硬件上的位置,也减重不少。
|
||||
|
||||
时至今日,Vive已经是新一代虚拟现实产品里面的佼佼者。所以HTC有信心离开自己不赚钱的手机业务,全力以赴做虚拟现实市场了。
|
||||
|
||||
亲爱的朋友,你怎么看待Valve跨界进入虚拟现实设备的研发,以及选择和HTC的合作呢?你对Vive的市场和前途又有什么看法?欢迎留言和我探讨。
|
||||
|
||||
|
||||
|
||||
|
||||
71
专栏/技术与商业案例解读/061GabeNewell:Valve帝国制度的利弊.md
Normal file
71
专栏/技术与商业案例解读/061GabeNewell:Valve帝国制度的利弊.md
Normal file
@@ -0,0 +1,71 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
061 Gabe Newell:Valve帝国制度的利弊
|
||||
Valve是一家极具特色的游戏公司。Valve有非常卖座的游戏,有被誉为游戏界iTunes的游戏发行平台Steam,有人气爆棚的联网游戏Dota 2,还有代表着未来的虚拟现实技术。在整个电子游戏界,你真的很难再找出第二家这样面面俱到,又每个方面都做得出彩的公司。
|
||||
|
||||
Valve又是一个在组织架构上独具一格的公司。在Valve,大家都是平等的。虽然现实通常像小说《动物庄园》里著名的谚语那样,“有些人比另外一些人更平等”,但是最起码Valve在的组织架构上,没有谁向谁汇报的关系,大家一起对公司负责。
|
||||
|
||||
Valve公司在招人上同样是不拘一格,所招之人往往具有鲜明特色、有主见、能力强,每个人多少都有独当一面的能力。
|
||||
|
||||
而且,Valve是一家持续盈利的私人公司。自从另外一个创始人退出以后,现在的大股东就一个人:创始人加布 · 纽维尔(Gabe Newell)。
|
||||
|
||||
在我看来,这家公司不可复制。它的制度,它的运作方式,它的招人方式,都是只有在特定情况下才能诞生的,并不具有普遍性。因此,把它当作一个案例来研究会很吸引人,但如果学习它的经验,希望运用到其他公司里面去,就很难说会是一个什么样的结果了。
|
||||
|
||||
Valve公司的优点,前面已经说过,这里我简单总结一下。
|
||||
|
||||
|
||||
这家公司的每个人都有很强的战斗力,能够独当一面,所以公司整体实力很强。
|
||||
公司有很民主的氛围,也鼓励大家别具一格地去创新,所以公司的产品非常耀眼。
|
||||
公司的创始人很有大局观,能审时度势。无论早年做Steam平台还是后来做Dota 2,又或者是进军虚拟现实,都是在恰当的时候做了恰当的事情的典范。
|
||||
Valve公司没有上下级关系,这也在很大程度上避免了政治斗争的内耗。
|
||||
Valve公司创立之初创始人就不缺钱,现在整个公司都不差钱,一直都不需要引进任何投资。因此,Valve公司受资本市场的操控和影响非常小,能够独立做很多的事情。
|
||||
|
||||
|
||||
Valve的缺点同样非常的明显,而且也同样的不可复制。这也可以从几个方面来看。
|
||||
|
||||
第一个方面,公司的层级汇报制度几乎是现在大小公司的基石,因为我们都知道明确责任和权力在公司管理上非常重要,通常即便是非常小的创业公司,也离不开组织架构上的层级关系。让所有人自由发挥做所有的事情,这种方式一实施,一万个公司里面可能最多存活一个公司,那还是烧高香了。
|
||||
|
||||
这套制度在Valve里面能够实施,首先得益于全体员工对公司创始人纽维尔的认可,即便公司里产生了矛盾,也可由他进行协调。不会产生矛盾的组织是不存在的,但纽维尔的个人威信足以平衡这种矛盾。
|
||||
|
||||
其次是Valve公司财大气粗,但是公司员工却不多。而且员工各个有主见有能力。这样一来,Valve公司有很多钱可以给员工们很大的自由空间去发挥,哪怕搞砸了一些事情,也就当经验去学习了。
|
||||
|
||||
再次是Valve公司从来没有打算扩大公司规模。Valve只打算在自己擅长的几个领域里面深耕细作,而不是进军新领域,把公司扩张到更大的规模。这是纽维尔可以保证不需要层级和汇报关系的基础。试想一下,一个公司如果大到几千人、几万人,还可以没有任何层级和汇报关系的话,会是怎样一番景象。
|
||||
|
||||
如果后来者要学习Valve,保持公司内的每个人都是平等的,没有层级没有汇报关系,又有没有可能呢?这家公司至少需要具备这样一些要素:
|
||||
|
||||
|
||||
一个能摆平大家,又很有战略眼光的创始人;
|
||||
一群数目不多,但是各个都自主能干的员工;
|
||||
很多很多的钱;
|
||||
公司并不打算大规模的扩张,愿意数十年如一日地维持公司员工规模。
|
||||
|
||||
|
||||
我想这些条件对于几乎任何一家公司都要求太高了。Valve公司成长到今天,变成这个样子,肯定有其必然性也有偶然性。但是不管怎么样,这是非常难复制的。无论是创业者还是企业管理者,看看热闹就好,切记不要邯郸学步。
|
||||
|
||||
第二个方面,这家公司对待资本的态度,它从创业之初开始至今都没有引入资本的力量,所以Valve很大程度上都是属于纽维尔一个人的公司。这个特点也决定了纽维尔可以在公司里面一言九鼎,从而有效地帮助他“摆平”公司内的所有员工。
|
||||
|
||||
但是完全不引入资本,需要几个前提条件。
|
||||
|
||||
|
||||
首先,在创业的阶段,创业者自己就很有钱。如果缺钱的话,公司在某些发展阶段总归是需要引入投资才能撑下去的。
|
||||
其次,这家公司在创业的最初期,就可以大规模盈利,而不是说需要持续烧钱。
|
||||
|
||||
|
||||
那么我们试想一下,互联网行业发展了这么久,到今天又有多少个企业家出来创业就不怕烧钱的呢?又有什么产业公司一创业就开始大把盈利的呢?Valve的创始人从微软公司上市攫取了第一桶金,之后又进入个人计算机游戏这个当时可以迅速大把盈利的产业。这些先决条件造就了今天它独具特色的状态。而我们目前新创业的公司,显然内部外部条件都不一定具备了。
|
||||
|
||||
|
||||
再次,这家公司的股权制度涉及对员工是否公平的问题。这也很难让创业公司去复制,很多人加入创业公司会是因为创业公司的股权,如果公司成功上市了,可以给自己带来大量的财富。但是在Valve公司现在这个状态下,基本上就是纽维尔一个人的公司。公司员工是不持股的。因为就算是持股,反正公司也不会卖掉或者上市,公司员工手里的股票也没有变现的空间。
|
||||
|
||||
|
||||
这就涉及到底对员工是不是公平的问题了。在Valve公司里工作的人,当然各个都是能手。我相信他们的薪水也不低,但是这个公司里的员工要想财富自由,同样比较困难。因为公司股票不上市,财富也就不会爆炸式增长。这对纽维尔其实影响不大,但是对公司的员工,影响就不小了。
|
||||
|
||||
从这个角度讲,其他企业是不敢这样做的,一个永不上市的企业,尤其在其初创阶段,对当今市面上优秀的人才来说,吸引力并不是很大。
|
||||
|
||||
总结一下,我觉得Valve公司本身非常有特色,而纽维尔作为公司创始人和实际掌控者,展现了高度的大局观和管理能力。但是Valve公司的这套独具特色的制度,对于大家来说,唯一的作用可能就是分析研究,因为并不具备普适性,其他公司其他人学不来也没必要学。如果一定要学的话,反而可能造成邯郸学步的结果。
|
||||
|
||||
|
||||
|
||||
|
||||
107
专栏/技术与商业案例解读/062文档数据库的缔造者MongoDB(上).md
Normal file
107
专栏/技术与商业案例解读/062文档数据库的缔造者MongoDB(上).md
Normal file
@@ -0,0 +1,107 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
062 文档数据库的缔造者MongoDB(上)
|
||||
大数据和云计算的风被谷歌吹起来的时候,被谷歌收购的网络广告公司DoubleClick的原CEO和CTO们觉得自己应该蹭上时代的列车,再次创业,然后10gen公司就这样在纽约诞生了。它的创始人分别是DoubleClick的创始人兼CTO德怀特 · 梅里曼(Dwight Merriman)、CEO凯文 · 瑞安(Kevin Ryan),以及工程师埃利特 · 霍洛威兹(Eliot Horowitz)。
|
||||
|
||||
公司成立之初,创始人的想法和MongoDB这个产品毫无关系:他们想做一个云计算的服务,并用开源的东西来搭建。然而很遗憾,这几位二次创业的人在开源社区找了一圈,也没有看到一个让人满意的东西。于是,怀着构建伟大云计算服务的梦想,他们决定先把这个事情停一停,先搭一个自己满意的数据库出来。这个数据库就是后来赫赫有名的MongoDB。
|
||||
|
||||
MongoDB的名字需要解释一下。国内很多人觉得是“芒果数据库”,其实不是的。在英文里,“芒果”是Mango,而Mongo是humongous的中间部分,在英文里是“巨大无比”的意思。所以MongoDB可以翻译成“巨大无比的数据库”,更优雅的叫法是“海量数据库”。
|
||||
|
||||
这几位创始人的梦想就是创建一个和过去关系数据库完全不一样的数据库,使之具有这样一些特点:海量数据库、数据库的模型极其灵活、适合程序员使用。
|
||||
|
||||
大概怀着伟大理想的人都会做出伟大的产品。MongoDB注定是独特的,在历史上会留下浓重一笔的产品。
|
||||
|
||||
当MongoDB开发出来的时候,创始人们给它的定义是:这是一个面向集合的、模式自由的文档型数据库。听到这里,你可能觉得有点晕了,那就先普及一下数据库的基本常识吧。
|
||||
|
||||
在过去的30多年里,整个工业界的数据库被所谓的关系数据库所主导。一个不太严谨的说法是:关系数据库的基本存储单元是表。而一张表则是有行有列的数据集合,而列的定义有严格的类型。所以关系数据库是一个严格定义的数据模型,每张表里的每条记录都是一个样的。
|
||||
|
||||
查询关系数据库的标准语言叫作SQL。SQL这个东西自从IBM发明出来以后,已经有30多年的历史了,人们爱它的有,恨它的也有。但是通常来说,程序员不太喜欢这个东西,因为它的基本理念和程序员编程的想法不一致。后来所谓的NoSQL风,指的就是那些不用SQL作为查询语言的数据存储系统,而文档数据库MongoDB正是NoSQL的代表。
|
||||
|
||||
和关系数据库相反,MongoDB的数据模型很不一样。简单来说,MongoDB面向的是集合而不是表,所有的数据存储都以集合为单位,而每个集合里面包含的东西则称为文档,一个集合可以包含无数个文档。每个文档,我们可以大致认为是个JSON数据模型。文档自带元数据。也就是说,MongoDB里面每个集合的每个文档并不要求数据严格一致,而是可能千差万别。
|
||||
|
||||
MongoDB还有一个特色,它的查询使用的不是SQL,而是程序语言和API。这样一来,MongoDB对程序员就是一个非常友善的选择。当然,对于原本非常熟悉SQL的DBA和数据分析人员,这就显得不太友好了。
|
||||
|
||||
MongoDB这个数据模型其实是非常脑洞大开的。在数据库领域的几十年发展里,很多人都试过各种各样挑战关系数据库的模型,但是鲜有成功的。即使成功了,也往往让人感觉雷声大雨点小,并不会对关系数据库的根本造成实质性的影响。然而MongoDB这个东西一出现,对有经验的数据库从业人员和使用者来说,第一个感觉就是这个东西是来搞事情的。
|
||||
|
||||
在开发MongoDB的过程中,随着开发的深入,10gen的人越来越觉得原来那个云计算平台是个虚无缥缈的东西。而这个他们一手缔造的文档数据库,可能是一个惊天动地的大杀器!虽然这些人其实不是数据库领域科班出身的,但他们对于数据库领域某些弊端的深刻理解,的确是一般人望尘莫及的。
|
||||
|
||||
于是他们决定彻底忘记那个云计算平台,集中精力开发这个被命名为“巨大无比的数据库”的产品。在漫长的开发过后,2009年2月10gen正式开源了MongoDB的第一个版本。这对于10gen来说是一个非常重要的里程碑。
|
||||
|
||||
然而我们必须要说,这个产品尽管看起来很新颖很有意思,但并不是一个很成熟的产品。它有无数多的东西没实现,有无数多的坑等着人们去踩。但是这些都已经不重要了,踩着NoSQL的东风,MongoDB开始飞起来了。
|
||||
|
||||
10gen是一家特别注重宣传的公司,它在早期就对如何花钱做宣传非常有一套。他们的做法是在全球各地资助成立很多的用户组,并组织每年一次的MongoDB大会。MongoDB还开起了Mongo大学。他们知道自己产品的用户都是开发人员,因此只要开发人员说好,尤其是各个地区那些在圈内有名的技术大牛说好,那么不管这个产品实际上好不好,完善不完善,炒起来的感觉起码很好。
|
||||
|
||||
先把大家都绑上Mongo的船,再慢慢地修理这艘船也是一种做法。俗话说“吃人的嘴短,拿人的手软”,那些在10gen支持下成长起来的用户组,那些10gen给报销机票和旅馆来做宣讲的大牛们,互利互惠地就借着NoSQL的东风把MongoDB给“吹”起来了。
|
||||
|
||||
10gen的CTO在某次采访中就说,他觉得与其花费那么多钱去做各种各样的广告,不如把钱花在资助用户组,资助MongoDB的会议上。让大家感觉到MongoDB产品好,公司对社区的支持力度大,是10gen花广告费的最佳途径。
|
||||
|
||||
踏上MongoDB“贼船”的公司很多,比如说卖车的Edmunds、美国版的“五八同城”Craigslist,以及老牌网络企业——思科。但是这些都比不上当年非常优秀的社交初创公司独角兽FourSquare使用MongoDB的影响来的大。当然这家公司现在是过气了,但在社交网络最为火爆的时候,FourSquare可是非常著名的。
|
||||
|
||||
在MongoDB刚出来的时候,FourSquare整个地“搬家”去用MongoDB,这曾是一件非常大的事情。这件事情当然被10gen公司大书特书地进行宣传。而MongoDB在独角兽里面被广泛使用这一事实,让MongDB是新时代的数据库、MongoDB适合开发APP,以及MongoDB适合创业公司使用等等的观点,都瞬间被“吹”了起来。
|
||||
|
||||
到2012年的时候,作为10gen公司创始人之一的梅里曼,其与人联合运营的科技博客Business Insider把MongoDB作为仅次于HTML的新时代最重要的技能宣传给大家。一时间仿佛只要MongoDB掌握好了,就能够有一碗饭吃。而很多在线教育网站也专门开起课来,给那些急于从其他职业转战IT的人普及MongoDB的用法。
|
||||
|
||||
我们必须说,这种宣传非常成功。大概是因为MongoDB的创业者在这之前已经成功创业一次,要知道DoubleClick在网络广告领域非常成功,而且被成功卖给了谷歌,所以这些人搞创业公司的套路,一点都不像那些毫无经验的初创公司创始人。他们非常懂得如何做才能够最大限度地吸引眼球,最大程度地把自己的产品铺出去。至于盈利与否,在初创阶段,并不是他们最需要关心的问题。无论从何种角度去看,这个做法都很成功。
|
||||
|
||||
除了在商业宣传上很成功,10gen发布MongoDB以后,在产品的开发和维护上也采取了和其他公司很不一样的策略。这个策略对于MongoDB的流行同样功不可没。
|
||||
|
||||
简单一点来说,10gen公司决定集中精力做最重要的几件事情:
|
||||
|
||||
|
||||
吸引客户上MongoDB的船;
|
||||
让MongoDB更好用;
|
||||
对常用的编程语言,提供各种各样的库和接口的支持;
|
||||
整个技术支持团队非常地友善,而且尽职尽责。
|
||||
|
||||
|
||||
10gen公司重点去做的这些事情,有很多值得我们深思的地方。如果要简单概括的话,就是10gen公司希望所有使用MongoDB的用户都觉得这个产品非常非常地好用。如果万一真的出了问题,也有很好的技术支持来及时地解决问题。
|
||||
|
||||
这种用户体验,绝对是开源社区中其他产品所不能达到的高度。举个简单的例子,要想自己去部署Hadoop的一个计算集群,那绝对是一件老难老难的事情了。如果这个东西容易部署,也就不会诞生一批以卖“更好用的Hadoop”为生的公司了。再举个例子,Hive的部署也同样不好用。
|
||||
|
||||
如果我们从企业级应用上来看,Oracle就是一个非常典型的难用的产品。一个企业如果想要把Oracle用好了,请有经验的DBA是基本条件,很多时候都需要咨询公司来帮助设计解决方案。这种项目的落地绝非简简单单就能行的。而SQL Server作为一个后起之秀,在数据库市场获得成功的一个重要原因,并非性能有多好,而是“很好用”。当然,SQL Server只是和Oracle比起来好用得多。
|
||||
|
||||
但是MongoDB就不一样了,10gen公司的目标就是让MongoDB非常非常地好用。而且从这一点上说,他们做得非常成功。整个社区里无数的用户组在提供支持,10gen自己的客服绝对是用户至上,有问必答,而且非常礼貌及时。整个10gen的开发重点,也是让用户更好上手。
|
||||
|
||||
所有的因素加起来,MongoDB对于创业公司来说就变得很有意思了:这个产品很好上手,支持也很多,而且还免费。创业公司拿着这个轮子,可以迅速实现自己的业务逻辑,而不需要再去学习怎么搭东西。我想正是这个原因,突然之间就着NoSQL的春风,MongoDB就开始流行起来了。
|
||||
|
||||
然而,接下来事情的发展,多少有些脱离美好的一面。MongoDB从产品的角度来说,其实就是个半成品。MongoDB实在有太多的东西没有做了,尤其是那些基本的东西,包括数据是不是会丢、结果是不是错的、并发做得好不好、支不支持事务处理,以及当规模上来的时候,能不能够通过加机器来解决问题。
|
||||
|
||||
这些看起来本应是一个数据库产品非常重要的、基本的东西,MongoDB做得却很差。一般来说,当一个人开始用MongoDB的时候,并不会遇到这样的问题,当然主要还是规模不够大,不至于触发瓶颈和问题。当APP或者网站的规模上去之后,同时工作的人多了,问题就会越来越常见,越来越令人无法忍受。
|
||||
|
||||
而10gen的CEO在宣传时,又往往以极其夸大的方式,告诉大家MongoDB就是未来,MongoDB就是一切。这样的结果就是:很多人用MongoDB去取代关系数据库。然而渐渐地,这些人发现这种取代并没有带来真正的好处,除了一开始开发省了点力气外,后面要维护的成本越来越高。
|
||||
|
||||
而10gen这种侧重于提高用户初始体验,外加一切都是MongoDB的宣传方式,终于导致了负面作用。有经验的程序员开始跳出来,在各种论坛里公开宣称千万别上MongoDB的“贼船”,因为虽然开船的时候容易,接下来要付出的代价也很大,一旦规模上来,各种丢数据的问题就都出来了。
|
||||
|
||||
10gen的CTO经常亲自上阵去和这些程序员们PK。他接受采访的时候说,MongoDB是个新产品嘛,新产品总是会有这样那样的问题,请给我们一些时间。他在论坛上和这些程序员交流,通常来说跳不出这样一些套路,就是:
|
||||
|
||||
|
||||
这个问题我们在下一版里会修好的;
|
||||
这个问题我从来没有遇到过,估计是假的吧;
|
||||
这个问题你给我们开BUG啊;
|
||||
这个问题我不相信是真的,肯定是你们程序写错了。
|
||||
|
||||
|
||||
不管你信不信,这种回复,加上10gen的公关能力,确实在很多时候给MongoDB赢得了修复问题的时间。但是这样的一种方式也让用户的接受度在降低。2009到2012的三年里,MongoDB被接受的比例一直处于飞升状态,而2012年开始这个曲线就越来越平。大家到底要不要用MongoDB,已经不再是“无脑”上的问题,而是要反复斟酌之后再做决定的事情。
|
||||
|
||||
尽管10gen的CEO一直高调宣布MongoDB无所不能,大家赶紧上,实际上后面的几年里,很多人反而是渐渐地离开了MongoDB。大家意识到,MongoDB作为一个一开始上手很快的东西,可能只适合一个V1产品。产品上一点规模之后,背后的数据存储系统还是要换的。
|
||||
|
||||
当然,任何公司都有盈利的压力。MongoDB作为一个开源、免费的产品,10gen公司不可能免费赚吆喝,它烧在社区建设上的钱也不是小数目。10gen推出盈利产品的第一步,是推出了对MongoDB的商业付费技术支持。
|
||||
|
||||
商业付费支持是很多公司常用的方式。比如说Hadoop平台公司的Hortonworks,其收入就基本上依赖于其提供的商业付费技术支持。MongoDB从这里开始赚第一笔钱,并且其技术支持以“态度好”而著称。
|
||||
|
||||
仅仅靠商业技术支持并不能为公司带来足够的收入,10gen的另外一个创收途径是推出商业版的MongoDB。和开源的MongoDB比起来,商业版的自然要带更多的功能。这些功能最主要的是一个加密的存储引擎——数据以企业级密码强度加密后再存储,以及额外的安全相关的功能,比如说LDAP和Kerberos的支持,等等。这方面倒是体现了企业级应用市场和开源小创业公司之间的差异:企业级应用市场对加密和安全相关的内容要重视得多,没有这些功能大企业是不会使用这些产品的。
|
||||
|
||||
在很长时间里,MongoDB的企业版都是10gen公司最主要的收入来源。此外,10gen也提供云上的托管服务,给那些不愿意自己管理数据库的人提供服务。MongoDB的业务模式和赚钱模式都还是很清晰的,但是一个巨大的问题在突显:MongoDB作为一个数据库,始终都不是一个成熟的产品,并因此给很多采用MongoDB的企业带来了一些出乎意料的东西。
|
||||
|
||||
2013年的时候,10gen公司觉得自己的名字已经不太符合现在的品牌效应了,于是正式更名为MongoDB公司,将产品名和公司名匹配起来。
|
||||
|
||||
尽管MongoDB的发展经历了很多曲折,它的产品在功能上、性能上有很多问题,乃至受到了某些程序员的公开抵制;尽管MongoDB的接受度自2012年以来开始大幅度降低,它在企业市场上却依然保持着一个非常可观的占有率。
|
||||
|
||||
今天,我详细讲了10gen在MongoDB的开发、推广、发展和营收上的策略。MongoDB侧重于易用性和对社区的支持,对其他方面则有些忽视了。那么,倘若你在运营一家做工具类产品的初创公司,在技术发展上又会采取什么样的策略呢?
|
||||
|
||||
|
||||
|
||||
|
||||
55
专栏/技术与商业案例解读/063文档数据库的缔造者MongoDB(下).md
Normal file
55
专栏/技术与商业案例解读/063文档数据库的缔造者MongoDB(下).md
Normal file
@@ -0,0 +1,55 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
063 文档数据库的缔造者MongoDB(下)
|
||||
鉴于10gen公司改名叫MongoDB了,这篇文章里我们统一称为MongoDB公司。上回说到MongoDB公司的发展策略是尽善尽美地提供良好的使用体验,而对于产品功能本身,则是哪怕不成熟也先推出来再说。这种策略的好处是让这个数据库很快地流行开来,坏处是用户用久了各种问题层出不穷,苦不堪言,用户甚至跳出来公开说“不要用MongoDB”。
|
||||
|
||||
MongoDB作为一个不成熟的产品,在2016年的时候终于曝出了一个非常严重的事件:MongoDB的安全门事件。任何一个国家的任何一个计算机产品,如果出现了安全相关的事件,对产品的影响都可能是致命的。
|
||||
|
||||
这个事件是安全界大牛维克托 · 格弗斯(Victor Gevers)在2016年底发现的,并于2017年初开始广为人知。做这个事情的黑客组织(HaRak1r1)把MongoDB的数据给删除了,然后留下一个叫作WARNING的数据库,里面的主要内容是说:给我们送0.2比特币到某个收费的地址,然后给我们发邮件([email protected])告诉我们你的IP地址,这样你就能够把丢失的数据拿回来。
|
||||
|
||||
大概是这个事情被到处报道,闹得沸沸扬扬的,而这个黑客组织又怕暴露在聚光灯下,在两天紧锣密鼓地攻击了大概8500个不同的MongoDB以后,这个黑客组织收手了。
|
||||
|
||||
然而架不住“撑死胆大的,饿死胆小的”,黑客后浪推前浪,前浪虽然死在了沙滩上,后浪仍接踵而来,own3d马上就开始继续搞事,而且收费涨到了半个比特币,一下涨了好几倍。这之后,阿猫阿狗的黑客组织鱼龙混杂地展开攻击,开始删除各种MongoDB的数据。事情到这个地步,问题已经扩大化了。
|
||||
|
||||
那么,到底是什么导致了这个问题呢?为什么有那么多人的MongoDB在“裸奔”呢?这个问题非常有意思,而国外早有好事者在研究。
|
||||
|
||||
简单来说,MongoDB从一开始就不是一个安全的系统。MongoDB的早期版本一直都默认侦听0.0.0.0这个外网地址,但如果有基本的安全常识,都应该知道默认配置要放到内网地址127.0.0.1。
|
||||
|
||||
这个问题在2011年11月就有用户汇报给了MongoDB,有兴趣的可以查Jira上的Server-4216。很有意思的是,在这个汇报的问题中,MongoDB公司CTO在2012年还回复说,如果我们修了这个BUG,就会影响到以前的安装的行为。如此严重的BUG在MongoDB中,又是什么时候修复的呢?2014年。
|
||||
|
||||
近三年的时间里,这个BUG的优先级居然只有P2级别。一般软件公司遇到这种安全问题,给的等级多半都是P0级别。当我亲自去查看这个BUG的详情时,一种恐惧感油然而生。MongoDB的人,难道基本的安全常识都没有吗?
|
||||
|
||||
做个对比来看,传统的数据库,不管是商用的Oracle、SQL Server,还是开源的PostgreSQL、MySQL,默认的设置都有用户名和密码,都会监听在内网上。我们不能说这就特别安全,但起码默认的设置还是合情合理的。MongoDB倒好,默认的设置是在外网上“裸奔”。我也不知道这个事情为什么长久未被解决。
|
||||
|
||||
根据不完全统计,这次全球暴露在黑客眼皮子底下,没有任何安全防范措施的数据近600 TB。当然,这个数字还可能更大。这件事让我们看到了,一个产品如果做得非常好用,但是该花力气的地方却没花,可能造成的破坏力到底有多大。
|
||||
|
||||
MongoDB的这次安全门事件,也引发了一些人一直以来就有的顾虑。在印度,政府对MongoDB一直就持怀疑态度,觉得这个软件不安全,其主要理由是MongoDB的投资机构里面有一家叫作In-Q-Tel的风险投资公司。这家公司在创投圈里很有名,可能不被普通群众熟知,但是其背后的老板,那可是无人不知无人不晓的CIA。
|
||||
|
||||
一家接受了CIA这个美国情报机构作为老板的风险投资公司,它开发的软件到底安全性有多高,是不是有后门,有没有搞鬼,基本上是件说不清楚的问题。这次大规模的数据泄露“裸奔”事件,和产品可能既有的漏洞是不是有关系,更是谁也说不清楚的事情了。
|
||||
|
||||
可以说,在我见过的数据库产品中,这是第一个犯下如此常识性数据安全错误的。那么,一家企业会想让自己的数据“裸奔”于互联网,被黑客删除问你要比特币吗?如果你不想面临这样的境况,那就得仔细斟酌一下要不要使用MongoDB了。
|
||||
|
||||
当然,MongoDB的新版里这个问题早就修复了。只是很多人,尤其是政府部门,对于这个接了CIA投资的公司,始终都保持了一些警惕的态度。我并没有看到中国对这家公司和这个产品的担心,但是印度已经有了这样的担心。这种担心是杞人忧天,还是确有必要呢?
|
||||
|
||||
2017年下半年,震撼整个IT圈的事情莫过于MongoDB开始准备材料要上市了。具体上市的时间可能不是今年底,就是明年初。MongoDB这一路走来,终于走向上市的道路,这的确是一件可喜可贺的事。
|
||||
|
||||
小道消息传来,有人采访MongoDB的领导,领导当然是一副天机不可泄露的样子。今年9月份在慕尼黑参加数据库领域的顶级会议VLDB时,我还和MongoDB的人聊天,问他们对公司即将上市是怎么看的。
|
||||
|
||||
对方的第一反应当然是环顾左右而言它,不想讨论这个话题。于是我说,要不我们就假设要上市吧,那么上市以后对你们有什么改变呢?当然,改变最大的就有辛辛苦苦那么久,终于要赚到钱了。
|
||||
|
||||
在北美市场上创业公司不计其数,能够最后走到上市的却百不存一。顺利地上市,无疑是对MongoDB这个产品的最大肯定。投资人终于有了回报,员工和创始人终于可以从此财务自由、衣食无忧了。上市,对于很多人来说是人生的新起点;对很多公司来说,也是发展的里程碑。
|
||||
|
||||
这条上市路,不知道MongoDB会怎样走下去,市场上对于MongoDB的热情毕竟没有当初那样热烈了。然而即使热度降低以后,MongoDB依然是全球市场上占有率最高的数据库之一。MongoDB“容易上手”的特性,决定了它在初创公司里占据特殊的地位,更何况很多公司还拿它来跑更重要的非初创产品呢。
|
||||
|
||||
但是我们也应该承认,即使到今天,MongoDB刨去“易用性”,在很多方面仍然存在很多这样那样的问题。MongoDB公司赚钱的途径也有一些,但是离盈利却还比较遥远。虽然大家都知道创业公司一般都要烧钱很多年。
|
||||
|
||||
MongoDB一路走来并即将上市,这也是一个成功的故事了。而从10gen发展至今,它在开发出MongoDB这个产品之后所采取的一系列开发和商业运作措施,和很多同时代、同类型的公司相比有着鲜明的特点。2017年初的这次大规模安全事件,则是一个非常值得你我思考的严肃事件。
|
||||
|
||||
关于MongoDB的故事讲完了,MongoDB上市的消息也已被证实。但不知道你又会如何看待MongoDB的这次安全门事件,以及MongoDB的投资机构里面有CIA作后台的In-Q-Tel呢?
|
||||
|
||||
|
||||
|
||||
|
||||
62
专栏/技术与商业案例解读/064以MongoDB为例,看基础架构类产品创业.md
Normal file
62
专栏/技术与商业案例解读/064以MongoDB为例,看基础架构类产品创业.md
Normal file
@@ -0,0 +1,62 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
064 以MongoDB为例,看基础架构类产品创业
|
||||
MongoDB的产品是文档数据库,可以归类于基础架构类的创业公司。这类公司的特点是,产品本身不产生价值,使用其产品做业务和应用的第三方使用者产生价值并给他们付费。
|
||||
|
||||
基础架构类的软件有很多,比如微软的Windows、Oracle的数据库,再比如整个Hadoop生态圈。
|
||||
|
||||
近些年来,因为大数据的蓬勃发展,以Hadoop生态圈为代表的开源基础架构非常火爆。几乎每个Hadoop的拳头产品背后都有一家或者几家创业公司,比如说Hadoop的发行商就有Cloudera、Hortonworks以及MapR,Spark的背后则是DataBricks。
|
||||
|
||||
这些公司成长于开源环境下,发展于开源环境下。和以前的闭源产品比起来,近些年来的基础架构类创业产品基本上都需要开放源代码,或者至少部分开放源代码。
|
||||
|
||||
总结一下基础架构类产品的显著特点,就是:
|
||||
|
||||
|
||||
产品本身不直接产生价值,被使用以后才产生价值;
|
||||
产品往往只有被大量用户使用以后,才能够盈利,未普及开来的产品基本上不可能赚钱;
|
||||
这个市场赢者和输者之间的差距很大,第一和第二所能赚到的钱差距非常大;
|
||||
通常来说这是创业的红海,因此需要创业公司不仅有很强的系统开发能力,更要有很厉害的市场公关能力。
|
||||
|
||||
|
||||
MongoDB出来之前,数据库市场主要有两类产品。第一类是传统意义上的关系数据库。这类数据库的特点是数据模型死板、产品难用,但是产品性能、稳定性和安全性都比较高,而且此类产品通常很贵。第二类是新起来的NoSQL。NoSQL有不少优点,但是最大的问题是写应用的人会觉得很难用。
|
||||
|
||||
MongoDB作为一个文档数据库,公司开发时在策略上做了几个很重要的决定。具体来讲,首先是把绝大部分注意力都用在提高易用性上,其次是把大量的广告和宣传费用都投入到社区的建设中去。
|
||||
|
||||
这两种策略的好处非常明显,首先MongoDB这个数据库上手快,非常好用,对客户的支持也好。用别的产品得学一个月,用MongoDB一天就够了。如果我是用户,我也喜欢啊。其次,社区在MongoDB的支持下日益壮大。作为工具类产品,用户是开发者,开发者社区不壮大,不会有更多的人来用的。
|
||||
|
||||
MongoDB在这两方面做得都非常成功。那么一个用户接受度那么高的产品,为什么最后商业化的时候,盈利却不好呢?这就要说到面子和里子的问题了。 好用是一个产品的面子,产品是否成熟、稳定、 安全,能够应对大规模的并发,不丢数据,不会给出错误的结果,不会突然死机等则是里子的问题。
|
||||
|
||||
最后上线的产品,必须能够真正稳定高效地把系统跑起来。MongoDB的开发,对用户体验重视到了极致,但是对于产品的基本功能,似乎没花太多力气。MongoDB BUG满天飞,2017年的安全问题更是让无数人的数据被黑客删除。所以用户通常是上了MongoDB的船,等到没办法继续用下去了,又下了船。这可以说是MongoDB的巨大悲哀。
|
||||
|
||||
MongoDB最初吸引了很多大客户,那么时至今日,这些大客户去了哪里呢?很多都跑回去用关系数据库了。一个好用但是不可靠的产品,比起一个可靠但不好用的产品,哪个对用户更有吸引力?这个问题,应该不难回答。
|
||||
|
||||
那么,我们从MongoDB这里学到了些什么呢?
|
||||
|
||||
做基础架构类产品,首先也是最根本的一点,就是可靠。 产品不可靠,即使用户能够一时上了船,也不能保证一世都在这个船上。MongoDB的使用者里颇有几个大客户,但是它们却都离开了。产品的可靠性,对于一个产品的长远发展来说,非常非常得重要。
|
||||
|
||||
其次,从用户体验的各方面来说,MongoDB确实可以打150分,远远超过满分。 如果我能够一天学会,为什么非要用一个月去学其他的东西呢?为什么其他公司能够做出可靠的产品,却做不出好用的东西呢?这同样是这些“其他公司”需要思考的。
|
||||
|
||||
而作为创业者,一旦进入基础架构的创业行列,前面就不是一马平川了。公司的程序员资源都是有限的,MongoDB是,其他公司也是。作为创业公司,如何在人力资源有限的情况下去平衡可靠性和可用性,是一个非常值得思考的问题。
|
||||
|
||||
为什么这样说呢?不可用,就没有人愿意用;不可靠,就没有人能够用下去。但是创业公司的资源就这么多,二选一也不现实,面面俱到更不现实,怎么办?在优先级的安排上,这其实是蛮有挑战的一件事。
|
||||
|
||||
我们肯定不能像MongoDB那样弄出安全事件,安全问题在哪里都是高优先级的事。做基础架构如果存在安全问题,是没有人敢用的。但是,比如说是不是需要支持大量的并发、要不要做到多数据中心运行等等,我想有很多东西是可以进行取舍的。
|
||||
|
||||
取舍的标准同样很复杂,我也只能凭借个人的开发经验说几句。
|
||||
|
||||
首先,应该确定使用人群。如果使用人群不需要大规模数据处理,或者不立即需要,那么做大规模并发相关的功能无疑是早了一点。
|
||||
|
||||
其次,应该确定可用性的痛点在哪里,不需要面面俱到,但是最重要的可用性流程都需要走一遍。很多东西只要大部分人觉得很好用,最后10%的人群自己有很强的动手能力就可以了。不需要像MongoDB那样“可用性好到极致,可靠性却成问题”。
|
||||
|
||||
最后,我觉得“吹嘘”肯定是会出问题的。MongoDB在宣传上花了很大力气,却在产品质量仍然存在问题的情况下,就给用户设置了很高的预期。很多时候对于开源产品,如果实事求是地告诉用户东西还不错,但是没完工,大家心里有数以后,对产品的预期和要求就不会过高。过度宣传,往往是基础架构类产品由盛转衰的很重要的因素。
|
||||
|
||||
但无论如何,MongoDB都是一个瑕不掩瑜的产品。 这个产品至今依然有无数多的使用者。当然,很多人现在主要是把它作为原型系统在用,等产品真的上线以后就换掉。因此,MongoDB如果希望成为一个可靠、有稳定营收,在世界范围内真正有影响力的产品,现在是时候静下来好好提高产品的可靠性了。
|
||||
|
||||
如果要做基础架构类的创业产品,可靠性和可用性的兼顾,是每个创业者都需要思考和解决的问题。
|
||||
|
||||
|
||||
|
||||
|
||||
74
专栏/技术与商业案例解读/065直面MongoDB,谈微软的NoSQL战略.md
Normal file
74
专栏/技术与商业案例解读/065直面MongoDB,谈微软的NoSQL战略.md
Normal file
@@ -0,0 +1,74 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
065 直面MongoDB,谈微软的NoSQL战略
|
||||
DocumentDB是微软于2014年推出的,基于Windows Azure的一个PaaS云产品。正如它的名字所示,这个产品是个文档数据库。它主要是冲着MongoDB的市场去的,它的数据模型和MongoDB很像。
|
||||
|
||||
2017年初,微软推出了和MongoDB兼容的DocumentDB的API。在2017年5月微软面向程序员的Build大会上,微软宣布DocumentDB升级为Cosmos DB。Cosmos DB包含多个数据模型,文档模型成为其子集。
|
||||
|
||||
今天,我就带你回顾下这个MongoDB竞品的发展历程。
|
||||
|
||||
让我们把时间线拉回2013年。那时候我还在微软,一个同事神神秘秘地宣布他要离开我们组,去投奔一个秘密项目了。和以往的各种离别不同,这个同事对于接下来转去做什么,一句话也不肯多说。事关公司机密,只是道听途说,这个秘密项目已经开发若干年,微软投入了若干人力物力。
|
||||
|
||||
因为我所在的组做的是经典的大数据基础架构的东西,而我同事十余年如一日地在数据库引擎上做开发,换来换去的组都是数据库引擎开发这方面的。所以我只能大概猜测,他要去的这个组做的应该也是和数据库相关的事情。我实在猜不出来,到底是一款什么样的神秘的数据库产品。
|
||||
|
||||
那时的数据库市场正如火如荼,大数据和NoSQL的风潮一浪高过一浪。MongoDB更是以简单易用、功能强大、服务周到,而成为很多创业者和初创企业的首选。像MongoDB这样的,基于文档而非传统关系模型的数据库,是如此受欢迎。
|
||||
|
||||
那个时候的我一直有个困惑:为什么这么美好而巨大的市场,就没有人觊觎呢?如果我是某家大公司的人,我一定会组个团队,开发一个和MongoDB一样容易卖钱的产品。
|
||||
|
||||
上面这两件事情一直盘旋在我脑海之中,但很长一段时间里都只是彼此孤立地存在。
|
||||
|
||||
然而,它们终究还是以很巧合的方式重合了。2014年,微软正式公开了一个新的数据库——DocumentDB。
|
||||
|
||||
2014年公布的当然只是预览版,正式版于2015年才正式发布。那个时候,我已经离开微软,而我朋友的LinkedIn档案终于更新,改成了自己是做DocumentDB的。有一天,我偶然看到这个朋友的LinkedIn才恍然大悟,原来微软早就已经开始觊觎MongoDB的市场,并秘密研发大杀器了。
|
||||
|
||||
我们知道,MongoDB作为一个产品来说,其易用性达到了相当的高度。唯一不足的,是产品的稳定性。MongoDB充其量就是一个“杂牌军”,在系统是不是丢数据、能不能够有比较好的分布式处理能力、够不够安全方面,都有很多的问题。
|
||||
|
||||
而DocumentDB开始杀入市场的时候,面对强大的MongoDB,这场大战并不好打。面对当时的境况,DocumentDB最终选择了几个切入点。
|
||||
|
||||
|
||||
和MongoDB不一样,DocumentDB最初的查询语言是一种SQL,它的类型系统和表达式则是JavaScript。使用这样一个组合,微软认为能够更好地实现对用户的支持。
|
||||
DocumentDB请来了图灵奖获得者莱斯利 · 兰伯特(Leslie Lamport)坐镇,系统对于事务处理的支持远远强于MongoDB,并且提供了可供选择的事务处理级别。相对而言,MongoDB对事务处理的支持是很脆弱的,有各种各样的丢数据的例子,微软觉得DocumentDB在这方面做得好很多。
|
||||
和MongoDB不同,DocumentDB会自动索引数据库里面的文档。这样一来,访问DocumentDB的时候速度要好很多。自动索引让用户也方便很多。
|
||||
DocumentDB被做成了在Windows Azure上的一个PaaS服务。这样一来,用户自己就不需要部署什么东西了。
|
||||
|
||||
|
||||
这个产品推出以后,在一定程度上证明了微软决策的正确性。微软这次的产品确实在易用性上有了本质的飞跃,也因此受到了很多人的欢迎。
|
||||
|
||||
然而,使用SQL到底是利大于弊还是弊大于利,是一件说不清楚的事情。毕竟,有人喜欢SQL,也有人讨厌SQL。而MongoDB的API方式和对语言的支持,与SQL走的是完全不一样的道路。这种不同,导致程序员们非常喜欢使用MongoDB。当然,这也使得MongoDB失去了大量只会写SQL或者对SQL有明显偏好的人。
|
||||
|
||||
那个对事务处理的支持和事务处理级别的选择的设计,确实让用户在精准服务和省钱之间必须做出选择。这种选择在MongoDB里没有,而且MongoDB在事务处理上也没有提供特别明确的语义支持。
|
||||
|
||||
对于很多用户来说,事务处理是一个很重要的需求。没有事务处理的话,数据的写和读就会麻烦很多,应用程序的开发就不一定会顺利。所以对事务处理的支持,和事务处理级别的选择,是DocumentDB非常重要的一个功能。我觉得,这也是它比MongoDB更出彩的特征。
|
||||
|
||||
为什么微软决定把DocumentDB做成Windows Azure的一个服务,而不是作为一个单独的产品来卖呢?我想一方面固然是Windows Azure自动帮每个用户管理了很多东西,另外一个很重要的方面是微软觉得这个产品会很成功,所以能够借助产品让Windows Azure的订阅和使用数都上一个台阶。而且微软为了推广这个产品,在Windows Azure上的收费很低。可以说,为了让这个产品去推动Windows Azure的订阅,微软也是不遗余力。
|
||||
|
||||
实际上,这个产品一开始算不上多么成功。的确是有不少人在用,但是这个比例和微软期望的,或者和MongoDB的使用率比起来,实在是低很多。而从已有的MongoDB迁移到DocumentDB上,又意味着程序的重新开发。很多人一点都不想重新开发一个新程序,所以即便DocumentDB有厉害的地方,也只有新的应用在用,而老的基于MongoDB的应用转化过来的比例并不高。
|
||||
|
||||
为了彻底解决这个问题,让那些使用MongoDB作为数据库的应用可以顺利地迁移到DocumentDB上,2017年的时候,微软准备了一个大杀器: 为DocumentDB提供了一套和MongoDB完全一样的API。
|
||||
|
||||
这次微软终于决定不再玩SQL了,也不再矜持了。既然Mongo是标准,那么我们就在自己的系统里面把标准给兼容了。那样你们要是在MongoDB上跑的,就可以不用改程序直接跑到我的数据库上来。
|
||||
|
||||
这种做法颇有点流氓做派。但是我们也知道,API不可能申请专利,加上MongoDB本身还是开源的,所以微软的这种做法也是情理之中的事。这样一来,但凡背后用了MongoDB的程序,都可以顺利地转化过来了。
|
||||
|
||||
MongoDB自己本身也并非没有问题,而这反过来给微软帮了很大的忙。在2017年1月的时候,黑客们大规模袭击了默认安装的MongoDB。这些MongoDB没有密码,可以被随意登录。黑客袭击MongoDB后,将数据删除或者转移到其他地方,并留言需要支付若干比特币才给恢复数据。造成这个问题的主要原因,还是MongoDB本身的默认安全设置不好。
|
||||
|
||||
这的确是给微软提供了很多活动的空间。在“更安全”的宣传下,又提供了MongoDB的API,DocumentDB终于开始迅猛发展,被越来越多的人使用。这又反过来促使微软对DocumentDB有了进一步的期望。
|
||||
|
||||
2017年5月微软全球Build大会上,作为大会主讲内容的一部分,微软宣布DocumentDB升级成为Cosmos DB。Cosmos DB直译过来就是“宇宙数据库”。Cosmos DB是DocumentDB的一个超集,不仅包括DocumentDB的所有功能,而且增加了对图数据库在内的多种其他数据库的支持。
|
||||
|
||||
Cosmos DB最初宣布的时候,很多人对这个命名表示了疑惑,因为这和微软内部大数据处理平台Cosmos的名字很像。也因此,很多时候不知情的人会以为,微软是把内部数据平台Cosmos开放给外面的人使用了。然而实际上,Cosmos DB和Cosmos并无半毛钱关系。
|
||||
|
||||
但是,Cosmos DB的宣传如火如荼、声势浩大。再加上图灵奖获得者的现身说法,Cosmos DB的知名度被迅速打开,并且获得了很多人的信任。
|
||||
|
||||
于是从DocumentDB升级到Cosmos DB,微软不仅完成了在文档数据库上面的布局,看起来其能力更是远远超过了MongoDB。这个数据库自2017年5月以来,Windows Azure的用户都在使用。虽然效率如何还需要时间去检验,但是其易用性已经经过了考验。
|
||||
|
||||
无论如何,作为MongoDB在市场上唯一的竞争对手,Cosmos DB的目标很宏大。如果微软能够顺利地让这个产品成长起来,那么在将来它很可能是Windows Azure云服务里面非常有特色的一个服务。当然,如果微软没能做好产品,用户又不愿意绑定到Windows Azure的战车上,未来就会堪忧了。
|
||||
|
||||
在我个人来看,未来Cosmos DB的成败概率大致在一半一半,而这在很大程度上取决于MongoDB怎么解决自己的问题,以及其他的云计算厂商打算怎么玩转文档数据库这个游戏。
|
||||
|
||||
|
||||
|
||||
|
||||
71
专栏/技术与商业案例解读/066Hadoop三国之魏国Cloudera.md
Normal file
71
专栏/技术与商业案例解读/066Hadoop三国之魏国Cloudera.md
Normal file
@@ -0,0 +1,71 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
066 Hadoop三国之魏国Cloudera
|
||||
今天开始,我打算介绍一下Hadoop领域里面的三家发行商,它们之间的关系正好和三国时候的魏蜀吴很类似,所以不妨就排演一出Hadoop的三国版,带你一起感受和思考下大数据领域的发展和乱相。
|
||||
|
||||
首先出场的是魏国Cloudera。我们知道三国时的魏国,曹操以“挟天子以令诸侯”而知名。这句话用在Cloudera身上不是太合适,不如说“天子”,也即Hadoop的第一个作者,和Cloudera联合在一起,来试图“令诸侯”更为贴切。我们姑且将就一下吧,历史总是惊人得相似,但也只能到相似的程度了。
|
||||
|
||||
Cloudera成立于2008年,由克里斯托夫 · 比塞格利亚(Christophe Bisciglia)、埃姆 · 阿瓦达拉(Amr Awadallah)以及杰夫 · 哈默巴赫(Jeff Hammerbacher)创建。如今阿瓦达拉还是CTO,哈默巴赫虽然挂着首席科学家的头衔,但很少参与公司管理了,而比塞格利亚则混迹于硅谷IT圈。
|
||||
|
||||
2012年大数据的概念才开始红火起来,2008年他们几位就能够看到这个市场并创立公司,实在是值得敬佩。
|
||||
|
||||
2009年3月发生了Cloudera创立以来第一件比较大的事件:第一笔融资到账。这笔500万美元的融资,是由全球知名的五大风险投资机构之一的Accel Partners提供的。Accel Partners这个投资者,在后面的几轮投资里面都扮演了重要角色。我想它最后一定是赚了不知道多少倍的钱。
|
||||
|
||||
伴随融资的到来,Cloudera发行了它的第一个Hadoop集成版。涉及Cloudera的盈利方式,我们需要展开讲一讲它的Hadoop集成版。
|
||||
|
||||
现在业界通常也把Cloudera发行的Hadoop版本叫作CDH,CDH里面的东西本身都开源,也可以从Cloudera官网获得。但是除了CDH发行版以外,Cloudera还有一些私货,这些就是Cloudera独有的了。
|
||||
|
||||
Cloudera的创始人在一次访谈中提到,2008年他们创建公司的时候,打算做的服务类似于现在AWS的Elastic MapReduce,通过在云上给大家提供服务来赚钱。然而他们很快就发现这个模式太超前,在2008年的时候不切实际,而且投入也很大,所以就转向了做Hadoop发行商的角色。
|
||||
|
||||
所谓的Hadoop发行商,有点类似于Linux世界里的RedHat。公司通过开源软件的包装,整合稳定的版本形成一个套餐,通过让企业用户购买套餐来实现盈利。
|
||||
|
||||
企业用户愿意购买套餐无非是两个原因:一是为了对方提供的技术支持,二是对方的套餐里面有一些开源版本没有的东西,可以方便企业使用和部署这个开源的版本。
|
||||
|
||||
Cloudera的盈利模式就来自于这两方面。Cloudera给企业提供技术支持,而这些技术支持是要通过购买收费套餐获得的。
|
||||
|
||||
Cloudera的价格不便宜,最新的价格差不多是1万美元一个节点一年。这个价格是相当高了,所以Cloudera在我国卖的时候,常常是用户只愿意买10个节点,回头自己就跑上几百个节点。盗版软件曾经一度横行,免费多用节点也就不是什么难事了。国内大致就是这个情况了。
|
||||
|
||||
Cloudera在盈利模式上还依赖于套餐里面拥有的非开源的东西。Cloudera的CDH是100%开源软件整合,在网站上可以免费下载使用。但是Cloudera同时又提供了一个叫作Cloudera Manager的企业管理组件,这个东西是不开放源代码的,在三个月试用期过后就要收费了。它提供了企业比较在乎的对计算机集群的管理、部署、升级、监控等各方面的功能。
|
||||
|
||||
这些功能对于普通用户,尤其是喜欢折腾的用户来说可能无所谓,但是Cloudera相信这些功能对于真正有钱的企业来说必不可少,而开源的Hadoop版本里面最差的就是这部分。
|
||||
|
||||
Cloudera相信,他们自己做的这个Manager,能够比其他Hadoop发行版更有价值,更加适合企业级用户使用。
|
||||
|
||||
等到2009年9月,Cloudera又一次的大手笔震惊了IT界。他们请到了一尊“大神”——道格 · 卡丁(Doug Cutting)。
|
||||
|
||||
这位大神是“Hadoop之父”,第一位作者。开始他是自己自娱自乐写Hadoop,后来被雅虎这个“活雷锋”招安,带领一队人马做Hadoop。有关大神的故事长篇累牍,讲也讲不完,因此这里就不展开了。
|
||||
|
||||
据说,因为在此之前卡丁和他的顶头上司,雅虎里面管Hadoop的那个副总裁之间互相看不顺眼,经常被对方鄙视或者穿小鞋,大神心里早就不爽了。于是Cloudera手一招,大神就毫不犹豫地跳过来,成了首席架构师。当然还有一个说法,那就是Cloudera给了很多钱很多股票。
|
||||
|
||||
至于哪个版本为真,其实不重要了。不管怎么样,大神现在肯定是发财,发大财了。至少如果大神一直继续在雅虎,肯定赚的比现在少很多。大神做了Cloudera的首席架构师以后,日子是过得顺风顺水,后来还荣升了著名的Apache基金会的主席。
|
||||
|
||||
自从有了卡丁以后,Cloudera腰杆也直了,底气也足了,从此以后就以“Hadoop正宗”自称了。
|
||||
|
||||
这个故事有点类似于曹操拿着天子做文章,但不同的是天子算是被曹操胁迫的,而“大神”和Cloudera这几个与Hadoop最初版本没太多关系的创始人之间,多少应该算是互相捧场,皆大欢喜。
|
||||
|
||||
好日子开始了,Cloudera不断烧钱壮大,到了2011年又开始了新一轮融资,这次的融资引入了一个特别值得注意的角色:In-Q-Tel。
|
||||
|
||||
国内的朋友对In-Q-Tel可能不太熟悉,这个金主是CIA下面的投资公司,专门投资对美国国家安全有重大意义的项目。其中著名而神秘的大数据分析公司Palantir,美国棱镜项目技术提供者的启动资金就是这家基金给的。另外,MongoDB也接受过他们的钱,所以印度觉得MongoDB不安全。而有了这个机构的投资,到底是不是还安全,这只能是“公说公有理婆说婆有理”了。
|
||||
|
||||
这次Cloudera拿到了4000万美金。有了这么大一笔钱,Cloudera迎来了一次大发展。这次Cloudera意识到Hadoop需要一个更快的查询引擎,并高调宣布要做一个MPP的产品,也就是Impala。
|
||||
|
||||
这也是Cloudera在宣传口号上的一次调整。以前Cloudera总是称自己为Hadoop发行商,这次它华丽丽地改名了,从此以后表示自己是个数据仓库公司,而Impala则是他们大力推进的查询系统。
|
||||
|
||||
Imapla可算是命不太好。最开始,Cloudera试图让Impala成为自己控制的项目,所以并没有将其交给Apache,于是Impala也就没有得到Cloudera以外人士的重视。结果,其他很多的竞争对手就这样起来了,尤其Spark更是攻城略地。等到后来Impala被贡献给Apache时,已经是为时太晚。
|
||||
|
||||
2014年是Cloudera的丰收年。这一年里,英特尔以7.5亿美元的价格拿走了它18%的股权。跟随英特尔的还有谷歌、戴尔公司老总迈克尔 · 戴尔(Michael Dell)的私人投资基金,以及其他各路人马。这次投资也把Cloudera的总估值送上了41亿的巅峰,让Cloudera当之无愧地坐上了Hadoop发行商里的第一把交椅。
|
||||
|
||||
为了坐实数据仓库公司的梦想,Cloudera又开始了另外一个项目Kudu,即2015年开始主推的新一代存储系统。Kudu的想法是让Cloudera有一个可以同时支持OLAP和OLTP查询,两者性能又都不会太差的存储引擎。这个项目引起了广泛关注,并让Cloudera再次吸引了大量的注意力。
|
||||
|
||||
然而俗话说得好,盛极必衰。此后的三年里,Cloudera的业务并没有随着“大数据”这个概念进一步膨胀,相反的,它的估值到底值不值41亿美元,一直让人有些揪心。
|
||||
|
||||
Cloudera终于走向了上市之路,而这个过程可谓非常曲折,因为上市消息宣布以后,大家首先注意的是上市材料里面的估值并没增加。2017年,Cloudera自砍估值一半,上市以后的估值只有20多亿。别人不知道,起码英特尔的投资是彻底亏了。
|
||||
|
||||
这种拼命也要上市的做法,充分反映了Cloudera可能遇到了什么问题。从各方面来看,这可能主要还是现金流的问题,缺钱却没有投资人愿意继续投入了,只能血淋淋地上市了。上市后的Cloudera并没有飞起来,可能大家都还希望给它一点时间,看看它到底能做多好吧。
|
||||
|
||||
|
||||
|
||||
|
||||
67
专栏/技术与商业案例解读/067Hadoop三国之吴国MapR.md
Normal file
67
专栏/技术与商业案例解读/067Hadoop三国之吴国MapR.md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
067 Hadoop三国之吴国MapR
|
||||
今天我要介绍的这个Hadoop发行商是MapR。它算得上是一家特立独行的公司,它实力很强,但却比较少去参与争斗,所以我们把它称作“吴国”吧。
|
||||
|
||||
MapR成立于2009年,由CEO约翰 · 施罗德(John Schroeder)和CTO斯里瓦斯(M. C. Srivas)创立。到2016年的时候,施罗德卸任CEO,做了执行主席(Executive Chairman),斯里瓦斯则去了Uber。为什么CEO和CTO下台的下台,去Uber的去Uber,这是个有意思的问题;我留到文章最后来说。
|
||||
|
||||
先从MapR这个名字聊起,它是MapReduce的缩写。在心理学上有这样一个说法:人们总是会在潜意识里面,流露出对自己不擅长的东西的关注。从这一点上来看,MapR这个公司拿了MapReduce来做商标,而事实上它擅长的也的确不是MapReduce。
|
||||
|
||||
MapR的Hadoop发行版和其他公司很不一样,它是一个挂着Hadoop外壳,但是夹杂着自己私货的版本。
|
||||
|
||||
MapR的联合创始人兼CTO曾经在谷歌的文件系统组做过经理,所以他很强烈地认为Hadoop的文件系统是个“渣子”。于是这个CTO用很低廉的薪资在印度雇用了一群程序员,重构了一个文件系统。这个文件系统据说有比Hadoop的文件系统优越无数倍的性能、稳定性、安全性,等等。
|
||||
|
||||
而MapR的Hadoop版本,简单一点来说,就是把Hadoop里面的文件系统替换成了自己的这个不开放源代码的文件系统,同时又做了很多工作,让这个文件系统和现有的Hadoop体系兼容。这种兼容性在我看来其实挺难做的,但是MapR号称是做到了。
|
||||
|
||||
本着在文件系统道路上越走越远的想法,MapR踏出了第二步:瞄准了在Hadoop生态圈里非常重要的NoSQL产品HBase。
|
||||
|
||||
HBase的大名可谓众人皆知,但是因为HBase受到了Hadoop文件系统本身的一些限制,以及设计与底层的存储分离得太厉害,其性能一直不是很好。
|
||||
|
||||
MapR的下一步做法是改变文件系统,在文件系统内实现对HBase的支持,并且提供HBase的接口给上层应用。这样用户其实不需要额外装HBase,就自然而然地拥有了HBase的功能。
|
||||
|
||||
这还没完,MapR在自我改造的道路上越走越远。它们又瞄准了Kafka——这个在Hadoop系统里面做数据交换的重要服务。MapR的做法还是继续改改改,改它的文件系统,让文件系统又拥有了Kafka的功能。于是,用户们不需要安装,就可以使用Kafka了。
|
||||
|
||||
没错,就是这样。这个创业公司凭借一己之力,集聚了一群程序员,挑战了全世界,重新实现了这么多的功能,然后再包装进自己的发行版卖给客户。更重要的是这些重新实现的功能,据说性能上要好很多。而开源的东西,按照MapR的说法,实在是只能凑合着用。怎么样也比不上MapR的高大上。
|
||||
|
||||
MapR的说法是,这种做法不只实现了同样的东西,而且做得更好、更高效。“更快、更高、更强”是每个人追求的目标,如果后面再加个“更便宜”,那就太完美了。
|
||||
|
||||
只是MapR的这套系统本身以赚钱为目的,和“便宜”是没有什么关系了:MapR的系统卖得比其他人的系统都贵,因为他们觉得自己的系统更好。
|
||||
|
||||
此外,但凡是存储相关的功能,MapR都重新实现了一遍,其他部分则选用开源的,这就导致了两个问题。
|
||||
|
||||
第一,那些开源的东西在这个文件系统下的兼容性需要仔细测试。所以很多时候你会发现,只有伴随着MapR的发行版一同发行的开源工具,才能在MapR的文件系统上很好地工作,而外部下载的就不能保证这一点了。
|
||||
|
||||
第二,就是客户有顾虑。客户会想:你的系统是自己实现的,如果我上了你的“贼船”,再想回头去用Cloudera的,就不太可能了吧?因为你的数据存储,对别人来说就是不透明的,迁移起来会有障碍。为了避免被“绑”在MapR的战车上,还是不要买你家的东西吧?
|
||||
|
||||
这其实很考验市场人的宣传功力。 当然MapR的宣传队伍不是吃素的,他们把自己的系统定义为“二进制代码无差别兼容”。简单一点来说就是,在其他的Hadoop发行版和MapR之间,可以互换模块随便运行。
|
||||
|
||||
这个口号看上去很美好,但实际测试的时候往往就是另一番景象了。这个所谓的“二进制代码无差别兼容”,从来没有真正实现过。不过,倒是很多人在宣传的时候说“我们就是Hadoop,没有兼容性问题”。这个Hadoop发行版终究没能成功开疆拓土,在美国以外地区几乎没有什么人用。
|
||||
|
||||
相对于存储系统,MapR在系统的执行方面就显得没这么自信了。MapR有关执行的部分,比如说MapReduce,或者在MapReduce之上开发的各种查询语言——如HIVE、PIG等,都是直接用开源的。不过,MapR对开源社区的贡献是有目共睹得低。
|
||||
|
||||
MapR主导了一个开源项目Apache Drill的开发。大概在2013年的时候MapR的人来找过我,我和当时的Drill项目负责人聊过以后,感觉对方对很多问题都还没想清楚,所以没有去MapR工作。
|
||||
|
||||
后来Drill的发展也并不顺利,再后来变更了主要负责人,项目也慢慢起来了,参与进来的公司越来越多。再后来,伴随着MapR创始人的下野,Drill的人也跑去开了个创业公司。我个人对于这个创业公司的前景不是特别看好,主要还是感觉Drill这个产品不是很出彩。
|
||||
|
||||
Drill这个东西是开源的,但是MapR这个企业对于好东西,往往都不开源。因此,我们难免要仔细审视一下Drill。至于Drill发展至今又是个什么境况,我就不妄加评论了。
|
||||
|
||||
MapR的融资过程比较有意思,前后融了好几轮,最后一轮时,谷歌旗下的风险投资部门Google Venture投了钱。为什么说有意思呢?因为谷歌很少在Hadoop的相关领域撒很多钱,比如在Cloudera上投入就不多。
|
||||
|
||||
我想,可能谷歌从来都没有看好过Hadoop的文件系统,或者Hadoop整个生态圈。但是对于凭一己之力去重写文件系统的公司,并且其创始人还是从谷歌出来的,知道Hadoop内部是怎么做的,可能就刮目相看了。谷歌也许认为这样的公司有可能成功,所以才投入了很多钱。
|
||||
|
||||
MapR的生意很有意思。它真正的客户量很少,可能连Cloudera的10%都不到。但是很奇怪,MapR和Cloudera在营收上差不多。也就是说,MapR的每个客户,贡献给它的钱都要多很多。这到底是什么原因导致的呢?因为客户上了MapR的“贼船”下不来,而不得不继续使用?还是这家公司的产品真的受有钱公司的欢迎?我无法去辨别。
|
||||
|
||||
MapR的CTO兼联合创始人,在2016年离开MapR成了Uber的首席数据架构师。创始人下台或者离职,显然不是什么好事情。那么,这个印度人为什么放着自己好好的公司不做,非要跑去Uber呢?
|
||||
|
||||
我想不外乎两个可能性:一是自己做得没兴趣,不想做下去了,二是资本的力量进来了。也许CTO觉得钱赚得不够多,不是上市的好时期,而资本没有这个耐心继续等下去,因此就只能把“拦路虎”清掉了。我想,第二个原因可能性更大。
|
||||
|
||||
但是我们必须要提醒大家的是,MapR的这套发行版能够出来,这位CTO功不可没。离开了他,MapR是不是依然具备继续前进的能力呢?这就留给时间来检验吧。
|
||||
|
||||
不知道MapR到底什么时候要上市,也不知道上市以后会采取什么举措,但这种创始人离职的现象,也许不是一个好的信号。我很难理解一个创始人需要在公司上市前夕,离开自己辛苦创业的公司这种情境。我只能说,要么是公司层面的问题,要么就是资本的力量太强大了。你认为,这对MapR又会有什么影响呢?
|
||||
|
||||
|
||||
|
||||
|
||||
85
专栏/技术与商业案例解读/068Hadoop三国之蜀国Hortonworks.md
Normal file
85
专栏/技术与商业案例解读/068Hadoop三国之蜀国Hortonworks.md
Normal file
@@ -0,0 +1,85 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
068 Hadoop三国之蜀国Hortonworks
|
||||
我把Hortonworks类比为“蜀国”,主要有两个原因:一是它也算正统出身,是原来雅虎里面写Hadoop的那个团队被剥离以后成立的;二是“蜀中无大将,廖化作先锋”,Hortonworks和其他公司比起来,真是没什么大神。Cloudera有Hadoop的创始人在,MapR的CTO精通文件系统,而Hortonworks缺了一个标杆式的人物。
|
||||
|
||||
Hortonworks的起源要追溯到2011年,那年雅虎决定将Hadoop团队拆分出去,与人合资成立一家新公司。
|
||||
|
||||
我想,这在很大程度上是因为雅虎一直是Hadoop源代码的最大贡献者,而Cloudera则拿着雅虎的源代码赚钱。雅虎里面做Hadoop的人看着对方发财,心里肯定很不爽,起了单干的雄心壮志,这是可以理解的。
|
||||
|
||||
主导这次拆分的人是埃里克 · 巴尔德施维勒(Eric Baldeschwieler),他当年也是雅虎Hadoop软件开发副总裁,掌管了整个Hadoop团队。拆分后,他先后就任Hortonworks公司的CEO和CTO。下台以后的他很久没有再找一份正式的工作,而是以投资人和导师的身份混迹于硅谷的IT圈。直到最近,他终于去了亚马逊旗下的子公司A9做了搜索部门的一把手。
|
||||
|
||||
这个埃里克就是那个当年和道格 · 卡丁(Doug Cutting)不和的人,他在一定程度上导致了卡丁决定离开雅虎,加盟Cloudera。后来卡丁发达了,埃里克“没落”了,所谓人生起伏莫过于此,不知道两位相见是否会感触良多。
|
||||
|
||||
Hortonworks早年赚钱很困难。竞争对手Cloudera不但先一步进入了市场,挖到了Hadoop的精神领袖,而且更重要的是,很早就开始专注于一些企业需求,包括权限管理、资源管理,以及对用户行为的监督等企业级应用的必需品。这些东西当然一部分被Cloudera给贡献进了Hadoop,但另外一部分则成为了Cloudera收费的Cloudera Manager。
|
||||
|
||||
而写了Hadoop大部分程序的Hortonworks没有这个觉悟,他们认为“开源”就是好的。这个公司从一开始就打出口号:我们的东西100%是开源的。
|
||||
|
||||
“100%开源”这件事到底好不好,就是“仁者见仁,智者见智”的事了。但是不可否认,既然是“100%开源”的,那么其他人也很容易就能组个局,就可以卖自己的Hadoop了,为什么非要用Hortonworks的呢?事实上这事情英特尔干过,Oracle想过。
|
||||
|
||||
所以这样一看,Hortonworks的竞争优势,最后只剩下“更廉价”了。Hortonworks到处打价格战抢客户,这个生意显然也没做成功。我想主要原因还是有钱的不缺那点钱,没钱的希望更便宜。
|
||||
|
||||
而这种100%开源的做法,意味着Hortonworks的发行版并不能比开源版带来额外的附加价值,从而也使得Hortonworks的定价没有太多的空间。这让Hortonworks成了“廉价”的代名词。
|
||||
|
||||
Hortonworks成立的时候,最大的一单生意来自于微软。那个时候微软特别得恐慌,因为Hadoop只能跑在Linux上,不能跑在Windows上。长久下去,这必然会影响到Windows的销售。在那个以Windows为纲的年代里,微软对任何会影响到Windows销量的问题,都要想办法解决。
|
||||
|
||||
微软的解决方法就是:把Hadoop做到Windows上来。据说微软和几家商谈,Hortonworks开价最便宜,于是微软决定让Hortonworks来做Hadoop的Windows版本。2013年的时候,Hadoop终于能够在Windows上跑起来了,而微软的重点却已经从Windows转移到云计算了。
|
||||
|
||||
因为版权的问题,在云上,Windows的虚拟机比Linux的虚拟机更贵,所以大家都宁可用Linux而不用Windows。微软自己的Windows Azure也不得不加入对Linux的支持里来,因此让Hortonworks做Hadoop的Windows版本这单生意,并没有让Windows的销量上去多少,微软多少有点赔本赚吆喝,但是Hortonworks的确很需要微软的钱。
|
||||
|
||||
Hortonworks当时被投资人问的最多的问题就是:你们的钱从哪里赚的,是不是还是主要从微软来?而Hortonworks可能觉得自己出身于硅谷,硅谷的传统又是“反微软”,与微软绑定似乎就是硅谷的敌人了,因此虽然拿了微软的钱,但态度却依然暧昧。
|
||||
|
||||
具体的表现是Hortonworks一方面和微软的合作扭扭捏捏,不太愿意和微软保持类似Cloudera和Intel那样很紧密的合作关系,也不太愿意微软注资拿一部分股份。另外一方面,Hortonworks在投资人面前非常强调自己在如何如何地努力增加非微软的收入。
|
||||
|
||||
Hortonworks与微软暧昧踟躇的关系并不是好事。微软毕竟家大业大,有很多企业客户,而Hortonworks最缺的就是客户。Cloudera这方面明显聪明太多了,接受了英特尔的投资让其成为自己的大股东,从而获得了英特尔这家大企的支持。
|
||||
|
||||
当Hortonworks有了更多的合作伙伴,其他各处的总收入超过微软给的钱时,与微软的合作就从若即若离,变得同床异梦起来。而萨蒂亚 · 纳德拉(Satya Nadella)的上台也让微软从“以Windows为纲”彻底转向了云计算。Hadoop能不能在Windows上运行,这一点已经不是重点了。
|
||||
|
||||
于是,在某次宣传Windows Azure的活动里,Cloudera作为合作伙伴,也在邀请之列。这样一来,Hortonworks和微软的蜜月期结束了,之后两家公司渐行渐远。没有抱住微软的“大腿”,这是Hortonworks发展史上非常遗憾的一幕。
|
||||
|
||||
Hortonworks在Hadoop社区里有一场非常知名的“互撕事件”,事件的另一主角是Cloudera。这都要从2011年说起,曾经的雅虎Hadoop团队重要成员,后来的Hortonworks创始人之一,也就是欧文 · 奥马利(Owen O’Malley)写了一篇博文:“The Yahoo!Effect”。
|
||||
|
||||
这篇文章总结来说就是:Apache基金会很厉害,开源项目很多。但是,这篇文章同样传递出这样一个意思:雅虎在里面做了大部分的贡献。至于竞争对手Cloudera,在文中就显得非常惨不忍睹。
|
||||
|
||||
也许文章的本意是唤醒大家“Hortonworks才是Hadoop正统”的意识,但是Hortonworks已经没什么牛人了,即便正统又怎么样呢?
|
||||
|
||||
Cloudera看到此文,自然不干了,他们辛辛苦苦挖来了道格 · 卡丁装点门面,就是想让自己显得更为正宗。这篇文章却直接“打脸”,似乎是说他们不劳而获,拿了雅虎的东西卖钱。
|
||||
|
||||
Cloudera的辩解方式简单总结就是:这个当年写代码的人——“Hadoop之父”道格 · 卡丁,都在我们公司了,他所有写的代码,包括过去未被我们雇用时写的代码,现在也应该算是我们公司的贡献了。
|
||||
|
||||
经过这样修改之后,Cloudera迅速成为了第三大贡献者,当然前两位依然是Hortonworks和雅虎。但不管怎么说,这也只是让Cloudera显得好看一点而已。Cloudera一下子从不重要的贡献者跻身为第三位贡献者的地位,我想Cloudera大致也就只能修饰到如此程度了吧。
|
||||
|
||||
非常有意思的是,Hortonworks里面原本就最不爽道格 · 卡丁的埃里克跳了出来,也就是前雅虎Hadoop软件开发副总裁,后来又先后做了Hortonworks CEO和CTO的那位。
|
||||
|
||||
埃里克说Cloudera这个统计也有问题。因为这个统计里面,用的指标是每个公司分别给系统提交了多少个补丁,而在统计的过程中并没有考虑每个补丁的大小是不一样的。于是埃里克说,我们干脆来看看每个公司分别提交了多少行源代码吧。
|
||||
|
||||
这一统计,雅虎的源代码还是占据了大部分,Hortonworks和Cloudera基本上旗鼓相当。但是埃里克说Hortonworks作为一家公司成立,晚了好几年,可是提交的源代码数量已经和Cloudera旗鼓相当了。Cloudera单位时间内提交的代码数量不如Hortonworks,所以Cloudera自然是名不符实。
|
||||
|
||||
这次事件主要就是在争夺Hadoop的控制权。而两位主角因为忙于互撕,直接导致Hadoop在两年内没有什么新版本发布。这样一来围观者看不下去了:天天叫着Hadoop的新版本怎么还没来,我们没空看你们互撕。
|
||||
|
||||
我们必须说资本的力量是无穷的,道格 · 卡丁顺利荣升Apache基金会主席,他的影响力一时无二;而埃里克这次跳出来发表意见,难免引起公司内外包括投资人的一些反应,之后他也从Hortonworks离职,然后很长一段时间里没有找到全职的工作。
|
||||
|
||||
最后的结果是,阿帕奇Hadoop项目委员会的成员里,Hortonworks和Cloudera的人大致占了一半,谁也不是赢家。Hortonworks可能更惨一些,毕竟CTO因为跳出来发表意见,之后就辞职了。
|
||||
|
||||
更重要的是,“二虎相争”又让第三方的软件有机可乘,比如MapR就趁机拓展了地盘,亚马逊的Elastic MapReduce更是迅速占领市场。|因为Elastic MapReduce这个版本在云上面的服务是基于S3的,而不是原生的Hadoop文件系统。
|
||||
|
||||
另外一方面,随着大数据技术的发展,引领大数据潮流的谷歌新推出了一个叫作BigQuery的服务,它主要是提供交互式分析查询,而交互式分析查询在Hadoop的生态系统里也越来越重要,客户越来越需要。但是这种交互式查询HIVE做不了,因此Cloudera启动了Impala项目,MapR也以Drill项目来响应。
|
||||
|
||||
但是Hortonworks却坚持说:HIVE才是交互式分析查询最自然的选择。虽然现在HIVE因为性能问题做不到交互式,但是Hortonworks决定大举进军HIVE,提高它的性能。Hortonworks相信经过性能改造,HIVE能够提供交互式分析查询。
|
||||
|
||||
结果,这条路走得不但艰难,而且很失败。Hortonworks始终没能够把HIVE改造到可以和Impala或者Drill相提并论的程度。而在合适的时候没有开始新产品的开发,没有了“大杀器”的Hortonworks,其产品销售比起其他两家来越加困难。
|
||||
|
||||
因为产品销售困难,Hortonworks的融资之路也开始受困。在此背景下,Hortonworks决定率先IPO;既然拿不到投资者的钱,不妨去股市里找钱。资金链的危机,据说正是Hortonworks急速上市的重要原因。
|
||||
|
||||
但是,这个上市过程就显得有点“血淋淋”了:上市的时候大概10亿美金,上市后不到半年,就腰斩一半只剩下5亿美金了。
|
||||
|
||||
Hortonworks这个正统出身的Hadoop公司,今天混到这步田地,只能说是“小二黑过年,一年不如一年”了。
|
||||
|
||||
Hortonworks公司既无大公司支持,又没有自己独特的功能。100%的开源,没有自己主导的开源项目,也没有自己开发的闭源的套件,它的未来之路会好走吗?
|
||||
|
||||
|
||||
|
||||
|
||||
53
专栏/技术与商业案例解读/069Hadoop及其发行商的未来.md
Normal file
53
专栏/技术与商业案例解读/069Hadoop及其发行商的未来.md
Normal file
@@ -0,0 +1,53 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
069 Hadoop及其发行商的未来
|
||||
以及它的生态圈,从开始到现在也已经有差不多十年历史了。Hadoop从雅虎支持的一个开源项目,到由很多项目组成的Hadoop生态圈,以及依靠Hadoop发行版开展商业活动的三大公司Cloudera、Hortonworks以及MapR,其发展不可谓不迅猛。
|
||||
|
||||
我在前面重点介绍了Hadoop的三大发行商,希望通过对其历史、技术和商业模式等各方面的介绍,让你对Hadoop当前的商业化状况有了一定的了解。
|
||||
|
||||
那么十年之后,整个生态圈又发生了哪些变化,Hadoop发行商们的未来又会是怎样呢?本文就来探讨这方面的问题。
|
||||
|
||||
Hadoop诞生的原因有很多,但是最重要的一条是除去谷歌,硅谷的其他互联网公司们每一个单拎出来,其研发能力都有限,不太可能构建出谷歌那样的大数据架构。而互联网业务的发展决定了这一套大数据架构是不可或缺的,所以这些“兄弟们”以雅虎和Facebook为首,开始抱团取暖,在Hadoop这个开源产品下,逐渐构建出了整个生态体系。
|
||||
|
||||
因此,这个生态体系最初的服务对象也是这些互联网公司。互联网公司的研发能力都很强,可以自己定制系统,所以Hadoop生态圈的发展,在很长一段时间里都不够稳定。而传统的非IT企业,则不愿意使用Hadoop。
|
||||
|
||||
这种情况随着Cloudera、MapR和Hortonworks的加入,有了很大的改善。这些Hadoop发行商提供的版本,不但是Hadoop的稳定版本,而且加入了很多帮助传统企业使用Hadoop的工具。这些厂商成了Hadoop生态圈里的另外一批受益者。
|
||||
|
||||
但是它们都算不上Hadoop生态圈里最大的受益者,从实际情况来看,亚马逊这个全球最大的云计算厂商才是。这里面有两方面原因。
|
||||
|
||||
首先,亚马逊自己的研发能力也不足以开发出一套大数据分析生态系统,但是它同样需要类似Hadoop的大数据分析平台,所以亚马逊内部就需要使用Hadoop。这样一来,亚马逊就需要研究怎么在自己内部部署Hadoop系统。
|
||||
|
||||
其次,亚马逊又是全球最大的云计算厂商,其所有云计算服务对内对外的接口完全一样,因此通过在亚马逊实现Hadoop的自动运行,除了服务亚马逊,更可以提供服务给外部使用,这就是Elastic MapReduce服务。这不仅让各大企业省去了购买机器集群和管理机器集群的负担,而且让亚马逊卖出了更多的云服务。这种“一鱼两吃”的做法,让亚马逊迅速做大了自己的圈子。
|
||||
|
||||
与之相反,其他两个云厂商——微软和谷歌,一开始都不是Hadoop生态圈的,它们都研发了自己的大数据处理平台,供内部使用,因此对于让Hadoop在云端运行起来没有那么大兴趣。等到它们发现,原来亚马逊已经靠云卖Hadoop赚了很多钱,多少有些为时已晚。
|
||||
|
||||
亚马逊的Hadoop云端服务,同时摊薄了谷歌和微软这样的云厂商,以及Cloudera、MapR和Hortonworks这些Hadoop发行商的盈利空间。
|
||||
|
||||
Cloudera意识到了亚马逊模式的威胁,在2016年曾经试图和英特尔沟通,让其投资Cloudera做云上的Hadoop服务,以便和亚马逊竞争。
|
||||
|
||||
然而,可能英特尔同时也是亚马逊的大主顾,亚马逊数据中心需要大量采购英特尔的硬件,又或者是英特尔自己并不想全面进入云计算这个领域,总之Cloudera没有获得足够的资金,这个计划就搁浅了。之后因为盈利不佳,融资不易,它只能自砍估值一半,流血上市。
|
||||
|
||||
在这次战争里,亚马逊笑到了最后,还有另外一个原因。亚马逊推出来的存储服务S3历史悠久,非常稳定,而Hadoop本身的文件系统HDFS则比较糟糕、效率很低。在亚马逊实现Elastic MapReduce的时候,对文件系统的处理,并非是基于HDFS的,而是把自己的S3作为存储系统,在上面实现了HDFS的接口而已。
|
||||
|
||||
面对一个非常稳定的文件系统,有无数的大小企业又都把自己的数据存在这个文件系统上,Elastic MapReduce相比原生Hadoop系统表现出了更高的效率、更好的性能,自然更受欢迎。加上亚马逊出了名的控制成本、定价便宜,其他Hadoop厂商要想在亚马逊的进攻下赚到钱,就比较艰难了。
|
||||
|
||||
微软的转型相对快一些。HDInsight就是微软的Hadoop云产品。它的文件系统也不再是简单的复用HDFS,而是在Windows Azure的存储上实现了HDFS的接口而已。
|
||||
|
||||
经过十年的发展,Hadoop所有在云上的版本,基本上都只是实现了HDFS的接口,却不用HDFS的完整实现,这是目前很多人觉得HDFS已死的原因。
|
||||
|
||||
另外,Hadoop早年实现的数据处理框架MapReduce,如今在整个生态圈里也被DataBricks主导的Spark打败,Spark已经成为通行的标准了。从这个角度来看,当年雅虎推出的那个Hadoop,经过这么多年的演变,很多东西都已经空心化,被新的技术取代了,留下来的只是接口。
|
||||
|
||||
数据处理框架的影响,从目前来看,比文件系统演变的影响要小。有一点很重要,就是亚马逊的Elastic MapReduce虽然取了这个名字,但其服务其实是提供了一个虚拟的Hadoop集群。既然是Hadoop集群,那么不跑MapReduce,而是跑Spark本身也不是问题。所以说名字可以欺骗人,但是数据处理框架的改变,一点都不影响亚马逊赚钱。
|
||||
|
||||
Hadoop三大发行商的空间,这些年里越来越被云厂商提供的Hadoop服务给占领了,所以它们的日子都不太好过。现在云厂商占领不了的那些,更多是不想上云,或者还没上云的传统企业。这些企业基于各种考虑,或者是数据安全的问题,或者是自身的IT能力比较弱,所以会选择三大发型商之一的版本。
|
||||
|
||||
在这三个版本里,HDFS被重写的MapR版本其文件系统相对稳定,性能更好;而其他两家的版本则基于老的HDFS。整体上看,MapR的版本在存储层可以提供更多的企业级特性,但是要确保和Hadoop生态圈的其他产品兼容却不太容易;Cloudera家大业大,目前可能拥有了最优质的线下客户资源;而Hortonworks暂时看不到任何优势。
|
||||
|
||||
在我看来,企业上云是必然趋势。但Cloudera和MapR需要新的盈利增长点,才能抵消企业上云带来的损失,否则长久来看,还是会逐渐走下坡路。而Hortonworks从技术和非技术的各方面表现来看,与竞争对手的差距很遥远,恐怕不出时日,日子就会不好过了。
|
||||
|
||||
|
||||
|
||||
|
||||
68
专栏/技术与商业案例解读/070谷歌的大数据路:从“三驾马车”到一无所有.md
Normal file
68
专栏/技术与商业案例解读/070谷歌的大数据路:从“三驾马车”到一无所有.md
Normal file
@@ -0,0 +1,68 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
070 谷歌的大数据路:从“三驾马车”到一无所有
|
||||
聊起西方文明,我们通常言必称希腊,古希腊有三大哲学家:苏格拉底、柏拉图和亚里士多德。而聊起大数据,我们通常言必称谷歌,谷歌有“三驾马车”:谷歌文件系统(GFS)、MapReduce和BigTable。
|
||||
|
||||
就像古希腊的哲学家照亮了西方文明一般,谷歌的“三驾马车”开启了大数据时代,并为我们指明了大数据的发展方向。
|
||||
|
||||
那么,大数据到底是从什么时候火起来的?这个问题并没有一个确切的答案,如果一定要说,2010年算是初现苗头。
|
||||
|
||||
但是,作为大数据时代开拓者的谷歌,它的“三架马车”远远早于2010年诞生:谷歌文件系统第一次公开发表的论文是在2003年,MapReduce公开发表的时间是2004年,而BigTable则公开发表于2006年。
|
||||
|
||||
谷歌的传统做法向来是先内部使用,等到下一代产品开发得差不多了,再发布这一代的产品。因此,谷歌的“三驾马车”在内部使用的时间更早。
|
||||
|
||||
这“三驾马车”,主要是为谷歌的核心搜索业务服务的。作为全球最大的搜索引擎,谷歌需要存储整个互联网的内容,并且要在这个内容的基础上构建倒排索引,这些都是基于“三驾马车”来实现的。
|
||||
|
||||
倒排索引是对互联网内容的一种索引方法,是指从搜索词到对应的互联网文档的索引方法。 用户可以通过搜索词去搜索互联网,返回的则是和搜索词相关的文档。之所以称为倒排索引,是因为文档到文档里面的词是顺序的,而从文档里面的词到文档是逆序的。
|
||||
|
||||
为了构建倒排索引,谷歌首先需要存储整个互联网的内容,并存储构建倒排索引所需的空间。而在当时的技术条件下,世界上是没有现成的产品可以实现这种倒排索引。所以,谷歌发明了谷歌文件系统,一个基于大量的廉价个人计算机的海量存储系统,它可以轻松地存储整个互联网的内容。
|
||||
|
||||
MapReduce则是谷歌构建第一代倒排索引的基础,它可以大规模并行地处理整个互联网上的所有文档,这是相当令人吃惊的。但是,这个索引构建方法有一个天然的缺陷:每次重新构建索引的时候都需要把整个索引全部推翻重来,而无法做到增量更新。而即使以谷歌的计算能力,重新构建一次索引也需要若干天的时间。这种做法最大的弊端是,新的突然更新的消息无法迅速融入到搜索引擎里。
|
||||
|
||||
而互联网内容变化的特点是,热点网站变化非常快,很多非热点网站却可能几个月如一日地没有内容更新。为了让索引的构建可以做到增量更新,即只更新有变化的网站,谷歌发明了BigTable。
|
||||
|
||||
BigTable是一个键值存储系统。 它可以存储一个主键的不同时期的多个版本的值,是谷歌代号为“咖啡因”的最新一代倒排索引引擎的核心。
|
||||
|
||||
在“咖啡因”构建倒排索引引擎里,因为BigTable这个键值系统的存在,互联网地址可以作为某个BigTable的主键使用,因此谷歌不必再把所有互联网地址全部推倒来重新构建索引,而只需要更新那些值已经发生变化的互联网地址。这样一来,网站上出现的新闻可以以秒级的速度被用户搜索到了。
|
||||
|
||||
当然,无论是存储还是数据处理的基础架构,适用性都不局限在构建索引上,这些技术渐渐在谷歌内部被广泛应用在其他很多方面。谷歌在发表这些技术的时候,也是把它们作为通用基础架构技术来发表的。
|
||||
|
||||
在其他方面的应用,最为著名的是谷歌对用户隐私数据的分析,这些分析促成了谷歌广告业务的蓬勃发展。业界广为流传的互联网模式是“羊毛出在狗身上,猪来买单”,而谷歌就是这个模式的开创者和第一个实践者。
|
||||
|
||||
具体来说,谷歌通过提供免费的互联网服务,比如搜索、邮箱、地图等,然后记录并分析用户的使用习惯,有针对性地为用户提供个性化的广告推荐服务。与此同时,谷歌把广告业务卖给其他企业。因为谷歌掌握了大量的数据,其广告推荐服务也非常地高效,所以企业主们愿意为这个服务支付高昂的广告费。
|
||||
|
||||
谷歌之所以可以做到个性化推荐,离不开这“三驾马车”:谷歌文件系统和BigTable用来存储和记录用户的隐私信息和产品使用情况,MapReduce用来分析海量数据。
|
||||
|
||||
简单来说,通过掌握“三驾马车”这一利器,谷歌具备了存储和分析海量数据的能力,其个性化广告系统就犹如永动的印钞机,不断地为谷歌赚取财富。这也正是谷歌带给全世界的互联网模式。
|
||||
|
||||
看懂这个互联网模式并不难,难的是除了谷歌,其他互联网公司并没有具备这样强大的数据存储、分析和处理能力。而谷歌并没有打算开放这些独家技术,也不打算通过售卖这些技术给其他互联网公司来赚钱。
|
||||
|
||||
这种模式赚钱如流水,因此其他互联网公司都趋之若鹜,希望构建同样强大的数据存储、分析和处理平台。“大数据”这个概念也因此被提出,从此作为一个产业开始爆发。
|
||||
|
||||
公允地讲,虽然谷歌扮演了大数据先驱者的角色,但是这个概念并不是它提出来的,而谷歌也从未真正通过给用户提供大数据分析平台服务的方式赚到钱,甚至在后来的Hadoop大数据开源社区里也毫无影响力。
|
||||
|
||||
除了谷歌,当时有众多互联网企业在诞生和发展,比如Facebook、LinkedIn,比如当时还如日中天的雅虎,又比如打算和谷歌在搜索领域竞争的微软。当这些公司意识到互联网前进的方向就是那个炙手可热的“大数据”概念,和这个概念下需要的海量存储和数据处理系统时,它们就需要面临艰难的抉择了。
|
||||
|
||||
有些公司,比如微软,对自己充满信心,决定像谷歌一样自己构建一套系统。有关微软这套系统的故事,我们会在后续的文章里继续讲解。有些公司,比如雅虎和Facebook,觉得凭借一己之力很难做到,于是开始抱团取暖,共同构建了后来闻名于世的Hadoop生态圈。
|
||||
|
||||
凭心而论,在很长一段时间里,Hadoop和谷歌内部的系统相比非常落后和不堪一击。然而,Hadoop这个毫无先进性可言的系统,凭借着人多力量大,竟也慢慢成长起来了。 这种成长包括两方面:
|
||||
|
||||
|
||||
一方面是,Hadoop的生态圈越来越大,用的人越来越多。越来越多的用户也在不断刺激着Hadoop的创新,这些创新导致Hadoop和谷歌的内部技术渐行渐远;
|
||||
另外一方面是,Hadoop因为用户多,成为了事实上的标准。
|
||||
|
||||
|
||||
待Hadoop成气候,受无数人和企业追捧的时候,谷歌那个很先进的“三驾马车”则彻底失去了先机。后来,谷歌开始做云计算,“三驾马车”作为云计算很重要的一部分,谷歌却需要为用户提供Hadoop或者类似Hadoop的服务。
|
||||
|
||||
其中一个服务叫作HBase,它是BigTable在Hadoop生态圈里的山寨版。当谷歌试图把自己内部真正的BigTable作为云服务提供给用户时,却不得不为Hadoop实现HBase这个山寨版的接口。本来自己是鼻祖,谷歌现在却必须兼容一个山寨版才能让用户买账,可想而知实现这些接口的程序员们内心肯定在滴血。
|
||||
|
||||
谷歌在大数据上,可谓“起个大早,赶个晚集”,最后一无所获。它给大家指明了方向,但是并没有开放它的系统,随后众多互联网公司们联合打造了Hadoop生态圈,并让Hadoop成为事实上的标准。在这之后,谷歌就彻底丧失了在大数据时代的先发优势。后来谷歌对外提供的云服务也不得不和这个Hadoop生态圈兼容。
|
||||
|
||||
在我看来,对于这样的结果,也只能怪谷歌自己在开放架构上太过保守了。
|
||||
|
||||
|
||||
|
||||
|
||||
76
专栏/技术与商业案例解读/071谷歌的大数据路:一场影响深远的论战.md
Normal file
76
专栏/技术与商业案例解读/071谷歌的大数据路:一场影响深远的论战.md
Normal file
@@ -0,0 +1,76 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
071 谷歌的大数据路:一场影响深远的论战
|
||||
在大数据发展史上有过一场非常著名的论战,这场争议影响深远,值得大书特书:其中一方是数据库领域的元老级人物迈克尔 · 斯通布雷克(Michael Stonebraker)和大卫 · 德威特(David Dewitt)。另外一方是主导了谷歌技术发展的杰夫 · 迪恩(Jeff Dean)。这两群人就谷歌“三架马车”之一的MapReduce和数据库到底谁好谁坏,争得不可开交。
|
||||
|
||||
在讲述这段故事之前,我先来介绍一下两方的人物。迈克尔是数据库领域的元老级人物,也是这场争议发起者。我们通常把数据库领域的人分为搞理论研究的和做数据库系统研究的两类,而迈克尔当之无愧是数据库系统研究领域最具影响力的人,没有之一。
|
||||
|
||||
迈克尔做过很多具有开拓性的事情,这里我就不再一一列举了,拣最最重要地来说。
|
||||
|
||||
迈克尔是第一个关系数据库系统Ingres的研发者,还是开源数据库系统Postgres最早的开发者。Postgres是目前开源数据库里面最具影响力的项目之一,只有MySQL勉强可以匹敌。
|
||||
|
||||
同时,迈克尔还是列存数据库C-Store,以及此后的商用版Vertica的开发者。他开发的系统,很多都被公司商业化了。
|
||||
|
||||
他还于2015年获得了图灵奖,迄今为止数据库领域只有4个人获得了这个奖项。他的学生更是遍布整个数据库领域的大学、政府、公司等等。
|
||||
|
||||
和迈克尔一同发起这场论战的大卫,曾经是美国威斯康辛大学的教授,退休之后被微软聘用,成为微软的技术院士。他同样也是数据库领域的元老级人物,最初的并行数据库系统和很多算法都是他提出来的。虽然和迈克尔比起来,大卫更加学术一些,但这丝毫没有影响到他在工业界的地位。
|
||||
|
||||
这场争论的另外一方人物是谷歌最牛、名气最大的工程师杰夫,他还是美国工程院院士,在谷歌内外都拥有庞大的粉丝群。他参与了谷歌多个重要项目的研发,为谷歌的基础架构研发做出了开创性和奠基性的工作。谷歌“三驾马车”中的MapReduce和BigTable,他都是主要的研发者和设计者,这场论战针对的MapReduce就是他最引以为傲的项目。
|
||||
|
||||
可以这样说,因为杰夫,谷歌才有了今天的高度。无论是早期基础架构研发的开创性工作,还是后期在人工智能方面的突破,没有杰夫,谷歌不一定能走这么远。但是,我们同样可以说,是谷歌成就了杰夫。因为,只有谷歌才有如此多的数据、计算机资源,和杰出的人才储备,可以让杰夫有足够的发挥空间和平台。
|
||||
|
||||
介绍完了相持不下的两方人物,我具体说说这场论战。这场针对MapReduce和数据库的争论在2008年1月17日爆发,这一天迈克尔、大卫以及朋友们联合发表了一篇长文“MapReduce:一个巨大的倒退”(MapReduce:A major step backwards),开始了对MapReduce的围剿。
|
||||
|
||||
这篇文章引起了广泛关注和讨论。首先,作者都是计算机行业赫赫有名的人物;其次,文章公然对谷歌宣传的新技术、伟大发明提出质疑。我们知道,这种质疑如果出自你我这样的“吃瓜群众”,谷歌当然不在乎。但如果是泰斗级的人物提出质疑,那就有如“平地一声雷”,每个人都要好好想一想了。
|
||||
|
||||
这篇博文的主要观点如下:
|
||||
|
||||
|
||||
MapReduce让人感觉像是生活在原始社会。使用MapReduce查询数据时还需要写很多的C++或者Java程序,而数据库系统在很多年前就发明了SQL语言,通过SQL语言本可以很方便地进行数据查询。
|
||||
MapReduce毫无效率可言。它并不是一个最优实现,现代数据库系统实现多年的性能优化(例如索引),在MapReduce里面都没有得到体现。
|
||||
MapReduce不具创新性。函数式编程语言很早就具备MapReduce的语言特性了。
|
||||
MapReduce不能兼容数据库系统用户已经依赖的所有工具,并且缺乏当前数据库系统拥有的大多数特性。
|
||||
|
||||
|
||||
客观地说,在我这个“吃瓜群众”看来,第一点“感觉像是生活在原始社会”的比喻其实不是问题。因为Hadoop生态圈里很快就出现了类似SQL的查询语言。如果有需要,谷歌也可以分分钟钟在MapReduce里面实现用SQL检索数据的功能。
|
||||
|
||||
第二点所说的“毫无效率”确实是问题,也是最为大家诟病的问题。后来,整个学术界和工业界围绕MapReduce的优化展开的各种工作,无非就是把分布式数据库领域里面实现了很多年的功能重新做了一遍。
|
||||
|
||||
至于第三点“MapReduce不具创新性”,有点儿道理,但也不是什么大问题。函数式编程里面的Map、Reduce和谷歌实现的MapReduce显然不是同一个概念,它们只是形似而已。而且,创新与否并不是衡量一个系统好坏的标准。
|
||||
|
||||
而第四点所说的“和现有数据库工具不兼容”,在我看来就多少有点牵强附会了。因为谷歌内部的系统完全可以形成闭环,不需要兼容外面的数据库工具。而且,和外部数据库的兼容也并不是什么大问题,开源的Hadoop社区很快就解决了这个问题。
|
||||
|
||||
其实,这篇博文最大的问题是,文中只提到了数据库比MapReduce好的方面,却没有说MapReduce的优势,因此表述太过偏颇。
|
||||
|
||||
相对于数据库系统来说,MapReduce最主要的优点是提出了在海量的普通廉价个人计算机上,进行稳定的大规模并行计算需要的技术,因为传统意义上的数据库系统都需要很高端的机器来完成同样的任务。
|
||||
|
||||
对于数据库系统来说,机器可以随时坏掉,但是系统却必须不间断地运行。因此,数据库系统必须要在稳定可靠的高端机器上运行,并进行冗余备份,来规避机器坏掉的风险。这就在无形中增加了数据库系统运行的成本,而MapReduce很好地解决了这个问题。
|
||||
|
||||
这场争论影响广泛,以至于数据库圈子里的很多人都开始站队。有支持甲方迈克尔和大卫的,也有支持乙方杰夫和谷歌的,还有“和稀泥”觉得双方都有道理的。这场争论更是持续了两年之久,“MapReduce到底是好是坏”也慢慢演变成为了学术圈的一个政治问题。
|
||||
|
||||
2009年,大卫在SIGMOD大会上发表了一篇论文:《大规模数据分析方法对比》(*A comparison of approaches to large-scale data analysis*)。论文比较了MapReduce在Hadoop开源社区中的实现和数据库系统的性能,并得出了数据库系统性能要好很多的结论。当时,我就在SIGMOD的现场,论文宣讲结束后,无数人质疑这篇论文的评价方式是否公平。
|
||||
|
||||
我印象最为深刻的是,数据库领域的知名学者拉 · 罗摩克里希纳恩(Raghu Ramakrishnan)当场就提出了质疑。他曾经和大卫同为威斯康辛大学的教授,不久前加入了雅虎研究院,并负责数据库研究工作。而雅虎是Hadoop的主导者,所以通常和大卫意见一致的他,这次却对这篇论文的内容表示了强烈反对。在我看来,这更多的就是政治立场的不同了。
|
||||
|
||||
更加不可思议的是,美国计算机协会ACM的重要刊物Communications of the ACM 也介入进了这场论战。这个杂志是美国计算机协会的会刊,通常刊登一些在计算机领域比较有影响力的文章。
|
||||
|
||||
2010年的第1期刊登了涉及这场争论的两篇论文:《MapReduce和并行数据库:是朋友还是敌人?》(MapReduce and Parallel DBMSs:Friends or Foes?)和《MapReduce:一个灵活的数据库处理工具》(MapReduce:A Flexible Data Processing Tool)。
|
||||
|
||||
虽然两篇文章都互相引用了对方的观点,但很大程度上还是自说自话。据我所知,这是Communications of the ACM 第一次刊登这种类型的文章,这也说明论战已经影响到整个计算机领域,不再仅仅局限于数据库的圈子了,可谓“一石激起千层浪”。
|
||||
|
||||
这场论战的深远影响还体现在,很多人都对这场论战的两方观点进行了认真思考,并希望可以扬长避短开发出更好的系统。但是,真正把从这场论战中得到的反思成功付诸实际行动的,就只有加州伯克利大学AMP实验室里的那群人了,他们发明了一个叫作Spark的计算引擎。
|
||||
|
||||
Spark项目的重要负责人之一迈克尔 · 富兰克林(Michael Franklin)在2017年的国际数据库顶级会议VLDB (International Conference of Very Large Data Base)上做了一个主题演讲:《大数据软件路在何方》(Big Data Software: What’s Next? ),主要内容就是“Spark是如何诞生的”。
|
||||
|
||||
在主题报告上,他提到了这场论战,当时整个AMP实验室的教授们都在思考这两方到底谁更有道理。经过非常深入地思考和论证,AMP实验室的教授们决定吸取MapReduce和数据库系统两方的精华,同时抛弃这两方不合理的地方,从头开始构建一个大数据计算引擎。于是,Spark在这样的背景下诞生了。
|
||||
|
||||
目前来看,Spark非常得成功。它既不是数据库,也不像MapReduce。在某种程度上来说,Spark是两者的结合,又有自己的创新。现在,Spark归属于这群人的创业公司Databricks,有关Spark和Databricks的故事我会在这个系列后续的文章里详细讲解。
|
||||
|
||||
这次针对MapReduce和数据库的大论战,最后伴随着Spark的诞生也就有了结果。
|
||||
|
||||
|
||||
|
||||
|
||||
75
专栏/技术与商业案例解读/072谷歌的大数据路:谷歌的“黑科技”.md
Normal file
75
专栏/技术与商业案例解读/072谷歌的大数据路:谷歌的“黑科技”.md
Normal file
@@ -0,0 +1,75 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
072 谷歌的大数据路:谷歌的“黑科技”
|
||||
谷歌的大数据之路,上半场以“三驾马车”(谷歌文件系统、MapReduce和BigTable)开始,却以被Hadoop开源生态系统全面山寨了自己的“三驾马车”而结束。
|
||||
|
||||
此后,开源社区不断推陈出新,推出了连谷歌都没有的开源项目,并将其融入了Hadoop生态系统。从此,Hadoop生态系统成为了大数据领域事实上的标准,而谷歌也不得不在自己的云计算平台上提供对Hadoop开源山寨项目的兼容性支持。
|
||||
|
||||
最终,在大数据的上半场,随着Hadoop生态圈的崛起,谷歌在大数据领域的影响力荡然无存。
|
||||
|
||||
然而,谷歌也不是吃素的。在大数据的下半场,谷歌携带“黑科技”Spanner数据库系统闪亮登场了。 在讲这个“黑科技”前,我们先来看看谷歌“三驾马车”里的BigTable。虽然BigTable名字里面包含了“Table”,但实际上它并不是一个数据库的表,它只是一个键值存储系统(即Key-Value Store)。
|
||||
|
||||
一方面,BigTable虽然可以处理大规模高并发的查询,但是这个查询功能并不好用。在BigTable中用户无法使用SQL进行数据查询,而必须采用编程的方式,这就导致数据查询的用户体验非常不好。因此,应用程序开发者更愿意选择用他们熟悉的数据库系统,通过SQL完成数据访问和查询。
|
||||
|
||||
另外一方面,虽然谷歌的搜索系统构建在“三驾马车”上,但广告引擎并不是。在很长一段时间里,谷歌的广告引擎都是采用开源的关系数据库MySQL。但是随着谷歌业务的发展,MySQL越来越无法支撑谷歌广告业务的发展。
|
||||
|
||||
基于以上两方面的诉求,谷歌需要再开发一个数据库系统,这个系统既要有BigTable处理大规模高并发查询的能力,又要能够支持SQL查询和事务处理。这个系统就是今天的主角,后来赫赫有名的“黑科技”Spanner:谷歌的跨洲多数据中心的数据库。
|
||||
|
||||
那么,Spanner到底是什么呢?
|
||||
|
||||
|
||||
首先,它是一个数据库,支持SQL查询,类似于Oracle或者微软的SQL Server,以及开源的MySQL、Postgres等。
|
||||
其次,Spanner跟其他数据库系统最大的不同是,它支持把数据存储在谷歌全球各地的不同的数据中心里,并且对这些数据进行查询。同时,它还能够保证这些跨洲多数据中心数据的一致性。
|
||||
|
||||
|
||||
目前这个系统,全球只此一家别无分号。有传闻说,亚马逊屡次试图实现Spanner这样的系统,但是屡战屡败,屡败屡战,现在依旧没有什么进展。
|
||||
|
||||
众所周知,时间问题是分布式系统里面最难解决的问题。 每台机器上细小的时间差别,反应到全局的结果就是没有统一的时间观念。
|
||||
|
||||
在同一个数据中心,通过时间同步协议定期对所有机器进行时间同步,这个时间问题就可以迎刃而解了。但是,一旦数据中心跨洲后,通过同步协议进行定期更新的做法就不切实际了。因为,利用同步协议更新跨洲数据中心的时间所要耗费的时间本身,就已经可以产生了不可忽略的误差。而Spanner被称为“黑科技”的原因之一就是,它开创性地采用了原子钟和GPS全球定位系统,从而解决了这个跨洲的全球数据中心的时间同步问题。
|
||||
|
||||
在最开始,谷歌只做了Spanner的存储层实现,虽然解决了全球数据中心的时间同步问题,但是并不能满足谷歌广告引擎业务的需要。主要原因是,在Spanner中存储层的访问需要使用底层的API,而广告系统是通过SQL访问MySQL集群的,这是一种高层的数据访问查询方式。而这时,谷歌将广告系统从MySQL集群迁移出来的需求也不断增长,于是就专门组建了一个技术团队,这个团队的任务就是基于Spanner的存储层开发一个新的数据库系统F1。
|
||||
|
||||
最终,F1研发成功了。F1的成功主要体现在两个方面。
|
||||
|
||||
|
||||
首先,F1是一个完整的数据库,可以兼容MySQL,广告部门基本上不需要改代码就可以通过SQL访问F1数据库。
|
||||
其次,F1的扩展性非常好,可以进行任意的扩展,包括跨地域的扩展,因此广告部门再也不需要因为流量的增加而手动扩展MySQL集群了。
|
||||
|
||||
|
||||
因此,谷歌终于有了属于自己的跨地域的全球性数据库。这个数据库提供了极大的便利性,从此谷歌的广告业务终于可以脱离MySQL了,谷歌也因此获得了许多新的收入。
|
||||
|
||||
然而,虽然F1系统解决了谷歌广告业务受制于MySQL的问题,但是这个系统有一个最大的问题:它完全是为谷歌的广告业务定制的,也因此无法应用在谷歌的其他项目上。
|
||||
|
||||
比如,F1数据库把表按照广告客户ID进行分区,数据在这些静态分区之间没法进行迁移。其他的项目都有自己的数据库表方式,而改造成F1数据库表方式是一个非常巨大的工作量,这也就导致了非广告业务无法实施在F1数据库系统上。
|
||||
|
||||
这时,谷歌内部对构建一个通用的数据库系统的诉求愈发强烈。一方面,F1数据库和广告业务紧紧耦合,且F1的团队也没时间做解耦来消除这种局限性;另一方面,Spanner团队发现他们需要在存储层上开发一些新的东西。
|
||||
|
||||
在这样的背景下,Spanner团队开始自己做执行层的开发。这样一来,Spanner被开发地越来越像是一个完备的数据库。经过几年的演变以后,Spanner最终成为了一个完备的数据库。
|
||||
|
||||
这样,谷歌内部就有了两套基于Spanner存储层的数据库了:Spanner团队自己开发的和广告组开发的F1数据库。 这两套系统在谷歌内部开展了广泛的竞争,最终的结果就是:非广告业务都采用Spanner组开发的系统,而广告业务部则用F1。而在外界,很多人被谷歌这两套系统搞蒙了,大家一直误会F1和Spanner是同一个产品,但事实上它们是功能和适用范围都不同的两个系统。
|
||||
|
||||
|
||||
F1开发得比较早,是针对广告部门定制的数据库系统。这个系统在广告相关业务上性能非常好,但缺失了很多支撑其他业务必要的功能,所以通用性很差。
|
||||
Spanner团队则开发了一个通用的数据库系统,具备了数据库系统的所有功能。但是这个系统没有专门针对广告业务进行优化,因此应用在广告系统上的性能要差一些。
|
||||
|
||||
|
||||
虽然有这些小插曲,但是自从有了Spanner,谷歌的底气就不一样了。这个黑科技支持的数据库,使谷歌第一次做到了进行全球范围的事务处理,这确实是史无前例的。鉴于开放“三驾马车”架构时的保守性,让谷歌丧失了在大数据时代的先发优势,这次谷歌决定把Spanner放到云上供大家使用,并将其命名为Cloud Spanner。
|
||||
|
||||
谷歌试图通过Cloud Spanner这个高大上的“黑科技”来推动云端大数据产品的销售,但是却没有达到预期效果。在我看来,Cloud Spanner发展不顺利的原因主要有两个:
|
||||
|
||||
|
||||
Spanner收费非常昂贵,对用户来说不够经济实惠;
|
||||
大部分用户都没有谷歌那么大的数据量,跨大洲、跨大洋的数据库功能对他们来说,多少有点华而不实。
|
||||
|
||||
|
||||
虽然Spanner在云端客户上发展并不顺利,但是有些情况也只有Spanner这样的数据库才可以从容应对。比如,中国的金融行业需要两地三中心的架构,这种架构目前主要通过高端机器实现。即便如此,金融机构也无法避免真正可能发生的灾难。但是,如果换成Spanner,金融机构不但能够更好地自动应对故障的发生,而且可以降低成本。
|
||||
|
||||
无论结果怎样,Spanner让谷歌再次在大数据领域吸引了很多关注。谷歌通过无与伦比的技术实力告诉大家,它才是大数据技术真正的推动者。但是Spanner这个“黑科技”也只对谷歌这种规模的数据有现实意义,而对其他企业来说并不是刚需。所以,Spanner终究还是落得了“叫好不叫座”的结局。
|
||||
|
||||
|
||||
|
||||
|
||||
66
专栏/技术与商业案例解读/073如何读懂类似谷歌“三驾马车”这样的技术论文?.md
Normal file
66
专栏/技术与商业案例解读/073如何读懂类似谷歌“三驾马车”这样的技术论文?.md
Normal file
@@ -0,0 +1,66 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
073 如何读懂类似谷歌“三驾马车”这样的技术论文?
|
||||
在信息化时代,技术发展日新月异,知识更新的速度也是越来越快。以前我们可以安安稳稳地坐在教室里,等到一本写得不错的教材出来,再去系统地学习知识。而现在,我们却必须选择去读那些最新发表出来的技术论文,因为只有这样才能赶得上时代发展的潮流。
|
||||
|
||||
作为互联网行业的软件从业人员,能不能读懂论文,是一项可以决定自己发展潜力的必备技能。
|
||||
|
||||
然而,读懂论文并不容易,这比读懂一本书要难多了。在我看来,读懂一篇技术论文是需要技巧的。
|
||||
|
||||
作为一个美国大学毕业的PhD,曾先后在各种顶级会议和期刊上发表过十几篇论文的作者,我觉得可以从论文写作的角度,跟你谈一谈论文和教科书的区别,帮助你理解怎么读论文才是一个相对正确而又省力的过程。
|
||||
|
||||
要理解为什么技术论文难以读懂,你首先要弄明白一个问题:论文到底是写给谁看的?
|
||||
|
||||
目前发表在顶级期刊或者会议上的论文,包括非常经典的谷歌“三驾马车”的论文,都是为了给这个领域的专家看的,而不是要写给广大程序员看的。因此,这些论文也就不太可能普遍照顾到程序员的理解能力。
|
||||
|
||||
关于作者在写作论文时会预先设定目标读者这一点,我们可以从以下两个方面来理解。
|
||||
|
||||
|
||||
顶级期刊或者会议发表的论文都是需要经过同行评审的。同行评审是很关键的一步,论文能否录取,往往取决于跟你处在同一个水平或者更权威的专家对论文内容的判断和评价。所以,论文首先就是写给同行专家看的,否则是无法通过同行评审这一关的,那论文发表又从何谈起呢?
|
||||
论文发表的目的是什么?其实,发表论文的目的有很多。在学术界,发表论文就是工作的一部分,目的就是宣示你做了很多、很有影响力的研究;在工业界,发表论文的目的就更多了,但树立自己在业界的领先地位这一点是毫无疑问的。
|
||||
|
||||
|
||||
理解了“论文到底是写给谁看的”这个问题,我们再来看下一个问题:论文通常都是怎么写出来的?这是个非常复杂的问题,我会一点一点地分解剖析。
|
||||
|
||||
首先,论文作者对同行的知识结构是有假设的。 和教科书非常不同,论文作者首先会假设同行对这个领域的基础性研究和相关知识都已经非常熟悉了,因此只在非常必要或者特殊情况下才会去介绍特定的知识。而在大部分情况下,论文作者给出一个引用已经是很奢侈的事情了。这意味着什么呢?如果你连这个领域的基础知识都不懂,是没有办法一上手就读懂论文的。
|
||||
|
||||
举个例子,如果你去看大数据基础架构的论文,比如谷歌的“三驾马车”的论文,倘若你连最基本的分布式系统知识都没有,那无异于是“小孩子读微积分”;倘若机器学习的知识你一点儿都不懂,那一篇讨论深度学习的论文对你来说,无异于“天书”。
|
||||
|
||||
因此,作为一个读者,你能不能读懂一篇论文,直接取决于你自己在这个领域中的基础知识积累。所以,想要有阅读论文的能力,首先要把基础知识补好。
|
||||
|
||||
其次,论文里面的内容都是“化了妆”的。 学术圈有一个基本规则,简单地说就是:不可以在论文里面说谎。然而,“不说谎”不代表作者要把自己做的系统的方方面面都说出来,换个说法就是:作者可以对系统的缺点轻描淡写,能简单就简单;而对系统的优点和先进性大书特书,极力营造为“天上没有,人间极品”的效果。因此,在不违背基本原则的前提下,作者在论文里有选择性地写作,是学术圈里公认的套路。
|
||||
|
||||
这就意味着,读者要带着批判性去读论文,而不能按照读教科书的思路去读。教科书的作者在写作时一般都会做到客观公正、深入浅出,而这很显然不是论文作者的写作方法。 因此,对于作者语焉不详的地方要多问几个为什么,对于作者自夸的地方要认真思考一下是不是真的牛。其实,这些都是读懂论文的基本功。
|
||||
|
||||
那这种基本功从何而来呢?总结起来,我觉得可以从以下三个方面来获得这些基本功。
|
||||
|
||||
|
||||
自己撰写论文,然后努力发表。 这个办法比较奢侈也比较痛苦,而且见效较慢。但是一旦成功,效果往往是其他办法不能比的。即便没有成功发出论文来,你也可以从论文的写作过程中学到很多知识。
|
||||
所以,在有条件发表论文的情况下,一定要不惜代价地尝试。即使最后一篇论文也没发出来,但这种尝试也绝对有好处。最明显的好处就是,可以帮助你理解论文写作过程中要展现好的一面、掩藏坏的一面,理解作者在论文中没写的那部分到底是什么。
|
||||
找到两篇可以比较的论文:后者引用前者,和前者的方法进行比较,并在前者的基础上有所提高。 这时,你可以拿着前者的文章,看看作者是如何“吹牛”的、又是如何避免谈缺陷的,而后者又是如何表明自己弥补了前者不足的。通过比较前后两篇论文的内容,可以有效地提高你用批判性思维阅读论文的能力。
|
||||
但是,这个方法对系统性的文章,比如谷歌的“三驾马车”这类的文章,不是特别适用。主要原因是,这类文章表述的系统往往是从无到有的原创性系统,也只有谷歌这样的大型科技公司才有能力去开发这样的系统。一般来说,是无法找到可以相比较的文章的。
|
||||
一定要认识到论文中一般只交代作者成功的故事,而对于成功背后无数次失败的尝试这样的内容绝少出现。 这就意味着,你看到的只是作者成功的解决方案。有过基础研究的人很清楚地知道,任何一篇论文背后都隐藏着无数次失败的尝试。对于系统论文、大数据论文,这个规律依然适用。
|
||||
比如,在微软、百度、阿里巴巴做过类似于谷歌“三驾马车”的系统开发人员,这些人虽然还没有成功,但是经历了多次类似的失败,已经足够体会到经验背后的教训了,因而可以比较轻松地读懂这些论文。而对其他没有类似体验的人来说,就很难了。
|
||||
|
||||
|
||||
所以有些论文你读不懂,其实是因为论文中缺乏对系统研究过程中失败尝试的描述,而你也没有过开发类似系统的体验。因此,从这个角度来讲,最能读懂论文的,往往都是那些从事过类似系统开发的人。
|
||||
|
||||
关于这一点,我认为比较好的解决办法只有两个。
|
||||
|
||||
|
||||
加入一个团队进行类似的系统开发,毕竟“纸上得来终觉浅”。
|
||||
找到这篇论文在各大网站上的相关解读,以及论文作者此后演讲的相关材料,这些资料往往是帮助你理解论文的最佳途径。在这些演讲材料中,作者往往会更自由地分享一些成功的经验、失败的教训。而在论文发表时,因为同行评审等压力,往往会有所忌讳,所以不会分享的太全面。
|
||||
|
||||
|
||||
写到这里,我需要特别指出一类比较特殊的论文,就是综述性质的论文。这种论文,往往是由业界大佬就这个领域在某段时间内的所有研究工作汇总而成,是最接近教科书的论文。
|
||||
|
||||
除了阅读综述性论文以外,你还可以参加一些行业的顶级会议。这些顶级会议除了论文宣讲,还会邀请行业大佬举行一些综述性质的讲座。这些讲座的内容往往更客观公正、逻辑性更强,也比较像教科书,更容易被听众理解。但是,这些讲座通常不会被发表成论文,只有现场的参会人员才可以听到。
|
||||
|
||||
总结来讲,论文难懂是正常情况。要想读懂论文,你需要明白论文是写给谁看的、是怎么写的。作为读者,你首先要提高自己的领域基础知识,然后明白论文的一些基本套路,这会让你在阅读论文时更容易读懂、更有收获。最后,综述性质的论文很像教科书,特别适合用于特定领域的入门。
|
||||
|
||||
|
||||
|
||||
|
||||
57
专栏/技术与商业案例解读/074雅虎:大数据领域的“活雷锋”.md
Normal file
57
专栏/技术与商业案例解读/074雅虎:大数据领域的“活雷锋”.md
Normal file
@@ -0,0 +1,57 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
074 雅虎:大数据领域的“活雷锋”
|
||||
在谷歌崛起之前的很长一段时间里,雅虎一直是互联网行业的“老大哥”。 虽然随着互联网行业的发展,谷歌的市场影响力越来越强,雅虎的日子越来越不好过,但雅虎仍是“瘦死的骆驼比马大”。谷歌发表了“三驾马车”的论文,开启了大数据时代,雅虎作为当时互联网行业的老大,也希望能用上类似“三驾马车”的系统。
|
||||
|
||||
鉴于和谷歌在广告市场上的直接竞争关系,雅虎不可能从谷歌那里获得基础架构并用在自己的业务上,而且谷歌也没有要开放自身架构的意思,因此雅虎决定自己开发一套。说到这里,就不得不说说道格 · 卡丁(Doug Cutting)了。
|
||||
|
||||
当时,卡丁在做一个叫作Nutch的网页爬虫项目,但是这个项目开发得并不顺利,主要问题是当爬虫达到一定规模后无法稳定地运行在更多的机器上。
|
||||
|
||||
这时,谷歌文件系统和MapReduce的论文相继发表了,卡丁从这些论文里面受到了启发。他认为谷歌文件系统和MapReduce可以解决Nutch项目遇到的问题,于是就在Nutch上实施了谷歌文件系统和MapReduce工具,果然重新实现后的Nutch很容易稳定运行在更多的机器上了。
|
||||
|
||||
而当时雅虎正在思考如何构建自己的基础架构,于是这个项目自然而然地进入了雅虎的视野。
|
||||
|
||||
2006年,雅虎聘用了卡丁,随后专门组建了Hadoop开发团队,并投入了大量的技术人员和机器资源来支持项目的开发、调试和落地。雅虎对Hadoop项目注入的人力和物力资源支持,奠定了Hadoop项目从简陋向完善发展的基础。
|
||||
|
||||
Hadoop团队的最高领导者是位副总裁,雅虎很多核心业务部门的最高领导的等级也不过如此,借此不难看出雅虎当时对Hadoop开发部门的重视程度。
|
||||
|
||||
不但如此,为了保证Hadoop项目能够顺利落地,雅虎把内部的很多数据处理业务迁移到了尚不成熟的Hadoop项目中。这种用实际业务促进项目成长的“小白鼠”精神,非常有效地帮助了Hadoop向成熟产品的转变。
|
||||
|
||||
接下来,我来讲讲Hadoop的具体发展进程。
|
||||
|
||||
2006年2月,卡丁决定从Nutch项目里将对谷歌文件系统和MapReduce的实现分离出来,并决定用他儿子的玩具命名这个项目:Hadoop。两个月后,Hadoop实现了第一个具有里程碑意义的计算:用48小时在188台机器上完成了对1.8 TB数据的排序。
|
||||
|
||||
这里所说的里程碑,并不是说这件事情有多伟大,而仅仅是证明了基于谷歌文件系统和MapReduce实现的架构,是一个相对通用的系统。这个系统除了可以用在Nutch上做爬虫应用外,还可以实现数据排序。
|
||||
|
||||
而这个数据排序的效率到底是高是低呢?现在我用C++随便写一个程序,运行在一台普通电脑上为1.8 TB的数据进行排序,而且这个排序绝对花不了48小时的时间。但是,当时Hadoop却需要用188台机器花费48小时来完成这个排序。
|
||||
|
||||
这里需要说明的是,对分布式系统来说,单机效率固然重要,但能够稳定运行在多少台机器上同样重要,而且实现起来更加困难。
|
||||
|
||||
到2006年5月,雅虎的Hadoop团队已经有了一个300台机器的集群。同年10月,这个集群达到了600台机器的规模 ,而这基本上接近了当时Hadoop可以实现的极限。整个Hadoop团队又花了差不多大半年的时间,才在2007年上半年实现了Hadoop在1000台机器上的稳定运行。这样的集群规模,终于可以让Hadoop存储和处理互联网级别的数据了。
|
||||
|
||||
2008年,Hadoop可以稳定运行了。正是这一年,雅虎决定把自己搜索引擎的倒排索引的构建工作迁移到Hadoop上。因为伴随着互联网内容的增加,在手工实现的系统上构建的倒排索引,再也无法处理越来越多的内容。
|
||||
|
||||
谷歌最初发明MapReduce的目的就是为自己的搜索引擎构建倒排索引,所以Hadoop一旦足够稳定,雅虎必然会将自己的倒排索引构建工作迁移到Hadoop上。这个处理雅虎倒排索引构建工作的Hadoop集群,规模大约在2000到3000台机器之间,这也是当时最大的Hadoop集群。
|
||||
|
||||
2009年,雅虎的很多业务都开始迁移到Hadoop上。为此,雅虎部署了很多个Hadoop集群,总机器规模超过两万台。
|
||||
|
||||
可以说,2006年到2009年是Hadoop项目发展最为关键的三年。在这三年的时间里,雅虎不但从人力上和机器上给予了Hadoop大量的支持,更重要的是逐渐把自己内部的很多平台都过渡到Hadoop上。 如果没有雅虎的这些大力支持,也就不会有Hadoop在2009年的成熟程度。
|
||||
|
||||
如果说,雅虎为了发展自己的业务在Hadoop项目上投入了如此多的资源,是情理之中的事情,那么雅虎毫无保留地把Hadoop相关的源代码全部开源出来,就必须说是扮演了一个“活雷锋”的角色了。因为雅虎无私地开源了Hadoop系统,其他比如LinkedIn和Facebook等互联网公司才有可能加盟进来。
|
||||
|
||||
除了Hadoop的核心系统以外,雅虎对Hadoop生态圈还有两个比较大的贡献:ZooKeeper项目和Pig项目,它们对Hadoop生态圈的发展产生了非常重要的影响。
|
||||
|
||||
ZooKeeper是一个分布式系统的协调服务,主要用来解决分布式应用中经常遇到的一些数据管理问题。它是很多Hadoop生态圈的其他项目(比如,谷歌BigTable的大数据开源版HBase)里面分布式协调部分的代码的基础。
|
||||
|
||||
Pig是第一个基于Hadoop的高级语言,它的脚本被编译成一系列的MapReduce任务来执行。Pig第一次让用户摆脱了烦琐的MapReduce,可以用高级语言去写任务,这就像是计算机从早期的汇编语言阶段过渡到了高级语言阶段。
|
||||
|
||||
现在十年多的时间过去了,Zookeeper作为一个基础组件,不断地演进,至今依然是Hadoop生态圈里最重要的一个基础组件。Pig则渐渐地被后来居上的高级语言,比如Spark和Flink,取代了,就像是COBOL被C、C++、Java等更高级的语言取代一样。
|
||||
|
||||
总结来说,如果当初没有雅虎对Hadoop项目的鼎力支持以及无私开源,我们很难想象会有今天如此繁荣昌盛的Hadoop生态圈。尽管雅虎作为一个实体公司已经不存在了,尽管我们也不知道当初雅虎为什么要如此无私地开源Hadoop,但我们都应该感谢它对Hadoop多年如一日的无私奉献。
|
||||
|
||||
|
||||
|
||||
|
||||
47
专栏/技术与商业案例解读/075IBM的大数据路之起早贪黑赶了晚集.md
Normal file
47
专栏/技术与商业案例解读/075IBM的大数据路之起早贪黑赶了晚集.md
Normal file
@@ -0,0 +1,47 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
075 IBM的大数据路之起早贪黑赶了晚集
|
||||
IBM是一家曾经有过无比辉煌历史的计算机公司,如今却时过境迁,对计算机发展的影响力所剩无几。
|
||||
|
||||
进入大数据时代后,IBM的路走得格外辛苦。IBM踏上大数据道路的早期我正好在IBM实习,也因此接触到了很多外人不知道的内容。
|
||||
|
||||
那是2008年,Hadoop刚刚开始兴起,雅虎正投入大量人力物力进行Hadoop核心模块的开发。我实习的部门是IBM Almaden研究院,这个研究院以研究数据库相关技术出名,历史上第一个关系数据库的原型系统System R就诞生于此。
|
||||
|
||||
当时我们组需要在Hadoop上开发两个外围项目。其一是做一种高级查询语言JAQL(JSON Analytical Query Language),它以JSON作为数据模型,语法上更像是一个数据流语言。另外一个项目则是基于JSON做一个搜索引擎。
|
||||
|
||||
2008年旧金山湾区有Hadoop聚会的时候,演讲内容一般针对的是Pig、Hive、JAQL,由此可见JAQL在当时也是颇有建树的。可以说,IBM很早就进入了Hadoop生态圈,而且有一个类似Pig或者Hive的查询语言的项目。从数据模型来看,JSON也是非常有特色,那为什么好好的一盘棋下着下着就输了呢?
|
||||
|
||||
在我看来,IBM的官僚作风是一个很重要的原因。 虽说下面有团队在做这件事,但是领导层的重视程度并不够。当时这个团队只有一个领导、两个兵,而且其他资源也是远远拼不过其他公司的。
|
||||
|
||||
第二个原因,是IBM对待开源自己项目的保守态度。 Hadoop本身是个开源项目,但是想要IBM开源JAQL项目是一件非常不容易的事情。当时的团队负责人尤金 · 谢基塔(Eugene Shekita)为此付出了很多努力,但仍是进展缓慢。
|
||||
|
||||
后来IBM终于把JAQL开源了,但并没有同意把它捐献给Apache软件基金会,JAQL也就没能成为Apache的顶级项目。这样一来,其他非IBM的人想要参与进来就很困难了。JAQL的用户数量也因此受到了影响,难免显现出一些衰败的迹象,最终直接影响了团队士气,团队成员纷纷跳槽,只留下了老板尤金孤掌难鸣。后来尤金跳槽去了谷歌,这个和大数据、和Hadoop相关的技术研发也就嘎然而止了。
|
||||
|
||||
此后,IBM决定不再开源JAQL,而是把它整合到自己的产品中,并且不再允许其他公司使用,这种做法是以开源为主体的Hadoop体系完全无法接受的。慢慢地,JAQL系统就淡出了Hadoop的圈子,最终变得无足轻重了。
|
||||
|
||||
在大数据领域,IBM研究院另外一个重要项目是机器学习平台System ML,这个项目始于2010年,也是比较早的。 但是,这个项目同样也不是开源的,所以虽然大家从论文里面知道了这个项目,但是却不知道它是怎么做出来的,自然也就无法在这个项目上进行开发了。
|
||||
|
||||
在大数据的道路上,IBM因为自产自销的原因越走越窄,后来不得不做出一项重大决策:采用哪种平台继续前进。这次IBM的决定是全面倒向Spark。
|
||||
|
||||
Spark是加州伯克利大学AMP实验室研发的产品,后来又经过Databricks公司不断地产业化,在数据分析和处理引擎领域已经有一统天下的倾向。
|
||||
|
||||
IBM决定全面倒向Spark以后,内部的各种分析工具也都要从原先的平台迁移到Spark上。
|
||||
|
||||
从某种程度上来说,IBM早早地就开始了Hadoop相关技术的研究,但最终却决定放弃自己对底层开发的积累,使用一个别人开发的、比它还要晚的平台。对于“百年老店”IBM来说,或许这个选择在商业上可以理解,但不管怎样看,这都不是一个好兆头。
|
||||
|
||||
倒向Spark后,整个System ML项目要基于Spark重新开发。作为支持Spark生态系统的一部分,在2015年的Spark Summit上,IBM宣布将System ML开源。这个决定自System ML项目开始已经过去5年了,而就外界所知道的System ML也已经经历了两大版本的变迁。
|
||||
|
||||
经过一年多的孵化,System ML终于在2017年夏天成为了Apache的顶级项目,这也算是IBM主导的第一个Apache顶级开源项目。但在机器学习和深度学习大行其道的今天,System ML到底还能产生多大的影响,要打一个大大的问号。
|
||||
|
||||
作为一个老牌的计算机公司,IBM眼光向来都不错。 在Hadoop刚兴起时,就进行了相关的研究。而且,行动力一点也不比其他互联网企业和社交媒体来得差。
|
||||
|
||||
但是,虽然IBM早早地就进场了,项目做得也不差,人员素质更是不低,一切却都架不住官僚体系的腐朽和不开源的偏见。IBM内部官僚主义太重,虽然有团队在做Hadoop的相关技术研发,但上层的重视程度不够。更重要的是,凡是涉及了开源的问题,IBM都毫不犹豫地选择了拒绝,这更让IBM失去了很多机会。
|
||||
|
||||
可以说,那个曾经为计算机发展做出过卓越贡献、始终走在历史发展前列的计算机公司,“蓝色巨人”已经死了。在Hadoop市场和大数据领域的错失,究其原因还是这个企业早就是垂垂朽已了。对此,除了一声叹气,我又能说些什么呢。
|
||||
|
||||
|
||||
|
||||
|
||||
69
专栏/技术与商业案例解读/076社交公司们的大数据贡献.md
Normal file
69
专栏/技术与商业案例解读/076社交公司们的大数据贡献.md
Normal file
@@ -0,0 +1,69 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
076 社交公司们的大数据贡献
|
||||
在Hadoop诞生初期,雅虎扮演了“活雷锋”的角色,几乎凭借一己之力撑起了整个Hadoop系统的发展。2006年雅虎把Hadoop开源以后,其他公司渐渐加入了Hadoop生态圈,其中三大社交公司Facebook、LinkedIn和Twitter的加入,为Hadoop生态圈的繁荣发展做出了巨大贡献。
|
||||
|
||||
一、Facebook对Hadoop生态圈的贡献
|
||||
|
||||
最先加入雅虎Hadoop项目里的是还在创业阶段的Facebook,它从2008年开始在内部使用Hadoop。因为用MapReduce做数据分析需要写很多C++或者Java程序,这非常不方便,因此Facebook决定做一个叫作SQL on Hadoop的项目,也就是后来鼎鼎大名的Hive。 这个项目的目标是,要在Hadoop上搭建一个可以用类似SQL进行数据查询、分析的应用。
|
||||
|
||||
最开始的时候,Facebook内部专门成立了一个Hive团队,后来团队成员从最初的两个人扩展到六个人。这时,Hive项目只是Facebook一个公司在开发和推广。
|
||||
|
||||
Hive的开发风格体现了Facebook的特色:快、糙、猛。Hive开发者的代码写得很快,因此Hive的代码质量是所有开源软件里面相对比较粗糙的:Bug比较多,且维护难度大,但基本上实现了所有必需的功能。如果说在没有遇到Bug且不需要维护的情况下,Hive还是可以凑活着用的。
|
||||
|
||||
但Hive后来的发展走向不再是Facebook来主导了,究其原因有以下两个。
|
||||
|
||||
|
||||
Facebook不断撤出对Hive的投资。一方面,Hive团队纷纷出走;另一方面,Facebook把开发重心转移向另外一个新的内部工具Presto。Presto后来也被Facebook开源,并被包括Airbnb、美团、京东等诸多企业采用。
|
||||
这种变化的主要原因是Facebook内部的赛马机制,Presto团队在产品上取得了胜利,从而可以获得越来越多的资源。而Hive团队获得的资源越来越少,无法再支撑其继续发展。
|
||||
Hive是最像SQL语言的,也是最方便的,因此,Hadoop的发行商们纷纷加入Hive项目的开发和维护,这其中对Hive最为青睐的就是Cloudera和从雅虎出来的Hortonworks。所以,2011年以后Hive项目就渐渐地由Facebook主导变成由这两个公司主导了。
|
||||
|
||||
|
||||
Facebook的另外一个贡献是,开源了NoSQL数据库项目:Cassandra。 Cassandra项目最初是由Facebook开发的,其实是效仿了亚马逊的Dynamo。但后来Facebook却转投了HBase的怀抱,而任由Cassandra自生自灭。
|
||||
|
||||
这个决定是当时Facebook的一位高管做的,具体是哪位高管无从查证,但这个决定背后的动机很明显,因为Facebook觉得谷歌的架构(HBase是谷歌BigTable的山寨版)更可靠,而对亚马逊的架构信心不足。
|
||||
|
||||
Cassandra的发展因此出现了一段时间的停滞,直到DataStax接手Cassandra项目。有关Cassandra的故事,我会留到讲DataStax的时候再详细介绍。
|
||||
|
||||
而Facebook投奔的HBase,也是Hadoop生态圈非常重要的成员,由已经被微软收购的公司Powerset贡献。HBase的故事,我会留到讲Powerset的时候再详细展开。
|
||||
|
||||
二、LinkedIn对Hadoop生态圈的贡献
|
||||
|
||||
LinkedIn是一家主导社交、求职的媒体公司,也是很早就开始用Hadoop去做内部数据的分析。它早年和Facebook、IBM等公司一起给Hadoop贡献了不少源代码,对Hadoop整个生态圈的发展做出了巨大贡献。
|
||||
|
||||
LinkedIn对Hadoop做出的巨大、原创性的贡献是其开源项目Kafka。 简单地说,Kafka是一个在不同数据源之间进行数据交换的消息队列的实现。这个项目由LinkedIn首创,是一个目前为止在整个Hadoop生态圈里都无可替代的开源项目。
|
||||
|
||||
Kafka诞生的背景是,LinkedIn内部有很多不同的数据源,而且LinkedIn需要在这些数据源之间进行有效的数据整合工作。这个项目被LinkedIn开源后备受关注,LinkedIn也因此获得了很多关注。
|
||||
|
||||
创业的诱惑可能是每个成功项目的创始人们都无法拒绝的,Kafka的创始人们也没能免俗。于是在2014年,Kafka的创始人们离开了LinkedIn,并创办了Confluent,致力于Kafka的商业化使用。有关Kafka的详细情况,留待讲Confluent的时候我再详细叙述。
|
||||
|
||||
LinkedIn另一个著名的开源项目是流处理引擎:Samza。 Samza和Kafka的搭配使用,是LinkedIn内部流数据的实时查询标配的解决方案,一直支撑着LinkedIn业务的发展。遗憾的是,跟Kafka比起来,Samza的名气相差甚远,最重要的原因就是Samza没有另外一个社交公司Twitter的流处理引擎Storm好用。
|
||||
|
||||
三、Twitter对Hadoop生态圈的贡献
|
||||
|
||||
对Hadoop生态圈有着巨大贡献的另外一家社交公司是Twitter,它最重要的贡献是:开源的流处理引擎Storm。严格来说,最初开发Storm的并不是Twitter,而是一家叫作BackType的初创公司。Twitter收购BackType以后,Storm自然就属于Twitter了。Storm在Twitter手中被发扬光大,并开源出来。
|
||||
|
||||
Hadoop本身是用Java开发的,所以这个生态圈里的大部分项目都基于Java语言,但Storm却是用比较小众的语言Clojure开发的,这也是Storm项目的特殊性。熟悉Clojure这个语言的程序员很少,因此想要找出一个写Clojure比较出彩的程序员并不是一件容易的事情,这也就导致了Storm的开发圈子要相对封闭一些。
|
||||
|
||||
但是,开发圈子的封闭性并没有影响Storm被广泛接受和使用。在很长一段时间里,Storm都是进行流计算的首选引擎。
|
||||
|
||||
Storm也被国内的大公司广泛采用,用得最多的要属阿里巴巴了。作为全球最大的电商,阿里巴巴的流数据处理规模很快就超越了Storm可以处理的范围,因此它必须自己对这个开源项目进行优化、改进。
|
||||
|
||||
然而Storm使用的开发语言是Clojure,这个语言本来就比较小众,国内可以熟练使用这个语言的人更是罕见,于是阿里巴巴的团队把整个Storm的引擎又用Java重新写了一遍,并将其命名为JStorm。JStorm后来被阿里巴巴集团捐给了Apache软件基金会,成为了Storm项目下面的一个子项目。
|
||||
|
||||
不过,近些年来随着Spark对流计算的支持和Flink的异军突起,流计算的开源市场又有点风起云涌的感觉了。有关Spark的内容,我会在Databricks的文章里面详细讲解。有关Flink的内容,我会在data Artisans的文章里详细讲解。
|
||||
|
||||
总结来说,在Hadoop从属于雅虎一家公司到逐渐被硅谷的其他互联网公司接受、再到形成生态圈的过程中,Facebook、LinkedIn和Twitter这三大社交媒体公司对Hadoop的贡献是巨大的。
|
||||
|
||||
如果没有这么多公司投入这么多资源去完善Hadoop,并通过各种开源项目解决整个生态圈缺失的功能,那么Hadoop很难成长到今天这样的规模。现在,Hadoop已经不仅仅是一个大数据平台了,更代表了一种标准。在今天,无论什么企业要提供什么样的产品,都需要兼容Hadoop生态圈。
|
||||
|
||||
不过,这些社交公司对Hadoop生态圈的热衷,也可以说是因为这些公司单独的技术实力不够强大、难以和谷歌抗衡,因此抱团取暖、共同促进和完善这个生态圈,是它们和谷歌并存的不二法门。
|
||||
|
||||
因此,Hadoop的诞生,可以说是天时、地利、人和的必然产物。 在我看来,即使没有Hadoop,也会在相似的时间点、在某一群公司的共同努力下,诞生一个类似Hadoop的项目。
|
||||
|
||||
|
||||
|
||||
|
||||
67
专栏/技术与商业案例解读/077微软的大数据发展史:微软硅谷研究院.md
Normal file
67
专栏/技术与商业案例解读/077微软的大数据发展史:微软硅谷研究院.md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
077 微软的大数据发展史:微软硅谷研究院
|
||||
在大数据发展的历程中,但凡有一点影响力的公司,都有一段自己的大数据发展史。微软这个20世纪存活下来的软件帝国自然不能免俗。
|
||||
|
||||
但是微软也有“软件帝国”的通病,就是“公司财大气粗”,有关大数据的发展史复杂而且混乱。微软内部的多个部门都在大数据发展史上相对独立地做了一些事情,所以讲述微软的大数据发展史,我们会分别从几个比较重要的部门独立地进行讲解。
|
||||
|
||||
我第一个想说的是一个曾经存在了很多年,现在却已被解散的部门:微软硅谷研究院。 它在微软乃至整个大数据的发展历程中,都扮演了一个很奇特的角色:不是不重要,又不是多重要;貌似很有影响力,又好像没什么太大的影响力。
|
||||
|
||||
有业内人士评价说,大数据发展史是做操作系统的人向做数据库系统的人发起的一场战争。这个说法其实挺有道理的:
|
||||
|
||||
|
||||
一方面,大数据领域奠基性的文章,比如谷歌的“三驾马车”,都发表在操作系统领域最顶级的研究会议上。而谷歌的“黑科技”Spanner,明明是一个数据库,却依然选择了在操作系统领域发表。
|
||||
另一方面,大数据出来之后和谷歌争论最厉害的,都是数据库领域的“泰山北斗们”。
|
||||
|
||||
|
||||
今天我要讲的微软硅谷研究院,是微软研究院里面相对特殊的一群人。他们为微软服务,但是又受到硅谷“反微软文化”的洗礼。他们里面很多是操作系统,尤其是分布式系统里面的世界级专家,包括图灵奖获得者,他们在大数据开始兴起的时候也没有闲着。微软硅谷研究院的主要贡献是一个叫作Dryad的系统,以及后续的DryadLINQ。
|
||||
|
||||
先从Dryad开始讲起。2007年,微软硅谷研究院以迈克尔 · 伊斯拉德(Michael Israd)为首的人发表了一篇论文:“Dryad:来自顺序构建模块的分布式数据并行程序”(Dryad: Distributed Data-parallel Programs from Sequential Building Blocks)。这篇论文提出了一个新的更灵活的大数据处理引擎的实现方式,有别于谷歌的MapReduce。
|
||||
|
||||
我们知道,谷歌MapReduce推出时,谷歌自己是大力鼓吹者。当然,站在谷歌背后支持的人也不少,但并不是所有人都赞同。很多人也指出了MapReduce这个模型太简单,用来做倒排索引还可以,但是对于更复杂的任务来说就不行了。至于传统数据库领域的大佬们,更是跳出来抨击MapReduce的缺点。
|
||||
|
||||
但是大家说归说,并没有人站出来告诉大家,如果MapReduce不行,在大数据的场景下什么是可行的。而微软硅谷研究院的Dryad论文,则是第一个有据可查的,对这个问题进行了系统回答的论文。
|
||||
|
||||
Dryad的想法并不复杂。整个系统支持的是一个有向无环图的执行,图中每个节点定义了计算,而每条有方向的边则代表了数据的流动,数据从边的起点流向终点。Dryad也回答了如何动态分区,以及如何做故障恢复等等问题。
|
||||
|
||||
Dryad的想法并非非常出彩,有很多可以提高改进的地方,不过它影响了后续的一些开源项目,比如说现在大数据领域执行引擎事实上的赢家Spark,其实用的也是类似的执行引擎。在微软内部,Dryad最初面向必应搜索引擎开发部门的兜售比较成功,这个故事我会在下一篇文章中展开讲一下。
|
||||
|
||||
但是在湾区,一般来说就是大家都在讲大数据、讲自己怎么支持MapReduce的时候,微软硅谷研究院的人就出来打个酱油,告诉大家我们有个叫Dryad的东西。
|
||||
|
||||
Dryad的影响力在微软之外并不大,这其实源于微软硅谷研究院是一个很奇特的地方。
|
||||
|
||||
|
||||
一方面,微软在硅谷比较遭恨,而谷歌很多时候是硅谷势力的象征。所以“谷歌出品”必须支持,“微软出品”必须反对的“政治正确”在硅谷很正常。
|
||||
另外一方面则是微软公司的开源理念了。在很长一段时间里,微软公司都是反对开源的,而在湾区的环境下,没人喜欢用不开源的东西。
|
||||
|
||||
|
||||
Dryad虽然说是一个有别于MapReduce的大数据执行引擎,而且功能还强大一些,但却有一个MapReduce没有的毛病:它在易用性上非常差。
|
||||
|
||||
具体来说,MapReduce的用户只需要不停地写Map和Reduce两个函数就可以了,编程模式很简单。而Dryad则不一样,用户必须指定每个节点做什么计算,节点之间要怎么连接。一个程序写下来,代码量和复杂度都比MapReduce多很多。
|
||||
|
||||
我想一个东西不管多牛,如果不好用,也就很难有人问津。如果这个东西还是微软出品的,又在硅谷寻求用户,其结果可想而知。如果再加上微软不开源的话,那大家最多就看个热闹,不会在产品里直接用的。
|
||||
|
||||
微软硅谷研究院的人也知道这个问题。他们的解决方式是一个叫作DryadLINQ的东西。发表于一年后的论文:“DryadLINQ:使用高级语言的通用分布式数据并行计算系统”(DryadLINQ: A System for General-Purpose Distributed Data-Parallel Computing Using a High-Level Language)对这个问题进行了回答。
|
||||
|
||||
我简单介绍一下,LINQ是C#语言的一个特性。它引入了类似函数式编程的思想,通过直接调用非常高层次的函数,来进行数据查询。后来谷歌的FlumeJava和Spark的API,某种程度上都是LINQ这种语言在其他平台上的实现。而LINQ这种语言特性,可以和不同的后端结合起来。以Yu Yuan为代表的微软硅谷研究院的研究员们给Dryad写了一个LINQ的实现,让Dryad这个计算平台可以通过LINQ来解决易用性的问题。
|
||||
|
||||
当然这个解决方式并非没有缺陷,最大的问题在于支持LINQ的只有C#。而我们都知道,Apache基金会下面的开源项目使用的语言都是Java。这样一来,不但微软这套和Apache基金会的开源项目有兼容性问题,而且会让硅谷的公司掉进C#的坑。所以虽然说微软硅谷研究院的人很快解决了这个问题,但他们的解决方式,却并未给Dryad带来更多的使用空间。
|
||||
|
||||
如此一来,摆在微软硅谷研究院面前的出路,是通过微软本身来商业化DryadLINQ这个技术,这个商业化的历程注定是不容易的。
|
||||
|
||||
那时,DryadLINQ获得了微软高性能计算组的支持。当时有一个专门的工程师小组负责商业化这个项目,而这个项目也最终出现在Windows HPC Server R2的预览版里面。然而,在经历了预览版之后,微软高层决定永久停止这个项目的开发。在Windows HPC Server R2的正式版里这个项目就被踢出去了。
|
||||
|
||||
这之后,微软再无任何商业化Dryad的想法。个中缘由太过于复杂,感兴趣的话,你可以再深入了解一下。
|
||||
|
||||
对于微软硅谷研究院的人来说,他们在大数据上面不可谓不努力。但是这一努力,在外部没有获得开源社区的支持,在内部也没有获得公司的支持,所以最后当然是一无所获。
|
||||
|
||||
更为遗憾的是,2014年微软换了CEO。新CEO萨提亚上台后,在全公司范围内大量裁员,于是就传出了曾经震惊世界的硅谷研究院整体被关闭,所有人员除了图灵奖获得者都被裁员的变故。这个决定到底谁做出的,曾经一度各种传闻,一直到“正主”自己公开承认,他就是现在微软负责搜索和AI的EVP沈向洋。
|
||||
|
||||
伴随着微软硅谷研究院的关闭,这个大数据故事也就告一段落了。这些参与了相关项目研发的人,被裁掉以后大部分被谷歌搜罗,在谷歌研究院开始新的工作,那就是后话了。
|
||||
|
||||
|
||||
|
||||
|
||||
67
专栏/技术与商业案例解读/078微软的大数据发展史:必应的Cosmos.md
Normal file
67
专栏/技术与商业案例解读/078微软的大数据发展史:必应的Cosmos.md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
078 微软的大数据发展史:必应的Cosmos
|
||||
微软的大数据发展史上另外一支非常重要的队伍,是必应(Bing)搜索引擎下的Cosmos团队。
|
||||
|
||||
2007年,当时的CEO 史蒂夫 · 鲍尔默(Steve Ballmer) 决定大举进军搜索市场,和谷歌开战。微软为这场战争投入了很多资源,包括对领导层大换血,调集了包括现任CEO 萨蒂亚 · 纳德拉(Satya Nadella)和现任EVP沈向洋在内的很多人才。之后,微软更是从雅虎“挖”了陆奇掌管整个部门。
|
||||
|
||||
随之,微软将MSN搜索改名为必应。我们知道谷歌的“三驾马车”,最初是为它的搜索业务服务的。姑且不谈微软的搜索业务发展得怎样,但它需要建立类似“三驾马车”的基础架构,才能够支撑前端的搜索。 为此,它秘密启动了一个叫作Cosmos(中文代号“宇宙”)的项目,也算是正式开始了和谷歌搜索业务的竞争,而这个时间几乎和Hadoop诞生的时间一致。
|
||||
|
||||
简单来说,Cosmos就是微软的大数据平台。 2000年时,微软利用垄断优势扼杀了硅谷企业Netscape,从此就难以再融入硅谷的圈子了。所以,在2007年时,微软和硅谷的公司们格格不入,也无法同雅虎等公司共建Hadoop平台。经过权衡之后,微软决定自己创建一个这样的平台。
|
||||
|
||||
2007年前后,微软硅谷研究院和必应搜索部门还维持着良好的合作关系,从排序算法,到底层基础架构,到数据中心的建设,微软研究院都参与了必应搜索系统的研发。在这段合作关系中,最为著名、重要的人物就是前文提到过的迈克尔 · 伊斯拉德(Michael Israd)。
|
||||
|
||||
Cosmos最开始的目标是解决必应搜索如何存储互联网上所有数据的问题。简单地说,微软需要一个类似GFS(谷歌文件系统)的文件系统,才能够备份互联网数据,并存储各种各样的日志文件。为了开发这个文件系统,当年微软召集了好几个牛人,包括Cosmos的第一任架构师。但是,这个架构师只在微软待了一年多,就因为政治斗争去了谷歌。
|
||||
|
||||
Cosmos文件系统的架构并不是全新的,它在很大程度上遵循了谷歌文件系统的设计宗旨,因此它的入门文档就是谷歌文件系统的论文。说地更直接一点,Cosmos是仿制了谷歌文件系统。
|
||||
|
||||
如果说Cosmos的文件系统有什么值得称道的地方,可能最值得一提的就是它的压缩算法。Cosmos没有采用任何公开的压缩算法,而是使用了它的第一任架构师自己发明的压缩算法。从压缩的空间和解压缩的时间上来讲,这个算法都领先于当时市面上已有的压缩算法。
|
||||
|
||||
Cosmos搭上文件系统后,很自然地就需要对数据进行处理了。当时正值迈克尔和必应的“蜜月期”,迈克尔很自然地推荐了自己的Dryad,因此Cosmos上第一次出现了和谷歌很不一样的地方:Cosmos的执行引擎是Dryad而并非MapReduce。
|
||||
|
||||
然而,迈克尔在成功推销Dryad后,和必应的关系却越来越不好,具体原因已经无可查证。其中有一个是我认为比较靠谱的说法:Dryad的Bug非常多,需要经常修复,但是迈克尔觉得产品已经推销出去了,修Bug就不是他的事情了;而必应认为迈克尔的产品出了问题,当然得他自己来修。
|
||||
|
||||
后来,必应为了让Dryad在Cosmos里稳定运行,花了很多精力做优化,最重要的优化是改写了Dryad里可能造成性能瓶颈的地方,结果这个优化却将Dryad改得“面目全非”,以至于Cosmos、微软硅谷研究院,以及HPC的Dryad版本都不太一样了。
|
||||
|
||||
随着Cosmos项目的进行,Dryad的弊端越来越多地显示出来,用户无法在Dyrad里面高效率地完成数据查询和分析任务,写程序就像是在写汇编。因此,Cosmos急需在改良后的Dryad上再封装一层,提供一个高级查询语言,这时SCOPE(Structured Computations Optimized for Parallel Execution)就登场了。
|
||||
|
||||
SCOPE算得上是Cosmos区别于其他系统最大的地方, 对微软里面要使用Cosmos的人来说,SCOPE无疑是他们和Cosmos打交道必须学会的查询语言。
|
||||
|
||||
SCOPE最初是由微软雷德蒙德研究院的比尔 · 希尔夫(Bill Ramsey)发明的,但是随着微软雷德蒙德研究院另外一位重量级人物,如今阿里巴巴集团副总裁兼阿里云首席科学家周靖人的加入,SCOPE变得不一般起来。
|
||||
|
||||
简单地说,如果Dryad是一个有向无环图的执行引擎,SCOPE则是一个类似于Pig的高级数据流语言,但是它又在易用性和性能上和Pig不太一样。
|
||||
|
||||
在易用性上,SCOPE具有以下特点。
|
||||
|
||||
|
||||
它有一个强类型系统,完全兼容C#类型系统。虽然当时C#在微软外部名声不显,但在微软内部是第一开发语言。所以,SCOPE选择了这个类型系统,自然而然增加了可用性。
|
||||
它提供了大量高级的查询功能,比如支持写类似SQL的查询语句。
|
||||
它还提供了类似MapReduce的扩展功能。
|
||||
它和C#的整合做得很好。
|
||||
|
||||
|
||||
而在性能上的不同,是SCOPE区别于其他系统的关键部分。SCOPE的性能远远超过了Hive,主要体现在以下两个方面:
|
||||
|
||||
|
||||
SCOPE使用了自动代码生成技术,可以针对每个查询直接生成C++代码。这样做虽然增加了编译时间,但是查询速度要快很多。因为编译只会进行一次,而查询速度的提升涉及了每条记录的查询,所以对于需要大量时间进行大规模数据处理的情况,这个自动代码生成技术为SCOPE提速很多。
|
||||
SCOPE的查询优化做得非常好,而其他很多系统不具备这个创新性的功能。之所以SCOPE可以实现这个创新,是因为它基于Dryad可以很灵活地生成图,而不必局限于MapReduce。
|
||||
|
||||
|
||||
Cosmos在必应取得成功后,被迅速应用到微软的其他业务部门,包括Windows、Xbox、Office365等等。
|
||||
|
||||
Cosmos的队伍在几年内迅速膨胀,阵容也非常强大。它的最高领导人是微软的VP或者院士,二线经理都是微软合伙人,一线经理也得达到首席经理的级别,而且其他成员在微软的职务也都非常高。这样的高配,至今我还没在微软的其他部门见过。
|
||||
|
||||
Cosmos后来又开始做流计算和交互式查询方面的查询引擎,这两个项目取得了一些成绩,但与Cosmos其他项目的成绩比起来还是要差一些。
|
||||
|
||||
2013年,在史蒂夫倡导的“同一个微软”(One Microsoft)的大重组中,微软将Cosmos从必应分了出去,把它合并进了云计算和企业事业部的数据处理部门。这次合并后,必应搜索部门丧失了对Cosmos项目的主导权,而新东家对Cosmos的未来看法不同。
|
||||
|
||||
未来一年多的时间里,Cosmos的队伍经历了成立以来最大的波折。Cosmos团队人员纷纷出走,最终负责Cosmos核心内容的成员各奔东西,我也在那个时候离开了微软。
|
||||
|
||||
很难说“同一个微软”的理念是对是错,但有一点可以肯定,调整后Cosmos的发展停滞了。微软必应的大数据故事,也就此告一段落。
|
||||
|
||||
|
||||
|
||||
|
||||
70
专栏/技术与商业案例解读/079微软的大数据发展史:Azure的大数据发展.md
Normal file
70
专栏/技术与商业案例解读/079微软的大数据发展史:Azure的大数据发展.md
Normal file
@@ -0,0 +1,70 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
079 微软的大数据发展史:Azure的大数据发展
|
||||
一、HDInsight:一个云端Hadoop版本
|
||||
|
||||
Azure是微软云计算的品牌,而云计算是给客户提供服务的。所以,微软云计算平台的大数据发展方式,与其他解决内部需求的项目不同,最初主要围绕Hadoop生态圈展开。
|
||||
|
||||
Hadoop诞生时,没有考虑过Windows上稳定运行的问题,因为做Hadoop的企业是雅虎、Facebook、LinkedIn等湾区互联网企业,这些企业都用免费的Linux,不用昂贵的Windows,它们没必要考虑Hadoop在Windows下运行的问题。
|
||||
|
||||
但是,Hadoop的壮大让微软感受到了危机。如果每个使用Hadoop的企业都用Linux了,数据就会被存到Linux里,各种应用服务也有可能就渐渐转向Linux。
|
||||
|
||||
微软担心大数据系统的出现和普及,尤其是Hadoop生态圈的壮大,会威胁到Windows的销售,导致Windows服务器的业务下降。因此微软云计算部门选择了和Hortonworks合作,把Hadoop在Windows上的稳定运行当作头等大事对待。
|
||||
|
||||
微软云计算部门和Hortonworks对接的,是微软内部负责研发一个叫作HDInsight的云端Hadoop版本的团队。这个团队有两大任务:其一是和Hortonworks一起,实现Hadoop在Windows上的稳定运行;其二是为微软提供云端的Hadoop版本,也就是HDInsight。
|
||||
|
||||
从微软给这个团队定义的任务出发,HDInsight团队很好地完成了这两个任务。但是HDInsight有一个比较大的问题:性能差。简单来说就是,HDInsight在对接Hadoop文件系统和微软的云存储Azure Blob Store时,对接得不是很高效,因此HDInsight的运行效率很低。
|
||||
|
||||
HDInsight作为云端的产品,不但对外推广,也在内部大量寻找用户,但是因为性能问题内部用户寥寥无几,没有部门愿意买单。
|
||||
|
||||
我在上一篇文章中提到过,必应部门做了一个数据分析平台Cosmos。这个平台和HDInsight比起来,优势主要就体现在性能上。而且,Cosmos作为数据分析工具,只要能分析数据就好,不需要考虑是不是兼容Hadoop。因此,Cosmos在和HDInsight的对标中,除了一些政治因素外,其他方面鲜有败绩。
|
||||
|
||||
二、 Azure Data Lake的诞生
|
||||
|
||||
很长一段时间里,HDInsight和Cosmos在微软内部都是竞争对手,双方都希望微软的各大部门采用自己的平台,然而HDInsight因为性能问题每战必输。
|
||||
|
||||
而在Cosmos被合并到云计算部门后,这两个产品同处在了一个组织下面,输赢不再重要,竞争关系也不复存在了。但是因为长期竞争的关系,两个团队私下并不和谐。
|
||||
|
||||
Cosmos被重组到云计算部门后,微软聘请了著名的数据库领域的专家,前威斯康辛大学教授、前雅虎副总裁拉 · 罗摩克里希纳恩(Raghu Ramakrishnan)领导这个团队。为什么聘请这个人,因为云计算部门想做一款新产品,我们姑且简单地理解为是做一款面向外部客户的Cosmos吧。
|
||||
|
||||
这个新的团队领导认为,对外服务的Cosmos是一款可以连接和处理Azure上所有数据源的数据查询引擎。因为他的这个想法,就需要对Cosmos做伤筋动骨的改动。
|
||||
|
||||
这样大的改动只获得了一部分人的支持,这些人得到了升迁和资源。而持反对意见的人,慢慢淡出了权力中心,陆续离开微软,我也正是在那个时候去了Tableau。
|
||||
|
||||
然而,这个Cosmos新版本的开发难度远远超出了他的心理预期,交付日期一拖再拖。2016年,这个产品在延期两年后终于以Azure Data Lake这个名字发布了。
|
||||
|
||||
无论微软内部和外部,这个团队都极力推动这款产品,但买账的人并不多。微软内部大部分选择了老版本的Cosmos不肯搬迁,在外部也只有沃尔玛买单。为什么会是这样一个结果呢?
|
||||
|
||||
这个系统失败的原因有很多,在我看来主要有以下两点。
|
||||
|
||||
|
||||
用户需要重新学习一种叫作U-SQL的语言,才能充分发挥这个系统的性能。U-SQL其实是SCOPE的改造版,但改造得不伦不类。为什么这么说?首先是SCOPE语言很灵活,但U-SQL却很死板。其次是SCOPE在数据类型上向C#兼容,而U-SQL却决定一半的地方兼容SQL,另外一些场景兼容C#,兼容规则因此搞得非常复杂。
|
||||
这个系统和C#紧紧地绑定在一起,而Hadoop生态圈完全基于Java,于是鲜有用户愿意尝试这个系统。
|
||||
|
||||
|
||||
三、大数据平台CosmosDB
|
||||
|
||||
云计算部门的另外一个大数据平台是DocumentDB,它是市面上很少见的可以和MongoDB竞争的产品。有关DocumenDB的功能分析,我在之前的文章里已经讲过。
|
||||
|
||||
DocumentDB在后来的一次升级中被改名为CosmosDB。这次升级的主要目的是把数据模型从MongoDB一种提升到了若干种,包括MongoDB的半结构化数据、图数据库等,从而使CosmosDB能够更灵活地支持不同的应用。
|
||||
|
||||
CosmosDB推出时,市面上还找不到同类竞品。当然,这个说法其实不完全准确,因为开源社区在2012年曾经有一个叫作FoundationDB的项目,和CosmosDB的做法很像,底层是统一的存储方式,上面支持不同的数据模型。但是FoundationDB被苹果收购之后就不再开源,一直到2018年5月这才重新开源出来。这种产品的独特性给了微软一个很好的市场切入点。
|
||||
|
||||
微软的云计算部门在CosmosDB上投入相当大。作为MongoDB的竞品,CosmosDB也表现出了良好的性能和扩展性,并解决了MongoDB长期以来为人诟病的安全问题。因此,CosmosDB发布之后业务量一直迅猛增长,最终成了微软大数据服务里面唯一的亮点。又因为这是一个只在Azure上发售的服务,一定程度上也给Azure带来了不少的流量。
|
||||
|
||||
在2018年5月刚结束的年度微软开发者大会(Microsoft Build)上,CosmosDB作为大数据领域唯一被大会主题报告提及的业务,展示了非常靓丽的业绩。而且,微软今年又为CosmosDB增加了全球多节点同时写入的功能。这一切都说明,CosmosDB业已成为微软云端大数据产品线上最为耀眼的一款产品。
|
||||
|
||||
总体上来说,微软云计算部门的大数据之路:无论是拥抱开源的HDInsight,还是自己努力研发的Azure Data Lake,又或者是具备独特地位的CosmosDB,投入都是巨大的。
|
||||
|
||||
但目前来看,只有CosmosDB既具有特色又很成功,其他产品就不过尔尔了。HDInsight的性能问题,Azure Data Lake的定位问题,都是微软云计算部门大数据上表现欠佳的地方。
|
||||
|
||||
在大数据时代,微软不可谓不努力,但是产品的表现参差不齐,没有表现出一个曾经的软件帝国的创造力和统治力。所以,一个公司如果成为时代的追随者,是很难在产业中有统治地位的。CosmosDB是这些产品里少有的亮点,一方面是因为解决了客户的实际需求,一方面是产品有独特的竞争优势。
|
||||
|
||||
因此,我们可以看到,在大数据时代,创新,尤其是解决实际需求的创新,依然是一个公司确立行业优势最重要的因素。
|
||||
|
||||
|
||||
|
||||
|
||||
47
专栏/技术与商业案例解读/080亚马逊的大数据故事:从先驱者到插管吸血开源.md
Normal file
47
专栏/技术与商业案例解读/080亚马逊的大数据故事:从先驱者到插管吸血开源.md
Normal file
@@ -0,0 +1,47 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
080 亚马逊的大数据故事:从先驱者到插管吸血开源
|
||||
全球的互联网大公司里面,如果说哪家公司最有争议性,亚马逊肯定是其中之一。在大数据发展历程中,亚马逊扮演的角色相当复杂,既曾是先驱者,也曾作为“吸血者”插管吸血开源社区。
|
||||
|
||||
此外,亚马逊不仅充分利用Hadoop生态圈壮大了自己,而且推出了一些特色化服务。亚马逊的大数据发展比较复杂,它既有对大数据发展作出里程碑式贡献的一面,也有利用了大数据圈的技术大量“插管吸血”却并不回馈社区的一面。 今天,我们一起来看看亚马逊的大数据故事。
|
||||
|
||||
Dynamo:NoSQL的先驱之一
|
||||
|
||||
除了谷歌,其他公司(比如微软)也或多或少对于大数据时代的发展有一些特色贡献。但只有亚马逊的这篇名为《Dyanmo:亚马逊的高可用键值存储》(Dynamo: Amazon’s Highly Available Key-value Store)的论文,是唯一一篇可以和谷歌“三驾马车”并驾齐驱,具有同样影响力的论文。 这篇论文发表于2007年的操作系统顶级会议SOSP上,它们共同开启了大数据时代。
|
||||
|
||||
在2017年上海举办的SOSP会议上,这篇论文荣获了SIGOPS 名人堂奖(Hall of Fame Award, HoF)。这是操作系统领域里面的大奖,专门用来表彰那些发表10年以上,对业界产生了深远影响的论文。
|
||||
|
||||
Dynamo和BigTable功能上很像,也是一个NoSQL。但是两者在实现方式上非常不一样。简单来说,BigTable基于排序来实现的 ,而Dynamo则基于哈希去实现,当然技术细节不在本文的探讨范围之内。但是,值得注意的是,亚马逊第一次给大家展现了一个全新的键值存储系统(Key-Value Store)是怎么实现的。
|
||||
|
||||
Dynamo也有开源的产品实现,即Cassandra。Cassandra先由Facebook开发并开源,后期则由DataStax公司维护。亚马逊AWS把Dynamo以DynamoDB的名字推出来给客户使用,现在DynamoDB是AWS历史最为悠久、用户量最大的产品之一。
|
||||
|
||||
Dynamo论文发表之后,据说在亚马逊内部掀起了轩然大波。很重要的一个原因是,亚马逊传统上是不发表自己的核心技术的。 所以虽然说亚马逊有全世界最好的编译和软件部署系统阿波罗(Apollo)和最好的版本控制系统巴西(Brazil),但是外界对于亚马逊到底是怎么实现这些东西的并不知晓。
|
||||
|
||||
谷歌也在一定程度上奉行这个策略,但是要好一些。比如说,谷歌虽然公布了“三驾马车”,但那是在技术成熟,下一代产品基本就位的时候才公布上一代产品的。至于谷歌最核心的基于容器的调度系统,则有十余年一直被当作核心机密。直到2015年,因为Docker已经大行其道了才公开。
|
||||
|
||||
而亚马逊基本上是完全不公布的政策,而Dynamo显然打破了这个规则。有传言贝佐斯对于Dynamo团队发表这篇论文,导致亚马逊核心技术泄露表达了强烈不满。这个传言真假不得而知,但是不管怎样,我们能够看到亚马逊后来在核心技术论文发表方面,又小心翼翼起来。
|
||||
|
||||
Elastic MapReduce
|
||||
|
||||
如果说Dynamo和后来商业化的DynamoDB是亚马逊带给整个大数据领域不可磨灭的贡献,亚马逊作为大数据的“先驱者”也因为这篇论文而名垂青史了,Elastic MapReduce这个云端产品带给亚马逊的则是滚滚财富。
|
||||
|
||||
伴随着Hadoop生态系统的成熟,很多围绕这个生态圈的创业公司诞生了,这包括后来很著名的Hadoop三大发行商:Cloudera、Hortonworks和MapR。亚马逊作为一个云厂商,也进入了这个市场,它推出的产品叫作Elastic MapReduce。
|
||||
|
||||
在如何对待开源产品这个事情上,我们必须说,亚马逊和其他公司有很大不同。其他公司不论出于什么样的目的,都或多或少对开源产品本身做出了很大的贡献。Hadoop的三大发行商在很大程度上维护了Hadoop基础架构的开发,Cloudera和Hortonworks一度是Pig和Hive最重要的维护者。各大社交媒体公司也纷纷开源了很多自己的系统,来丰富整个生态圈。这些公司都对Hadoop核心代码做出了很多贡献。
|
||||
|
||||
但是亚马逊对于整个Hadoop生态圈的贡献,除了如何去连接它自己的云服务(比如S3)以外,善乏可陈。亚马逊做的事情,典型的做法就是把已成熟的开源社区产品拿过来,在内部做二次开发,以便能够在亚马逊的云端很好得运行。然后,就没有然后了。亚马逊并不会给开源社区贡献自己的核心代码。
|
||||
|
||||
一方面来说,因为Hadoop生态圈本身就意味着对机器资源的大规模消耗。所以任何使用Hadoop的人,在亚马逊的AWS服务上,都必然会支付不菲的金钱。因此,亚马逊的AWS得到了快速发展。
|
||||
|
||||
另外一方面,S3本身就是世界上最大的存储服务,无数公司把数据存储在S3里。AWS的Elastic MapReduce可以有效整合S3的数据读写,这也让用户更加离不开AWS这个生态圈。
|
||||
|
||||
如果我们回过头来看,整个大数据历史的发展中,如果说哪个公司最得利,没有任何一家公司比得上亚马逊的,大数据的发展很大程度上也是亚马逊云计算业务的发展过程。那么,亚马逊对开源的贡献是什么呢?对Hadoop生态圈的贡献又是什么?或许,在这一点上还是未来值得思考和期待的事情吧。
|
||||
|
||||
有关亚马逊的大数据先驱者和“插管吸血”开源社区的故事就讲到这里了。亲爱的读者,你觉得这种状态是Hadoop开源社区错了,被亚马逊“合理利用”了呢?还是亚马逊本身的做法值得商榷呢?
|
||||
|
||||
|
||||
|
||||
|
||||
73
专栏/技术与商业案例解读/081亚马逊的大数据故事:创新和拿来并存的云服务.md
Normal file
73
专栏/技术与商业案例解读/081亚马逊的大数据故事:创新和拿来并存的云服务.md
Normal file
@@ -0,0 +1,73 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
081 亚马逊的大数据故事:创新和拿来并存的云服务
|
||||
随着大数据的发展,数据处理变得越来越重要,亚马逊的云端数据处理和分析服务也逐渐多起来。亚马逊的这些服务,除去已经提到的DynamoDB和Elastic MapReduce,还有很多。它们的来源大致分为两种:一种是自己开发的,另外一种则是拿开源的包装一下。今天我们就来看一看这些服务。
|
||||
|
||||
Redshift
|
||||
|
||||
Redshift是亚马逊比较早的一个基于云的数据仓库系统。Redshift是一个兼容PostgreSQL 8.0.2版本的数据仓库系统,前端对SQL语言的解析复用了PostgreSQL 8.0.2版本的源代码,后端最初是基于一家亚马逊投资的公司ParAccel的并行数据仓库处理技术。Redshift在2012年以Beta版发布,2013年2月正式亮相。
|
||||
|
||||
Redshift无疑是亚马逊最为成功的数据处理云服务之一,或许我们都不需要加“之一”这种说法。Redshift自诞生开始就受到了中小型企业的欢迎,很多大型企业(比如Airbnb)也一度使用它。
|
||||
|
||||
Redshift到底有多牛?证据之一,在2017年的年度大会OpenWorld上,Oracle创始人拉里 · 埃里森(Larry Elison)在发表主题演讲时,把Redshift作为Oracle的唯一对标的产品进行了比较。Oracle在数据库领域的建树,决定了任何一个被Oracle作为敌人对待的人,都是在这个领域里面取得了相当成就的。这一次,Redshift终于“荣幸”地成为了“靶子”。
|
||||
|
||||
Redshift这款产品,长久以来都有自己独立的数据存储方式,用户需要从其他地方把数据导入Redshift才可以使用。2017年4月,亚马逊发布了叫作Redshift Spectrum的新功能,从而允许Redshift直接访问存储在S3上的文件。
|
||||
|
||||
这个新发布的功能,给业界带来了相当大的震撼。结合亚马逊S3存储的无敌和Redshift的查询功能,这进一步强化了亚马逊在云端数据处理上的能力。
|
||||
|
||||
Redshift在市场上最大的竞争对手是Snowflake,这是一家云端弹性数据仓库的创业公司。有关Snowflake的故事,我会单独介绍。
|
||||
|
||||
Aurora
|
||||
|
||||
Aurora是亚马逊推出的第二个数据库云端服务,2014年底推出。如果说Redshift是服务于数据仓库和数据分析的,Aurora主要是亚马逊用于事务处理的服务。
|
||||
|
||||
Aurora和MySQL 5.6版本兼容,其存储引擎和InnoDB兼容。2017年的时候,亚马逊又推出了和PostgreSQL兼容的Aurora数据库。这样一来,两大开源数据库都兼容了。
|
||||
|
||||
Aurora是亚马逊另外一款在云端受欢迎的数据库。亚马逊自己公布的数据显示,Aurora的性能比传统MySQL要快5倍,性能提升主要是源于亚马逊自己设计的,属于商业机密的基于SSD的存储结构。
|
||||
|
||||
Aurora团队在2017年发表了一篇论文,介绍了Aurora的实现细节。其中最为创新的地方在于计算引擎往存储层写入东西的时候,可以做得非常轻量级,只需要把日志文件记录传下去就好,文件系统本身实现了对数据的整理和冗余的保证。
|
||||
|
||||
结合Aurora和Redshift,亚马逊拥有了关于数据仓库和事务处理全方位的解决方案,这也让它在云端数据库领域越发显得有竞争力。
|
||||
|
||||
Athena
|
||||
|
||||
Athena是亚马逊的一个查询服务,它允许用户直接查询存储在S3中的数据。和Redshift以及Aurora不同,Athena是Serverless架构的,这个服务可以按照计算的需要自动起虚拟机,就能够进行查询。用户不再需要显式的起虚拟机,大大的方便了用户的使用体验。
|
||||
|
||||
此外,它与Aurora以及Redshift还有一点不一样,Athena是一个拿来主义的产物。它基于开源项目Presto,这个项目在Facebook、Airbnb、京东等很多公司都被广泛使用。实际上,按照公布的信息来看,Redshift Spectrum也是基于Presto的技术。
|
||||
|
||||
亚马逊当然是对Presto进行了很多的改进。但是以亚马逊一贯的作风,这些改进并没有被重新贡献回开源社区。所以指望亚马逊在从开源吸血的时候能够反馈社会,可能过于乐观。
|
||||
|
||||
Kinesis
|
||||
|
||||
Kinesis是亚马逊平台上另外一款重要的产品,它主要针对的是对流数据的导入和分析。从某种程度上来讲,Kinesis平台对应的开源产品是Kafka。这一次,亚马逊选择了不用Kafka,而是自己开发一套具有竞争意义的产品。
|
||||
|
||||
这是一个我不太理解的决定。因为Kafka在开源社区里面是质量挺高的一款软件,它的用途也很广泛,充分被人证实了是靠谱的选择。亚马逊这个非常擅长“拿来主义”的公司,这次竟然选择了自己去建一个系统。
|
||||
|
||||
我后来注意到,这个团队的主管人员是微软里面早年做流计算平台出身的。我想可能这位主管人员觉得,自己的经验搭建一个新产品可能会比Kafka更成熟更先进。至于实际效果,我们还需要时间去验证。
|
||||
|
||||
但是不管怎样,作为在AWS上流计算的唯一选择,Kinesis推出以来还是吸引了不少用户。这个产品无论如何,结果都应该不会太差。只要AWS本身表现可以的话,流计算总是有需求的。
|
||||
|
||||
Glue
|
||||
|
||||
Glue是亚马逊2017年最新推出来的云计算服务。它的主要目标是ETL,ETL是数据管理整个生态周期中很重要的一环。以前用户需要把数据导入Redshift之类的数据库时,需要自己去写ETL的管道(pipeline),这无疑非常不方便。
|
||||
|
||||
Glue的推出是亚马逊想要弥补这块市场缺失必然的一步。至于为什么到2017年才提上日程,我想数据处理的产品,核心的还是在数据处理,而数据的导入,很多用户有自己成熟的解决方案,其优先级到底有多高不好说。
|
||||
|
||||
QuickSight
|
||||
|
||||
严格讲,QuickSight不是一个数据处理分析工具,而是一个数据可视化服务,主要的服务对象是商业智能仪表盘(BI dashboard)。
|
||||
|
||||
亚马逊主推的QuickSight和传统的BI领导者比起来,还有很多的问题,比如说功能上比较单一。但是它主要的优点是成本低廉,又和亚马逊云端的其他产品紧密集成。所以对于中小企业,不需要太复杂BI功能的,这是一个很好的选择。
|
||||
|
||||
我们可以看到,亚马逊在云端已经构建了非常完善的大数据处理生态圈,这其中既有开源的,又有自己构建的,这个生态圈足以让亚马逊对任何一个传统的和云端数据处理的提供者展开竞争。
|
||||
|
||||
亚马逊在整个大数据的发展历程里,通过Dynamo产品给大数据的发展作出了巨大贡献,也体现了一个业界领先企业的创新能力。很多其他的产品,也展现出了亚马逊良好的创新能力。
|
||||
|
||||
但是亚马逊从Hadoop开源社区获得了很多的便利,却不愿意把自己的改进反馈给开源社区,实际上这种做法动摇了开源社区良性发展的基础,树立了一个坏榜样。所以对于亚马逊在大数据发展过程中的功与过,我们只能以一种很复杂的态度去看待,无法一言以蔽之。
|
||||
|
||||
|
||||
|
||||
|
||||
57
专栏/技术与商业案例解读/082阿里巴巴的大数据故事:数据分析平台发展史.md
Normal file
57
专栏/技术与商业案例解读/082阿里巴巴的大数据故事:数据分析平台发展史.md
Normal file
@@ -0,0 +1,57 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
082 阿里巴巴的大数据故事:数据分析平台发展史
|
||||
阿里巴巴是国内最早开始做大数据的公司,也是国内最早开始做云计算的公司。阿里巴巴的数据分析平台非常齐全,今天我带大家看一看阿里巴巴的大数据发展历史。我们首先看看数据分析平台方面的发展。
|
||||
|
||||
MaxCompute
|
||||
|
||||
阿里巴巴作为国内最大的互联网公司之一,也需要一个大数据分析平台。阿里巴巴发展大数据平台,走了两条路:一部分业务用的是开源的Hadoop,另外一部分则用了自己研发的平台。这个自己研发的平台最初叫ODPS,也就是现在的MaxCompute。
|
||||
|
||||
阿里巴巴的平台研发,时间上比微软、谷歌或者雅虎起步的时候稍微晚了一点。这个平台最初主要做法是前端和Hive兼容,使用了Hive的语法,后端从查询优化到查询的执行,到数据的存储都是自己开发的。当时负责开发的是徐常亮。
|
||||
|
||||
平台的开发一开始并不顺利。但是通过几年的磨合,这个平台也开发得有模有样了,和阿里内部使用开源Hadoop的组并驾齐驱。到后来,很多阿里内部业务都泡在了MaxCompute上。当然,阿里巴巴的MapReduce叫作E-MapReduce,至今依然是阿里云支持的服务之一。
|
||||
|
||||
MaxCompute在2015年迎来了一次大换血。当时微软Cosmos部门负责SCOPE开发的领导,微软合伙人之一的周靖人加盟阿里云,成为阿里的副总裁兼首席科学家,MaxCompute成为了他手下负责的方向之一。
|
||||
|
||||
此后随着曾在微软SCOPE队伍里的中国人的加盟,MaxCompute的负责人换成了微软来的关涛,同时加盟的还有后来MaxCompute的总架构师林伟。这群新来的人对MaxCompute的整个框架做了很大的改动,让整个框架更加得模块化。在2017年的时候,MaxCompute 第2版也顺利发布了。
|
||||
|
||||
目前阿里巴巴内部的很多数据分析任务都跑在MaxCompute上。这也是就我所知除去谷歌和微软以外,全球第三家不基于Hadoop生态圈,而是基于自己开发的系统做大数据分析的公司。
|
||||
|
||||
OceanBase
|
||||
|
||||
OceanBase是另外一个非常重要的产品,严格一点来说它属于蚂蚁金服集团。OceanBase是阿里巴巴集团的新一代分布式金融关系数据库,主要面向对象是蚂蚁金服集团内部的各种金融业务。
|
||||
|
||||
阿里巴巴公司建立的早期,业务主要跑在Oracle的数据库上。但是随着时间的推移,Oracle数据库越发无法支撑阿里巴巴的业务规模,而Oracle的昂贵价格也让阿里巴巴的运营成本居高不下,这就有了用自己的软件代替Oracle数据库的想法。
|
||||
|
||||
阳振坤老师是OceanBase项目的负责人。根据2017年财富排行榜公布的信息,他的目前身价是70亿元。但是阳老师至今依然领导OceanBase的工作,为理想而奋斗。
|
||||
|
||||
OceanBase起始于2009年,最初是支付宝钱包项目的一个子模块。后来OceanBase独立出来,慢慢做成了一个通用的数据库系统,并被用到了蚂蚁金服集团各个不同的项目上。2014年的OceanBase是第一个稳定版本,还一度开源过。但是那个时候的OceanBase有一个问题,数据写入时只能从一个节点写入,会造成写操作的瓶颈。
|
||||
|
||||
伴随蚂蚁金服业务规模的扩张,这个问题导致OceanBase在很多项目上成为瓶颈。2014年开始研发的新版本最终将这个问题解决掉了。2017年的时候,按照蚂蚁金服集团非官方的说法,OceanBase已经全面取代了Oracle,成为蚂蚁金服主要业务的、唯一的数据库平台。
|
||||
|
||||
PolarDB
|
||||
|
||||
阿里巴巴早年大量使用Oracle,所以培养出了中国最早的一批Oracle高手。但是阿里巴巴也是大量使用MySQL的,所以集团内部也培养出了第一批MySQL的高手。
|
||||
|
||||
以俞峰为首的团队是阿里巴巴内部对MySQL最为精通的团队之一。这个团队对MySQL进行了大量改良,使之支持了阿里巴巴的很多业务,其核心业务主要是在非金融方面。包括MySQL的两地三中心主从备份的版本,都是从这个团队里出来的。
|
||||
|
||||
2017年正式发布的PolarDB,是这个团队把这种MySQL的认知发扬光大以后最新的云端产品。如果要对标业界的产品,那么最合适的应该是亚马逊的Aurora。但是从技术层面上来说,PolarDB和Aurora有很多不一样的地方。
|
||||
|
||||
PolarDB兼容MySQL的API,后端则通过最新的硬件和软件相结合的方式,使性能达到了MySQL的10倍,同时还可以有效地处理大量的并发请求。这个系统无疑代表了阿里巴巴大数据方面一个很高的里程碑。
|
||||
|
||||
当然,在阿里巴巴旗下的数据分析平台,还不只这几个。比如说,阿里巴巴有HybridDB for Postgress,我们可以认为这是类似亚马逊Redshift的产品。此外,阿里巴巴还有对主要的NoSQL开源产品的支持,比如说MongoDB、Redis。这些产品都在ApsaraDB的品牌下。
|
||||
|
||||
重叠的功能
|
||||
|
||||
每次我面对阿里巴巴的产品时,都有一个很大的困惑。这些产品看起来是阿里巴巴内部不同的团队独立开发出来的,然后它们作为不同的产品出现在大家面前。
|
||||
|
||||
比如说,到今天如果要我在OceanBase和PolarDB之间给用户推荐一下,我会不知如何决策。因为从功能上看,这两者都是做事务处理的数据库。从宣传上看,两者都很牛,都支持了双十一,当然是在不同的业务上。
|
||||
|
||||
这种困惑并非只有我有,知乎上类似的问题很多,各种回答也是众说纷纭,有时候项目负责人也会亲自上场回答问题。但是看完答案, 我的困惑更多了。在阿里巴巴发展的不同时期,不同的团队开发了功能类似的产品,这很正常。但是如果这些产品都一股脑儿摆在用户面前让用户挑选的话,商业上就不知道怎么评价了。
|
||||
|
||||
|
||||
|
||||
|
||||
63
专栏/技术与商业案例解读/083阿里巴巴的大数据故事:流计算引擎发展史.md
Normal file
63
专栏/技术与商业案例解读/083阿里巴巴的大数据故事:流计算引擎发展史.md
Normal file
@@ -0,0 +1,63 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
083 阿里巴巴的大数据故事:流计算引擎发展史
|
||||
在阿里巴巴的发展过程中,流数据处理一直是业务中很重要的一部分。和数据分析平台不一样,阿里巴巴内部的流数据处理平台有很多套。
|
||||
|
||||
在阿里巴巴的流数据发展历程里,有两个著名的流引擎JStorm和Blink依然还在产生着深远的影响。这种影响并不仅仅在阿里巴巴集团的内部,并且扩散到了全球的开源世界。比起其他用于集团内部的流计算引擎,它们更被人所熟知,今天我们就来重点分析一下这两个流计算引擎的发展。
|
||||
|
||||
我们先来说说Storm和JStorm
|
||||
|
||||
Storm是被Twitter收购以后才开源出来的流计算引擎。阿里巴巴集团是在封仲淹带领的团队下才开始使用Storm的。
|
||||
|
||||
我在之前讲Storm的时候说过,这种流计算引擎是用一种比较小众的函数式编程语言Clojure开发出来的。国内的Clojure专家屈指可数,因此阿里巴巴使用Storm时遇到了很多的问题。
|
||||
|
||||
毕竟有些时候需要去增加或者改变一些功能,而这也就意味着需要对系统进行改进或者定制,但是Clojure语言十分小众,懂这种编程语言的人尚且不多,更不用说专业去修改了,所以,这些都决定了这种工作非常难以展开。
|
||||
|
||||
鉴于Storm十分难以改进和定制,又是当时开源世界里最成熟的流计算引擎。于是,从2012年开始,阿里巴巴决定用Java对Storm进行重写,这就是JStorm项目的由来。
|
||||
|
||||
按照封仲淹的观点来说,JStorm就是Storm二次开发的产物。它可以让用户无缝地从Storm迁移到JStorm。
|
||||
|
||||
阿里巴巴选择用Java进行开发,这让开发进度明显加快。而且,源于阿里巴巴的应用规模、对数据实时性等种种要求,团队对JStorm也进行了很多的优化。可以这么说,JStorm的出现,解决了Storm存在的很多问题。
|
||||
|
||||
2015年11月19日,阿里巴巴集团正式向Apache基金会捐赠了JStorm。JStorm成为了Apache Storm下面的一个子项目,并在Apache基金会里继续孵化。
|
||||
|
||||
那段时间,JStorm的作者们对于开源表现出非常大的积极性。封仲淹那时也表示,整个社区的Storm 2.0会基于阿里巴巴的JStorm,用Java语言进行开发。
|
||||
|
||||
然而世事无常,JStorm在Apache的孵化器里待了快两年,依然没有成为Apache基金会的顶级项目。而Storm2.0这个以阿里巴巴JStorm为主的开发项目更是连影子都没有见到。
|
||||
|
||||
对于此事,我非常好奇,但并不真正知晓其答案。只是有次听到一个Apache圈内人士聊到过,说阿里巴巴和Storm社区之间似乎有了矛盾。
|
||||
|
||||
再来说说Flink和Blink
|
||||
|
||||
Flink是德国柏林工业大学设计的一个流计算引擎,现在是Apache的顶级开源项目。Flink这个引擎从模型的角度来看是非常先进的,但是在工程实现上却相对薄弱一些。
|
||||
|
||||
Flink也被阿里巴巴集团用到了自己的生产环境中,项目的领导者是曾经在微软SQL Server组以及Facebook都待过的数据库专家蒋晓伟(花名“量仔”)。
|
||||
|
||||
他在接受采访时表示,在Spark和Flink这两个引擎中,Flink的设计理念更为先进一些,也更符合阿里巴巴对流计算引擎的要求,这恰恰也是他的团队选择这个引擎的原因。
|
||||
|
||||
当然,阿里巴巴集团并没有把Flink拿来直接使用,而是对Flink进行了大量的、全方位的改造,不仅提高了Flink的性能,而且改进了不少功能。这个项目在阿里巴巴内部叫作Blink,是阿里巴巴集团内部很多业务的流处理引擎,其重要地位可见一斑。
|
||||
|
||||
Blink目前还未开源,但在与社区的合作上,Blink团队和Flink的开发者之间保持了更为友好的关系。Flink的开发团队多次在公开场合感谢Blink团队对Flink项目的贡献,Blink团队也把很多功能都反馈到了Flink的代码库里。
|
||||
|
||||
为什么JStorm和Blink同为由阿里巴巴主导的,针对Apache已有项目改良的产物,却在和开源社区的互动以及对开源社区的影响方面有着不同的结果。我想,这其中大概有几方面的原因。
|
||||
|
||||
首先,Flink是后起之秀,又来自德国,还是从学校里出来的。在Flink流进市场的时候,北美的主要互联网企业要么已经使用了自研的流计算引擎,要么已经基于开源的流计算引擎开展了业务,不太可能短期内更新流计算引擎到Flink,所以Flink本身就需要大客户的支撑,阿里巴巴的出现恰逢其时。
|
||||
|
||||
其次是Flink团队和阿里巴巴团队的互补性比较强。前者理论基础好,但是没有工业界的开发经验,后者工业界开发经验却很足,这也就让双方的合作有了基础。
|
||||
|
||||
最后,也可能是最重要的一点就是,这还是一个面子问题。JStorm的做法是把Storm的整个代码库用另外一个语言完全重写了一遍,这无疑是一种比较得罪人的做法。而Blink在贡献回自己的代码时,是在Flink原有代码基础上改的,并且改动时也和Flink的人做了仔细协商。我想,也许就是这两种不同的合作态度,决定了两个项目的不同结果。
|
||||
|
||||
除了这两个流计算引擎以外,阿里巴巴内部还有其他一些流计算引擎(包括Max Compute组自己开发的,一个完全和开源社区无关的流计算引擎),但是这些引擎公开的消息很少,我就算是有心想研究它们,却也不知道从何下手了。
|
||||
|
||||
不过最新消息称,经过多年不同引擎之间的内部PK,阿里巴巴在2018年终于确定了:未来Blink会是阿里巴巴集团统一的流计算引擎。
|
||||
|
||||
JStorm和其他的流计算引擎上的业务都会慢慢迁移过来,最终整个公司的所有流计算引擎的开发和维护资源都会集中到Blink上。这也是阿里巴巴集团内部第一次有某种数据处理产品“一统江山”。
|
||||
|
||||
两个流计算引擎和开源社区的交流的不同结局告诉我们,和开源社区打交道,仅仅是提供自认为更加厉害的代码给开源社区是远远不够的。尤其是贡献代码的同时却没有给予社区主要贡献者足够的尊重,往往会让事情往坏的方向发展。和社区的合作需要大量持续的互动和交流,以及对社区主要贡献者的尊重。
|
||||
|
||||
|
||||
|
||||
|
||||
81
专栏/技术与商业案例解读/084大公司的大数据战略得失:自建轮子成本高.md
Normal file
81
专栏/技术与商业案例解读/084大公司的大数据战略得失:自建轮子成本高.md
Normal file
@@ -0,0 +1,81 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
084 大公司的大数据战略得失:自建轮子成本高
|
||||
介绍完主流大公司的大数据战略,我们来分析一下这些公司的状况。大体来说,我们可以把这些公司分成两类:一类是自己造轮子的,另一类是在Hadoop生态圈里面抱团取暖的。前者主要有三个公司:谷歌、微软和阿里巴巴,后者就是其他我们耳熟能详的大公司了。今天我们就来聊聊自己造轮子的公司。
|
||||
|
||||
谷歌自建轮子是一件可以理解的事情,“三驾马车”的出现才真正把人类带入了大数据时代。毕竟没有谷歌就没有大数据,更不会存在“某个软硬件体系可以低成本高效率地解决整个互联网数据的分析和存储”的事情。可以不夸张地说,它的前方基本一片空白,于是在“自建轮子”这件事上,谷歌没有多少选择权。
|
||||
|
||||
谷歌的目标是做世界上最好的搜索引擎,因此它需要大数据相关的基础架构。没有这套东西,就没有谷歌这个搜索引擎,有了这套东西,才能继续把搜索做下去。至于这个东西需要消耗多少成本,对谷歌来说都是没有办法的事儿。
|
||||
|
||||
更为重要的是,大数据这个概念,以及和这个概念相关的一切技术架构,在谷歌开始发明之前都是不存在。所以谷歌只能选择从无到有自建轮子开发大数据的基础架构。
|
||||
|
||||
不过从另一个角度来说,从无到有地把这一套东西搭起来,这无疑也是谷歌对全世界最大的贡献。
|
||||
|
||||
至于微软为什么要建设自己的轮子,原因也并不复杂。在微软大规模投钱进入搜索领域的时候,谷歌已经发明了自己的轮子,但是市面上公开的轮子,那个叫Hadoop的东西,还非常简陋不好用。
|
||||
|
||||
那个年代的微软很傲娇,对待开源相当抵制。看不起Hadoop这个在当时看来像是玩具一样的东西,更不要说Hadoop又是以微软特别讨厌的Java语言开发的。
|
||||
|
||||
于是,对于微软来说选择也不多。Hadoop不可用,谷歌的东西不可得,而微软又非要在那个时间点把搜索做起来,就只能自己搭了。
|
||||
|
||||
那时候呢,微软对自己的技术实力、人才储备以及资金都很有信心,所以选择自建轮子时的底气我们是可以想象的。不过,当时的微软是否过度自信了,那就是另外一个问题了。
|
||||
|
||||
阿里巴巴是我知道的,第三个自己搭建轮子的公司,它的MaxCompute系统,原来叫作ODPS。
|
||||
|
||||
阿里巴巴的系统对于远在美国的我来说更陌生一些。至于为什么阿里巴巴会自己搭建系统,原因我也不是特别清楚,但基本上也不外乎是“开源系统不可用,无意去共建开源系统抱团取暖,又对自己的技术实力、人才储备以及资金有信心”这些原因吧。
|
||||
|
||||
但话又说回来,自建轮子是一件非常不容易的事情,特别是当自建轮子的公司希望有所创新,而不是亦步亦趋盲目模仿的时候。
|
||||
|
||||
谷歌的不易我们可想而知,从无到有地把东西发明出来,离不开谷歌天才般工程师们的贡献,比如我们现在耳熟能详的杰夫·迪恩(Jeff Dean)就是其中的一员。
|
||||
|
||||
有了谷歌的先驱以后,Hadoop采取的方式是亦步亦趋模仿谷歌的论文;但是Hadoop的产品并不好,和谷歌的系统不能比,至今也依然有很多为人诟病的地方。
|
||||
|
||||
微软在建设Cosmos的时候,和Hadoop的做法挺不一样的。Cosmos是微软投入极其巨大的一个项目,它的投入主要体现在两方面。
|
||||
|
||||
一是Cosmos的开发团队集中了微软内部各个技术领域的专家精英,涉及了分布式系统,存储,压缩,分布式数据处理,查询优化等多个领域。
|
||||
|
||||
二是为了运营Cosmos,微软投入了好多个数据中心,总机器容量超过10万台;而这些机器平均在三年内就会被淘汰。由此可见,为了开发和运营Cosmos,微软可谓不计血本。
|
||||
|
||||
除此之外,为了让Cosmos这个产品成熟起来,微软冒了很多风险,也付出了巨大的代价。这些代价和风险体现在两方面。
|
||||
|
||||
一方面体现在Cosmos系统早期对计算机资源的巨大浪费。在Cosmos的早期,由于系统本身开发成熟度不够,于是系统对计算机资源(包括内存、CPU和网络)的使用都不是最优的,很多时候甚至有效利用率连50%都不到。这些被浪费的资源可谓非常巨大。
|
||||
|
||||
另外一个方面,为了帮助Cosmos早日成熟。必应搜索引擎在Cosmos还不够完善的早期阶段,就把很多核心业务从相对稳定的SQL Server集群上迁移到Cosmos上来,让业务承受巨大风险,和Cosmos一起成长和成熟。
|
||||
|
||||
在Cosmos的早期,因为系统的问题导致计算结果出现错误,进而影响了整个业务的成本和收益的核算,是司空见惯的问题。甚至是类似数据永久丢失这样的事情,也曾经发生过若干次。
|
||||
|
||||
其中最为著名的一次是由于Cosmos里一个很难发现的Bug,导致系统误删了大量数据。虽然经历了艰难的数据恢复过程,但是有10%的数据依然永久丢失了,这里面就包括必应广告团队的一些核心数据,它们的丢失直接影响了微软广告的营收。
|
||||
|
||||
然而,即使是需要如此巨大的投入,即使有可能造成计算资源的极大浪费,甚至可能会让业务陷入非常严重的问题,微软对Cosmos的开发、运营和使用的支持仍然始终如一。
|
||||
|
||||
据我所知,阿里巴巴的MaxCompute平台的发展过程也很类似。比如说,阿里巴巴集团内部把某些贷款业务放在了MaxCompute平台上,让业务本身和平台一起成长。这种成本很多时候非常巨大。
|
||||
|
||||
自建轮子的成本是非常高的,然而一旦轮子建成并稳定运行以后,其收益也是非常巨大的。无论谷歌、微软还是阿里巴巴,借助其内部平台强大的分析能力,给自身业务的发展提供的强力支持,绝非是一个Hadoop平台可以媲美的。
|
||||
|
||||
既然自建平台好处多多,为什么没有其他企业自己建设轮子呢?
|
||||
|
||||
首先,有时不是愿不愿意的问题,而是能不能的问题。 要具备自己建设轮子的能力,并且这个轮子还要好用,确实需要方方面面的积累。在整个互联网行业里,具备自己建设轮子能力的公司,并不是很多。
|
||||
|
||||
其次,这些公司到底有没有自己建轮子的需求。 这也是一个问题,比如说,做搜索需要存整个互联网的数据,还需要对用户访问互联网的日志文件进行分析,这就对轮子本身能够存储和处理数据的规模提出了很高的要求。在很长一段时间里,Hadoop是做不到的,但是这个世界上只有少数公司需要如此大规模的数据存储和处理能力。很多公司既然不需要,那么也就不一定非要建设这样的轮子了。
|
||||
|
||||
最后,这还和公司文化有关系。 对待开源社区的态度,决定了这些公司是愿意合作建轮子,还是自建轮子。
|
||||
|
||||
自建轮子解决内部事情,是一个很好的做法,但是不忘初心这件事情也挺难的。那些自建轮子成功解决内部问题的企业,都有把自己建设好的轮子包装一下卖给外部客户的想法。
|
||||
|
||||
比如说谷歌搞了App Engine,让用户可以通过API来用它的三架马车。微软则在2015年推出了Cosmos的企业版:Azure Data Lake。从ODPS改名的MaxCompute更是阿里巴巴在云端主推的产品。
|
||||
|
||||
但是很有意思的是,这些内部非常成功的产品,在对外以云产品销售的过程中,都惨败地一塌糊涂。
|
||||
|
||||
没有人买账,这是一个非常有趣的现象。我想原因也是多方面的。第一个方面是Hadoop生态圈对大部分企业够用了。大部分企业对数据的处理到不了微软谷歌阿里巴巴的量级,不需要自建的轮子,而Hadoop相对普及,大家都用得比较顺手。
|
||||
|
||||
第二个方面是这些轮子都是专有工具,使用任何一个专有工具就意味着让自己锁定进了这个平台。这是很多企业不愿意做的。所以成功解决内部需求的自建轮子,却在外部市场上屡屡折戟。
|
||||
|
||||
总而言之,自建轮子是一件成本非常高昂的事情,并非对每个企业都适用。所以这个世界上真正自建轮子的企业并不多。每个自建的轮子在服务其内部业务的时候,都很成功。
|
||||
|
||||
然而不忘初心这件事情挺难的。每家自建的轮子最终都在试图卖给第三方,却一个也没做成过生意。究其原因,做事情还是需要初心的。当初为了服务内部业务的目的而构建的系统,本非为外部客户服务,结果却强行扭转,非要做成服务外部,犹如强扭的瓜,到底甜不甜,可想而知。
|
||||
|
||||
|
||||
|
||||
|
||||
65
专栏/技术与商业案例解读/085大公司的大数据战略得失:抱团取暖难敌插管吸血者.md
Normal file
65
专栏/技术与商业案例解读/085大公司的大数据战略得失:抱团取暖难敌插管吸血者.md
Normal file
@@ -0,0 +1,65 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
085 大公司的大数据战略得失:抱团取暖难敌插管吸血者
|
||||
开源项目最讨厌的就是只进不出的参与者。一个公司如果只把开源项目拿去赚钱,却不拿自己的改动和成果反哺社区,开源项目就难以持续发展下去。
|
||||
|
||||
所以,抱团取暖的前提是大家都愿意主动贡献自己的成果,但亚马逊是一个另类,它从开源社区拿了很多东西却从不贡献开源。这样只会“插管吸血”的亚马逊,是不是会就此破坏了开源社区良好的氛围呢?
|
||||
|
||||
在大数据的发展战略上,除了自建轮子的谷歌、微软和阿里巴巴,各大公司大多走向了一条抱团取暖的道路;而这个抱团取暖的产物,就是你搭一个模块、我搭一个模块,大家一起开源出来,组成了一个叫作Hadoop的生态圈。
|
||||
|
||||
如果要具体来说一说,雅虎当然是Hadoop生态圈里最大的贡献者,但是Facebook、Twitter和LinkedIn的贡献也不算少。eBay和IBM的功劳自然也不可忽略,大家前前后后都做了不少事。最近来说,加州大学伯克利分校的AMP实验室的Spark贡献也是十分突出。
|
||||
|
||||
为什么这些公司会选择抱团取暖?我简单总结了一下,主要有3个原因:
|
||||
|
||||
|
||||
技术和资源储备还不够,单靠自己没法搭建起来;
|
||||
业务需求不迫切,还没到非要自己搭轮子的地步;
|
||||
公司可以熟悉开源文化,通过这种方式,公司对开源社区会更加友好。
|
||||
|
||||
|
||||
那么,这些公司的“抱团取暖”带来了哪些好处呢?
|
||||
|
||||
首先,这些参与其中的公司们在很长一段时间内保持了亲密合作关系,也很快让Hadoop生态圈变得丰富起来,变得越来越可用,越来越实用。
|
||||
|
||||
其次,这也让更多并未参与其中的创业公司获得加持,以极低的成本获得了大数据分析的能力。湾区的创业氛围因此变得无比美好,客观来说这样的合作确实促进了创业的发展。毕竟创业者更需要关注业务逻辑,而具体的系统实现可以利用开源社区的产品和架构来快速解决。
|
||||
|
||||
只是在很多时候,有钱能捡的话,就一定会有人去捡。随着这个生态圈的壮大,试图通过这个生态圈牟利的人和公司也越来越多,而这在很大程度上违背了雅虎、Facebook、Twitter和LinkedIn等公司最初的设想。
|
||||
|
||||
首先出现的当然是把Hadoop打包卖给其他企业的公司。Cloudera就是这样一家公司,MapR也是,Hortonworks也是,而最后这家公司干脆原本就是雅虎的Hadoop团队,他们看着别人捡钱心里不爽,所以特意从雅虎跳出来创建的。
|
||||
|
||||
然而,和当初抱团取暖时“难兄难弟们”的无私贡献相比,因为是带着明确的商业目的,这一类公司对于Hadoop的态度就多少有些不一样了。
|
||||
|
||||
不过,就算它们的目的是为了把东西卖出去,很多事情还是要做好的。相较来说,毕竟当时的Hadoop作为抱团取暖的产物,很多时候只算是一个可以用,却并不是最好用的东西。对于那些传统企业来说,Hadoop的方方面面都不符合他们的要求,比如安全问题、使用者的权限管理和监控、效率和资源的消耗等等方面都不尽如人意。
|
||||
|
||||
这样看来,我们必须说,Cloudera和Hortonworks对于Hadoop本身的发展是投入了大量资源的,对于Hadoop相关生态圈的模块也是投入了很多人力物力的。即便这些公司是打算靠这个赚钱的,它们也的确是为Hadoop生态圈的繁荣贡献了自己的力量。
|
||||
|
||||
不过,在Hadoop生态圈里面赚钱最多的显然不是这些公司。Hortonworks股票上市以后估值掉了50%,Cloudera在上市前自砍50%的估值血淋淋地上市,这两件事情都说明这个行当的利润并没有想象中那么高。这些公司虽然都活着,但是恐怕活得也是有些艰辛。
|
||||
|
||||
要是说哪家公司借着Hadoop生态圈的东风,迅速青云直上了?无疑是亚马逊。亚马逊的AWS之所以能如火如荼地开展起来,离不开Hadoop生态圈的贡献。亚马逊的Elastic MapReduce服务自推出以后就非常受欢迎,这个云上的Hadoop系统,给亚马逊带来了滚滚红利。
|
||||
|
||||
但是回头看一下亚马逊到底给这个生态圈做了什么贡献呢?几乎屈指可数。即使不能说是零,起码也可以说是无限接近于零了。虽然它也有一些代码提交,但主要还是为了解决Hadoop生态圈与亚马逊其他云服务如何打交道的能力。也就是说,亚马逊做出的最大贡献,是解决了Hadoop集群如何同亚马逊的云存储S3连接的问题。
|
||||
|
||||
一方面是赚到了很多的钱,一方面则是毫无贡献。这个只负责插管吸血的亚马逊,无疑在商业上获得了非常大的成功。而我们也很难去苛责亚马逊,毕竟开源系统拿过来用,回头要不要反哺开源系统,很多时候也只是公司自己决策的问题。
|
||||
|
||||
尤其是开源社区的授权方式本身就有很大的Bug。Hadoop社区通行的Apache授权方式,不要求商业公司必须公开修改后的源代码。即使是更严格的GPL授权方式,商业公司依然有无数的办法可以绕过去。所以最终来看,商业公司要不要反哺开源系统,基本上靠大家的自觉。
|
||||
|
||||
但是有一点是可以肯定的,如果每个公司都学习亚马逊的做法,那么Hadoop生态圈在一开始就不可能构建出来。毕竟如果没有很多互联网公司的开源,也就不可能有完善可用的生态圈。
|
||||
|
||||
所以,亚马逊这样的做法,实际上是有碍开源社区繁荣的。我想很多做大数据开源的人,肯定对亚马逊的做法颇有微词。
|
||||
|
||||
只是从开源社区来看,Apache基金会也没有什么行之有效的办法,去阻止别人像亚马逊一样使用这些开源软件,既然没有约束,那么亚马逊的做法则显得合理又合法,那么我们究竟应该用什么态度来看待这样的一家公司呢?
|
||||
|
||||
我个人对亚马逊的感情其实是很复杂的。首先,亚马从很多方面来看都是一家伟大的公司,它所推崇并遵循的亚马逊领导力准则,更是值得每一位有志于做出一番事业的互联网从业者认真学习了解,并深刻理解。这些简单而深刻的准则,我不敢说是普遍适用的真理,但是起码对我个人来说受益非常大。
|
||||
|
||||
但是从另外一个方面来看,亚马逊这个公司没有“取之于社区,用之于社区”的观念。亚马逊对客户是很好的,对社区就不一定了。一个只是不断从社区获取,却不愿意贡献给社区的公司,破坏的是整个社区的氛围和默契。
|
||||
|
||||
如果这个公司籍籍无名,也没有因此发家致富,那它的破坏力还不是那么强。而一个公司如果保持如此作风同时在大量地赚钱,那无疑是树立了一个坏的榜样,这种破坏力是极为巨大的。
|
||||
|
||||
开源社区发展到今天,已经度过了不成气候的阶段,现在也有了很多非常有影响力的项目。但是如果还是不能找到有效的管理方式来表彰贡献、控制索取,长久来看可能会出现越来越多对开源“插管吸血”的公司,这对开源社区来说显然会是一件极其不利的事情。
|
||||
|
||||
|
||||
|
||||
|
||||
61
专栏/技术与商业案例解读/086Palantir:神秘的大数据独角兽.md
Normal file
61
专栏/技术与商业案例解读/086Palantir:神秘的大数据独角兽.md
Normal file
@@ -0,0 +1,61 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
086 Palantir:神秘的大数据独角兽
|
||||
在大数据领域,Palantir无疑是知名度非常高,却又带着强烈神秘色彩的公司。因为大家虽然都知道它是做大数据的,其产品在很长一段时间里却几乎没有办法从市面上看到。
|
||||
|
||||
为什么?因为它最初的服务对象都是美国国防部(DOD)、中央情报局(CIA)、联邦调查局(FBI)等非常敏感的政府机构。庆幸的是,自从它开始把业务拓展到金融领域之后,终于向世人揭开了一部分神秘面纱。
|
||||
|
||||
Palantir的创始人彼得·蒂尔(Peter Thiel)是硅谷著名的企业家和投资人。他于1998年创建了 PayPal,该公司在上市后不久的2002年被 eBay 收购,他也因此获得了人生第一桶金。
|
||||
|
||||
PayPal,从很大程度上来说,是彼得·蒂尔为理想而创建的公司,并非为了金钱。彼得·蒂尔在斯坦福读书时,就表达了自己保守主义的政治理念,在9·11事件以后更是觉得国家通过监控个人行为来阻止可能存在的破坏和犯罪活动是应该的,而之后成立Palantir就是为自己的这种理念提供技术支撑。
|
||||
|
||||
Palantir注册于2003年,正式成立于2004年,那个时候彼得·蒂尔与几位工程师开发出了第一版的系统。同一年,他邀请了亚历克斯·卡普(Alex Karp)任公司CEO。说起亚历克斯,他和彼得·蒂尔曾经是斯坦福法学院的同学,毕业后去了德国读哲学博士,研究西方马克思主义哲学。总之,最后的结果就是:一个投资人为了理想成立了 Palantir,一个哲学博士则成了这个大数据公司的CEO。
|
||||
|
||||
Palantir 成立之初,资金主要来自两部分:一部分是美国中央情报局下属的投资机构 In-Q-Tel 投资的200万美元,也正是 In-Q-Tel 这种资金来源渠道让Palantir一开始就和政府有着千丝万缕的联系;另一部分资金是彼得·蒂尔自己投入的3000万美元,这主要来自于他卖掉 PayPal 的所得。
|
||||
|
||||
虽说 In-Q-Tel 投资的科技公司不少,比如我们耳熟能详的大数据公司 Cloudera 和数据库公司 MongoDB 都接受过 In-Q-Tel 的投资,但是相对来说,Palantir 是比较早期就拿了In-Q-Tel 投资的公司,并且 In-Q-Tel 对Palantir的期望也颇高。
|
||||
|
||||
Palantir早年最重要的产品是Palantir Gotham,简单来说这是一款给政府部门用的大数据分析软件,这里的“政府部门”当然是指国防部、中央情报局、联邦调查局等机构。也因此,这款软件非常神秘,见过的人很少。网上虽偶尔有截图流传出来,但是没有人能够肯定说这就真的是Palantir Gotham 软件的截图。
|
||||
|
||||
所以我们并不知道Palantir到底使用了什么样的技术,做了什么样的产品。但是有关Palantir的产品帮助美国政府发现攻击之类的故事却非常多,这些故事也在很大程度上增加了这个公司的神秘性。
|
||||
|
||||
外界关于Palantir的小道消息很多,包括其软件如何被美国军方应用到多兵种联席作战指挥中,美国政府是如何在Palantir 软件的帮助下抓获本·拉登的,等等。事出有因,查无实据,倒似乎可以作为我们对Palantir Gotham的一个总结。
|
||||
|
||||
时至今日,关于这款产品我能够知道的唯一信息就是:它确实存在。
|
||||
|
||||
有传言称:Palantir公司内有一个办公室,所有玻璃都是防弹玻璃;这个办公室就是给CEO亚历克斯用的;亚历克斯日常就有政府高官才会配备的联邦保卫人员,出行必须穿防弹衣、配备一定级别的安保等等。这所有的传闻,都让公司显得异常神秘,也让它在外界眼中显得更有势力,和整个美国的权力部门有很深、很密切的联系。
|
||||
|
||||
Palantir在给政府部门提供大数据分析支持的一段时间以后,又开始进军金融行业。正是这样,Palantir Metropolis 应运而生,它主要面向金融公司,比如高盛、摩根大通之类的投行。
|
||||
|
||||
据说这款软件给予金融行业各种各样的能力,帮助金融企业发现了很多的欺诈问题,挽回了不少的损失。但是相较于Palantir Gotham,因为这款新软件服务的对象是金融机构,所以神秘性也就降低了不少。
|
||||
|
||||
参与Palantir Gotham软件工作的人员是需要通过美国政府背景调查的,而Palantir Metropolis 因为主要面向商业软件,所以工作人员不需要走背景调查程序。
|
||||
|
||||
我在2014年的时候参加过Palantir的面试,个人感觉其整个面试过程非常地压抑。进门之前要先过一道类似机场的安检门,然后拍照;进入公司以后,我还被要求只能在特定区域内待着,不能随便走动。当然,事先面试官就告诉我这个面试是面向Palantir Metropolis的,而不是Palantir Gotham。
|
||||
|
||||
作为面试环节的一部分,Palantir的员工给我们演示了这个软件,当然拍照和摄像都是不被允许的。Palantir Metropolis当时给我的感觉就是:见面不如闻名。
|
||||
|
||||
我来面试之前,对这款为金融行业服务的软件期望特别高,但是在演示中我并没有看到任何一点值得惊艳的地方,我个人感觉这个软件展示的功能非常对不起Palantir公司那种神秘的味道。
|
||||
|
||||
大约是我“乘兴而来、败兴而归”的缘故吧,公司对我也不满意,所以双方等于是“互拒”了。
|
||||
|
||||
Palantir这家公司除了神秘,还存在很多非议,比如:公司到底要不要上市?
|
||||
|
||||
CEO亚历克斯曾经在某次接受采访时表示了公司不打算上市的观点。初创公司不上市,对员工来说或许不是什么好事儿,因为员工手里的股票就没有渠道轻松变现了。不过,对于Palantir这样的公司来说,不上市或许是好事儿,因为上市就需要披露很多信息,这对其和美国政府之间的合作并不友好。
|
||||
|
||||
Palantir还有一点备受非议,就是招聘时对亚裔面试者的歧视。2016年,美国劳工部对Palantir提起诉讼,原因是Palantir公司在招聘过程中,长期一贯地终止亚裔面试者的录用资格,哪怕他是合格的。
|
||||
|
||||
2017年4月,这场官司以Palantir赔偿170万美元的方式庭外和解。但是Palantir依然公开宣称,公司并无对亚裔的歧视。至于这话是否可信,我想大家心里都有公论吧。
|
||||
|
||||
此外,2016年有文章说Palantir公司有大量员工离职,公司临近破产边缘。不过,这个事情随着彼得·蒂尔给特朗普(Trump)大量捐款,此后特朗普又顺利成为美国总统而慢慢销声匿迹,随后Palantir 还获得了政府的大量订单。我想彼得·蒂尔对特朗普的政治献金对于缓解公司窘境应该是起到了很大的作用。
|
||||
|
||||
从Palantir这个公司我们可以看到,创业的时候我们需要考虑公司怎么做生意。和政府关系密切本身是做生意的一种办法,Palantir显然在互联网行业里把这种办法拔高到了一个一般公司无可企及的高度,这给Palantir的发展带来了大量便利。但是凡事有利有弊,和政府的紧密结合也为Palantir的公司发展带来了障碍,比如企业上市的问题。
|
||||
|
||||
彼得·蒂尔是一个个性鲜明的人,Palantir这家企业的争议性也非常得大。个性鲜明和争议性本身并无对错,但是对于创业者和创立的企业来说,是不是每个都能在大的争议性中不倒并且还能发展,就不一定了。大部分创业者和企业,争议性小一点,也许更好。
|
||||
|
||||
|
||||
|
||||
|
||||
65
专栏/技术与商业案例解读/087Splunk:机器大数据的分析帝国.md
Normal file
65
专栏/技术与商业案例解读/087Splunk:机器大数据的分析帝国.md
Normal file
@@ -0,0 +1,65 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
087Splunk:机器大数据的分析帝国
|
||||
在大数据圈里,Splunk是一家赫赫有名的企业,主要分析机器运行时产生的日志数据,是机器日志数据分析领域当之无愧的老大。
|
||||
|
||||
Splunk在上市之前就实现了盈利,上市之后利润更是不断增长。无论是不断扩展的产品领域,还是其逐年递增的盈利能力,Splunk都是所有上市大数据公司里首屈一指的。今天我就带你去看看这家公司的发展历程。
|
||||
|
||||
Splunk成立于2003年,主要创始人是迈克尔·巴姆(Michael Baum)、罗布·达斯(Rob Das)以及埃里克·斯万(Erik Swan),早期的投资主要来源于August Capital、Seven Rosen、Ignition Partners 以及 JK&B Capital。截至2007年,公司一共获得了4千万美元的投资。
|
||||
|
||||
2009年,美国经济危机爆发,但 Splunk 并没有受到冲击,甚至还实现了盈利。2012年,公司正式在纳斯达克上市。那么,是什么让Splunk获得了成功呢?下现我就来说一说。
|
||||
|
||||
Splunk的核心竞争力在于搜集和分析大量机器产生的数据。它的产品线有很多,最初成名的产品是Splunk Enterprise。这是一个用于搜集和分析数据的软件,在很多公司里它最大的作用是把机器产生的日志文件搜集起来,然后在这个日志文件上做查询。
|
||||
|
||||
Splunk Enterprise这款软件价格不菲,但是相较于市面上的同类产品,无论是功能还是可用性都优秀很多,它在这个领域里面占据了不可取代的位置。比如我现在任职的企业,也花了很多资金买了Splunk Enterprise,来给我们的云计算服务做日志分析。
|
||||
|
||||
Splunk的这套软件对于云服务提供商尤其有帮助。云服务提供商每天要应对“无数”客户“五花八门”的服务,其一天产生的日志文件就是一个天文数字。因此,有效去分析这些日志文件,并帮助进行问题诊断,是一件非常不容易的事情。目前很多云服务提供商都买了这套 Splunk 软件进行分析,谷歌云在2016年还宣布和Splunk的分析平台进行整合。
|
||||
|
||||
Splunk以提供软件作为解决方案起家,并因此做大。但是随着整个世界在往云上迁移,Splunk也开始进军云市场。2011年,它推出了一款叫做Splunk Storm的云端产品。这是Splunk卖给企业的Splunk Enterprise的一个云端服务,但提供的功能要比Splunk Enterprise弱一些。
|
||||
|
||||
可能是传统软件厂商第一次进军云计算的原因,这个服务非常不成功,基本上没多少人用。到了2013年,Splunk干脆宣布Splunk Storm完全免费。但是免费也没有拯救Splunk Storm。于是Splunk在推出第二代云产品之后,过了两年,也就是2015年关停了Splunk Storm。
|
||||
|
||||
Splunk在云端的第二次尝试是一个名字叫做Splunk Cloud的产品,于2013年推出。Splunk Cloud可以看成是Splunk Enterprise在云端的一个完整服务。
|
||||
|
||||
与Splunk Storm的做法不同,这次Splunk完全重写了整个软件体系,让它适应云架构。同样不同的是,Splunk Cloud推出以后,就受到了很多用户的欢迎。这和两年前Splunk Storm推出时候的情况不可同日而语。可见用户需要的是一个完整版的Splunk Enterprise,而不是一个阉割版的从众产品。
|
||||
|
||||
一个企业上市以后,如何拓展业务也是需要重点考虑的问题。Splunk最初擅长的是机器产生的日志数据的存储和分析,这个核心竞争力如果可以和其他东西结合,也许就可以创造出新的盈利增长点和新的产品。那么如何与其他东西结合呢?解决办法之一就是:收购。
|
||||
|
||||
Splunk在2013年收购了Bugsense,这是一个给开发人员使用的、对移动APP的数据进行分析的创业公司。这个收购比较保密,至今不知道收购金额是多少,我也不太清楚这个公司的收购到底给Splunk带来了什么。2015年,Splunk再次出手,收购了一家做网络安全的初创公司Caspida,收购价是1.9亿美元。
|
||||
|
||||
有了这两次收购,Splunk开始进军网络安全领域,Splunk Enterprise Security就是一款安全产品。那么,Splunk为什么要关注于企业安全问题呢?
|
||||
|
||||
|
||||
第一,这个问题是企业永恒的话题,无论哪个企业都愿意砸钱在企业安全上。
|
||||
第二,Splunk对机器产生的日志数据的强大分析能力,也使它在进入企业安全这个领域上有非常独特的优势。
|
||||
|
||||
|
||||
当然,网络安全是需要大量积累的。Splunk不可能“万丈高楼一夜起”,所以收购一个网络初创公司,融入其技术到Splunk的数据分析平台里面,也就成了Splunk进军企业安全的捷径。
|
||||
|
||||
在企业安全的路上,Splunk最有里程碑意义的事件是2015年和美国政府的安全提供商 Booz Allen Hamilton签署了企业安全联盟协议,两者合作提供企业安全监测和分析技术。因为美国政府对安全提供商有特殊的资质要求,必须经过政府认可的才可以被采购,所以Splunk这相当于曲线救国,把自己的产品卖进了政府部门。这是一个非常傲人的成绩。
|
||||
|
||||
除了进军企业安全以外,Splunk还推出了一款产品:Splunk IT Service Intelligence。这款产品主要面向的是企业IT人员,通过对企业IT数据的分析,告诉IT人员整个企业的IT状况。这款产品提供了一个统一的界面,对IT性能和功能进行全面地监控;而且通过对事件的监督,也可以告诉IT部门企业当前存在的问题。
|
||||
|
||||
随着机器学习的火热,Splunk这个能够大量分析和处理机器数据的企业,当然也不会放过这个热点,转而推出了最新相关产品Splunk User Behavior Analytics,并号称这是一款完全基于机器学习的产品。
|
||||
|
||||
这款基于机器学习的产品可以告诉企业的管理人员,自己企业里的哪些人员正在做着不正常的举动。按照Splunk的说法,这款软件提供了对企业内部潜在威胁的监控和预测,而且还可以和已有的其他软件配合,进一步提高企业的安全性。
|
||||
|
||||
整体来讲,Splunk起源于一个对机器数据快速搜集和查询的软件,此后在此软件基础上进行了云端的扩展,但是这个公司最近几年新的领域开发主要集中在企业安全这个领域。除了传统的企业安全技术以外,该公司还特别强调使用机器学习来进行企业安全分析。换句话来说,Splunk已经从自己的核心技能出发,演变开发出了若干个不同类型的软件。
|
||||
|
||||
这些年来,想要做机器日志数据分析的公司非常多,但是在这个领域做成功的当属Splunk。而从这些年的财报看,Splunk不仅仅是在盈利,而且是在稳步扩大它的盈利,这在所有的大数据公司里面都是非常罕见的。
|
||||
|
||||
我想Splunk之所以能成为一个非常成功的公司,主要有两个方面的原因:
|
||||
|
||||
|
||||
第一,立足其核心价值。Splunk对机器日志文件大数据的强大分析能力一直是其成功的基础。
|
||||
第二,在核心价值以外,非常努力地多元化发展。
|
||||
|
||||
|
||||
企业多元化一直都是一个值得讨论的话题。有的企业靠多元化发扬光大,有的则在多元化中走下坡路。Splunk在紧守自己核心领域的同时,也不断努力地多元化。目前看来,它的多元化是很成功的。亲爱的读者,你是怎么看待一个企业在核心领域取得成功以后,是否要多元化发展的问题呢?如果要多元化的话,又应该怎么样去做呢?
|
||||
|
||||
|
||||
|
||||
|
||||
43
专栏/技术与商业案例解读/088Confluent:在Kafka上飞驰的数据交换者.md
Normal file
43
专栏/技术与商业案例解读/088Confluent:在Kafka上飞驰的数据交换者.md
Normal file
@@ -0,0 +1,43 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
088 Confluent:在Kafka上飞驰的数据交换者
|
||||
今天我们要讲的大数据公司叫作Confluent,这个公司是前LinkedIn员工出来后联合创办的,而创业的基础是一款叫作Apache Kafka的开源软件。
|
||||
|
||||
在整个Hadoop的生态圈里,Kafka是一款非常特殊的软件。它由LinkedIn于2011年开源,并在2012年底从阿帕奇孵化器里面毕业,正式成为阿帕奇的顶级项目。
|
||||
|
||||
Kafka和其他的大数据平台都不同,它的主要目的不是数据的存储或者处理,而是用来做数据交换的。要更好地理解它是干什么的,我先谈一下数据库的日志文件。
|
||||
|
||||
数据库系统需要保证数据的稳定性,为了确保修改的数据能够写入库,通常会在更改数据之前先在磁盘里写一条日志文件,大致上的格式是“时间戳:做了什么操作”。如果此后因为故障导致数据本身没有被更改,系统可以根据日志文件一条一条地重新执行操作,让数据恢复到应该恢复的状态。
|
||||
|
||||
后来有人意识到,这个日志的恢复功能还可以充当数据复制。简单来说,如果两个数据库的初始状态相同,又按照同样的顺序执行了一系列操作,那么最后的状态也相同。所以在数据库进行数据复制的时候,系统可以把日志文件从一个系统传输到另外一个系统,另外一边只要照着日志同样地执行一遍就好。
|
||||
|
||||
这个想法构成了大部分数据库的主从备份机制的核心,而Kafka则把这个机制充分发扬光大了。Kafka允许消费者和生产者注册进Kafka,其中生产者会产生日志,而消费者则消费产生的日志。整个系统允许多个消费者和多个生产者的注册,这就实现了公司内部不同数据源之间的数据交换。
|
||||
|
||||
Kafka作为开源产品是如此之成功,在整个Hadoop生态圈,乃至不用Hadoop,而是用其他数据源的产品里,它都可以用来进行数据的备份和交换。所以,我们可以看到几乎所有的互联网公司里都部署了Kafka。
|
||||
|
||||
2014年的时候,Kafka的三个主要开发人员从LinkedIn出来创业,开了一家叫作Confluent的公司。和其他大数据公司类似,Confluent的产品叫作Confluent Platform。这个产品的核心是Kafka,分为三个版本:Confluent Open Source、Confluent Enterprise和Confluent Cloud。
|
||||
|
||||
Confluent Open Source是Confluent公司在Kafka上的一个增强版本,其主要增强的地方是:增加了一个REST代理,以便客户端可以使用HTTP连接;增加了对Java以外的语言的支持,比如C++、Python和.NET;增加了对Hadoop文件系统、亚马逊S3存储、JDBC等的连接的支持;最重要的是一个Schema Registry,这是对Kafka一个比较大的增强,它使得Kafka的数据流必须符合注册的Schema,从而增强了可用性。所有这些东西本身也都是开源的,这使得其他第三方在这个上面继续开发新功能成为了可能。
|
||||
|
||||
Confluent Enterprise是Confluent面向企业级应用的产品,里面增加了一个叫作Confluent Control Center的非开源产品。Confluent Control Center是一个对整个产品进行管理的控制中心,最主要的功能对这个Kafka里面各个生产者和消费者的性能监控。
|
||||
|
||||
Kafka作为一个非常重要的产品,已经在很多互联网企业里被作为关键组件部署了。而Kafka的性能监控也早就是一个非常重要的问题,Kafka本身并不自带性能监控平台,很多公司比如雅虎自己内部开发了这样的系统。但是Confluent开发的控制平台无疑应该是最可靠的,毕竟没有人比Kafka的开发者更了解自己的产品。可惜这个是收费产品,而且不开源。Confluent Enterprise同时还自带了数据自动负载平衡和跨数据中心数据复制的能力。
|
||||
|
||||
Confluent Cloud是Confluent Enterprise的云端托管服务,它增加了一个叫作云端管理控制台的组件。除此之外,按照Confluent的说法,其实没有什么差别。但是对于想要省心的用户来说,这个产品无疑是更好的选择。
|
||||
|
||||
Confluent的基本做法和Cloudera很像,主要的产品开源,但是控制中心这样的东西不开源,只有买了企业版才能够享受到。而两者不同的地方主要在于,Confluent同时提供了云端服务的版本。加上Confluent有基于S3的连接,这使得从亚马逊AWS读写数据都非常方便。
|
||||
|
||||
和Cloudera是Hadoop的集成商不同,Confluent主要还是围绕着不同数据源之间数据的交换这个任务而生的服务。Kafka在整个开源产品里面是一个非常特殊的存在,它没有什么竞争对手,又是各大企业的刚需,它在脱离了整个Hadoop生态圈以后依然非常有价值。
|
||||
|
||||
从这个角度来讲,Confluent毫无疑问有很多客户会买单。大部分企业都不可能只有一个数据源,当然谷歌这样的企业除外。而Kafka给数据源之间的数据交换提供了统一的平台,而Confluent的企业级服务则让这个平台不但更好用了,而且更好管理了。
|
||||
|
||||
虽然说是同样的生意模式,用在不同的产品里,产生的结果却可能很不一样。Confluent作为一家公司,是否能够从Kafka这个数据交换平台里面跳出来继续扩张,这很难说。但是仅仅是把这一摊生意做好,也足以支撑Confluent成为一个估值不低的公司,养活自己应该是绰绰有余了。
|
||||
|
||||
Confluent最近拿到了5000万美元的融资,其CEO在接受采访的时候表示公司还将继续扩张。像Confluent这样的平台,在未来物联网的架构上,还有足够多的空间,这大概表示了Confluent未来将重点发展的方向。
|
||||
|
||||
|
||||
|
||||
|
||||
82
专栏/技术与商业案例解读/089Powerset:HBase的老东家.md
Normal file
82
专栏/技术与商业案例解读/089Powerset:HBase的老东家.md
Normal file
@@ -0,0 +1,82 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
089 Powerset:HBase的老东家
|
||||
谷歌的“三驾马车”,即谷歌文件系统、MapReduce、BigTable,被誉为计算机科学进入大数据时代的标志。
|
||||
|
||||
作为开源大数据的标杆:Hadoop,它的开发者道格·卡丁(Doug Cutting),最初在实现自己的爬虫Nutch的时候,只实现了Hadoop文件系统和Hadoop MapReduce,并未实现BigTable。所以在很长一段时间里,BigTable在Hadoop的生态圈里是缺失的。
|
||||
|
||||
对于这种缺失,我们也可以理解为:无论是在爬虫还是当时Hadoop的几大生态圈里,大家对BigTable的需求并没有另外“两驾马车”那样强烈。
|
||||
|
||||
真正在Hadoop的生态圈里实现BigTable的开源版的,是一家叫做Powerset的公司推出的HBase项目。HBase代码量大,架构复杂,但是很多代码都写得非常优雅。与Hadoop文件系统和Hadoop MapReduce的快、糙、猛相比,HBase的出现无疑让人眼前一亮。
|
||||
|
||||
曾经的Powerset也是十分著名的创业公司,它创业的领域是下一代搜索引擎:自然语言搜索引擎。在今天,它却没有了当初的名气,为什么这么说呢,接下来我就会说到。
|
||||
|
||||
那么,这个曾经开发了HBase的创业公司,现在又是怎样的情况呢?今天我们就一起来了解一下。
|
||||
|
||||
2004年,谷歌成功上市,它是2000年的互联网泡沫后,第一家上市的超大型互联网公司。作为搜索巨人的谷歌,已经渐渐取代门户网站,成为互联网新的入口。与此同时,它的股票增值速度也像坐上了火箭,一路攀升。
|
||||
|
||||
那个时候移动互联网尚在萌芽,社交网络也没有占据主流地位;“搜索引擎”因为谷歌的成功,成为了创业者和投资人的关注热点。
|
||||
|
||||
在这样的大背景下,一个以投资者和创业者的信息为主的网站VentureBeat发出了不同的声音,它的主编马特·马绍尔(Matt Marshall)发表了一篇文章,标题是这样的:“不可忽视的创业公司Powerset,即将筹集1000万美元去打败谷歌。”(Bold start-up,Powerset,about to raise $10M to take on Google)
|
||||
|
||||
这篇文章画出了三个重点:有一个新的高科技创业公司Powerset,它的创始人是人工智能和自然语言处理技术专家巴尼·佩尔(Barney Pell),这家公司将会以新的技术打败谷歌。
|
||||
|
||||
在这篇文章发表之后,Powerset的创始人,号称“人工智能和自然语言处理专家”的巴尼,也亲自撰写了一篇文章,告诉大家自己正在创办一家搜索公司。
|
||||
|
||||
巴尼还举了一个例子,如果搜索 “Book by children”,谷歌会自动忽略掉“by”,导致搜索引擎不能明白这句话到底是什么意思。但是,自己创立的公司Powerset则不会有这个问题。因为后者可以理解自然语言,而前者只是做关键词匹配,所以高频介词“by”被忽略掉了,造成了语义不正确。
|
||||
|
||||
即使到了今天,谷歌的搜索引擎在很大程度上还是对单词进行匹配,于是基于语义的搜索,对2006年的谷歌而言,毋庸置疑是个问题,而Powerset是基于自然语言的,想来技术上应该相当厉害。
|
||||
|
||||
但事实上是,Powerset在公司还没有任何产品的时候,就开始大肆炒作。这靠不靠谱就不好说了。后来公布出来的信息让人大跌眼镜,Powerset所使用的自然语言分析技术,是从施乐公司的帕洛阿尔托研究中心(Palo Alto Research Center)授权得来的。
|
||||
|
||||
一个自然语言搜索的公司,它的核心技术不是由自己开发的,而是授权过来的。这就更让人怀疑Powerset到底靠不靠谱了。所以Powerset一边在聚光灯下备受瞩目,一边又被大家不断质疑。
|
||||
|
||||
众人盼星星盼月亮地等待Powerset发布跨时代的产品,然而这一等就是两年。到了2008年5月的时候,Powerset终于发布了它们的第一个基于自然语言的搜索引擎,但是这个引擎只能搜索维基百科上面的一部分文章,并不能处理维基百科以外的任何互联网内容搜索问题。
|
||||
|
||||
不过,在Powerset的搜索结果页面上,确实包括了一些和谷歌不一样的东西,它们主要是下面的内容。
|
||||
|
||||
|
||||
资料(Factz) :当用户输入一个搜索主题,Powerset会从维基百科(Wikipedia)中总结出一些相关资料。
|
||||
主题档案(Dossiers) :Powerset会对主题做一个总结。
|
||||
答案集(Answers) :对很多问题,Powerset会自动生成一个答案表。
|
||||
语意高亮(Semantic Highlighting) :与用户问题语意相关的搜索结果,会高亮显示。
|
||||
微浏览器(MiniBrowser) : 搜索结果会以大纲形式显示。
|
||||
专题条(Article Outline) :一个导航工具条,会随时漂浮在搜索结果旁边,来帮助用户快速进入文章的某个章节。
|
||||
资料概要(Summary of Factz) : 会自动生成文章的内容总结。
|
||||
相关资料(Explore Factz) : 可以生成相关主题文章的链接。
|
||||
|
||||
|
||||
这些东西和谷歌比起来,自然是有令人耳目一新的成分;但是这样的搜索引擎是不是比谷歌的更强大好用,那就见仁见智了。
|
||||
|
||||
有人问Powerset,为什么不提供整个互联网的索引?Powerset的回答是:它们作为一个创业公司,没有足够的机器存储整个互联网的内容,但它们的技术对整个互联网都是适用的;只要有足够多的财力、物力,Powerset分分钟就可以把自己变成一个能够搜索整个互联网的搜索引擎。
|
||||
|
||||
这个回答,当然不会让所有人十分满意。有些人相信Powerset有这样的能力,还有人觉得Powerset是在吹牛。
|
||||
|
||||
毕竟维基百科有相对工整的数据,工整的数据在语义上就会相对简单,建立知识库也不是那么复杂;而对于整个互联网来说,数据不仅仅没有这样工整,很可能也是不正确的,面对这样的数据,Powerset的表现很可能是一塌糊涂。
|
||||
|
||||
之后发生的事情就十分有趣了。谷歌有钱以后就开始挑衅微软,开始了在西雅图建办公室、挖微软的墙角、推出Google Docs进军微软的办公软件市场等一系列行径。
|
||||
|
||||
这导致当时微软的CEO史蒂夫·鲍尔默(Steve Ballmer),决定大举进军搜索市场,做“必应搜索引擎”和谷歌正面对抗。
|
||||
|
||||
于是,在Powerset公布它们基于维基百科的新一代搜索引擎以后没多久,也就是2008年7月,Powerset就被微软收购了,收购价是1亿美金,实际上,收购价其实算不得很高。
|
||||
|
||||
而收购了Powerset的微软,既没有终止HBase的开发,也没有把HBase当作自己重要的资产对待。一直到萨提亚(Satya)上台以后,微软开始向“云”转移,HBase的重要性才体现了出来。
|
||||
|
||||
但是在那个时候,在微软收购Powerset时加入的那批HBase开发人员,却早已经纷纷跳槽离开了。
|
||||
|
||||
所以,微软曾经有一次绝佳的机会,可以对Hadoop生态圈形成巨大的影响,但自己却轻易地放过去了。这或许是微软一时之失,或许是它当时过于自以为是,但历史就是历史,我们也不好过多评判。
|
||||
|
||||
我们无从验证Powerset是否真的那么牛,但是起码有一点,微软的必应搜索引擎自从收购了Powerset的技术以后,再也没有呈现出超越谷歌的趋势。
|
||||
|
||||
不过不可否认,Powerset也是做出了一定的贡献。它在开发语义搜索系统的过程中,需要用到类似于谷歌BigTable的系统,但是当时开源的Hadoop生态圈却没有,所以Powerset自己开发了HBase。
|
||||
|
||||
单纯从这一点来讲,Powerset就有点让我刮目相看了。HBase并非是一个简单的系统,最初Powerset投进去的人虽然只是个位数,但是它的质量在开源社区里是非常不错的。
|
||||
|
||||
所以,如果我们中肯地去评论Powerset,它做出了HBase,并且对Hadoop生态圈和大数据开源的贡献依然是极为巨大的。所以,无论如何,我们都还是要感谢Powerset,毕竟,它还是给我们留下了HBase,这个优质的开源产品。
|
||||
|
||||
|
||||
|
||||
|
||||
71
专栏/技术与商业案例解读/090Cassandra和DataStax的故事.md
Normal file
71
专栏/技术与商业案例解读/090Cassandra和DataStax的故事.md
Normal file
@@ -0,0 +1,71 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
090 Cassandra和DataStax的故事
|
||||
Cassandra是大数据时代中非常具有影响力的一个开源项目,DataStax则是背后支持开源Cassandra并将其商业化的公司。今天我们就来聊一下Cassandra和Datatax的故事。
|
||||
|
||||
我们都知道,在大数据发展历史上,谷歌的“三驾马车”:谷歌文件系统、 MapReduce、 BigTable。三者都曾经扮演了非常重要的角色,Hadoop开源生态圈里也有对应的Hadoop文件系统,Hadoop MapReduce和HBase。
|
||||
|
||||
但是在大数据发展史上,还有一篇影响力几乎等同于谷歌“三驾马车”的论文。它讲的就是亚马逊发布的Dynamo系统。
|
||||
|
||||
2008年,Dynamo系统的作者之一阿维纳什·拉克希曼(Avinash Lakshman),跳槽去了Facebook。跳槽的阿维纳(Avinash)和Facebook网站的另外一个工程师普拉桑特·马利克(Prashant Malik),一起开发了Cassandra,一个Dynamo的开源山寨版。
|
||||
|
||||
Cassandra开发出来之后很快就被开源了。早期Facebook对于开源这件事还是非常支持的,但是它开源的Cassandra很快就受到了一次重大的打击,这个打击可以说是十分致命的。
|
||||
|
||||
早年的Facebook对于谷歌技术非常崇拜,但对于亚马逊的技术却缺乏信心。于是Facebook准备开发移动App“Messenger”的时候,决定使用谷歌的技术架构。更明确一点说就是,Facebook抛弃了自己开发的Cassandra,选择了当时在Hadoop系统里山寨了BigTable的HBase。
|
||||
|
||||
亲儿子被自己的公司抛弃,开发人员也没什么兴趣继续开发了。与被众心捧月的HBase状态比起来,Cassandra当时就是一种被众人嫌弃的状态,不过,如果故事到此为止的话,那么Cassandra估计也就不会活到今天了。
|
||||
|
||||
我们把时光回溯到2010年,当时在Rackspace工作的乔纳森·艾利斯(Jonathan Ellis)和马特·皮菲尔(Matt Pfeil),这两个和Cassandra无关的人,决定离开Rackspace,自己创业。
|
||||
|
||||
Rackspace在工业界里最为著名的是OpenStack那一套体系,做的是数据中心云计算的基础架构。算起来和Cassandra这套NoSQL的东西多少也有点关系。
|
||||
|
||||
他们创业的故事非常有意思,同时也跟Cassandra有着千丝万缕的联系,公开的说法是这样的。
|
||||
|
||||
|
||||
乔纳森是个很牛的工程师,决定结束碌碌无为的工作状态,辞职创业去。马特代表公司去挽留这个人才,于是两个人约了去吃午餐;然而结局却颇为戏剧化,马特没有说服乔纳森继续为Rackspace工作,而杰纳森却说服了马特和他一起创业,并让他出任自己公司的CEO。
|
||||
公司同年成立,最初公司的名字叫Riptano。创业需要有方向,乔纳森和马特看好开源社区商业化的模式,但是他们并没有打算成为Hadoop的发行商,所以环顾四周之后他们挑中了Cassandra,并打算将它做为核心,开启他们的创业之旅。
|
||||
大概就是因为选取了Cassandra,公司的定位就比较明确了,也就是选择了云端数据处理的方向。于是他们觉得Riptano这个公司的名字不太适合公司的定位,就把公司名字改成了DataStax。这个故事就是DataStax的由来。
|
||||
|
||||
|
||||
自从2010年选中了Cassandra之后,DataStax就开始了全力以赴开发Cassandra的历程。在很长一段时间里,DataStax对Cassandra贡献的代码量,占据了整个代码提交量的85%以上。
|
||||
|
||||
可以说,正是因为DataStax的介入,才最终让Cassandra活了下来,并且在2011年成为了Apache基金会的顶级开源项目。DataStax推出的主打产品,是一个叫做DataStax Enterprise的东西。这是一个以Cassandra为核心,整合了诸多开源项目的产品。
|
||||
|
||||
DataStax Enterprise提供了两种模式,一种是卖软件和服务给企业,企业再装到自己的机器上去运行。另外一种是托管云服务“DataStax Managed Cloud”,这是一个运行在亚马逊云服务(AWS)上的云托管服务,用户无需购买和维护自己的机器。
|
||||
|
||||
从产品完整性和盈利模式来看,DataStax提供的是相对来说比较完整的一套产品体系。但是以Cassandra为核心的主要问题是,Cassandra的技术相对冷门,优点和缺点也都很明显,这导致的结果是:适用于Cassandra的应用也是有一定限制的。
|
||||
|
||||
DataStax的产品也因为选择了Cassandra作为核心,和其他公司的同类产品就有很明显的不一样。
|
||||
|
||||
具体来说,Cassandra是一个写入非常快、吞吐量很大、延时很低的系统;同时,这个系统的处理能力伴随容量的增长,也呈现出线性的增强。这些都是Cassandra的优势。尤其是做云端部署时,这个系统可以很灵活地根据工作负载来加减机器。
|
||||
|
||||
2012年,多伦多大学一篇论文比较研究了6个不同的NoSQL数据库的优劣,得出的结论是Cassandra是当之无愧的赢家。这篇论文被DataStax广泛引用,以此来证明这个系统比其他更为优质。
|
||||
|
||||
但是凡事都有两面性,Cassandra的缺点也很明显。首先是Cassandra有一个十分令人讨厌的问题:这个系统没办法保证一条记录行级别的一致性。
|
||||
|
||||
简单来说,如果A操作改变了行里面的一个列,B操作改变了同一行里面的另外一列,那么很有可能就得到了一条四不像的行。
|
||||
|
||||
这对应用程序来说是一件非常糟糕的事,虽然现实来说这种错误的概率不是特别高,但是只要不是0概率的话,很多应用程序都不可能使用这样的系统。
|
||||
|
||||
还有一个缺点是Cassandra普遍适用的场景非常有限,Cassandra虽然对于单行操作非常快,但是对于多行操作就会非常慢;而且不仅仅慢,很可能同时消耗的资源也会很高。
|
||||
|
||||
Cassandra对范围查询的能力比起HBase要差了很多。因此,通常来说Cassandra应用的场景适合只访问单行记录的,但是在单行记录的时候却不能保证行级别的一致性。这就是Cassandra适用场景的瓶颈所在。
|
||||
|
||||
不过,DataStax发展到了今天,它的主打产品DataStax Enterprise也是经过了多年的演进,并且在以Cassandra为核心的基础上,进行了全面的整合。
|
||||
|
||||
例如它通过对Spark和Solr的整合,提供了数据分析和搜索的功能。它还在自我完善中提供了对多种语言和开发平台的支持,比如说Java、Python、Ruby、 C++、Javascript等等。
|
||||
|
||||
此外,DataStax Enterprise还提供了给管理员用来做系统监控和操作的OpsCenter,以及给开发者提供的IDE环境 DataStax Studio。
|
||||
|
||||
从产品的完善程度来讲,DataStax Enterprise是非常完善的,它是一套整合了开源以及自主开发产品的系统,并提供了开发、运行、部署和监控几乎全方位的支持。这些都是这套系统的优势。
|
||||
|
||||
然而,DataStax的发展相对来说不温不火,在业界也只是名气平平。我想,它选择了Cassandra,既给了DataStax足够多的辨识度和区分度,也让DataStax的产品受到了各种限制。至于这样的选择到底是好是坏,对DataStax的发展是否有利,可能只有时间才能说清楚了。
|
||||
|
||||
不管怎么样,Cassandra仍然需要感谢DataStax的救命之恩和鼎力支持。可以说没有DataStax,就不会有今天的Cassandra。
|
||||
|
||||
|
||||
|
||||
|
||||
75
专栏/技术与商业案例解读/091Databricks之Spark的数据金砖王国.md
Normal file
75
专栏/技术与商业案例解读/091Databricks之Spark的数据金砖王国.md
Normal file
@@ -0,0 +1,75 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
091 Databricks之Spark的数据金砖王国
|
||||
说起大数据的创业公司,我们一定都会提到Databricks这公司,而这家公司知名的原因,一大部分来自于它的开源产品Spark。Spark是Hadoop生态圈里大红大紫的项目,事实上,它甚至已经取代了新一代的经典运行框架:Hadoop MapReduce。
|
||||
|
||||
所以,想要了解Databricks这家创业公司,我们就需要先了解Spark这个Apache开源项目。Spark是一个大数据计算框架,它诞生于加州大学伯克利分校AMP实验室,是当时的博士生马泰·扎哈里亚(Matei Zaharia)的博士论文课题。
|
||||
|
||||
2010年,Spark在BSD License下开源。经过几年发展以后,在2013年成立了Databricks,同年,它被Databricks捐献给Apache基金会,并将开源模式转向了Apache 2.0,从此,Spark正式成为Apache家族里顶级开源项目之一。
|
||||
|
||||
Spark是目前整个Hadoop的生态系统里最为活跃的计算框架,它已经取代了Hadoop原来MapReduce框架的地位,目前,只有Flink的计算框架尚能与它平分秋色(有关Flink的情况,我们会在后面的文章里详细介绍)。
|
||||
|
||||
Spark框架下支持SQL、机器学习、图计算、流计算等各种各样的计算模型,应用起来十分广泛。它不仅在开源社区里广受追捧,在大公司里也常常被拿来应用,IBM现在已经把自己的大数据计算引擎押宝在Spark上了。
|
||||
|
||||
介绍完Spark,我们来看看它背后的Databricks公司,这家公司是由加州大学伯克利分校AMP实验室的原班人马组建的,它成立的目的主要是为了推广Spark和Spark的生态圈。
|
||||
|
||||
Databricks的管理层可谓明星荟萃。CTO马泰·扎哈里亚是Apache Spark最初的创作者,同时也是斯坦福大学的教授。CEO是阿里·格霍西(Ali Ghodsi)是加州大学伯克利分校的兼职教授,执行总裁艾恩·斯塔卡(Ion Stoica)也是学校的全职教授,他还是CTO马泰·扎哈里亚的导师。另外一位联合创始人是华人雷诺·辛(Reynold Xin),他现在是首席架构师。
|
||||
|
||||
Databricks的核心,主要是Spark。如果我们把Spark理解成为一个计算平台的话,那么围绕着Spark生态圈做的东西则是Databricks的核心价值。对Databricks来说,首先要做的事情,是把Spark的开源项目越做越大。
|
||||
|
||||
作为做大Spark的一部分,Databricks对Spark发展方向的掌控在开源社区是出了名的强势。自从Databricks成立以来,对Spark技术的演进一直都是有自己的路线图的。
|
||||
|
||||
近些年来,无论是SparkSQL、DataFrame的推出,还是基于Mini-batch的Spark Streaming的工作开展,都是Spark这个计算框架下面非常重要的项目。如果没有Databricks的推动和首肯,这些项目几乎不可能进到Spark的发行版里。
|
||||
|
||||
因此,我们总结一下Databricks的商业模式:壮大Spark社区,掌控和引导Spark的技术走向。
|
||||
|
||||
然而仅仅做大Spark开源项目,对Databricks来说还是不够的,这些不足以带给Databricks盈利;而一个公司是否成功,最终还是取决于这个公司的赚钱能力。从这个角度上来讲。壮大Spark是Databricks盈利的一个基础,但是却不是Databricks盈利的根本。
|
||||
|
||||
那么说,Databricks是怎么盈利的呢?
|
||||
|
||||
Databricks的第一条盈利方式就是:选择在这些基石上面,开发附加产品来赚钱。 其中第一个产品,也是Databricks现阶段正在努力的方向,就是提供云上搭建的Spark计算平台。
|
||||
|
||||
我们来看看这个产品具体是如何赚钱的。
|
||||
|
||||
Spark团队在一开始设计Spark产品的时候,就遵循了一条原则:它和Hadoop整个体系保持松耦合,所有的相关服务都抽象成接口,再通过接口调用。
|
||||
|
||||
这样做的好处在于,如果Spark哪一天决定和另外一套类似的系统对接,那么只要针对另外一套系统重新实现一下接口就好了,Spark自身的代码则完全不需要改动。
|
||||
|
||||
这样,它一方面可以和Hadoop做到有效整合,借助业已壮大的Hadoop平台和生态圈推广自己。另外一方面,如果万一哪天Hadoop被别家取代了,或者Spark需要针对某些企业内部系统(比如对微软、谷歌内部大数据系统)进行整合的话,改动工作也会非常容易。
|
||||
|
||||
果不其然,深谋远虑的Spark团队十分生财有道。他们在开源了支持Hadoop的社区版以外,还专门开发了直接对接云厂商的版本,比如亚马逊AWS版的Spark。
|
||||
|
||||
这个版本的Spark按照Databricks公布的数据,针对AWS优化的Spark的效率比开源版高5倍以上,但是,这个版本却不是开源的。
|
||||
|
||||
Databricks又把这个不开源的版本做成云服务卖给用户。由于这个版本的Spark比开源版的要更快,很多企业愿意付钱买,这也就成了目前Databricks最重要的盈利途径。
|
||||
|
||||
Databricks的第二条盈利方式是对建立在Apache Spark平台上的应用进行认证,并确保这些应用和Spark的兼容性。 这种认证当然不是免费的,由于Spark社区的成功,这方面的认证开展工作也是如火如荼。
|
||||
|
||||
Databricks的第三条盈利方式是:给使用了Spark技术的各大公司提供技术支持。 简单来说,Spark虽然开源,但是用好Spark的公司,不一定都有技术实力读、改源代码来适应自己的应用场景。这个时候买了Databricks的技术支持服务的话,Databricks就可以提供支持了。
|
||||
|
||||
由于Databricks对Spark的源代码非常熟悉,Databricks的技术支持往往能够解决很多企业非常重要的紧急问题。而有些公司不缺钱,也愿意付钱给Databricks,这门生意对Databricks来说也是重要的赚钱途径。
|
||||
|
||||
这三块服务是不是足够支撑Databricks呢?我想这个问题的答案有点复杂。
|
||||
|
||||
第一块业务非常实际,这是可以大规模推广的赚钱方式。一部分开源,一部分不开源,通过开源来圈用户,通过提供更高性能的服务来赚钱。这个生意做得比较成功。
|
||||
|
||||
这个生意里最大的问题是,Databricks自身并不拥有云平台,它的云平台主要运行在亚马逊的云服务上面,这就造成了亚马逊自己一旦也想做类似服务的话,Databricks就很难抵抗。所以多做几个云厂商上面的服务,这也许是一个好主意,起码可以不把全部筹码压在一个平台的身上。
|
||||
|
||||
后面两块业务的市场取决于Spark到底有多重要,以及Databricks到底有多懂Spark。
|
||||
|
||||
首先,我觉得Spark的重要性毋庸置疑,大企业比如SAP,IBM都在其产品里面用Spark和引入对Spark的支持。这证明了Spark的市场占有率是巨大的。
|
||||
|
||||
其次,Databricks的几个创始人基本上奠定了Spark的架构。在很多情况下,某些特定的东西Spark为什么是这样设计的,也只有做架构的人才能回答了。所以恐怕市面上不存在一家比Databricks更懂Spark的商业机构。从这一点来看,Databricks的基本盘是很稳妥的,所以这两个业务也能赚到钱。
|
||||
|
||||
但是,Databricks目前面临的一个大问题是机器学习,尤其是深度学习的潮流。Spark是用Scala写的,并在JVM上运行。这就意味着,基于Spark的机器学习平台并不能有效地利用GPU。这样一来,这个问题就大了。
|
||||
|
||||
机器学习作为Spark最初也是最重要的应用之一,在Spark社区占有很重要的地位。Databricks是否能够有效解决这个问题,对自己的是否能成功和Spark将来会怎么发展,都非常的重要。Databricks的另外一个考验是需要应对Flink这个后起之秀的进攻。
|
||||
|
||||
我想,Databricks的前途是光明的,但是也会充满竞争和曲折。
|
||||
|
||||
|
||||
|
||||
|
||||
63
专栏/技术与商业案例解读/092DataArtisans:浴火重生的新一代大数据计算引擎Flink.md
Normal file
63
专栏/技术与商业案例解读/092DataArtisans:浴火重生的新一代大数据计算引擎Flink.md
Normal file
@@ -0,0 +1,63 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
092 Data Artisans:浴火重生的新一代大数据计算引擎Flink
|
||||
2014年,数据库领域的顶级会议VLDB在杭州召开。柏林理工大学的教授沃克尔·马尔科(Volker Markl)做了一场关于大数据计算平台的专题报告,这场报告讲的是一个叫做Flink的系统。
|
||||
|
||||
沃克尔和他的团队从事大数据研究已经很多年了,他们最初开始做的是一个叫做Stratosphere的项目。这个系统并不出名,既无Hadoop的声势浩大,也没有Spark的迅速扩张。
|
||||
|
||||
后来,沃克尔吸取了早年Stratosphere系统的教训,并调研了市场上现存的系统不足,经过了重新设计,才制作出了这个叫Flink的新系统。
|
||||
|
||||
Flink以非常先进的流计算引擎思想为基本,同时还结合了传统大数据和数据库的优点。于是,这个系统一进入Apache软件基金会以后,就迅速火爆了,甚至连Capital One和国内的阿里巴巴集团银行都开始相继使用。
|
||||
|
||||
Flink从一出现就获得了很多的关注,这是自Spark项目出现以来,所有Apache项目里面最受关注的一个。最主要的原因就是Flink的理念非常先进,而且Flink是基于流模型的一个计算平台,它所使用的流计算模型,又是目前市面上所有开源项目里最为先进的。“先进”“实时”“流计算”,这些词语被放在一起,就给Flink带来了无限的光辉。
|
||||
|
||||
Flink一时风头无两,网上很快出现了Spark是不是会被Flink取代的言论。在美版知乎Quora和程序员非常喜欢的Stack Overflow上面,这个问题屡次被提出来讨论。
|
||||
|
||||
实际上这个问题却没有一个定论,业内大部分的人都觉得Spark和Flink的竞争中,前者很成熟,商业化也不错;后者的理念先进,也有一定的支持,究竟谁能胜出,还是要看后续的发展。
|
||||
|
||||
介绍完了Flink的概况,我们再来聊聊它背后的公司。和加州大学伯克利学院对待Spark一样,柏林理工Flink的主要开发者们,也为Flink成立了一家大数据公司Data Artisans,它的总部位于欧洲柏林,在硅谷设有分公司。
|
||||
|
||||
从某种程度上,Data Artisans和Databricks很像,区别只是前者的主打项目是Flink,后者是Spark而已。
|
||||
|
||||
Data Artisans的运营模式和盈利模式和Databricks也很像,他们也提供一个基于Flink的云计算平台,叫做dA Platform。这个平台有开源的Flink,还有不开源的应用管理器,平台不开源的部分就是他们的增值服务。此外,公司同时提供了对Flink的培训和咨询服务。
|
||||
|
||||
如果我们把Flink换成Spark,忽略主打项目的不同,那么我们几乎可以看到两家公司几乎一样的商业运营模式。而这两个公司唯一的区别是:Data Artisans目前不做认证服务。
|
||||
|
||||
那么说,两个极其相似的产品之间,后来者Data Artisans是不是会有一些不利之处呢。
|
||||
|
||||
首先,它的竞争对手Databricks已经运营很久了。何况Databricks的前身,加州大学伯克利分校的AMP实验室也已经和工业界有非常紧密的联系,更不要说,Spark在整个社区里已经建立非常强劲的生态环境。
|
||||
|
||||
其次,Flink作为一个新产品,又出自一个远离湾区的德国柏林的公司,它的境遇自然就要差一些了。先不去谈时间上的短板,仅仅因为它是欧洲公司出品的产品,就可以令它在湾区的使用率被打一个折扣。所以对于Flink,很多公司一直都是站着看戏的态度。这让Flink在号称互联网中心的北美地区推广并不顺利。
|
||||
|
||||
最后,虽然Flink的产品在理念上很先进,但是理念从来都不是一切,理念之外,还需要有这个产品的实现。这方面,后来的Data Artisans比起Databricks要差了不少,所以Flink实现起来,Bug会多一些,代码对于大规模的并行处理效率也要更低,有很多的瓶颈等等。
|
||||
|
||||
不过,虽然Flink有诸多不利之处,但是它先进的流计算引擎思想,代表着比Spark更光明的未来。这不妨碍一些公司,尤其是自身学术能力不一定强,但是有着强大工程开发能力和开发资源的公司去支持Flink。
|
||||
|
||||
Data Artisans的第一个强大的“后盾”就是阿里巴巴。阿里巴巴集团内部组建了一支自己的队伍,在数据库专家蒋晓伟的带领下,对Flink的代码进行了大量的改动,这些改动在工程实现上让Flink有了一个质的飞跃。这款克隆版的Flink就是我们在前面文章中讲到过的Blink。
|
||||
|
||||
我们之前也讲到过,Flink社区和阿里巴巴的Blink团队的合作非常紧密。阿里巴巴把很多自己做的改动都重新贡献回Flink,这让Flink的发展迅速地走向了康庄大道。到今天为止,阿里巴巴是世界上对Flink贡献代码第二多的公司,仅次于Data Artisans。
|
||||
|
||||
Data Artisans和阿里巴巴的结合,让我们对Flink的未来多了很多信心。
|
||||
|
||||
另外,在北美也有一家公司在支持着Data Artisans,它就是Capital One公司。Capital One公司也是Flink目前在北美的最大使用者,它对Flink的表现还是相当满意的。
|
||||
|
||||
此外,公开支持Flink的还有谷歌。支持Flink的原因是谷歌开源了它的数据流定义平台Apache Beam,而在开源这一平台的过程中,谷歌表示只有Flink这个引擎具备了Beam需要的所有特性,其他引擎,包括Spark在内,都还是差了那么一点。
|
||||
|
||||
这些都让Flink赢得了一些关注,但是不管怎么样,Flink在北美的发展,总体上仍然举步维艰。
|
||||
|
||||
我们常常说“成就都是站在巨人的肩膀上取得的”,我们还常常会说“失败是成功之母”。Flink在某种程度上是这两句话的完美体现。
|
||||
|
||||
Flink很晚才被开发出来,所以一方面,它继承了一个失败项目的优点,并规避了缺点。另外一方面,它参考了市场上已有的引擎,学习它们的长处与不足。简而言之,Flink的起点很高。
|
||||
|
||||
但是晚出来的产品也有坏处。如果之前有一个很好的产品基本上已经占据了市场,那么晚出的产品想要得到市场的认可,不但需要技术要非常强大,还需要看自身的运气。而它的前辈Spark,的确是一个非常厉害的产品。
|
||||
|
||||
所以说,Flink能不能够抢占一整块市场,这一点不太好说。至于它能不能彻底把Spark取代了,那更是痴人说梦。只要Databricks自己不犯错,Data Artisans要想取得胜利,实在是一件不容易的事情。但是我想,市场那么大,Data Artisans应该也能分得自己的一块蛋糕。
|
||||
|
||||
你又是怎么看待站在巨人的肩上这个问题呢?你可以给我留言,我们一起讨论。
|
||||
|
||||
|
||||
|
||||
|
||||
72
专栏/技术与商业案例解读/093Dremio_在Drill和Arrow上的大数据公司.md
Normal file
72
专栏/技术与商业案例解读/093Dremio_在Drill和Arrow上的大数据公司.md
Normal file
@@ -0,0 +1,72 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
093 Dremio_在Drill和Arrow上的大数据公司
|
||||
093 Dremio:在Drill和Arrow上的大数据公司
|
||||
|
||||
今天这篇文章,我们来讲讲一个非常年轻的公司Dremio的故事。这个故事涉及了两个Apache开源项目Drill和Arrow,和一家Hadoop发行商MapR。
|
||||
|
||||
我们先从MapR公司开始讲起,MapR在2009年成立,发展一直不错,在CTO的带领下,公司出品了一个自己的文件系统,取代了HDFS,同时,它的Hadoop发行版也取得了不俗的成绩。
|
||||
|
||||
托马尔 · 希兰(Tomer Shiran)和雅克 · 纳杜(Jacques Nadeau),这两位都是MapR公司的核心员工。让我们记住这两个人的名字,因为他们与我们接下来的故事息息相关。托马尔是MapR的第一位产品经理,负责整个产品线的开发。雅克则是Apache Drill项目和Apache Arrow项目的主要负责人。
|
||||
|
||||
第一个项目:Apache Drill
|
||||
|
||||
让我们把时间倒回到2013年。当时Hive已经存在,但是很慢很不好用。谷歌的Dremel刚出来没多久,就掀起了交互式查询的风潮,随之而来的是Cloudera开始了它的Impala引擎的计划;而MapR也决定做一款查询引擎,自己主导开源项目,这就是后来的Apache Drill。
|
||||
|
||||
当时筹建这个项目的人,是托马尔,而具体负责干事情的人,是雅克。我之所以知道这件事情的详细情况,是因为2013年的时候,这两位打电话给我,希望我加盟这个尚未展开的项目。
|
||||
|
||||
但是当时的我比较担心小公司不稳定,就没有去。不过,虽然我没有去,但还是获得了Apache Drill的一些内幕信息。
|
||||
|
||||
Apache Drill是一个基于类SQL语言的查询引擎,它的第一个特点,也是最主要的特点就是可以通过连接器连接各种各样的数据源,这里包括了HDFS、HBase、Hive的表,关系数据库等等。
|
||||
|
||||
并且它可以跨多个数据源进行数据查询和分析。这些连接器是可扩展的,只要有人愿意替一个特定的数据源写一个连接器,那么Apache Drill就可以支持这个数据源。
|
||||
|
||||
Apache Drill的第二个特点是:它使用了半结构化数据类型,类似JSON。它的查询语法类似SQL,但是引入了很多半结构化数据支持的新语法。当然,对于半结构化数据支持,在Google的Dremel以及Hive里面早就有了,所以这些新语法的扩展并没有那么让人吃惊。
|
||||
|
||||
Apache Drill的第三个特点是:系统可以自动推导和识别“元数据”。这一点是Apache Drill独有的特性,其主要目的是解决半结构化数据中“元数据”难以确定的情况。
|
||||
|
||||
Drill的理念无疑是非常先进的,可惜的是Drill并没有大红大紫过。可能的原因有很多,但在我看来,最大的原因是:这个系统很难做到高效。
|
||||
|
||||
在用户查询数据量大的时候,Drill比其他系统要慢很多。好用却不高效,无法应对大规模的数据处理,在大数据的场景下就有些吃力不讨好了。
|
||||
|
||||
第二个项目:Apache Arrow
|
||||
|
||||
雅克致力于Drill的开发已经很多年了,肯定也意识到了这样的性能对于Drill是一个问题。但是性能问题要怎么解决,却不是一件容易的事情,雅克的做法是构建另外一个项目:Apache Arrow。于是2016年,Apache Arrow诞生了。
|
||||
|
||||
简单来说,Apache Arrow是一个内存数据结构,它的主要作用是在不同的数据源之间做快速高效的数据交换。这个项目吸收了10多个Apache顶级项目。它的主要目标有两个:
|
||||
|
||||
|
||||
定义一个通用而高效的内存数据格式,方便数据查询引擎进行查询。
|
||||
定义了从上述格式中载入数据的方式。任何支持这个格式的系统,都可以方便、高效地输入或者输出这种格式。
|
||||
|
||||
|
||||
这两者放在一起,就使得从不同数据源读取和写入数据的效率得到大大的提高。这种提高,对于各个产品都是有意义的。然而更加有意义的并非各种产品之间,而是类似Apache Drill这样需要对不同数据源做联合查询的查询引擎。这种方式的交互数据已经把可能的消耗都降低了。对Drill这样的引擎才有可能实现高速查询。
|
||||
|
||||
Dremio公司的核心产品
|
||||
|
||||
但是,这个时候,MapR公司却出现了一些问题。MapR经过了一轮大洗盘,创始人和早期高管纷纷被迫离职,连CTO也去了Uber,托马尔和雅克,这两位MapR非常重要的早期员工也开始了他们的创业历程,他们创立了Dremio公司。
|
||||
|
||||
有了Apache Arrow,托马尔和雅克就可以构建新一代的、类似Drill的查询引擎了。这就是Dremio公司的核心产品。它是一个有UI,可以连接到不同数据源进行数据分析的软件。当然这个产品也是不开源的,所以我们就没办法了解到它的具体实现。
|
||||
|
||||
乍一看,Dremio项目和Drill没有区别,但是它们内部其实是很不一样的。最大的区别在于,Drill可以任意地连接各种数据源,所以它虽然灵活,但是效率低。
|
||||
|
||||
Dremio公司的这款产品,只支持能输出Apache Arrow格式的数据源。但在内部,Dremio这款产品统一处理使用Apache Arrow格式。因为不需要通过连接器进行数据格式转换,不需要对元数据进行推理,Dremio的效率自然要高了很多。
|
||||
|
||||
Dremio的这款产品并非没有缺点。和Drill比起来,它能够连接的数据源一下子少了很多,目前只有Apache的10余个顶级项目支持常用的数据源,比如各种开源和商业关系数据库都是不支持输出Apache Arrow的。这样一来,这些数据源也不支持连接了。这显然限制了Dremio这款软件在传统企业中的使用。
|
||||
|
||||
当然,除了这个优化以外,Dremio的这款产品还进行了另外一个优化。简单来说,这和传统数据仓库的做法差不多,Dremio会预先做一些计算,然后把计算的结果存起来。这样一来,当真正需要做查询的时候,可以在已经计算好的数据上查询,从而减少计算量,缩短查询时间。
|
||||
|
||||
这种效率的提升有可能是非常可观的,尤其是当预计算数据的结果可以存放在内存里的话,查询速度的提升是非常可观的。但是这种做法有一个大问题:我们到底如何才能做到空间与效率的平衡,需要用多大的空间来换取多少效率的提升呢?
|
||||
|
||||
这个问题,传统数据库厂商和数据仓库厂商已经研究了几十年,其实并没有一个通用解法。很多时候只能根据业务需求和查询的实际情况定制。但是对于Dremio这个初创公司来说,这个方面的积累到底怎么样,我不好判断。
|
||||
|
||||
数据分析市场现在风起云涌,类似的产品也不少。Dremio从Apache Drill借鉴了连接的思想,又用Apache Arrow来提高系统效率的做法,的确是一个不错的折中方法。
|
||||
|
||||
但是在我看来,Dremio的这个折中方式最大的问题是:如何支持一些极为常见的数据源。比如Oracle,SQL Server。这些数据源并不支持Arrow格式的输出,可能Dremio在开源产品和Hadoop生态圈会有一片空间,但是对传统企业来说,恐怕不容易成为一个通用的数据平台。所以在我看来,Dremio能不能生存下来,也是在模棱两可之间了。
|
||||
|
||||
|
||||
|
||||
|
||||
67
专栏/技术与商业案例解读/094Imply:基于Druid的大数据分析公司.md
Normal file
67
专栏/技术与商业案例解读/094Imply:基于Druid的大数据分析公司.md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
094 Imply:基于Druid的大数据分析公司
|
||||
在今天的大数据创业领域,每个有相当数量受众的开源项目,它的背后都会有一个创业公司在支持。今天我们就来聊聊开源项目Druid,以及它背后的创业公司Imply。
|
||||
|
||||
Druid起始于2011年。它最初的开发商叫做Metamarkets,是一个籍籍无名的广告公司。这个项目于2012年8月份基于GPL版权开源,这一点和Hadoop生态圈里基于Apache版权开源的项目都不太一样。
|
||||
|
||||
Druid一开始并不是很有名,不过随着Airbnb的加入和推广,这个项目也逐渐在社区成名起来,但是GPL的开源方式始终不是社区开源的主体。
|
||||
|
||||
于是,在2015年2月,项目的开源方式转向了Apache版权,正式投奔了Hadoop生态圈。这算得上是Druid发展历程里最为重要的一步。
|
||||
|
||||
Druid的优与劣
|
||||
|
||||
介绍完了Druid整个项目历程,接下来我就来聊聊这个项目的特点。
|
||||
|
||||
在诸多数据分析开源项目里,Druid有两个独具特色的优点。具体来讲,Druid的第一个优点是:它的整个系统同时提供了对离线数据分析和在线实时数据分析的支持。
|
||||
|
||||
它是通过冷热数据分离的方式做到这一点的。冷数据是已经写入到Druid存储的数据,这一类数据存在Druid的某个节点的硬盘上。
|
||||
|
||||
热数据是等待写入的数据,这类数据在内存里。 Druid对冷数据和热数据分别进行查询分析,再把查询分析的结果结合起来作为最终结果返回给用户。这种数据一经导入就立刻能被查询的特性,让Druid在很多企业里都十分受欢迎。
|
||||
|
||||
Druid的第二个优点是:它是一个可插拔的查询系统。
|
||||
|
||||
通常来说,一个查询系统需要实现存储和执行两个模块。而存储则依赖特定的存储系统,比如说内存、本地磁盘、网盘、Hadoop文件系统和云盘等等。
|
||||
|
||||
市面上大部分的查询系统是和特定的一个或者有限个存储系统绑定的,而Druid本身并不绑定特定的存储系统。它可以支持所有流行的存储系统,不论是本地磁盘、网盘、Hadoop文件系统或者是常见的云盘比如亚马逊的S3,都可以成为其存储系统。
|
||||
|
||||
当然,Druid作为一个查询引擎,也有着两个非常显著的缺点。
|
||||
|
||||
第一个缺点是它不支持Join。或者我们可以这样说,Druid只支持单表查询。也正因为这个原因,Druid可以在本地就处理掉本地存储的数据,无论是冷数据还是热数据,然后再把数据整合在一起给出结果。如果Druid支持Join的话,这种方式就不切实际。
|
||||
|
||||
Druid这个设计很像谷歌的BigTable。这说明在互联网公司,确实有很多业务可以只需要单表。但是谷歌的BigTable下一代产品Spanner已经过渡到了一个完整的关系数据库,也开始支持Join。所以我们可以认为Druid更像是一个过渡产品。
|
||||
|
||||
第二个缺点是Druid不支持SQL,只类似BigTable那样的API。这导致了Druid这个开源项目身上互联网公司的气味很重。而传统一些的需要SQL支持的公司并不愿意用不支持SQL的Druid。
|
||||
|
||||
Imply公司与系统
|
||||
|
||||
说完了Druid,我们来看看它背后的公司。2015年8月,Druid最初的那些创始人离开了Metamarkets去创业,成立了Imply公司。这是诸多大数据创业公司里又一家提供在线分析报表服务的公司,这样类型的公司,我们一路走来也已经讲过很多。
|
||||
|
||||
Imply公司主要为Druid提供企业级应用的支持。它的产品也叫Imply。Imply公司的这套系统主要有两个版本。第一个版本是一套离线可以下载本地部署的系统,企业可以部署在自己的企业内部,叫Imply On-Premise。另外一个版本是基于亚马逊的云计算架构AWS的云版本,叫Imply Cloud。
|
||||
|
||||
Imply这套系统在Druid的基础上进行了两个方面的优化。
|
||||
|
||||
第一方面,它解决了开源的Druid为人诟病的问题:不支持SQL。Imply实现了一个新的、不开源组件,这个组件叫做SQL层。它的主要作用是允许外部系统通过ODBC或者JDBC连接进来,系统同时具备了把SQL翻译成Druid查询语言API的能力。
|
||||
|
||||
所以这样一来,外部系统通过标准的ODBC/JDBC连接,发送SQL语句,而这个SQL层则完成从SQL到Druid自己查询语言API的转换,从而连通内外系统。不过,这种连接方式依然不支持Join。
|
||||
|
||||
第二方面,Imply还增加了一个可视化查询模块。这是在用户本身没有Tableau或者Power BI等类似的可视化工具外部连接的情况下,系统本身提供一些简单的可视化操作和支持。
|
||||
|
||||
除去做可视化以外,这一层还提供了通过对数据的预先计算和处理,并存储中间结果的方式来加速查询。这一点和我在前面文章提到的Dremio的做法很像。
|
||||
|
||||
Imply公司的主要盈利模式还是通过出售他们的系统,以及为他们的系统提供支持来赚钱。鉴于开源版的Druid不支持SQL,所以传统企业如果想要使用Druid的整个技术栈的话,买Imply的版本比用开源的Druid会更方面好用。后者提供了SQL的支持,可以降低企业内部员工迁移的学习成本。
|
||||
|
||||
Imply的赚钱模式并没有和其他基于开源大数据的创业公司的赚钱模式有特别大的区别,区别的地方只是底层的产品换成了Druid。我个人并不看好这个公司,主要有两方面的原因。
|
||||
|
||||
第一是Druid的产品虽然比较适合互联网公司,但它不是一个通用的系统。互联网公司的自我开发能力强,用开源的Druid足够了,不会花钱去买Imply的增强版,所以Imply很难赚到互联网公司的钱。
|
||||
|
||||
第二是Druid本身不支持Join,这让它非常高效,可以同时提供离线和在线分析,但是也让它对传统企业来说,变得非常不实用。不支持Join的数据查询引擎在传统企业里要怎么用起来,是一个巨大的挑战,所以我觉得Imply也很难赚到传统企业的钱。
|
||||
|
||||
总而言之,我觉得不管在什么情况下,因为Druid的特殊性,Imply很难赚到任何一个企业的钱。我有理由相信这个公司是诸多开源项目背后的创业公司里最早倒下的那一批,所以,Imply的前途在我看来并不乐观。
|
||||
|
||||
|
||||
|
||||
|
||||
69
专栏/技术与商业案例解读/095Kyligence:阿帕奇麒麟背后的大数据公司.md
Normal file
69
专栏/技术与商业案例解读/095Kyligence:阿帕奇麒麟背后的大数据公司.md
Normal file
@@ -0,0 +1,69 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
095 Kyligence:阿帕奇麒麟背后的大数据公司
|
||||
几乎每一个成功的大数据开源项目背后都有一个公司。今天我们故事的主角就是Kyligence这家成立于2016年的公司。这个公司背后的项目就是阿帕奇麒麟。
|
||||
|
||||
先来介绍一下阿帕奇麒麟,它的英文名是Apache Kylin,一般业内都简称它为麒麟,这是第一个由中国人主导的阿帕奇开源项目。
|
||||
|
||||
麒麟项目由eBay中国公司开发,开发目的是为了解决在Hadoop生态圈里对数据仓库进行实时分析的问题。
|
||||
|
||||
和我们提到的其他开源项目解决数据分析的方式不同,阿帕奇麒麟的做法使用的是数据立方(DataCube)模型。
|
||||
|
||||
数据立方模型是数据仓库里很成熟的一个模型,它定义了查询可以在哪些维度哪些粒度上进行预计算。这个模型有许多商业化的产品,比如说微软的SQL Server Analysis Service就是这个模型的一个商业化实现。
|
||||
|
||||
通常我们说起开源项目解决数据分析问题,做法都是直接在原始数据上进行查询。而数据立方模型则允许系统事先做预计算,并存储一部分预计算的结果,查询可以发生在预计算的数据上,这是一种典型用空间换时间的策略。
|
||||
|
||||
这个模型最大的挑战在于,系统现实里到底选择了哪些维度与粒度进行预计算。如果系统对所有维度和所有粒度都进行预计算的话,那么所有查询都会加速,但是随之而来的是额外的存储空间将会非常巨大,远远超过原始数据的大小,这肯定是负担不起的。
|
||||
|
||||
所以如何有效地进行预计算,从而在不浪费空间的情况下,也能极大地缩短查询时间,是所有此类分析软件的核心问题。
|
||||
|
||||
阿帕奇麒麟是一个在Hadoop上基于数据立方模型,通过预计算的方式来提高查询性能的系统。它也是阿帕奇的顶级开源项目之一。
|
||||
|
||||
这个系统主要有两个核心的模块。第一个模块是对数据的预计算。这个是用户通过对数据立方的设计,进而产生Hive的查询,并且运行实现的。第二个是数据实际被查询的时候,系统会根据查询和预计算的内容进行匹配,进而改写查询,再从预计算的数据里面算出用户查询的结果。
|
||||
|
||||
麒麟是这样进行加速查询过程的:它对数据的导入会进行增量处理,每次导入新的数据以后,麒麟会生成增量文件,增量文件会在合适的时候被合并到主文件里面去。
|
||||
|
||||
这样的好处是系统导入数据的速度快,同时系统的查询性能也比较好。
|
||||
|
||||
麒麟于2014年10月正式在GitHub上开源,并在一个月以后加入阿帕奇基金会的孵化器,一年后正式毕业,成为阿帕奇基金会的顶级项目。
|
||||
|
||||
这既是eBay公司的第一个阿帕奇基金会的顶级开源项目,也是中国人的第一个阿帕奇基金会的顶级项目。
|
||||
|
||||
麒麟在eBay公司里面发展势头很好,还获得了美团等很多企业的支持。不过,在2016年的时候,原来在eBay中国开发麒麟项目的主要人员决定离开eBay开始创业,创业的公司就是这家总部位于上海的大数据公司Kyligence。
|
||||
|
||||
Kyligence的产品主要有三个:Kyligence分析平台、Kyligence机器人以及Kyligence云托管产品。
|
||||
|
||||
其中Kyligence分析平台,我们可以将它理解为阿帕奇麒麟的升级版。Kyligence的机器人则是一个自动化的诊断和分析平台,用于为Kyligence分析平台提供性能诊断等服务。Kyligence的云托管产品等同于云端的Kyligence分析平台。
|
||||
|
||||
总体来说,Kyligence分析平台在体系架构上和开源的阿帕奇麒麟比较像,但是很多重要的模块都重新开发了。
|
||||
|
||||
举例来说,开源版本的存储使用了阿帕奇的开源项目HBase作为底层的NoSQL存储,但是在Kyligence分析平台里面,这个组件被替换成了Kyligence公司自己开发的新的NoSQL存储,这个存储并没有开源。
|
||||
|
||||
我很有幸和Kyligence公司的CEO韩卿见过几次。我们聊到为什么Kyligence分析平台里HBase被替换的问题的时候,他说开源的阿帕奇生态圈里面有很多的好东西,但是这些开源软件又属于半成品,不够达到工业级的质量。
|
||||
|
||||
HBase作为一个开源项目来说是够了,但是HBase因为使用了Java,垃圾收集导致的延时现象很常见。这种延时对于一个追求亚秒级响应的查询系统来说,性能上就不能达标了,所以使用自己开发的组件去替换掉那些开源组件,是一个切实可行的做法。
|
||||
|
||||
当然,为了开发这些非开源的组件,Kyligence公司也投入了大量的人力物力。所以Kyligence公司并没有打算把这些东西开源出来。于是,和开源的麒麟比起来,这些不开源的组件才是Kyligence分析平台的核心资产。
|
||||
|
||||
Kyligence的盈利模式并不复杂。主要是通过卖他们的分析平台(无论是离线的,还是在线基于云的分析平台),然后按年收取费用,这些费用构成了Kyligence的主要收入来源。
|
||||
|
||||
Kyligence的想法是,如果大家使用了麒麟,觉得开源版本很好,又想用更好的版本,那么只要收费合理,总是会有人愿意出钱的。
|
||||
|
||||
这个做法与MapR的Hadoop发行版非常类似。因为MapR也是自己开发了自己的文件系统,去取代性能一般又不够稳定的Hadoop的文件系统。由于这个文件系统本身并不开放源代码。MapR公司就觉得如果大家用了Hadoop,并且喜欢使用的话,面对自家那个更好的系统,肯定更加愿意用。
|
||||
|
||||
当然,Kyligence和MapR的做法是有区别的,区别在于Kyligence系统的开源版和非开源版都是主要由Kyligence维护的。而MapR作为Hadoop的发行商,本身并非是最主要的维护Hadoop开源版的开发者。相反的,Hadoopd发行版是由多家公司联合维护的。
|
||||
|
||||
从这个角度来说,MapR要维持自己的文件系统和Hadoop开源版本的文件系统兼容性会比较困难,而Kyligence要维护阿帕奇麒麟和自己家的Kyligence分析平台的兼容性则要容易很多。
|
||||
|
||||
作为第一个中国人主导的阿帕奇顶级开源项目,麒麟也给中国人在阿帕奇基金会的活动提供了很多平台。麒麟的多个项目负责人为国内企业在阿帕奇基金会开源它们的项目提供了很多的支持。
|
||||
|
||||
从系统的架构来讲,一个通过预计算生成比较多的中间数据的产品,在某些场景下会很出彩。但是这并非是一个通用的系统,所以它适用的场景还是比较有限的。这使得无论是麒麟也好,Kyligence分析平台也罢,可能只适用于某些客户。
|
||||
|
||||
这种限制肯定会影响Kyligence公司的发展。然而从这样一个系统过渡到一个更加通用的系统,需要大规模改变整个系统的架构。这几乎是不可能发生的事情。所以我个人对Kyligence的判断是:它会在某些市场里面做得很好,但是市场的蛋糕并不是特别大。
|
||||
|
||||
|
||||
|
||||
|
||||
67
专栏/技术与商业案例解读/096Snowflake_云端的弹性数据仓库.md
Normal file
67
专栏/技术与商业案例解读/096Snowflake_云端的弹性数据仓库.md
Normal file
@@ -0,0 +1,67 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
096 Snowflake_云端的弹性数据仓库
|
||||
096 Snowflake:云端的弹性数据仓库
|
||||
|
||||
Snowflake是一个初创公司,也是一个完全基于云端构建的弹性数据仓库。它是大数据时代数据分析的一个重要的公司。今天我们来聊聊这个公司。
|
||||
|
||||
Snowflake成立于2012年,总部设在加州下属的一个小城市圣马特奥。Snowflake的创始人是本纳特·达格维尔(Benoit Dageville), 蒂里·克鲁安纳(Thierry Cruanes )以及马尔辛·茹科夫斯基(Marcin Zukowski)。这三位都是欧洲人,不过,现在都在美国发展。
|
||||
|
||||
本纳特早年在欧洲计算中心做研究,主要工作是并行数据库。后来,他来到了Oracle公司发展,并在Oracle待了16年。前6年是负责领导Oracle的并行执行引擎组,后面10年一直在做Oracle的架构师。
|
||||
|
||||
在Oracle里,架构师是一个明确的级别,这个级别非常不容易达到,需要公司里所有架构师全部同意才能晋升。能够在Oracle里面做到这个位置的,自然是非常厉害的人。
|
||||
|
||||
蒂里也是欧洲人,他在巴黎攻读完成数据库方向的博士,来到美国之后,先在IBM工作了四年,又在Oracle工作了12年,也是一位资深的数据库专家。
|
||||
|
||||
马尔辛和这两位比起来就是年轻一辈了。他在阿莫斯特丹大学获得博士学位,博士期间做的内容是著名的Monet DB/X100。毕业后,他创业成立了Vectorwise,后来公司被卖给了Ingres,他也随之到了Ingres工作,一段时间以后才来到了湾区。
|
||||
|
||||
从三个创始人的经历来看,他们都是在数据库方向的专家,有多年的积累与经验。Snowflake便是一个由这样的团队创建的数据库公司。它在成立之后一直都处于保密的状态。直到两年后的2014年10月,公司才正式宣布了他们的产品,同时宣布的还有他们的CEO。
|
||||
|
||||
Snowflake的CEO不是三个创始人中的任何一个。他叫鲍博·穆格里亚(Bob Muglia)。这个人在微软的第一份职务是SQL Server的项目经理,之后逐渐升职,直至最后做到了微软的资深副总裁。
|
||||
|
||||
2011年,他离开微软。根据后来公布的信息来看,他和当时微软副总裁史蒂夫·鲍尔默(Steve Ballmer)之间就公司的云计算发展产生了冲突。
|
||||
|
||||
了解了公司的主创人员和管理人员之后,我们来看看Snowflake的产品。Snowflake的产品主要是一款基于云的数据仓库。2014年发布的时候,所谓的云当然是指亚马逊的AWS。确切地讲就是S3的存储和EC2的虚拟机。
|
||||
|
||||
这款数据库是由Snowflake的成员从头开发的。它的主要想法是存储和计算要分离。Snowflake的数据被压缩以后存在亚马逊的S3上,每个文件的大小大约是16MB。文件的格式是列存,每个列被单独存成文件。
|
||||
|
||||
当数据需要处理的时候,Snowflake的处理引擎会启动EC2的虚拟机,虚拟机从S3读取数据,然后使用本地的磁盘作为数据的缓存。如果多个数据查询发生,每个数据查询的执行引擎在本地各保留了一份数据。当然查询结果被写回S3的时候,如果两个查询需要更新同一张表,Snowflake有某种写保护方式避免数据写入发生冲突。
|
||||
|
||||
Snowflake一出来的时候,它就号称自己的SQL支持SQL1998和SQL2003里面的大部分分析函数。它的数据库产品和SQL的兼容性好,Snowflake的数据模型并非只是基于纯粹的关系数据库,它同时也支持半结构化的数据。
|
||||
|
||||
不过,作为一个数据仓库产品,Snowflake本身并不支持索引。当然Snowflake还是会对每个文件记录最大最小值,这些信息可以用来让优化器过滤一部分的数据读取。
|
||||
|
||||
Snowflake的收费方式主要有两种,一种是存储的钱,这个按月收费。另外一种块是EC2上跑处理程序的时间,用了多少收多少。
|
||||
|
||||
Snowflake有很多不同档次的收费计划,其区别主要是数据库里面保存了多少个以前的版本。比较低级的计划只保存了1天的,而比较高级的计划可以最多保存90天内的所有版本。
|
||||
|
||||
从技术角度来讲,Snowflake的实现方式,因为是从头开始搭建的,所以它能够很好契合云计算的架构,也就是存储和计算分离。
|
||||
|
||||
Snowflake和亚马逊之间的关系,最初是很友好的合作关系。但是后来亚马逊进军了数据库市场,并推出了Redshift。Redshift作为一个云端的数据库产品,由亚马逊自己提供,并且与自家的S3做了整合。
|
||||
|
||||
亲儿子和干儿子之间的区别是很明显的。尤其是当亚马逊今年推出了Redshift Spectrum以后,Redshift就具备了扫描S3文件进行查询的能力了。这个能力让Snowflake使用S3作为廉价存储的梦想受到了打击。
|
||||
|
||||
总而言之,现在整个云计算市场上最为明显的竞争对手肯定是Redshift,这一点,Snowflake多少还是感觉到了威胁的。
|
||||
|
||||
为了应对这种变化,Snowflake的做法是在西雅图成立了分部。Snowflake在西雅图的分部主要从微软Windows Azure招人,为的是在Windows Azure的存储和虚拟机上实现类似于自己在亚马逊上提供的服务。
|
||||
|
||||
大概是2016年下半年,Snowflake从微软的某个云计算部门挖了一个经理,开始组建这个部门。之后陆陆续续的,公司在西雅图的部门逐渐扩展到了10多个人。并在2016年底进军Windows Azure市场。
|
||||
|
||||
Snowflake有一些固定的客户,它的商业模式里面,最大的不确定因素是如果云计算厂商自己也想抢Snowflake想做的生意。云厂商对自己的存储和计算服务最熟悉。第三方开发怎么样也不可能比自己开发得到更多的支持。这是Snowflake尴尬的地方。那么,Snowflake要如何打赢这场仗。
|
||||
|
||||
当亚马逊做了Redshift之后,Snowflake还是可以去做Windows Azure上面的生意。如果微软也介入这个市场,Snowflake是不是只能去做谷歌的生意呢?如果要是谷歌也介入这个市场,Snowflake怎么办?
|
||||
|
||||
从这个角度来讲,云计算的数据库服务如果没有底层基础平台的话,要想在竞争对手的围攻下胜利,是一件不容易的事情。
|
||||
|
||||
在云计算上非常成功的应用软件厂商Salesforce,它之所以没有倒下,很大程度上也是因为它的服务是跑在自己的基础架构上,而不是AWS或者微软的服务上的。虽然Salesforce最近也在和AWS合作紧密,主要还是亚马逊目前没有进入企业CRM市场的打算。
|
||||
|
||||
而当亚马逊或者微软自己也介入到同样的业务里面来的时候,这种竞争关系就会非常麻烦了。第三方厂商既依赖云厂商提供的基础服务,又和云厂商的服务竞争。这对它们显然是不利的。
|
||||
|
||||
不过无论如何,作为第一个云端的弹性数据仓库,Snowflake还是获得了很多的关注。但是我想这个公司的未来,如果能够被某个云厂商收购了,可能会是最好的出路。
|
||||
|
||||
|
||||
|
||||
|
||||
79
专栏/技术与商业案例解读/097TiDB:一个国产新数据库的创业故事.md
Normal file
79
专栏/技术与商业案例解读/097TiDB:一个国产新数据库的创业故事.md
Normal file
@@ -0,0 +1,79 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
097 TiDB:一个国产新数据库的创业故事
|
||||
TiDB是一个位于北京的创业公司PingCAP的产品,它是一个新型的数据库。PingCAP成立于2015年。联合创始人是刘奇、黄东旭和崔秋。在2017年的时候,他们完成了1500万美元的融资。今天我们的故事主角就是这个国产数据库和它背后的公司。
|
||||
|
||||
说起数据库产业,其中的经典是关系数据库。这一类要么是外国大公司的商业数据库,其代表是Oracle数据库,IBM的DB2,以及微软的SQL Server;要么就是开源的数据库,这类以MySQL和PostgreSQL为代表。
|
||||
|
||||
进入新世纪后,随着大数据相关技术的出现,又有了一些NoSQL的产品。
|
||||
|
||||
在数据库的发展上,关系数据库好用,但是扩展性差,对于大数据场景不好;NoSQL产品可以支持大量的数据和大规模的访问,但是可用性却非常差,对产品开发来说,使用时要注意的事情太多。
|
||||
|
||||
那么说,有没有一种产品兼有关系型数据库和NoSQL的优点呢?进入到2012年以后,大数据技术奠基者谷歌发表了一系列新论文,主要讲述了它们新开发的一个叫做Spanner的数据库。这种数据库同时具备了关系数据库和NoSQL的优点。所以通常我们又把这个类型的数据库称为NewSQL。
|
||||
|
||||
TiDB就是这样一款数据库,它的基本理念就是基于NewSQL的技术,这个项目的名字TiDB,也包含了一定的含义。引用联合创始人黄东旭的说法,Ti是金属元素钛,这是一种非常坚硬的金属,以此来象征他们的数据库牢不可摧。
|
||||
|
||||
它背后的公司,则是给自己取名叫做PingCAP。对于做系统的人,肯定能理解这是一个雄心壮志的公司。这个名字的本身包含了两层意思,“Ping”+“CAP理论”。
|
||||
|
||||
Ping是TCP/IP里面的“ping”命令的意思。它的本意是用于查看一个IP地址是不是可以连得上,用在这个公司的名字上是用来表达“连接”的意思。
|
||||
|
||||
再来介绍一下CAP理论,CAP理论主张任何基于网络的数据共享系统,最多只能拥有以下三条中的两条:
|
||||
|
||||
|
||||
数据一致性(C),等同于所有节点访问同一份最新的数据副本;
|
||||
对数据更新具备高可用性(A);
|
||||
分区容错性(P)。
|
||||
|
||||
|
||||
所以说,CAP理论主要是说在一个系统中,C、A、P里只能满足三条的两条。而这个公司的名字 PingCAP就是希望可以连接CAP,同时满足三者的条件。
|
||||
|
||||
那么为什么我们需要连接CAP呢?这是因为CAP理论就是所谓的三者选两个,系统在任何时候都是只选特定的两个。
|
||||
|
||||
当网络表现良好的时候,P不存在,所以C和A是可以兼得的。而网络一旦出问题,C和A之间选择哪个,其实是传统关系数据库和NoSQL的区别。
|
||||
|
||||
但是,NewSQL里因为它良好的实现,可以更大限度减少P的出现,从而保证系统在绝大部分时候都满足C和A,但是有能力实现一个系统保证绝大部分情况下P不会出现,是一件不容易的事情。
|
||||
|
||||
总之,无论从公司的名字,产品的名字,还有选择创业的方向,都证明了一个雄心勃勃的公司,正在做一款非常有难度的产品。
|
||||
|
||||
PingCAP刚成立的时候,TiDB的项目就已经立项了。但是要从头到尾做一款数据库产品有两方面的问题。一方面是技术上的问题,这个只有顶尖人才才可能解决;另外一方面是商业上的问题,现在市场上如此多的数据库,如何让大家接受一款新的数据库本身才是个问题。
|
||||
|
||||
PingCAP做的第一个决定是,它们的产品会和市面上最流行的开源数据库MySQL保持100%的兼容。这样的好处是,只要是原来使用MySQL的客户,都可以无缝地切换过来;而原来MySQL的社区里面已有的资源,包括各种工具和各种测试实例也都可以直接拿过来用。
|
||||
|
||||
当然这样做也不是没有代价的。一款产品要和另外一款产品等价,其实也就意味着需要对另外一款产品的各种行为都有深刻的研究。这就意味着开发难度绝对不是从头建一个产品可比的。
|
||||
|
||||
PingCAP在这里选择了一个非常聪明的做法。他们的开发是从上面往下走的,第一件事情是先把SQL层相关的东西做出来。这样的好处是在一开始就可以检测出语言级别上是不是会有不一致的地方。
|
||||
|
||||
PingCAP的另外一个非常聪明的地方是,他们是很有底层软件的开发经验的。在写SQL层的时候,他们也把网上有关MySQL的测试都扒到自己的实验环境里来。因为一个底层软件的开发是否成功,很大程度上取决于测试做得有多好。
|
||||
|
||||
这里我们需要解释一下,底层软件本身是提供给客户用的。所以这类产品除了性能要求以外,还有稳定性的要求,而测试这类产品则需要构建不同的应用环境才可以。
|
||||
|
||||
如果说一切从头而来的话,整个过程会非常不容易。PingCAP选择了和MySQL 100%兼容,那么他们就可以用MySQL社区里已经发展了10多年的测试,完全不需要从头写起。
|
||||
|
||||
PingCAP在开发完上层的MySQL层以后,就进入到下层的存储层。这里他们决定学习谷歌的Spanner,做一个体量无限大的MySQL。
|
||||
|
||||
从技术上来讲,这就需要做到自动分区,而这在工业界里是非常难的一个东西。通常来说实现的方式不是Paxos就是Raft,前者在谷歌的实现已经证明是非常复杂,后者还是2014年才出现的新方案。在全世界,真正实现了这种高可用性的公司并不多。
|
||||
|
||||
在上述的基础上,他们还是需要一个底层的基础存储结构。我有幸和黄东旭吃过一顿饭。聊到这方面的时候他说过,他们的选择就是拥抱开源社区了。毕竟很多东西开源社区里有非常丰富的资源。
|
||||
|
||||
这样一来,PingCAP和开源社区的一些项目一起,就渐渐地把这个叫做TiDB的数据库搭起来了。
|
||||
|
||||
不过,在搭起来以后,PingCAP面临着一个非常实际的问题:用户是不是愿意把系统替换掉。用户很多时候是愿意在实验环境下尝试一下新东西,却不代表他们有这个胆量在生产实践里就能直接替换。因为数据库如果出了问题,导致数据错误或者丢失,很多时候是灾难性的,损失无法估量。
|
||||
|
||||
好在MySQL早就实现了主从备份,主服务器用于接受写和读的操作,而从服务器则在背后同步。PingCAP实现了TiDB和MySQL的备份通讯协议,所以TiDB可以作为MySQL的主从备份服务器里的从备份服务器,部署到生产实践的应用里去。
|
||||
|
||||
这样的好处是,用户只是增加了一个“从”的备份,接下来就可以直接去查询这个“从”的数据库。
|
||||
|
||||
用户可以将TiDB作为从数据库与MySQL作为从数据库进行比较,看看两种情况下的查询结果是否一致,并且可以同时比较两种情况下的性能差异。通过这种比较,用户可以确定TiDB作为MySQL的替代品,是不是从正确性到性能上都没有问题。
|
||||
|
||||
如果在从数据库的比较中,先确定了TiDB没有正确性问题,又确定TiDB的性能好于MySQL,那么它替换主MySQL数据库也就成为可能了。
|
||||
|
||||
通过这样的一种方式,TiDB很顺利地就打入了很多用户的市场。而且事实证明TiDB有良好的扩展性,对查询的速度也快很多。这样慢慢的,公司也就打开了局面。
|
||||
|
||||
时至今日,TiDB才成立两年,但是它们的产品已经小试牛刀了。公司在产品的商业策略和技术实现上都表现出了非常优异的表现,所以我们完全有理由相信,在不远的将来,这个公司可以带给我们一款底层基础数据库的利器,这也是我们中国人在基础架构领域取得的一个巨大的成就。
|
||||
|
||||
|
||||
|
||||
|
||||
73
专栏/技术与商业案例解读/098大数据创业公司的前景:红海创业多艰辛.md
Normal file
73
专栏/技术与商业案例解读/098大数据创业公司的前景:红海创业多艰辛.md
Normal file
@@ -0,0 +1,73 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
098 大数据创业公司的前景:红海创业多艰辛
|
||||
我们介绍了很多大数据创业公司,这些公司在大体上可以分成开源软件创业公司和闭源软件创业公司两类。
|
||||
|
||||
开源软件创业公司是指,很多的大数据创业公司的背后是某一个或者几个开源项目的创始人,或者是项目的主要开发者。
|
||||
|
||||
闭源软件创业公司是指创业公司有自己闭源的软件,这种又分为两类:一类是闭源的基础架构软件,一类是闭源的商业应用软件。
|
||||
|
||||
我们通常用“红海”“蓝海”来形容创业的难易程度,基础架构类创业,无论开源还是闭源,很多时候就属于红海,毕竟相对于应用层面的创业,基础架构类的创业要艰难很多,这主要是因为应用层面的创业是直接和商业行为联系的。
|
||||
|
||||
基础架构类的创业,其创业依赖于其他客户对其产品的使用和付费。比如说Hadoop生态圈里各种开源软件为基础的创业公司,如果没有人去用这个公司的产品,这个公司也就不容易赚到钱。
|
||||
|
||||
不过,凡事都有两面,从好的方面来说,如果有大客户用了,那么可能会有持续稳定的收入。从坏的方面来说,一则很多客户不一定愿意去用不熟悉的开源产品,二则如果真的要用,大公司自己有技术实力去把开源的产品拿过来,自己二次开发,并且维护使用。但是无论如何,要想在基础架构类进行创业,都不是一件容易的事情。
|
||||
|
||||
基础架构类里面最普遍的创业企业都和某个开源项目有联系。比如说Spark后面站的是Databricks,Kafka后面站的是Confluent,DataStax则是基于Cassandra的开源公司。
|
||||
|
||||
这些公司如何盈利,通常来说有几个选项。
|
||||
|
||||
|
||||
第一是公司做的产品里有不开源的收费部分。
|
||||
第二是公司往往会提供一些咨询和技术支持的服务。
|
||||
第三是很多公司也选择提供在云端的托管服务,这些基于云端的托管服务往往是在AWS上开发的。
|
||||
|
||||
|
||||
并非说这些盈利服务不好,而是这些服务都取决于很多人去用这个产品,并且愿意为额外的服务付费。但是,实际上到底怎么样,是一个很复杂的问题。
|
||||
|
||||
首先是有些开源产品本身已经被广泛使用了,用户并不愿意为了增值服务而掏钱。其次是这些公司往往只支持一个开源产品,那么如果一个公司需要联合使用多个开源产品的时候,可能还不如选择一个Hadoop的发行商,用它们的版本一劳永逸地解决所有问题。
|
||||
|
||||
至于基于AWS的托管服务,这当然是一个生财有道的途径。但是这个依然取决于用户到底想怎么用这个托管服务。很多时候,用户用单一的开源产品可能性很小,而这些创业公司提供的套餐却往往基于单一的产品,我想这在很大程度上会降低这些公司盈利的可能性。
|
||||
|
||||
这类公司是不是有例外,当然在我看来是有的。如果产品的特色明显而且不可或缺,那么成功的可能性就更大一些。
|
||||
|
||||
具体来说,我觉得Kafka就是一款很有特色,而且是Hadoop的生态系统里面不可或缺的产品,所以,Confluent作为一个创业公司,它获得成功的可能就比其他公司要大一些。
|
||||
|
||||
另外如果一个产品的通用性很大,那么这样的公司比起其他公司更可能会成功;但是归根结底,这些公司的成功与否,我想很大程度上取决于这些公司能不能顺利地盈利。
|
||||
|
||||
而公司是否能保持一直盈利,这也是个问题。我个人觉得很多都会慢慢死掉,但是也有一些会成功活下来甚至壮大。只是,基于开源项目创业的公司,的确是创业的红海,会非常艰难。
|
||||
|
||||
不过大数据创业公司也不仅仅是和开源项目保持联系这一种模式,还有一些创业公司的产品,是直接面对客户,解决客户实际问题的。
|
||||
|
||||
最著名的是独角兽Palantir。Palantir是大数据创业公司里面最为神秘,但是同时也是估值最高的公司之一。它和其他大数据公司有非常鲜明的不同,它提供的大数据分析平台,是一个直接给客户提供最终解决方案的平台。
|
||||
|
||||
客户买了Palantir之后,可以从数据的采集、分析、存储、优化、查询、显示等方方面面都一体化的解决。除此之外,它家的软件还针对特别的领域进行优化。
|
||||
|
||||
当然目前为止大家都知道的,Palantir主要针对的是政府部门以及金融领域的业务。这两个领域的好处也很明显,合同长期稳定,客户不缺钱。
|
||||
|
||||
从这个角度来看,Palantir的商业模式比其他基于开源项目的创业公司要更合理,也更容易盈利。这样的公司发展起来,结果怎么样,虽然我们依旧需要拭目以待。但是概率上来说,成功的可能性更高一些。
|
||||
|
||||
而另外一个著名的大数据公司Splunk,专注于机器产生的日志文件的分析。这个公司不但成功地上市,而且上市以后市值一直持续上涨,盈利能力也是不断攀升。毫无疑问,如果说大数据创业公司里面哪一个可以证明是非常成功的,Splunk这一席绝对不会缺的。
|
||||
|
||||
但是不管是Splunk还是Palantir,如果从创业的角度来讲,它们都应该属于蓝海。
|
||||
|
||||
它们直接针对客户,解决某一个领域的问题,提供一体化解决方案。而前面很多基于开源项目的创业企业,则属于红海。
|
||||
|
||||
它们的数据分析平台和云托管服务,还做不到一体化解决方案。可想而知,如果我是投资人的话,我更愿意把钱投给前者而不是后者。
|
||||
|
||||
那么为什么开源社区一下子冒出了那么多的基于开源项目的创业公司呢?我想可能是一股风潮。
|
||||
|
||||
每个开源项目的人都希望自己的项目可以进一步的壮大,乃至给自己带来经济上的利益。作为创业者这样去努力,我可以理解。尤其如果创业者本身是开源项目的开发者的话,寻求经济利益上的诉求无可厚非。
|
||||
|
||||
但是如果是打工的呢?作为员工加盟这些创业公司的时候,我们就需要谨慎考虑了。很多基于开源项目的创业公司,前景不一定好看,股票很可能是废纸。
|
||||
|
||||
如果有选择,像Splunk这样的蓝海创业公司和像DataStax这样的红海创业公司,前者对于员工来说风险会更低一些。最主要的原因是前者如果有特色,公司会有不可替代性,也能有稳定的营收。比如说聚焦特定的领域,技术上有领先优势,这样的公司就更加安全稳定。
|
||||
|
||||
所以,红海的公司并非不可以加入,只是你在选择的时候,最好还是挑那些有特色的,能够在红海中屹立不倒的,加盟进去才比较靠谱。
|
||||
|
||||
|
||||
|
||||
|
||||
57
专栏/技术与商业案例解读/099如何通过企业技术积累去分析一家企业?.md
Normal file
57
专栏/技术与商业案例解读/099如何通过企业技术积累去分析一家企业?.md
Normal file
@@ -0,0 +1,57 @@
|
||||
|
||||
|
||||
因收到Google相关通知,网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
099 如何通过企业技术积累去分析一家企业?
|
||||
通过企业的技术积累去分析一家企业是一个行之有效的办法。一个企业如果想要成功,要么需要在商业上有所建树,要么需要在技术上有所建树,总之,一定需要有在某些方面和别人有明显的优势,才可以在激烈的竞争里面站稳脚跟。
|
||||
|
||||
如果我们要对上述的话一一举例的话,我想,亚马逊的成功,背后应该是对商业深刻理解的成功。谷歌的成功,很大程度上是对技术的极致追求的成功。
|
||||
|
||||
从2003年开始,谷歌发表了一系列论文,这促成了大数据时代的到来,之后谷歌又在人工智能领域发力,实现了“AlphaGo战胜人类最顶级围棋高手”这样历史性的突破。我们可以看到在谷歌踏足的每一个领域,很大程度上展现出来的技术水平都代表了这个领域人类突破性的进展。
|
||||
|
||||
所以,谷歌对技术的极致追求可见一斑。也正是因为谷歌对技术的极致追求,它才能在互联网海量数据的搜索和广告领域占据无可取代的地位。其广告收入就像印钞机一般,24小时源源不断地提供巨额营收。
|
||||
|
||||
那么我们应该如何通过企业技术积累去分析呢。首先有一个前提,一个人如果可以从技术积累去分析企业,那么对分析企业的人本身也提出了一些要求。
|
||||
|
||||
如果分析企业的人本身对技术不够精通,不是某一个领域专家的话,那么透过技术去分析企业多少就有点镜花水月了,毕竟分析者自己也无法比其他人能够更早地判断在某个行业里,哪一家拥有独特技术的企业是否可以一飞冲天。
|
||||
|
||||
所以,能够通过技术积累去分析企业的,最好本人是某一方面的专家,或者在一个领域内已经有所建树了。通过技术去分析企业,就我个人而言,只有在分析大数据企业的时候,我才会信心满满。毕竟在大数据基础架构这个领域,我已经工作了10多年,并且在这个领域里也有一些建树。
|
||||
|
||||
其次,通过技术积累去分析企业,大体上我们要看几个方面。
|
||||
|
||||
第一个方面要看一个企业的技术是否具有适用的、有意义的场景,并且这些场景是需要能够带来巨大利润的。我们知道很多时候,企业可以研究一些很领先的技术,但是如果这些技术本身并不能产生效益的话,那么这个技术对盈利其实就是没有意义的。
|
||||
|
||||
虽然说这类技术可能对于基础研究会有帮助,但是对于一个公司,尤其是初创公司来说,其拥有的技术一定是有适用的场景,这些场景是需要有实际意义,并能够带来巨大利润的。大公司里或许还能允许一些失败,小公司,创业公司,其技术积累的盈利能力就是其生存的根基之一。
|
||||
|
||||
如果以大数据作为例子的话,Kafka这个软件对应的技术显然有非常普适的价值,并且,这种价值在很多有实际意义的场景里都可以体现出来,这些场景显然也能带来巨大的利润。因此我们有理由相信做Kafka的公司,很有可能会十分成功。
|
||||
|
||||
第二个方面,我们要看这个技术是不是有其领先和独到的优势。一个企业的技术,如果很容易被模仿的话,那么这个技术带给这个企业的价值也就非常有限了;而如果一个企业的技术有非常领先和独到的优势,其他企业和个人即便花费巨大的代价也很难模仿和超越,那么这种技术就可以产生技术壁垒,进而给公司带来充足的发展空间。
|
||||
|
||||
举个例子来说,搜索是一个大家都知道的东西。前前后后做搜索的公司也非常多。但是谷歌在搜索上,比如说在对所有的搜索结果进行排序,决定到底哪条记录是和搜索的关键词最相关的这个问题上,谷歌的技术就有非常独到之处,而且其技术的领先优势也非常明显。
|
||||
|
||||
这就可以回答了,为什么尽管那么多的公司都非常眼红谷歌在搜索广告上赚取了巨大的利润,但是这些公司其实拿谷歌没有任何办法,即便砸钱砸人进去做,对方能够掌握的技术依然无法和谷歌的技术相媲美。
|
||||
|
||||
比如说微软砸钱并不少,微软人才也不少,但是微软无法掌握谷歌的技术,所以无法和谷歌一样在搜索广告上赚取大量利润。
|
||||
|
||||
对于一个企业分析人员来说,如果他能够洞察到一家企业的技术领先和独到之处,并且这项技术同时具备盈利能力,那么企业分析人员就应该可以判断得出来这个企业前途无量,他的垄断地位几乎是无可动摇的。
|
||||
|
||||
第三个方面要看一个企业技术积累的深度和广度。如果一个企业的技术积累可以覆盖一个领域横向纵向的相关方面,既广且深,并且每个方面的技术都有其独到之处,那么在某个领域内,这个公司就很容易形成优势。
|
||||
|
||||
相反的,如果一个公司只是在某个方面技术有些独到之处,并只覆盖了这个方面的周边,但是在相关更深入的问题积累方面有欠缺的话,这个公司的发展空间仍就受阻于这些技术积累跛脚的地方。
|
||||
|
||||
这里我们也可以举一个例子。Tableau作为数据可视化的领头羊,其软件在数据可视化领域有很丰富的积累。Tableau在数据可视化用户交互这个方面的积淀很深,不是一般人能够随便抄袭的。数据可视化本身也是一个很有价值的领域,可以带来大量的利润。
|
||||
|
||||
但是Tableau这款软件和这个公司的技术积累的广度是有问题的。比如说在用户交互方面,Tableau只适合用鼠标去交互。但是在流行自然语言的交互模式上,就毫无建树。因此当AI流行开来,需要更自然的交互方式的时候,这些都会成为Tableau的瓶颈。
|
||||
|
||||
通过一家公司的技术积累去分析一家公司,是非常行之有效的分析手段。但是它对分析者本身提出了比较高的要求。分析者本身对这方面的技术要非常懂,才可以有效地对企业进行分析。
|
||||
|
||||
在具体分析的时候,我们可以从三个方面展开,首先看技术适用的场景是否有巨大的盈利空间,再看技术本身是否有领先和独到之处,最后是这个企业的技术积累的深度和广度。
|
||||
|
||||
这种分析的优势在于分析所基于的证据非常扎实,所以分析得出来的结论的可靠性也很高,预见性强,不容易出错。
|
||||
|
||||
但是这也对分析者提出了很高的要求。作为分析者,我们也需要不断来充实自己,同时提高自身对技术和商业的理解,才可以做出更为精准的判断。
|
||||
|
||||
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user