|
|
# 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沈向洋。
|
|
|
|
|
|
伴随着微软硅谷研究院的关闭，这个大数据故事也就告一段落了。这些参与了相关项目研发的人，被裁掉以后大部分被谷歌搜罗，在谷歌研究院开始新的工作，那就是后话了。
|
|
|
|