|
|
# 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相对普及，大家都用得比较顺手。
|
|
|
|
|
|
第二个方面是这些轮子都是专有工具，使用任何一个专有工具就意味着让自己锁定进了这个平台。这是很多企业不愿意做的。所以成功解决内部需求的自建轮子，却在外部市场上屡屡折戟。
|
|
|
|
|
|
总而言之，自建轮子是一件成本非常高昂的事情，并非对每个企业都适用。所以这个世界上真正自建轮子的企业并不多。每个自建的轮子在服务其内部业务的时候，都很成功。
|
|
|
|
|
|
然而不忘初心这件事情挺难的。每家自建的轮子最终都在试图卖给第三方，却一个也没做成过生意。究其原因，做事情还是需要初心的。当初为了服务内部业务的目的而构建的系统，本非为外部客户服务，结果却强行扭转，非要做成服务外部，犹如强扭的瓜，到底甜不甜，可想而知。
|
|
|
|