大数据那些事(5):沉没的微软以及Dryad

到目前为止，我大致上是按照年代的顺序来讲述故事，除了刻意的延迟了对Google第三架马车的叙述。但是接下来的文章，出于逻辑的考虑，可能会更加的前后错开一些。大数据技术的发展，很快从史前时代进入了蓬勃发展的时期，我关注得到的东西也就越来越少了。

在这场大数据的革命里，有的公司耀眼了，赚到了名。有的公司做了雷锋，赚到了关注度。有的公司起了个早，在内斗中赶了个晚集。还有的公司，微软这个上个时代的领军人物，扑通了几声，迅速被淹没在了大浪里面，沉没了。

然而我们必须说，作为老司机，微软还是非常有鉴别能力的，什么东西是好东西，什么是烂东西。换句话说什么该抄什么应该抛弃，在我有限的接触的几个公司譬如IBM，Yahoo来说，至少那个MapReduce耀眼横行的年代里，微软的某些决定显得很另类，并不引人注目，然而未必就错了。

微软大概是在2007年前后决定大规模的投资search，这可能一半是因为微软在自己的大本营上被Google撩拨的不行了。Google在Kirkland开了个office明目张胆的开始在微软挖人。网上有个视频是说当又一个微软的Fellow离开的时候，前CEO巴尔默问对方去哪，还说，千万不要又是Google。结果对方说很不幸的就是Google。于是巴尔默砸椅子了。当然这个坊间传闻不知道真假。那个先开始叫Windows Live Search，后来改名叫Bing的产品，在外名声不显。然而我必须说，从微软内部来看，这个投资的意义极其的巨大。因为投资Bing，微软掌握了大规模data center的建设和管理能力，开发出了几个对微软这个只会做单机版软件的公司有着飞跃性意义的平台，掌握了A/B testing的实验平台，学会了大规模数据分析的能力。其中有一些东西则成为了Windows Azure的基础。可以说，没有Bing的钱砸进去，微软并没有办法顺利的从一个软件公司过度到一个云计算的公司。如此算一笔账，亏了还是赚了确实是不好说。同时代的IBM和Oracle显然就没有这样的幸运。至今依然在苦苦的挣扎中不知道能云成什么鬼样。

这里我们要介绍一个人Michael Isard。这个作为在这个特定时期对微软非常有意义的人，值得去大书特书一下。Michael Isard，微软硅谷研究院的高级研究员，早年做计算机视觉出身。按照以前我看他在微软的主页上的说法，他在2007年前后几年的时候和微软的Search有着非常的紧密的合作，参与了微软Search的两个特别重要的infrastructure项目的开发：Autopilot和Cosmos。因为这两个项目其实现在都不是秘密的项目了，所以我就可以自由自在的拎出来讲。其中Autopilot的早期情况可以参考他的论文：Autopilot: Automatic Data Center Management。从标题上看大家就知道Autopilot是干什么的了。Autopilot后来有了非常长足的发展，并成为了windows azure下面管理data center的基础。因为鹅厂不让我贴外面的链接，所以就只能辛苦大家自己动手丰衣足食了。而Cosmos是微软的大数据计算的平台。我一度在此team共事非常长的时间。关于Cosmos的详细情况也可以参考VLDB Journal的论文 SCOPE: Parallel Databases Meet MapReduce。关于后者，在以后讲到相关话题的时候我们会展开叙述。

顺便说两个八卦，都是和微软的现任CEO Satya有关的。第一个八卦是澄清一下大家长久以来的误会。Satya一直以来都是受到微软上层非常信任的人。在执掌search也就是后来的Bing的时候，作为Senior Vice President，Search和Ads的大头，两个VP都是直接report给他的。而陆奇在2008年登陆微软的时候，虽然名义上是Online Service Division，实际上来说，只有msn是直接汇报给陆奇，其他都是汇报给Satya，然后Satya再汇报给陆大大。所以虽然说有所谓的上下级关系，到底谁更获得高层的信任其实可见一斑。后来Satya去了Server and Tools成了President，陆大大直接接手了Search和Ads的汇报，中间那一层并没有其他人来接替。因此坊间传闻陆大大是上级然后变成了下级不爽，多半不靠谱。在微软内部，Satya获得高层的信任一直以来都高于陆大大。当初把陆大大搞过来也是想促成Yahoo的deal，确保Bing有三分之一的traffic。至于谁是名义上的头，谁是实际上的老大，其实很容易看明白的。

第二个八卦是Satya上台以后的一次layoff，做出来的决定是把Microsoft Silicon Valley Research Lab给关了，这次关掉整个研究院的事情发生在2014年，造成了非常恶劣的影响。我们的主角Michael Isard也被裁员了。这些被裁员的人据说当天Jeff Dean带着Google的HR就守在门口给签了Google研究院的合同。而最新的公开资料显示Michael Isard去做TensorFlow了。果然牛人是在什么地方都能发光发热的。

提这个人是因为他发表了Dryad这篇论文。Dryad这个东西最终被微软用到了一些产品里，具体的细节我们也等到了后面相关的故事慢慢展开。但是作为一个比MapReduce更通用，也同样更底层的系统，在这个时代里其实是被大大的忽略了。另外说一句，Hortonworks主导的开源项目Tez的原型就是Dryad系统。大概是2013年左右，在Cosmos里面负责开发Dryad相关的东西的一个印度人跳槽去了Hortonworks，我想这可能和之后Hortonworks决定做Tez有一定的关系。

Dryad的基本思想并不难理解，说白了就是一个有向无环图的执行引擎，其中图里面的每个点表示了一个计算，而边则表示了数据流，边的方向决定了数据的流向。系统可以通过这个图来按照一定的调度尽可能的让更多的东西并行执行起来。Dryad的另外一个特点是，图上指定的边可以在运行时候进行展开，举个例子来说，套用MapReduce吧。程序运行前的图可以是一个Mapper和一个Reducer，但是当runtime发现数据量比较大的时候，它可以动态的切成若干份，从而改变图的结构和连接，获得更多的并发度。最初实验室里面的Dryad其实缺了很多东西，所以只能稳定的运行在几百台机器上。而经过Cosmos组不断增强的Dryad层，可以扩展到几万台机器上。MapReduce里有的监控和自动重试功能在这个系统里面也同样的实现了。

我想系统的细节我就不展开了，大家可以看论文去。但是作为和MapReduce比较一下还是有必要的。其实Dryad就是一个DAG的执行引擎，学到了Google作为MapReduce infrastructure那个部分的核心。在一个海量文件系统的支持下，做到了对系统的自动监控，运行和重试。另外一个方面，这个系统并没有局限成Map Shuffle Reduce这三个阶段，故而提供了很多的灵活性。

但是我们需要注意到的是，这个系统对用户的要求太高了，需要给每个节点定义计算，给每条边定义数据流向，和MapReduce比起来，就像是SQL和汇编的区别。所以这个系统其实是没有那么强的可用性的。不仅仅如此，因为用户要负责的东西很多，所以用户错误也可能导致很多的job 失败的问题。因此大家可以想象，下面的路就是在这个汇编语言上发展出更高层次的编程接口。DryadLinQ和SCOPE就是在这样的背景下诞生的两个项目。关于它们，我们留到以后相关的主题的时候再展开。

额外说一句MapReduce这个框架里面的Shuffle其实是不公开给用户的，当然，你非要override partitioner也是可以的。然而不知道大家是不是注意到Google论文里面的一个细节。Google的Shuffle阶段是Sort based。作为一个长在关系代数下的生是关系数据库的人，死是关系数据库的死人的我，第一次读这个论文的时候在心里大大的嘲笑了一把Google这个傻13.这种情况下不就是一个GroupBy么。关系数据库的世界里玩了几十年了，Hashing明显是比Sorting更好的一个选择么。

只不过Google没有告诉大家，在数据规模足够大的时候，Hashing会产生很多很多的小文件，因此，它的效率其实不如Sorting。如果我们追溯一下现在特别流行的Spark的版本变迁，在早年的版本里，Spark做了并且只做了Hash-based partition，充分说明了Spark是一群根红苗正的关系代数和关系数据库的人搞出来的。但是后来Spark实现了Sort-based partition，并且把这个做成了默认值。我想Spark肯定也是吃了大量小文件的亏，所以只能吃土了，老老实实的做Sorting-based。我其实不知道Google是一开始就直接上了Sorting呢，还是Hashing失败了再搞的Sorting。但是这种细节上的东西，没有做过是断然无法真的知道的。顺便说一句，Cosmos里面最后还是Sorting和Hashing都有，并且默认是Hashing，因为解决了产生大量小文件的问题。

Dryad和MapReduce比起来显然是没有太多的声音，而微软作为这波大数据里面非常另类的一个公司，在整个浪潮里也并没有扑通出什么来。但是一则我是微软出来的，二则我觉得让大家看一看相对更小众一些的实现，现在回头看也有其参考价值。