|
|
# 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具有以下特点。
|
|
|
|
|
|
1. 它有一个强类型系统，完全兼容C#类型系统。虽然当时C#在微软外部名声不显，但在微软内部是第一开发语言。所以，SCOPE选择了这个类型系统，自然而然增加了可用性。
|
|
|
|
|
|
2. 它提供了大量高级的查询功能，比如支持写类似SQL的查询语句。
|
|
|
|
|
|
3. 它还提供了类似MapReduce的扩展功能。
|
|
|
|
|
|
4. 它和C#的整合做得很好。
|
|
|
|
|
|
|
|
|
而在性能上的不同，是SCOPE区别于其他系统的关键部分。SCOPE的性能远远超过了Hive，主要体现在以下两个方面：
|
|
|
|
|
|
1. SCOPE使用了自动代码生成技术，可以针对每个查询直接生成C++代码。这样做虽然增加了编译时间，但是查询速度要快很多。因为编译只会进行一次，而查询速度的提升涉及了每条记录的查询，所以对于需要大量时间进行大规模数据处理的情况，这个自动代码生成技术为SCOPE提速很多。
|
|
|
|
|
|
2. SCOPE的查询优化做得非常好，而其他很多系统不具备这个创新性的功能。之所以SCOPE可以实现这个创新，是因为它基于Dryad可以很灵活地生成图，而不必局限于MapReduce。
|
|
|
|
|
|
|
|
|
Cosmos在必应取得成功后，被迅速应用到微软的其他业务部门，包括Windows、Xbox、Office365等等。
|
|
|
|
|
|
Cosmos的队伍在几年内迅速膨胀，阵容也非常强大。它的最高领导人是微软的VP或者院士，二线经理都是微软合伙人，一线经理也得达到首席经理的级别，而且其他成员在微软的职务也都非常高。这样的高配，至今我还没在微软的其他部门见过。
|
|
|
|
|
|
Cosmos后来又开始做流计算和交互式查询方面的查询引擎，这两个项目取得了一些成绩，但与Cosmos其他项目的成绩比起来还是要差一些。
|
|
|
|
|
|
2013年，在史蒂夫倡导的“同一个微软”（One Microsoft）的大重组中，微软将Cosmos从必应分了出去，把它合并进了云计算和企业事业部的数据处理部门。这次合并后，必应搜索部门丧失了对Cosmos项目的主导权，而新东家对Cosmos的未来看法不同。
|
|
|
|
|
|
未来一年多的时间里，Cosmos的队伍经历了成立以来最大的波折。Cosmos团队人员纷纷出走，最终负责Cosmos核心内容的成员各奔东西，我也在那个时候离开了微软。
|
|
|
|
|
|
很难说“同一个微软”的理念是对是错，但有一点可以肯定，调整后Cosmos的发展停滞了。微软必应的大数据故事，也就此告一段落。
|
|
|
|