大数据那些事(17):DoNotEvil公司的程序猿味

这篇文章填一下以前写的时候留下来的坑。

前些天和几个DoNotEvil公司的朋友一起吃饭，做那个著名的display ads的。聊到对方怎么样去用著名的Spanner的时候，对方说了他们其实就一个一个TableScan，一个一个Join，一个一个的Aggregate那样的operator by operator的搭起来。这不是我第一次听到这种故事了。因为听多了，屡见不鲜了，我也就不再觉得那么吃惊。但是我想这里面透露出来的很多问题还是值得大家去思考思考的。

Google在MapReduce之后有过不少的系统，当年来看比较有影响力的是Sawzall和Flume Java。前者是一个新的语言，主要是用于更好的方便用户去写MapReduce Job。作为这个语言来说，我觉得其实没有什么特色，不比同期的HIVE PIG有特色。但是大概是因为顶着Google的名气，所以也就发了论文。这个系统后来应该也就慢慢没有声音了。 后者是一个Java library，实现了几个Parallel的collection，以及在Parallel collection上可以做的操作。

Flume Java本质上来说还是MapReduce，但是它采取了一种delayed execution的方式，把所有相关的操作先存成一个execution DAG,然后一口气执行。听起来很熟悉吧。没错，这个和C#里的LINQ差不多。这种方式就产生了很多optimization的机会了。具体来说大的有两个，一个是怎么样把若干个Map或者Reduce整成一个，一个是怎么样把一系列的operation整成一个MapReduce job。

我们常常说，每个公司都有自己的基因。比如说亚马逊吧，Business的人是老大，MBA进去就先给senior。程序员，尤其是底层的程序员就不重要了，升个senior老难了去了。DoNotEvil公司本质上应该是程序猿文化。所以无论是一开始做MapReduce，到后来的Flume Java，乃至很牛逼的Spanner，都无法逃脱程序员的那种味道。简而言之就是为了算点count，我们必须写个MapReduce，而不是写SELECT COUNT(*) FROM TABLE;

这种写physical plan的工作方式，对于优秀的程序员，对于只有固定几个task的项目组，往往容易产生更为高执行效率的实现。只是，实现和维系这些physical plan是非常非常的困难的。对程序员的要求特别的高。

但是这个世界上有很多的人其实不是程序员，比如说数据科学家。这些人让他们一个接一个的写mapreduce，尤其为了干一些简单的活的时候，我想就有点过了。这是为什么SQL作为一个语言非常流行，至少在某些人群里非常流行的原因。

然而SQL实在不是一个好的语言。任何东西一旦超过了最基本的界限以后，有些时候要查点数据，还不如裸写plan来的快。很多时候SQL如果带上了所谓的correlated aggrgate，那要理解起来就需要对SQL有更深刻的了解了。

我今天就偏离我们平常讲的performance， scalability之类的，讨论一下最简单的易用性问题。到底在大数据的平台下，乃至在正常的工作的时候，我们需要提供什么样的用户体验来保证易用性和灵活性。MapReduce作为一个平台，对用户来说不是太好使，但是也能勉强用起来。Flume Java则是在这个基础上，对Java的用户开放了一个更高层次的abstraction以及它们的实现。但是归根到底，这些都是非常典型的程序员的风格的实现。而SQL，或者类似SQL的语言是在Google的很晚的产品才开始出现的。我个人对于这种过分程序员化的做事方式当然有自己的顾虑。这个事情Google可以干，因为Google的员工素质还是不错的，但是其他公司如果in general需要去搭physical plan才能把事情做了的话，恐怕就不好说了。

SQL的存在是为了提供一个相对简单的用户体验。这种体验其实对初学者有很不错的帮助。然而SQL能够做的就那么多了，在SQL上搞machine learning，就很折腾了。Flume Java代表了另外一个极端，就是google的程序眼文化，不管什么东西都是程序员的方式直接去写程序来解决。后者最大的好处就是精准的控制和灵活性。

我写过SCOPE这个语言，我有对它满意的地方也有不满意的地方，然而这个语言也是在dataflow language和SQL之间做了一些妥协。这个语言因此也有了自己的特色。然而我这么多年来，最困惑的问题，从用户使用的角度来说，是我们应该提供什么样的programming language，使得简单的东西保持今天这样的简单，然而对更复杂的东西，依然保留一些简单和可控的特性。

Spark作为新一代的平台，对于语言的易用也是另外一种考验。如果问我个人的评价，我觉得我拿不太准，到底什么样的语言才是大数据时代里面最好的。这个问题我想了很久，有很大可能还会继续困惑下去。但是我觉得我们应该在performance，scabality 等等问题之外，多多关注大数据平台的易用性。