大數據那些事(18):DoNotEvil公司的程序猿味

01-28

這篇文章填一下以前寫的時候留下來的坑。

前些天和幾個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 等等問題之外，多多關注大數據平台的易用性。