zhihu spark集群,书籍,论文
spark集群中的節(jié)點(diǎn)可以只處理自身獨(dú)立數(shù)據(jù)庫里的數(shù)據(jù)，然后匯總嗎？
修改
我將spark搭建在兩臺機(jī)器上，其中一臺既是master又是slave，另一臺是slave，兩臺機(jī)器上均裝有獨(dú)立的mongodb數(shù)據(jù)庫。我是否可以讓它們只統(tǒng)計(jì)自身數(shù)據(jù)庫的內(nèi)容，然后將結(jié)果匯總到一臺服務(wù)器上的數(shù)據(jù)庫里？目前我的代碼如下，但是最終只統(tǒng)計(jì)了master里的數(shù)據(jù)，另一個(gè)worker沒有統(tǒng)計(jì)上。val config = new Configuration() //以下代碼表示只統(tǒng)計(jì)本機(jī)數(shù)據(jù)庫上的數(shù)據(jù)，猜測問題可能出在這里 config.set("mongo.input.uri", "mongodb://127.0.0.1:27017/local.test") //統(tǒng)計(jì)結(jié)果輸出到服務(wù)器上 config.set("mongo.output.uri", "mongodb://103.25.23.80:60013/test_hao.result") val mongoRDD = sc.newAPIHadoopRDD(config, classOf[com.mongodb.hadoop.MongoInputFormat], classOf[Object], classOf[BSONObject]) // Input contains tuples of (ObjectId, BSONObject) val countsRDD = mongoRDD.flatMap(arg => { var str = arg._2.get("type").toString str = str.toLowerCase().replaceAll("[.,!?\n]", " ") str.split(" ") }) .map(word => (word, 1)) .reduceByKey((a, b) => a + b) // Output contains tuples of (null, BSONObject) - ObjectId will be generated by Mongo driver if null val saveRDD = countsRDD.map((tuple) => { var bson = new BasicBSONObject() bson.put("word", tuple._1) bson.put("count", tuple._2.toString() ) (null, bson) }) // Only MongoOutputFormat and config are relevant saveRDD.saveAsNewAPIHadoopFile("file:///bogus", classOf[Any], classOf[Any], classOf[com.mongodb.hadoop.MongoOutputFormat[Any, Any]], config)
自問自答。原因可能是這樣：
val mongoRDD = sc.newAPIHadoopRDD(config, classOf[com.mongodb.hadoop.MongoInputFormat], classOf[Object], classOf[BSONObject]) 這行代碼表示這是由driver讀取數(shù)據(jù)庫，然后將符合條件的數(shù)據(jù)載入RDD，由于之前設(shè)置了是將127.0.0.1作為輸入，也就是從driver的mongodb上讀取數(shù)據(jù)。由于driver就在master上，所以讀取的數(shù)據(jù)也自然就是master上的數(shù)據(jù)了。
怎么掌握HA下的Spark集群工作原理？
默認(rèn)情況下，Standalone的Spark集群是Master-Slaves架構(gòu)的集群模式，由一臺master來調(diào)度資源，這就和大部分的Master-Slaves結(jié)構(gòu)集群一樣，存在著Master單點(diǎn)故障的問題。如何解決這個(gè)單點(diǎn)故障的問題呢？Spark提供了兩種方案：基于文件系統(tǒng)的單點(diǎn)恢復(fù)(Single-Node Recovery with Local File system)和基于zookeeper的Standby Masters(Standby Masters with ZooKeeper)。其中ZooKeeper是生產(chǎn)環(huán)境下的最佳選擇。
ZooKeeper提供了一個(gè)Leader Election機(jī)制，利用這個(gè)機(jī)制你可以在集群中開啟多個(gè)master并使它們都注冊到ZooKeeper實(shí)例，ZooKeeper會管理使其中只有一個(gè)是Active的，其他的都是Standby的，Active狀態(tài)的master可以提供服務(wù)，standby狀態(tài)的則不可以。ZooKeeper保存了集群的狀態(tài)信息，該信息包括所有的Worker，Driver 和Application。當(dāng)Active的Master出現(xiàn)故障時(shí)，ZooKeeper會從其他standby的master中選舉出一臺，然后該新選舉出來的master會恢復(fù)掛掉了的master的狀態(tài)信息，之后該Master就可以正常提供調(diào)度服務(wù)。整個(gè)恢復(fù)過程只需要1到2分鐘。需要注意的是，在這1到2分鐘內(nèi)，只會影響新程序的提交，那些在master崩潰時(shí)已經(jīng)運(yùn)行在集群中的程序并不會受影響。
下面我們就實(shí)戰(zhàn)如何配置ZooKeeper下的spark HA。
注：
DT_大數(shù)據(jù)夢工廠（IMF傳奇行動絕密課程）有所有大數(shù)據(jù)實(shí)戰(zhàn)資料
更多私密內(nèi)容，請關(guān)注微信公眾號：DT_Spark
如果您對大數(shù)據(jù)Spark感興趣，可以免費(fèi)聽由王家林老師每天晚上20：00開設(shè)的Spark永久免費(fèi)公開課，地址YY房間號：68917580
spark集群搭建:
https://zhuanlan.zhihu.com/p/20819281
http://www.cnblogs.com/shishanyuan/p/4699644.html
http://www.cnblogs.com/kinglau/p/3794433.html
http://www.cnblogs.com/tec-vegetables/p/3778358.html
http://blog.csdn.net/laoyi_grace/article/details/6254743
http://www.cnblogs.com/tina-smile/p/5045927.html
http://edu.51cto.com/lesson/id-31786.html
沒有hdfs，spark不能集群方式跑是吧？修改
可以讀本地文件，但是只能spark本地模式運(yùn)行計(jì)算這個(gè)從本地讀的數(shù)據(jù)，是吧？修改 一個(gè)計(jì)算服務(wù) HDFS只是輸入的一種 本地文件、隊(duì)列、Netcat 都可以作為輸入 咋就不能跑了另外 區(qū)分下YARN和HDFS YARN也不是必須依賴HDFS的 kafka，redis，mysql，都可以作為數(shù)據(jù)源。只要你能拉到數(shù)，管從哪拉呢？ 可以跑。
配置你每個(gè)節(jié)點(diǎn)上都存一份，或者放在 NFS 里。
數(shù)據(jù)你不從 HDFS 取就行了。? 可以集群方式運(yùn)行。但是要求所有節(jié)點(diǎn)都能用同樣的路徑訪問到數(shù)據(jù)文件。解決方案一是在每個(gè)節(jié)點(diǎn)上的同樣路徑放上同樣的數(shù)據(jù)文件。解決方案二是采用網(wǎng)絡(luò)共享目錄和文件方式。比如linux的nfs方式共享。這兩種方法都比較麻煩，因此，還是用hdfs吧。 spark-standalone模式可以不啟動hdfs跑嗎
可以看看《為什么會有第一代大數(shù)據(jù)Hadoop和第二代大數(shù)據(jù)Spark？》這個(gè)視頻，深刻講解了spark和Hadoop的優(yōu)缺點(diǎn)和hadoop和大數(shù)據(jù)的關(guān)系，觀點(diǎn)一針見血，分析的入木三分 相同的面料，都是基于MapReduce實(shí)現(xiàn)分布式計(jì)算，可能在面料選取（架構(gòu)）或個(gè)別針線活上稍有些技巧性的區(qū)別。 Spark的實(shí)現(xiàn)略不同于Hadoop的是，Job中間輸出和結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫HDFS，因此Spark能更好地適用于數(shù)據(jù)挖掘與機(jī)器學(xué)習(xí)等需要迭代的MapReduce的算法。
要分開存儲和計(jì)算看這問題。
Hadoop中，hdfs已經(jīng)算是大數(shù)據(jù)存儲的標(biāo)配了，mr基本已淘汰（即便用hive都改tez了）。
數(shù)據(jù)分析和挖掘，spark已經(jīng)是趨勢了。
Spark也能支持秒級的流式計(jì)算，但毫秒級的，還得用storm。
Hadoop還有個(gè)組件yarn，做資源管理調(diào)度的，spark可以運(yùn)行在yarn上，也可以獨(dú)立運(yùn)行（還）有種方式是運(yùn)行在mesos上。 最近面試騰訊， 一面和二面都問起了hadoop和spark的區(qū)別和聯(lián)系， 回答的不太好。
應(yīng)用場景： hadoop更擅長于離線批處理
spark更擅長于迭代處理。
但是 hadoop和spark的區(qū)別也在于 前者基于磁盤多次IO， 后者基于內(nèi)存計(jì)算移動計(jì)算而非數(shù)據(jù)。需要注意的是hadoop和spark的Map / Reduce思想 以及其二者的shuffle過程。 我一直沒有講明白shuffle的過程。
Hadoop提供map和reduce算子，而spark提供了大量的transform和action算子，比Hadoop豐富。
提到大數(shù)據(jù)，就不能不提Hadoop和 Spark，那么作為大數(shù)據(jù)領(lǐng)域中的兩座大山，它們到底是什么？各自又有什么魅力呢？
1. Hadoop ，Spark為何物？
Hadoop是http://Apache.org的一個(gè)項(xiàng)目
Spark是一個(gè)運(yùn)算速度快如閃電的Apache項(xiàng)目
一種軟件庫和框架
可跨計(jì)算器集群對龐大數(shù)據(jù)集(大數(shù)據(jù))進(jìn)行分布式處理
大數(shù)據(jù)分析領(lǐng)域的重量級大數(shù)據(jù)平臺
一種用于數(shù)據(jù)大規(guī)模處理的快速通用引擎
處理PB級別數(shù)據(jù)運(yùn)算速度最快的開源工具
它有四個(gè)主要模塊：
1) Hadoop Common
2) Hadoop分布式文件系統(tǒng)(HDFS)
3) Hadoop YARN
4) Hadoop MapReduce
Spark核心組件可以和其他一些高效的軟件庫無縫連接使用
這些軟件庫包括：
SparkSQL
Spark Streming
MLlib(機(jī)器學(xué)習(xí)專用)
GraphX
Spark是一種集群計(jì)算框架，意味著Hadoop vs Spark Spark VS MapReduce
2. Hadoop vs Spark使用難易度
隨帶易于使用的API，支持Scala(原生語言)、Java、Python和Spark SQL。Spark SQL非常類似于SQL 92，且有一種交互模式，可馬上上手。
Hadoop MapReduce沒有交互模式，有Hive和Pig等附加模塊，采用者使用MapReduce更加容易。
Spark因易用性受到追捧
3. Hadoop vs Spark使用成本大比拼
MapReduce和Spark都是Apache項(xiàng)目，是開源免費(fèi)軟件產(chǎn)品
MapReduce使用常規(guī)數(shù)量的內(nèi)存
Spark需要大量內(nèi)存
需要速度更快的磁盤和大量磁盤空間來運(yùn)行MapReduce
需要更多的系統(tǒng)，將磁盤輸入/輸出分布到多個(gè)系統(tǒng)上
使用常規(guī)數(shù)量的常規(guī)轉(zhuǎn)速磁盤
不使用磁盤輸入/輸入用于處理，已使用的磁盤空間可以用于SAN或NAS
Spark系統(tǒng)的成本更高，但技術(shù)減少了數(shù)量，最終結(jié)果是系統(tǒng)成本較高，但是數(shù)量大大減少
4.Hadoop與Spark的特性
? 數(shù)據(jù)處理方式
Hadoop MapReduce使用批量處理
Spark使用內(nèi)存處理
不斷收集來自網(wǎng)站的信息，不需要這些數(shù)據(jù)具有實(shí)時(shí)性或近乎實(shí)時(shí)性
它在內(nèi)存中處理一切數(shù)據(jù)，為來自多個(gè)來源的數(shù)據(jù)提供了近乎實(shí)時(shí)分析的功能
Hadoop MapReduce運(yùn)行順序：集群讀取-執(zhí)行操作-寫回到集群-讀取更新后的數(shù)據(jù)-執(zhí)行下一個(gè)數(shù)據(jù)操作
Spark執(zhí)行類似的操作，不過是在內(nèi)存中一步執(zhí)行：集群讀取-執(zhí)行操作-寫回到集群
? 兼容性
在兼容性一點(diǎn)上，二者互相兼容，MapReduce通過JDBC和ODC兼容諸多數(shù)據(jù)源、文件格式和商業(yè)智能工具，Spark亦是如此。
? 容錯性
MapReduce
Spark
使用TaskTracker節(jié)點(diǎn)，它為 JobTracker節(jié)點(diǎn)提供了心跳(heartbeat)
用彈性分布式數(shù)據(jù)集(RDD)，它們是容錯集合，里面的數(shù)據(jù)元素可執(zhí)行并行操作，使RDD可以引用外部存儲系統(tǒng)中的數(shù)據(jù)集，Spark可以用Hadoop支持的任何存儲源創(chuàng)建RDD ，Spark的緩存也具有容錯性。
? 可擴(kuò)展性
MapReduce和Spark都可以使用HDFS來擴(kuò)展
據(jù)目前所知，最大的Hadoop集群是42000個(gè)節(jié)點(diǎn)，可以說擴(kuò)展無極限
最大的已知Spark集群是8000個(gè)節(jié)點(diǎn)，隨著大數(shù)據(jù)增多，預(yù)計(jì)集群規(guī)模也會隨之變大
? 安全性
Hadoop支持Kerberos身份驗(yàn)證
Spark的安全性弱一點(diǎn)，目前只支持通過共享密鑰(密碼驗(yàn)證)的身份驗(yàn)證
能夠充分利用活動目錄Kerberos和LDAP用于身份驗(yàn)證
在HDFS上運(yùn)行Spark，它可以使用HDFS ACL和文件級權(quán)限
Hadoop分布式文件系統(tǒng)支持訪問控制列表(ACL)和傳統(tǒng)的文件權(quán)限模式，確保用戶擁有正確的權(quán)限
Spark可以在YARN上運(yùn)行，因而能夠使用Kerberos身份驗(yàn)證
事實(shí)上，Hadoop vs Spark并沒有真正的孰優(yōu)孰劣，它們不是你死我活的關(guān)系，而是一種相互共生的關(guān)系，Spark幫助人們簡化了處理大規(guī)模數(shù)據(jù)的步驟流程，而Hadoop又提供了Spark所沒有的功能特性，可以說二者只有相輔相成，互利共生，才能夠?yàn)槠髽I(yè)、為團(tuán)隊(duì)提供更為有效的數(shù)據(jù)分析，為決策者提供更為有效的建議。
關(guān)于大數(shù)據(jù)的“大”，我想糾正一下大家的看法。
大數(shù)據(jù)不僅僅是大，它Bigger than big。如果是“大”，那么，多大才是大？PB？TB？
大數(shù)據(jù)的關(guān)鍵特性在于，區(qū)別于傳統(tǒng)的統(tǒng)計(jì)學(xué)，它處理的對象是數(shù)據(jù)的整體，而不是“樣本”。傳統(tǒng)的統(tǒng)計(jì)學(xué)，都是根據(jù)樣本來推測整體，免不了偏差——所以它有個(gè)概念叫做“顯著”（Confidence），告訴你，我針對樣本得出的結(jié)論，有多大把握對整體也是真的。
之所以會這樣，因?yàn)檫^去計(jì)算機(jī)科學(xué)不發(fā)達(dá)，數(shù)據(jù)的采集和計(jì)算都是大問題，只能抽樣。
現(xiàn)在不同了，數(shù)據(jù)的采集，存儲，計(jì)算都不是問題，為什么還要抽樣呢？因此，誕生了大數(shù)據(jù)概念，直接處理數(shù)據(jù)整體，而不是抽樣。
有了上述鋪墊，再舉個(gè)栗子。如果回答PB是大，OK，10PB算大了吧？是不是大數(shù)據(jù)？是。OK，那我告訴你，這10PB來自阿里，但只是其已處理數(shù)據(jù)量的1/10。那么，現(xiàn)在它還是不是大數(shù)據(jù)？
對比一下，一個(gè)中小型網(wǎng)站，每天只有10G的數(shù)據(jù)，是不是大數(shù)據(jù)？可能不是？OK，但這已經(jīng)是他全部的數(shù)據(jù)量了。
大數(shù)據(jù)這個(gè)概念很寬泛，就類似于什么PC時(shí)代、互聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)再到現(xiàn)在的大數(shù)據(jù)時(shí)代，一種技術(shù)不斷發(fā)展的時(shí)代浪潮而已，定義有很多，我認(rèn)為可以這樣定義：以數(shù)據(jù)為中心更加精準(zhǔn)的服務(wù)。你能想象到很多例子，如果不知道的話可以看《大數(shù)據(jù)時(shí)代》這本書。
而Hadoop、Spark都是處理大數(shù)據(jù)的一種技術(shù)手段，Spark由于是在內(nèi)存中計(jì)算，速度要更快一些。還有很多其它處理大數(shù)據(jù)的方式，技術(shù)沒有最好只有最合適的。
1. 大數(shù)據(jù)，數(shù)據(jù)量至少在TB級別。
2. Hadoop是大數(shù)據(jù)處理的開源軟件，也是使用最廣的。
3. Hadoop的計(jì)算過程，大量使用磁盤存儲。Spark的計(jì)算，大量使用內(nèi)存存儲，所以Spark塊。兩者并行。
4. spark支持從Hadoop的hdfs做數(shù)據(jù)輸入輸出。
5. Hadoop 2.x支持Spark作為一個(gè)組件。
Hadoop是一個(gè)基礎(chǔ)平臺，存儲有HDFS、資源調(diào)度有YARN、計(jì)算引擎有內(nèi)置的MapReduce（跑在YARN上），Hadoop的HDFS、YARN是大數(shù)據(jù)系統(tǒng)的底層組件。
對于Spark，我從以下角度理解：
1. 是一種內(nèi)存計(jì)算引擎，與MR是競爭關(guān)系，但效率比MR高。
2. 需要外部的資源調(diào)度系統(tǒng)來支持，可以跑在YARN上，也可以跑在Mesos上，當(dāng)然可以用Standalone模式。
3. Spark核心計(jì)算引擎外圍有若干數(shù)據(jù)分析組件，Spark SQL（SQL接口）、Spark Streaming（流計(jì)算）、MLlib（機(jī)器學(xué)習(xí)）、GraphX（圖計(jì)算），“One Stack to rule them all”。
總體來說，Spark是跑在Hadoop上（依賴YARN和HDFS）的內(nèi)存計(jì)算引擎，內(nèi)置多種豐富組件，可以處理數(shù)據(jù)分析各個(gè)領(lǐng)域的問題。
大數(shù)據(jù)（Big Data）
大數(shù)據(jù)，官方定義是指那些數(shù)據(jù)量特別大、數(shù)據(jù)類別特別復(fù)雜的數(shù)據(jù)集，這種數(shù)據(jù)集無法用傳統(tǒng)的數(shù)據(jù)庫進(jìn)行存儲，管理和處理。大數(shù)據(jù)的主要特點(diǎn)為數(shù)據(jù)量大（Volume），數(shù)據(jù)類別復(fù)雜（Variety），數(shù)據(jù)處理速度快（Velocity）和數(shù)據(jù)真實(shí)性高（Veracity），合起來被稱為4V。
大數(shù)據(jù)中的數(shù)據(jù)量非常巨大，達(dá)到了PB級別。而且這龐大的數(shù)據(jù)之中，不僅僅包括結(jié)構(gòu)化數(shù)據(jù)（如數(shù)字、符號等數(shù)據(jù)），還包括非結(jié)構(gòu)化數(shù)據(jù)（如文本、圖像、聲音、視頻等數(shù)據(jù)）。這使得大數(shù)據(jù)的存儲，管理和處理很難利用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫去完成。在大數(shù)據(jù)之中，有價(jià)值的信息往往深藏其中。這就需要對大數(shù)據(jù)的處理速度要非常快，才能短時(shí)間之內(nèi)就能從大量的復(fù)雜數(shù)據(jù)之中獲取到有價(jià)值的信息。在大數(shù)據(jù)的大量復(fù)雜的數(shù)據(jù)之中，通常不僅僅包含真實(shí)的數(shù)據(jù)，一些虛假的數(shù)據(jù)也混雜其中。這就需要在大數(shù)據(jù)的處理中將虛假的數(shù)據(jù)剔除，利用真實(shí)的數(shù)據(jù)來分析得出真實(shí)的結(jié)果。
大數(shù)據(jù)分析（Big Data Analysis）
大數(shù)據(jù)，表面上看就是大量復(fù)雜的數(shù)據(jù)，這些數(shù)據(jù)本身的價(jià)值并不高，但是對這些大量復(fù)雜的數(shù)據(jù)進(jìn)行分析處理后，卻能從中提煉出很有價(jià)值的信息。對大數(shù)據(jù)的分析，主要分為五個(gè)方面：可視化分析（Analytic Visualization）、數(shù)據(jù)挖掘算法（Date Mining Algorithms）、預(yù)測性分析能力（Predictive Analytic Capabilities）、語義引擎（Semantic Engines）和數(shù)據(jù)質(zhì)量管理（Data Quality Management）。
可視化分析是普通消費(fèi)者常常可以見到的一種大數(shù)據(jù)分析結(jié)果的表現(xiàn)形式，比如說百度制作的“百度地圖春節(jié)人口遷徙大數(shù)據(jù)”就是典型的案例之一。可視化分析將大量復(fù)雜的數(shù)據(jù)自動轉(zhuǎn)化成直觀形象的圖表，使其能夠更加容易的被普通消費(fèi)者所接受和理解。
數(shù)據(jù)挖掘算法是大數(shù)據(jù)分析的理論核心，其本質(zhì)是一組根據(jù)算法事先定義好的數(shù)學(xué)公式，將收集到的數(shù)據(jù)作為參數(shù)變量帶入其中，從而能夠從大量復(fù)雜的數(shù)據(jù)中提取到有價(jià)值的信息。著名的“啤酒和尿布”的故事就是數(shù)據(jù)挖掘算法的經(jīng)典案例。沃爾瑪通過對啤酒和尿布購買數(shù)據(jù)的分析，挖掘出以前未知的兩者間的聯(lián)系，并利用這種聯(lián)系，提升了商品的銷量。亞馬遜的推薦引擎和谷歌的廣告系統(tǒng)都大量使用了數(shù)據(jù)挖掘算法。
預(yù)測性分析能力是大數(shù)據(jù)分析最重要的應(yīng)用領(lǐng)域。從大量復(fù)雜的數(shù)據(jù)中挖掘出規(guī)律，建立起科學(xué)的事件模型，通過將新的數(shù)據(jù)帶入模型，就可以預(yù)測未來的事件走向。預(yù)測性分析能力常常被應(yīng)用在金融分析和科學(xué)研究領(lǐng)域，用于股票預(yù)測或氣象預(yù)測等。
語義引擎是機(jī)器學(xué)習(xí)的成果之一。過去，計(jì)算機(jī)對用戶輸入內(nèi)容的理解僅僅停留在字符階段，不能很好的理解輸入內(nèi)容的意思，因此常常不能準(zhǔn)確的了解用戶的需求。通過對大量復(fù)雜的數(shù)據(jù)進(jìn)行分析，讓計(jì)算機(jī)從中自我學(xué)習(xí)，可以使計(jì)算機(jī)能夠盡量精確的了解用戶輸入內(nèi)容的意思，從而把握住用戶的需求，提供更好的用戶體驗(yàn)。蘋果的Siri和谷歌的Google Now都采用了語義引擎。
數(shù)據(jù)質(zhì)量管理是大數(shù)據(jù)在企業(yè)領(lǐng)域的重要應(yīng)用。為了保證大數(shù)據(jù)分析結(jié)果的準(zhǔn)確性，需要將大數(shù)據(jù)中不真實(shí)的數(shù)據(jù)剔除掉，保留最準(zhǔn)確的數(shù)據(jù)。這就需要建立有效的數(shù)據(jù)質(zhì)量管理系統(tǒng)，分析收集到的大量復(fù)雜的數(shù)據(jù)，挑選出真實(shí)有效的數(shù)據(jù)。
分布式計(jì)算（Distributed Computing）
對于如何處理大數(shù)據(jù)，計(jì)算機(jī)科學(xué)界有兩大方向：第一個(gè)方向是集中式計(jì)算，就是通過不斷增加處理器的數(shù)量來增強(qiáng)單個(gè)計(jì)算機(jī)的計(jì)算能力，從而提高處理數(shù)據(jù)的速度。第二個(gè)方向是分布式計(jì)算，就是把一組計(jì)算機(jī)通過網(wǎng)絡(luò)相互連接組成分散系統(tǒng)，然后將需要處理的大量數(shù)據(jù)分散成多個(gè)部分，交由分散系統(tǒng)內(nèi)的計(jì)算機(jī)組同時(shí)計(jì)算，最后將這些計(jì)算結(jié)果合并得到最終的結(jié)果。盡管分散系統(tǒng)內(nèi)的單個(gè)計(jì)算機(jī)的計(jì)算能力不強(qiáng)，但是由于每個(gè)計(jì)算機(jī)只計(jì)算一部分?jǐn)?shù)據(jù)，而且是多臺計(jì)算機(jī)同時(shí)計(jì)算，所以就分散系統(tǒng)而言，處理數(shù)據(jù)的速度會遠(yuǎn)高于單個(gè)計(jì)算機(jī)。
過去，分布式計(jì)算理論比較復(fù)雜，技術(shù)實(shí)現(xiàn)比較困難，因此在處理大數(shù)據(jù)方面，集中式計(jì)算一直是主流解決方案。IBM的大型機(jī)就是集中式計(jì)算的典型硬件，很多銀行和政府機(jī)構(gòu)都用它處理大數(shù)據(jù)。不過，對于當(dāng)時(shí)的互聯(lián)網(wǎng)公司來說，IBM的大型機(jī)的價(jià)格過于昂貴。因此，互聯(lián)網(wǎng)公司的把研究方向放在了可以使用在廉價(jià)計(jì)算機(jī)上的分布式計(jì)算上。
服務(wù)器集群（Server Cluster）
服務(wù)器集群是一種提升服務(wù)器整體計(jì)算能力的解決方案。它是由互相連接在一起的服務(wù)器群所組成的一個(gè)并行式或分布式系統(tǒng)。服務(wù)器集群中的服務(wù)器運(yùn)行同一個(gè)計(jì)算任務(wù)。因此，從外部看，這群服務(wù)器表現(xiàn)為一臺虛擬的服務(wù)器，對外提供統(tǒng)一的服務(wù)。
盡管單臺服務(wù)器的運(yùn)算能力有限，但是將成百上千的服務(wù)器組成服務(wù)器集群后，整個(gè)系統(tǒng)就具備了強(qiáng)大的運(yùn)算能力，可以支持大數(shù)據(jù)分析的運(yùn)算負(fù)荷。Google，Amazon，阿里巴巴的計(jì)算中心里的服務(wù)器集群都達(dá)到了5000臺服務(wù)器的規(guī)模。
大數(shù)據(jù)的技術(shù)基礎(chǔ)：MapReduce、Google File System和BigTable
2003年到2004年間，Google發(fā)表了MapReduce、GFS（Google File System）和BigTable三篇技術(shù)論文，提出了一套全新的分布式計(jì)算理論。
MapReduce是分布式計(jì)算框架，GFS（Google File System）是分布式文件系統(tǒng)，BigTable是基于Google File System的數(shù)據(jù)存儲系統(tǒng)，這三大組件組成了Google的分布式計(jì)算模型。
Google的分布式計(jì)算模型相比于傳統(tǒng)的分布式計(jì)算模型有三大優(yōu)勢：首先，它簡化了傳統(tǒng)的分布式計(jì)算理論，降低了技術(shù)實(shí)現(xiàn)的難度，可以進(jìn)行實(shí)際的應(yīng)用。其次，它可以應(yīng)用在廉價(jià)的計(jì)算設(shè)備上，只需增加計(jì)算設(shè)備的數(shù)量就可以提升整體的計(jì)算能力，應(yīng)用成本十分低廉。最后，它被Google應(yīng)用在Google的計(jì)算中心，取得了很好的效果，有了實(shí)際應(yīng)用的證明。
后來，各家互聯(lián)網(wǎng)公司開始利用Google的分布式計(jì)算模型搭建自己的分布式計(jì)算系統(tǒng)，Google的這三篇論文也就成為了大數(shù)據(jù)時(shí)代的技術(shù)核心。
主流的三大分布式計(jì)算系統(tǒng)：Hadoop，Spark和Storm
由于Google沒有開源Google分布式計(jì)算模型的技術(shù)實(shí)現(xiàn)，所以其他互聯(lián)網(wǎng)公司只能根據(jù)Google三篇技術(shù)論文中的相關(guān)原理，搭建自己的分布式計(jì)算系統(tǒng)。
Yahoo的工程師Doug Cutting和Mike Cafarella在2005年合作開發(fā)了分布式計(jì)算系統(tǒng)Hadoop。后來，Hadoop被貢獻(xiàn)給了Apache基金會，成為了Apache基金會的開源項(xiàng)目。Doug Cutting也成為Apache基金會的主席，主持Hadoop的開發(fā)工作。
Hadoop采用MapReduce分布式計(jì)算框架，并根據(jù)GFS開發(fā)了HDFS分布式文件系統(tǒng)，根據(jù)BigTable開發(fā)了HBase數(shù)據(jù)存儲系統(tǒng)。盡管和Google內(nèi)部使用的分布式計(jì)算系統(tǒng)原理相同，但是Hadoop在運(yùn)算速度上依然達(dá)不到Google論文中的標(biāo)準(zhǔn)。
不過，Hadoop的開源特性使其成為分布式計(jì)算系統(tǒng)的事實(shí)上的國際標(biāo)準(zhǔn)。Yahoo，Facebook，Amazon以及國內(nèi)的百度，阿里巴巴等眾多互聯(lián)網(wǎng)公司都以Hadoop為基礎(chǔ)搭建自己的分布式計(jì)算系統(tǒng)。
Spark也是Apache基金會的開源項(xiàng)目，它由加州大學(xué)伯克利分校的實(shí)驗(yàn)室開發(fā)，是另外一種重要的分布式計(jì)算系統(tǒng)。它在Hadoop的基礎(chǔ)上進(jìn)行了一些架構(gòu)上的改良。Spark與Hadoop最大的不同點(diǎn)在于，Hadoop使用硬盤來存儲數(shù)據(jù)，而Spark使用內(nèi)存來存儲數(shù)據(jù)，因此Spark可以提供超過Hadoop100倍的運(yùn)算速度。但是，由于內(nèi)存斷電后會丟失數(shù)據(jù)，Spark不能用于處理需要長期保存的數(shù)據(jù)。
Storm是Twitter主推的分布式計(jì)算系統(tǒng)，它由BackType團(tuán)隊(duì)開發(fā)，是Apache基金會的孵化項(xiàng)目。它在Hadoop的基礎(chǔ)上提供了實(shí)時(shí)運(yùn)算的特性，可以實(shí)時(shí)的處理大數(shù)據(jù)流。不同于Hadoop和Spark，Storm不進(jìn)行數(shù)據(jù)的收集和存儲工作，它直接通過網(wǎng)絡(luò)實(shí)時(shí)的接受數(shù)據(jù)并且實(shí)時(shí)的處理數(shù)據(jù)，然后直接通過網(wǎng)絡(luò)實(shí)時(shí)的傳回結(jié)果。
Hadoop，Spark和Storm是目前最重要的三大分布式計(jì)算系統(tǒng)，Hadoop常用于離線的復(fù)雜的大數(shù)據(jù)處理，Spark常用于離線的快速的大數(shù)據(jù)處理，而Storm常用于在線的實(shí)時(shí)的大數(shù)據(jù)處理。 hadoop側(cè)重離線的批處理 而在應(yīng)付流計(jì)算和迭代計(jì)算上略顯不足，因?yàn)閔adoop的每次運(yùn)算結(jié)果都要寫入文件系統(tǒng)，下次計(jì)算重新從文件系統(tǒng)讀進(jìn)來，這就造成很大的IO開銷，
spark采用RDD的分布式內(nèi)存抽象，是一棧的大數(shù)據(jù)解決方案，包括spark core、spark streaming、spark sql、mllib，目的是不是補(bǔ)充hadoop 而是取而代之
還有一個(gè)比較關(guān)注的是spark的數(shù)據(jù)庫，一個(gè)基于采樣的數(shù)據(jù)庫，可以在精度和效率上面權(quán)衡
轉(zhuǎn)一下馬鐵教授本人的回答：
Matei Zaharia's answer to Will Apache Spark ever overtake Apache Hadoop?
我自己的答案：
- MapReduce是和Spark并行的概念，兩者都是計(jì)算引擎。兩者的比較可以參見 Reynold Xin's answer to When is Hadoop MapReduce better than Spark? 。我傾向于這樣總結(jié)：Spark通過lineage這個(gè)核心思想實(shí)現(xiàn)了基于內(nèi)存的輕量的容錯機(jī)制，取代了MR保守的硬盤數(shù)據(jù)冗余。
- Apache Hadoop系統(tǒng)其實(shí)就像一個(gè)操作系統(tǒng)。主要包含HDFS －相當(dāng)于Linux下面的ext3,ext4，和Yarn － 相當(dāng)于Linux下面的進(jìn)程調(diào)度和內(nèi)存分配模塊。
- Hadoop生態(tài)圈包括Apache Hadoop以及更上層的應(yīng)用。在Spark／MapReduce這一層計(jì)算引擎上面，還可以加Hive來做SQL，各種流處理應(yīng)用，等等。比如Hive就有on MapReduce和on Spark兩個(gè)版本。
- Spark不完全屬于Hadoop生態(tài)圈，它也可以脫離Apache Hadoop。比如用紅帽的Gluster FS做文件系統(tǒng)，Mesos做調(diào)度。但是從現(xiàn)在的情況來看它主要還是一個(gè)Hadoop應(yīng)用。比如最近打破TeraSort紀(jì)錄（Spark officially sets a new record in large-scale sorting）就是基于HDFS做的。
- 大數(shù)據(jù)這個(gè)概念就模糊多了。但我覺得最起碼可以很安全的說 大部分的大數(shù)據(jù)應(yīng)用運(yùn)行在Hadoop生態(tài)圈里。
有什么關(guān)于 Spark 的書推薦？
Fei Dong | LinkedIn
Hadoop Spark學(xué)習(xí)小結(jié)[2014版]Hadoop
Hadoop社區(qū)依然發(fā)展迅速，2014年推出了2.3，2.4, 2.5 的社區(qū)版本，比如增強(qiáng) Resource Manager HA, YARN Rest API, ACL on HDFS, 改進(jìn) HDFS 的 Web UI…
Hadoop Roadmap 根據(jù)我的觀察，主要更新在Yarn，HDFS，而Mapreduce幾乎停滯了，還有一些feature 屬于安全，穩(wěn)定可靠性一方面是比較穩(wěn)定了，但也可以說是瓶頸了。
Apache Hadoop Project Members
這個(gè)是Hadoop project member and committee, 里面好多來自Hortonworks，也有不少國人上榜。
SparkSpark 介紹Spark今年大放溢彩，Spark簡單說就是內(nèi)存計(jì)算（包含迭代式計(jì)算，DAG計(jì)算,流式計(jì)算 ）框架，之前MapReduce因效率低下大家經(jīng)常嘲笑，而Spark的出現(xiàn)讓大家很清新。
-
Reynod 作為Spark核心開發(fā)者, 介紹Spark性能超Hadoop百倍，算法實(shí)現(xiàn)僅有其1/10或1/100
-
淺談Apache Spark的6個(gè)發(fā)光點(diǎn)
-
Spark: Open Source Superstar Rewrites Future of Big Data
-
Spark is a really big deal for big data, and Cloudera gets it
其實(shí)起名字也很重要，Spark就占了先機(jī)，CTO說Where There’s Spark There’s Fire: The State of Apache Spark in 2014
Spark 起源2010年Berkeley AMPLab，發(fā)表在hotcloud 是一個(gè)從學(xué)術(shù)界到工業(yè)界的成功典范，也吸引了頂級VC：Andreessen Horowitz的 注資
AMPLab這個(gè)實(shí)驗(yàn)室非常厲害，做大數(shù)據(jù)，云計(jì)算，跟工業(yè)界結(jié)合很緊密，之前就是他們做mesos，hadoop online, crowddb, Twitter，Linkedin等很多知名公司都喜歡從Berkeley找人，比如Twitter也專門開了門課程 Analyzing Big Data with Twitter 還有個(gè)BDAS (Bad Ass)引以為傲: The lab that created Spark wants to speed up everything, including cures for cancer
在2013年，這些大牛從Berkeley AMPLab出去成立了Databricks，半年就做了2次summit參會1000人，引無數(shù)Hadoop大佬盡折腰，大家看一下Summit的sponsor ，所有hadoop廠商全來了，并且各個(gè)技術(shù)公司也在巴結(jié)，cloudrea, hortonworks, mapr, datastax, yahoo, ooyala, 根據(jù)CTO說 Spark新增代碼量活躍度今年遠(yuǎn)遠(yuǎn)超過了Hadoop本身，要推出商業(yè)化產(chǎn)品Cloud。
Spark人物- Ion Stoica: Berkeley教授，AMPLab 領(lǐng)軍
- Matei Zaharia: 天才，MIT助理教授
- Reynold Xin Apache Spark開源社區(qū)的主導(dǎo)人物之一。他在UC Berkeley AMPLab進(jìn)行博士學(xué)業(yè)期間參與了Spark的開發(fā)，并在Spark之上編寫了Shark和GraphX兩個(gè)開源框架。他和AMPLab同僚共同創(chuàng)建了Databricks公司
- Andy Konwinski
- Haoyuan Li
- Patrick Wendell
- Xiangrui Meng
- Paco Nathan
- Lian Cheng
- Hossein Falaki
- Mosharaf Chowdhury
- Zongheng Yang
- Yin Huai
- Committers
目前還有一些子項(xiàng)目，比如 Spark SQL, Spark Streaming, MLLib, Graphx 工業(yè)界也引起廣泛興趣，國內(nèi)Taobao, baidu也開始使用：Powered by Spark
Apache Spark支持4種分布式部署方式，分別是Amazon EC2, standalone、spark on mesos和 spark on YARN 比如AWS
Spark Summit-
2014 Summit
-
取代而非補(bǔ)充，Spark Summit 2014精彩回顧
-
擁抱Spark，機(jī)遇無限——Spark Summit 2013精彩回顧
-
Databricks Cloud Demo 今年最叫好的demo是Dtabricks Cloud, 把Twitter上面實(shí)時(shí)收集的數(shù)據(jù)做作為machine learning素材，用類似IPython notebook，可視化呈現(xiàn)驚艷，而搭建整個(gè)sampling系統(tǒng)就花了20分鐘！
-
官方文檔
-
Databricks Blog
-
Summit Training
-
Databricks upcoming training
-
Stanford Spark Class
-
CSDN Spark專欄
10月份還有個(gè)培訓(xùn)在灣區(qū)的培訓(xùn)，只不過3天就要1500刀，看來做個(gè)講師也不錯:)
第三方項(xiàng)目- Web interactive UI on Hadoop/Spark
- Spark on cassandra
- Spark Cassandra Connector
- Calliope
- H2O + Spark
- Shark - Hive and SQL on top of Spark
- MLbase - Machine Learning research project on top of Spark
- BlinkDB - a massively parallel, approximate query engine built on top of Shark and Spark
- GraphX - a graph processing & analytics framework on top of Spark (GraphX has been merged into Spark 0.9)
- Apache Mesos - Cluster management system that supports running Spark
- Tachyon - In memory storage system that supports running Spark
- Apache MRQL - A query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop, Hama, and Spark
- OpenDL - A deep learning algorithm library based on Spark framework. Just kick off.
- SparkR - R frontend for Spark
- Spark Job Server - REST interface for managing and submitting Spark jobs on the same cluster.
-
Resilient Distributed Datasets
-
spark on yarn的技術(shù)挑戰(zhàn)
-
Hive原理與不足
-
Impala/Hive現(xiàn)狀分析與前景展望
-
Apache Hadoop: How does Impala compare to Shark
-
MapReduce：一個(gè)巨大的倒退
-
Google Dremel 原理 — 如何能3秒分析1PB
-
Isn’t Cloudera Impala doing the same job as Apache Drill incubator project?
-
Shark
-
Big Data Benchmark
-
How does Impala compare to Shark
-
EMC講解Hawq SQL性能：左手Hive右手Impala
-
Shark, Spark SQL, Hive on Spark, and the future of SQL on Spark
-
Cloudera: Impala’s it for interactive SQL on Hadoop; everything else will move to Spark
-
Databricks – an interesting plan for Spark, Shark, and Spark SQL
-
Apache Storm vs Spark Streaming
-
Apache Spark源碼走讀
加州大學(xué)伯克利分校提出的mesos有哪些優(yōu)缺點(diǎn)？ 作者：Weitao Zhou
鏈接：https://www.zhihu.com/question/20043233/answer/52708295
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
Docker Swarm與Apache Mesos的區(qū)別
summary:
Docker Swarm 是目前 Docker 社區(qū)原生支持的集群工具，它通過擴(kuò)展 Docker API 力圖讓用戶像使用單機(jī) Docker API 一樣來驅(qū)動整個(gè)集群；而 Mesos 是 Apache 基金會下的集群資源管理工具，它通過抽象主機(jī)的 CPU、內(nèi)存、存儲等計(jì)算資源來搭建一套高效、容錯、彈性的分布式系統(tǒng)。
顯然，這兩者功能上有交集，網(wǎng)絡(luò)上也有很多關(guān)于 Docker Swarm, Mesos 和 Kubernetes 之間區(qū)別的討論，作為一個(gè) Mesos 重度用戶，最近也抽時(shí)間把玩了下 Docker Swarm。一路下來，Docker Swarm 給我的感覺首先是它特別簡單、靈活，相較于 Mesos 而言， Docker Swarm 對集群的侵入性更小，從而資源損耗也更低；其次，我特別想強(qiáng)調(diào)的是目前看來，雖然它與 Mesos 之間功能有重疊，但是兩者關(guān)注在不同的東西上了，所以拿這兩者作比較沒有多大意義。當(dāng)然，未來這種情況可能會發(fā)生變化，這取決于社區(qū)的 roadmap 。下面我會從多個(gè)角度把 Docker Swarm 和 Mesos 進(jìn)行比較。
============================我是分割線======================
Docker大火，我們公司也在使用Docker+Mesos，給出些自己的看法。
歷史
先八卦一下Mesos的歷史，其實(shí)Mesos并不是為Docker而生的，它產(chǎn)生的初衷是為spark做集群管理。而且，Mesos有自己的容器隔離，后來，隨著Docker的崛起，Mesos就開始支持Docker容器了。再后來，google一哥們兒發(fā)了篇paper，對比google內(nèi)部的borg(Omega?)，Mesos和Yarn（是不是Yarn）三個(gè)集群管理工具的性能，大致結(jié)論就是Mesos跟google內(nèi)部的集群管理工具有異曲同工之妙。有了Docker助力，再加上google的paper，大家就開始去嘗試Mesos了。據(jù)我在網(wǎng)上搜羅的消息，國外的twitter，apple（用Mesos管理siri的集群），uber（uber的開發(fā)在Mesos的mail-list說他們已經(jīng)使用Mesos有一段時(shí)間了，同時(shí)準(zhǔn)備把更多的東西遷到Mesos集群上），國內(nèi)的愛奇藝（視頻轉(zhuǎn)碼），數(shù)人科技（敝公司）都已經(jīng)或正在使用Mesos集群。
優(yōu)點(diǎn)
R 如何解決R在大樣本回歸中，內(nèi)存不足問題？ 原因（據(jù)我的了解，可能有誤，但八九不離十）：任何數(shù)據(jù)類型在R中都和雙精度等價(jià)的。比如說你想保存一個(gè)boolean，但其實(shí)占用的內(nèi)存和double是一樣的。其次R是copy by memory。如果matrix A用了1G內(nèi)存，那么B=A就會占用2G內(nèi)存。（這個(gè)問題我在使用parralel 作fork并行的時(shí)候尤為明顯。不知為何如果一個(gè)函數(shù)引用一個(gè)變量，會把那個(gè)變量在內(nèi)存中復(fù)制一邊。最后我的解決方法是用了很多全局變量，然后函數(shù)不申明引用那個(gè)變量，在運(yùn)算的時(shí)候直接調(diào)用。這樣做很危險(xiǎn)，很難debug~）
解決方案：用C，python，（julia？）
他們都是copy by reference。 B=A后內(nèi)存只會多一個(gè)指針。而且他們對內(nèi)存有更精確的控制，作并行運(yùn)算的時(shí)候可以共享主要的數(shù)據(jù)。甚至你可以用或者自己實(shí)現(xiàn)運(yùn)算不一定那么快但是需要內(nèi)存少的算法。
偷懶的辦法：既然是大樣本，假設(shè)你的sample size 很大。那么可以取一個(gè)subsample（隨機(jī)取一個(gè)子集，能放進(jìn)內(nèi)存就好）。 子集的結(jié)果和全部大樣本的結(jié)果應(yīng)該差別不大。因?yàn)榛貧w的收斂速度還是挺快的么：）。 可不可以順便問下，有沒有什么可以auto variables selection的同時(shí)做time series的r package？ 如果你，必須用R不能用別的語言，也不能用什么高大上的H2O或者spark，還不能升級硬件，那么你可以借助一下bootstrap這種奇技淫巧：
1. 隨機(jī)采樣200次，每一次采樣20%的數(shù)據(jù)（當(dāng)然200次和20%是我隨便說的，你自己看情況定）
2. 給每個(gè)小樣本作回歸，這樣你有200組參數(shù)
3. 取這200組參數(shù)的中位數(shù)作為解
如果你，必須用R不能用別的語言，也不能用什么高大上的H2O或者spark，還不能升級硬件，那么你可以借助一下bootstrap這種奇技淫巧：
1. 隨機(jī)采樣200次，每一次采樣20%的數(shù)據(jù)（當(dāng)然200次和20%是我隨便說的，你自己看情況定）
2. 給每個(gè)小樣本作回歸，這樣你有200組參數(shù)
3. 取這200組參數(shù)的中位數(shù)作為解
CRAN - Package bigmemory
Michael Kane on Bigmemory
這個(gè)作者的一系列包，可以用shared memory來解決大數(shù)據(jù)集在R中的存儲分析問題。當(dāng)然SparkR在服務(wù)器上也是解決方法，但是應(yīng)該對于單機(jī)個(gè)人用戶big系列包應(yīng)該是一個(gè)很好的解決方案。
同時(shí)請參考CRAN上的task view
CRAN Task View: High-Performance and Parallel Computing with R
中的Large memory and out-of-memory data一節(jié)，其中介紹了很多關(guān)于大數(shù)據(jù)集分析方法工具的軟件包。
插一張超大的閃存, 調(diào)成虛擬內(nèi)存來用
超超超大的樣本, 就在aws雲(yún)端開個(gè)Spark集群, 用SparkR, 賦予每個(gè)橫列(row)一個(gè)隨機(jī)數(shù)後grouping可以實(shí)現(xiàn)抽樣出數(shù)個(gè)子集, 把要用的模型套到MapReduce, 看不同子集所擬合的參數(shù)分佈
SparkR (R on Spark)
換其他編程語言的方案已經(jīng)有人提了
我給你個(gè)實(shí)際可行的方法就是，
租用Google或者Amazon的計(jì)算平臺，對于新用戶都有免費(fèi)。比如我用Google，可以建一個(gè)虛擬機(jī)，用200G內(nèi)存，總該滿足你需求了。
當(dāng)然，這是短期的，如果經(jīng)常要處理大規(guī)模數(shù)據(jù)，確實(shí)R并不是很合適。 基于spark的深度學(xué)習(xí)怎么實(shí)現(xiàn)，具體應(yīng)用實(shí)例？ Spark 貌似不支持直接支持 深度學(xué)習(xí)吧，你可以通過 deeplearning4j與Spark整合來支持。你也可以參考這個(gè)：https://github.com/sunbow1/SparkMLlibDeepLearn
Apache Spark項(xiàng)目于2009年誕生于伯克利大學(xué)的AMPLab實(shí)驗(yàn)室，當(dāng)初的目的在于將內(nèi)存內(nèi)分析機(jī)制引入大規(guī)模數(shù)據(jù)集當(dāng)中。在那個(gè)時(shí)候，Hadoop MapReduce的關(guān)注重點(diǎn)仍然放在那些本質(zhì)上無法迭代的大規(guī)模數(shù)據(jù)管道身上。想在2009年以MapReduce為基礎(chǔ)構(gòu)建起分析模型實(shí)在是件費(fèi)心費(fèi)力而又進(jìn)展緩慢的工作，因此AMPLab設(shè)計(jì)出Spark來幫助開發(fā)人員對大規(guī)模數(shù)據(jù)集執(zhí)行交互分析、從而運(yùn)行各類迭代工作負(fù)載——也就是對內(nèi)存中的同一套或者多套數(shù)據(jù)集進(jìn)行反復(fù)處理，其中最典型的就是機(jī)器學(xué)習(xí)算法。
Spark的意義并不在于取代Hadoop。正相反，它為那些高度迭代的工作負(fù)載提供了一套備用處理引擎。通過顯著降低面向磁盤的寫入強(qiáng)度，Spark任務(wù)通常能夠在運(yùn)行速度方面高出Hadoop MapReduce幾個(gè)數(shù)量級。作為“寄生”在Hadoop集群當(dāng)中的得力助手，Spark利用Hadoop數(shù)據(jù)層（HDFS、HBase等等）作為數(shù)據(jù)管道終端，從而實(shí)現(xiàn)原始數(shù)據(jù)讀取以及最終結(jié)果存儲。
編寫Spark應(yīng)用程序
作為由Scala語言編寫的項(xiàng)目，Spark能夠?yàn)閿?shù)據(jù)處理流程提供一套統(tǒng)一化抽象層，這使其成為開發(fā)數(shù)據(jù)應(yīng)用程序的絕佳環(huán)境。Spark在大多數(shù)情況下允許開發(fā)人員選擇Scala、Java以及Python語言用于應(yīng)用程序構(gòu)建，當(dāng)然對于那些最為前沿的層面、只有Scala能夠?qū)崿F(xiàn)大家的一切構(gòu)想。
Spark當(dāng)中的突出特性之一在于利用Scala或者Python控制臺進(jìn)行交互式工作。這意味著大家可以在嘗試代碼運(yùn)行時(shí)，立即查看到其實(shí)際執(zhí)行結(jié)果。這一特性非常適合調(diào)試工作——大家能夠在無需進(jìn)行編譯的前提下變更其中的數(shù)值并再次處理——以及數(shù)據(jù)探索——這是一套典型的處理流程，由大量檢查-顯示-更新要素所構(gòu)成。
Spark的核心數(shù)據(jù)結(jié)構(gòu)是一套彈性分布式數(shù)據(jù)（簡稱RDD）集。在Spark當(dāng)中，驅(qū)動程序被編寫為一系列RDD轉(zhuǎn)換機(jī)制，并附帶與之相關(guān)的操作環(huán)節(jié)。顧名思義，所謂轉(zhuǎn)換是指通過變更現(xiàn)有數(shù)據(jù)——例如根據(jù)某些特定指標(biāo)對數(shù)據(jù)進(jìn)行過濾——根據(jù)其創(chuàng)建出新的RDD。操作則隨RDD自身同步執(zhí)行。具體而言，操作內(nèi)容可以是計(jì)算某種數(shù)據(jù)類型的實(shí)例數(shù)量或者將RDD保存在單一文件當(dāng)中。
Spark的另一大優(yōu)勢在于允許使用者輕松將一套RDD共享給其它Spark項(xiàng)目。由于RDD的使用貫穿于整套Spark堆棧當(dāng)中，因此大家能夠隨意將SQL、機(jī)器學(xué)習(xí)、流以及圖形等元素?fù)诫s在同一個(gè)程序之內(nèi)。
熟悉各類其它函數(shù)型編程語言——例如LISP、Haskell或者F#——的開發(fā)人員會發(fā)現(xiàn)，除了API之外、自己能夠非常輕松地掌握Spark編程方式。歸功于Scala語言的出色收集系統(tǒng)，利用Spark Scala API編寫的應(yīng)用程序能夠以干凈而且簡潔的面貌呈現(xiàn)在開發(fā)者面前。在對Spark編程工作進(jìn)行調(diào)整時(shí)，我們主要需要考慮這套系統(tǒng)的分布式特性并了解何時(shí)需要對對象以及函數(shù)進(jìn)行排序。
擁有其它程序語言，例如Java，知識背景的程序員則往往沒辦法快速適應(yīng)Spark項(xiàng)目的函數(shù)編程范式。有鑒于此，企業(yè)可能會發(fā)現(xiàn)找到一位能夠切實(shí)上手Spark（從這個(gè)角度講，Hadoop也包含其中）的Scala與函數(shù)編程人員實(shí)在不是件容易的事。
<img src="https://pic2.zhimg.com/4b02ef9e99f644ee035f8f9b0ef30375_b.jpg" data-rawwidth="552" data-rawheight="295" class="origin_image zh-lightbox-thumb" width="552" data-original="https://pic2.zhimg.com/4b02ef9e99f644ee035f8f9b0ef30375_r.jpg">由于Spark的RDD能夠?qū)崿F(xiàn)跨系統(tǒng)共享，因此大家能夠隨意將SQL、機(jī)器學(xué)習(xí)、流以及圖形等元素?fù)诫s在同一個(gè)程序之內(nèi)。
彈性分布式數(shù)據(jù)集
對于RDD的使用貫穿于整套堆棧當(dāng)中，而這也成為Spark如此強(qiáng)大的根基之一。無論是從概念層面還是實(shí)施層面，RDD都顯得非常簡單; RDD類當(dāng)中的大部分方法都在20行以內(nèi)。而從核心角度看，RDD屬于一套分布式記錄集合，由某種形式的持久性存儲作為依托并配備一系列轉(zhuǎn)換機(jī)制。
RDD是不可變更的。我們無法對RDD進(jìn)行修改，但卻能夠輕松利用不同數(shù)值創(chuàng)建新的RDD。這種不可變性算得上是分布式數(shù)據(jù)集的一大重要特性; 這意味著我們用不著擔(dān)心其它線程或者進(jìn)程在我們不知不覺中對RDD數(shù)值作出了變更——而這正是多線程編程領(lǐng)域的一個(gè)老大難問題。這同時(shí)意味著我們能夠?qū)DD分發(fā)到整個(gè)集群當(dāng)中加以執(zhí)行，而不必?fù)?dān)心該如何在各節(jié)點(diǎn)之間對RDD內(nèi)容變更進(jìn)行同步。
RDD不可變性在Spark應(yīng)用程序的容錯機(jī)制當(dāng)中同樣扮演著重要角色。由于每個(gè)RDD都保留有計(jì)算至當(dāng)前數(shù)值的全部歷史記錄、而且其它進(jìn)程無法對其作出變更，因此在某個(gè)節(jié)點(diǎn)丟失時(shí)對RDD進(jìn)行重新計(jì)算就變得非常輕松——只需要返回原本的持久性數(shù)據(jù)分區(qū)，再根據(jù)不同節(jié)點(diǎn)重新推導(dǎo)計(jì)算即可。（Hadoop當(dāng)中的大多數(shù)分區(qū)都具備跨節(jié)點(diǎn)持久性。）
RDD能夠通過多種數(shù)據(jù)分區(qū)類型加以構(gòu)成。在大多數(shù)情況下，RDD數(shù)據(jù)來自HDFS，也就是所謂“分區(qū)”的書面含義。不過RDD也可以由來自其它持久性存儲機(jī)制的數(shù)據(jù)所構(gòu)成，其中包括HBase、Cassandra、SQL數(shù)據(jù)庫（通過JDBC）、Hive ORC（即經(jīng)過優(yōu)化的行列）文件乃至其它能夠與Hadoop InputFormat API相對接的存儲系統(tǒng)。無論RDD的實(shí)際來源如何，其運(yùn)作機(jī)制都是完全相同的。
Spark轉(zhuǎn)換機(jī)制的最后一項(xiàng)備注是：此類流程非常懶惰，也就是說直到某項(xiàng)操作要求將一條結(jié)果返回至驅(qū)動程序，否則此前整個(gè)過程不涉及任何計(jì)算環(huán)節(jié)。這樣的特性在與Scala shell進(jìn)行交互時(shí)顯得意義重大。這是因?yàn)镽DD在逐步轉(zhuǎn)換的過程當(dāng)中不會帶來任何資源成本——直到需要執(zhí)行實(shí)際操作。到這個(gè)時(shí)候，所有數(shù)值才需要進(jìn)行計(jì)算，并將結(jié)果返回給用戶。除此之外，由于RDD能夠利用內(nèi)存充當(dāng)緩存機(jī)制，因此頻繁使用計(jì)算結(jié)果也不會造成反復(fù)計(jì)算或者由此引發(fā)的資源消耗。
<img src="https://pic2.zhimg.com/8f99ad9074e249324a00e68e58939729_b.jpg" data-rawwidth="594" data-rawheight="119" class="origin_image zh-lightbox-thumb" width="594" data-original="https://pic2.zhimg.com/8f99ad9074e249324a00e68e58939729_r.jpg">Spark轉(zhuǎn)換機(jī)制非常懶惰，也就是說直到某項(xiàng)操作要求將一條結(jié)果返回至用戶處，否則此前整個(gè)過程不涉及任何計(jì)算環(huán)節(jié)。
執(zhí)行Spark應(yīng)用程序
為了將一項(xiàng)Spark任務(wù)提交至集群，開發(fā)人員需要執(zhí)行驅(qū)動程序并將其與集群管理器（也被稱為cluster master）相對接。集群管理器會為該驅(qū)動程序提供一套持久性接口，這樣同一款應(yīng)用程序即可在任何受支持集群類型之上實(shí)現(xiàn)正常運(yùn)行。
Spark項(xiàng)目目前支持專用Spark（獨(dú)立）、Mesos以及YARN集群。運(yùn)行在集群當(dāng)中的每個(gè)驅(qū)動程序以各自獨(dú)立的方式負(fù)責(zé)資源分配與任務(wù)調(diào)度工作。盡管以隔離方式進(jìn)行應(yīng)用程序交付，但這種架構(gòu)往往令集群很難高效實(shí)現(xiàn)內(nèi)存管理——也就是對于Spark而言最為寶貴的資源類型。多個(gè)高內(nèi)存消耗任務(wù)在同時(shí)提交時(shí)，往往會瞬間將內(nèi)存吞噬殆盡。盡管獨(dú)立集群管理器能夠?qū)崿F(xiàn)簡單的資源調(diào)度，但卻只能做到跨應(yīng)用程序FIFO（即先入先出）這種簡單的程度，而且無法實(shí)現(xiàn)資源識別。
總體而言，Spark開發(fā)人員必須更傾向于裸機(jī)層面思維，而非利用像Hive或者Pig這樣的高級應(yīng)用程序?qū)?shù)據(jù)分析作為思考出發(fā)點(diǎn)。舉例來說，由于驅(qū)動程序充當(dāng)著調(diào)度任務(wù)的執(zhí)行者，它需要最大程度與這些工作節(jié)點(diǎn)保持緊密距離、從而避免網(wǎng)絡(luò)延遲對執(zhí)行效果造成的負(fù)面影響。
驅(qū)動程序與集群管理器高可用性這兩者都很重要。如果驅(qū)動程序停止工作，任務(wù)也將立即中止。而如果集群管理器出現(xiàn)故障，新的任務(wù)則無法被提交至其中，不過現(xiàn)有任務(wù)仍將繼續(xù)保持執(zhí)行。在Spark 1.1版本當(dāng)中，主高可用性機(jī)制由獨(dú)立Spark集群通過ZooKeeper實(shí)現(xiàn)，但驅(qū)動程序卻缺乏與高可用性相關(guān)的保障措施。
將一套Spark集群當(dāng)中的性能最大程度壓榨出來更像是一種魔法甚至妖術(shù)，因?yàn)槠渲行枰婕皩︱?qū)動程序、執(zhí)行器、內(nèi)存以及內(nèi)核的自由組合及反復(fù)實(shí)驗(yàn)，同時(shí)根據(jù)特定集群管理器對CPU及內(nèi)存使用率加以優(yōu)化。目前關(guān)于此類運(yùn)維任務(wù)的指導(dǎo)性文檔還非常稀缺，而且大家可能需要與同事進(jìn)行頻繁溝通并深入閱讀源代碼來實(shí)現(xiàn)這一目標(biāo)。
<img src="https://pic3.zhimg.com/6ede2e5d81161192c22ac8b1f77156f2_b.jpg" data-rawwidth="565" data-rawheight="262" class="origin_image zh-lightbox-thumb" width="565" data-original="https://pic3.zhimg.com/6ede2e5d81161192c22ac8b1f77156f2_r.jpg">Spark應(yīng)用程序架構(gòu)。Spark目前可以被部署在Spark獨(dú)立、YARN或者M(jìn)esos集群當(dāng)中。請注意，運(yùn)行在集群當(dāng)中的每一個(gè)驅(qū)動程序都會以彼此獨(dú)立的方式進(jìn)行資源分配與任務(wù)調(diào)度。
監(jiān)控與運(yùn)維
每一款驅(qū)動程序都擁有自己的一套Web UI，通常為端口4040，其中顯示所有實(shí)用性信息——包括當(dāng)前運(yùn)行任務(wù)、調(diào)度程度、執(zhí)行器、階段、內(nèi)存與存儲使用率、RDD等等。這套UI主要充當(dāng)信息交付工具，而非針對Spark應(yīng)用程序或者集群的管理方案。當(dāng)然，這也是調(diào)試以及性能調(diào)整之前的基礎(chǔ)性工具——我們需要了解的、與應(yīng)用程序運(yùn)行密切相關(guān)的幾乎所有信息都能在這里找到。
雖然算是個(gè)不錯的開始，但這套Web UI在細(xì)節(jié)方面仍然顯得比較粗糙。舉例來說，要想查看任務(wù)歷史記錄、我們需要導(dǎo)航到一臺獨(dú)立的歷史服務(wù)器，除非大家所使用的是處于獨(dú)立模式下的集群管理器。不過最大的缺點(diǎn)在于，這套Web UI缺少對于運(yùn)維信息的管理與控制能力。啟動與中止節(jié)點(diǎn)運(yùn)行、查看節(jié)點(diǎn)運(yùn)行狀況以及其它一些集群層面的統(tǒng)計(jì)信息在這里一概無法實(shí)現(xiàn)。總體而言，Spark集群的運(yùn)行仍然停留在命令行操作時(shí)代。
<img src="https://pic1.zhimg.com/83f3a05dcda66bc606bd256d1bbfcbb0_b.jpg" data-rawwidth="560" data-rawheight="411" class="origin_image zh-lightbox-thumb" width="560" data-original="https://pic1.zhimg.com/83f3a05dcda66bc606bd256d1bbfcbb0_r.jpg">Spark的Web UI提供了與當(dāng)前運(yùn)行任務(wù)相關(guān)的豐富信息，但所有指向集群的管理操作則需要完全通過命令行來實(shí)現(xiàn)。
Spark對決Tez
事實(shí)上，Spark與Tez都采用有向無環(huán)圖（簡稱DAG）執(zhí)行方式，這兩套框架之間的關(guān)系就如蘋果與桔子般不分軒輊，而最大的差別在于其受眾以及設(shè)計(jì)思路。即使如此，我發(fā)現(xiàn)很多IT部門仍然沒能分清這兩款框架間的差異所在。
Tez是一款應(yīng)用程序框架，設(shè)計(jì)目的在于幫助開發(fā)人員編寫出更為高效的多級MapReduce任務(wù)。舉例來說，在Hive 0.13版本當(dāng)中，HQL（即Hive查詢語言）由語言編譯器負(fù)責(zé)解析并作為Tez DAG進(jìn)行渲染，即將數(shù)據(jù)流映射至處理節(jié)點(diǎn)處以實(shí)現(xiàn)高效執(zhí)行。Tez DAG由應(yīng)用程序以邊緣到邊緣、頂點(diǎn)到頂點(diǎn)的方式進(jìn)行構(gòu)建。用戶則完全不需要了解Tez DAG的構(gòu)建方式，甚至感受不到它的存在。
Spark與Tez之間的真正差異在于二者實(shí)現(xiàn)方式的不同。在Spark應(yīng)用程序當(dāng)中，同樣的工作節(jié)點(diǎn)通過跨迭代實(shí)現(xiàn)重新使用，這就消除了JVM啟動所帶來的資源成本。Spark工作節(jié)點(diǎn)還能夠?qū)ψ兞窟M(jìn)行緩存處理，從而消除對數(shù)值進(jìn)行跨迭代重新讀取與重新計(jì)算的需要。正是借鑒著以上幾大特征，Spark才能夠在迭代編程當(dāng)中如魚得水、充分發(fā)力。而由此帶來的缺點(diǎn)是，Spark應(yīng)用程序會消耗大量集群資源、特別是在緩存過期的情況下。我們很難在集群運(yùn)行著Spark的時(shí)候?qū)Y源進(jìn)行優(yōu)化。
盡管支持多級任務(wù)執(zhí)行機(jī)制，Tez仍然不具備任何形式的緩存處理能力。雖然變量能夠在一定程度上得到緩存處理，從而保證規(guī)劃器在可能的情況下保證調(diào)度任務(wù)從同節(jié)點(diǎn)中的上一級處獲取必要數(shù)值，但Tez當(dāng)中仍然未能提供任何一種經(jīng)過妥善規(guī)劃的跨迭代或者變量廣播機(jī)制。除此之外，Tez任務(wù)還需要反復(fù)啟動JVM，而這會帶來額外的資源開銷。因此，Tez更適合處理那些規(guī)模極為龐大的數(shù)據(jù)集，在這種情況下啟動時(shí)間只占整體任務(wù)處理周期的一小部分、幾乎可以忽略不計(jì)。
在大多數(shù)情況下，Hadoop社區(qū)對此都擁有很好的移花接木式解決方案，而且其中最出色的部分機(jī)制已經(jīng)能夠作用于其它項(xiàng)目。舉例來說，YARN-1197將允許Spark執(zhí)行器以動態(tài)方式進(jìn)行規(guī)模調(diào)整，這樣它們就能夠在合適的條件下將資源返還給集群。與之相似，Stinger.next將為Hive等傳統(tǒng)Hadoop應(yīng)用程序帶來由跨查詢緩存提供的巨大優(yōu)勢。
一整套集成化分析生態(tài)系統(tǒng)
Spark所采用的底層RDD抽象機(jī)制構(gòu)建起整個(gè)Spark生態(tài)系統(tǒng)的核心數(shù)據(jù)結(jié)構(gòu)。在機(jī)器學(xué)習(xí)（MLlib）、數(shù)據(jù)查詢（Spark SQL）、圖形分析（GraphX）以及流運(yùn)行（Spark Streaming）等模塊的共同支持下，開發(fā)人員能夠以無縫化方式使用來自任意單一應(yīng)用程序的庫。
舉例來說，開發(fā)人員可以根據(jù)HDFS當(dāng)中的某個(gè)文件創(chuàng)建一個(gè)RDD，將該RDD轉(zhuǎn)換為SchemaRDD、利用Spark SQL對其進(jìn)行查詢，而后將結(jié)果交付給MLlib庫。最后，結(jié)果RDD可以被插入到Spark Streaming當(dāng)中，從而充當(dāng)消息交付機(jī)制的預(yù)測性模型。如果要在不使用Spark項(xiàng)目的情況下實(shí)現(xiàn)以上目標(biāo)，大家需要使用多套庫、對數(shù)據(jù)結(jié)構(gòu)進(jìn)行封包與轉(zhuǎn)換，并投入大量時(shí)間與精力對其加以部署。總體而言，將三到上個(gè)在最初設(shè)計(jì)當(dāng)中并未考慮過協(xié)作場景的應(yīng)用程序整合在一起絕對不是正常人的脆弱心靈所能承受的沉重負(fù)擔(dān)。
堆棧集成機(jī)制讓Spark在交互式數(shù)據(jù)探索與同一數(shù)據(jù)集內(nèi)的重復(fù)性函數(shù)應(yīng)用領(lǐng)域擁有著不可替代的重要價(jià)值。機(jī)器學(xué)習(xí)正是Spark項(xiàng)目大展拳腳的理想場景，而在不同生態(tài)系統(tǒng)之間以透明方式實(shí)現(xiàn)RDD共享的特性更是大大簡化了現(xiàn)代數(shù)據(jù)分析應(yīng)用程序的編寫與部署流程。
然而，這些優(yōu)勢的實(shí)現(xiàn)并非全無代價(jià)。在1.x系列版本當(dāng)中，Spark系統(tǒng)在諸多細(xì)節(jié)上還顯得相當(dāng)粗糙。具體而言，缺乏安全性（Spark無法運(yùn)行在Kerberised集群當(dāng)中，也不具備任務(wù)控制功能）、缺乏企業(yè)級運(yùn)維功能、說明文檔質(zhì)量糟糕，而且嚴(yán)苛的稀缺性技能要求意味著目前Spark仍然只適合早期實(shí)驗(yàn)性部署或者那些有能力滿足大規(guī)模機(jī)器學(xué)習(xí)模型必需條件且愿意為其構(gòu)建支付任何投入的大型企業(yè)。
到底應(yīng)不應(yīng)該部署Spark算是一個(gè)“仁者見仁，智者見智”的開放性議題。對于一部分組織而言，Spark這套速度極快的內(nèi)存內(nèi)分析引擎能夠帶來諸多優(yōu)勢，從而輕松為其帶來理想的投資回報(bào)表現(xiàn)。但對于另一些組織來說，那些雖然速度相對較慢但卻更為成熟的工具仍然是其不二之選，畢竟它們擁有適合企業(yè)需求的完善功能而且更容易找到有能力對其進(jìn)行管理與控制的技術(shù)人員。
無論如何，我們都要承認(rèn)Spark的積極意義。Spark項(xiàng)目將一系列創(chuàng)新型思維帶入了大數(shù)據(jù)處理市場，并且表現(xiàn)出極為強(qiáng)勁的發(fā)展勢頭。隨著其逐步成熟，可以肯定Spark將最終成為一支不容忽視的巨大力量。
<img src="https://pic2.zhimg.com/200ea9a38a8acce589b18f3ee9d00cd9_b.jpg" data-rawwidth="586" data-rawheight="128" class="origin_image zh-lightbox-thumb" width="586" data-original="https://pic2.zhimg.com/200ea9a38a8acce589b18f3ee9d00cd9_r.jpg">Apache Spark 1.1.0 / Apache軟件基金會
總結(jié)性描述
作為一套配備精妙A(yù)PI以實(shí)現(xiàn)數(shù)據(jù)處理應(yīng)用程序創(chuàng)建目標(biāo)的高速內(nèi)存內(nèi)分析引擎，Spark在迭代工作負(fù)載這類需要重復(fù)訪問同一套或者多套數(shù)據(jù)集的領(lǐng)域——例如機(jī)器學(xué)習(xí)——表現(xiàn)出無可匹敵的競爭優(yōu)勢。
基于Apache 2.0許可的開源項(xiàng)目
優(yōu)勢
? 精妙且具備一致性保障的API幫助開發(fā)人員順利構(gòu)建起數(shù)據(jù)處理應(yīng)用程序
? 支持Hadoop集群上的交互式查詢與大規(guī)模數(shù)據(jù)集分析任務(wù)
? 在運(yùn)行迭代工作負(fù)載時(shí)擁有高出Hadoop幾個(gè)數(shù)量級的速度表現(xiàn)
? 能夠以獨(dú)立配置、YARN、Hadoop MapReduce或者M(jìn)esos等方式部署在Hadoop集群當(dāng)中
? RDD（即彈性分布式數(shù)據(jù)集）能夠在不同Spark項(xiàng)目之間順利共享，從而允許用戶將SQL、機(jī)器學(xué)習(xí)、流運(yùn)行以及圖形等元素?fù)诫s在同一程序當(dāng)中
? Web UI提供與Spark集群及當(dāng)前運(yùn)行任務(wù)相關(guān)的各類實(shí)用性信息
缺點(diǎn)
? 安全性不理想
? 說明文檔質(zhì)量糟糕
? 不具備集群資源管理能力
? 學(xué)習(xí)曲線不夠友好
熱愛大數(shù)據(jù)的話歡迎加我們信微：idacker
我被這東西快弄瘋了…… 半年內(nèi)版本升級到1.3了，依賴的hive還要0.13.1版本，人家hive都升級到1.1了。回頭又要依賴hadoop的mapredue和yarn，還要2.4版本的，可是人家都升級到2.6了。
Spark SQL 到底怎么搭建起來？
別告訴我那你就用0.13.1的hive和2.4的hadoop啊，2.4的hadoop已經(jīng)被官方拋棄了，連官方下載鏈接都沒有，2.x的版本，最古老的鏈接也是2.5.2的。0.13.1的hive的確有，可是人家都1.1了啊，好多東西都變了啊，網(wǎng)上連教程都變了啊。
回頭再說SparkSQL，他只是Spark的一個(gè)Module，可是卻要依賴這么多，還要依賴Scala，還要特定2.10.4版本，還要依賴hive，hive要依賴yarn，mapreduce又是必須的……
在網(wǎng)上各種爬文，我都買了個(gè)DigitalOcean服務(wù)器來搜外文，結(jié)果搜到的也還是古老的，揮著零散的部署教程，就是要么只告訴你spark怎么部署，要么告訴你sparksql怎么用，要么告訴你hive怎么搭，然后各個(gè)版本還不能依賴到一起去…
做畢設(shè)都半年了，前期就是寫sql代碼來著，最后就靠這玩意來加速跑代碼，結(jié)果死活搭不起來，去年弄了半個(gè)月，不行，今年這有弄了半個(gè)月，還不行……真是醉了……
求哪位大神快出現(xiàn)啊！！！ T_T 我真是跪了…… 給我個(gè)從頭到尾搭起 SparkSQL 的教程就行…… 么么噠……
作者：紀(jì)路鏈接：https://www.zhihu.com/question/29585524/answer/44883019
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
把Spark二進(jìn)制包下載并解壓到某一臺*nux的機(jī)器上，這段代碼中‘/Users/jilu/Downloads/’這段換成你自己的路徑，這就是單機(jī)執(zhí)行SparkSQL的代碼，在這個(gè)程序中，我已經(jīng)創(chuàng)建好sqlContext了，以后的部分就是SparkSQL教程了。這是我更新完1.3版之后新改的程序，不出意外1.X的版本都是這樣用的。
PS：補(bǔ)充一下這個(gè)是Python API，不是Scala的。
import os import sys import traceback # Path for spark source folder os.environ['SPARK_HOME']="/Users/jilu/Downloads/spark-1.3.0-bin-hadoop2.4"# Append pyspark to Python Path sys.path.append("/Users/jilu/Downloads/spark-1.3.0-bin-hadoop2.4/python/") sys.path.append("/Users/jilu/Downloads/spark-1.3.0-bin-hadoop2.4/python/lib/py4j-0.8.2.1-src.zip")# try to import needed models try:from pyspark import SparkContext from pyspark import SparkConf from pyspark.sql import SQLContext, Row print ("Successfully imported Spark Modules")except ImportError as e:print ("Can not import Spark Modules {}".format(traceback.format_exc()))sys.exit(1)# config spark env conf = SparkConf().setAppName("myApp").setMaster("local") sc = SparkContext(conf=conf) sqlContext = SQLContext(sc) 您好，請問Spark用python通過jdbc讀數(shù)據(jù)庫數(shù)據(jù)您用過嗎？我沒有成功，但是Scala和Java可以通過jdbc讀到數(shù)據(jù)。求助，謝謝！
我也是用Scala，我記得Spark的數(shù)據(jù)輸入輸出那一塊Python支持的不太好，除了RESTful和文件之外Python API不是沒有就是有問題。
你也可以使用Spark Standalone模式（文檔https://spark.apache.org/docs/latest/spark-standalone.html），官方又啟動腳本，直接幫你完成所有的部署，不需要Hadoop，不需要Hive，不需要MySQL
vm問題是太損性能
如果集群要nb的機(jī)器
＊＊＊測試環(huán)境
用docker好些 機(jī)器損耗小 普通macmini都可以搭出hadoop／spark最小三節(jié)點(diǎn)集群
參考
使用docker打造spark集群
＊＊＊生產(chǎn)環(huán)境
未來生產(chǎn)環(huán)境部署hadoop／spark到物理機(jī) 應(yīng)該情景不多
多是云端的大數(shù)據(jù)處理paas例如azure的hdinsight
（當(dāng)然云端也可以用docker）
節(jié)省成本 少維護(hù) 少硬件損耗（aws azure的數(shù)據(jù)流入流量都是不計(jì)費(fèi)的）
盡快上算法／應(yīng)用才是王道
spark在aws上已經(jīng)能做到1tb數(shù)據(jù)－》1rmb成本了
基本大數(shù)據(jù)的運(yùn)算量12tb 的spark運(yùn)算成本是12rmb（節(jié)點(diǎn)無限伸縮）
按照這個(gè)成本 自建hadoop／spark集群的硬件意義不大
（這個(gè)百節(jié)點(diǎn)要上百萬還有維護(hù)損耗
頂級國安或者軍事金融部門的需求另說
當(dāng)然如果有采購貪污需求的也另說
其它行業(yè)正經(jīng)做事不用云處理大數(shù)據(jù)是傻蛋）
問題是大數(shù)據(jù)的場景何在
weblog 達(dá)到12tb／天的網(wǎng)站中國過不去10家
SparkSQL就是Spark的一個(gè)模塊，只要成功安裝了Hadoop和Spark，最后開發(fā)的時(shí)候在pom文件里加上SparkSQL的依賴，并且在代碼里引SparkSQL的包就行了，所以關(guān)鍵還是搭Hadoop和Spark的集群，Hadoop2.6.0（現(xiàn)在已經(jīng)出到2.7了）和Spark1.3.1的搭建教程網(wǎng)上都可以找到，照著教程一步步做就行了
想快速建立一個(gè)hadoop+spark的環(huán)境， 你可以直接裝cloudera 的 CDH。 他們把上面一切都很好的整合在一起了。如果還想更簡單一點(diǎn)，裝一個(gè)cloudera 的quickstart 虛擬機(jī)， Cloudera QuickStart VM。 一個(gè)虛擬機(jī)，什么都有了。
不好意思，我沒有在quickstart VM上用過Spark SQL， 但是我在CDH5.1 的release note上看到這樣的話
Spark SQL
Spark SQL, which deserves a?blog post of its own, is a new Spark component that allows you to run SQL statements inside of a Spark application that manipulate and produce RDDs. Due to its immaturity and alpha component status, Cloudera does not currently offer commercial support for Spark SQL. **However, we bundle it with our distribution so that users can try it out.**
如果沒有理解錯的話，應(yīng)該是CDH已經(jīng)包含了，只是不提供官方支持。另外Spark 1.3 對Spark SQL有重大更新，引入了Data Frame RDD，以更好地支持結(jié)構(gòu)化數(shù)據(jù)。
再補(bǔ)充一點(diǎn)，Spark 并不是一定要綁定Hadoop，如果你僅僅是學(xué)習(xí)用，不打算把數(shù)據(jù)放到HDFS上， 你從github上下一個(gè)最新版的spark，編譯一下就可以了。 還是裝 hortonworks 發(fā)行的 hadoop吧，社區(qū)版本更新更快，組件更全，安裝配置更簡易。試用的話，直接下 sandbox虛擬機(jī)文件
hadoop,spark在虛擬機(jī)集群里跑還有性能上的優(yōu)勢嗎?修改
如題，系統(tǒng)搭建在公司的虛擬機(jī)集群上，這樣還有木有性能上的優(yōu)勢?或者說這樣搭建分布式計(jì)算系統(tǒng)還有意義么?反正最終都是服務(wù)器的內(nèi)存和硬盤，我感覺用多線程，多進(jìn)程的老方法，直接在服務(wù)器上跑，省去那些集群間的調(diào)度和網(wǎng)絡(luò)io，是不是會更快一些？
小白不懂,求大俠相助
作為分布式計(jì)算平臺，性能是非常重要的一個(gè)指標(biāo)，但絕對不是唯一一個(gè)指標(biāo)。單純從性能角度上來講，硬件資源固定，虛擬化增大了開銷，必然有所降低。但是虛擬化會帶來一些其他方面的功能。
問題中談到了性能，當(dāng)然虛擬化的引入比裸奔性能上一定會有影響，如果影響很大的話，在做架構(gòu)設(shè)計(jì)的時(shí)候就要根據(jù)實(shí)際需求進(jìn)行取舍；然而比如像container，docker等輕量級虛擬化技術(shù)的出現(xiàn)，使它對性能的影響被壓縮到了一個(gè)很小的地步，對于大多數(shù)分布式系統(tǒng)來說，這點(diǎn)性能損耗并不會有太大的影響……然后你懂的…… 性能問題在hadoop虛擬化里其實(shí)是個(gè)次要問題，雖然也確實(shí)性能差。
更重要不要做虛擬化的原因是你的很多hadoop虛擬機(jī)很有可能其實(shí)是跑在一臺物理服務(wù)器上的，那這臺物理服務(wù)器宕機(jī)就會導(dǎo)致整個(gè)集群不可用。
另外，虛擬化也可能使用的是共享存儲，那么這樣會讓hadoop內(nèi)建的冗余機(jī)制變得毫無意義。
第三，虛擬化里，你無法劃分正確的機(jī)架來讓hadoop合理的分布數(shù)據(jù)塊存放位置。
最后，虛擬化的網(wǎng)絡(luò)是軟件定義的，底層發(fā)生問題你很難對hadoop定位和排錯。
這些才是不要用虛擬化最重要的原因，排除這些才談到性能問題。
當(dāng)然曾經(jīng)也有人跟我抬杠，說一臺服務(wù)器只做一個(gè)虛擬機(jī)不就好了嗎？可問題是，你要這樣做的話為什么不直接裝hadoop，非要為了部署方便而白白浪費(fèi)掉30%的性能呢。每三臺服務(wù)器就會浪費(fèi)掉一臺物理機(jī)的計(jì)算能力，代價(jià)太大了，除非土豪的國企或政府，否則沒人會這么干。
確實(shí)沒有必要虛擬，Hadoop和spark都是可以單機(jī)跑的。如果你的服務(wù)器只有一個(gè)node，那么單機(jī)跑要快很多。
我同意樓上?@楊甬舟的說法。虛擬機(jī)或者容器來跑Hadoop和Spark，最大的優(yōu)勢就是在于方便部署和管理，并且共有云服務(wù)提供商可以提供彈性的服務(wù)，現(xiàn)在Databricks和Amazon，甚至國內(nèi)的青云都提供了Spark虛擬機(jī)集群服務(wù)。我覺得虛擬化主要是針對大型云服務(wù)提供商而言的，集群的快速部署和便捷管理服務(wù)是很有市場的，不管是科研還是生產(chǎn)環(huán)境。在此基礎(chǔ)上我想補(bǔ)充一下：
1. 性能的隔離是有必要的，不然就會相互干擾，單個(gè)物理節(jié)點(diǎn)下用多線（進(jìn)）程的方式的確從直觀上性能是比虛擬化后要好，但是虛擬機(jī)帶來的好處就是，一個(gè)服務(wù)器上可以跑多個(gè)集群，這些虛擬機(jī)可以分屬于不同的集群。你怎么在一臺服務(wù)器上裸奔多個(gè)Spark集群呢？
2. 虛擬化技術(shù)作為云計(jì)算的基礎(chǔ)，有其優(yōu)勢，它可以提供彈性資源服務(wù)，總體上是可以提高硬件使用率的，性能和資源使用率之間是存在一個(gè)tradeoff的。
3. 在按時(shí)間的計(jì)費(fèi)模式下，像Spark這種對內(nèi)存和CPU使用率較高的集群，部署到公有云中性價(jià)比較高。
另外一點(diǎn)，Hadoop部署到虛擬機(jī)集群中也已經(jīng)有很多很多成熟的研究成功和工業(yè)產(chǎn)品，至于性能，據(jù)前Spark團(tuán)隊(duì)leader明風(fēng)透露，阿里巴巴內(nèi)部曾經(jīng)試驗(yàn)過，大概性能損耗10%，這在大規(guī)模分布式系統(tǒng)中，和數(shù)據(jù)中心資源利用率比起來，應(yīng)該不足為道。
其實(shí)要看你們公司想怎么搞了，要是這些機(jī)器就用來跑你的這個(gè)集群，那就裸奔試試看唄，不然的話，虛擬化還是有存在的必要的。
另外，傳送門
[1]Three reasons you need to run Spark in the cloud
[2]Databricks Cloud: Making Big Data Easy hadoop的關(guān)鍵在io
spark的關(guān)鍵在內(nèi)存
虛擬機(jī)，沒錯，跑當(dāng)然能跑，尤其作為測試環(huán)境，但是扯得蛋真的很疼，是真的很疼的那種
如果生產(chǎn)環(huán)境資源有限，spark可以放在vm中跑，只要載入數(shù)據(jù)時(shí)注意點(diǎn)； Hadoop就盡量在物理機(jī)上面跑吧，節(jié)點(diǎn)少點(diǎn)比n個(gè)vm都強(qiáng)太多
經(jīng)驗(yàn)之談，你在太平洋攢10臺pc遠(yuǎn)比你買一臺hp的2U跑虛擬機(jī)讓Hadoop來得暢快
我們用的是hp的2U機(jī)器25塊900gb硬盤物理機(jī)作為節(jié)點(diǎn)來跑的，酸爽
推薦用docker搭建你的集群，真是太方便了。大數(shù)據(jù)是一個(gè)知識體系，不僅僅是spark，你其實(shí)應(yīng)該學(xué)的還包括，文件系統(tǒng)hdfs，Nosql，我推薦的是Cassandra，分布式消息隊(duì)列，比如kafka，由于kafka綁定了zookeeper，所以zk也少不了。流式處理越來越重要，storm雖然很不錯，但spark streaming由于能夠和spark sql，mllib無縫整合，所以更加推薦。最后你會發(fā)現(xiàn)搭建可以拿來學(xué)習(xí)的開發(fā)環(huán)境是相當(dāng)頭疼的。那么，學(xué)習(xí)docker吧，github上有大量配置好的鏡像可以供你使用。可以任意組織你期望的集群。所有一切都可以跑在一臺單機(jī)上。總之，docker是學(xué)習(xí)大數(shù)據(jù)的終極利器。
docker是最近很熱的microservices的基礎(chǔ)，很多產(chǎn)品級的服務(wù)都已經(jīng)遷移的docker上了，所以docker可以說基本成熟了。另外docker容器對宿主機(jī)來說就是一個(gè)進(jìn)程而已，內(nèi)核級的開銷很小，所以和創(chuàng)建一個(gè)虛擬機(jī)比，怎么會消耗更多內(nèi)存呢？另外，對于學(xué)習(xí)目的的集群，穩(wěn)定性真的這么重要嗎？ 我們用4核8G x86跑HDP鏡像，在dock中啟動6個(gè)container，兩個(gè)namenode，四個(gè)datanode。基本上每次跑mapreduce都會失敗，提示network refused，虛擬內(nèi)存達(dá)到4個(gè)G。最后不得不destroy container再rebuild，導(dǎo)致hdfs上結(jié)果文件丟失，需要重新跑。每次執(zhí)行都提心吊膽。最后，還是換成單機(jī)鏡像了。。
用 standalone 的方式跑不挺好，大部分人的機(jī)子跑不起 spark 的
用standlone模式當(dāng)然也可以，但是如果能模擬集群的運(yùn)行狀態(tài)，豈不是更好。畢竟真正的應(yīng)用都是跑在集群上的。spark版本演進(jìn)很快，用docker驗(yàn)證一個(gè)新版本，是非常方便的。它不會干擾你主機(jī)上跑的任何東西。
1）學(xué)搭建用docker鏡像意義不大 2）作為開發(fā)環(huán)境，你哪怕執(zhí)行個(gè) wordcount 無論數(shù)據(jù)多少，那速度，調(diào)試到你奔潰；不論 lxc 還是虛擬機(jī)，性能都強(qiáng)不過宿主機(jī)（更何況大部分人的開發(fā)機(jī)是 windows，先搭個(gè) vbox ，再在上面搭個(gè)docker），spark 在哪跑更快，可想而知
docker的好處一是你可以試錯，spark新版本出來了，你可以跑跑看，不會影響你現(xiàn)有的環(huán)境。第二是你可以搭配其它docker，比如kafka，比如Nosql用。組成一個(gè)更接近生產(chǎn)系統(tǒng)的真實(shí)大數(shù)據(jù)環(huán)境。
我當(dāng)然是裝過才這么說的。單機(jī)處理能力擺在那里，根本不應(yīng)該拿來跑完整的數(shù)據(jù)集，你可以采樣以后跑。但是在單機(jī)上，我們要驗(yàn)證算法的正確性。所以模擬一個(gè)近生產(chǎn)系統(tǒng)的環(huán)境還是有必要的。
感覺目前在大集群管理系統(tǒng)中，應(yīng)用docker做資源隔離容器（替代系統(tǒng)級進(jìn)程或JVM進(jìn)程）的要比用docker搭建集群更多些，因?yàn)閐ocker本身的特性，使得支持docker容器的資源管理框架能夠支持更多類型的應(yīng)用（例如Web）。之前也看多不少hadoop on docker的文章、dockerfile，但實(shí)際上由于docker在文件系統(tǒng)上還是存在不足的，所以也鮮見實(shí)際應(yīng)用的。在各種傻瓜式部署軟件例如cdh、cloudera manager的幫助下，環(huán)境的搭建反而不那么困難。在生產(chǎn)環(huán)境docker on hadoop的意義應(yīng)當(dāng)遠(yuǎn)勝于hadoop on docker，不過對于初學(xué)者學(xué)習(xí)而言，或許算是一個(gè)不錯的選擇，足夠直觀簡潔。個(gè)人淺見~
承蒙各位捧場，給贊，我想把我的回答再澄清一下。首先，我想回答的問題是大數(shù)據(jù)學(xué)習(xí)者如何搭建一個(gè)學(xué)習(xí)環(huán)境。并不是如何搭建一個(gè)生產(chǎn)環(huán)境。實(shí)驗(yàn)和生產(chǎn)環(huán)境是有很大區(qū)別的。docker目前可能還不太適合用于生產(chǎn)環(huán)境，但是用于實(shí)驗(yàn)是絕對沒有問題的，而且非常方便，搭建快速。github什么有很多例子，大家可以參考借鑒一下。
關(guān)于學(xué)好大數(shù)據(jù)處理框架，我這里這樣假設(shè)：
關(guān)于機(jī)器配置，其實(shí)也不用太夸張，這無非又是給自己的惰性找個(gè)借口罷了，主流能跑得動LOL的機(jī)器都能滿足你基本的測試學(xué)習(xí)需要了，實(shí)在不行就壯士斷腕放棄游戲直接把系統(tǒng)裝成linux……所以關(guān)鍵還是你學(xué)習(xí)欲望是否強(qiáng)烈的問題。
當(dāng)然其實(shí)也沒有那么簡單，大數(shù)據(jù)量和小數(shù)據(jù)量畢竟有本質(zhì)上的區(qū)別，根本就是兩個(gè)世界的東西，處理100M和100T數(shù)據(jù)的區(qū)別不只是時(shí)間長短、節(jié)點(diǎn)多少的問題，有些問題只有在大規(guī)模數(shù)據(jù)處理時(shí)才會遇到，能夠解決好這類問題的人就很厲害了，也是這行門檻所在。
那么重點(diǎn)我想談?wù)劦氖堑诙€(gè)情況：假設(shè)你想學(xué)好框架。
Hadoop 和Spark發(fā)展到了今天，都已經(jīng)不僅僅是一個(gè)計(jì)算框架了，而使已經(jīng)演化成了生態(tài)完整的系統(tǒng)，很多這個(gè)行業(yè)最優(yōu)秀的程序員為它們做了貢獻(xiàn)。贊美開源世界，這些代碼對你都是Open的，那么就去閱讀好了，帶著目的的那種。比如你看到了spark standalone的任務(wù)提交流程代碼，那么為什么它這么搞？能從中借鑒什么？假設(shè)哪天自己要設(shè)計(jì)一個(gè)別的分布式系統(tǒng)時(shí)是否能夠參考？有什么優(yōu)缺點(diǎn)？這些東西我認(rèn)為在沒有集群的情況下都是能夠做的。
假設(shè)有這樣的積累，當(dāng)開始工作時(shí)，你放心：任何系統(tǒng)都會出現(xiàn)問題，當(dāng)問題發(fā)生時(shí)對你來說應(yīng)該一切都是脈絡(luò)清晰的；任何系統(tǒng)都不可能滿足所有需求，當(dāng)新需求spark/hadoop或者其他什么的滿足不了需求時(shí)需要重新開發(fā)或者改造時(shí)，你應(yīng)該使思路活躍的，應(yīng)該是能夠直擊問題關(guān)鍵點(diǎn)的。當(dāng)然這些鍛煉在沒有集群和實(shí)際操作的情況下是很難做到的，但可以先做好準(zhǔn)備。
我定義學(xué)好，在于系統(tǒng)的每個(gè)動作對你來說都是很清晰的，你知道它做這個(gè)動作的理由，它的實(shí)現(xiàn)方法，這個(gè)動作產(chǎn)生的影響，可能會出現(xiàn)問題的點(diǎn)……我比較笨，大概只能想到好好積累這一種手段……
如果你只是學(xué)習(xí)怎么用hadoop和spark單機(jī)跑就是了。如果你非要用cluster，去組一個(gè)就是了。這么多提供cloud服務(wù)的公司呢，也不貴。國內(nèi)用阿里，國外Amazon的EC2和Google的GCP都行。
可能對vagrant docker完全不了解？
如果你只是學(xué)習(xí)怎么用hadoop和spark單機(jī)跑就是了。如果你非要用cluster，去組一個(gè)就是了。這么多提供cloud服務(wù)的公司呢，也不貴。國內(nèi)用阿里，國外Amazon的EC2和Google的GCP都行。
作者：Wayne Shi
鏈接：https://www.zhihu.com/question/37026972/answer/87828727
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
Spark雖然是大規(guī)模的計(jì)算框架，但也支持在單機(jī)上運(yùn)行，對于入門學(xué)習(xí)者而言，單機(jī)環(huán)境已經(jīng)足夠。實(shí)驗(yàn)樓Spark訓(xùn)練營Hadoop - Spark 大數(shù)據(jù)動手實(shí)驗(yàn)第一節(jié)提供了免費(fèi)的在線Spark學(xué)習(xí)環(huán)境。
<img data-rawheight="632" data-rawwidth="1358" src="https://pic3.zhimg.com/fbdbae02c1b58ad2def6f8b3e5c339b6_b.png" class="origin_image zh-lightbox-thumb" width="1358" data-original="https://pic3.zhimg.com/fbdbae02c1b58ad2def6f8b3e5c339b6_r.png">
Spark安裝非常簡單，如需本地安裝可以參考以下步驟。
1. 安裝
1.1 安裝前準(zhǔn)備
安裝Spark之前需要先安裝Java，Scala及Python。
安裝Java實(shí)驗(yàn)樓環(huán)境中已經(jīng)安裝了JDK，這里打開桌面上的Xfce終端，執(zhí)行查看Java版本：
<img data-rawheight="169" data-rawwidth="682" src="https://pic4.zhimg.com/f250ba5f3c6bd2dad21f19249b9209bb_b.jpg" class="origin_image zh-lightbox-thumb" width="682" data-original="https://pic4.zhimg.com/f250ba5f3c6bd2dad21f19249b9209bb_r.jpg">可以看到實(shí)驗(yàn)樓的Java版本是1.8.0_60，滿足Spark 1.5.1對Java版本的要求。
如果需要自己安裝可以在Oracle的官網(wǎng)下載Java SE JDK，下載鏈接：Java SE - Downloads。
安裝Scala老版本的Spark安裝前需要先裝Scala，1.5.1版本可以無需這一步驟。但為了自己開發(fā)Scala程序調(diào)試的方便我們?nèi)匀话惭b一個(gè)最新版本2.11.7的Scala。
Scala官網(wǎng)下載地址：http://www.scala-lang.org/download/
<img data-rawheight="646" data-rawwidth="896" src="https://pic1.zhimg.com/aa486bad337fa300446c4d277e404880_b.jpg" class="origin_image zh-lightbox-thumb" width="896" data-original="https://pic1.zhimg.com/aa486bad337fa300446c4d277e404880_r.jpg">由于官網(wǎng)速度很慢，我們預(yù)先上傳到了實(shí)驗(yàn)樓內(nèi)網(wǎng)，下載并解壓到/opt/目錄：
wget http://labfile.oss.aliyuncs.com/courses/456/scala-2.11.7.tgz tar zxvf scala-2.11.7.tgz sudo mv scala-2.11.7 /opt/測試scala命令，并查看版本：
<img data-rawheight="125" data-rawwidth="695" src="https://pic1.zhimg.com/d92147fb9a9016ce1c91f09341f865d0_b.jpg" class="origin_image zh-lightbox-thumb" width="695" data-original="https://pic1.zhimg.com/d92147fb9a9016ce1c91f09341f865d0_r.jpg">安裝Python及IPython
安裝執(zhí)行命令：
sudo apt-get update sudo apt-get install python ipython實(shí)驗(yàn)樓中已經(jīng)安裝了Python及IPython，分別查看版本：
<img data-rawheight="165" data-rawwidth="402" src="https://pic1.zhimg.com/eaddcfc021a2e4440d65159ad48b2fb8_b.jpg" class="content_image" width="402">1.2 Spark下載
課程中使用目前最新穩(wěn)定版：Spark 1.5.1，官網(wǎng)上下載已經(jīng)預(yù)編譯好的Spark binary，直接解壓即可。
Spark官方下載鏈接：Downloads | Apache Spark
下載頁面中我們?nèi)缦聢D選擇Pre-build for Hadoop 2.6 and later并點(diǎn)擊下載：
<img data-rawheight="752" data-rawwidth="968" src="https://pic2.zhimg.com/56200e96756095d44ee51667ca91fb3d_b.jpg" class="origin_image zh-lightbox-thumb" width="968" data-original="https://pic2.zhimg.com/56200e96756095d44ee51667ca91fb3d_r.jpg">為了節(jié)約時(shí)間，我們選擇從阿里云的鏡像下載：
wget http://mirrors.aliyuncs.com/apache/spark/spark-1.5.1/spark-1.5.1-bin-hadoop2.6.tgz大約268M大小，下載完成后解壓并拷貝到/opt/目錄：
tar zxvf spark-1.5.1-bin-hadoop2.6.tgz sudo mv spark-1.5.1-bin-hadoop2.6 /opt/進(jìn)入到spark目錄查看目錄結(jié)構(gòu)，本節(jié)實(shí)驗(yàn)中會用到bin/目錄下的操作命令以及conf/目錄下的配置文件。
1.3 配置路徑與日志級別
為了避免每次都輸入/opt/spark-1.5.1-bin-hadoop2.6這一串前綴，我們將必要的路徑放到PATH環(huán)境變量中（實(shí)驗(yàn)樓用的是zsh，所以配置文件為~/.zshrc）：
# 添加配置到zshrc echo "export PATH=$PATH:/opt/spark-1.5.1-bin-hadoop2.6/bin" >> ~/.zshrc# 使zshrc起作用 source ~/.zshrc# 測試下spark-shell的位置是否可以找到 which spark-shell我們進(jìn)入到spark的配置目錄/opt/spark-1.5.1-bin-hadoop2.6/conf進(jìn)行配置：
# 進(jìn)入配置目錄 cd /opt/spark-1.5.1-bin-hadoop2.6/conf# 基于模板創(chuàng)建日志配置文件 cp log4j.properties.template log4j.properties# 使用vim或gedit編輯文件log4j.properties # 修改log4j.rootCategory為WARN, console，可避免測試中輸出太多信息 log4j.rootCategory=WARN, console# 基于模板創(chuàng)建配置文件 sudo cp spark-env.sh.template spark-env.sh# 使用vim或gedit編輯文件spark-env.sh # 添加以下內(nèi)容設(shè)置spark的環(huán)境變量 export SPARK_HOME=/opt/spark-1.5.1-bin-hadoop2.6 export SCALA_HOME=/opt/scala-2.11.7spark-env.sh配置如圖：
<img data-rawheight="542" data-rawwidth="842" src="https://pic1.zhimg.com/21e4cbc6a1aff91562f4883d1ee26c64_b.jpg" class="origin_image zh-lightbox-thumb" width="842" data-original="https://pic1.zhimg.com/21e4cbc6a1aff91562f4883d1ee26c64_r.jpg">spark-env.sh腳本會在啟動spark時(shí)加載，內(nèi)容包含很多配置選項(xiàng)及說明，在以后的實(shí)驗(yàn)中會用到少部分，感興趣可以仔細(xì)閱讀這個(gè)文件的注釋內(nèi)容。
至此，Spark就已經(jīng)安裝好了，Spark安裝很簡單，依賴也很少。
后續(xù)幾節(jié)介紹簡單的Spark操作，為以后的實(shí)驗(yàn)做基礎(chǔ)。
1.4 Spark-Shell
Spark-Shell是Spark自帶的一個(gè)Scala交互Shell，可以以腳本方式進(jìn)行交互式執(zhí)行，類似直接用Python及其他腳本語言的Shell。
進(jìn)入Spark-Shell只需要執(zhí)行spark-shell即可：
spark-shell進(jìn)入到Spark-Shell后可以使用Ctrl D組合鍵退出Shell。
在Spark-Shell中我們可以使用scala的語法進(jìn)行簡單的測試，比如下圖所示我們運(yùn)行下面幾個(gè)語句獲得文件/etc/protocols的行數(shù)以及第一行的內(nèi)容：
<img data-rawheight="227" data-rawwidth="828" src="https://pic4.zhimg.com/77a89194b89ada0f62ceba76bc79ba27_b.jpg" class="origin_image zh-lightbox-thumb" width="828" data-original="https://pic4.zhimg.com/77a89194b89ada0f62ceba76bc79ba27_r.jpg">上面的操作中創(chuàng)建了一個(gè)RDD file，執(zhí)行了兩個(gè)簡單的操作：
- count()獲取RDD的行數(shù)
- first()獲取第一行的內(nèi)容
我們繼續(xù)執(zhí)行其他操作，比如查找有多少行含有tcp和udp字符串：
<img data-rawheight="85" data-rawwidth="443" src="https://pic3.zhimg.com/d6163829db2711205dc6c9f3b65754c6_b.jpg" class="origin_image zh-lightbox-thumb" width="443" data-original="https://pic3.zhimg.com/d6163829db2711205dc6c9f3b65754c6_r.jpg">查看一共有多少個(gè)不同單詞的方法，這里用到Mapreduce的思路：
<img data-rawheight="117" data-rawwidth="537" src="https://pic1.zhimg.com/099feaa44189110662b8b06ed7bacb38_b.jpg" class="origin_image zh-lightbox-thumb" width="537" data-original="https://pic1.zhimg.com/099feaa44189110662b8b06ed7bacb38_r.jpg">上面兩步驟我們發(fā)現(xiàn)，/etc/protocols中各有一行含有tcp與udp字符串，并且一共有243個(gè)不同的單詞。上面兩步驟我們發(fā)現(xiàn)，/etc/protocols中各有一行含有tcp與udp字符串，并且一共有243個(gè)不同的單詞。上面每個(gè)語句的具體含義這里不展開，可以結(jié)合你閱讀的文章進(jìn)行理解，后續(xù)實(shí)驗(yàn)中會不斷介紹。Scala的語法我們在后續(xù)實(shí)驗(yàn)中會單獨(dú)學(xué)習(xí)，這里僅僅是提供一個(gè)簡單的例子讓大家對Spark運(yùn)算有基本認(rèn)識。
操作完成后，Ctrl D組合鍵退出Shell。
pysparkpyspark類似spark-shell，是一個(gè)Python的交互Shell。
執(zhí)行pyspark啟動進(jìn)入pyspark：
<img data-rawheight="381" data-rawwidth="825" src="https://pic4.zhimg.com/8978b30a85049daa08aa97e18e835a1b_b.jpg" class="origin_image zh-lightbox-thumb" width="825" data-original="https://pic4.zhimg.com/8978b30a85049daa08aa97e18e835a1b_r.jpg">退出方法仍然是Ctrl D組合鍵。
也可以直接使用IPython，執(zhí)行命令：IPYTHON=1 pyspark
<img data-rawheight="542" data-rawwidth="814" src="https://pic4.zhimg.com/c1e1ab057102281df1bf03289a9f8a1f_b.jpg" class="origin_image zh-lightbox-thumb" width="814" data-original="https://pic4.zhimg.com/c1e1ab057102281df1bf03289a9f8a1f_r.jpg">在pyspark中，我們可以用python語法執(zhí)行spark-shell中的操作，比如下面幾個(gè)語句獲得文件/etc/protocols的行數(shù)以及第一行的內(nèi)容：
<img data-rawheight="205" data-rawwidth="719" src="https://pic2.zhimg.com/52d8bf3f7d634742cd075bafe76f5b45_b.jpg" class="origin_image zh-lightbox-thumb" width="719" data-original="https://pic2.zhimg.com/52d8bf3f7d634742cd075bafe76f5b45_r.jpg">操作完成后，Ctrl D組合鍵退出Shell。操作完成后，Ctrl D組合鍵退出Shell。在后續(xù)的實(shí)驗(yàn)中我們將大量使用python和scala的交互式shell，可以及時(shí)的獲得實(shí)驗(yàn)結(jié)果，實(shí)驗(yàn)重在理解原理，內(nèi)容將很少涉及Java的內(nèi)容，如果你對Java很熟悉可以參考后續(xù)的實(shí)驗(yàn)代碼練習(xí)。
2. 啟動spark服務(wù)
這一節(jié)我們將啟動spark的master主節(jié)點(diǎn)和slave從節(jié)點(diǎn)，這里也會介紹spark單機(jī)模式和集群模式的部署區(qū)別。
2.1 啟動主節(jié)點(diǎn)執(zhí)行下面幾條命令啟動主節(jié)點(diǎn)：
# 進(jìn)入到spark目錄 cd /opt/spark-1.5.1-bin-hadoop2.6# 啟動主節(jié)點(diǎn) ./sbin/start-master.sh沒有報(bào)錯的話表示master已經(jīng)啟動成功，master默認(rèn)可以通過web訪問http://localhost:8080，打開桌面上的firefox瀏覽器，訪問該鏈接：
<img data-rawheight="478" data-rawwidth="892" src="https://pic1.zhimg.com/dfdae884d1f3eb085a2f375ddac9dc7c_b.jpg" class="origin_image zh-lightbox-thumb" width="892" data-original="https://pic1.zhimg.com/dfdae884d1f3eb085a2f375ddac9dc7c_r.jpg">圖中所示，master中暫時(shí)還沒有一個(gè)worker，我們啟動worker時(shí)需要master的參數(shù)，該參數(shù)已經(jīng)在上圖中標(biāo)志出來：spark://7a1e9a46bf54:7077，請?jiān)趫?zhí)行后續(xù)命令時(shí)替換成你自己的參數(shù)。
2.2 啟動從節(jié)點(diǎn)執(zhí)行下面的命令啟動slave
./sbin/start-slave.sh spark://7a1e9a46bf54:7077沒有報(bào)錯表示啟動成功，再次刷新firefox瀏覽器頁面可以看到下圖所示新的worker已經(jīng)添加：
<img data-rawheight="518" data-rawwidth="902" src="https://pic3.zhimg.com/6258e2fd44ffb967cb447176f6282f52_b.jpg" class="origin_image zh-lightbox-thumb" width="902" data-original="https://pic3.zhimg.com/6258e2fd44ffb967cb447176f6282f52_r.jpg">也可以用jps命令查看啟動的服務(wù)，應(yīng)該會列出Master和Slave。
2.3 測試實(shí)例使用pyspark連接master再次進(jìn)行上述的文件行數(shù)測試，如下圖所示，注意把MASTER參數(shù)替換成你實(shí)驗(yàn)環(huán)境中的實(shí)際參數(shù)：
<img data-rawheight="541" data-rawwidth="836" src="https://pic4.zhimg.com/717c2fa05786782a0aa349e231aaf38f_b.jpg" class="origin_image zh-lightbox-thumb" width="836" data-original="https://pic4.zhimg.com/717c2fa05786782a0aa349e231aaf38f_r.jpg">刷新master的web頁面，可以看到新的Running Applications，如下圖所示：
<img data-rawheight="527" data-rawwidth="899" src="https://pic2.zhimg.com/e53f109d1c461855ae02768a6bc37dc5_b.jpg" class="origin_image zh-lightbox-thumb" width="899" data-original="https://pic2.zhimg.com/e53f109d1c461855ae02768a6bc37dc5_r.jpg">當(dāng)退出pyspark時(shí)，這個(gè)application會移動到Completed Applications一欄。
可以自己點(diǎn)擊頁面中的Application和Workers的鏈接查看并了解相關(guān)信息。
2.4 停止服務(wù)停止服務(wù)的腳本為sbin/stop-all.sh，運(yùn)行時(shí)需要輸入shiyanlou用戶的密碼，因?yàn)槟_本中使用ssh遠(yuǎn)程對slave節(jié)點(diǎn)進(jìn)行管理：
cd /opt/spark-1.5.1-bin-hadoop2.6 ./sbin/stop-all.sh 2.5 集群部署上面的步驟介紹了我們在單機(jī)狀態(tài)Standalone Mode下部署的spark環(huán)境，如果要部署spark集群稍有區(qū)別：
那些說單機(jī)的，誰都知道可以單機(jī)跑，但是，在單機(jī)和集群搭建一個(gè)可以使用的環(huán)境是完全不一樣的，而且，有很多bug在單機(jī)環(huán)境下是無法觸發(fā)的。所以很多時(shí)候你在單機(jī)上能跑的代碼在集群上是會不斷報(bào)錯的。學(xué)習(xí)不是只是知道的就行。
沒有集群環(huán)境，可以單機(jī)跑應(yīng)用，但是還是沒有解決學(xué)習(xí)大數(shù)據(jù)平臺處理框架的問題。
我覺得有幾個(gè)方面，可以給你參考：
1、你需要一個(gè)比較強(qiáng)勁的機(jī)器，內(nèi)存/CPU要稍大一些，這些大數(shù)據(jù)的家伙都是吃資源的；
2、你可以選擇采用虛擬化技術(shù)，比如VMware，VirtualBox，多跑幾個(gè)linux，應(yīng)該問題不大；
3、你還可以選擇最近比較流行的Docker技術(shù)，很大程度上比虛擬化要便捷的多；
4、你還可以很土豪，買很多實(shí)體機(jī)，選擇用Ambari搭建一個(gè)真實(shí)的hadoop環(huán)境，我覺得那樣你會學(xué)得更快。
Sequence IQ, DataStax, Cloudera有很多已經(jīng)build 好的Docker images. Dockerhub上可以搜一下 用AWS的EMR吧，好處是你可以快速的跨過技術(shù)搭建環(huán)節(jié)開始關(guān)注商業(yè)價(jià)值。 集群環(huán)境更多的是為了生產(chǎn)環(huán)境。如果要學(xué)習(xí)相關(guān)知識的話，單機(jī)偽分布式完全是可以的。hadoop的話，建議讀hadoop權(quán)威指南，了解hadoop處理數(shù)據(jù)的各個(gè)流程，做一些基本的練習(xí)。 下載CDH鏡像文件，在虛擬機(jī)里面?zhèn)畏植际綀?zhí)行hadoop。需要注意，增加本機(jī)內(nèi)存至少到8G，hadoop尤其spark是吃內(nèi)存大戶。 推薦《深入理解Spark》 OReilly .Learning Spark. 推薦我去看官方文檔。因?yàn)閟park更新太快了，推薦直接去Apache spark 社區(qū)去看官方文檔 推薦 <Advanced.Analytics.with.Spark>, OReilly出版的,
這不是一本入門書,主要是講ML這一塊。
但這本書并不難讀，里面每一章都是實(shí)例，還提供數(shù)據(jù)源，
很方便動手實(shí)踐，通過這些“非玩具”的例子可以更好的學(xué)習(xí)
使用spark。 推薦幾個(gè)資料，是我最近在看的。
第一個(gè)是Apache Spark源碼剖析 (豆瓣)，這本書雖然照抄源碼，但是我覺得盯著電腦看源碼比較累（摔~~~）
第二本是Spark大數(shù)據(jù)處理：技術(shù)、應(yīng)用與性能優(yōu)化 (豆瓣) ，貌似評價(jià)不好，但是適合入門使用
但是，如果想徹底搞明白的話還是建議閱讀官方doc，幾篇論文啃下來比較好。Introduction 翻譯比較好的開發(fā)手冊也可以參照一下 推薦?《深入理解SPARK：核心思想與源碼分析》，此書適合Spark已經(jīng)入門的讀者閱讀，對于熱愛源碼的人也是不錯的選擇，目前，此書是國內(nèi)介紹Spark最全面的一本書，對于原理有深層次的解析。 《大數(shù)據(jù)Spark企業(yè)級實(shí)戰(zhàn)》http://item.jd.com/1443682720.html
本書共包括14章，每章的主要內(nèi)容如下。
第1章回答了Spark為何是大數(shù)據(jù)處理平臺的必然選擇？Spark速度如此之快的原因是什么？Spark的理論基石是什么？Spark具體是如何僅僅使用一個(gè)技術(shù)堆棧解決多元化的大數(shù)據(jù)處理的需求的？
第2章回答了如何從零起步構(gòu)建Hadoop集群？如何在Hadoop集群的基礎(chǔ)上構(gòu)建Spark集群？如何測試Spark集群？
第3章回答了如何在IDEA集成開發(fā)環(huán)境中開發(fā)并運(yùn)行Spark程序？如何在IDA中開發(fā)Spark代碼并進(jìn)行測試？
第4章在細(xì)致解析RDD的基礎(chǔ)上會動手實(shí)戰(zhàn)RDD中的Transformation類型的RDD、Action類型的RDD，并伴有Spark API的綜合實(shí)戰(zhàn)案例。
第5章詳細(xì)分析了Spark Standalone模式、Spark Yarn-Cluster模式、Spark-Client模式的設(shè)計(jì)和實(shí)現(xiàn)。
第6章首先介紹Spark內(nèi)核，接著分享通過源碼分析Spark內(nèi)核及源碼，細(xì)致解析Spark作業(yè)的全生命周期，最后分享Spark性能優(yōu)化的內(nèi)容。
. 第7章通過大約30個(gè)動手實(shí)踐的案例循序漸進(jìn)地展示Spark GraphX框架方方面面的功能和使用方法，并對Spark GraphX的源碼進(jìn)行解析。
第8章基于Spark SQL動手編程實(shí)踐章節(jié)，從零起步，細(xì)致而深入地介紹了Spark SQL方方面面的內(nèi)容。
第9章從快速入門機(jī)器學(xué)習(xí)開始，詳細(xì)解析MLlib框架，通過對線性回歸、聚類、協(xié)同過濾的算法解析、源碼解析和案例實(shí)戰(zhàn)，循序漸進(jìn)地揭秘MLLib，最后通過對MLlib中Basic Statics、樸素貝葉斯算法、決策樹的解析和實(shí)戰(zhàn)，進(jìn)一步提升掌握Spark機(jī)器學(xué)習(xí)的技能。
第10章細(xì)致解析了Tachyon這個(gè)分布式內(nèi)存文件系統(tǒng)的架構(gòu)設(shè)計(jì)、具體實(shí)現(xiàn)、部署以及Spark對Tachyon的使用等內(nèi)容。
第11章循序漸進(jìn)地介紹Spark Streaming的原理、源碼和實(shí)戰(zhàn)案例等內(nèi)容。
第12章介紹了Spark多語言編程的特點(diǎn)，并通過代碼實(shí)例循序漸進(jìn)地介紹Spark多語言編程，最后通過一個(gè)綜合實(shí)例來實(shí)踐Spark多語言編程。
第13章從R語言的基礎(chǔ)介紹和動手實(shí)戰(zhàn)入手，介紹SparkR的使用和代碼實(shí)戰(zhàn)，助您快速上手R語言和Spark兩大大數(shù)據(jù)處理的利器。
第14章循序漸進(jìn)地介紹了Spark常見的問題及其調(diào)優(yōu)方式。首先介紹Spark性能優(yōu)化的14大問題及其解決方法，然后從內(nèi)存優(yōu)化、RDD分區(qū)、Spark對象和操作的性能調(diào)優(yōu)等角度解決常見的性能調(diào)優(yōu)問題，最后講解Spark最佳實(shí)踐方案。
第15章聚焦于Spark源碼中的BlockManager、Cache和Checkpoint等核心源碼解析，BlockManager、Cache和Checkpoint是每個(gè)Spark學(xué)習(xí)者都必須掌握的核心內(nèi)容。本章循序漸進(jìn)地解析了這三部分的源碼，包括通過源碼說明其用途、實(shí)現(xiàn)機(jī)制、內(nèi)部細(xì)節(jié)和實(shí)際Spark生產(chǎn)環(huán)境下的最佳實(shí)踐等，通過本章即可輕松駕馭BlockManager、Cache和Checkpoint，從而對Spark精髓的領(lǐng)悟也必將更上層樓！
附錄主要是從Spark的角度來講解Scala，以動手實(shí)戰(zhàn)為核心，從零開始，循序漸進(jìn)地講解Scala函數(shù)式編程和面向?qū)ο缶幊獭? 剛找到了一個(gè)微信，上面剛開始講spark的，可以學(xué)習(xí)下。
【Spark大數(shù)據(jù)處理】動手寫WordCount
王家林《Spark亞太研究院系列叢書——Spark實(shí)戰(zhàn)高手之路 從零開始 》Spark亞太研究院系列叢書――Spark實(shí)戰(zhàn)高手之路 從零開始
王家林《spark亞太研究院專刊》Spark專刊-Spark亞太研究院
王家林《spark亞太研究院中文文檔翻譯》【Spark亞太研究院 共享資料】Spark官方文檔中文翻譯
王家林spark亞太研究院出版圖書《大數(shù)據(jù)Spark企業(yè)級實(shí)戰(zhàn)》現(xiàn)貨包郵 大數(shù)據(jù)Spark企業(yè)級實(shí)戰(zhàn) Spark亞太研究院 王家林【圖片 價(jià)格 品牌 報(bào)價(jià)】
王家林《spark亞太研究院100期公益大講堂》
搜索視頻：spark亞太研究院
王家林spark亞太研究院線下課程地址Spark亞太研究院的在線課堂
王家林英語視頻百度視頻搜索_王家林英語
王家林的書籍王家林 - 商品搜索
王家林spark亞太峰會百度視頻搜索_spark亞太峰會#pn=0
王家林移動互聯(lián)網(wǎng)Android書籍王家林Android
王家林Hadoop視頻從技術(shù)角度思考Hadoop到底是什么
王家林Scala視頻熟練的掌握Scala語言【大數(shù)據(jù)Spark實(shí)戰(zhàn)高手之路1】_51CTO學(xué)院
王家林spark視頻百度視頻搜索_王家林spark視頻
我個(gè)人感覺看spark的書，還不如看spark官網(wǎng)的開發(fā)文檔，文檔寫的很詳細(xì)。等熟悉了再看源碼，推薦jerryshao的博客http://jerryshao.me/和岑玉海的Spark源碼系列，或者M(jìn)atei Zaharia的論文。 講解的非常詳細(xì)，內(nèi)容深入淺出。下面是王家林的1000講免費(fèi)視頻：1，《大數(shù)據(jù)不眠夜：Spark內(nèi)核天機(jī)解密（共100講）》：http://pan.baidu.com/s/1eQsHZAq
2，《Hadoop深入淺出實(shí)戰(zhàn)經(jīng)典》http://pan.baidu.com/s/1mgpfRPu
3，《Spark純實(shí)戰(zhàn)公益大講壇》http://pan.baidu.com/s/1jGpNGwu
4，《Scala深入淺出實(shí)戰(zhàn)經(jīng)典》http://pan.baidu.com/s/1sjDWG25
5，《Docker公益大講壇》http://pan.baidu.com/s/1kTpL8UF
6，《Spark亞太研究院Spark公益大講堂》http://pan.baidu.com/s/1i30Ewsd
7，DT大數(shù)據(jù)夢工廠Spark、Scala、Hadoop的所有視頻、PPT和代碼在百度云網(wǎng)盤的鏈接：
百度云 網(wǎng)盤-Rocky_Android的分享 1，《大數(shù)據(jù)不眠夜：Spark內(nèi)核天機(jī)解密（共100講）》：http://pan.baidu.com/s/1eQsHZAq
2，《Hadoop深入淺出實(shí)戰(zhàn)經(jīng)典》http://pan.baidu.com/s/1mgpfRPu
3，《Spark純實(shí)戰(zhàn)公益大講壇》http://pan.baidu.com/s/1jGpNGwu
4，《Scala深入淺出實(shí)戰(zhàn)經(jīng)典》http://pan.baidu.com/s/1sjDWG25
5，《Docker公益大講壇》http://pan.baidu.com/s/1kTpL8UF
6，《Spark亞太研究院Spark公益大講堂》http://pan.baidu.com/s/1i30Ewsd
7，DT大數(shù)據(jù)夢工廠Spark、Scala、Hadoop的所有視頻、PPT和代碼在百度云網(wǎng)盤的鏈接：
百度云 網(wǎng)盤-Rocky_Android的分享 今年一月份新出的Learning Spark: Lightning-Fast Big Data Analysis算是官方的權(quán)威書籍了，對于Spark入門很有幫助。
Amazon鏈接：Learning Spark: Lightning-Fast Big Data Analysis: Holden Karau, Andy Konwinski, Patrick Wendell, Matei Zaharia: 9781449358624: Amazon.com: Books
spark更新太快了，市面上書都是基于spark1.2以前的版本，而最新的1.4和以前的版本已經(jīng)有了相當(dāng)大的改變。尤其是dataframe，mllib，改動非常大。 回答中已經(jīng)有書的推薦，確實(shí)還沒有什么好書。
如果是使用，本人推薦看spark各個(gè)版本的doc：Documentation更加合適，還有多看微博上國內(nèi)的幾個(gè)contributor在微博上關(guān)于spark的討論。
如果要了解源碼，可以跟進(jìn)github上spark的repo：apache/spark · GitHub，從配置sbt，編譯源碼，嘗試修改源碼開始，多看PR：Pull Requests · apache/spark · GitHub。
由于spark正在發(fā)展，你可以找你感興趣的緊跟其中一方面spark sql（包括sql parser，查詢優(yōu)化catalyst和邏輯和物理執(zhí)行計(jì)劃的表示，各個(gè)物理算子的實(shí)現(xiàn)），mlbase（各種機(jī)器學(xué)習(xí)算法的實(shí)現(xiàn)）或者graphx，集中了解某一方面的原理和詳細(xì)的實(shí)現(xiàn)過程，我想這個(gè)是學(xué)習(xí)spark最大的價(jià)值。 后面的總結(jié)很到位，跟我想的一樣。其實(shí)學(xué)習(xí)大數(shù)據(jù)之前，推薦學(xué)習(xí)《函數(shù)式編程思維》、《七周七并發(fā)模型》。基本原理一樣了，就是分布式的實(shí)現(xiàn)了。 作者：慕尤才
鏈接：https://www.zhihu.com/question/23655827/answer/64871458
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
注意！注意！推薦今年年初出版的一本書，作者都是Spark的主要貢獻(xiàn)者：
Learning Spark: Lightning-Fast Big Data Analysis
http://www.amazon.com/Learning-Spark-Lightning-Fast-Data-Analysis/dp/1449358624/
這本書有這樣幾個(gè)特點(diǎn)：
- 可操作性強(qiáng)：安裝好Spark后，就可以直接照著書中的例子進(jìn)行實(shí)際操作，Learning by doing，比直接看Spark的論文來得要簡單爽快。類似于初學(xué)Linux也不一定得先把操作系統(tǒng)原理學(xué)得徹徹底底了才開始動手；帶著問題邊干邊學(xué)不斷深入才會效率高。
- 實(shí)例充實(shí)：提供了Scala、Python、Java三種接口的操作代碼，提供了諸如PageRank算法的實(shí)現(xiàn)，并在在How to的基礎(chǔ)上加入了大量Why to的討論，討論如何在Spark分布式環(huán)境下實(shí)現(xiàn)更高效的計(jì)算，如何減少網(wǎng)絡(luò)開銷。github上也有作者提供的配套代碼：databricks/learning-spark · GitHub
- 文字扼要：比官方文檔（Spark Programming Guide）更深入地介紹代碼作用原理，同時(shí)也不像普通外文教材一樣廢話連篇。例如這一句：“為分布式數(shù)據(jù)集選擇正確的分區(qū)策略的重要性類似于為本地?cái)?shù)據(jù)選擇正確的數(shù)據(jù)結(jié)構(gòu)。”讓人思考良久。
翻譯了其中我認(rèn)為最重要的第四章，放在了這里，大家可以看一看：
CHAPTER 4: Working with Key/ValuePairs
百度云：OReilly.Learning.Spark.2015.1-CN-13-Chapter4.pdf_免費(fèi)高速下載
截圖1：
&amp;amp;amp;amp;amp;lt;img src="https://pic1.zhimg.com/4635f69fb4927245a2414db1f3f2ccb8_b.png" data-rawwidth="524" data-rawheight="785" class="origin_image zh-lightbox-thumb" width="524" data-original="https://pic1.zhimg.com/4635f69fb4927245a2414db1f3f2ccb8_r.png"&amp;amp;amp;amp;amp;gt;
截圖2：
&amp;amp;amp;amp;amp;lt;img src="https://pic2.zhimg.com/fa3024230728e7f3a99387545bd74559_b.png" data-rawwidth="517" data-rawheight="795" class="origin_image zh-lightbox-thumb" width="517" data-original="https://pic2.zhimg.com/fa3024230728e7f3a99387545bd74559_r.png"&amp;amp;amp;amp;amp;gt;
=======下面是我的一些理解=========
Spark在嘗試把函數(shù)式語言的模型，應(yīng)用在了分布式的環(huán)境中。
我一直認(rèn)為函數(shù)式語言是為了分布式/多核環(huán)境而生的，而且其設(shè)計(jì)歷史之久遠(yuǎn)足以看出設(shè)計(jì)者的遠(yuǎn)見（額，這個(gè)遠(yuǎn)見可能只是巧合，還好我們除了圖靈機(jī)外還有l(wèi)ambda演算）。我在大三時(shí)修習(xí)喬海燕老師的“函數(shù)式編程”這門課時(shí)，發(fā)現(xiàn)函數(shù)式語言很多特點(diǎn)在單機(jī)/單核上是浪費(fèi)時(shí)間和浪費(fèi)空間的操作，例如無副作用、不可變（immutable），我尤其不太理解為什么一個(gè)容器（例如List），改變其中一個(gè)元素，就需要生成一個(gè)新的不可變?nèi)萜?#xff0c;這在命令式語言（例如C）的思路里是多么的浪費(fèi)空間和時(shí)間。不過，不可變和無副作用卻也帶來了另外的好處：1）不可變：節(jié)約了多核和多線程訪問臨界區(qū)的鎖資源；2）無副作用：節(jié)約了重復(fù)計(jì)算相同參數(shù)函數(shù)的資源。并且這種好處在硬件越來越廉價(jià)，更加趨向分布式/多核的環(huán)境中越發(fā)彰顯優(yōu)勢。
Lisp和C語言是編程模型中的兩座高山，其他語言都在這兩座高山之間權(quán)衡折衷。
語言設(shè)計(jì)，這是計(jì)算機(jī)科學(xué)中最有美感和純度的分支。另外感覺很熱門的數(shù)據(jù)科學(xué)（數(shù)據(jù)挖掘/機(jī)器學(xué)習(xí)）只是統(tǒng)計(jì)學(xué)在計(jì)算機(jī)里面的實(shí)現(xiàn)，是個(gè)數(shù)學(xué)工程，或者是仿生學(xué)工程，它們也具有美感，卻不夠簡單缺少純度。
一本Holden Karau著作的《Fast Data Processing With Spark》，市場上也有了中文版《Spark快速數(shù)據(jù)處理》。 基本的Spark使用介紹的挺詳細(xì)，缺點(diǎn)是Spark新版本不斷發(fā)布，導(dǎo)致書里的部分內(nèi)容或鏈接無效了，自己去克服克服看！-----------------------------
其實(shí)，不建議使用這本書。這是一本缺少內(nèi)容，又容易讓你因?yàn)閮?nèi)容過期暈頭轉(zhuǎn)向的書。還是去閱讀相關(guān)論文和Spark網(wǎng)頁吧
Hadoop MapReduce只是函數(shù)式語言到分布式環(huán)境跨出的第一步。然而函數(shù)式語言包含了許多基礎(chǔ)的先驅(qū)函數(shù)（Prelude Function），除了Map、Reduce，還有Filter、Fold、Sort、GroupBy、Join。而Spark就是函數(shù)式語言到分布式環(huán)境跨出的第二步，在分布式環(huán)境中實(shí)現(xiàn)并優(yōu)化了這些函數(shù)。
函數(shù)式編程概念
可以參考問題“什么是函數(shù)式編程思維？”
1. 無副作用（no side effects）
2. 高階函數(shù)（high-order function）
3. 閉包（closure）
4. 不可變（immutable）
5. 惰性計(jì)算（lazy evaluation）
6. 科里化（currying）
7. 模式匹配（pattern matching）
8. 后續(xù)（continuation）
9. monad
Spark相關(guān)論文
·An Architecture for Fast and General Data Processing on Large Clusters(PhD Disseration). M. Zaharia.
·Spark SQL: Relational Data Processing in Spark. Michael Armbrust, Reynold S. Xin, Cheng Lian, Yin Huai, Davies Liu, Joseph K. Bradley, XiangruiMeng, Tomer Kaftan, Michael J. Franklin, Ali Ghodsi, MateiZaharia. SIGMOD 2015. June 2015.
·GraphX: Unifying Data-Parallel and Graph-Parallel Analytics. Reynold S. Xin, Daniel Crankshaw, Ankur Dave, Joseph E. Gonzalez, Michael J. Franklin, Ion Stoica. OSDI 2014. October 2014.
·Discretized Streams: Fault-Tolerant Streaming Computation at Scale. MateiZaharia, Tathagata Das, Haoyuan Li, Timothy Hunter, Scott Shenker, Ion Stoica. SOSP 2013. November 2013.
·Shark: SQL and Rich Analytics at Scale. Reynold S. Xin, Joshua Rosen, MateiZaharia, Michael J. Franklin, Scott Shenker, Ion Stoica. SIGMOD 2013. June 2013.
·Discretized Streams: An Efficient and Fault-Tolerant Model for Stream Processing on Large Clusters. MateiZaharia, Tathagata Das, Haoyuan Li, Scott Shenker, Ion Stoica. HotCloud 2012. June 2012.
·Shark: Fast Data Analysis Using Coarse-grained Distributed Memory (demo). Cliff Engle, Antonio Lupher, Reynold S. Xin, MateiZaharia, Haoyuan Li, Scott Shenker, Ion Stoica. SIGMOD 2012. May 2012. Best Demo Award.
·Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing. MateiZaharia, Mosharaf Chowdhury, Tathagata Das, Ankur Dave, Justin Ma, Murphy McCauley, Michael J. Franklin, Scott Shenker, Ion Stoica. NSDI 2012. April 2012. Best Paper Award.
·Spark: Cluster Computing with Working Sets. MateiZaharia, Mosharaf Chowdhury, Michael J. Franklin, Scott Shenker, Ion Stoica. HotCloud 2010. June 2010.
官方文檔
1. Spark Programming Guide
靠譜的書
1. Learning Spark: Lightning-Fast Big Data Analysis http://www.amazon.com/Learning-Spark-Lightning-Fast-Data-Analysis/dp/1449358624/
2. Fast Data Processing with Spark - Second Edition http://www.amazon.com/Fast-Data-Processing-Spark-Second/dp/178439257X/
作者鏈接
Matei Zaharia
作者：董飛鏈接：https://www.zhihu.com/question/23655827/answer/29611595
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
Fei Dong | LinkedIn
&amp;amp;amp;lt;img src="https://pic3.zhimg.com/d13573f58390f67cf5a36414be3838ee_b.jpg" data-rawwidth="950" data-rawheight="694" class="origin_image zh-lightbox-thumb" width="950" data-original="https://pic3.zhimg.com/d13573f58390f67cf5a36414be3838ee_r.jpg"&amp;amp;amp;gt;
Hadoop Spark學(xué)習(xí)小結(jié)[2014版]Hadoop
Hadoop社區(qū)依然發(fā)展迅速，2014年推出了2.3，2.4, 2.5 的社區(qū)版本，比如增強(qiáng) Resource Manager HA, YARN Rest API, ACL on HDFS, 改進(jìn) HDFS 的 Web UI…
Hadoop Roadmap 根據(jù)我的觀察，主要更新在Yarn，HDFS，而Mapreduce幾乎停滯了，還有一些feature 屬于安全，穩(wěn)定可靠性一方面是比較穩(wěn)定了，但也可以說是瓶頸了。
Apache Hadoop Project Members
這個(gè)是Hadoop project member and committee, 里面好多來自Hortonworks，也有不少國人上榜。
SparkSpark 介紹Spark今年大放溢彩，Spark簡單說就是內(nèi)存計(jì)算（包含迭代式計(jì)算，DAG計(jì)算,流式計(jì)算 ）框架，之前MapReduce因效率低下大家經(jīng)常嘲笑，而Spark的出現(xiàn)讓大家很清新。
-
Reynod 作為Spark核心開發(fā)者, 介紹Spark性能超Hadoop百倍，算法實(shí)現(xiàn)僅有其1/10或1/100
-
淺談Apache Spark的6個(gè)發(fā)光點(diǎn)
-
Spark: Open Source Superstar Rewrites Future of Big Data
-
Spark is a really big deal for big data, and Cloudera gets it
其實(shí)起名字也很重要，Spark就占了先機(jī)，CTO說Where There’s Spark There’s Fire: The State of Apache Spark in 2014
Spark 起源2010年Berkeley AMPLab，發(fā)表在hotcloud 是一個(gè)從學(xué)術(shù)界到工業(yè)界的成功典范，也吸引了頂級VC：Andreessen Horowitz的 注資
AMPLab這個(gè)實(shí)驗(yàn)室非常厲害，做大數(shù)據(jù)，云計(jì)算，跟工業(yè)界結(jié)合很緊密，之前就是他們做mesos，hadoop online, crowddb, Twitter，Linkedin等很多知名公司都喜歡從Berkeley找人，比如Twitter也專門開了門課程 Analyzing Big Data with Twitter 還有個(gè)BDAS (Bad Ass)引以為傲: The lab that created Spark wants to speed up everything, including cures for cancer
在2013年，這些大牛從Berkeley AMPLab出去成立了Databricks，半年就做了2次summit參會1000人，引無數(shù)Hadoop大佬盡折腰，大家看一下Summit的sponsor ，所有hadoop廠商全來了，并且各個(gè)技術(shù)公司也在巴結(jié)，cloudrea, hortonworks, mapr, datastax, yahoo, ooyala, 根據(jù)CTO說 Spark新增代碼量活躍度今年遠(yuǎn)遠(yuǎn)超過了Hadoop本身，要推出商業(yè)化產(chǎn)品Cloud。
Spark人物- Ion Stoica: Berkeley教授，AMPLab 領(lǐng)軍
- Matei Zaharia: 天才，MIT助理教授
- Reynold Xin Apache Spark開源社區(qū)的主導(dǎo)人物之一。他在UC Berkeley AMPLab進(jìn)行博士學(xué)業(yè)期間參與了Spark的開發(fā)，并在Spark之上編寫了Shark和GraphX兩個(gè)開源框架。他和AMPLab同僚共同創(chuàng)建了Databricks公司
- Andy Konwinski
- Haoyuan Li
- Patrick Wendell
- Xiangrui Meng
- Paco Nathan
- Lian Cheng
- Hossein Falaki
- Mosharaf Chowdhury
- Zongheng Yang
- Yin Huai
- Committers
目前還有一些子項(xiàng)目，比如 Spark SQL, Spark Streaming, MLLib, Graphx 工業(yè)界也引起廣泛興趣，國內(nèi)Taobao, baidu也開始使用：Powered by Spark
Apache Spark支持4種分布式部署方式，分別是Amazon EC2, standalone、spark on mesos和 spark on YARN 比如AWS
Spark Summit-
2014 Summit
-
取代而非補(bǔ)充，Spark Summit 2014精彩回顧
-
擁抱Spark，機(jī)遇無限——Spark Summit 2013精彩回顧
-
Databricks Cloud Demo 今年最叫好的demo是Dtabricks Cloud, 把Twitter上面實(shí)時(shí)收集的數(shù)據(jù)做作為machine learning素材，用類似IPython notebook，可視化呈現(xiàn)驚艷，而搭建整個(gè)sampling系統(tǒng)就花了20分鐘！
-
官方文檔
-
Databricks Blog
-
Summit Training
-
Databricks upcoming training
-
Stanford Spark Class
-
CSDN Spark專欄
10月份還有個(gè)培訓(xùn)在灣區(qū)的培訓(xùn)，只不過3天就要1500刀，看來做個(gè)講師也不錯:)
第三方項(xiàng)目- Web interactive UI on Hadoop/Spark
- Spark on cassandra
- Spark Cassandra Connector
- Calliope
- H2O + Spark
- Shark - Hive and SQL on top of Spark
- MLbase - Machine Learning research project on top of Spark
- BlinkDB - a massively parallel, approximate query engine built on top of Shark and Spark
- GraphX - a graph processing & analytics framework on top of Spark (GraphX has been merged into Spark 0.9)
- Apache Mesos - Cluster management system that supports running Spark
- Tachyon - In memory storage system that supports running Spark
- Apache MRQL - A query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop, Hama, and Spark
- OpenDL - A deep learning algorithm library based on Spark framework. Just kick off.
- SparkR - R frontend for Spark
- Spark Job Server - REST interface for managing and submitting Spark jobs on the same cluster.
-
Resilient Distributed Datasets
-
spark on yarn的技術(shù)挑戰(zhàn)
-
Hive原理與不足
-
Impala/Hive現(xiàn)狀分析與前景展望
-
Apache Hadoop: How does Impala compare to Shark
-
MapReduce：一個(gè)巨大的倒退
-
Google Dremel 原理 — 如何能3秒分析1PB
-
Isn’t Cloudera Impala doing the same job as Apache Drill incubator project?
-
Shark
-
Big Data Benchmark
-
How does Impala compare to Shark
-
EMC講解Hawq SQL性能：左手Hive右手Impala
-
Shark, Spark SQL, Hive on Spark, and the future of SQL on Spark
-
Cloudera: Impala’s it for interactive SQL on Hadoop; everything else will move to Spark
-
Databricks – an interesting plan for Spark, Shark, and Spark SQL
-
Apache Storm vs Spark Streaming
-
Apache Spark源碼走讀
如何將手中 20 多臺舊電腦，組建一臺超級計(jì)算機(jī)？修改
背景：1 手里有20多臺 臺式舊電腦，奔四 CPU 512MB 內(nèi)存，板載顯卡聲卡獨(dú)立網(wǎng)卡。2 前兩年云計(jì)算開始火，自己的學(xué)校建立了云計(jì)算中心，偶然體驗(yàn)了一下覺得很刺激，但體驗(yàn)和遠(yuǎn)程登陸沒有區(qū)別。
3 學(xué)校領(lǐng)導(dǎo)不滿足我的計(jì)算機(jī)需求，反而說都給你 20 多臺電腦了，還要新的？
4 聽過一位兩院院士的學(xué)術(shù)報(bào)告，聽到了分布式計(jì)算的概念
5 聽說 Google 機(jī)房和我的情況類似，采用舊的機(jī)器來分擔(dān)服務(wù)器壓力
問：我可否用這些破電腦來組建一臺超級計(jì)算機(jī)，當(dāng)然也不需要太強(qiáng)，做電設(shè)的軟件不卡就行。
謝謝 云計(jì)算有三個(gè)方面：
1/ 計(jì)算能力
就是cpu的速度。我看了一篇文檔說，第一代／第二代／第三代／第四代／core 處理器的性能相差不大，最主要是功耗有很大的降低。你現(xiàn)在擁有的p4是最傻的cpu，功耗大，流水線最長，計(jì)算速度慢，不支持硬件虛擬化，所以已經(jīng)沒有任何實(shí)際使用價(jià)值的
2/ 內(nèi)存
內(nèi)存大小是云計(jì)算的關(guān)鍵。一般一個(gè)節(jié)點(diǎn)怎么也得32g以上，512m的內(nèi)存塞牙縫都不夠
3/ 存儲能力
目前云計(jì)算采用sata盤能有效降低運(yùn)營成本，但是速度慢／可靠性低，因此要采用sata 6g的接口，并作底層的硬件raid. 我一般做RAID 10 BOINC（Berkeley Open Infrastructure for NetworkComputing，伯克利開放式網(wǎng)絡(luò)計(jì)算平臺）
玩這個(gè)
能效比你可以找資料算算就知道不合算了，計(jì)算機(jī)唯一可以重復(fù)利用的就是硬盤了，什么內(nèi)存，顯卡，cpu都是一代主板一代口，架構(gòu)完全不同，這些電子垃圾會有人專門回收。不是說某學(xué)生在cpu提煉出黃金嗎？我覺得這是最大利用價(jià)值了。
硬盤你有20個(gè)可以組一個(gè)磁盤陣列，速度飛快無比啊～不過功率和發(fā)熱同樣是可怕
不搞超算，搞分布式計(jì)算不行嗎？
hadoop/spark集群 樓主真是太可愛了，雖說分布式集群是一種廉價(jià)的解決方案，但廉價(jià)是和IBM小型機(jī)比較而言的。集群的單個(gè)節(jié)點(diǎn)內(nèi)存一般最少16個(gè)G，一堆奔4的機(jī)子做集群，真的不如i7 這種配置的舊電腦真不如去DIY一臺新機(jī)器，32g內(nèi)存，4核8線程i7處理器，然后開10個(gè)虛擬機(jī)。 我覺得云計(jì)算重點(diǎn)不在硬件上，而且在軟件上！ 0. 超級計(jì)算機(jī)是以科學(xué)計(jì)算（例如，每秒浮點(diǎn)數(shù)計(jì)算峰值）為評價(jià)標(biāo)準(zhǔn)的，并不是僅靠搭個(gè)集群就能實(shí)現(xiàn)的，要靠對很多cpu的重新組織，涉及到硬件架構(gòu)和指令流水線，比較底層我也不懂，總之不是簡單堆疊就行的，要不誰都可以實(shí)現(xiàn)了，題目說法不準(zhǔn)確；
1. 你說道谷歌的集群，這20臺機(jī)器配置來說搭個(gè)hadoop集群勉強(qiáng)可以，但只能跑點(diǎn)資源分發(fā)的程序（谷歌主要是用來跑爬蟲，這個(gè)不需要實(shí)時(shí)，廉價(jià)pc你要求能多高？所以徹夜的爬數(shù)據(jù)才是他們的歸宿），不適合科學(xué)計(jì)算，而且是離線的，響應(yīng)速度也慢，再說資源多了（達(dá)到TB級別）效果才明顯。 內(nèi)存是關(guān)鍵，512m跑個(gè)系統(tǒng)都勉強(qiáng)，更不要想跑什么軟件了。您所說的Google的舊電腦，一般也會配置16G以上的ECC內(nèi)存以及TB級別的硬盤。
更不要提一般基于集群的程序都是要專門寫的，當(dāng)然您也可以下載個(gè)開源的Hadoop平臺玩下。
建議題主還是把這20臺舊機(jī)器賣了買個(gè)好點(diǎn)的服務(wù)器吧。
首先，Google機(jī)房那種云計(jì)算，是通過一個(gè)轉(zhuǎn)發(fā)器，把各個(gè)請求轉(zhuǎn)發(fā)到不同的電腦上來分擔(dān)訪問壓力。
其次，你要弄的超級計(jì)算機(jī)，需要各個(gè)電腦的CPU之間能夠協(xié)同工作，這樣需要各臺電腦之間有延遲很小帶寬很大的連接。
所以，你做不了超級計(jì)算機(jī)，只能做出一些類似Web集群或者存儲集群的東東。 對對對，我就是這個(gè)意思。學(xué)校組建的云計(jì)算中心，可以在我這一端申請cpu數(shù)量，內(nèi)存大小，然后就像遠(yuǎn)程登錄一樣登陸到計(jì)算中心，用那里的matlab運(yùn)算特別爽，當(dāng)然，基于校園網(wǎng)11mb/s的極限速度。 那個(gè)是多重負(fù)載，不需要你操心。最前端有cache, 然后是DNS 負(fù)載，然后是http負(fù)載，在然后是message server，在在然后到http server， 在在在然后到application server，最后才到數(shù)據(jù)庫。 這個(gè)需求不成啊，目前的虛擬主機(jī)技術(shù)有限制的，就是CPU和內(nèi)存需求，不能高于單體宿主的最大值。即如果宿主的集群里，最大單臺只有8核的機(jī)器，那你生成的虛擬主機(jī)也最大只能到8核了。。不過我這是2年前的老知識了，現(xiàn)在有突破也說不定。但如果那么新的技術(shù)，可定不支持P4的CPU了。。所以請放棄吧。。 首先，明確需求。你組建一個(gè)分布式網(wǎng)絡(luò)到底是用來干嘛？
其次，構(gòu)建測試平臺。你看看你要解決的問題是否可以被拆分多個(gè)任務(wù)，是否存在計(jì)算損耗。是否可以估算出計(jì)算成本。
再次，進(jìn)行風(fēng)險(xiǎn)預(yù)估，看看這件事做了，技術(shù)上最大的風(fēng)險(xiǎn)是什么？增加了哪些難題？是否劃得來？
然后，在動手。
唉，想當(dāng)年沒錢，用了接近100臺PC，搞了個(gè)sun grid EDA計(jì)算農(nóng)場，真的很慘呀！ 才疏學(xué)淺，基于我目前對于超級計(jì)算機(jī)的需求是軟需求，我的思路是在諸位大神的問答中，找到一個(gè)可行性（經(jīng)濟(jì)、時(shí)間）的方案，自己嘗試著去探索，自己先爽，然后找朋友爽，最后在全校范圍內(nèi)吹牛逼。嘿嘿。 現(xiàn)在的并行計(jì)算技術(shù)，即使是業(yè)界最前沿的Spark, Hadoop YARN等也只能對特定的計(jì)算任務(wù)進(jìn)行并行化。這里說的特定任務(wù)主要指的是，可以拆解并行化的任務(wù)，而且這個(gè)“拆解”也是需要人工進(jìn)行。像題主說的“做電設(shè)的軟件”對于并行計(jì)算是非常復(fù)雜的一項(xiàng)任務(wù)，即使能進(jìn)行并行化，人工的費(fèi)用也是極不劃算的。
人家云起來都是e3起了，一臺e5可能都爆一百個(gè)樓主的u了，樓上那些說用i7的，什么心態(tài)…你這樣組裝起來不過是二十個(gè)vps而已，人家一臺機(jī)器虛擬出來，你就直接實(shí)體機(jī)，其實(shí)這些都不是重點(diǎn)，重點(diǎn)是什么用途，儲存？你不組個(gè)raid好意思，就那些機(jī)器的硬盤…還是做數(shù)據(jù)處理，模型分析和視頻渲染之類的？這個(gè)事…i3都玩不起啊，呵呵。綜上所述，樓主還是跟校長要2-5w的預(yù)算，購買兩三臺e5 內(nèi)存32g 硬盤4t + ssd,然后用一些虛擬技術(shù)，vmvere,xen都可以，起碼可以開幾百個(gè)像樓主這樣性能的虛擬機(jī)，不要以為這不是云，這就是，阿里云都是這么干的，他的虛擬化技術(shù)就是xen的，只不過你是兩臺，人家是幾百臺，其實(shí)云這些都是一些yy出來的東西，云這個(gè)模式10年前就有了，但是這個(gè)概念就最近一兩年才火。有什么問題可以跟我的帖子。
可是事實(shí)上，云你認(rèn)為的云，到底應(yīng)該給你怎么操作，你又會在上面做什么呢？我說的云都是大部分idc認(rèn)可的云，狹義的云，其實(shí)就是一臺虛擬出來的電腦而已，你可以做自己電腦做不到的一些事情，比如說儲存，數(shù)據(jù)處理，用戶交互。如果你覺得要廣意來說，那么整個(gè)互聯(lián)網(wǎng)都是云，云中的你向知乎的服務(wù)器發(fā)送了數(shù)據(jù)，知乎給你存起來了，難道不是云在操作嗎。當(dāng)然，你如果要說是分布計(jì)算才是云，那么多少臺算一個(gè)云，難道你真的以為會有真的n臺電腦為你一個(gè)人服務(wù)嗎，還是說，要一臺電腦服務(wù)n個(gè)人？ 為之前也有類似的想法，所以研究云計(jì)算。以為云計(jì)算就可以把多個(gè)計(jì)算機(jī)組成一個(gè)牛逼的服務(wù)器。搭建好openstack之類的平臺之后才發(fā)現(xiàn)，原來不是做這個(gè)的。郁悶啊。研究了好久。 做成超級計(jì)算機(jī)當(dāng)然不可行，但是簡單做成集群（Cluster）是可行的。實(shí)際上國外一些中小型研究項(xiàng)目都是在幾十個(gè)CPU的集群上運(yùn)算的。國內(nèi)航空研究領(lǐng)域以前沒有超算，都是自己用十幾臺、幾十臺臺式機(jī)搭集群來進(jìn)行大規(guī)模運(yùn)算。不過需要注意的是，這樣搭建集群需要自己特別編制軟件，并不能讓一般的辦公軟件之類快速運(yùn)行。編制這類軟件對個(gè)人編程能力以及對硬件的理解都要求很高。如果你有能力編這個(gè)軟件，還不如把專業(yè)技能放到有實(shí)際價(jià)值的方面。總之就不要白非這個(gè)力氣了。
對！當(dāng)年成都那個(gè)人造太陽，也就是20臺P4的群集而已！ASUS的板子+3COM的交換， 私有云這東西，名曰節(jié)能環(huán)保高效容錯易管理降成本，實(shí)際就倆字：“燒錢”。
不說別的，硬件：服務(wù)器+存儲，就算測試用也得十來萬吧，如果提供服務(wù)就慢慢乘10往上加；
軟件…各大廠商都盯著呢，按核心收費(fèi)，按功能模塊收費(fèi)，按服務(wù)收費(fèi)，只要能收費(fèi)的方法都被想絕了。
后面是各應(yīng)用系統(tǒng)及數(shù)據(jù)庫的遷移部署（說是零難度遷移，實(shí)際應(yīng)用時(shí)大家都懂的，購買白金服務(wù)吧）、基礎(chǔ)網(wǎng)絡(luò)交換的設(shè)備更新（說不定要優(yōu)化拓?fù)?#xff0c;繼續(xù)購買服務(wù)）、操作員的培訓(xùn)（還是買服務(wù)），如果牽扯分/等級保護(hù)，還要重新評估信息系統(tǒng)安全性（郭嘉的服務(wù)，貴）。
為了省錢還是別弄這個(gè)了…申課題倒是可以考慮，只說技術(shù)優(yōu)化別提節(jié)能減排…
對了，聽說Google機(jī)房的服務(wù)器是批量定制的x86機(jī)器，從邏輯性能到物理硬件都高度標(biāo)準(zhǔn)化，所以納入云平臺管理不算太費(fèi)力。題主提到的20臺PC組一起，能不能實(shí)現(xiàn)云的部署真不好說，在怎么說，云也是個(gè)操作系統(tǒng)，也是挑硬件的。
主要是是看你的需求
很明顯，你所提到的學(xué)校領(lǐng)導(dǎo)在智商、誠實(shí)和友愛三者之中最多只擁有一樣，而且很有可能三者都缺。
下圖是P4 3.0GHz CPU同其他目前常見的中高端CPU的計(jì)算性能比較（CPU Mark），就算你花了九牛二虎之力把這20多個(gè)CPU組裝到一起，并且奇跡般地沒有任何通訊開銷和效率損失，這20多臺計(jì)算機(jī)的計(jì)算能力也只有勉強(qiáng)達(dá)到一個(gè)i7-2600主機(jī)的水平。某寶告訴我這種主機(jī)目前大約價(jià)錢4000元。
&lt;img src="https://pic4.zhimg.com/40ed9b3c2a9d6df569138f9cc0baf25b_b.jpg" data-rawwidth="520" data-rawheight="314" class="origin_image zh-lightbox-thumb" width="520" data-original="https://pic4.zhimg.com/40ed9b3c2a9d6df569138f9cc0baf25b_r.jpg"&gt;
如果這種“超級計(jì)算機(jī)”是你追求的目標(biāo)，或者你希望通過這樣一個(gè)活動來提高自己對并行計(jì)算的認(rèn)識，不妨玩玩。否則我能給的最好的建議就是——把所有機(jī)器放淘寶上一個(gè)200賣掉，賺到的5000元錢買一個(gè)性能強(qiáng)勁新的主機(jī)回來。 http://www.cpubenchmark.net/ 9月份，學(xué)院集中報(bào)廢物資，按理說這些電腦可以申請報(bào)廢了。可我不再負(fù)責(zé)這些事情了。上周過去看電腦還在，已經(jīng)down了一半了。 在其位謀其政，我不在負(fù)責(zé)這個(gè)位置了，這個(gè)夢想也落空了。 心中的超級計(jì)算機(jī)被我手上的mbpr取代了。玩兒lol別人度條10%的時(shí)候我就完成了，至少在開局之前就能給對面威懾了。 嘗試去說服你領(lǐng)導(dǎo)吧，不然后面有的麻煩。畢竟計(jì)算機(jī)硬件的淘汰速度（摩爾定律，18月便宜一半）比其他東西（如家具）快很多。按照你領(lǐng)導(dǎo)那觀念，你們估計(jì)要一直停留在準(zhǔn)石器時(shí)代。 還有一點(diǎn)。Google云計(jì)算的應(yīng)用場景是大量簡單任務(wù)，如搜索，這類任務(wù)可以分配給性能較差的節(jié)點(diǎn)，所以Google可以用老電腦。這種架構(gòu)與超級計(jì)算機(jī)（如高性能計(jì)算平臺）還是不同的。 現(xiàn)在i7的確性能有p4的20倍了，但僅限多任務(wù)。
單任務(wù)也至少有5倍以上，比如100萬PI計(jì)算，p4 2.0差不多80s，3.0差不多55-60s，據(jù)說玩死里超，超冒煙可以30s。i7的話10s不難達(dá)成，8s也早就有了，i7的極限我想6s應(yīng)該是問題不大的。
你再想一下，i7最高是有6核的。
所以20倍問題不大。
最后，現(xiàn)在的四通道內(nèi)存速度是p4時(shí)代的DDR2的10倍并非難事（但是內(nèi)存不是瓶頸，根據(jù)跑分，四通道和三通道，雙通道差距不大，但是和單通道差距較大），SSD硬盤速度過500都是常事，p4時(shí)期的機(jī)械硬盤基本上都是并口硬盤，我沒記錯當(dāng)年是ATA-33，ATA-66，ATA-100，ATA-133一路升級過來的。sata-133的極限傳輸速度也只有133mb/s。
現(xiàn)在的計(jì)算機(jī)是當(dāng)年的20倍，并非妄言。 難度并不大，只是如第一名的答案所說的那樣，性能會非常非常爛。不用像第二名的答案那么麻煩。
你只需要：
1：用一個(gè)路由器把它們連在一起（不用太高速，反正這些電腦也很爛）。
2：每臺電腦裝個(gè)debian吧。應(yīng)當(dāng)只有一臺裝GUI就行。你不妨裝Xfce或者LXDE桌面，比較省。
3：看看mpich的文檔，把這些機(jī)器配上MPI的環(huán)境。
4：自己編MPI玩去吧！！
[圖]美大學(xué)生自制廉價(jià)桌面超級計(jì)算機(jī)
新聞鏈接里有詳細(xì)說明：
制作者Tim Brom在自己的主頁里給出了詳細(xì)的制作方法,有興趣的可以自己試著制作一下
相關(guān)連接:
http://www.calvin.edu/~adams/research/microwulf/
http://www.clustermonkey.net//content/view/211/1/
硬件清單
Microwulf: Hardware Manifest
作者：feemung
鏈接：https://www.zhihu.com/question/21116669/answer/18864330
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
請不要嘲笑別人的想法，老外已經(jīng)實(shí)現(xiàn)了四臺電腦的計(jì)算集群，題主20臺也應(yīng)該是可以實(shí)現(xiàn)的。這個(gè)資料是英文，我找到了部分中文資料，粗略地瀏覽了一遍，應(yīng)該是可以實(shí)現(xiàn)的，但是細(xì)節(jié)部分沒看明白，求高人翻譯資料。（不好意思，我剛才發(fā)現(xiàn)和@高超 的回答撞車了，不過，這些資料確實(shí)是在我沒看他的資料之前自己搜索出來的，嘿嘿，大家就當(dāng)他回答的補(bǔ)充好了）。知乎里的大神真多，呵呵，以后得好好看回答
資料地址如下 官方網(wǎng)址 Microwulf: A Personal, Portable Beowulf Cluster
中文翻譯的資料地址如下【個(gè)人小超算】實(shí)戰(zhàn)資料匯編
先上張圖片震撼一下大家
&lt;img data-rawheight="600" data-rawwidth="800" src="https://pic1.zhimg.com/65efd8304d9fda0155d7c416fc630bb4_b.jpg" class="origin_image zh-lightbox-thumb" width="800" data-original="https://pic1.zhimg.com/65efd8304d9fda0155d7c416fc630bb4_r.jpg"&gt;&lt;img data-rawheight="600" data-rawwidth="800" src="https://pic3.zhimg.com/36b1ffece1a83b536838cb4e9bab5cd2_b.jpg" class="origin_image zh-lightbox-thumb" width="800" data-original="https://pic3.zhimg.com/36b1ffece1a83b536838cb4e9bab5cd2_r.jpg"&gt;&lt;img data-rawheight="600" data-rawwidth="800" src="https://pic4.zhimg.com/0a60bf8a4aec5cb4604e40b71f2c38f7_b.jpg" class="origin_image zh-lightbox-thumb" width="800" data-original="https://pic4.zhimg.com/0a60bf8a4aec5cb4604e40b71f2c38f7_r.jpg"&gt;&lt;img data-rawheight="600" data-rawwidth="800" src="https://pic1.zhimg.com/7bf373350a01c13311ec57ba6f093524_b.jpg" class="origin_image zh-lightbox-thumb" width="800" data-original="https://pic1.zhimg.com/7bf373350a01c13311ec57ba6f093524_r.jpg"&gt;以下是我找到中文翻譯資料，我是直接復(fù)制的，沒能把圖片等復(fù)制過來，大家就湊合看吧，也可以看上面那個(gè)中文資料的網(wǎng)站以下是我找到中文翻譯資料，我是直接復(fù)制的，沒能把圖片等復(fù)制過來，大家就湊合看吧，也可以看上面那個(gè)中文資料的網(wǎng)站
個(gè)人電腦陣列
一、作者簡介：
喬爾 亞當(dāng)斯 （Joel Adams）是卡爾文學(xué)院（Calvin College）計(jì)算機(jī)科學(xué)（computer science）教授，1988年獲得在匹次堡大學(xué)獲得博士學(xué)位，主要研究超算的內(nèi)部連接，是幾本計(jì)算機(jī)編程教材的作者，兩次獲得Fulbright Scholar (毛里求斯1998, 冰島 2005).
緹姆 布倫姆（Tim Brom）是卡耐基大學(xué)計(jì)算機(jī)科學(xué)的研究生，2007年五月在卡爾文學(xué)院獲得計(jì)算機(jī)科學(xué)學(xué)士學(xué)位。
二、說明：
此小超算擁有超過260億次的性能，價(jià)格少于2500美元，重量少于31磅，外觀規(guī)格為11" x 12" x 17"——剛好夠小，足夠放在桌面上或者柜子里上,
更新：2007年8月1日，這個(gè)小超算已經(jīng)可以用1256美元構(gòu)建成，使得其性價(jià)比達(dá)到4.8美元/億次——這樣的話，可以增加更多的芯片，以提升性能，讓其更接近21世紀(jì)初的超算性能。
此小超算是由卡爾文大學(xué)的計(jì)算機(jī)系統(tǒng)教授喬爾 亞當(dāng)斯和助教 緹姆 布倫姆設(shè)計(jì)和構(gòu)建。下面是原文的目錄，可點(diǎn)擊查看：
- 設(shè)計(jì)
- 硬件信息
- 軟件系統(tǒng)構(gòu)建說明
- 效果圖片
- 性能
- 計(jì)算效率
- 價(jià)格效率
- 功耗
- 新聞報(bào)道
- 相關(guān)系統(tǒng)
三、介紹
作為一個(gè)典型的超算用戶，我需要到計(jì)算中心排隊(duì)，而且要限定使用的計(jì)算資源。這個(gè)對于開發(fā)新的分布式軟件來說，很麻煩。所以呢，我需要一個(gè)自己 的，我夢想中的小超算是可以小到放在我的桌面上，就像普通個(gè)人電腦一樣。只需要普通的電源，不需要特殊的冷切裝置就可以在室溫下運(yùn)行……2006年末, 兩個(gè)硬件發(fā)展，讓我這個(gè)夢想接近了現(xiàn)實(shí)：
2006年秋天, 卡爾文學(xué)院計(jì)算機(jī)系給了我們一筆小錢——就是2500美元，去構(gòu)建這么一個(gè)系統(tǒng)，我們當(dāng)時(shí)設(shè)定的目標(biāo)：
- 費(fèi)用少于2500美元——這樣一般人都能負(fù)擔(dān)得起，可以促進(jìn)普及。
- 足夠小，適合放在我的桌面上，適合放到旅行箱里。
- 要夠輕，可以手提，然后帶到我的汽車?yán)铩?/li>
- 性能強(qiáng)勁，測試結(jié)果至少要200億次：
- 用于個(gè)人研究,
- 用于我教授的高性能運(yùn)算課程,
- 用于專業(yè)論壇講授、高中講演等,
- 只需要一根電源線，使用普通的120伏電源。
- 可在室溫下運(yùn)行。
據(jù)我們當(dāng)時(shí)所知，已經(jīng)有一些小型的超算，或者是性價(jià)比不錯的超算出現(xiàn)，這些東西給了我們很好的參考：
- Little Fe
- The Ultimate Linux Lunchbox
下面是歷年的性價(jià)比之王：
- 2005: Kronos
- 2003: KASY0
- 2002: Green Destiny
- 2001: The Stone Supercomputer
- 2000: KLAT2
- 2000: bunyip
- 1998: Avalon
在同一時(shí)間，還有其他更廉價(jià)或者是更具性價(jià)比的超算集群，不過這些記錄都在2007年被改變了，最具性價(jià)比的就是下文介紹的小超算（2007年一月，9.41美元/億次），而其記錄半年后就被打破（2007年8月 4.784美元/億次）。
架構(gòu)設(shè)計(jì)：
個(gè)人小超算一般做法是使用多核芯片，集中安裝到一個(gè)小的空間里，集中供電——嗯，如果能自己燒制主板，體積上應(yīng)該可以做得更小——樹莓派的主板體積很小，就是芯片不給力，所以需要那么多片才能達(dá)到2007年用普通電腦芯片實(shí)現(xiàn)的性能。
1960年代末，吉恩 庵達(dá)郝樂（Gene Amdahl）提出了一個(gè)設(shè)計(jì)準(zhǔn)則，叫 "庵達(dá)赫樂法則"（Amdahl's Other Law），大意是：
為了兼容性考慮， 下面幾個(gè)特性應(yīng)該相同：- 每片芯片的頻率
- 每根內(nèi)存大小
- 每處帶寬
高性能計(jì)算一般有三個(gè)瓶頸：芯片運(yùn)算速度，運(yùn)算所需內(nèi)存，吞吐帶寬。本小超算里面，帶寬主要是指網(wǎng)絡(luò)帶寬。我們預(yù)算是2500美元，在設(shè)定了每核內(nèi)存量，每核的帶寬之后，其中芯片運(yùn)算速度當(dāng)然是越快越好。
內(nèi)部使用千兆網(wǎng)絡(luò)（GigE），則意味著我們的帶寬只有1Gbps，如果要更快的，可以使用比如Myrinet，不過那會超預(yù)算了，此處核心1吉赫茲+每核1吉B內(nèi)存+1吉bps，嗯，看起來比較完美，哈哈。最終決定是2.0GHz的雙核芯片，每核1GB內(nèi)存
芯片，使用AMD Athlon 64 X2 3800 AM2+ CPUs. 2007年一月時(shí)每片價(jià)格$165 ，這種2.0GHz的雙核芯片，是當(dāng)時(shí)可以找到的性價(jià)比最好的。 (2007年8月就更便宜了，每片只有$65.00).
為了盡量減少體積，主板選用的是MSI Micro-ATX。此主板特點(diǎn)是小(9.6" by 8.2") ，并且有一個(gè)AM2 socket，可支持AMD的Athlon多核芯片。其實(shí)如果有條件的話，更應(yīng)該做的是使用AMD的四核Athlon64 CPU替代這個(gè)雙核，而這系統(tǒng)恰好還不用改。
To do so, we use motherboards with a smaller form-factor (like Little Fe) than the usual ATX size, and we space them using threaded rods (like this cluster) and scrap plexiglass, to minimize "packaging" costs.
By building a "double decker sandwich" of four microATX motherboards, each with a dual core CPU and 2 GB RAM (1 GB/core), we can build a 4-node, 8-core, 8GB multiprocessor small enough to fit on one's desktop, powerful enough to do useful work, and inexpensive enough that anyone can afford one.
此 主板上已經(jīng)嵌有一個(gè)千兆網(wǎng)卡，還有一個(gè)PCI-e擴(kuò)展插槽，在PCI-e插槽插入另一根網(wǎng)卡（41美元），用于平衡芯片運(yùn)算速度和網(wǎng)絡(luò)帶寬。這樣，四塊主 板總共就有內(nèi)嵌的4個(gè)網(wǎng)卡，外加PCI-e插槽的4張網(wǎng)卡，一共8個(gè)網(wǎng)絡(luò)通道，用網(wǎng)線把它們都連接到8口路由器（100美元）上。
Our intent was to provide sufficient bandwidth for each core to have its own GigE channel, to make our system less imbalanced with respect to CPU speed (two x 2 GHz cores) and network bandwidth (two x 1 Gbps adaptors). This arrangement also let us experiment with channel bonding the two adaptors, experiment with HPL using various MPI libraries using one vs two NICs, experiment with using one adaptor for "computational" traffic and the other for "administrative/file-service" traffic, and so on.)
每塊主板插了兩根內(nèi)存，共2G，這8G內(nèi)存消耗了預(yù)算的40%！！
為了更小化，本小超算沒有使用機(jī)箱，而是一個(gè)完全非封閉的外架，像Little Fe 和 這些集群，把主板直接安裝到有機(jī)玻璃上面，然后用幾根小鐵桿撐起來，并連接成一立體狀。——（這個(gè)架子一般的五金店應(yīng)該可以制造，用導(dǎo)熱性好的鋁/鐵當(dāng)托盤，整機(jī)的熱分布會好點(diǎn)，也有利于集中散熱）
最底部是兩片有機(jī)玻璃隔開的一個(gè)夾層，放著8口路由，光驅(qū)，還有250GB的硬盤。
結(jié)構(gòu)圖如下：
&lt;img data-rawheight="311" data-rawwidth="452" src="https://pic2.zhimg.com/836f990c77a27c0c7fe90f4808eaabed_b.jpg" class="origin_image zh-lightbox-thumb" width="452" data-original="https://pic2.zhimg.com/836f990c77a27c0c7fe90f4808eaabed_r.jpg"&gt;我們這小超算的硬件結(jié)構(gòu)
如圖所示，主板放在最頂層的下方，而中間層則兩面都放主板，底層則上方放主板，這樣做的目的是盡可能減少高度。
Since each of our four motherboards is facing another motherboard, which is upside-down with respect to it, the CPU/heatsink/fan assembly on one motherboard lines up with the PCI-e slots in the motherboard facing it. As we were putting a GigE NIC in one of these PCI-e slots, we adjusted the spacing between the Plexiglas pieces so as to leave a 0.5" gap between the top of the fan on the one motherboard and the top of the NIC on the opposing motherboard. 這樣的結(jié)果就是每塊主板間的間距為6"，如圖所示：
主板之間的距離
(說明：這些主板都有一個(gè)單獨(dú) PCI-e x16插槽，留給以后想提升性能的時(shí)候，可以插上一塊GPU）
使用350瓦的電源供電（每塊主板一個(gè)），使用雙面膠固定在有機(jī)玻璃上，電源插座放在最上面的有機(jī)玻璃上，如圖所示：
本小超算的電源和風(fēng)扇
(此處用膠水固定硬盤、光驅(qū)、路由器)
最靠近夾層的底部主板作為“主節(jié)點(diǎn)”——主控主板，連接硬盤、光驅(qū)（可選）等，系統(tǒng)啟動/關(guān)機(jī)/重啟的時(shí)候也是從這個(gè)部分操作。其他的主板當(dāng)作“分支節(jié)點(diǎn)”，使用PXE網(wǎng)絡(luò)啟動方式啟動。
對最底部的主控主板做特殊設(shè)置，連接250GB硬盤，并且作為啟動分區(qū)。插入光驅(qū)（主要是用于安裝初始系統(tǒng)，現(xiàn)在都不需要了，直接用優(yōu)盤做系統(tǒng)安裝盤吧……）插入另一塊網(wǎng)卡10/100 NIC到PCI插槽中，用于連接外部網(wǎng)絡(luò)。
頂部三個(gè)節(jié)點(diǎn)都是無硬盤的， and used NFS to export the space on the 250 GB drive to them。
下圖顯示了本小超算各個(gè)部分的連接關(guān)系（節(jié)點(diǎn)0為重心，連接了硬盤、光驅(qū)、以及連接外部的接口，內(nèi)部中心為千兆路由，用于連接其他節(jié)點(diǎn)）：
&lt;img data-rawheight="134" data-rawwidth="420" src="https://pic3.zhimg.com/fe70dd27a5e704552c7b255a815845da_b.jpg" class="content_image" width="420"&gt;說明：每個(gè)節(jié)點(diǎn)都有兩條獨(dú)立的通訊線路，連接自己和網(wǎng)絡(luò)路由器。
With four CPUs blowing hot air into such a small volume, we thought we should keep the air moving through Microwulf. To accomplish this, we decided to purchase four Zalman 120mm case fans ($8 each) and grills ($1.50 each). Using scavenged twist-ties, we mounted two fans -- one for intake and one for exhaust -- on opposing sides of each pair of facing motherboards. This keeps air moving across the boards and NICs; Figure Five shows the two exhaust fans:
Figure Five: Two of Microwulf's (Exhaust) Fans
So far, this arrangement has worked very well: under load, the on-board temperature sensors report temperatures about 4 degrees above room temperature.
Last, we grounded each component (motherboards, hard drive, etc.) by wiring them to one of the power supplies.
系統(tǒng)使用的是有奔頭（Ubuntu Linux）.
開源通用信道（Open MPI）將自動識別每個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)適配器，并讓它們之間組成一個(gè)圓環(huán)型的信息交流系統(tǒng)。 To try to help Open MPI spread the load on both the sending and receiving side, we configured the on-board adaptors to be part of a 192.168.2.x subnet, and the PCI-e adaptors to be part of a 192.168.3.x subnet.價(jià)格參考（2007年一月）：
部件
產(chǎn)品名稱
單價(jià)
數(shù)量
總價(jià)
主板 微星 K9N6PGM-F MicroATX $80.00 4 $320.00 芯片
威盛Athlon 64 X2 3800+ AM2 CPU $165.00 4 $660.00 內(nèi)存 金士頓 DDR2-667 1GByte RAM $124.00 8 $992.00 電源 Echo Star 325W MicroATX Power Supply $19.00 4 $76.00 網(wǎng)卡 Intel PRO/1000 PT PCI-Express NIC (節(jié)點(diǎn)連接路由) $41.00 4 $164.00 網(wǎng)卡 Intel PRO/100 S PCI NIC (主控主板連接外部網(wǎng)絡(luò)) $15.00 1 $15.00 路由器 Trendware TEG-S80TXE 8-port Gigabit Ethernet Switch $75.00 1 $75.00 硬盤 希捷7200轉(zhuǎn) 250GB SATA硬盤 $92.00 1 $92.00 光驅(qū) Liteon SHD-16S1S 16X $19.00 1 $19.00 冷切系統(tǒng) Zalman ZM-F3 120mm Case Fans $8.00 4 $32.00 風(fēng)扇 Generic NET12 Fan Grill (120mm) $1.50
+ shipping 4 $10.00 硬件支架 36" x 0.25" threaded rods $1.68 3 $5.00 硬件固定 Lots of 0.25" nuts and washers $10.00 機(jī)箱或外殼
12" x 11" 有機(jī)玻璃(是我們物理實(shí)驗(yàn)室的廢品) $0.00 4 $0.00 總價(jià)
$2,470.00
非必須的硬件
部件產(chǎn)品名稱
單價(jià)
數(shù)量 總價(jià) KVM Switch Linkskey LKV-S04ASK $50.00 1 $50.00 總價(jià)
$50.00
除了技術(shù)支持還有硬件加固 (購買自Lowes), 風(fēng)扇和轉(zhuǎn)接器購買自 newegg.com, 其他都購買自（量多有折扣，呵呵）：
N F P Enterprises
1456 10 Mile Rd NE
Comstock Park, MI 49321-9666
(616) 887-7385
So we were able to keep the price for the whole system to just under $2,500. That's 8 cores with 8 GB of memory and 8 GigE NICs for under $2,500, or about $308.75 per core.
構(gòu)建配置：
點(diǎn)擊此處：軟件系統(tǒng)構(gòu)建說明，有詳細(xì)的介紹文件下載——建議想自己構(gòu)建的人下載下來，然后按照其說明，逐步完成。
細(xì)節(jié)是魔鬼
首先是選用哪個(gè)你牛叉發(fā)行版：曾經(jīng)一度使用Gentoo，但后來覺得gentoo太消耗能量了（包括系統(tǒng)管理員的精力和系統(tǒng)的耗電），后來 試了試有奔頭，一開始安裝的桌面是6.10版本，其內(nèi)核是2.6.17，但美中不足的是he on-board NIC的驅(qū)動需要到2.6.18才內(nèi)置，所以一開始兩個(gè)月，我們的小超算就用的7.04的測試版（內(nèi)核是2.6.20），直到最后穩(wěn)定版發(fā)行就換了穩(wěn)定 版。
在其他三個(gè)計(jì)算節(jié)點(diǎn)上，安裝的是有奔頭的服務(wù)器版，因?yàn)樗鼈儾恍枰烂婀δ堋?br />也就是：有奔頭桌面版+3個(gè)有奔頭服務(wù)器版
我們也試過其他的集群管理軟件：ROCKS, Oscar, 和 Warewulf.，但ROCKS和Oscar不支持無盤的節(jié)點(diǎn)。Warewulf工作良好，但因?yàn)楸拘〕銓?shí)在太小，目前看不出其優(yōu)勢來。因?yàn)檫@篇論文，曾經(jīng)想使用iSCSI。不過為了盡快讓我們的集群運(yùn)行起來，還是決定使用NFSroot，因?yàn)槠渑渲梅浅：唵?#xff0c;只需要修改/etc/initramfs.conf ，讓其生成一個(gè)虛擬內(nèi)存（initial ramdisk） that does NFSroot and then setting up DHCP/TFTP/PXELinux on the head node, as you would for any diskless boot situation.
We did configure the network adaptors differently: we gave each onboard NIC an address on a 192.168.2.x subnet, and gave each PCI-e NIC an address on a 192.168.3.x subnet. Then we routed the NFS traffic over the 192.168.2.x subnet, to try to separate "administrative" traffic from computational traffic. It turns out that OpenMPI will use both network interfaces (see below), so this served to spread communication across both NICs.
One of the problems we encountered is that the on-board NICs (Nvidia) present soem difficulties. After our record setting run (see the next section) we started to have trouble with the on-board NIC. After a little googling, we added the following option to the forcedeth module options:
forcedeth max_interrupt_work=35The problem got better, but didn't go away. Originally we had the onboard Nvidia GigE adaptor mounting the storage. Unfortunately, when the Nvidia adaptor started to act up, it reset itself, killing the NFS mount and hanging the "compute" nodes. We're still working on fully resolving this problem, but it hasn't kept us from benchmarking Microwulf.
效果圖：直接點(diǎn)擊上面目錄連接，可查看
性能表現(xiàn)：
所獲得的性能表現(xiàn)
Once Microwulf was built and functioning it's fairly obvious that we wanted to find out how 'fast' it was. Fast can have many meanings, depending upon your definition. But since the HPL benchmark is the standard used for the Top500 list, we decided to use it as our first measure of performance. Yes, you can argue and disagree with us, but we needed to start somewhere.
We installed the development tools for Ubuntu (gcc-4.1.2) and then built both Open MPI and MPICH. Initially we used OpenMPI as our MPI library of choice and we had both GigE NICs configured (the on-board adaptor and the Intel PCI-e NIC that was in the x16 PCIe slot).
Then we built the GOTO BLAS library, and HPL, the High Performance Linpack benchmark.The Goto BLAS library built fine, but when we tried to build HPL (which uses BLAS), we got a linking error indicating that someone had left a function named main() in a module named main.f in /usr/lib/libgfortranbegin.a. This conflicted with main() in HPL. Since a library should not need a main() function, we used ar to remove the offending module from /usr/lib/libgfortranbegin.a, after which everything built as expected.
Next, we started to experiment with the various parameters for running HPL - primarily problem size and process layout. We varied PxQ between {1x8, 2x4}, varied NB between {100, 120, 140, 160, 180, 200}, and used increasing values of N (problem size) until we ran out of memory. As an example of the tests we did, Figure Six below is a plot of the HPL performance in GFLOPS versus the problem size N.
Figure Six: Microwulf Results for HPL WR00R2R24 (NB=160)
For Figure Six we chose PxQ=2x4, NB=160, and varied N from a very small number up to 30,000. Notice that above N=10,000, Microwulf achieves 20 GLFOPS, and with N greater than 25,000, it exceeds 25 GFLOPS. Anything above N=30,000 produced "out of memory" errors.
We did achieve a peak performance of 26.25 GFLOPS. The theoretical peak performance for Microwulf is 32 GLFOPS. (Eight cores x 2 GHz x 2 double-precision units per core.) This means we have hit about 82% efficiency (which we find remarkable). Note that one of the reasons we asume that we achieved such a high efficiency is due to Open MPI, which will use both GigE interfaces. It will round-robin data transfers over the various interfaces unless you explicitly tell it to just use certain interfaces.
It's important to note that this performance occurred using the default system and Ethernet settings. In particular, we did not tweak any of Ethernet parameters mentioned in Doug Eadline and Jeff Layton's article on cluster optimization. We were basically using "out of the box" settings for these runs.
To assess how well our NICs were performing, Tim did some followup HPL runs, and used netpipe to gauge our NICs latency. Netpipe reported 16-20 usecs (microseconds) latency on the onboard NICs, and 20-25 usecs latency on the PCI-e NICs, which was lower (better) than we were expecting.
As a check on performance we also tried another experiment. We channel bonded the two GigE interfaces to produce, effectively, a single interface. We then used MPICH2 with the channel bonded interface and used the same HPL parameters we found to be good for Open-MPI. The best performance we achieved was 24.89 GLOPS (77.8% efficiency). So it looks like Open MPI and multiple interfaces beats MPICH2 and a bonded interface.
Another experiment we tried was to use Open MPI and just the PCI-e GigE NIC. Using the same set of HPL parameters we have been using we achieved a performance of 26.03 GFLOPS (81.3% efficiency). This is fairly close to the performance we obtained when using both interfaces. This suggests that the on-board NIC isn't doing as much work as we thought. We plan to investigate this more in the days ahead.
下面看看歷年最強(qiáng)500超算里面的本小超算性能方面的排名：
- Nov. 1993: #6
- Nov. 1994: #12
- Nov. 1995: #31
- Nov. 1996: #60
- Nov. 1997: #122
- Nov. 1998: #275
- June 1999: #439
- Nov. 1999: 被踢出名單了
1993年11月，本小超算可以排名世界第6。1999年6月，排名為第439，相比于一般超算放在一個(gè)大大的機(jī)房里，而且需要眾多芯片，這個(gè)4片、8芯的集群，只有11" x 12" x 17"，能有如此表現(xiàn)，很不錯了。
更進(jìn)一步挖掘下這個(gè)列表：1993年11月的排名中，排在第五位的超算是用了512片核芯的Thinking Machines CM-5/512，運(yùn)算速度達(dá)到300億次。本小超算的4核相當(dāng)于當(dāng)年的512核啊，哈哈。
1996年11月，此小超算排在第60位，下一個(gè)是用了256片核芯的Cray T3D MC256-8，現(xiàn)在8核俄性能都超過11年前的256核了，此處還沒說價(jià)格差異呢，T3D花費(fèi)了上百萬美元！超算性能一般以每秒浮算次數(shù)（flops）來衡量。早期超算使用百萬次來衡量，隨著硬件飛躍，十億次已經(jīng)是很落后的指標(biāo)了，現(xiàn)在都流行用萬億次，甚至千萬億次來表示了。
Early supercomputer performance was measured in megaflops (Mflops: 10 6 flops). Hardware advances increased subsequent supercomputers performance to gigaflops (Gflops: 10 9 flops). Today's massively parallel supercomputers are measured in teraflops (Tflops: 10 12 flops), and tomorrow's systems will be measured in petaflops (Pflops: 10 15 flops).
When discussing supercomputer performance, you must also distinguish between
- 峰值性能 --理論上最大的性能表現(xiàn)
- 測量性能 -- 用檢測軟件檢測出來的性能表現(xiàn)
另一個(gè)要注意的是精度，一般高性能運(yùn)算都是用的雙精度，所以不可混淆了單精度和雙精度運(yùn)算。
The standard benchmark (i.e., used by the top500.org supercomputer list) for measuring supercomputer performance is high performance Linpack (aka HPL), a program that exercises and reports a supercomputer's double-precision floating point performance. To install and run HPL, you must first install a version of the Basic Linear Algebra Subprograms (BLAS) libraries, since HPL depends on them.
In March 2007, we benchmarked Microwulf using HPL and Goto BLAS. After compiling and installing each package, we ran the standard, double-precision version of HPL, varying its parameter values as follows: We varied PxQ between {1x8, 2x4}; varied NB between {100, 120, 140, 160, 180, 200}; and used increasing values of N, starting with 1,000. For the following parameter values:
PxQ = 2x4; NB = 160; N = 30,000 HPL reported 26.25 Gflops on its WR00R2R4 operation. Microwulf also exceeded 26 Gflops on other operations, but 26.25 Gflops was our maximum.在最強(qiáng)500超算中，1996年的Cray T3D-256也才達(dá)到253億次，所以我們這個(gè)260億次的性能，是足夠用來做很多事情的了。
Since we benchmarked Microwulf, Advanced Clustering Technologies has published a convenient web-based calculator that removes much of the trial and error from tuning HPL.
性價(jià)比：When you have measured a supercomputer's performance using HPL, and know its price, you can measure its cost efficiency by computing its price/performance ratio. By computing the number of dollars you are paying for each floating point operation (flop), you can compare one supercomputer's cost-efficiency against others.
With a price of just $2470 and performance of 26.25 Gflops, Microwulf's price/performance ratio (PPR) is $94.10/Gflop, or less than $0.10/Mflop! This makes Microwulf the first general-purpose Beowulf cluster to break the $100/Gflop (or $0.10/Mflop) threshold for measured double-precision floating point performance.
下面列表可作為參考，了解下這個(gè)性價(jià)比的意義:
- In 1976, the Cray-1 cost more than 8 million dollars and had a peak (theoretical maximum) performance of 250 Mflops, making its PPR more than $32,000/Mflop. Since peak performance exceeds measured performance, its PPR using measured performance (estimated at 160 Mflops) would be much higher.
- In 1985, the Cray-2 cost more than 17 million dollars and had a peak performance of 3.9 Gflops, making its PPR more than $4,350/Mflop ($4,358,974/Gflop).
- 1997年，打敗西方象棋世界冠軍卡斯帕羅夫的 IBM 深藍(lán)。價(jià)格是5百萬美元，性能是113.8億次，其性價(jià)比是43936.7美元/億次
- In 2003, the U. of Kentucky's Beowulf cluster KASY0 cost $39,454 to build, and produced 187.3 Gflops on the double-precision version of HPL, giving it a PPR of about $210/Gflop.
- Also in 2003, the University of Illinois at Urbana-Champaign's National Center for Supercomputing Applications built the PS 2 Cluster for about $50,000. No measured performance numbers are available; which isn't surprising, since the PS-2 has no hardware support for double precision floating point operations. This cluster's theoretical peak performance is about 500 Gflops (single-precision); however, one study showed that the PS-2's double-precision performance took over 17 times as long as its single-precision performance. Even using the inflated single-precision peak performance value, its PPR is more than $100/Gflop; it's measured double-precision performance is probably more than 17 times that.
- In 2004, Virginia Tech built System X, which cost 5.7 million dollars, and produced 12.25 Tflops of measured performance, giving it a PPR of about $465/Gflop.
- In 2007, Sun's Sparc Enterprice M9000 with a base price of $511,385, produced 1.03 Tflops of measured performance, making its PPR more than $496/Gflop. (The base price is for the 32 cpu model, the benchmark was run using a 64 cpu model, which is presumably more expensive.)
$9.41/億次，我們的小超算可以說是超算里面性價(jià)比最好的一個(gè)了，不過呢，還沒法提供千萬億次的運(yùn)算，若有需要，或許可以突破這個(gè)價(jià)格限制，讓性能方面獲得更大的提升。
效能 - 世界記錄 功耗：
以2007年一月的價(jià)格，本小超算用了2470美元，獲得262.5億次的運(yùn)算速度，平均9.41美元／億次。這個(gè)已經(jīng)成為新的世界紀(jì)錄了。
另外，節(jié)能方面的事情最近也比較敏感，性耗比（耗電量/性能）也需要測量下了，性耗比對集群是非常重要的，尤其是成片的集群（比如谷歌的服務(wù)器場）。本小超算我們測試了下，- 待機(jī)需要消耗250瓦（平均30瓦每核），
- 運(yùn)行是需要消耗450瓦，
對比下其他的超算。
專門進(jìn)行節(jié)能設(shè)計(jì)的超算Green Destiny 使用了非常節(jié)能的芯片，只需要較低的冷切，240核消耗了3.2千瓦，獲得的運(yùn)算性能是1010億次，性耗比為3.1瓦/億次。是我們這個(gè)自制的小超算的兩倍哦！！！
Another interesting comparison is to the Orion Multisystems clusters. Orion is no longer around, but a few years ago they sold two commercial clusters: a 12-node desktop cluster (the DS-12) and a 96-node deskside cluster (the DS-96). Both machines used Transmeta CPUs. The DS-12 used 170W under load, and its performance was about 13.8 GFLOPS. This gives it a performance/power ratio of 12.31W/GLFOP (much better than Microwulf). The DS-96 consumed 1580W under load, with a performance of 109.4 GFLOPS. This gives it a performance/power ratio of 14.44W/GFLOP, which again beats Microwulf.
Another way to look at power consumption and price is to use the metric from Green 500. Their metric is MFLOPS/Watt (the bigger the number the better). Microwulf comes in at 58.33, the DS-12 is 81.18, and the deskside unit is 69.24. So using the Green 500 metric we can see that the Orion systems are more power efficient than Microwulf. But let's look a little deeper at the Orion systems.
The Orion systems look great at Watts/GFLOP and considering the age of the Transmeta chips, that is no small feat. But let's look at the price/performance metric. The DS-12 desktop model had a list price of about $10,000, giving it a price/performance ratio of $724/GFLOP. The DS-96 deskside unit had a list price of about $100,000, so it's price/performance is about $914/GFLOP. That is, while the Orion systems were much more power efficient, their price per GFLOP is much higher than that of Microwulf, making them much less cost efficient than Microwulf.
Since Microwulf is better than the Orion systems in price/performance, and the Orion systems are better than Microwulf in power/performance, let's try some experiments with metrics to see if we can find a useful way to combine the metrics. Ideally we'd like a single metric that encompasses a system's price, performance, and power usage. As an experiment, let's compute MFLOP/Watt/$. It may not be perfect, but at least it combines all 3 numbers into a single metric, by extending the Green 500 metric to include price. You want a large MFLOP/Watt to get the most processing power per unit of power as possible. We also want price to be as small as possible so that means we want the inverse of price to be as large as possible. This means that we want MFLOP/Watt/$ to be as large as possible. With this in mind, let's see how Microwulf and Orion did.
- Microwulf: 0.2362
- Orion DS-12: 0.00812
- Orion DS-96: 0.00069
From these numbers (even though they are quite small), Microwulf is almost 3 times better than the DS-12 and almost 35 times better than the DS-96 using this metric. We have no idea if this metric is truly meaningful but it give us something to ponder. It's basically the performance per unit power per unit cost. (OK, that's a little strange, but we think it could be a useful way to compare the overall efficiency of different systems.)
We might also compute the inverse of the MFLOP/Watt/$ metric: -- $/Watt/MFLOP -- where you want this number to be as small as possible. (You want price to be small and you want Watt/MFLOP to be small). So using this metric we can see the following:
- Microwulf: 144,083
- Orion DS-12: 811,764
- Orion DS-96: 6,924,050
This metric measures the price per unit power per unit performance. Comparing Microwulf to the Orion systems, we find that Microwulf is about 5.63 times better than the DS-12, and 48 times better than the DS-96. It's probably a good idea to stop here, before we drive ourselves nuts with metrics.
While most clusters publicize their performance data, Very few clusters publicize their power consumption data.
Some notable exceptions are:
- Green Destiny, an experimental blade cluster built at Los Alamos National Labs in 2002. Green Destiny was built expressly to minimze power consumption, using 240 Transmeta TM560 CPUs. Green Destiny consumed 3.2 kilowatts and produced 101 Gflops (on Linpack), yielding a power/performance ratio of 31 watts/Gflop. Microwulf's 17.14 watts/Gflop is much better.
- The (apparently defunct) Orion Multisystems DS-12 and DS-96 systems:
- The DS-12 "desktop" system consumed 170 watts under load, and produced 13.8 Gflops (Linpack), for a power/performance ratio of 12.31 watts/Gflop. (The DS-12's list price was about $10,000, making its price/performance ratio $724/Gflop.)
- The DS-96 "under desk" system consumed 1580 watts under load, and produced 109.4 Gflops (Linpack), for a power/performance ratio of 14.44 watts/Gflop. (The DS-96's list price was about $100,000, making its price/performance ratio about $914/Gflop.)
- 我們的小超算性價(jià)比上 遠(yuǎn)超這些商業(yè)機(jī)器，其性耗比也居于前流。
節(jié)能500超算名單，是基于最強(qiáng)500超算的（本小超算沒有被列入，呵呵），排名按每瓦運(yùn)算次數(shù)排列。我們的小超算是1.713瓦／億次，換算如下：
1 / 17.14 W/Gflop * 1000 Mflops/Gflop= 58.34 Mflops/W 2007年8月，我們的小超算超越了節(jié)能500超算的第二位，Mare Nostrum (58.23 Mflops/W) -- 可惜啊，和排名第一BlueGene/L (112.24 Mflops/W)的距離有點(diǎn)遠(yuǎn)。結(jié)論
此小超算用了4塊芯片、8核集群，大小為11" x 12" x 17"，適合放在桌面上，也適合打包放到飛機(jī)上運(yùn)輸。
除了小巧，HPL檢測本超算有262.5億次的運(yùn)算性能，總花費(fèi)是2470美元（2007年1月），性價(jià)比為9.41美元/億次。
本小超算能有如此神力的原因是：
- 多核芯片已經(jīng)普及：這樣可以讓系統(tǒng)變得更小。
- 內(nèi)存大降價(jià)： 此小超算最貴的部分就是這個(gè)，不過價(jià)格一直在快速下降中，8G內(nèi)存應(yīng)該夠用了吧？？
- 千兆網(wǎng)卡已經(jīng)普及：On-board GigE adaptors, inexpensive GigE NICs, and inexpensive GigE switches allow Microwulf to offer enough network bandwidth to avoid starving a parallel computation with respect to communication.
我們不打算保守我們的技術(shù)秘密，而是希望所有人都來嘗試這玩玩，嗯，其實(shí)很多部件都是可以替換的。
比如，隨著固態(tài)硬盤的降價(jià)，可以試試固態(tài)硬盤替換掉機(jī)械硬盤，看看對性能有何影響。
比如內(nèi)存：因?yàn)閮?nèi)存降價(jià)，可以把內(nèi)存換為2GB的，這樣每核可以2GB內(nèi)存。Recalling that HPL kept running out of memory when we increased N above 30,000, it would be interesting to see how many more FLOPS one could eke out with more RAM. The curve in Figure Six suggests that performance is beginning to plateau, but there still looks to be room for improvement there.
比如主板和芯片：此微星主板使用AM2插槽，這個(gè)插槽剛好支持威盛新的4核Athlon64芯片，這樣就可以替換掉上文中的雙核芯片，使得整個(gè)系統(tǒng)變成 16核，性能更加強(qiáng)勁。有興趣的同學(xué)可以測測這么做的結(jié)果性能提升多少？性價(jià)比因此而產(chǎn)生的變化？千兆內(nèi)部網(wǎng)的效能變化等……
等等……尤其是已經(jīng)幾年后的今天（2012），這個(gè)列表幾乎可以全部替換掉了。
2007年8月配件價(jià)格：
各個(gè)部件的價(jià)格下降很快。芯片、內(nèi)存、網(wǎng)絡(luò)、硬盤等，都降了好多價(jià)格。2007年8月在 新蛋（Newegg） 中的價(jià)格：
部件產(chǎn)品名稱
單價(jià)
數(shù)量 總價(jià) 主板 微星K9N6PGM-F MicroATX$50.32 4 $201.28 芯片
威盛 Athlon 64 X2 3800+ AM2 CPU$65.00 4 $260.00 內(nèi)存 Corsair DDR2-667 2 x 1GByte RAM $75.99 4 $303.96 電源
LOGISYS Computer PS350MA MicroATX 350W Power Supply$24.53 4 $98.12 網(wǎng)卡 Intel PRO/1000 PT PCI-Express NIC (節(jié)點(diǎn)連接路由) $34.99 4 $139.96 網(wǎng)卡
Intel PRO/100 S PCI NIC (主控主板連接外部網(wǎng)絡(luò)) $15.30 1 $15.30 路由器
SMC SMCGS8 10/100/1000Mbps 8-port Unmanaged Gigabit Switch$47.52 1 $47.52 硬盤
希捷7200轉(zhuǎn) 250GB SATA 硬盤$64.99 1 $64.99 光驅(qū)
Liteon SHD-16S1S 16X$23.831$23.83 制冷設(shè)備
Zalman ZM-F3 120mm Case Fans$14.98 4 $59.92 風(fēng)扇 Generic NET12 Fan Grill (120mm)$6.48 4 $25.92 硬件支架 36" x 0.25" threaded rods $1.68 3 $5.00 硬件加固 Lots of 0.25" nuts and washers $10.00 機(jī)箱或外殼 12" x 11" 有機(jī)玻璃（來自物理實(shí)驗(yàn)室的廢物） $0.00 4 $0.00 總價(jià)$1,255.80
(現(xiàn)在價(jià)格應(yīng)該更低了!而且性能方面應(yīng)該更強(qiáng)悍了！！！)
可見，2007年8月，這個(gè)性價(jià)比已經(jīng)達(dá)到了4.784美元/億次，突破5美元/億次！！！！！
性耗比則保持不變。
如果融合價(jià)格、性能、功耗，則每百萬次/瓦/美元為0.04645，是原來的小超算兩倍。美元/瓦/百萬次為 73,255，也是原來的兩倍。
應(yīng)用：
和其他超算一樣，本小超算可以運(yùn)行一些并行運(yùn)算軟件——需要特別設(shè)計(jì)，以利用系統(tǒng)的并行運(yùn)算能力。
這些軟件一般會使用 通用信道和并行虛擬機(jī)。這幾個(gè)庫提供了分布式計(jì)算的最基礎(chǔ)功能，一是使得進(jìn)程可以在網(wǎng)絡(luò)間溝通和同步，二是提供了一個(gè)分布執(zhí)行最后匯總的機(jī)制，使得程序可以被復(fù)制成多份，分別在各個(gè)節(jié)點(diǎn)上運(yùn)行。
有很多應(yīng)用軟件已經(jīng)可以在本小超算上使用，大部分是由特定領(lǐng)域的科學(xué)家寫的，用于解決特定問題：
- CFD codes, an assortment of programs for computational fluid dynamics
- DPMTA, a tool for computing N-body interactions fastDNAml, a program for computing phylogenetic trees from DNA sequences
- Parallel finite element analysis (FEA) programs, including:
- Adventure, the ADVanced ENgineering analysis Tool for Ultra large REal world, a library of 20+ FEA modules
- deal.II, a C++ program library providing computational solutions for partial differential equations using adaptive finite elements
- DOUG, Domain decomposition On Unstructured Grids
- GeoFEM, a multi-purpose/multi-physics parallel finite element simulation/platform for solid earth
- ParaFEM, a general parallel finite element message passing libary
- Parallel FFTW, a program for computing fast Fourier transforms (FFT)
- GADGET, a cosmological N-body simulator
- GAMESS, a system for ab initio quantum chemistry computations
- GROMACS, a molecular dynamics program for modeling molecular interactions, especially those from biochemistry
- MDynaMix, a molecular dynamics program for simulating mixtures
- mpiBLAST, a program for comparing gene sequences
- NAMD, a molecular dynamics program for simulating large biomolecular systems
- NPB 2, the NASA Advanced Supercomputing Division's Parallel Benchmarks suite. These include:
- BT, a computational fluid dynamics simulation
- CG, a sparse linear system solver
- EP, an embarrassingly parallel floating point solver
- IS, a sorter for large lists of integers
- LU, a different CFD simulation
- MG, a 3D scalar Poisson-equation solver
- SP, yet another (different) CFD simulation
- ParMETIS, a library of operations on graphs, meshes, and sparse matrices
- PVM-POV, a ray-tracer/renderer
- SPECFEM3D, a global and regional seismic wave simulator
- TPM, a collisionless N-body (dark matter) simulator
這是我們使用小超算的領(lǐng)域：
- 給卡爾文大學(xué)的本科生做研究項(xiàng)目
- As a high performance computing resource for CS 374: High Performance Computing
- 正在做的事情：
- 給本地的高中學(xué)校也定制幾個(gè)，以提升學(xué)生了解計(jì)算的興趣
- 用于會議，作為一個(gè)個(gè)人超算的示例模型。
- When not being used for these tasks, Microwulf runs the client for Stanford's Folding@Home project, which helps researchers better understand protein folding, which in turn helps them the causes of (and hopefuly the cures for) genetic diseases. Excess CPU cycles on a Beowulf cluster like Microwulf can be devoted to pretty much any distributed computing project.
Unless the program has been written specifically to run in parallel across a network (i.e., it has been written using a parallel library like message passing interface (MPI)), probably not.
A normal computer with a multicore CPU is a shared memory multiprocessor, since programs/threads running on the different cores can communicate with one another through the memory each core shares with the others.
On a Beowulf cluster like Microwulf, each motherboard/CPU has its own local memory, so there is no common/shared memory through which programs running on the different CPUs can communicate. Instead, such programs communicate through the network, using a communication library like MPI. Since its memory is distributed among the cluster's CPUs, a cluster is a distributed memory multiprocessor.
Many companies only began writing their programs for shared-memory multiprocessors (i.e., using multithreading) in 2006 when dual core CPUs began to appear. Very few companies are writing programs for distributed memory multiprocessors (but there are some). So a game (or other program) will only run faster on Microwulf if it has been parallelized to run on a distributed multiprocessor.
The key to making any cluster work is the availability of a software library that will in parallel run a copy of a program on each of the cluster's cores, and let those copies communicate across the network. The most commonly used library today is MPI.
There are several versions of MPI available for Windows. (To find them, just google 'windows mpi'.) So you can build a cluster using Windows. But it will no longer be a Beowulf cluster, which, by definition, uses an open source operating system. Instead, it will be a Windows cluster.
Microsoft is very interested in high performance computing -- so interested, they have released a special version of Windows called Windows Compute Cluster Server (Windows CCS), specifically for building Windows clusters. It comes with all the software you need to build a Windows cluster, including MPI. If you are interested in building a Windows cluster, Windows CCS is your best bet.
There are many websites that describe how. Here are a few of them:
- Building a Beowulf System, by Jan Lindheim, provides a quick overview
- Jacek Radajewski and Douglas Eadline's HowTo provides a more detailed overview
- Kurt Swendson's HowTo provides step-by-step instructions for building a cluster using Redhat Linux and LAM-MPI
- Engineering a Beowulf-style Compute Cluster, by Robert Brown, is an online book on building Beowulf clusters, with lots of useful information.
- The Beowulf mailing list FAQ, by Don Becker, et al, is a list of answers to questions frequently posted to the Beowulf.org mailing list, which has a searchable Archive.
- Beowulf.org's Projects page provides a list of links to the first hundred or so Beowulf cluster project sites. Many of these sites provide information that is useful to someone building a Beowulf cluster.
Our vendor supplied screws and brass standoffs with our motherboards. The standoffs have a male/screw end, normally screwed into the case; and a female/nut end, to which the motherboard is screwed. To use these to mount the motherboards, we just had to:
To prepare each plexiglass piece, we laid a motherboard on top of it and then used a marker to color the plexiglass through the motherboard's mounting holes. The only tricky parts are:
- one piece of plexiglass has motherboards on both its top and its bottom, so you have to mark both sides; and
- two motherboards hang upside down, and two sit right-side up, so you have to take that into account when marking the holes.
We used a red marker to mark the positions of the holes on motherboards facing up, and a blue marker to mark the positions of the holes on motherboards facing down.
With the plexiglass pieces marked, we took them to our campus machine shop and used a drill press to drill holes in each piece of plexiglass.
When all the motherboard holes were drilled, we stacked the plexiglass pieces as they would appear in Microwulf and drilled holes in their corners for the threaded rods.
We then screwed the standoffs into the plexiglass, taking care not to overtighten them. Being made of soft brass, they are very easy to shear off. If this happens to you, just take the piece of plexiglass back to the drill press and drill out the bit of brass screw that's in the hole. (Or, if this is the only one, you can just leave it there and use one fewer screws to mount the motherboard.)
With the standoffs in place, we then placed the motherboards on the standoffs, and used screws to secure them in place. That's it!
The only other detail worth mentioning is that before we screwed each motherboard tight to the standoffs, we chose one standoff on each motherboard to ground that motherboard against static. To do this grounding, we got some old phone wire, looped one end to the standoff, and then tightened the screw for that standoff. We then grounded each wire to one of the threaded rods, and grounded that threaded rod to one of the power supplies.
否，主要是因?yàn)槲覀兌疾欢虡I(yè)。
But we are trying to build an endowment to provide in-house funding for student projects like Microwulf, so if you've found this site to be useful, please consider making a (tax-deductible) donation to it:
CS Hardware Endowment FundDepartment of Computer ScienceCalvin College3201 Burton SEGrand Rapids, MI 49546 謝啦!某網(wǎng)友測試過評論如下
好多年前的事情了.....
不在于系統(tǒng)是ubuntu Linux
而問題的重點(diǎn)是:
你會組裝機(jī)器 硬件組裝； 會作系統(tǒng)優(yōu)化配置， 會配置很多服務(wù)， 比如NFS（構(gòu)建無盤系統(tǒng)），NIS， 構(gòu)建用戶信息， MPI（高斯可以不用這個(gè)并行環(huán)境）， 網(wǎng)絡(luò)優(yōu)化， 幾個(gè)機(jī)器之間通信能力的優(yōu)化，
如果你僅僅是明白硬件， 而對于linux系統(tǒng)的水平只專注于3D桌面之類的桌面應(yīng)用， 那么你要搞明白這套系統(tǒng)，
還是比較困難的。
我自己作過， 只不過是用的兩臺機(jī)器，也是無盤系統(tǒng)， 系統(tǒng)采用自己熟悉的RHEL， 5.3 ,
那位作者的組裝說明， 適合管理過linux系統(tǒng)， 熟悉linux網(wǎng)絡(luò)應(yīng)用的人看，
沒有涉及過網(wǎng)絡(luò)管理， 網(wǎng)絡(luò)應(yīng)用的， 要作下去比較費(fèi)勁的。
他寫的只是一個(gè)方案， 不是具體的每一步的how-to,
誰有興趣的可以試試！
這套無盤系統(tǒng)， 性能很大程度取決于你的磁盤性能！
注意，這套系統(tǒng)， 適合并
自己組建spark集群,硬件方面以及網(wǎng)絡(luò)連接設(shè)備方面應(yīng)該如何選擇
測試環(huán)境好些吧
spark運(yùn)算速度超快
生產(chǎn)環(huán)境適合云計(jì)算（aws azure數(shù)據(jù)流入流量都是免費(fèi)的）
比hadoop處理同樣數(shù)據(jù)能省很多機(jī)時(shí)和錢
spark如何實(shí)現(xiàn)一個(gè)快速的RDD中所有的元素相互計(jì)算？
在spark集群中需要實(shí)現(xiàn)每個(gè)元素與其他元素進(jìn)行計(jì)算，比如
rdd = sc.parallelize(Array('a', 'b', 'c', 'd'))，
那么需要相互計(jì)算的元素對為
(a, b), (a, c), (a, d), (b, c), (b, d), (c, d)
我知道可以先進(jìn)行cartesian，然后filter一下，但是對于數(shù)據(jù)量特別大的時(shí)候(比如，10w個(gè))，這種方法貌似很慢，所以請問大家知道在spark中有什么好的解決方法呢？
Spark程序如何只輸出最后結(jié)果，隱藏中間的輸出？？？
由于spark的調(diào)試信息輸出在stderr 可以在命令后面加上 2>/dev/null 去掉調(diào)試信息
把spark/conf/log4j.properties下的
log4j.rootCategory=【W(wǎng)arn】=> 【ERROR】
log4j.logger.org.spark-project.jetty=【W(wǎng)arn】=> 【ERROR】
頭大，這幾種框架是什么關(guān)系？？？我現(xiàn)在想對hdfs上的文件做分析，spark是基于hadoop嗎？sparksql又是什么，獨(dú)立的項(xiàng)目嗎？可以搭建一個(gè)hadoop+spark的平臺嗎，比如說使用hadoop的hdfs，然后使用spark sql方式來查詢分析數(shù)據(jù)？？？對了還有hive on spark
瀉藥，水平有限，就科普一下吧。Hadoop是最早的MapReduce框架和Google File System的開源實(shí)現(xiàn)，被作為大數(shù)據(jù)處理的主流處理技術(shù)已經(jīng)10多年了，其主要組件包括了MapReduce（計(jì)算）和HDFS（存儲），然后在這個(gè)基礎(chǔ)上發(fā)展成了一個(gè)生態(tài)系統(tǒng)，包括HBase，Hive等等。大約在2012年加州伯克利的Matei等人在MapReduce思想的基礎(chǔ)上提出了RDD模式對數(shù)據(jù)進(jìn)行暫存，并實(shí)現(xiàn)了Spark的原始版本，然后一直發(fā)展到現(xiàn)在。二者從根源上講是基于同一種MapReduce思想的，但是Spark能完成的計(jì)算任務(wù)多樣化，同配置下在絕大多數(shù)場景下比Hadoop要快。二者并無直接關(guān)系。基于Spark的核心作業(yè)引擎，Matei等人又設(shè)計(jì)了Spark SQL，Spark Streaming和Spark MLib等框架用來提供對特定場景的作業(yè)的支持。Spark SQL是基于Spark的。但是Spark是支持從Hadoop HDFS讀取數(shù)據(jù)然后進(jìn)行處理的，也支持S3和Tachyon，所以二者并不是密不可分的關(guān)系。
此外，題主問出這種問題讓我很震驚，這是在某度里度一下都可以解決的問題。上知乎前先自己去了解一下。
1、Hadoop提供存儲和離線計(jì)算，分別是HDFS和MapReduce（當(dāng)然還有個(gè)HBase，題主既然沒說那么不提也罷）
2、Spark只是一種計(jì)算框架，和Hadoop對應(yīng)起來就是里面的MapReduce這個(gè)角色，他的存儲系統(tǒng)可以使HDFS或者S3等，和MapReduce不同的是Spark是基于內(nèi)存計(jì)算的
3、SparkSQL只是Spark中的一個(gè)核心擴(kuò)展，在SparkSQL中用戶可以通過類似SQL語句對數(shù)據(jù)進(jìn)行分析操作，相對比scala，sql可能能夠給大部分人所接受= =
對于題主的問題：
Hadoop并不是一定要上Spark，Spark也并不一定要依賴于Hadoop，所以這兩者不是強(qiáng)制一定要一起使用的，當(dāng)然肯定也不會是“有你沒我，有我沒你”的關(guān)系，互補(bǔ)，互補(bǔ)！
SparkSQL肯定是和Spark有關(guān)系的了，父子關(guān)系嘛，他還有Mllib，Graphx，Spark Streaming這些兄弟呢。。
我猜題主的應(yīng)該是測試型的數(shù)據(jù)集，上Spark玩看看吧，有時(shí)間也可以用MapReduce實(shí)現(xiàn)對比試試
通過對比的方式可以更加深刻的理解MapReduce和Spark RDD編程模型之間的優(yōu)缺點(diǎn)
對于最后一個(gè)問題，完全可以。。
?
我很喜歡用python，用python處理數(shù)據(jù)是家常便飯，從事的工作涉及nlp，算法，推薦，數(shù)據(jù)挖掘，數(shù)據(jù)清洗，數(shù)據(jù)量級從幾十k到幾T不等，我來說說吧
百萬級別數(shù)據(jù)是小數(shù)據(jù)，python處理起來不成問題，python處理數(shù)據(jù)還是有些問題的
Python處理大數(shù)據(jù)的劣勢：
1. python線程有g(shù)il，通俗說就是多線程的時(shí)候只能在一個(gè)核上跑，浪費(fèi)了多核服務(wù)器。在一種常見的場景下是要命的：并發(fā)單元之間有巨大的數(shù)據(jù)共享或者共用（例如大dict），多進(jìn)程會導(dǎo)致內(nèi)存吃緊，多線程則解決不了數(shù)據(jù)共享的問題，單獨(dú)的寫一個(gè)進(jìn)程之間負(fù)責(zé)維護(hù)讀寫這個(gè)數(shù)據(jù)不僅效率不高而且麻煩
2. python執(zhí)行效率不高，在處理大數(shù)據(jù)的時(shí)候，效率不高，這是真的，pypy（一個(gè)jit的python解釋器，可以理解成腳本語言加速執(zhí)行的東西）能夠提高很大的速度，但是pypy不支持很多python經(jīng)典的包，例如numpy（順便給pypy做做廣告，土豪可以捐贈一下PyPy - Call for donations）
3. 絕大部分的大公司，用java處理大數(shù)據(jù)不管是環(huán)境也好，積累也好，都會好很多
Python處理數(shù)據(jù)的優(yōu)勢（不是處理大數(shù)據(jù)）：
1. 異常快捷的開發(fā)速度，代碼量巨少
2. 豐富的數(shù)據(jù)處理包，不管正則也好，html解析啦，xml解析啦，用起來非常方便
3. 內(nèi)部類型使用成本巨低，不需要額外怎么操作（java，c++用個(gè)map都很費(fèi)勁）
4. 公司中，很大量的數(shù)據(jù)處理工作工作是不需要面對非常大的數(shù)據(jù)的
5. 巨大的數(shù)據(jù)不是語言所能解決的，需要處理數(shù)據(jù)的框架（hadoop， mpi。。。。）雖然小眾，但是python還是有處理大數(shù)據(jù)的框架的，或者一些框架也支持python
6. 編碼問題處理起來太太太方便了
綜上所述：
1. python可以處理大數(shù)據(jù)
2. python處理大數(shù)據(jù)不一定是最優(yōu)的選擇
3. python和其他語言（公司主推的方式）并行使用是非常不錯的選擇
4. 因?yàn)殚_發(fā)速度，你如果經(jīng)常處理數(shù)據(jù)，而且喜歡linux終端，而且經(jīng)常處理不大的數(shù)據(jù)（100m一下），最好還是學(xué)一下python
python數(shù)據(jù)處理的包：
1. 自帶正則包， 文本處理足夠了
2. cElementTree, lxml 默認(rèn)的xml速度在數(shù)據(jù)量過大的情況下不足
3. beautifulsoup 處理html
4. hadoop(可以用python) 并行處理，支持python寫的map reduce，足夠了， 順便說一下阿里巴巴的odps，和hadoop一樣的東西，支持python寫的udf，嵌入到sql語句中
5. numpy, scipy, scikit-learn 數(shù)值計(jì)算，數(shù)據(jù)挖掘
6. dpark(搬樓上的答案）類似hadoop一樣的東西
1，2，3，5是處理文本數(shù)據(jù)的利器（python不就處理文本數(shù)據(jù)方便嘛），4，6是并行計(jì)算的框架（大數(shù)據(jù)處理的效率在于良好的分布計(jì)算邏輯，而不是什么語言）
暫時(shí)就這些，最好說一個(gè)方向，否則不知道處理什么樣的數(shù)據(jù)也不好推薦包，所以沒有頭緒從哪里開始介紹這些包
這要看具體的應(yīng)用場景，從本質(zhì)上來說，我們把問題分解為兩個(gè)方面：
1、CPU密集型操作
即我們要計(jì)算的大數(shù)據(jù)，大部分時(shí)間都在做一些數(shù)據(jù)計(jì)算，比如求逆矩陣、向量相似度、在內(nèi)存中分詞等等，這種情況對語言的高效性非常依賴，Python做此類工作的時(shí)候必然性能低下。
2、IO密集型操作
假如大數(shù)據(jù)涉及到頻繁的IO操作，比如從數(shù)據(jù)流中每次讀取一行，然后不做什么復(fù)雜的計(jì)算，頻繁的輸入輸出到文件系統(tǒng)，由于這些操作都是調(diào)用的操作系統(tǒng)接口，所以用什么語言已經(jīng)不在重要了。
結(jié)論
用Python來做整個(gè)流程的框架，然后核心的CPU密集操作部分調(diào)用C函數(shù)，這樣開發(fā)效率和性能都不錯，但缺點(diǎn)是對團(tuán)隊(duì)的要求又高了(尤其涉及到Python+C的多線程操作)...所以...魚與熊掌不可兼得。如果一定要兼得，必須得自己牛逼。
奧利根神棍
1：Numpy+Scipy+Numba
2：Pandas+NLTK
答主是不是都沒用過。
我們公司每天處理數(shù)以P記的數(shù)據(jù)，有個(gè)并行g(shù)rep的平臺就是python做的。當(dāng)初大概是考慮快速成型而不是極限速度，但是事實(shí)證明現(xiàn)在也跑得杠杠的。大數(shù)據(jù)很多時(shí)候并不考慮太多每個(gè)節(jié)點(diǎn)上的極限速度，當(dāng)然速度是越快越好，但是再更高層次做優(yōu)化（比如利用data locality減少傳輸，建索引快速join，做sample優(yōu)化partition，用bloomfilter快速測試等等），把python換成C并不能很大程度上提升效率。
很多機(jī)器學(xué)習(xí)，神經(jīng)網(wǎng)絡(luò)，數(shù)據(jù)計(jì)算的算法已經(jīng)存在幾十年了，這些零零散散的工具多被C和Fortran實(shí)現(xiàn)，直到有人開始用Python把這些工具集合到一起，所以，表面上是在用Python的庫，實(shí)際上是C和Fortran的程序，性能上也并無大的影響，如果你真的是大數(shù)據(jù)的話
使用python可以，但對速度要求較高的關(guān)鍵模塊，還是要用C重寫。
Python調(diào)用vtk庫對面片數(shù)量我測試過是沒有限制的好像，你所說的100萬多數(shù)據(jù)是不是都是存入了python的list中，list是有上限限制的。如果不存入list，應(yīng)該是沒有渲染上限的。
求python在大數(shù)據(jù)環(huán)境下高效編程的方法。
在spark集群下，我對對原來scala程序進(jìn)行python重寫。對過億行級數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗整合操作。從執(zhí)行任務(wù)的時(shí)間來看，scala執(zhí)行效率比python重寫程序高好多倍。
什么叫處理？ 100萬的數(shù)據(jù)，如果只是傳輸?shù)脑?#xff0c;python和c/c++差不多；如果用來計(jì)算話題模型的話，python的速度為c/c++的1/10，內(nèi)存消耗為10倍多。
使用Python調(diào)用vtk庫對100萬行的數(shù)據(jù)進(jìn)行可視化，結(jié)果內(nèi)存爆滿，使用C++就沒有問題，Python很占內(nèi)存，不知道為什么……
Python clone of Spark, a MapReduce alike framework in Python
https://github.com/douban/dpark
?
組建spark集群(生成環(huán)境)如何選擇硬件？修改
1、看過官方的一個(gè)文檔：https://spark.apache.org/docs/1.2.0/hardware-provisioning.html
2、集群主要用于spark streaming 和 機(jī)器學(xué)習(xí)這塊，在硬件選擇上有哪些注意點(diǎn)？
3、是否有同學(xué)能夠共享一個(gè)線上環(huán)境的配置。
首先推薦看一看新出爐的https://spark-summit.org/east-2015/
題主給出的官方文檔已經(jīng)說得很好了，我只是結(jié)合自己的經(jīng)驗(yàn)補(bǔ)充一下：
首先估算數(shù)據(jù)量大小（總?cè)萘?#xff09;、Spark作業(yè)復(fù)雜度（需要多少計(jì)算能力）、作業(yè)的Locality（是否容易緩存）、數(shù)據(jù)交換的流量（多少數(shù)據(jù)需要在不同節(jié)點(diǎn)交換）。另外也考慮一下實(shí)時(shí)性需求，比如一次作業(yè)能忍受多長時(shí)間出結(jié)果。
每個(gè)節(jié)點(diǎn)的CPU、Memory、Network要匹配上面作業(yè)的需求，換句話說別讓一個(gè)成為短板。
從成本上看，使用平民級硬件更好。比如RAID就沒必要用。但是生產(chǎn)系統(tǒng)，ECC是必須的。
可以超量部署一段時(shí)間，然后再減下來
Spark Streaming沒玩過，不過從用Storm的經(jīng)驗(yàn)看，CPU和Network更容易是瓶頸。
MLlib用的不多，如果數(shù)據(jù)集能放在內(nèi)存中，CPU和Network是瓶頸。
如何利用spark快速計(jì)算笛卡爾積？修改
在在spark集群里面 需要計(jì)算a＊b的笛卡爾積 a為一列
b為一列 我將a作為一個(gè)rdd b作為一個(gè)rdd 直接調(diào)用cartesian方法，當(dāng)數(shù)據(jù)量比較大的時(shí)候計(jì)算非常的慢，看sparkUI shuffleread的數(shù)據(jù)量較大，想請教下有可能是哪里出了問題或者有什么更好的方法在分布式上處理計(jì)算笛卡爾積。
作者：連城
鏈接：https://www.zhihu.com/question/39680151/answer/86174606
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
可以試試用 DataFrame API。
笛卡爾積映射到 SQL/DataFrame 上就是一個(gè)不帶 join 條件的 inner join。DataFrame API 相對于 RDD API 的好處在于整體執(zhí)行引擎基于 Spark SQL 的 Catalyst optimizer，并且可以利用上 project Tungsten 引入的各種執(zhí)行層面的優(yōu)化。Spark 新近版本中無 join 條件的 inner join 被編譯為 CartesianProduct 時(shí)采用的已經(jīng)是 UnsafeCartesianRDD 了。
此外，如果是兩個(gè) DataFrame 中有一個(gè)顯著小于另一個(gè)，可以考慮將小的 DataFrame 廣播出去從而避免大量 shuffle。以下是 1.6 的 spark-shell 中的示例：
import org.apache.spark.sql.functions.broadcast
val large = sqlContext.range(5)
val small = sqlContext.range(2)
large.join(broadcast(small)).show()
+---+---+
| id| id|
+---+---+
| 0| 0|
| 0| 1|
| 1| 0|
| 1| 1|
| 2| 0|
| 2| 1|
| 3| 0|
| 3| 1|
| 4| 0|
| 4| 1|
+---+---+
十分感謝，一會試試dataframe API ，我們原來的環(huán)境是1.2.0才升級成了1.5.0 囧，[SPARK-6307][Core] Speed up RDD.cartesian by caching remotely received blocks by viirya · Pull Request #5572 · apache/spark · GitHub 根據(jù)這個(gè)jira單號 spark在處理笛卡爾集的時(shí)候如果是remote讀過來的數(shù)據(jù) 是計(jì)算后會釋放的導(dǎo)致做笛卡爾集反復(fù)的讀取和，如果spark有部分小的問題，我看了下源代碼很多類和方法都是private的，如果想要做一定的修復(fù)，只能修改源代碼重新打包 測試，比較麻煩，這個(gè)方面我想問下 spark可以開放更多的東西給開發(fā)者嗎。
這點(diǎn)比較糾結(jié)……開放 API 是相對謹(jǐn)慎的，因?yàn)橐坏╅_放就要在長時(shí)間內(nèi)保持向下兼容，一定程度上會束縛后期演化。所以只有比較成熟的 API 才會開放。
理解，當(dāng)前來看想要維護(hù)spark的一些bug之類的，要么修改源代碼，要么只能等待spark升級了：），總之多follow，多研究，感謝回答
弱弱的問一句 使用jdbc進(jìn)行join的執(zhí)行效率會比使用dataframe API的執(zhí)行效率低么？
不是很明白意思誒，啥叫使用jdbc進(jìn)行join
研究過相關(guān)課題,看到delta join的問題格外的親切
更好的方法,看你問的是那一層面的優(yōu)化了
spark本身研究不多,以前研究這個(gè)課題是基于hadoop
無條件情況計(jì)算量無法優(yōu)化,因?yàn)橛?jì)算量就是m*n這么多
大小表的情況,可以通過廣播小表等方法優(yōu)化
兩個(gè)都是大表的情況,分布式計(jì)算模型中數(shù)據(jù)傳輸量可以優(yōu)化,但是很有限
這是幾年前研讀論文的總結(jié),現(xiàn)在說不定過時(shí)了,但希望對你有幫助
論文:https://github.com/effyroth/paper/blob/master/10487_080605_200915055%E6%9C%89%E5%AD%A6%E5%8F%B7.pdf
感謝回答，個(gè)人這段時(shí)間的思考是1.如果是分布式計(jì)算m＊n，可以將相對較大的m，較小的n變成（m1+m2+m3..mx）＊n，n遍成廣播變量這樣減少n的shuffle，同時(shí)并行計(jì)算笛卡爾集，或者將變換m1＊n＝（m11*n+m12*n+m13*n...+m1x*n）這樣可以串行計(jì)算減少單次計(jì)算的數(shù)據(jù)量以減少集群單節(jié)點(diǎn)的壓力。2.對于spark的話和我上面說的是對于spark計(jì)算cartesianjoin的話，本身的方法有瑕疵，而想要優(yōu)化又只能修改源代碼帶來的不方便。3后面更多的思考是 怎么從業(yè)務(wù)邏輯本身去優(yōu)化，減少m和n的數(shù)據(jù)量或者避免笛卡爾集的計(jì)算，畢竟隨便1w＊1w的笛卡爾集數(shù)據(jù)量是相當(dāng)嚇人的。
?
關(guān)于Spark：
Spark是UC Berkeley AMP lab所開源的類Hadoop MapReduce的通用的并行計(jì)算框架，Spark基于map reduce算法實(shí)現(xiàn)的分布式計(jì)算，
擁有Hadoop MapReduce所具有的優(yōu)點(diǎn)；但不同于MapReduce的是Job中間輸出和結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫HDFS，
因此Spark能更 好地適用于數(shù)據(jù)挖掘與機(jī)器學(xué)習(xí)等需要迭代的map reduce的算法
Spark與Hadoop的對比
Spark的中間數(shù)據(jù)放到內(nèi)存中，對于迭代運(yùn)算效率更高。
Spark更適合于迭代運(yùn)算比較多的ML和DM運(yùn)算。因?yàn)樵赟park里面，有RDD的抽象概念。
Spark比Hadoop更通用。
Spark提供的數(shù)據(jù)集操作類型有很多種，不像Hadoop只提供了Map和Reduce兩種操作。比如map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort,partionBy等多種操作類型，Spark把這些操作稱為Transformations。同時(shí)還提供Count, collect, reduce, lookup, save等多種actions操作。
這些多種多樣的數(shù)據(jù)集操作類型，給給開發(fā)上層應(yīng)用的用戶提供了方便。各個(gè)處理節(jié)點(diǎn)之間的通信模型不再像Hadoop那樣就是唯一的Data Shuffle一種模式。用戶可以命名，物化，控制中間結(jié)果的存儲、分區(qū)等。可以說編程模型比Hadoop更靈活。
不過由于RDD的特性，Spark不適用那種異步細(xì)粒度更新狀態(tài)的應(yīng)用，例如web服務(wù)的存儲或者是增量的web爬蟲和索引。就是對于那種增量修改的應(yīng)用模型不適合。
容錯性。
在分布式數(shù)據(jù)集計(jì)算時(shí)通過checkpoint來實(shí)現(xiàn)容錯，而checkpoint有兩種方式，一個(gè)是checkpoint data，一個(gè)是logging the updates。用戶可以控制采用哪種方式來實(shí)現(xiàn)容錯。
可用性。
Spark通過提供豐富的Scala, Java，Python API及交互式Shell來提高可用性。
Spark與Hadoop的結(jié)合
Spark可以直接對HDFS進(jìn)行數(shù)據(jù)的讀寫，同樣支持Spark on YARN。Spark可以與MapReduce運(yùn)行于同集群中，共享存儲資源與計(jì)算，數(shù)據(jù)倉庫Shark實(shí)現(xiàn)上借用Hive，幾乎與Hive完全兼容。
Spark的適用場景
Spark是基于內(nèi)存的迭代計(jì)算框架，適用于需要多次操作特定數(shù)據(jù)集的應(yīng)用場合。需要反復(fù)操作的次數(shù)越多，所需讀取的數(shù)據(jù)量越大，受益越大，數(shù)據(jù)量小但是計(jì)算密集度較大的場合，受益就相對較小
由于RDD的特性，Spark不適用那種異步細(xì)粒度更新狀態(tài)的應(yīng)用，例如web服務(wù)的存儲或者是增量的web爬蟲和索引。就是對于那種增量修改的應(yīng)用模型不適合。
總的來說Spark的適用面比較廣泛且比較通用。
Spark是一個(gè)基于內(nèi)存計(jì)算的開源的集群計(jì)算系統(tǒng)，目的是讓數(shù)據(jù)分析更加快速。Spark非常小巧玲瓏，由加州伯克利大學(xué)AMP實(shí)驗(yàn)室的Matei為主的小團(tuán)隊(duì)所開發(fā)。使用的語言是Scala，項(xiàng)目的core部分的代碼只有63個(gè)Scala文件，非常短小精悍。
Spark 是一種與 Hadoop 相似的開源集群計(jì)算環(huán)境，但是兩者之間還存在一些不同之處，這些有用的不同之處使 Spark 在某些工作負(fù)載方面表現(xiàn)得更加優(yōu)越，換句話說，Spark 啟用了內(nèi)存分布數(shù)據(jù)集，除了能夠提供交互式查詢外，它還可以優(yōu)化迭代工作負(fù)載。
Spark 是在 Scala 語言中實(shí)現(xiàn)的，它將 Scala 用作其應(yīng)用程序框架。與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數(shù)據(jù)集。
盡管創(chuàng)建 Spark 是為了支持分布式數(shù)據(jù)集上的迭代作業(yè)，但是實(shí)際上它是對 Hadoop 的補(bǔ)充，可以在 Hadoop 文件系統(tǒng)中并行運(yùn)行。通過名為Mesos的第三方集群框架可以支持此行為。Spark 由加州大學(xué)伯克利分校 AMP 實(shí)驗(yàn)室 (Algorithms, Machines, and People Lab) 開發(fā)，可用來構(gòu)建大型的、低延遲的數(shù)據(jù)分析應(yīng)用程序。
Spark 集群計(jì)算架構(gòu)
雖然 Spark 與 Hadoop 有相似之處，但它提供了具有有用差異的一個(gè)新的集群計(jì)算框架。首先，Spark 是為集群計(jì)算中的特定類型的工作負(fù)載而設(shè)計(jì)，即那些在并行操作之間重用工作數(shù)據(jù)集（比如機(jī)器學(xué)習(xí)算法）的工作負(fù)載。為了優(yōu)化這些類型的工作負(fù)載，Spark 引進(jìn)了內(nèi)存集群計(jì)算的概念，可在內(nèi)存集群計(jì)算中將數(shù)據(jù)集緩存在內(nèi)存中，以縮短訪問延遲。
Spark 還引進(jìn)了名為彈性分布式數(shù)據(jù)集(RDD) 的抽象。RDD 是分布在一組節(jié)點(diǎn)中的只讀對象集合。這些集合是彈性的，如果數(shù)據(jù)集一部分丟失，則可以對它們進(jìn)行重建。重建部分?jǐn)?shù)據(jù)集的過程依賴于容錯機(jī)制，該機(jī)制可以維護(hù) "血統(tǒng)"（即允許基于數(shù)據(jù)衍生過程重建部分?jǐn)?shù)據(jù)集的信息）。RDD 被表示為一個(gè) Scala 對象，并且可以從文件中創(chuàng)建它；一個(gè)并行化的切片（遍布于節(jié)點(diǎn)之間）；另一個(gè) RDD 的轉(zhuǎn)換形式；并且最終會徹底改變現(xiàn)有 RDD 的持久性，比如請求緩存在內(nèi)存中。
Spark 中的應(yīng)用程序稱為驅(qū)動程序，這些驅(qū)動程序可實(shí)現(xiàn)在單一節(jié)點(diǎn)上執(zhí)行的操作或在一組節(jié)點(diǎn)上并行執(zhí)行的操作。與 Hadoop 類似，Spark 支持單節(jié)點(diǎn)集群或多節(jié)點(diǎn)集群。對于多節(jié)點(diǎn)操作，Spark 依賴于 Mesos 集群管理器。Mesos 為分布式應(yīng)用程序的資源共享和隔離提供了一個(gè)有效平臺。該設(shè)置充許 Spark 與 Hadoop 共存于節(jié)點(diǎn)的一個(gè)共享池中。
什么是Hive on Spark？修改
1.在Hive里設(shè)置hive.execution.engine=spark，然后在Hive CLI里執(zhí)行查詢Hive中的表。
2.在Spark程序中通過hiveContext.sql()查詢Hive中的表。
這兩種都是Hive on Spark嗎？還是說有什么區(qū)別
Hive有兩個(gè)execution backend, 一個(gè)是Tez, 另一個(gè)是MapReduce.
意思就是你的HiveQL語句的最終執(zhí)行程序可以選擇Tez或者M(jìn)apReduce.
Hive On Spark: 其實(shí)就是多一個(gè)Spark作為execution backend的選擇而已. 三者共生平行關(guān)系.
以下摘自Hive Official:
Here are the main motivations for enabling Hive to run on Spark:
1. Spark user benefits: This feature is very valuable to users who are already using Spark for other data processing and machine learning needs. Standardizing on one execution backend is convenient for operational management, and makes it easier to develop expertise to debug issues and make enhancements.
2. Greater Hive adoption: Following the previous point, this brings Hive into the Spark user base as a SQL on Hadoop option, further increasing Hive’s adoption.
3. Performance: Hive queries, especially those involving multiple reducer stages, will run faster, thus improving user experience as Tez does.
It is not a goal for the Spark execution backend to replace Tez or MapReduce. It is healthy for the Hive project for multiple backends to coexist. Users have a choice whether to use Tez, Spark or MapReduce. Each has different strengths depending on the use case. And the success of Hive does not completely depend on the success of either Tez or Spark.
你說的第二個(gè)是Spark On Hive:
可以理解為Hive外包了一層基于Spark的User Interface. 即通過Spark可以直接進(jìn)行Hive的相關(guān)操作: Hive Table , Hive UDFs, HiveQL等均可正常使用無誤.
這樣已經(jīng)有歷史遺留問題的Hive的相關(guān)資料也可以通過SparkSQL繼續(xù)使用.
如果是新的資料, 你想仍放在以Hive作為data warehouse的里面的話, 直接使用SparkSQL可以享用Spark針對RDD設(shè)計(jì)的相關(guān)優(yōu)化, 會比Hive On Spark的效能更好.
所謂Hive on Spark只是Hive項(xiàng)目的一個(gè)新特性，和Spark項(xiàng)目的開發(fā)沒啥關(guān)系。
針對你列的1和2的區(qū)別是：
1. 就是所謂的Hive on Spark，就是把hive執(zhí)行引擎換成spark。眾所周知的是這個(gè)engine還可以設(shè)置和成mr（MRv1時(shí)代）和tez（目前hive13默認(rèn)用的引擎，性能更佳），所以目前新增的spark選項(xiàng)只是Hive把執(zhí)行計(jì)劃放到spark集群上運(yùn)行而已。
2. 是Spark SQL的一個(gè)特性。就是可以把hive作為一個(gè)數(shù)據(jù)源，這樣我除了textFile從HDFS直接讀文件，還可以直接用HiveQL查詢到RDD，這對于要獲取保存在Hive表的數(shù)據(jù)太方便了。這個(gè)特性早就支持了，至少我在之前用Spark1.2的時(shí)候已經(jīng)可以從Hive里導(dǎo)入數(shù)據(jù)啦，最新的1.5新增了更多接口，用起來更方便了。
所以，簡單來說區(qū)別1是Hive調(diào)用Spark任務(wù)，2是Spark調(diào)用Hive任務(wù)。
1.Hive on Spark。主要是對mr的一種性能優(yōu)化（并不是所有場景都更好）
2.這個(gè)只是把hive當(dāng)數(shù)據(jù)源。和你在其它語言中訪問Hive沒有差別。
其實(shí)還有一種情況，在SparkSQL中訪問底層的Hive存儲。更像是Spark on Hive，但是其實(shí)也是當(dāng)作數(shù)據(jù)源而已。但是由于被隱藏在SparkSQL的配置中，看起來會覺得結(jié)合更緊密。
前者 是交互式的，后者是 應(yīng)用式的（本來想說 非交互式的，感覺還不夠?qū)I(yè)→_→）
關(guān)于Hadoop
官方文檔是最重要的
----------------------------------
Hadoop: the definitive guide
Hadoop in action
這兩本書還不錯
----------------------------------
http://allthingshadoop.com
Coursera上有一門UCSD開設(shè)的Big Data的專項(xiàng)課程
總共分五個(gè)課程，第一節(jié)大數(shù)據(jù)導(dǎo)論主要介紹的是大數(shù)據(jù)，hadoop是啥，有什么作用等等背景。
第二節(jié)是Map Reduce，HDFS，Spark等等的設(shè)計(jì)框架，實(shí)現(xiàn)機(jī)制等等，每一周后面還會有一個(gè)在虛擬機(jī)上用hadoop完成的小作業(yè)。比較初級的map reduce任務(wù)等等。
第三節(jié)是HBase Hive PIG等等更細(xì)一點(diǎn)的設(shè)計(jì)框架，實(shí)現(xiàn)機(jī)制，也都有對應(yīng)的小作業(yè)。
第四節(jié)是big data在機(jī)器學(xué)習(xí)里的應(yīng)用。
第五節(jié)還沒有開課。
每節(jié)課程都是4周，如果只是為了完成課程內(nèi)容的話還是比較簡單的，但是覆蓋的范圍挺廣的，這個(gè)課程適合作為引導(dǎo)去深入的了解big data，不會教你怎么去搭環(huán)境等等具體的問題，主要是講原理的，搭配官方文檔和其他更細(xì)致的資料服用更佳。反正對我這種沒有工程實(shí)踐的學(xué)生來說對了解big data 幫助很大。
在coursera上直接搜big data就可以了
我只能弱弱的說一句。。課程費(fèi)略貴。。
http://course.tuicool.com/course/tag/hadoop
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
總結(jié)
以上是生活随笔為你收集整理的zhihu spark集群,书籍,论文的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 手机游戏简要介绍
- 下一篇： 计算机组成原理--复习简答题+答案