與 hadoop 對比，如何看待 spark 技術？

我先說我個人的結論。

我的結論必須基于2017年9月初這個時間節點。因為未來，是存在一切可能的變數的。

1.Hive 在短期2-3年内，仍然無法被取代。大部分中大型網際網路公司的sql類大資料分析job，70%以上都仍舊會跑在hive上。

2.presto ／ impala / sparksql / hive on tez . 我認為presto目前是最有可能勝出的一個。

3.spark 的地位有些尴尬。在大熱之後，我不太看好他的未來。

我當然會慢慢來說我為什麼會下這些結論。

首先，我在說幾個我在工作當中看到的事實：

1.spark在小資料集的優勢明顯。 spark更容易編寫類mr家族的job，引擎也更容易的幫助開發者構造了合理的dag執行步驟。 但是，在大規模資料集工作的時候，尤其是reduce的key很多的時候，spark的預設hash shuffle就完蛋了(具體請自己看spark的hash-based-shuffle原理)。是以高版本的spark也回到了mr賴以生存的sort-based-shuffle。既然在大規模資料集上工作，那麼記憶體顯然也裝不下（幾～幾十tb）大的表資料，是以spark在大資料上，幾乎沒發代替hive。hive是穩如狗，spark經常有莫名其妙的問題。

2.小資料集上spark 和 presto／impala類的對比。首先，我做個假設，即大部分公司85％+的資料分析工作，仍然是sql based的。那麼在這個前提下，我來談一談spark和 presto/impala的不同。 既然是在小資料集，那麼我們假設worker節點有足夠的記憶體，能容納整個sql查詢背後的資料表。那麼查詢的［速度／穩定性］（這玩意類似籃球屆的 [ 助攻／失誤] 比）， 就成為了最關鍵的名額。 spark的硬傷，就在于在spark官方推薦的幾種部署方式中，仍然需要每次動态的啟動spark-submit制定數量&記憶體大小的executor。 而presto/impala是使用常駐程序的方式。在期望值為秒級别傳回的小資料集查詢中，這是spark的硬傷。

3.相容hive，是另一個最重要的點。相容hive的好處，我就不做過多的解釋了。網上經常有很多公司發的《sparksql相容hive在xx公司的各種挑戰》，一堆一堆的技術blog，我想說這些是你們該幹的事情麼？ 你們的相容率,在spark1.8上，從50%做到了70%，在spark2.1呢？ 你們有能力把你們做的這些事情推進到spark社群，并merge進去麼？ 你們投入在這上面的人月，用presto是不是直接就work了？ 大多數人在搞這個的人，我想心中都有自己的小算盤把。 那麼diss完了spark-sql，回到presto/impala。

presto: 目前沒有明顯的硬傷，算是中規中矩的産品，相容hive最好，速度不慢，多租戶，資源控制做的相對很好。沒有不支援的主流存儲類型。 我認為這背後的一切，都是因為facebook是

遊戲賬号轉讓平台

幕後的推手。facebook是一家自己有大資料的公司。自己家用的産品，自己先production-ready，才好意思拿出來。那麼系統的設計者，就不是趙高在做紙上談兵，而是實實際際的考慮到了 sql on hadoop的實際痛點。

impala: 最大的優勢就是超級快。緩存metastore的資料，緩存hdfs block位置的資料，緩存一切能緩存的東西。 這很好，但是，這些資訊的變更也是很頻繁的。采用太多緩存的結果是很多查詢因為緩存資訊的失效而直接fail了。 而且impala是大資料發行商cloudera推出的sql on hadoop，他為了支援自家的parquet存儲結構，官方竟然選擇不支援orcfile這種在hive裡很常用的存儲結構 ［我們組的兄弟自己寫了一個支援orcfile的patch，馬上推給impala社群，司。 馬昭之心，馬上便知］。這就是cloudera的短視，和不接地氣。在sql on hadoop的市場格局還沒有徹底形成之前，在cloudera manager本身都沒有上市，沒有占據大多數大型公司的hadoop部署管理工具的前提下，居然就開始想護犢子，開始搞保護主義了， 真的是格局太小了。 同理hive on tez是hortonworks維護的sql on hadoop産品， 就你那點可憐的文檔，你是想搞開源呢？還是遮遮掩掩怕大家看到你沒有實力的代碼？

是以，我個人比較看好presto. 希望presto可以吸收impala上一些設計好的點。 在2-3年内統一這個sql on hadoop的市場。 未來待記憶體的價格進一步走低後，我們的“小資料集”，就可以變的越來越大了，那時候，hive的sql，也才更有可能會越來越多的跑在sql on hadoop上了。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

spark的部分，我忘記提程式設計範式。在shuffle的處理啊，記憶體管理啊，我認為在當下21世紀的今天，不會存在多大的技術gap，即一個公司一撥人的實作，可以2x 3x的秒殺另一個公司的産品。因為技術的理論基礎是差不多的。 那麼其不同，更多的表現在其他的架構點上。

presto&impala是純sql-based的，而spark最開始是rdd based，是要用scala程式設計的,要寫lambda表達式。我是個程式員，我很尊重lambda表達式，我尊重函數式程式設計。但我認為工程上，函數式程式設計是會阻礙這項技術的發展的。 lambda不好打斷點debug，也比過程式更難以了解一些。 一個公司真正創造價值的那幾十個，幾百個大資料job，是要更容易debug，更容易做長期維護來的好呢，還是在寫的時候為了快一些程式設計更好呢？ 而且，寫起來最快的，最容易不出邏輯錯誤，最容易懂的資料分析ddl語言，是sql啊。 是以到了今年，spark社群全面轉向了dateframe ,dateset, sparksql. 這玩意很類似 javaEE時代的hibernate，是一個大資料時代的orm架構.這可以看出spark社群在為了code based big-data job在努力。 但正如前面所說，我不知道spark社群為何不在相容hive這條路，把hivesql相容性支援的更好些，反而是去把重心放在dateframe ,dataset 上。 這就好比hibernate 不去做好怎麼相容mysql的sql，而是把重心放在hibernate自己的hql和creteria的api設計上。 這真有點kind of funny，想一統天下做sql層的入口，想革了hive 的命，最後撿了芝麻，丢了西瓜。