微软的大数据发展史上另外一支非常重要的队伍，是必应（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 的发展停滞了。微软必应的大数据故事，也就此告一段落。