大數據那些事(8):HIVE之初期起

01-27

在大數據領域，發展到今天HIVE已經可以說過了集萬千寵愛在一身的階段。然而即使是過了氣，我們依舊必須承認它還是有著極其巨大的影響力，廣泛的使用率。無數的人依舊繼續去優化，包括最新的HIVE2.1裡面對內存計算的優化，無疑說明起碼有一小撮人，以Hortonworks為代表的那一小撮人，依舊在努力的優化。從另外一個方面看，當紅炸子雞的Spark在支持SQL的時候也需要做到和HIVE的兼容，可見HIVE已經事實上成為了Hadoop平台上SQL和類SQL的標杆和事實的標準。

從歷史發展的角度，我的確應該寫一篇HIVE的文章。但是當我開始寫的時候，我卻覺得並不是很好寫，無論從技術的角度上還是從八卦的角度上。很多東西都耳熟能詳。我知道的多半大家都知道，大家都知道的小半我也不知道。所以這篇文章難免流於打醬油的嫌疑。

2008年的炎炎夏日，Hadoop的聚會在傻白甜活雷鋒Yahoo的辦公地點開了一圈又一圈。沒有車的我跟著18摸的人(下一期公眾號文章的主角們)，去參加了好幾次這樣的活動。活動的開場大致是這樣的。我們Hadoop現在又取得了偉大的成就啊，來，大家鼓掌。Yahoo的那幾個後來或者離家出走或者被spin off，乃至導致了後來Hortonworks和Cloudera互相撕逼主角們那個時候還和和氣氣的露臉，和一群二愣子們一起鼓掌，吃垃圾食品，喝碳酸飲料。

這個時候通常出來的有個美國佬，我來說說我們最近在做的一個東西吧，小小的做machine learning的，Mahout。當然這個小小的慢慢也就變大了，慢慢大家發現大是夠大的但是慢的可以。大公司比如Twitter上過賊船又下來了。所以Spark出來的時候大家歡欣鼓舞，很多時候也是因為Mahout太爛太慢。但是不管怎麼樣，出道早，就容易出名，無論是臭名還是好名聲。

還有兩個印度小哥，上來的時候笑的靦腆，一看就不是老江湖。恩，我們是從非死不可來的，我們最近在做一個東西叫做HIVE。這個東西是這樣的,像SQL。我們叫它HIVE。過些天我們會給開源出來的。

有人問，這東西你們啥時候寫的，用在非死不可裡面了么？小哥們靦腆的說，你們知道的，非死不可的活很多的。但是我們經常有Hackathon，我們的Hackathon都是從晚上6點開始到第二天早上，一個晚上讓我們寫很多東西。我們幾次Hackthon下來也就出來了這個叫HIVE的東西。一副你懂的，我們很辛苦我們不能耽誤正常的工作的樣子和神情。當時我就說乖乖，非死不可不能去，白天要幹活，晚上還要hackathon，那我是不是要掛了。所以一開始對這個公司就沒有多好的印象了。

小哥們繼續說，我們用SQL很久了，可是我們覺得SQL很彆扭，明明應該是FROM ... SELECT ...，卻偏偏搞成SELECT FROM WHERE，不知道是哪個傻蛋設計的。我們比那個傻蛋聰明多了，你看，在HIVE裡面我們把它改回了FROM...SELECT...。確實我在這裡必須給這兩個小哥點個贊。SELECT FROM非常的反人類。只有18摸（IBM）這種能做出那麼反人類的DB2的UI的地方出來的人才有可能搞出同樣反人類的SQL啊。

當然隨著HIVE的發展，FROM...SELECT...基本上都不提了，而SELECT FROM也支持了。但是各位看官不妨去試試，小哥們最初的FROM SELECT作為兼容性的需要應該還是保留了下來。

大概一年多以後我去開ICDE2010年得會，遇到了另外一個印度小哥，是Jeniffer Widom的學生，暫時quit了PhD，去非死不可組上班。一聊天，不得了，做的是HIVE。也就是那一年姍姍來遲的HIVE的論文發了出來。再一聊天，那倆開發HIVE的印度小哥們都升職了，不一樣了。這個小哥一樣的淳樸，告訴我寫這篇paper他花了多大多大的力氣但是卻沒有得到多麼多麼靠前的名字。我只能笑笑說，做得多不如做的早啊，你要是早點進HIVE不但論文你名字靠前，而且還能做出更好的design啊。印度小哥們都有很淳樸的過去啊。

後來再追尋一下，這倆印度小哥很長時間一直在HIVE的PMC裡面，大概一直到2014年的樣子吧。他們早不在非死不可，自己搞了個創業的大數據公司。再後來，一群做Pig的人看上了HIVE的資產，同樣看上的還有第一批發商Cloudera。 Hortonworks先是塞進了一個PMC，然後就開始夢塞PMC,到今天，HIVE里這倆小哥已經除名了，Hortonworks和Cloudera基本上大半和小半的江山了。Cloudera因為自己戰略需要，只是在HIVE插一腳，做一些企業客戶需要的比如安全方面的東西，Hortonworks則在戰略層面提出了要努力提高HIVE的性能，不需要其他的輪子。於是TEZ也上了，那個戰略有個名字叫Stiner。

做Pig的人成了HIVE的主力，做HIVE的人卻不知道去哪裡了，鳩佔鵲巢的故事哪裡都能發生。

關於HIVE，說白了就是因為在Hadoop裡面的整個stack它最像SQL了，加之又起來的早，所以一堆做database的人就把腳查插進來，越做越像是一個數據倉庫的鬼東西了。這就是站在風口飛起來的豬，雖然說這豬的肉實在都不怎麼樣，賣相還可以就先湊合了。只不過我不太清楚那個當年Hackathon趕出HIVE的兩位對於HIVE變成今天這樣是什麼感觸。當然有一點可以肯定，HIVE這個project 非死不可其實不怎麼在乎，而兩個小哥對於整個codebase的控制能力有限，所以作為結果，這和很多的其他開源項目不一樣，在HIVE裡面是兩撥人在弄，都不是原來的主人。這比起Spark主要在Databricks的掌控下，Kafka主要是linkedin出來的人在負責一般，是有很大的不同的。很多時候，項目的創始人對項目有主導權，就更容易推進這個項目健康有效率的發展，而一堆人在裡面開始扯皮，事情就不好說了。Hadoop在兩年內沒出一個新版本就是一個很好的例子。僅僅從這個角度看我也覺得Spark將來一統天下的概率非常的高，我非常的看好啊。

HIVE的早年就需要metastore，這個metastore的主流選項是某個關係資料庫，當然也可以寫入HDFS。後來這個東西大概在2011年左右被抽出來變成了HCatalog，而HCatalog之後也就成了很重要的一個組成部分。

我其實是非常喜歡metadata store這樣的東西的，但是我對HIVE的這個東西，尤其早年的版本非常的痛恨。因為你對它進行的操作都是metadata only，data還需要自己手動去清理。如果不這樣做的話metadata和data之間的一致性問題就沒辦法保證了。現在都21世紀了，做個東西不能做成玩具一樣，不然的話，誰能用得舒服呢？

我想HIVE的成功證明了風口的豬總是會飛的。也證明了蜀中無大將廖化作先鋒這句話很有道理。只是今天HIVE在不停的發展，只要有公司還願意不停砸人砸錢進去，HIVE和其他SQL on Hadoop的競爭就不會停止。Spark，比如說，的壓力就一定多多少少的會存在。但是有壓力才有動力么，我特別想知道最後到底誰能一桶漿糊。目前看起來Spark最有這個可能。但是計算機領域實在是變化太快了。