What’s the task of a system guy

大约1个多月之前就想写这样一个文章， 我想谈谈在我眼中， 一个系统方向的硕士生、博士生或者广泛到所有类型的身处高校的研究者应该做怎么样的工作。

 

本人仅仅是硕士阶段进入尾声而已，并且所做的工作仅仅涉及庞大的系统方向的一小部分， 所以在这个文章中， 所表达的观点仅仅是个人思考的成果， 所用的例子也来自于我最熟悉的领域，但是我相信，这篇文章会给大家带来一些思考、自省的机会， 因为当我思考这个话题的时候， 我总是在反思自己以前的工作， 找出失败的原因。我希望这篇文章能带给所有读者同样的体验。

 

1. 关于系统方向， 关于我

 

首先我想谈谈我眼中的系统方向，系统方向其实是一个庞大的体系， 包括体系结构， 操作系统， 安全等等等等，这是个很难去划分出明显边界的集合， 那么就谈谈他的特点吧。

我觉得系统方向较之于其他领域， 例如图形学、计算机理论等， 最突出的特点是其实用性。系统领域的课题永远是面向特定的问题而存在的， 比如软件运行速度过慢， 消耗资源过多，并行软件调试所面临的问题， 这些问题长期困扰着软件的用户和开发人员。只要是做系统的基本都是为了去解决问题。 纵观我所看到的各种系统会议， 水会上的所发表的工作， 往往是一个自创的问题或者是一个已经被人解决了的问题， 而牛会上的工作， 面向的是一个困扰工业界很久的问题。但是这不影响系统方向所存在的特质：面向具体问题。同时， 刚才我说过， 这些问题更多的是困扰工业界的问题， 所以这是系统方向存在的第二个特性， 对工业界的推动性和引导性， 这个特性我想这样解释：“系统方向的顶级研究是计算机科学中与人类生活最密切相关部分的方向盘，而工业界的code monkeys是这部分内容的发动机 ”

 

那么介绍一下我的研究方向， 目前是两块， 分布式系统的scalability（偏大规模数据处理系统， 如mapreduce）和数据中心的能耗问题，介绍这个的目的主要是为了说明本文中所举例子的范围。

 

1. 失败系统研究

我眼中比较失败的系统研究基本都有一个特质， 就是纯粹是写代码， 而不是解决问题。前一段时间看了Matt Welsh的一篇讲他作为hotos chair的感悟的博客， 一个GOOGLE的researcher（这人也是HotOS的PC）说， 他再也不愿意看到一种投稿， 就是称自己提高了Hadoop性能10%， 原因并不是说Hadoop这个软件很烂， 根本没人关注， 也不是说10%这个指标太小了， 而是这种工作没有意义， 这种在既有基础上提高软件性能的工作工业界早就做完了， 只是出于公司利益的原因， 没有公布出来， 而且这种tuning， 是不是适用到每一个场合是一个很大的未知数。因为这类的工作， 不能提供给读者学习的机会， 除了XX大学有个人编程还蛮吊的。

所以这类的工作是很典型的一个失败的系统研究课题，其犯的错误根本在于解决一个别人明显已经解决的问题， 因此， 从这个例子中我们应该学到的是， 如果你发现你现在手上拿的一个开源软件性能不是很好， 你发现其实仅仅是因为某个算法或者某个数据结构设计的不好， 你想改了他， 发篇论文， 你的论文必然是个水会， 因为你自己应该清楚， 使用这个软件的人群中， 技术比你好， 理解比你透彻的多的是， 不改有不改的理由， 改了有不说的理由。

 

还有一类失败的系统研究应该是create problem了， 其实我觉得在中国CREATE PROBLEM比上面一种严重多了。自己创造一个问题， 自己解决， 大多数是因为闭门造车。不知道工业界的故事， 随便做出了一个假设， 假设在什么什么情况下， 其实这个情况很少存在。如果你的问题是拍脑袋想出来的，或者是先实现再找应用场景， 我觉得你写出一篇荒诞的论文几率还蛮大的。好的研究课题都是在生活（我指的是与研究相关的生活中）观察到的某些特定的现象：例如， MPI，PTHREAD的弱和复杂诞生了MAPREDUCE；CPU数据并行度的缺乏和CG的复杂催生了BROOKGPU从而诞生出了CUDA和BROOK+；LINUX原有文件系统在集群环境和大数据量压力下的不足催生出了CEPH。

 

1. 好的研究

这一部分我想来分析下从2009-2011一些顶级会议中的论文（主要是OSDI , SOSP）， 尤其BEST PAPER的工作， 从而找出它们的特性， 最后得出我的结论。

 

我首先要说的是， 不是所有的OSDI SOSP都是好的工作， 至少不是都是来自大学的学术圈应该去做的事情

 

我觉得包括很多大学里的学者过分迷信OSDI SOSP了， 我觉得这些会议里部分的工作由于各种各样的原因发表了， 但是却给了我们误导的作用， 认为这才是我们应该做的事情， 其实不然， 我想吐槽一下OSDI 2010 GOOGLE的一篇文章.

Large-scale Incremental Processing Using Distributed Transactions and Notifications

这篇文章讲的是GOOGLE新一代的WEB INDEX系统， 其脱离了原先基于MAPREDUCE的设计， 支持了INCREMENTAL COMPUTING， 使得GOOGLE的WEB INDEX信息能够做到以小时为单位更新， 这个工作是个很好的工作， 真的是代表了互联网巨头， 搜索引擎巨头的实力， 但是这个文章写的， 其实是一个故事， 是一个写了一个系统发现不行， 然后改改， 然后再性能调优的故事， 这不是一个真正的研究， 这篇文章不会对你有任何的学习价值， 除了你可以知道GOOGLE现在在用什么技术之外。换句话说， 这个文章不是真的研究工作， 是一个工程实现。

 

所以看这样的文章， 我个人感觉大家还是应该辩证的去看， 这是你了解工业界发展的好机会， 但是学术界的任务不是这样的， 下面挑我知道的比较喜欢的OSDI SOSP 级别的工作做简单介绍

 

下面我想就09-11年与分布式系统， SCALABILITY， 包括POWER相关的我比较欣赏的工作做简单介绍， 从而得出一个基本的结论， 什么样的工作是好的工作， 会产生被收录到顶级会议里的论文

 

1. Helios: Heterogeneous Multiprocessing with Satellite Kernels &The Multikernel: A New OS Architecture for Scalable Multicore Systems这是两篇SOSP 2009类似的文章， 我到今天都想不通这是肿么了， 怎么会一届SOSP收了两个几乎完全一样的话题的文章， 还都是M$做的。好，开始看这两篇文章： 其都是讲的是一种提高OS Scalability的方法， 这种方法有点复古主义的倾向， 其实整体架构就是微内核的一个思想， 在每个核上都运行一个操作系统的内核，这样就有效的MATCH了NUMA的架构， 从而提高系统的可扩展性， 并且能够针对未来可能出现的（其实已经出现， e.g. APU）异构多核架构提供必要的支持
2. B.      RouteBricks: Exploiting Parallelism to Scale Software Routers， 这一篇是SOSP 2009的BEST PAPER，他的工作的价值是向学术界展示了对于一个经典问题解决的未来的方向，路由的可编程性和性能一直是router design的biggest tradeoff， 其中一个解决方法就是软路由， 问题是软路由于载体是普通SERVER，PERFORMANCE实在太差， 而且现在的软路由都是在SINGLE SERVER上做， 遇到大规模计算机网络软路由明显搞不定。这篇文章其实真正创造部分没多少， 用了教科书上的topology， 搭了一个SERVER CLUSTER做ROUTER CLUSTER， 从而使得每一台SERVER的要求处理速率最多只要线速的3倍， 而通过对NIC驱动的修改， 单台服务器的处理速度也提高了很多，所以在他的设计下， 通过软路由完全可以达到高端硬路由的性能还提供了极好的可编程性， 从而ISP可以更便捷的提供服务， 研究者也可以更方便的展开网络架构的研究。 
3. C.        An Analysis of Linux Scalability to Many Cores，这是OSDI 2010的文章， 来自于MIT的PDOS组，我非常喜欢这个文章， 或许是因为对R. Morris的个人崇拜， 呵呵。这篇文章对影响LINUX SCALABILITY的因素做了一个全面的实验性验证， 并且通过自己的方式解决了部分的因素。但是一作在TALK的时候也承认了， 他的方法其实某种程度上是questionable,所以他并没有把这个PATCH提交到MAIN LINE里。但是这个文章的意义就在于， 他是真正的研究， 谁说研究一定要出一个放之四海皆准的东西， 研究是一种探索， 这篇文章完全遵循了探索的含义， 他从探索到48核状况下的LINUX SCALABILITY， 并且做了非常convincible 的分析，这就是研究， 这是现在的研究者对一个经典问题的最新贡献， 我想在未来很多年， 人们还会不断探索LINUX SCALABILITY的问题， 这篇文章所得出的结果， 会成为很多人最新工作的基石， 这才是最正统的科研。 
4. D.      Reining in the Outliers in Map-Reduce Clusters using Mantri， 这也是OSDI 2010的文章，来自于MSR著名阿三Srikanth Kandula的组， 他是大名鼎鼎的Dina Katabi的学生。 他其实是解决早在2004年就在Jeff Dean的Paper里提出的MapReduce的Straggler问题，这篇文章的牛B之处就是通过丰富的实验彻底调查了Straggler的原因， 而不是停留在以往的“Straggler 就是运行的过慢的进城”的肤浅的Definition上，他将Straggler的原因分为了Data Skew、System Error、Network-unaware task scheduling，从而对每一个原因都进行的不同的解决尝试。 
5. E.       Power Management of On-line Data-Intensive Services，这是UMICH和GOOGLE在ISCA 2011上合发的一个文章， UMICH的Thomas Wenisch确实是Energy Efficient Datacenter的一朵奇葩， 做出的东西我基本都很受用。这篇文章其实是讲的如何管理高负载， 连续性服务请求类型（个人理解就是streaming data processing）的数据中心能耗， 没有SOLUTION， 就是分析， 然后提出inactive model 比SLEEP MODEL更适合这类的数据中心   

 

 

3.1    这些研究的共同特点

1. 做了普通的程序员不能做的工作， 这些研究都需要深厚的理论基础和足够的研究时间， 普通的程序员因为各种原因的限制不可能做这些工作， 例如普通程序员没必要去研究N个不同程序的源代码， 然后有针对性的测SCALABILITY， 新的操作系统原型也不是每个人都能想出来的，所以如果你做出的工作， 普通程序员也能做，可以肯定， 你会被牛会拒掉的，因为你的研究， 不会让工业界学到任何东西。我觉得作为一个做系统的硕士生或者博士生， 应该找到自己的优势， 就是自己有足够的时间， 不需要去赶项目的DEADLINE， 自己处在一个理论基础相对扎实的环境里，所以顶级会议对来自学术界的工作的期盼， 在于能够对一个问题提出更透彻， 更有水准的分析， 而不是写了一个又一个的软件。我们都太急了， 换了一个又一个项目， 速度比外包公司都快， 而你的硕士生涯， 博士生涯少则3年， 多则6年， 这段时间是让你对一个问题做最深入的分析， 而不是让你3年做了8个项目。
2. 对经典问题的探究 和对未来的展望，部分好的工作只做其中一点， 比如PDOS OSDI 2010的文章， 还有一些工作用新的方法去挑战经典问题，比如MS在SOSP 2009的两个文章， SOSP2009的BEST PAPER则是兼顾了两个方面， 既解决了经典问题， 同时将软路由重新带进了大家的视野（参见NSDI 2011的BEST PAPER）。这里我想强调一下， 对经典问题的探究并不是说研究应该面向过去， 其实工业界在这么多年面临的问题永远是那几个， Extension不够， Scalability不够， 所以从这一点上来讲， 这些好的研究的共同点就是look beyond industry, 提出对工业发展方向未来的展望，对应以上论文，  A， 新的系统模型， B，软路由王者归来， C，LINUX内核未来的发展（比如，数据结构变小， 防止不必要的LOCK）, D,Hadoop现在就在提Resource-aware Scheduling, E， 这个不要说了， 新的应用服务， 怎么减能耗。我们的研究目标应该定高， 我说的是工作目标， 不是PUBLICATION， PUBLICATION应该是研究工作的副产品， 好的工作必然会有好的PUBLICATION，但TOP PUBLICATION并不都是TOP WORK（如果要我吐槽， 我还能吐好几篇这样的文章）。我们的工作是在现有条件的基础上， 提出自己对未来计算机科学的见解。

 

后记，

 

这篇文章是我在结合一个多月的思考， 在回家的车上完成的， 正如所有的technical writing的目的， 是交流，将自己在做一个工作， 在做很多工作之后的体会与同行， 同窗去交流。我期待你们的反馈。

----

好早之前写的文章了。。。