怎麼看hadoop Summit 2015 and Spark summit 2015？

01-12

首先，IBM 要在spark 上面拼了，據說要全公司參與到spark裡面，因為spark還在初創階段，所以早參入必然好處多。其他幾個大公司比如google，ms是怎麼看的？
Schedule 里有不少有意思的topic，大家覺得那些比較有意思的？
因為hadoop summit 上周也在san jose 開了，所以合併為一個問題吧。

我參加了今年的這兩個大會。我來說一說我個人的感受吧。

首先，IBM（如樓主所說的）宣稱在Spark上拼了，只是因為IBM在Big Data領域的發展太慢（相對互聯網企業而言），所以想乘上Spark這班快車，趕超過去。這到底對IBM公司有多大幫助，我不是非常的樂觀。而其它幾家大公司早有類似的技術布局，所以沒有必要像IBM宣稱的那樣孤注一擲。

下面是詳細的感受。

會議資料

Hadoop Summit 2015: 日程, 錄像, PPT

Spark Summit 2015: 日程(含錄像與PPT), 完整錄像(Track A, Track B, Track C)

會議規模

大數據的社區規模在不斷的擴大。今年的兩個會議的參會人數都創了新高。Hadoop Summit 2015的參會人數是4000，同比增長30%（2014: 3100, 2013: 2600, 2012: 2100, 2011: 1600, 2010: 1200）。Spark Summit 2015的參會人數是2000，同比增長300%（2014: 500）。可以看出，Hadoop Summit的參會人數還在加速增長，但是增長速度遠遠不及Spark Summit。值得一提的是這兩個會議的門票都要上千美金，所以這麼多的參會人數很好的反映出了目前大數據的熱門程度。另外，兩個大會上有很多不同行業的公司現身說法，講述Hadoop/Spark技術的應用，可以說大數據已經在很多行業落地生根了。

關於為什麼Spark的發展速度比Hadoop更快，我認為有以下幾點原因：

1. Spark非常容易使用。Spark Notebook，Spark與Java/Scala/Python/R的互操作性都做得非常好。而Hadoop的早期用戶和社區的主要貢獻者都來自於大公司，服務於資深用戶。資深用戶更關注功能是否完善、系統是否穩定，而易用性就不是主要的考慮因素。

2. Spark是為互動式使用設計的。這體現在聚焦於規模較小的數據處理應用，因而使用內存來加速變得非常重要。這也體現在剔除很多不必要的開銷，例如JVM啟動時間、polling/heartbeat interval、用來防止出現Self-DDOS的sleep/wait。而Hadoop社區的決定者很多都是大公司。在那裡，超大規模的數據計算是最重要的，而幾秒鐘的啟動時間和等待都是無關緊要的。

3. Spark的Committer非常注重發展外部的代碼貢獻者。一開始，輔導外部的代碼貢獻者來提交patch可能比Committer自己寫code提交patch更慢，但是輔導外部的代碼貢獻者是一個很好的投資，可以有長期的回報。顯然，這個策略在Spark身上非常奏效。

相對來說，Spark的技術比較新，所以運維穩定性、調試等方面不及Hadoop的相關技術。今年Berkeley AMPLAB就專門在USENIX NSDI 2015上發表了一篇文章 Making Sense of Performance in Data Analytics Frameworks 來講述如何調試Spark的性能問題。

趨勢

1. Hadoop技術進一步的成熟。Hadoop最近的比較大的進步都是在運維穩定性和性能上的，例如HA（High Availablility）for YARN ResourceManager，Rolling Upgrades，Erasure Coding Support inside HDFS 等等。相對來說，用戶可用的新功能較少。

2. Spark在Machine Learning和Data Science/Statistics用戶中的普及非常快。Spark Notebook，MLLib，SparkR 是Spark的幾個殺手級的產品。SparkSQL中的DataFrame也是一個非常有效的功能，但SparkSQL在Data Warehouse領域（如ETL，BI等）的前景還有待進一步的觀察，因為SparkSQL畢竟是後來者。

3. Spark和Hadoop的生態系統在融合。這點可以參見Hadoop Spark, Perfect Together。Hadoop和Spark各自都有很多子項目。對於一個大數據的高級用戶來說，他/她所做的決定一定不是」我到底用Hadoop還是Spark「，而是"我到底用Hadoop的哪些組件和Spark的哪些組件"。所以，對Hadoop和Spark的各個子項目的了解變得非常重要。

我最關注的技術

1. YARN。YARN是Hadoop 2的計算資源管理調度系統，可以說YARN是Hadoop 1和Hadoop 2的最主要的區別。YARN從2010年開始開發，2013年10月發布第一版，到現在已經有5年歷史，所以技術也相對成熟了，可以在生產環境中穩定的使用。目前Dropbox的Hadoop機群就在遷移到YARN的過程當中。

感興趣的同學建議先讀一讀 Hadoop YARN的Blog。然後重點關注這些新功能：Rolling upgrades，Support for Long-running services (HBase, Storm, Kafka), support for Docker containers。將來YARN會有更多的監測和調試功能（如Timeline server Next Generation），也值得關注。

2. Hive與Stinger。Stinger是2013-2014年Hive上最大的改進，號稱要把Hive的效率提高100倍。到今年這項技術已經比較成熟，可以在生產環境中比較穩定的使用了。Stinger包含三大方面的改進：ORCFile（優化列存儲），Vectorized Execution（向量計算），Tez（非Map-Reduce的DAG執行系統）。這是Dropbox的Hadoop機群下一步的升級目標。

3. SparkR。 我之前學過一些統計的課程，很喜歡R語言在數據處理方面的優勢。SparkR把Spark和R結合在一起，對於學習統計的同學來說，會有非常大的幫助。我猜想以後很多大數據方面的高級應用（風控建模之類的）會使用SparkR。

4. Project Tungsten。Tungsten會給Spark的性能帶來非常大的提升。主要的技術點有：使用Off-Heap Storage並去除Java Object的overhead，Cache-aware Computation，與Code Generation。這個項目還在開發的過程中，有興趣的同學可以參與進去。

建議

1. 初學者與大數據應用愛好者：建議從2014年的 Databricks Cloud Demo 開始，去 Databricks Cloud 註冊用戶（點擊右上角"Sign Up for Databricks"），做一些練習，掌握大數據處理的基本流程。

2. 大數據底層技術開發者：建議關注Project Tungsten並且參與進去。

3. 大數據高級用戶：建議多多關注各大公司使用這些技術的經驗總結，例如Letter from the Trenches: An inside look at Hive at Yahoo 。如果還沒有在生產環境中使用YARN與Hive Stinger，建議開始考慮升級。

從這次spark summit上看，spark的方向大體包括兩塊：data science和platform API，前者包括DataFrames，Machine Learning Pipeline以及R language，後者包括多種源的通用介面還有一些spark 的package。除了IBM宣布大力支持spark之外big data三巨頭(Mapr,hortonWorks和Cloudera)紛紛表示自己的平台對spark支持良好，並持對spark的積極態度。其他公司像TimeFul（被google收購了）的Gloria Lau也發表了一個key note

分享下我們Apache Kylin在兩次Hadoop峰會上的演講和參會的感受，內容較多就不copy到這裡了：

Hadoop Spark 峰會雜談

我來為樓主添磚加瓦，關於IBM投資spark的事，可以參考這裡助人就是助己：IBM宣布大規模資助開源大數據項目Spark. 為什麼IBM會這樣做，個人認為IBM根本上說是一個諮詢公司，估計它發現客戶對大數據的需求與日俱增。而Spark正是下一代大數據最有前途的產品，當然要早做布局了。

Spark 1.3是一個非常重要的版本，因為在這個版本里，SchemaRDD演化為了Dataframe。這個演進消除了無數Data Scientist （他們習慣SQL，Python， R而不是Scala，Java）接受Spark的最大障礙。可以預見，很多傳統數據工程師將開始擁抱Spark了。

至於2015 summit, 我比較關注機器學習。

苦於門票價格，窮學生就是看看現場的video 和 ppt了。

樓上參加了大會的同志的總結的蠻清楚的，有心了。

補自己關心的幾個領域的問題。

(1) 我們組一起看了 data frame的talk，但是沒有什麼新的東西。就是把之前在blog上宣傳的data frame的好處在說了下。btw：老闆說，dataframe 名字改的好啊，就是rdd加上schema, 可以利用現在spark sql 去優化查詢器。

(2) optimization the Mlib, 根據我們自己使用 spark LDA or page rank 的experience 來說。spark還是還是比較慢的。感覺得原因可能是使用了graphx 裡面的圖的切分有問題。因為graphx 是 vertex partition。而不是針對具體的圖的分布來切分的，比如說二分圖有power graph這種特性，很可能有的節點有大量的edge，導致了load balance 的問題。這就需要用戶手工來做切分，這還是蠻苦難的。同時MLIb matrix 計算的時候，底層還是調用的常見的matrix 計算包。分散式的矩陣計算，spark 還是需要優化的。今年sigmod 有一篇 cui bing 他們組的論文，就是解決矩陣計算的時候，怎樣切分matrix的問題。idea 很好的，但是沒有具體實現其中的 query plan 優化器。

(3) reduce the serialization cost 也就是上面說的Tungsten 這個項目，其中一個分會場上說了一些細節，比如怎樣減少serialization 的 cost. 我沒有仔細看實驗結果，但是聽mentor說，spark serialization 一個object 需要的內存太高，需要重新設計可以達到減少10多倍這部分的內存使用量。具體不太懂，但是感覺這個意義太大。因為 caching and checking point spark的時候，內存消耗好大的。

(4) bloom filter in the data block 這個內容是hadoop summit 上 cloudrea上一個組的talk，就是說如果在arc file or parquet file 裡面，如何在一個data block 裡面加上bloom filter 這樣就可以加速對於某一個column在讀數據的時候可以加速查詢了的。

補一個最新Michael Stonebraker 的關於spark vs hadoop 的討論

Michael Stonebraker 把hadoop的演進歷程被批判了一番。首先mapreduce 未來幾年要被完全kill掉的，大家應該記得當年他和google 大神的論戰吧，hadoop 現在不是 map reduce 了的，而是HDFS+ others. 最近改變為 HDFS+Spark.

他predict 未來db的幾個方向。

(1)column based db 將會完全取代 row based db，

(2)in memory database 更加重要，

(3) data curation 將會更加重要，因為數據的質量直接決定了後面一切應用的效果，他好像針對這個開了一個公司。

(4)他老人家最後說了自己的scidb 如何能夠做 data analysis，如何如何的能夠支持array or matrix operation.

(5)他說spark 的一個問題就是對於streaming query real work, 因為spark streaming 是batch based。雖然這個batch 很小，但是還是不適合streaming query 的logic。同事對於OLTP spark 是不可能支持的，這對於很多公司來說，OLTP很重要，而新的memory db 將會fit 這個需求。spark 在matrix計算上和 scidb的差距是, scidb 只需要2台機器，而spark 需要上百台機器來達到相同的response time.

其同坐的其他幾個大牛說了不同意見，對於spark 都表示了肯定的態度，就是spark 不管好不好，現在是一個evolve 很塊的系統，在spark core的基礎上，加了很多的功能，比如graph，R，streaming，data frame 等等。這樣就能很快滿足不同的需求。

好吧，我對於spark最喜歡的一點就是代碼寫的很好，很簡單，很好懂，所以才有大量的人去貢獻,而 scidb的代碼，我就...了。

就說這些了吧，謝謝樓上的回答。

這個演進消除了無數Data Scientist （他們習慣SQL，Python， R而不是Scala，Java）接受Spark的最大障礙