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