384
Spark實踐的階段性總結
寫這篇小總結是因為前段時間是自己業餘時間對Spark相關進行了些探索，接下來可能有別的同事一起加入，且會去借用一些別的服務器資源，希望可以借此理下思路。
實踐Spark的原因
在之前Spark簡介及安裝的文章前麵，介紹了Spark在大數據處理領域的一個定位，以及AMP實驗室構建的生態圈，總之我定義Spark為一個值得研究的東西，包括他的實現語言Scala，底層的資源管理Mesos/YARN。對於Spark的實踐，我理了下思路，大致有以下幾個階段：
1.看paper，官網等網上的資源介紹，了解熟悉Spark，熟悉scala之後看看源碼
2.搭建Spark，以standalone的方式run example，在spark-shell下體驗一下Scala的API，在pyspark下體驗Python API
3.搭建Mesos，讓Spark依賴Mesos跑起來
4.更大規模搭建Spark集群，測試一個場景，對性能進行評估，出一個具有說服力的報告
5.優化Spark集群配置，編寫更多算法去體驗
6.最後，基於Spark這個核心，打算建立一個平台，現在的構想還比較初步
現在處於從3進入4的階段，而關於Spark的構想，也還有一些東西需要去實踐，新的技術需要去調研和了解。大致是有了Spark集群之後，對Mesos和YARN有一個選擇問題，從Spark讀取另一個Hadoop的HDFS上文件，這件事的網絡延遲影響究竟有多大，畢竟現在的情況是hadoop和spark肯定是部署兩套機器上，存儲節點和計算節點分離，特別是基於Mesos的話，肯定是這種狀態。像豆瓣的Dpark可能是和MFS上的數據打交道的，可能會比較好地解決本地化的問題，可能能檢測到目標數據存在某個節點上，而把這次任務調度到那台機器上，類似這樣的感知我們肯定做不了。其次，現在搭建的Spark，目標是為了一些ML，DM的算法服務，如果是SQL能完成的簡單查詢任務，ad-hoc的東西讓Shark來做應該就滿足了，所以相關python的算法包支持，甚至能否支持結合R在Spark上，也是有待考察的一件事。關於這點，AMP實驗室正在開發的MLbase是支持了不同抽象程度的算法api，今年夏天應該是要release一部分，冬天還會release一部分，MLBase能在Spark上提供給我們什麼樣程度的支持也有待考察。更遠的，Scala其實還蠻適合編寫DSL的，最後我們希望能在Spark這層之上，基於python等算法包，在最上麵再封裝一層DSL，類似Hadoop上的pig，而不是hive，來把數據處理的整個過程可視化出來，每個過程都可以清楚地剝離，甚至可以可視化。
Spark及周邊
我可以使用的開發機無法連接外網，所以搭建Spark時使用的是編譯過的Spark版本。Spark的編譯依賴scala的sbt(simple build tool)，相當於java的maven，但會更強大。sbt方麵，本來Spark可以支持sbt構建的scala項目，但是sbt compile test package這些步驟在開發機上無法完成，根據項目裏的build.sbt，構建是需要聯網的。無奈的做法是使用spark的pyspark跑一些.py的程序，而spark支持的python API有些功能還沒有完全完善，而且python是動態語言，在進行RDD相關操作時候，api使用起來總有些區別，不像java和scala的api會大同小異。
Mesos的搭建也是費了一番力，Mesos的優勢在於利用linux container，完成了資源的分離和調度工作，不過也比較迷茫Mesos是否真的可靠，是不是YARN會更靠譜，比較Mesos是C++寫成的，與Spark的交互會依賴JNI。淘寶的Spark是搭建在阿裏的YARN集群上，所以我也還要進一步確定對於Mesos和YARN兩套資源管理係統的異同。
以上兩點是關於sbt和Mesos的，還有最近有意學習了下Scala這門語言的情況，有一些總結。《programming in scala》和《scala程序設計》都看了一遍，後者更適合java程序員讀，從實踐和特性介紹角度，都更好。整體上，scala的創新也許就是綜合了其他語言的優點，本身是純OO且麵向函數的，這兩者之間你可以使用任何一種你習慣的編程方式。與java的兼容不需要任何特殊寫法和膠水代碼，繼承、調用、訪問域、實現接口都沒有問題，trait擁有類似接口的實現，介於單一和多繼承之間，可以做到類似AOP那樣切麵的效果。函數式編程方麵把immutable貫徹在每一處，從變量聲明val到不可變的容器。函數式編程的思想主要就體現在兩點上：函數是一級公民；方法引用透明。前者讓函數可以像值一樣互相傳遞，函數內可以內嵌函數；後者保證任何方法的調用都可以用他的結果來代替，而不影響程序語義，即函數不會有任何副作用。並行編程方麵借鑒erlang的actor模型，每個傳遞對象本身就是不可變的，自然不用擔心多線程時候對某個變量的修改操作會帶來的任何影響。其實Spark裏很多對RDD的transform操作，都大量依賴了scala本身帶的filter(), map(), reduce(), foldLeft(), foreach()等操作，而scala的不可變也完全符合RDD。
階段總結及展望
現在正在嚐試一個可測試的場景，稍微編寫一些代碼，從HDFS上取數據，做一些處理。然後將這個程序放到更大的集群上去對比，性能怎麼樣？關於Mesos和YARN，也需要更多的調研和嚐試，而sbt如果在現有的開發機上不可行的話，是否先編寫python版本的程序運行？嚐試部署一個Shark，看看Shark是否能夠投入到一些場景中使用？python、R，怎樣/是否可以融入Spark？MLbase？Spark本身源碼層麵的了解，以及scala語言本身更深入的認識。
在探索Spark的過程中，還需要更多的實踐，更深的了解，更廣的涉獵。
(全文完)
最後更新：2017-04-03 16:49:06