zhihu spark集群,书籍,论文
spark集群中的節點可以只處理自身獨立數據庫里的數據，然后匯總嗎？
修改
我將spark搭建在兩臺機器上，其中一臺既是master又是slave，另一臺是slave，兩臺機器上均裝有獨立的mongodb數據庫。我是否可以讓它們只統計自身數據庫的內容，然后將結果匯總到一臺服務器上的數據庫里？目前我的代碼如下，但是最終只統計了master里的數據，另一個worker沒有統計上。val config = new Configuration() //以下代碼表示只統計本機數據庫上的數據，猜測問題可能出在這里 config.set("mongo.input.uri", "mongodb://127.0.0.1:27017/local.test") //統計結果輸出到服務器上 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讀取數據庫，然后將符合條件的數據載入RDD，由于之前設置了是將127.0.0.1作為輸入，也就是從driver的mongodb上讀取數據。由于driver就在master上，所以讀取的數據也自然就是master上的數據了。
怎么掌握HA下的Spark集群工作原理？
默認情況下，Standalone的Spark集群是Master-Slaves架構的集群模式，由一臺master來調度資源，這就和大部分的Master-Slaves結構集群一樣，存在著Master單點故障的問題。如何解決這個單點故障的問題呢？Spark提供了兩種方案：基于文件系統的單點恢復(Single-Node Recovery with Local File system)和基于zookeeper的Standby Masters(Standby Masters with ZooKeeper)。其中ZooKeeper是生產環境下的最佳選擇。
ZooKeeper提供了一個Leader Election機制，利用這個機制你可以在集群中開啟多個master并使它們都注冊到ZooKeeper實例，ZooKeeper會管理使其中只有一個是Active的，其他的都是Standby的，Active狀態的master可以提供服務，standby狀態的則不可以。ZooKeeper保存了集群的狀態信息，該信息包括所有的Worker，Driver 和Application。當Active的Master出現故障時，ZooKeeper會從其他standby的master中選舉出一臺，然后該新選舉出來的master會恢復掛掉了的master的狀態信息，之后該Master就可以正常提供調度服務。整個恢復過程只需要1到2分鐘。需要注意的是，在這1到2分鐘內，只會影響新程序的提交，那些在master崩潰時已經運行在集群中的程序并不會受影響。
下面我們就實戰如何配置ZooKeeper下的spark HA。
注：
DT_大數據夢工廠（IMF傳奇行動絕密課程）有所有大數據實戰資料
更多私密內容，請關注微信公眾號：DT_Spark
如果您對大數據Spark感興趣，可以免費聽由王家林老師每天晚上20：00開設的Spark永久免費公開課，地址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本地模式運行計算這個從本地讀的數據，是吧？修改 一個計算服務 HDFS只是輸入的一種 本地文件、隊列、Netcat 都可以作為輸入 咋就不能跑了另外 區分下YARN和HDFS YARN也不是必須依賴HDFS的 kafka，redis，mysql，都可以作為數據源。只要你能拉到數，管從哪拉呢？ 可以跑。
配置你每個節點上都存一份，或者放在 NFS 里。
數據你不從 HDFS 取就行了。? 可以集群方式運行。但是要求所有節點都能用同樣的路徑訪問到數據文件。解決方案一是在每個節點上的同樣路徑放上同樣的數據文件。解決方案二是采用網絡共享目錄和文件方式。比如linux的nfs方式共享。這兩種方法都比較麻煩，因此，還是用hdfs吧。 spark-standalone模式可以不啟動hdfs跑嗎
可以看看《為什么會有第一代大數據Hadoop和第二代大數據Spark？》這個視頻，深刻講解了spark和Hadoop的優缺點和hadoop和大數據的關系，觀點一針見血，分析的入木三分 相同的面料，都是基于MapReduce實現分布式計算，可能在面料選取（架構）或個別針線活上稍有些技巧性的區別。 Spark的實現略不同于Hadoop的是，Job中間輸出和結果可以保存在內存中，從而不再需要讀寫HDFS，因此Spark能更好地適用于數據挖掘與機器學習等需要迭代的MapReduce的算法。
要分開存儲和計算看這問題。
Hadoop中，hdfs已經算是大數據存儲的標配了，mr基本已淘汰（即便用hive都改tez了）。
數據分析和挖掘，spark已經是趨勢了。
Spark也能支持秒級的流式計算，但毫秒級的，還得用storm。
Hadoop還有個組件yarn，做資源管理調度的，spark可以運行在yarn上，也可以獨立運行（還）有種方式是運行在mesos上。 最近面試騰訊， 一面和二面都問起了hadoop和spark的區別和聯系， 回答的不太好。
應用場景： hadoop更擅長于離線批處理
spark更擅長于迭代處理。
但是 hadoop和spark的區別也在于 前者基于磁盤多次IO， 后者基于內存計算移動計算而非數據。需要注意的是hadoop和spark的Map / Reduce思想 以及其二者的shuffle過程。 我一直沒有講明白shuffle的過程。
Hadoop提供map和reduce算子，而spark提供了大量的transform和action算子，比Hadoop豐富。
提到大數據，就不能不提Hadoop和 Spark，那么作為大數據領域中的兩座大山，它們到底是什么？各自又有什么魅力呢？
1. Hadoop ，Spark為何物？
Hadoop是http://Apache.org的一個項目
Spark是一個運算速度快如閃電的Apache項目
一種軟件庫和框架
可跨計算器集群對龐大數據集(大數據)進行分布式處理
大數據分析領域的重量級大數據平臺
一種用于數據大規模處理的快速通用引擎
處理PB級別數據運算速度最快的開源工具
它有四個主要模塊：
1) Hadoop Common
2) Hadoop分布式文件系統(HDFS)
3) Hadoop YARN
4) Hadoop MapReduce
Spark核心組件可以和其他一些高效的軟件庫無縫連接使用
這些軟件庫包括：
SparkSQL
Spark Streming
MLlib(機器學習專用)
GraphX
Spark是一種集群計算框架，意味著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項目，是開源免費軟件產品
MapReduce使用常規數量的內存
Spark需要大量內存
需要速度更快的磁盤和大量磁盤空間來運行MapReduce
需要更多的系統，將磁盤輸入/輸出分布到多個系統上
使用常規數量的常規轉速磁盤
不使用磁盤輸入/輸入用于處理，已使用的磁盤空間可以用于SAN或NAS
Spark系統的成本更高，但技術減少了數量，最終結果是系統成本較高，但是數量大大減少
4.Hadoop與Spark的特性
? 數據處理方式
Hadoop MapReduce使用批量處理
Spark使用內存處理
不斷收集來自網站的信息，不需要這些數據具有實時性或近乎實時性
它在內存中處理一切數據，為來自多個來源的數據提供了近乎實時分析的功能
Hadoop MapReduce運行順序：集群讀取-執行操作-寫回到集群-讀取更新后的數據-執行下一個數據操作
Spark執行類似的操作，不過是在內存中一步執行：集群讀取-執行操作-寫回到集群
? 兼容性
在兼容性一點上，二者互相兼容，MapReduce通過JDBC和ODC兼容諸多數據源、文件格式和商業智能工具，Spark亦是如此。
? 容錯性
MapReduce
Spark
使用TaskTracker節點，它為 JobTracker節點提供了心跳(heartbeat)
用彈性分布式數據集(RDD)，它們是容錯集合，里面的數據元素可執行并行操作，使RDD可以引用外部存儲系統中的數據集，Spark可以用Hadoop支持的任何存儲源創建RDD ，Spark的緩存也具有容錯性。
? 可擴展性
MapReduce和Spark都可以使用HDFS來擴展
據目前所知，最大的Hadoop集群是42000個節點，可以說擴展無極限
最大的已知Spark集群是8000個節點，隨著大數據增多，預計集群規模也會隨之變大
? 安全性
Hadoop支持Kerberos身份驗證
Spark的安全性弱一點，目前只支持通過共享密鑰(密碼驗證)的身份驗證
能夠充分利用活動目錄Kerberos和LDAP用于身份驗證
在HDFS上運行Spark，它可以使用HDFS ACL和文件級權限
Hadoop分布式文件系統支持訪問控制列表(ACL)和傳統的文件權限模式，確保用戶擁有正確的權限
Spark可以在YARN上運行，因而能夠使用Kerberos身份驗證
事實上，Hadoop vs Spark并沒有真正的孰優孰劣，它們不是你死我活的關系，而是一種相互共生的關系，Spark幫助人們簡化了處理大規模數據的步驟流程，而Hadoop又提供了Spark所沒有的功能特性，可以說二者只有相輔相成，互利共生，才能夠為企業、為團隊提供更為有效的數據分析，為決策者提供更為有效的建議。
關于大數據的“大”，我想糾正一下大家的看法。
大數據不僅僅是大，它Bigger than big。如果是“大”，那么，多大才是大？PB？TB？
大數據的關鍵特性在于，區別于傳統的統計學，它處理的對象是數據的整體，而不是“樣本”。傳統的統計學，都是根據樣本來推測整體，免不了偏差——所以它有個概念叫做“顯著”（Confidence），告訴你，我針對樣本得出的結論，有多大把握對整體也是真的。
之所以會這樣，因為過去計算機科學不發達，數據的采集和計算都是大問題，只能抽樣。
現在不同了，數據的采集，存儲，計算都不是問題，為什么還要抽樣呢？因此，誕生了大數據概念，直接處理數據整體，而不是抽樣。
有了上述鋪墊，再舉個栗子。如果回答PB是大，OK，10PB算大了吧？是不是大數據？是。OK，那我告訴你，這10PB來自阿里，但只是其已處理數據量的1/10。那么，現在它還是不是大數據？
對比一下，一個中小型網站，每天只有10G的數據，是不是大數據？可能不是？OK，但這已經是他全部的數據量了。
大數據這個概念很寬泛，就類似于什么PC時代、互聯網、移動互聯網再到現在的大數據時代，一種技術不斷發展的時代浪潮而已，定義有很多，我認為可以這樣定義：以數據為中心更加精準的服務。你能想象到很多例子，如果不知道的話可以看《大數據時代》這本書。
而Hadoop、Spark都是處理大數據的一種技術手段，Spark由于是在內存中計算，速度要更快一些。還有很多其它處理大數據的方式，技術沒有最好只有最合適的。
1. 大數據，數據量至少在TB級別。
2. Hadoop是大數據處理的開源軟件，也是使用最廣的。
3. Hadoop的計算過程，大量使用磁盤存儲。Spark的計算，大量使用內存存儲，所以Spark塊。兩者并行。
4. spark支持從Hadoop的hdfs做數據輸入輸出。
5. Hadoop 2.x支持Spark作為一個組件。
Hadoop是一個基礎平臺，存儲有HDFS、資源調度有YARN、計算引擎有內置的MapReduce（跑在YARN上），Hadoop的HDFS、YARN是大數據系統的底層組件。
對于Spark，我從以下角度理解：
1. 是一種內存計算引擎，與MR是競爭關系，但效率比MR高。
2. 需要外部的資源調度系統來支持，可以跑在YARN上，也可以跑在Mesos上，當然可以用Standalone模式。
3. Spark核心計算引擎外圍有若干數據分析組件，Spark SQL（SQL接口）、Spark Streaming（流計算）、MLlib（機器學習）、GraphX（圖計算），“One Stack to rule them all”。
總體來說，Spark是跑在Hadoop上（依賴YARN和HDFS）的內存計算引擎，內置多種豐富組件，可以處理數據分析各個領域的問題。
大數據（Big Data）
大數據，官方定義是指那些數據量特別大、數據類別特別復雜的數據集，這種數據集無法用傳統的數據庫進行存儲，管理和處理。大數據的主要特點為數據量大（Volume），數據類別復雜（Variety），數據處理速度快（Velocity）和數據真實性高（Veracity），合起來被稱為4V。
大數據中的數據量非常巨大，達到了PB級別。而且這龐大的數據之中，不僅僅包括結構化數據（如數字、符號等數據），還包括非結構化數據（如文本、圖像、聲音、視頻等數據）。這使得大數據的存儲，管理和處理很難利用傳統的關系型數據庫去完成。在大數據之中，有價值的信息往往深藏其中。這就需要對大數據的處理速度要非常快，才能短時間之內就能從大量的復雜數據之中獲取到有價值的信息。在大數據的大量復雜的數據之中，通常不僅僅包含真實的數據，一些虛假的數據也混雜其中。這就需要在大數據的處理中將虛假的數據剔除，利用真實的數據來分析得出真實的結果。
大數據分析（Big Data Analysis）
大數據，表面上看就是大量復雜的數據，這些數據本身的價值并不高，但是對這些大量復雜的數據進行分析處理后，卻能從中提煉出很有價值的信息。對大數據的分析，主要分為五個方面：可視化分析（Analytic Visualization）、數據挖掘算法（Date Mining Algorithms）、預測性分析能力（Predictive Analytic Capabilities）、語義引擎（Semantic Engines）和數據質量管理（Data Quality Management）。
可視化分析是普通消費者常常可以見到的一種大數據分析結果的表現形式，比如說百度制作的“百度地圖春節人口遷徙大數據”就是典型的案例之一。可視化分析將大量復雜的數據自動轉化成直觀形象的圖表，使其能夠更加容易的被普通消費者所接受和理解。
數據挖掘算法是大數據分析的理論核心，其本質是一組根據算法事先定義好的數學公式，將收集到的數據作為參數變量帶入其中，從而能夠從大量復雜的數據中提取到有價值的信息。著名的“啤酒和尿布”的故事就是數據挖掘算法的經典案例。沃爾瑪通過對啤酒和尿布購買數據的分析，挖掘出以前未知的兩者間的聯系，并利用這種聯系，提升了商品的銷量。亞馬遜的推薦引擎和谷歌的廣告系統都大量使用了數據挖掘算法。
預測性分析能力是大數據分析最重要的應用領域。從大量復雜的數據中挖掘出規律，建立起科學的事件模型，通過將新的數據帶入模型，就可以預測未來的事件走向。預測性分析能力常常被應用在金融分析和科學研究領域，用于股票預測或氣象預測等。
語義引擎是機器學習的成果之一。過去，計算機對用戶輸入內容的理解僅僅停留在字符階段，不能很好的理解輸入內容的意思，因此常常不能準確的了解用戶的需求。通過對大量復雜的數據進行分析，讓計算機從中自我學習，可以使計算機能夠盡量精確的了解用戶輸入內容的意思，從而把握住用戶的需求，提供更好的用戶體驗。蘋果的Siri和谷歌的Google Now都采用了語義引擎。
數據質量管理是大數據在企業領域的重要應用。為了保證大數據分析結果的準確性，需要將大數據中不真實的數據剔除掉，保留最準確的數據。這就需要建立有效的數據質量管理系統，分析收集到的大量復雜的數據，挑選出真實有效的數據。
分布式計算（Distributed Computing）
對于如何處理大數據，計算機科學界有兩大方向：第一個方向是集中式計算，就是通過不斷增加處理器的數量來增強單個計算機的計算能力，從而提高處理數據的速度。第二個方向是分布式計算，就是把一組計算機通過網絡相互連接組成分散系統，然后將需要處理的大量數據分散成多個部分，交由分散系統內的計算機組同時計算，最后將這些計算結果合并得到最終的結果。盡管分散系統內的單個計算機的計算能力不強，但是由于每個計算機只計算一部分數據，而且是多臺計算機同時計算，所以就分散系統而言，處理數據的速度會遠高于單個計算機。
過去，分布式計算理論比較復雜，技術實現比較困難，因此在處理大數據方面，集中式計算一直是主流解決方案。IBM的大型機就是集中式計算的典型硬件，很多銀行和政府機構都用它處理大數據。不過，對于當時的互聯網公司來說，IBM的大型機的價格過于昂貴。因此，互聯網公司的把研究方向放在了可以使用在廉價計算機上的分布式計算上。
服務器集群（Server Cluster）
服務器集群是一種提升服務器整體計算能力的解決方案。它是由互相連接在一起的服務器群所組成的一個并行式或分布式系統。服務器集群中的服務器運行同一個計算任務。因此，從外部看，這群服務器表現為一臺虛擬的服務器，對外提供統一的服務。
盡管單臺服務器的運算能力有限，但是將成百上千的服務器組成服務器集群后，整個系統就具備了強大的運算能力，可以支持大數據分析的運算負荷。Google，Amazon，阿里巴巴的計算中心里的服務器集群都達到了5000臺服務器的規模。
大數據的技術基礎：MapReduce、Google File System和BigTable
2003年到2004年間，Google發表了MapReduce、GFS（Google File System）和BigTable三篇技術論文，提出了一套全新的分布式計算理論。
MapReduce是分布式計算框架，GFS（Google File System）是分布式文件系統，BigTable是基于Google File System的數據存儲系統，這三大組件組成了Google的分布式計算模型。
Google的分布式計算模型相比于傳統的分布式計算模型有三大優勢：首先，它簡化了傳統的分布式計算理論，降低了技術實現的難度，可以進行實際的應用。其次，它可以應用在廉價的計算設備上，只需增加計算設備的數量就可以提升整體的計算能力，應用成本十分低廉。最后，它被Google應用在Google的計算中心，取得了很好的效果，有了實際應用的證明。
后來，各家互聯網公司開始利用Google的分布式計算模型搭建自己的分布式計算系統，Google的這三篇論文也就成為了大數據時代的技術核心。
主流的三大分布式計算系統：Hadoop，Spark和Storm
由于Google沒有開源Google分布式計算模型的技術實現，所以其他互聯網公司只能根據Google三篇技術論文中的相關原理，搭建自己的分布式計算系統。
Yahoo的工程師Doug Cutting和Mike Cafarella在2005年合作開發了分布式計算系統Hadoop。后來，Hadoop被貢獻給了Apache基金會，成為了Apache基金會的開源項目。Doug Cutting也成為Apache基金會的主席，主持Hadoop的開發工作。
Hadoop采用MapReduce分布式計算框架，并根據GFS開發了HDFS分布式文件系統，根據BigTable開發了HBase數據存儲系統。盡管和Google內部使用的分布式計算系統原理相同，但是Hadoop在運算速度上依然達不到Google論文中的標準。
不過，Hadoop的開源特性使其成為分布式計算系統的事實上的國際標準。Yahoo，Facebook，Amazon以及國內的百度，阿里巴巴等眾多互聯網公司都以Hadoop為基礎搭建自己的分布式計算系統。
Spark也是Apache基金會的開源項目，它由加州大學伯克利分校的實驗室開發，是另外一種重要的分布式計算系統。它在Hadoop的基礎上進行了一些架構上的改良。Spark與Hadoop最大的不同點在于，Hadoop使用硬盤來存儲數據，而Spark使用內存來存儲數據，因此Spark可以提供超過Hadoop100倍的運算速度。但是，由于內存斷電后會丟失數據，Spark不能用于處理需要長期保存的數據。
Storm是Twitter主推的分布式計算系統，它由BackType團隊開發，是Apache基金會的孵化項目。它在Hadoop的基礎上提供了實時運算的特性，可以實時的處理大數據流。不同于Hadoop和Spark，Storm不進行數據的收集和存儲工作，它直接通過網絡實時的接受數據并且實時的處理數據，然后直接通過網絡實時的傳回結果。
Hadoop，Spark和Storm是目前最重要的三大分布式計算系統，Hadoop常用于離線的復雜的大數據處理，Spark常用于離線的快速的大數據處理，而Storm常用于在線的實時的大數據處理。 hadoop側重離線的批處理 而在應付流計算和迭代計算上略顯不足，因為hadoop的每次運算結果都要寫入文件系統，下次計算重新從文件系統讀進來，這就造成很大的IO開銷，
spark采用RDD的分布式內存抽象，是一棧的大數據解決方案，包括spark core、spark streaming、spark sql、mllib，目的是不是補充hadoop 而是取而代之
還有一個比較關注的是spark的數據庫，一個基于采樣的數據庫，可以在精度和效率上面權衡
轉一下馬鐵教授本人的回答：
Matei Zaharia's answer to Will Apache Spark ever overtake Apache Hadoop?
我自己的答案：
- MapReduce是和Spark并行的概念，兩者都是計算引擎。兩者的比較可以參見 Reynold Xin's answer to When is Hadoop MapReduce better than Spark? 。我傾向于這樣總結：Spark通過lineage這個核心思想實現了基于內存的輕量的容錯機制，取代了MR保守的硬盤數據冗余。
- Apache Hadoop系統其實就像一個操作系統。主要包含HDFS －相當于Linux下面的ext3,ext4，和Yarn － 相當于Linux下面的進程調度和內存分配模塊。
- Hadoop生態圈包括Apache Hadoop以及更上層的應用。在Spark／MapReduce這一層計算引擎上面，還可以加Hive來做SQL，各種流處理應用，等等。比如Hive就有on MapReduce和on Spark兩個版本。
- Spark不完全屬于Hadoop生態圈，它也可以脫離Apache Hadoop。比如用紅帽的Gluster FS做文件系統，Mesos做調度。但是從現在的情況來看它主要還是一個Hadoop應用。比如最近打破TeraSort紀錄（Spark officially sets a new record in large-scale sorting）就是基于HDFS做的。
- 大數據這個概念就模糊多了。但我覺得最起碼可以很安全的說 大部分的大數據應用運行在Hadoop生態圈里。
有什么關于 Spark 的書推薦？
Fei Dong | LinkedIn
Hadoop Spark學習小結[2014版]Hadoop
Hadoop社區依然發展迅速，2014年推出了2.3，2.4, 2.5 的社區版本，比如增強 Resource Manager HA, YARN Rest API, ACL on HDFS, 改進 HDFS 的 Web UI…
Hadoop Roadmap 根據我的觀察，主要更新在Yarn，HDFS，而Mapreduce幾乎停滯了，還有一些feature 屬于安全，穩定可靠性一方面是比較穩定了，但也可以說是瓶頸了。
Apache Hadoop Project Members
這個是Hadoop project member and committee, 里面好多來自Hortonworks，也有不少國人上榜。
SparkSpark 介紹Spark今年大放溢彩，Spark簡單說就是內存計算（包含迭代式計算，DAG計算,流式計算 ）框架，之前MapReduce因效率低下大家經常嘲笑，而Spark的出現讓大家很清新。
-
Reynod 作為Spark核心開發者, 介紹Spark性能超Hadoop百倍，算法實現僅有其1/10或1/100
-
淺談Apache Spark的6個發光點
-
Spark: Open Source Superstar Rewrites Future of Big Data
-
Spark is a really big deal for big data, and Cloudera gets it
其實起名字也很重要，Spark就占了先機，CTO說Where There’s Spark There’s Fire: The State of Apache Spark in 2014
Spark 起源2010年Berkeley AMPLab，發表在hotcloud 是一個從學術界到工業界的成功典范，也吸引了頂級VC：Andreessen Horowitz的 注資
AMPLab這個實驗室非常厲害，做大數據，云計算，跟工業界結合很緊密，之前就是他們做mesos，hadoop online, crowddb, Twitter，Linkedin等很多知名公司都喜歡從Berkeley找人，比如Twitter也專門開了門課程 Analyzing Big Data with Twitter 還有個BDAS (Bad Ass)引以為傲: The lab that created Spark wants to speed up everything, including cures for cancer
在2013年，這些大牛從Berkeley AMPLab出去成立了Databricks，半年就做了2次summit參會1000人，引無數Hadoop大佬盡折腰，大家看一下Summit的sponsor ，所有hadoop廠商全來了，并且各個技術公司也在巴結，cloudrea, hortonworks, mapr, datastax, yahoo, ooyala, 根據CTO說 Spark新增代碼量活躍度今年遠遠超過了Hadoop本身，要推出商業化產品Cloud。
Spark人物- Ion Stoica: Berkeley教授，AMPLab 領軍
- Matei Zaharia: 天才，MIT助理教授
- Reynold Xin Apache Spark開源社區的主導人物之一。他在UC Berkeley AMPLab進行博士學業期間參與了Spark的開發，并在Spark之上編寫了Shark和GraphX兩個開源框架。他和AMPLab同僚共同創建了Databricks公司
- Andy Konwinski
- Haoyuan Li
- Patrick Wendell
- Xiangrui Meng
- Paco Nathan
- Lian Cheng
- Hossein Falaki
- Mosharaf Chowdhury
- Zongheng Yang
- Yin Huai
- Committers
目前還有一些子項目，比如 Spark SQL, Spark Streaming, MLLib, Graphx 工業界也引起廣泛興趣，國內Taobao, baidu也開始使用：Powered by Spark
Apache Spark支持4種分布式部署方式，分別是Amazon EC2, standalone、spark on mesos和 spark on YARN 比如AWS
Spark Summit-
2014 Summit
-
取代而非補充，Spark Summit 2014精彩回顧
-
擁抱Spark，機遇無限——Spark Summit 2013精彩回顧
-
Databricks Cloud Demo 今年最叫好的demo是Dtabricks Cloud, 把Twitter上面實時收集的數據做作為machine learning素材，用類似IPython notebook，可視化呈現驚艷，而搭建整個sampling系統就花了20分鐘！
-
官方文檔
-
Databricks Blog
-
Summit Training
-
Databricks upcoming training
-
Stanford Spark Class
-
CSDN Spark專欄
10月份還有個培訓在灣區的培訓，只不過3天就要1500刀，看來做個講師也不錯:)
第三方項目- 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的技術挑戰
-
Hive原理與不足
-
Impala/Hive現狀分析與前景展望
-
Apache Hadoop: How does Impala compare to Shark
-
MapReduce：一個巨大的倒退
-
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源碼走讀
加州大學伯克利分校提出的mesos有哪些優缺點？ 作者：Weitao Zhou
鏈接：https://www.zhihu.com/question/20043233/answer/52708295
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
Docker Swarm與Apache Mesos的區別
summary:
Docker Swarm 是目前 Docker 社區原生支持的集群工具，它通過擴展 Docker API 力圖讓用戶像使用單機 Docker API 一樣來驅動整個集群；而 Mesos 是 Apache 基金會下的集群資源管理工具，它通過抽象主機的 CPU、內存、存儲等計算資源來搭建一套高效、容錯、彈性的分布式系統。
顯然，這兩者功能上有交集，網絡上也有很多關于 Docker Swarm, Mesos 和 Kubernetes 之間區別的討論，作為一個 Mesos 重度用戶，最近也抽時間把玩了下 Docker Swarm。一路下來，Docker Swarm 給我的感覺首先是它特別簡單、靈活，相較于 Mesos 而言， Docker Swarm 對集群的侵入性更小，從而資源損耗也更低；其次，我特別想強調的是目前看來，雖然它與 Mesos 之間功能有重疊，但是兩者關注在不同的東西上了，所以拿這兩者作比較沒有多大意義。當然，未來這種情況可能會發生變化，這取決于社區的 roadmap 。下面我會從多個角度把 Docker Swarm 和 Mesos 進行比較。
============================我是分割線======================
Docker大火，我們公司也在使用Docker+Mesos，給出些自己的看法。
歷史
先八卦一下Mesos的歷史，其實Mesos并不是為Docker而生的，它產生的初衷是為spark做集群管理。而且，Mesos有自己的容器隔離，后來，隨著Docker的崛起，Mesos就開始支持Docker容器了。再后來，google一哥們兒發了篇paper，對比google內部的borg(Omega?)，Mesos和Yarn（是不是Yarn）三個集群管理工具的性能，大致結論就是Mesos跟google內部的集群管理工具有異曲同工之妙。有了Docker助力，再加上google的paper，大家就開始去嘗試Mesos了。據我在網上搜羅的消息，國外的twitter，apple（用Mesos管理siri的集群），uber（uber的開發在Mesos的mail-list說他們已經使用Mesos有一段時間了，同時準備把更多的東西遷到Mesos集群上），國內的愛奇藝（視頻轉碼），數人科技（敝公司）都已經或正在使用Mesos集群。
優點
R 如何解決R在大樣本回歸中，內存不足問題？ 原因（據我的了解，可能有誤，但八九不離十）：任何數據類型在R中都和雙精度等價的。比如說你想保存一個boolean，但其實占用的內存和double是一樣的。其次R是copy by memory。如果matrix A用了1G內存，那么B=A就會占用2G內存。（這個問題我在使用parralel 作fork并行的時候尤為明顯。不知為何如果一個函數引用一個變量，會把那個變量在內存中復制一邊。最后我的解決方法是用了很多全局變量，然后函數不申明引用那個變量，在運算的時候直接調用。這樣做很危險，很難debug~）
解決方案：用C，python，（julia？）
他們都是copy by reference。 B=A后內存只會多一個指針。而且他們對內存有更精確的控制，作并行運算的時候可以共享主要的數據。甚至你可以用或者自己實現運算不一定那么快但是需要內存少的算法。
偷懶的辦法：既然是大樣本，假設你的sample size 很大。那么可以取一個subsample（隨機取一個子集，能放進內存就好）。 子集的結果和全部大樣本的結果應該差別不大。因為回歸的收斂速度還是挺快的么：）。 可不可以順便問下，有沒有什么可以auto variables selection的同時做time series的r package？ 如果你，必須用R不能用別的語言，也不能用什么高大上的H2O或者spark，還不能升級硬件，那么你可以借助一下bootstrap這種奇技淫巧：
1. 隨機采樣200次，每一次采樣20%的數據（當然200次和20%是我隨便說的，你自己看情況定）
2. 給每個小樣本作回歸，這樣你有200組參數
3. 取這200組參數的中位數作為解
如果你，必須用R不能用別的語言，也不能用什么高大上的H2O或者spark，還不能升級硬件，那么你可以借助一下bootstrap這種奇技淫巧：
1. 隨機采樣200次，每一次采樣20%的數據（當然200次和20%是我隨便說的，你自己看情況定）
2. 給每個小樣本作回歸，這樣你有200組參數
3. 取這200組參數的中位數作為解
CRAN - Package bigmemory
Michael Kane on Bigmemory
這個作者的一系列包，可以用shared memory來解決大數據集在R中的存儲分析問題。當然SparkR在服務器上也是解決方法，但是應該對于單機個人用戶big系列包應該是一個很好的解決方案。
同時請參考CRAN上的task view
CRAN Task View: High-Performance and Parallel Computing with R
中的Large memory and out-of-memory data一節，其中介紹了很多關于大數據集分析方法工具的軟件包。
插一張超大的閃存, 調成虛擬內存來用
超超超大的樣本, 就在aws雲端開個Spark集群, 用SparkR, 賦予每個橫列(row)一個隨機數後grouping可以實現抽樣出數個子集, 把要用的模型套到MapReduce, 看不同子集所擬合的參數分佈
SparkR (R on Spark)
換其他編程語言的方案已經有人提了
我給你個實際可行的方法就是，
租用Google或者Amazon的計算平臺，對于新用戶都有免費。比如我用Google，可以建一個虛擬機，用200G內存，總該滿足你需求了。
當然，這是短期的，如果經常要處理大規模數據，確實R并不是很合適。 基于spark的深度學習怎么實現，具體應用實例？ Spark 貌似不支持直接支持 深度學習吧，你可以通過 deeplearning4j與Spark整合來支持。你也可以參考這個：https://github.com/sunbow1/SparkMLlibDeepLearn
Apache Spark項目于2009年誕生于伯克利大學的AMPLab實驗室，當初的目的在于將內存內分析機制引入大規模數據集當中。在那個時候，Hadoop MapReduce的關注重點仍然放在那些本質上無法迭代的大規模數據管道身上。想在2009年以MapReduce為基礎構建起分析模型實在是件費心費力而又進展緩慢的工作，因此AMPLab設計出Spark來幫助開發人員對大規模數據集執行交互分析、從而運行各類迭代工作負載——也就是對內存中的同一套或者多套數據集進行反復處理，其中最典型的就是機器學習算法。
Spark的意義并不在于取代Hadoop。正相反，它為那些高度迭代的工作負載提供了一套備用處理引擎。通過顯著降低面向磁盤的寫入強度，Spark任務通常能夠在運行速度方面高出Hadoop MapReduce幾個數量級。作為“寄生”在Hadoop集群當中的得力助手，Spark利用Hadoop數據層（HDFS、HBase等等）作為數據管道終端，從而實現原始數據讀取以及最終結果存儲。
編寫Spark應用程序
作為由Scala語言編寫的項目，Spark能夠為數據處理流程提供一套統一化抽象層，這使其成為開發數據應用程序的絕佳環境。Spark在大多數情況下允許開發人員選擇Scala、Java以及Python語言用于應用程序構建，當然對于那些最為前沿的層面、只有Scala能夠實現大家的一切構想。
Spark當中的突出特性之一在于利用Scala或者Python控制臺進行交互式工作。這意味著大家可以在嘗試代碼運行時，立即查看到其實際執行結果。這一特性非常適合調試工作——大家能夠在無需進行編譯的前提下變更其中的數值并再次處理——以及數據探索——這是一套典型的處理流程，由大量檢查-顯示-更新要素所構成。
Spark的核心數據結構是一套彈性分布式數據（簡稱RDD）集。在Spark當中，驅動程序被編寫為一系列RDD轉換機制，并附帶與之相關的操作環節。顧名思義，所謂轉換是指通過變更現有數據——例如根據某些特定指標對數據進行過濾——根據其創建出新的RDD。操作則隨RDD自身同步執行。具體而言，操作內容可以是計算某種數據類型的實例數量或者將RDD保存在單一文件當中。
Spark的另一大優勢在于允許使用者輕松將一套RDD共享給其它Spark項目。由于RDD的使用貫穿于整套Spark堆棧當中，因此大家能夠隨意將SQL、機器學習、流以及圖形等元素摻雜在同一個程序之內。
熟悉各類其它函數型編程語言——例如LISP、Haskell或者F#——的開發人員會發現，除了API之外、自己能夠非常輕松地掌握Spark編程方式。歸功于Scala語言的出色收集系統，利用Spark Scala API編寫的應用程序能夠以干凈而且簡潔的面貌呈現在開發者面前。在對Spark編程工作進行調整時，我們主要需要考慮這套系統的分布式特性并了解何時需要對對象以及函數進行排序。
擁有其它程序語言，例如Java，知識背景的程序員則往往沒辦法快速適應Spark項目的函數編程范式。有鑒于此，企業可能會發現找到一位能夠切實上手Spark（從這個角度講，Hadoop也包含其中）的Scala與函數編程人員實在不是件容易的事。
<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能夠實現跨系統共享，因此大家能夠隨意將SQL、機器學習、流以及圖形等元素摻雜在同一個程序之內。
彈性分布式數據集
對于RDD的使用貫穿于整套堆棧當中，而這也成為Spark如此強大的根基之一。無論是從概念層面還是實施層面，RDD都顯得非常簡單; RDD類當中的大部分方法都在20行以內。而從核心角度看，RDD屬于一套分布式記錄集合，由某種形式的持久性存儲作為依托并配備一系列轉換機制。
RDD是不可變更的。我們無法對RDD進行修改，但卻能夠輕松利用不同數值創建新的RDD。這種不可變性算得上是分布式數據集的一大重要特性; 這意味著我們用不著擔心其它線程或者進程在我們不知不覺中對RDD數值作出了變更——而這正是多線程編程領域的一個老大難問題。這同時意味著我們能夠將RDD分發到整個集群當中加以執行，而不必擔心該如何在各節點之間對RDD內容變更進行同步。
RDD不可變性在Spark應用程序的容錯機制當中同樣扮演著重要角色。由于每個RDD都保留有計算至當前數值的全部歷史記錄、而且其它進程無法對其作出變更，因此在某個節點丟失時對RDD進行重新計算就變得非常輕松——只需要返回原本的持久性數據分區，再根據不同節點重新推導計算即可。（Hadoop當中的大多數分區都具備跨節點持久性。）
RDD能夠通過多種數據分區類型加以構成。在大多數情況下，RDD數據來自HDFS，也就是所謂“分區”的書面含義。不過RDD也可以由來自其它持久性存儲機制的數據所構成，其中包括HBase、Cassandra、SQL數據庫（通過JDBC）、Hive ORC（即經過優化的行列）文件乃至其它能夠與Hadoop InputFormat API相對接的存儲系統。無論RDD的實際來源如何，其運作機制都是完全相同的。
Spark轉換機制的最后一項備注是：此類流程非常懶惰，也就是說直到某項操作要求將一條結果返回至驅動程序，否則此前整個過程不涉及任何計算環節。這樣的特性在與Scala shell進行交互時顯得意義重大。這是因為RDD在逐步轉換的過程當中不會帶來任何資源成本——直到需要執行實際操作。到這個時候，所有數值才需要進行計算，并將結果返回給用戶。除此之外，由于RDD能夠利用內存充當緩存機制，因此頻繁使用計算結果也不會造成反復計算或者由此引發的資源消耗。
<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轉換機制非常懶惰，也就是說直到某項操作要求將一條結果返回至用戶處，否則此前整個過程不涉及任何計算環節。
執行Spark應用程序
為了將一項Spark任務提交至集群，開發人員需要執行驅動程序并將其與集群管理器（也被稱為cluster master）相對接。集群管理器會為該驅動程序提供一套持久性接口，這樣同一款應用程序即可在任何受支持集群類型之上實現正常運行。
Spark項目目前支持專用Spark（獨立）、Mesos以及YARN集群。運行在集群當中的每個驅動程序以各自獨立的方式負責資源分配與任務調度工作。盡管以隔離方式進行應用程序交付，但這種架構往往令集群很難高效實現內存管理——也就是對于Spark而言最為寶貴的資源類型。多個高內存消耗任務在同時提交時，往往會瞬間將內存吞噬殆盡。盡管獨立集群管理器能夠實現簡單的資源調度，但卻只能做到跨應用程序FIFO（即先入先出）這種簡單的程度，而且無法實現資源識別。
總體而言，Spark開發人員必須更傾向于裸機層面思維，而非利用像Hive或者Pig這樣的高級應用程序將數據分析作為思考出發點。舉例來說，由于驅動程序充當著調度任務的執行者，它需要最大程度與這些工作節點保持緊密距離、從而避免網絡延遲對執行效果造成的負面影響。
驅動程序與集群管理器高可用性這兩者都很重要。如果驅動程序停止工作，任務也將立即中止。而如果集群管理器出現故障，新的任務則無法被提交至其中，不過現有任務仍將繼續保持執行。在Spark 1.1版本當中，主高可用性機制由獨立Spark集群通過ZooKeeper實現，但驅動程序卻缺乏與高可用性相關的保障措施。
將一套Spark集群當中的性能最大程度壓榨出來更像是一種魔法甚至妖術，因為其中需要涉及對驅動程序、執行器、內存以及內核的自由組合及反復實驗，同時根據特定集群管理器對CPU及內存使用率加以優化。目前關于此類運維任務的指導性文檔還非常稀缺，而且大家可能需要與同事進行頻繁溝通并深入閱讀源代碼來實現這一目標。
<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應用程序架構。Spark目前可以被部署在Spark獨立、YARN或者Mesos集群當中。請注意，運行在集群當中的每一個驅動程序都會以彼此獨立的方式進行資源分配與任務調度。
監控與運維
每一款驅動程序都擁有自己的一套Web UI，通常為端口4040，其中顯示所有實用性信息——包括當前運行任務、調度程度、執行器、階段、內存與存儲使用率、RDD等等。這套UI主要充當信息交付工具，而非針對Spark應用程序或者集群的管理方案。當然，這也是調試以及性能調整之前的基礎性工具——我們需要了解的、與應用程序運行密切相關的幾乎所有信息都能在這里找到。
雖然算是個不錯的開始，但這套Web UI在細節方面仍然顯得比較粗糙。舉例來說，要想查看任務歷史記錄、我們需要導航到一臺獨立的歷史服務器，除非大家所使用的是處于獨立模式下的集群管理器。不過最大的缺點在于，這套Web UI缺少對于運維信息的管理與控制能力。啟動與中止節點運行、查看節點運行狀況以及其它一些集群層面的統計信息在這里一概無法實現。總體而言，Spark集群的運行仍然停留在命令行操作時代。
<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提供了與當前運行任務相關的豐富信息，但所有指向集群的管理操作則需要完全通過命令行來實現。
Spark對決Tez
事實上，Spark與Tez都采用有向無環圖（簡稱DAG）執行方式，這兩套框架之間的關系就如蘋果與桔子般不分軒輊，而最大的差別在于其受眾以及設計思路。即使如此，我發現很多IT部門仍然沒能分清這兩款框架間的差異所在。
Tez是一款應用程序框架，設計目的在于幫助開發人員編寫出更為高效的多級MapReduce任務。舉例來說，在Hive 0.13版本當中，HQL（即Hive查詢語言）由語言編譯器負責解析并作為Tez DAG進行渲染，即將數據流映射至處理節點處以實現高效執行。Tez DAG由應用程序以邊緣到邊緣、頂點到頂點的方式進行構建。用戶則完全不需要了解Tez DAG的構建方式，甚至感受不到它的存在。
Spark與Tez之間的真正差異在于二者實現方式的不同。在Spark應用程序當中，同樣的工作節點通過跨迭代實現重新使用，這就消除了JVM啟動所帶來的資源成本。Spark工作節點還能夠對變量進行緩存處理，從而消除對數值進行跨迭代重新讀取與重新計算的需要。正是借鑒著以上幾大特征，Spark才能夠在迭代編程當中如魚得水、充分發力。而由此帶來的缺點是，Spark應用程序會消耗大量集群資源、特別是在緩存過期的情況下。我們很難在集群運行著Spark的時候對資源進行優化。
盡管支持多級任務執行機制，Tez仍然不具備任何形式的緩存處理能力。雖然變量能夠在一定程度上得到緩存處理，從而保證規劃器在可能的情況下保證調度任務從同節點中的上一級處獲取必要數值，但Tez當中仍然未能提供任何一種經過妥善規劃的跨迭代或者變量廣播機制。除此之外，Tez任務還需要反復啟動JVM，而這會帶來額外的資源開銷。因此，Tez更適合處理那些規模極為龐大的數據集，在這種情況下啟動時間只占整體任務處理周期的一小部分、幾乎可以忽略不計。
在大多數情況下，Hadoop社區對此都擁有很好的移花接木式解決方案，而且其中最出色的部分機制已經能夠作用于其它項目。舉例來說，YARN-1197將允許Spark執行器以動態方式進行規模調整，這樣它們就能夠在合適的條件下將資源返還給集群。與之相似，Stinger.next將為Hive等傳統Hadoop應用程序帶來由跨查詢緩存提供的巨大優勢。
一整套集成化分析生態系統
Spark所采用的底層RDD抽象機制構建起整個Spark生態系統的核心數據結構。在機器學習（MLlib）、數據查詢（Spark SQL）、圖形分析（GraphX）以及流運行（Spark Streaming）等模塊的共同支持下，開發人員能夠以無縫化方式使用來自任意單一應用程序的庫。
舉例來說，開發人員可以根據HDFS當中的某個文件創建一個RDD，將該RDD轉換為SchemaRDD、利用Spark SQL對其進行查詢，而后將結果交付給MLlib庫。最后，結果RDD可以被插入到Spark Streaming當中，從而充當消息交付機制的預測性模型。如果要在不使用Spark項目的情況下實現以上目標，大家需要使用多套庫、對數據結構進行封包與轉換，并投入大量時間與精力對其加以部署。總體而言，將三到上個在最初設計當中并未考慮過協作場景的應用程序整合在一起絕對不是正常人的脆弱心靈所能承受的沉重負擔。
堆棧集成機制讓Spark在交互式數據探索與同一數據集內的重復性函數應用領域擁有著不可替代的重要價值。機器學習正是Spark項目大展拳腳的理想場景，而在不同生態系統之間以透明方式實現RDD共享的特性更是大大簡化了現代數據分析應用程序的編寫與部署流程。
然而，這些優勢的實現并非全無代價。在1.x系列版本當中，Spark系統在諸多細節上還顯得相當粗糙。具體而言，缺乏安全性（Spark無法運行在Kerberised集群當中，也不具備任務控制功能）、缺乏企業級運維功能、說明文檔質量糟糕，而且嚴苛的稀缺性技能要求意味著目前Spark仍然只適合早期實驗性部署或者那些有能力滿足大規模機器學習模型必需條件且愿意為其構建支付任何投入的大型企業。
到底應不應該部署Spark算是一個“仁者見仁，智者見智”的開放性議題。對于一部分組織而言，Spark這套速度極快的內存內分析引擎能夠帶來諸多優勢，從而輕松為其帶來理想的投資回報表現。但對于另一些組織來說，那些雖然速度相對較慢但卻更為成熟的工具仍然是其不二之選，畢竟它們擁有適合企業需求的完善功能而且更容易找到有能力對其進行管理與控制的技術人員。
無論如何，我們都要承認Spark的積極意義。Spark項目將一系列創新型思維帶入了大數據處理市場，并且表現出極為強勁的發展勢頭。隨著其逐步成熟，可以肯定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軟件基金會
總結性描述
作為一套配備精妙API以實現數據處理應用程序創建目標的高速內存內分析引擎，Spark在迭代工作負載這類需要重復訪問同一套或者多套數據集的領域——例如機器學習——表現出無可匹敵的競爭優勢。
基于Apache 2.0許可的開源項目
優勢
? 精妙且具備一致性保障的API幫助開發人員順利構建起數據處理應用程序
? 支持Hadoop集群上的交互式查詢與大規模數據集分析任務
? 在運行迭代工作負載時擁有高出Hadoop幾個數量級的速度表現
? 能夠以獨立配置、YARN、Hadoop MapReduce或者Mesos等方式部署在Hadoop集群當中
? RDD（即彈性分布式數據集）能夠在不同Spark項目之間順利共享，從而允許用戶將SQL、機器學習、流運行以及圖形等元素摻雜在同一程序當中
? Web UI提供與Spark集群及當前運行任務相關的各類實用性信息
缺點
? 安全性不理想
? 說明文檔質量糟糕
? 不具備集群資源管理能力
? 學習曲線不夠友好
熱愛大數據的話歡迎加我們信微：idacker
我被這東西快弄瘋了…… 半年內版本升級到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已經被官方拋棄了，連官方下載鏈接都沒有，2.x的版本，最古老的鏈接也是2.5.2的。0.13.1的hive的確有，可是人家都1.1了啊，好多東西都變了啊，網上連教程都變了啊。
回頭再說SparkSQL，他只是Spark的一個Module，可是卻要依賴這么多，還要依賴Scala，還要特定2.10.4版本，還要依賴hive，hive要依賴yarn，mapreduce又是必須的……
在網上各種爬文，我都買了個DigitalOcean服務器來搜外文，結果搜到的也還是古老的，揮著零散的部署教程，就是要么只告訴你spark怎么部署，要么告訴你sparksql怎么用，要么告訴你hive怎么搭，然后各個版本還不能依賴到一起去…
做畢設都半年了，前期就是寫sql代碼來著，最后就靠這玩意來加速跑代碼，結果死活搭不起來，去年弄了半個月，不行，今年這有弄了半個月，還不行……真是醉了……
求哪位大神快出現啊！！！ T_T 我真是跪了…… 給我個從頭到尾搭起 SparkSQL 的教程就行…… 么么噠……
作者：紀路鏈接：https://www.zhihu.com/question/29585524/answer/44883019
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
把Spark二進制包下載并解壓到某一臺*nux的機器上，這段代碼中‘/Users/jilu/Downloads/’這段換成你自己的路徑，這就是單機執行SparkSQL的代碼，在這個程序中，我已經創建好sqlContext了，以后的部分就是SparkSQL教程了。這是我更新完1.3版之后新改的程序，不出意外1.X的版本都是這樣用的。
PS：補充一下這個是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讀數據庫數據您用過嗎？我沒有成功，但是Scala和Java可以通過jdbc讀到數據。求助，謝謝！
我也是用Scala，我記得Spark的數據輸入輸出那一塊Python支持的不太好，除了RESTful和文件之外Python API不是沒有就是有問題。
你也可以使用Spark Standalone模式（文檔https://spark.apache.org/docs/latest/spark-standalone.html），官方又啟動腳本，直接幫你完成所有的部署，不需要Hadoop，不需要Hive，不需要MySQL
vm問題是太損性能
如果集群要nb的機器
＊＊＊測試環境
用docker好些 機器損耗小 普通macmini都可以搭出hadoop／spark最小三節點集群
參考
使用docker打造spark集群
＊＊＊生產環境
未來生產環境部署hadoop／spark到物理機 應該情景不多
多是云端的大數據處理paas例如azure的hdinsight
（當然云端也可以用docker）
節省成本 少維護 少硬件損耗（aws azure的數據流入流量都是不計費的）
盡快上算法／應用才是王道
spark在aws上已經能做到1tb數據－》1rmb成本了
基本大數據的運算量12tb 的spark運算成本是12rmb（節點無限伸縮）
按照這個成本 自建hadoop／spark集群的硬件意義不大
（這個百節點要上百萬還有維護損耗
頂級國安或者軍事金融部門的需求另說
當然如果有采購貪污需求的也另說
其它行業正經做事不用云處理大數據是傻蛋）
問題是大數據的場景何在
weblog 達到12tb／天的網站中國過不去10家
SparkSQL就是Spark的一個模塊，只要成功安裝了Hadoop和Spark，最后開發的時候在pom文件里加上SparkSQL的依賴，并且在代碼里引SparkSQL的包就行了，所以關鍵還是搭Hadoop和Spark的集群，Hadoop2.6.0（現在已經出到2.7了）和Spark1.3.1的搭建教程網上都可以找到，照著教程一步步做就行了
想快速建立一個hadoop+spark的環境， 你可以直接裝cloudera 的 CDH。 他們把上面一切都很好的整合在一起了。如果還想更簡單一點，裝一個cloudera 的quickstart 虛擬機， Cloudera QuickStart VM。 一個虛擬機，什么都有了。
不好意思，我沒有在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.**
如果沒有理解錯的話，應該是CDH已經包含了，只是不提供官方支持。另外Spark 1.3 對Spark SQL有重大更新，引入了Data Frame RDD，以更好地支持結構化數據。
再補充一點，Spark 并不是一定要綁定Hadoop，如果你僅僅是學習用，不打算把數據放到HDFS上， 你從github上下一個最新版的spark，編譯一下就可以了。 還是裝 hortonworks 發行的 hadoop吧，社區版本更新更快，組件更全，安裝配置更簡易。試用的話，直接下 sandbox虛擬機文件
hadoop,spark在虛擬機集群里跑還有性能上的優勢嗎?修改
如題，系統搭建在公司的虛擬機集群上，這樣還有木有性能上的優勢?或者說這樣搭建分布式計算系統還有意義么?反正最終都是服務器的內存和硬盤，我感覺用多線程，多進程的老方法，直接在服務器上跑，省去那些集群間的調度和網絡io，是不是會更快一些？
小白不懂,求大俠相助
作為分布式計算平臺，性能是非常重要的一個指標，但絕對不是唯一一個指標。單純從性能角度上來講，硬件資源固定，虛擬化增大了開銷，必然有所降低。但是虛擬化會帶來一些其他方面的功能。
問題中談到了性能，當然虛擬化的引入比裸奔性能上一定會有影響，如果影響很大的話，在做架構設計的時候就要根據實際需求進行取舍；然而比如像container，docker等輕量級虛擬化技術的出現，使它對性能的影響被壓縮到了一個很小的地步，對于大多數分布式系統來說，這點性能損耗并不會有太大的影響……然后你懂的…… 性能問題在hadoop虛擬化里其實是個次要問題，雖然也確實性能差。
更重要不要做虛擬化的原因是你的很多hadoop虛擬機很有可能其實是跑在一臺物理服務器上的，那這臺物理服務器宕機就會導致整個集群不可用。
另外，虛擬化也可能使用的是共享存儲，那么這樣會讓hadoop內建的冗余機制變得毫無意義。
第三，虛擬化里，你無法劃分正確的機架來讓hadoop合理的分布數據塊存放位置。
最后，虛擬化的網絡是軟件定義的，底層發生問題你很難對hadoop定位和排錯。
這些才是不要用虛擬化最重要的原因，排除這些才談到性能問題。
當然曾經也有人跟我抬杠，說一臺服務器只做一個虛擬機不就好了嗎？可問題是，你要這樣做的話為什么不直接裝hadoop，非要為了部署方便而白白浪費掉30%的性能呢。每三臺服務器就會浪費掉一臺物理機的計算能力，代價太大了，除非土豪的國企或政府，否則沒人會這么干。
確實沒有必要虛擬，Hadoop和spark都是可以單機跑的。如果你的服務器只有一個node，那么單機跑要快很多。
我同意樓上?@楊甬舟的說法。虛擬機或者容器來跑Hadoop和Spark，最大的優勢就是在于方便部署和管理，并且共有云服務提供商可以提供彈性的服務，現在Databricks和Amazon，甚至國內的青云都提供了Spark虛擬機集群服務。我覺得虛擬化主要是針對大型云服務提供商而言的，集群的快速部署和便捷管理服務是很有市場的，不管是科研還是生產環境。在此基礎上我想補充一下：
1. 性能的隔離是有必要的，不然就會相互干擾，單個物理節點下用多線（進）程的方式的確從直觀上性能是比虛擬化后要好，但是虛擬機帶來的好處就是，一個服務器上可以跑多個集群，這些虛擬機可以分屬于不同的集群。你怎么在一臺服務器上裸奔多個Spark集群呢？
2. 虛擬化技術作為云計算的基礎，有其優勢，它可以提供彈性資源服務，總體上是可以提高硬件使用率的，性能和資源使用率之間是存在一個tradeoff的。
3. 在按時間的計費模式下，像Spark這種對內存和CPU使用率較高的集群，部署到公有云中性價比較高。
另外一點，Hadoop部署到虛擬機集群中也已經有很多很多成熟的研究成功和工業產品，至于性能，據前Spark團隊leader明風透露，阿里巴巴內部曾經試驗過，大概性能損耗10%，這在大規模分布式系統中，和數據中心資源利用率比起來，應該不足為道。
其實要看你們公司想怎么搞了，要是這些機器就用來跑你的這個集群，那就裸奔試試看唄，不然的話，虛擬化還是有存在的必要的。
另外，傳送門
[1]Three reasons you need to run Spark in the cloud
[2]Databricks Cloud: Making Big Data Easy hadoop的關鍵在io
spark的關鍵在內存
虛擬機，沒錯，跑當然能跑，尤其作為測試環境，但是扯得蛋真的很疼，是真的很疼的那種
如果生產環境資源有限，spark可以放在vm中跑，只要載入數據時注意點； Hadoop就盡量在物理機上面跑吧，節點少點比n個vm都強太多
經驗之談，你在太平洋攢10臺pc遠比你買一臺hp的2U跑虛擬機讓Hadoop來得暢快
我們用的是hp的2U機器25塊900gb硬盤物理機作為節點來跑的，酸爽
推薦用docker搭建你的集群，真是太方便了。大數據是一個知識體系，不僅僅是spark，你其實應該學的還包括，文件系統hdfs，Nosql，我推薦的是Cassandra，分布式消息隊列，比如kafka，由于kafka綁定了zookeeper，所以zk也少不了。流式處理越來越重要，storm雖然很不錯，但spark streaming由于能夠和spark sql，mllib無縫整合，所以更加推薦。最后你會發現搭建可以拿來學習的開發環境是相當頭疼的。那么，學習docker吧，github上有大量配置好的鏡像可以供你使用。可以任意組織你期望的集群。所有一切都可以跑在一臺單機上。總之，docker是學習大數據的終極利器。
docker是最近很熱的microservices的基礎，很多產品級的服務都已經遷移的docker上了，所以docker可以說基本成熟了。另外docker容器對宿主機來說就是一個進程而已，內核級的開銷很小，所以和創建一個虛擬機比，怎么會消耗更多內存呢？另外，對于學習目的的集群，穩定性真的這么重要嗎？ 我們用4核8G x86跑HDP鏡像，在dock中啟動6個container，兩個namenode，四個datanode。基本上每次跑mapreduce都會失敗，提示network refused，虛擬內存達到4個G。最后不得不destroy container再rebuild，導致hdfs上結果文件丟失，需要重新跑。每次執行都提心吊膽。最后，還是換成單機鏡像了。。
用 standalone 的方式跑不挺好，大部分人的機子跑不起 spark 的
用standlone模式當然也可以，但是如果能模擬集群的運行狀態，豈不是更好。畢竟真正的應用都是跑在集群上的。spark版本演進很快，用docker驗證一個新版本，是非常方便的。它不會干擾你主機上跑的任何東西。
1）學搭建用docker鏡像意義不大 2）作為開發環境，你哪怕執行個 wordcount 無論數據多少，那速度，調試到你奔潰；不論 lxc 還是虛擬機，性能都強不過宿主機（更何況大部分人的開發機是 windows，先搭個 vbox ，再在上面搭個docker），spark 在哪跑更快，可想而知
docker的好處一是你可以試錯，spark新版本出來了，你可以跑跑看，不會影響你現有的環境。第二是你可以搭配其它docker，比如kafka，比如Nosql用。組成一個更接近生產系統的真實大數據環境。
我當然是裝過才這么說的。單機處理能力擺在那里，根本不應該拿來跑完整的數據集，你可以采樣以后跑。但是在單機上，我們要驗證算法的正確性。所以模擬一個近生產系統的環境還是有必要的。
感覺目前在大集群管理系統中，應用docker做資源隔離容器（替代系統級進程或JVM進程）的要比用docker搭建集群更多些，因為docker本身的特性，使得支持docker容器的資源管理框架能夠支持更多類型的應用（例如Web）。之前也看多不少hadoop on docker的文章、dockerfile，但實際上由于docker在文件系統上還是存在不足的，所以也鮮見實際應用的。在各種傻瓜式部署軟件例如cdh、cloudera manager的幫助下，環境的搭建反而不那么困難。在生產環境docker on hadoop的意義應當遠勝于hadoop on docker，不過對于初學者學習而言，或許算是一個不錯的選擇，足夠直觀簡潔。個人淺見~
承蒙各位捧場，給贊，我想把我的回答再澄清一下。首先，我想回答的問題是大數據學習者如何搭建一個學習環境。并不是如何搭建一個生產環境。實驗和生產環境是有很大區別的。docker目前可能還不太適合用于生產環境，但是用于實驗是絕對沒有問題的，而且非常方便，搭建快速。github什么有很多例子，大家可以參考借鑒一下。
關于學好大數據處理框架，我這里這樣假設：
關于機器配置，其實也不用太夸張，這無非又是給自己的惰性找個借口罷了，主流能跑得動LOL的機器都能滿足你基本的測試學習需要了，實在不行就壯士斷腕放棄游戲直接把系統裝成linux……所以關鍵還是你學習欲望是否強烈的問題。
當然其實也沒有那么簡單，大數據量和小數據量畢竟有本質上的區別，根本就是兩個世界的東西，處理100M和100T數據的區別不只是時間長短、節點多少的問題，有些問題只有在大規模數據處理時才會遇到，能夠解決好這類問題的人就很厲害了，也是這行門檻所在。
那么重點我想談談的是第二個情況：假設你想學好框架。
Hadoop 和Spark發展到了今天，都已經不僅僅是一個計算框架了，而使已經演化成了生態完整的系統，很多這個行業最優秀的程序員為它們做了貢獻。贊美開源世界，這些代碼對你都是Open的，那么就去閱讀好了，帶著目的的那種。比如你看到了spark standalone的任務提交流程代碼，那么為什么它這么搞？能從中借鑒什么？假設哪天自己要設計一個別的分布式系統時是否能夠參考？有什么優缺點？這些東西我認為在沒有集群的情況下都是能夠做的。
假設有這樣的積累，當開始工作時，你放心：任何系統都會出現問題，當問題發生時對你來說應該一切都是脈絡清晰的；任何系統都不可能滿足所有需求，當新需求spark/hadoop或者其他什么的滿足不了需求時需要重新開發或者改造時，你應該使思路活躍的，應該是能夠直擊問題關鍵點的。當然這些鍛煉在沒有集群和實際操作的情況下是很難做到的，但可以先做好準備。
我定義學好，在于系統的每個動作對你來說都是很清晰的，你知道它做這個動作的理由，它的實現方法，這個動作產生的影響，可能會出現問題的點……我比較笨，大概只能想到好好積累這一種手段……
如果你只是學習怎么用hadoop和spark單機跑就是了。如果你非要用cluster，去組一個就是了。這么多提供cloud服務的公司呢，也不貴。國內用阿里，國外Amazon的EC2和Google的GCP都行。
可能對vagrant docker完全不了解？
如果你只是學習怎么用hadoop和spark單機跑就是了。如果你非要用cluster，去組一個就是了。這么多提供cloud服務的公司呢，也不貴。國內用阿里，國外Amazon的EC2和Google的GCP都行。
作者：Wayne Shi
鏈接：https://www.zhihu.com/question/37026972/answer/87828727
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
Spark雖然是大規模的計算框架，但也支持在單機上運行，對于入門學習者而言，單機環境已經足夠。實驗樓Spark訓練營Hadoop - Spark 大數據動手實驗第一節提供了免費的在線Spark學習環境。
<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 安裝前準備
安裝Spark之前需要先安裝Java，Scala及Python。
安裝Java實驗樓環境中已經安裝了JDK，這里打開桌面上的Xfce終端，執行查看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">可以看到實驗樓的Java版本是1.8.0_60，滿足Spark 1.5.1對Java版本的要求。
如果需要自己安裝可以在Oracle的官網下載Java SE JDK，下載鏈接：Java SE - Downloads。
安裝Scala老版本的Spark安裝前需要先裝Scala，1.5.1版本可以無需這一步驟。但為了自己開發Scala程序調試的方便我們仍然安裝一個最新版本2.11.7的Scala。
Scala官網下載地址：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">由于官網速度很慢，我們預先上傳到了實驗樓內網，下載并解壓到/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
安裝執行命令：
sudo apt-get update sudo apt-get install python ipython實驗樓中已經安裝了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下載
課程中使用目前最新穩定版：Spark 1.5.1，官網上下載已經預編譯好的Spark binary，直接解壓即可。
Spark官方下載鏈接：Downloads | Apache Spark
下載頁面中我們如下圖選擇Pre-build for Hadoop 2.6 and later并點擊下載：
<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">為了節約時間，我們選擇從阿里云的鏡像下載：
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/進入到spark目錄查看目錄結構，本節實驗中會用到bin/目錄下的操作命令以及conf/目錄下的配置文件。
1.3 配置路徑與日志級別
為了避免每次都輸入/opt/spark-1.5.1-bin-hadoop2.6這一串前綴，我們將必要的路徑放到PATH環境變量中（實驗樓用的是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我們進入到spark的配置目錄/opt/spark-1.5.1-bin-hadoop2.6/conf進行配置：
# 進入配置目錄 cd /opt/spark-1.5.1-bin-hadoop2.6/conf# 基于模板創建日志配置文件 cp log4j.properties.template log4j.properties# 使用vim或gedit編輯文件log4j.properties # 修改log4j.rootCategory為WARN, console，可避免測試中輸出太多信息 log4j.rootCategory=WARN, console# 基于模板創建配置文件 sudo cp spark-env.sh.template spark-env.sh# 使用vim或gedit編輯文件spark-env.sh # 添加以下內容設置spark的環境變量 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時加載，內容包含很多配置選項及說明，在以后的實驗中會用到少部分，感興趣可以仔細閱讀這個文件的注釋內容。
至此，Spark就已經安裝好了，Spark安裝很簡單，依賴也很少。
后續幾節介紹簡單的Spark操作，為以后的實驗做基礎。
1.4 Spark-Shell
Spark-Shell是Spark自帶的一個Scala交互Shell，可以以腳本方式進行交互式執行，類似直接用Python及其他腳本語言的Shell。
進入Spark-Shell只需要執行spark-shell即可：
spark-shell進入到Spark-Shell后可以使用Ctrl D組合鍵退出Shell。
在Spark-Shell中我們可以使用scala的語法進行簡單的測試，比如下圖所示我們運行下面幾個語句獲得文件/etc/protocols的行數以及第一行的內容：
<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">上面的操作中創建了一個RDD file，執行了兩個簡單的操作：
- count()獲取RDD的行數
- first()獲取第一行的內容
我們繼續執行其他操作，比如查找有多少行含有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">查看一共有多少個不同單詞的方法，這里用到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">上面兩步驟我們發現，/etc/protocols中各有一行含有tcp與udp字符串，并且一共有243個不同的單詞。上面兩步驟我們發現，/etc/protocols中各有一行含有tcp與udp字符串，并且一共有243個不同的單詞。上面每個語句的具體含義這里不展開，可以結合你閱讀的文章進行理解，后續實驗中會不斷介紹。Scala的語法我們在后續實驗中會單獨學習，這里僅僅是提供一個簡單的例子讓大家對Spark運算有基本認識。
操作完成后，Ctrl D組合鍵退出Shell。
pysparkpyspark類似spark-shell，是一個Python的交互Shell。
執行pyspark啟動進入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，執行命令：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語法執行spark-shell中的操作，比如下面幾個語句獲得文件/etc/protocols的行數以及第一行的內容：
<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。在后續的實驗中我們將大量使用python和scala的交互式shell，可以及時的獲得實驗結果，實驗重在理解原理，內容將很少涉及Java的內容，如果你對Java很熟悉可以參考后續的實驗代碼練習。
2. 啟動spark服務
這一節我們將啟動spark的master主節點和slave從節點，這里也會介紹spark單機模式和集群模式的部署區別。
2.1 啟動主節點執行下面幾條命令啟動主節點：
# 進入到spark目錄 cd /opt/spark-1.5.1-bin-hadoop2.6# 啟動主節點 ./sbin/start-master.sh沒有報錯的話表示master已經啟動成功，master默認可以通過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中暫時還沒有一個worker，我們啟動worker時需要master的參數，該參數已經在上圖中標志出來：spark://7a1e9a46bf54:7077，請在執行后續命令時替換成你自己的參數。
2.2 啟動從節點執行下面的命令啟動slave
./sbin/start-slave.sh spark://7a1e9a46bf54:7077沒有報錯表示啟動成功，再次刷新firefox瀏覽器頁面可以看到下圖所示新的worker已經添加：
<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命令查看啟動的服務，應該會列出Master和Slave。
2.3 測試實例使用pyspark連接master再次進行上述的文件行數測試，如下圖所示，注意把MASTER參數替換成你實驗環境中的實際參數：
<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">當退出pyspark時，這個application會移動到Completed Applications一欄。
可以自己點擊頁面中的Application和Workers的鏈接查看并了解相關信息。
2.4 停止服務停止服務的腳本為sbin/stop-all.sh，運行時需要輸入shiyanlou用戶的密碼，因為腳本中使用ssh遠程對slave節點進行管理：
cd /opt/spark-1.5.1-bin-hadoop2.6 ./sbin/stop-all.sh 2.5 集群部署上面的步驟介紹了我們在單機狀態Standalone Mode下部署的spark環境，如果要部署spark集群稍有區別：
那些說單機的，誰都知道可以單機跑，但是，在單機和集群搭建一個可以使用的環境是完全不一樣的，而且，有很多bug在單機環境下是無法觸發的。所以很多時候你在單機上能跑的代碼在集群上是會不斷報錯的。學習不是只是知道的就行。
沒有集群環境，可以單機跑應用，但是還是沒有解決學習大數據平臺處理框架的問題。
我覺得有幾個方面，可以給你參考：
1、你需要一個比較強勁的機器，內存/CPU要稍大一些，這些大數據的家伙都是吃資源的；
2、你可以選擇采用虛擬化技術，比如VMware，VirtualBox，多跑幾個linux，應該問題不大；
3、你還可以選擇最近比較流行的Docker技術，很大程度上比虛擬化要便捷的多；
4、你還可以很土豪，買很多實體機，選擇用Ambari搭建一個真實的hadoop環境，我覺得那樣你會學得更快。
Sequence IQ, DataStax, Cloudera有很多已經build 好的Docker images. Dockerhub上可以搜一下 用AWS的EMR吧，好處是你可以快速的跨過技術搭建環節開始關注商業價值。 集群環境更多的是為了生產環境。如果要學習相關知識的話，單機偽分布式完全是可以的。hadoop的話，建議讀hadoop權威指南，了解hadoop處理數據的各個流程，做一些基本的練習。 下載CDH鏡像文件，在虛擬機里面偽分布式執行hadoop。需要注意，增加本機內存至少到8G，hadoop尤其spark是吃內存大戶。 推薦《深入理解Spark》 OReilly .Learning Spark. 推薦我去看官方文檔。因為spark更新太快了，推薦直接去Apache spark 社區去看官方文檔 推薦 <Advanced.Analytics.with.Spark>, OReilly出版的,
這不是一本入門書,主要是講ML這一塊。
但這本書并不難讀，里面每一章都是實例，還提供數據源，
很方便動手實踐，通過這些“非玩具”的例子可以更好的學習
使用spark。 推薦幾個資料，是我最近在看的。
第一個是Apache Spark源碼剖析 (豆瓣)，這本書雖然照抄源碼，但是我覺得盯著電腦看源碼比較累（摔~~~）
第二本是Spark大數據處理：技術、應用與性能優化 (豆瓣) ，貌似評價不好，但是適合入門使用
但是，如果想徹底搞明白的話還是建議閱讀官方doc，幾篇論文啃下來比較好。Introduction 翻譯比較好的開發手冊也可以參照一下 推薦?《深入理解SPARK：核心思想與源碼分析》，此書適合Spark已經入門的讀者閱讀，對于熱愛源碼的人也是不錯的選擇，目前，此書是國內介紹Spark最全面的一本書，對于原理有深層次的解析。 《大數據Spark企業級實戰》http://item.jd.com/1443682720.html
本書共包括14章，每章的主要內容如下。
第1章回答了Spark為何是大數據處理平臺的必然選擇？Spark速度如此之快的原因是什么？Spark的理論基石是什么？Spark具體是如何僅僅使用一個技術堆棧解決多元化的大數據處理的需求的？
第2章回答了如何從零起步構建Hadoop集群？如何在Hadoop集群的基礎上構建Spark集群？如何測試Spark集群？
第3章回答了如何在IDEA集成開發環境中開發并運行Spark程序？如何在IDA中開發Spark代碼并進行測試？
第4章在細致解析RDD的基礎上會動手實戰RDD中的Transformation類型的RDD、Action類型的RDD，并伴有Spark API的綜合實戰案例。
第5章詳細分析了Spark Standalone模式、Spark Yarn-Cluster模式、Spark-Client模式的設計和實現。
第6章首先介紹Spark內核，接著分享通過源碼分析Spark內核及源碼，細致解析Spark作業的全生命周期，最后分享Spark性能優化的內容。
. 第7章通過大約30個動手實踐的案例循序漸進地展示Spark GraphX框架方方面面的功能和使用方法，并對Spark GraphX的源碼進行解析。
第8章基于Spark SQL動手編程實踐章節，從零起步，細致而深入地介紹了Spark SQL方方面面的內容。
第9章從快速入門機器學習開始，詳細解析MLlib框架，通過對線性回歸、聚類、協同過濾的算法解析、源碼解析和案例實戰，循序漸進地揭秘MLLib，最后通過對MLlib中Basic Statics、樸素貝葉斯算法、決策樹的解析和實戰，進一步提升掌握Spark機器學習的技能。
第10章細致解析了Tachyon這個分布式內存文件系統的架構設計、具體實現、部署以及Spark對Tachyon的使用等內容。
第11章循序漸進地介紹Spark Streaming的原理、源碼和實戰案例等內容。
第12章介紹了Spark多語言編程的特點，并通過代碼實例循序漸進地介紹Spark多語言編程，最后通過一個綜合實例來實踐Spark多語言編程。
第13章從R語言的基礎介紹和動手實戰入手，介紹SparkR的使用和代碼實戰，助您快速上手R語言和Spark兩大大數據處理的利器。
第14章循序漸進地介紹了Spark常見的問題及其調優方式。首先介紹Spark性能優化的14大問題及其解決方法，然后從內存優化、RDD分區、Spark對象和操作的性能調優等角度解決常見的性能調優問題，最后講解Spark最佳實踐方案。
第15章聚焦于Spark源碼中的BlockManager、Cache和Checkpoint等核心源碼解析，BlockManager、Cache和Checkpoint是每個Spark學習者都必須掌握的核心內容。本章循序漸進地解析了這三部分的源碼，包括通過源碼說明其用途、實現機制、內部細節和實際Spark生產環境下的最佳實踐等，通過本章即可輕松駕馭BlockManager、Cache和Checkpoint，從而對Spark精髓的領悟也必將更上層樓！
附錄主要是從Spark的角度來講解Scala，以動手實戰為核心，從零開始，循序漸進地講解Scala函數式編程和面向對象編程。 剛找到了一個微信，上面剛開始講spark的，可以學習下。
【Spark大數據處理】動手寫WordCount
王家林《Spark亞太研究院系列叢書——Spark實戰高手之路 從零開始 》Spark亞太研究院系列叢書――Spark實戰高手之路 從零開始
王家林《spark亞太研究院專刊》Spark專刊-Spark亞太研究院
王家林《spark亞太研究院中文文檔翻譯》【Spark亞太研究院 共享資料】Spark官方文檔中文翻譯
王家林spark亞太研究院出版圖書《大數據Spark企業級實戰》現貨包郵 大數據Spark企業級實戰 Spark亞太研究院 王家林【圖片 價格 品牌 報價】
王家林《spark亞太研究院100期公益大講堂》
搜索視頻：spark亞太研究院
王家林spark亞太研究院線下課程地址Spark亞太研究院的在線課堂
王家林英語視頻百度視頻搜索_王家林英語
王家林的書籍王家林 - 商品搜索
王家林spark亞太峰會百度視頻搜索_spark亞太峰會#pn=0
王家林移動互聯網Android書籍王家林Android
王家林Hadoop視頻從技術角度思考Hadoop到底是什么
王家林Scala視頻熟練的掌握Scala語言【大數據Spark實戰高手之路1】_51CTO學院
王家林spark視頻百度視頻搜索_王家林spark視頻
我個人感覺看spark的書，還不如看spark官網的開發文檔，文檔寫的很詳細。等熟悉了再看源碼，推薦jerryshao的博客http://jerryshao.me/和岑玉海的Spark源碼系列，或者Matei Zaharia的論文。 講解的非常詳細，內容深入淺出。下面是王家林的1000講免費視頻：1，《大數據不眠夜：Spark內核天機解密（共100講）》：http://pan.baidu.com/s/1eQsHZAq
2，《Hadoop深入淺出實戰經典》http://pan.baidu.com/s/1mgpfRPu
3，《Spark純實戰公益大講壇》http://pan.baidu.com/s/1jGpNGwu
4，《Scala深入淺出實戰經典》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大數據夢工廠Spark、Scala、Hadoop的所有視頻、PPT和代碼在百度云網盤的鏈接：
百度云 網盤-Rocky_Android的分享 1，《大數據不眠夜：Spark內核天機解密（共100講）》：http://pan.baidu.com/s/1eQsHZAq
2，《Hadoop深入淺出實戰經典》http://pan.baidu.com/s/1mgpfRPu
3，《Spark純實戰公益大講壇》http://pan.baidu.com/s/1jGpNGwu
4，《Scala深入淺出實戰經典》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大數據夢工廠Spark、Scala、Hadoop的所有視頻、PPT和代碼在百度云網盤的鏈接：
百度云 網盤-Rocky_Android的分享 今年一月份新出的Learning Spark: Lightning-Fast Big Data Analysis算是官方的權威書籍了，對于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和以前的版本已經有了相當大的改變。尤其是dataframe，mllib，改動非常大。 回答中已經有書的推薦，確實還沒有什么好書。
如果是使用，本人推薦看spark各個版本的doc：Documentation更加合適，還有多看微博上國內的幾個contributor在微博上關于spark的討論。
如果要了解源碼，可以跟進github上spark的repo：apache/spark · GitHub，從配置sbt，編譯源碼，嘗試修改源碼開始，多看PR：Pull Requests · apache/spark · GitHub。
由于spark正在發展，你可以找你感興趣的緊跟其中一方面spark sql（包括sql parser，查詢優化catalyst和邏輯和物理執行計劃的表示，各個物理算子的實現），mlbase（各種機器學習算法的實現）或者graphx，集中了解某一方面的原理和詳細的實現過程，我想這個是學習spark最大的價值。 后面的總結很到位，跟我想的一樣。其實學習大數據之前，推薦學習《函數式編程思維》、《七周七并發模型》。基本原理一樣了，就是分布式的實現了。 作者：慕尤才
鏈接：https://www.zhihu.com/question/23655827/answer/64871458
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
注意！注意！推薦今年年初出版的一本書，作者都是Spark的主要貢獻者：
Learning Spark: Lightning-Fast Big Data Analysis
http://www.amazon.com/Learning-Spark-Lightning-Fast-Data-Analysis/dp/1449358624/
這本書有這樣幾個特點：
- 可操作性強：安裝好Spark后，就可以直接照著書中的例子進行實際操作，Learning by doing，比直接看Spark的論文來得要簡單爽快。類似于初學Linux也不一定得先把操作系統原理學得徹徹底底了才開始動手；帶著問題邊干邊學不斷深入才會效率高。
- 實例充實：提供了Scala、Python、Java三種接口的操作代碼，提供了諸如PageRank算法的實現，并在在How to的基礎上加入了大量Why to的討論，討論如何在Spark分布式環境下實現更高效的計算，如何減少網絡開銷。github上也有作者提供的配套代碼：databricks/learning-spark · GitHub
- 文字扼要：比官方文檔（Spark Programming Guide）更深入地介紹代碼作用原理，同時也不像普通外文教材一樣廢話連篇。例如這一句：“為分布式數據集選擇正確的分區策略的重要性類似于為本地數據選擇正確的數據結構。”讓人思考良久。
翻譯了其中我認為最重要的第四章，放在了這里，大家可以看一看：
CHAPTER 4: Working with Key/ValuePairs
百度云：OReilly.Learning.Spark.2015.1-CN-13-Chapter4.pdf_免費高速下載
截圖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在嘗試把函數式語言的模型，應用在了分布式的環境中。
我一直認為函數式語言是為了分布式/多核環境而生的，而且其設計歷史之久遠足以看出設計者的遠見（額，這個遠見可能只是巧合，還好我們除了圖靈機外還有lambda演算）。我在大三時修習喬海燕老師的“函數式編程”這門課時，發現函數式語言很多特點在單機/單核上是浪費時間和浪費空間的操作，例如無副作用、不可變（immutable），我尤其不太理解為什么一個容器（例如List），改變其中一個元素，就需要生成一個新的不可變容器，這在命令式語言（例如C）的思路里是多么的浪費空間和時間。不過，不可變和無副作用卻也帶來了另外的好處：1）不可變：節約了多核和多線程訪問臨界區的鎖資源；2）無副作用：節約了重復計算相同參數函數的資源。并且這種好處在硬件越來越廉價，更加趨向分布式/多核的環境中越發彰顯優勢。
Lisp和C語言是編程模型中的兩座高山，其他語言都在這兩座高山之間權衡折衷。
語言設計，這是計算機科學中最有美感和純度的分支。另外感覺很熱門的數據科學（數據挖掘/機器學習）只是統計學在計算機里面的實現，是個數學工程，或者是仿生學工程，它們也具有美感，卻不夠簡單缺少純度。
一本Holden Karau著作的《Fast Data Processing With Spark》，市場上也有了中文版《Spark快速數據處理》。 基本的Spark使用介紹的挺詳細，缺點是Spark新版本不斷發布，導致書里的部分內容或鏈接無效了，自己去克服克服看！-----------------------------
其實，不建議使用這本書。這是一本缺少內容，又容易讓你因為內容過期暈頭轉向的書。還是去閱讀相關論文和Spark網頁吧
Hadoop MapReduce只是函數式語言到分布式環境跨出的第一步。然而函數式語言包含了許多基礎的先驅函數（Prelude Function），除了Map、Reduce，還有Filter、Fold、Sort、GroupBy、Join。而Spark就是函數式語言到分布式環境跨出的第二步，在分布式環境中實現并優化了這些函數。
函數式編程概念
可以參考問題“什么是函數式編程思維？”
1. 無副作用（no side effects）
2. 高階函數（high-order function）
3. 閉包（closure）
4. 不可變（immutable）
5. 惰性計算（lazy evaluation）
6. 科里化（currying）
7. 模式匹配（pattern matching）
8. 后續（continuation）
9. monad
Spark相關論文
·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
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
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學習小結[2014版]Hadoop
Hadoop社區依然發展迅速，2014年推出了2.3，2.4, 2.5 的社區版本，比如增強 Resource Manager HA, YARN Rest API, ACL on HDFS, 改進 HDFS 的 Web UI…
Hadoop Roadmap 根據我的觀察，主要更新在Yarn，HDFS，而Mapreduce幾乎停滯了，還有一些feature 屬于安全，穩定可靠性一方面是比較穩定了，但也可以說是瓶頸了。
Apache Hadoop Project Members
這個是Hadoop project member and committee, 里面好多來自Hortonworks，也有不少國人上榜。
SparkSpark 介紹Spark今年大放溢彩，Spark簡單說就是內存計算（包含迭代式計算，DAG計算,流式計算 ）框架，之前MapReduce因效率低下大家經常嘲笑，而Spark的出現讓大家很清新。
-
Reynod 作為Spark核心開發者, 介紹Spark性能超Hadoop百倍，算法實現僅有其1/10或1/100
-
淺談Apache Spark的6個發光點
-
Spark: Open Source Superstar Rewrites Future of Big Data
-
Spark is a really big deal for big data, and Cloudera gets it
其實起名字也很重要，Spark就占了先機，CTO說Where There’s Spark There’s Fire: The State of Apache Spark in 2014
Spark 起源2010年Berkeley AMPLab，發表在hotcloud 是一個從學術界到工業界的成功典范，也吸引了頂級VC：Andreessen Horowitz的 注資
AMPLab這個實驗室非常厲害，做大數據，云計算，跟工業界結合很緊密，之前就是他們做mesos，hadoop online, crowddb, Twitter，Linkedin等很多知名公司都喜歡從Berkeley找人，比如Twitter也專門開了門課程 Analyzing Big Data with Twitter 還有個BDAS (Bad Ass)引以為傲: The lab that created Spark wants to speed up everything, including cures for cancer
在2013年，這些大牛從Berkeley AMPLab出去成立了Databricks，半年就做了2次summit參會1000人，引無數Hadoop大佬盡折腰，大家看一下Summit的sponsor ，所有hadoop廠商全來了，并且各個技術公司也在巴結，cloudrea, hortonworks, mapr, datastax, yahoo, ooyala, 根據CTO說 Spark新增代碼量活躍度今年遠遠超過了Hadoop本身，要推出商業化產品Cloud。
Spark人物- Ion Stoica: Berkeley教授，AMPLab 領軍
- Matei Zaharia: 天才，MIT助理教授
- Reynold Xin Apache Spark開源社區的主導人物之一。他在UC Berkeley AMPLab進行博士學業期間參與了Spark的開發，并在Spark之上編寫了Shark和GraphX兩個開源框架。他和AMPLab同僚共同創建了Databricks公司
- Andy Konwinski
- Haoyuan Li
- Patrick Wendell
- Xiangrui Meng
- Paco Nathan
- Lian Cheng
- Hossein Falaki
- Mosharaf Chowdhury
- Zongheng Yang
- Yin Huai
- Committers
目前還有一些子項目，比如 Spark SQL, Spark Streaming, MLLib, Graphx 工業界也引起廣泛興趣，國內Taobao, baidu也開始使用：Powered by Spark
Apache Spark支持4種分布式部署方式，分別是Amazon EC2, standalone、spark on mesos和 spark on YARN 比如AWS
Spark Summit-
2014 Summit
-
取代而非補充，Spark Summit 2014精彩回顧
-
擁抱Spark，機遇無限——Spark Summit 2013精彩回顧
-
Databricks Cloud Demo 今年最叫好的demo是Dtabricks Cloud, 把Twitter上面實時收集的數據做作為machine learning素材，用類似IPython notebook，可視化呈現驚艷，而搭建整個sampling系統就花了20分鐘！
-
官方文檔
-
Databricks Blog
-
Summit Training
-
Databricks upcoming training
-
Stanford Spark Class
-
CSDN Spark專欄
10月份還有個培訓在灣區的培訓，只不過3天就要1500刀，看來做個講師也不錯:)
第三方項目- 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的技術挑戰
-
Hive原理與不足
-
Impala/Hive現狀分析與前景展望
-
Apache Hadoop: How does Impala compare to Shark
-
MapReduce：一個巨大的倒退
-
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 多臺舊電腦，組建一臺超級計算機？修改
背景：1 手里有20多臺 臺式舊電腦，奔四 CPU 512MB 內存，板載顯卡聲卡獨立網卡。2 前兩年云計算開始火，自己的學校建立了云計算中心，偶然體驗了一下覺得很刺激，但體驗和遠程登陸沒有區別。
3 學校領導不滿足我的計算機需求，反而說都給你 20 多臺電腦了，還要新的？
4 聽過一位兩院院士的學術報告，聽到了分布式計算的概念
5 聽說 Google 機房和我的情況類似，采用舊的機器來分擔服務器壓力
問：我可否用這些破電腦來組建一臺超級計算機，當然也不需要太強，做電設的軟件不卡就行。
謝謝 云計算有三個方面：
1/ 計算能力
就是cpu的速度。我看了一篇文檔說，第一代／第二代／第三代／第四代／core 處理器的性能相差不大，最主要是功耗有很大的降低。你現在擁有的p4是最傻的cpu，功耗大，流水線最長，計算速度慢，不支持硬件虛擬化，所以已經沒有任何實際使用價值的
2/ 內存
內存大小是云計算的關鍵。一般一個節點怎么也得32g以上，512m的內存塞牙縫都不夠
3/ 存儲能力
目前云計算采用sata盤能有效降低運營成本，但是速度慢／可靠性低，因此要采用sata 6g的接口，并作底層的硬件raid. 我一般做RAID 10 BOINC（Berkeley Open Infrastructure for NetworkComputing，伯克利開放式網絡計算平臺）
玩這個
能效比你可以找資料算算就知道不合算了，計算機唯一可以重復利用的就是硬盤了，什么內存，顯卡，cpu都是一代主板一代口，架構完全不同，這些電子垃圾會有人專門回收。不是說某學生在cpu提煉出黃金嗎？我覺得這是最大利用價值了。
硬盤你有20個可以組一個磁盤陣列，速度飛快無比啊～不過功率和發熱同樣是可怕
不搞超算，搞分布式計算不行嗎？
hadoop/spark集群 樓主真是太可愛了，雖說分布式集群是一種廉價的解決方案，但廉價是和IBM小型機比較而言的。集群的單個節點內存一般最少16個G，一堆奔4的機子做集群，真的不如i7 這種配置的舊電腦真不如去DIY一臺新機器，32g內存，4核8線程i7處理器，然后開10個虛擬機。 我覺得云計算重點不在硬件上，而且在軟件上！ 0. 超級計算機是以科學計算（例如，每秒浮點數計算峰值）為評價標準的，并不是僅靠搭個集群就能實現的，要靠對很多cpu的重新組織，涉及到硬件架構和指令流水線，比較底層我也不懂，總之不是簡單堆疊就行的，要不誰都可以實現了，題目說法不準確；
1. 你說道谷歌的集群，這20臺機器配置來說搭個hadoop集群勉強可以，但只能跑點資源分發的程序（谷歌主要是用來跑爬蟲，這個不需要實時，廉價pc你要求能多高？所以徹夜的爬數據才是他們的歸宿），不適合科學計算，而且是離線的，響應速度也慢，再說資源多了（達到TB級別）效果才明顯。 內存是關鍵，512m跑個系統都勉強，更不要想跑什么軟件了。您所說的Google的舊電腦，一般也會配置16G以上的ECC內存以及TB級別的硬盤。
更不要提一般基于集群的程序都是要專門寫的，當然您也可以下載個開源的Hadoop平臺玩下。
建議題主還是把這20臺舊機器賣了買個好點的服務器吧。
首先，Google機房那種云計算，是通過一個轉發器，把各個請求轉發到不同的電腦上來分擔訪問壓力。
其次，你要弄的超級計算機，需要各個電腦的CPU之間能夠協同工作，這樣需要各臺電腦之間有延遲很小帶寬很大的連接。
所以，你做不了超級計算機，只能做出一些類似Web集群或者存儲集群的東東。 對對對，我就是這個意思。學校組建的云計算中心，可以在我這一端申請cpu數量，內存大小，然后就像遠程登錄一樣登陸到計算中心，用那里的matlab運算特別爽，當然，基于校園網11mb/s的極限速度。 那個是多重負載，不需要你操心。最前端有cache, 然后是DNS 負載，然后是http負載，在然后是message server，在在然后到http server， 在在在然后到application server，最后才到數據庫。 這個需求不成啊，目前的虛擬主機技術有限制的，就是CPU和內存需求，不能高于單體宿主的最大值。即如果宿主的集群里，最大單臺只有8核的機器，那你生成的虛擬主機也最大只能到8核了。。不過我這是2年前的老知識了，現在有突破也說不定。但如果那么新的技術，可定不支持P4的CPU了。。所以請放棄吧。。 首先，明確需求。你組建一個分布式網絡到底是用來干嘛？
其次，構建測試平臺。你看看你要解決的問題是否可以被拆分多個任務，是否存在計算損耗。是否可以估算出計算成本。
再次，進行風險預估，看看這件事做了，技術上最大的風險是什么？增加了哪些難題？是否劃得來？
然后，在動手。
唉，想當年沒錢，用了接近100臺PC，搞了個sun grid EDA計算農場，真的很慘呀！ 才疏學淺，基于我目前對于超級計算機的需求是軟需求，我的思路是在諸位大神的問答中，找到一個可行性（經濟、時間）的方案，自己嘗試著去探索，自己先爽，然后找朋友爽，最后在全校范圍內吹牛逼。嘿嘿。 現在的并行計算技術，即使是業界最前沿的Spark, Hadoop YARN等也只能對特定的計算任務進行并行化。這里說的特定任務主要指的是，可以拆解并行化的任務，而且這個“拆解”也是需要人工進行。像題主說的“做電設的軟件”對于并行計算是非常復雜的一項任務，即使能進行并行化，人工的費用也是極不劃算的。
人家云起來都是e3起了，一臺e5可能都爆一百個樓主的u了，樓上那些說用i7的，什么心態…你這樣組裝起來不過是二十個vps而已，人家一臺機器虛擬出來，你就直接實體機，其實這些都不是重點，重點是什么用途，儲存？你不組個raid好意思，就那些機器的硬盤…還是做數據處理，模型分析和視頻渲染之類的？這個事…i3都玩不起啊，呵呵。綜上所述，樓主還是跟校長要2-5w的預算，購買兩三臺e5 內存32g 硬盤4t + ssd,然后用一些虛擬技術，vmvere,xen都可以，起碼可以開幾百個像樓主這樣性能的虛擬機，不要以為這不是云，這就是，阿里云都是這么干的，他的虛擬化技術就是xen的，只不過你是兩臺，人家是幾百臺，其實云這些都是一些yy出來的東西，云這個模式10年前就有了，但是這個概念就最近一兩年才火。有什么問題可以跟我的帖子。
可是事實上，云你認為的云，到底應該給你怎么操作，你又會在上面做什么呢？我說的云都是大部分idc認可的云，狹義的云，其實就是一臺虛擬出來的電腦而已，你可以做自己電腦做不到的一些事情，比如說儲存，數據處理，用戶交互。如果你覺得要廣意來說，那么整個互聯網都是云，云中的你向知乎的服務器發送了數據，知乎給你存起來了，難道不是云在操作嗎。當然，你如果要說是分布計算才是云，那么多少臺算一個云，難道你真的以為會有真的n臺電腦為你一個人服務嗎，還是說，要一臺電腦服務n個人？ 為之前也有類似的想法，所以研究云計算。以為云計算就可以把多個計算機組成一個牛逼的服務器。搭建好openstack之類的平臺之后才發現，原來不是做這個的。郁悶啊。研究了好久。 做成超級計算機當然不可行，但是簡單做成集群（Cluster）是可行的。實際上國外一些中小型研究項目都是在幾十個CPU的集群上運算的。國內航空研究領域以前沒有超算，都是自己用十幾臺、幾十臺臺式機搭集群來進行大規模運算。不過需要注意的是，這樣搭建集群需要自己特別編制軟件，并不能讓一般的辦公軟件之類快速運行。編制這類軟件對個人編程能力以及對硬件的理解都要求很高。如果你有能力編這個軟件，還不如把專業技能放到有實際價值的方面。總之就不要白非這個力氣了。
對！當年成都那個人造太陽，也就是20臺P4的群集而已！ASUS的板子+3COM的交換， 私有云這東西，名曰節能環保高效容錯易管理降成本，實際就倆字：“燒錢”。
不說別的，硬件：服務器+存儲，就算測試用也得十來萬吧，如果提供服務就慢慢乘10往上加；
軟件…各大廠商都盯著呢，按核心收費，按功能模塊收費，按服務收費，只要能收費的方法都被想絕了。
后面是各應用系統及數據庫的遷移部署（說是零難度遷移，實際應用時大家都懂的，購買白金服務吧）、基礎網絡交換的設備更新（說不定要優化拓撲，繼續購買服務）、操作員的培訓（還是買服務），如果牽扯分/等級保護，還要重新評估信息系統安全性（郭嘉的服務，貴）。
為了省錢還是別弄這個了…申課題倒是可以考慮，只說技術優化別提節能減排…
對了，聽說Google機房的服務器是批量定制的x86機器，從邏輯性能到物理硬件都高度標準化，所以納入云平臺管理不算太費力。題主提到的20臺PC組一起，能不能實現云的部署真不好說，在怎么說，云也是個操作系統，也是挑硬件的。
主要是是看你的需求
很明顯，你所提到的學校領導在智商、誠實和友愛三者之中最多只擁有一樣，而且很有可能三者都缺。
下圖是P4 3.0GHz CPU同其他目前常見的中高端CPU的計算性能比較（CPU Mark），就算你花了九牛二虎之力把這20多個CPU組裝到一起，并且奇跡般地沒有任何通訊開銷和效率損失，這20多臺計算機的計算能力也只有勉強達到一個i7-2600主機的水平。某寶告訴我這種主機目前大約價錢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;
如果這種“超級計算機”是你追求的目標，或者你希望通過這樣一個活動來提高自己對并行計算的認識，不妨玩玩。否則我能給的最好的建議就是——把所有機器放淘寶上一個200賣掉，賺到的5000元錢買一個性能強勁新的主機回來。 http://www.cpubenchmark.net/ 9月份，學院集中報廢物資，按理說這些電腦可以申請報廢了。可我不再負責這些事情了。上周過去看電腦還在，已經down了一半了。 在其位謀其政，我不在負責這個位置了，這個夢想也落空了。 心中的超級計算機被我手上的mbpr取代了。玩兒lol別人度條10%的時候我就完成了，至少在開局之前就能給對面威懾了。 嘗試去說服你領導吧，不然后面有的麻煩。畢竟計算機硬件的淘汰速度（摩爾定律，18月便宜一半）比其他東西（如家具）快很多。按照你領導那觀念，你們估計要一直停留在準石器時代。 還有一點。Google云計算的應用場景是大量簡單任務，如搜索，這類任務可以分配給性能較差的節點，所以Google可以用老電腦。這種架構與超級計算機（如高性能計算平臺）還是不同的。 現在i7的確性能有p4的20倍了，但僅限多任務。
單任務也至少有5倍以上，比如100萬PI計算，p4 2.0差不多80s，3.0差不多55-60s，據說玩死里超，超冒煙可以30s。i7的話10s不難達成，8s也早就有了，i7的極限我想6s應該是問題不大的。
你再想一下，i7最高是有6核的。
所以20倍問題不大。
最后，現在的四通道內存速度是p4時代的DDR2的10倍并非難事（但是內存不是瓶頸，根據跑分，四通道和三通道，雙通道差距不大，但是和單通道差距較大），SSD硬盤速度過500都是常事，p4時期的機械硬盤基本上都是并口硬盤，我沒記錯當年是ATA-33，ATA-66，ATA-100，ATA-133一路升級過來的。sata-133的極限傳輸速度也只有133mb/s。
現在的計算機是當年的20倍，并非妄言。 難度并不大，只是如第一名的答案所說的那樣，性能會非常非常爛。不用像第二名的答案那么麻煩。
你只需要：
1：用一個路由器把它們連在一起（不用太高速，反正這些電腦也很爛）。
2：每臺電腦裝個debian吧。應當只有一臺裝GUI就行。你不妨裝Xfce或者LXDE桌面，比較省。
3：看看mpich的文檔，把這些機器配上MPI的環境。
4：自己編MPI玩去吧！！
[圖]美大學生自制廉價桌面超級計算機
新聞鏈接里有詳細說明：
制作者Tim Brom在自己的主頁里給出了詳細的制作方法,有興趣的可以自己試著制作一下
相關連接:
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
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
請不要嘲笑別人的想法，老外已經實現了四臺電腦的計算集群，題主20臺也應該是可以實現的。這個資料是英文，我找到了部分中文資料，粗略地瀏覽了一遍，應該是可以實現的，但是細節部分沒看明白，求高人翻譯資料。（不好意思，我剛才發現和@高超 的回答撞車了，不過，這些資料確實是在我沒看他的資料之前自己搜索出來的，嘿嘿，大家就當他回答的補充好了）。知乎里的大神真多，呵呵，以后得好好看回答
資料地址如下 官方網址 Microwulf: A Personal, Portable Beowulf Cluster
中文翻譯的資料地址如下【個人小超算】實戰資料匯編
先上張圖片震撼一下大家
&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;以下是我找到中文翻譯資料，我是直接復制的，沒能把圖片等復制過來，大家就湊合看吧，也可以看上面那個中文資料的網站以下是我找到中文翻譯資料，我是直接復制的，沒能把圖片等復制過來，大家就湊合看吧，也可以看上面那個中文資料的網站
個人電腦陣列
一、作者簡介：
喬爾 亞當斯 （Joel Adams）是卡爾文學院（Calvin College）計算機科學（computer science）教授，1988年獲得在匹次堡大學獲得博士學位，主要研究超算的內部連接，是幾本計算機編程教材的作者，兩次獲得Fulbright Scholar (毛里求斯1998, 冰島 2005).
緹姆 布倫姆（Tim Brom）是卡耐基大學計算機科學的研究生，2007年五月在卡爾文學院獲得計算機科學學士學位。
二、說明：
此小超算擁有超過260億次的性能，價格少于2500美元，重量少于31磅，外觀規格為11" x 12" x 17"——剛好夠小，足夠放在桌面上或者柜子里上,
更新：2007年8月1日，這個小超算已經可以用1256美元構建成，使得其性價比達到4.8美元/億次——這樣的話，可以增加更多的芯片，以提升性能，讓其更接近21世紀初的超算性能。
此小超算是由卡爾文大學的計算機系統教授喬爾 亞當斯和助教 緹姆 布倫姆設計和構建。下面是原文的目錄，可點擊查看：
- 設計
- 硬件信息
- 軟件系統構建說明
- 效果圖片
- 性能
- 計算效率
- 價格效率
- 功耗
- 新聞報道
- 相關系統
三、介紹
作為一個典型的超算用戶，我需要到計算中心排隊，而且要限定使用的計算資源。這個對于開發新的分布式軟件來說，很麻煩。所以呢，我需要一個自己 的，我夢想中的小超算是可以小到放在我的桌面上，就像普通個人電腦一樣。只需要普通的電源，不需要特殊的冷切裝置就可以在室溫下運行……2006年末, 兩個硬件發展，讓我這個夢想接近了現實：
2006年秋天, 卡爾文學院計算機系給了我們一筆小錢——就是2500美元，去構建這么一個系統，我們當時設定的目標：
- 費用少于2500美元——這樣一般人都能負擔得起，可以促進普及。
- 足夠小，適合放在我的桌面上，適合放到旅行箱里。
- 要夠輕，可以手提，然后帶到我的汽車里。
- 性能強勁，測試結果至少要200億次：
- 用于個人研究,
- 用于我教授的高性能運算課程,
- 用于專業論壇講授、高中講演等,
- 只需要一根電源線，使用普通的120伏電源。
- 可在室溫下運行。
據我們當時所知，已經有一些小型的超算，或者是性價比不錯的超算出現，這些東西給了我們很好的參考：
- Little Fe
- The Ultimate Linux Lunchbox
下面是歷年的性價比之王：
- 2005: Kronos
- 2003: KASY0
- 2002: Green Destiny
- 2001: The Stone Supercomputer
- 2000: KLAT2
- 2000: bunyip
- 1998: Avalon
在同一時間，還有其他更廉價或者是更具性價比的超算集群，不過這些記錄都在2007年被改變了，最具性價比的就是下文介紹的小超算（2007年一月，9.41美元/億次），而其記錄半年后就被打破（2007年8月 4.784美元/億次）。
架構設計：
個人小超算一般做法是使用多核芯片，集中安裝到一個小的空間里，集中供電——嗯，如果能自己燒制主板，體積上應該可以做得更小——樹莓派的主板體積很小，就是芯片不給力，所以需要那么多片才能達到2007年用普通電腦芯片實現的性能。
1960年代末，吉恩 庵達郝樂（Gene Amdahl）提出了一個設計準則，叫 "庵達赫樂法則"（Amdahl's Other Law），大意是：
為了兼容性考慮， 下面幾個特性應該相同：- 每片芯片的頻率
- 每根內存大小
- 每處帶寬
高性能計算一般有三個瓶頸：芯片運算速度，運算所需內存，吞吐帶寬。本小超算里面，帶寬主要是指網絡帶寬。我們預算是2500美元，在設定了每核內存量，每核的帶寬之后，其中芯片運算速度當然是越快越好。
內部使用千兆網絡（GigE），則意味著我們的帶寬只有1Gbps，如果要更快的，可以使用比如Myrinet，不過那會超預算了，此處核心1吉赫茲+每核1吉B內存+1吉bps，嗯，看起來比較完美，哈哈。最終決定是2.0GHz的雙核芯片，每核1GB內存
芯片，使用AMD Athlon 64 X2 3800 AM2+ CPUs. 2007年一月時每片價格$165 ，這種2.0GHz的雙核芯片，是當時可以找到的性價比最好的。 (2007年8月就更便宜了，每片只有$65.00).
為了盡量減少體積，主板選用的是MSI Micro-ATX。此主板特點是小(9.6" by 8.2") ，并且有一個AM2 socket，可支持AMD的Athlon多核芯片。其實如果有條件的話，更應該做的是使用AMD的四核Athlon64 CPU替代這個雙核，而這系統恰好還不用改。
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.
此 主板上已經嵌有一個千兆網卡，還有一個PCI-e擴展插槽，在PCI-e插槽插入另一根網卡（41美元），用于平衡芯片運算速度和網絡帶寬。這樣，四塊主 板總共就有內嵌的4個網卡，外加PCI-e插槽的4張網卡，一共8個網絡通道，用網線把它們都連接到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.)
每塊主板插了兩根內存，共2G，這8G內存消耗了預算的40%！！
為了更小化，本小超算沒有使用機箱，而是一個完全非封閉的外架，像Little Fe 和 這些集群，把主板直接安裝到有機玻璃上面，然后用幾根小鐵桿撐起來，并連接成一立體狀。——（這個架子一般的五金店應該可以制造，用導熱性好的鋁/鐵當托盤，整機的熱分布會好點，也有利于集中散熱）
最底部是兩片有機玻璃隔開的一個夾層，放著8口路由，光驅，還有250GB的硬盤。
結構圖如下：
&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;我們這小超算的硬件結構
如圖所示，主板放在最頂層的下方，而中間層則兩面都放主板，底層則上方放主板，這樣做的目的是盡可能減少高度。
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. 這樣的結果就是每塊主板間的間距為6"，如圖所示：
主板之間的距離
(說明：這些主板都有一個單獨 PCI-e x16插槽，留給以后想提升性能的時候，可以插上一塊GPU）
使用350瓦的電源供電（每塊主板一個），使用雙面膠固定在有機玻璃上，電源插座放在最上面的有機玻璃上，如圖所示：
本小超算的電源和風扇
(此處用膠水固定硬盤、光驅、路由器)
最靠近夾層的底部主板作為“主節點”——主控主板，連接硬盤、光驅（可選）等，系統啟動/關機/重啟的時候也是從這個部分操作。其他的主板當作“分支節點”，使用PXE網絡啟動方式啟動。
對最底部的主控主板做特殊設置，連接250GB硬盤，并且作為啟動分區。插入光驅（主要是用于安裝初始系統，現在都不需要了，直接用優盤做系統安裝盤吧……）插入另一塊網卡10/100 NIC到PCI插槽中，用于連接外部網絡。
頂部三個節點都是無硬盤的， and used NFS to export the space on the 250 GB drive to them。
下圖顯示了本小超算各個部分的連接關系（節點0為重心，連接了硬盤、光驅、以及連接外部的接口，內部中心為千兆路由，用于連接其他節點）：
&lt;img data-rawheight="134" data-rawwidth="420" src="https://pic3.zhimg.com/fe70dd27a5e704552c7b255a815845da_b.jpg" class="content_image" width="420"&gt;說明：每個節點都有兩條獨立的通訊線路，連接自己和網絡路由器。
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.
系統使用的是有奔頭（Ubuntu Linux）.
開源通用信道（Open MPI）將自動識別每個節點的網絡適配器，并讓它們之間組成一個圓環型的信息交流系統。 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.價格參考（2007年一月）：
部件
產品名稱
單價
數量
總價
主板 微星 K9N6PGM-F MicroATX $80.00 4 $320.00 芯片
威盛Athlon 64 X2 3800+ AM2 CPU $165.00 4 $660.00 內存 金士頓 DDR2-667 1GByte RAM $124.00 8 $992.00 電源 Echo Star 325W MicroATX Power Supply $19.00 4 $76.00 網卡 Intel PRO/1000 PT PCI-Express NIC (節點連接路由) $41.00 4 $164.00 網卡 Intel PRO/100 S PCI NIC (主控主板連接外部網絡) $15.00 1 $15.00 路由器 Trendware TEG-S80TXE 8-port Gigabit Ethernet Switch $75.00 1 $75.00 硬盤 希捷7200轉 250GB SATA硬盤 $92.00 1 $92.00 光驅 Liteon SHD-16S1S 16X $19.00 1 $19.00 冷切系統 Zalman ZM-F3 120mm Case Fans $8.00 4 $32.00 風扇 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 機箱或外殼
12" x 11" 有機玻璃(是我們物理實驗室的廢品) $0.00 4 $0.00 總價
$2,470.00
非必須的硬件
部件產品名稱
單價
數量 總價 KVM Switch Linkskey LKV-S04ASK $50.00 1 $50.00 總價
$50.00
除了技術支持還有硬件加固 (購買自Lowes), 風扇和轉接器購買自 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.
構建配置：
點擊此處：軟件系統構建說明，有詳細的介紹文件下載——建議想自己構建的人下載下來，然后按照其說明，逐步完成。
細節是魔鬼
首先是選用哪個你牛叉發行版：曾經一度使用Gentoo，但后來覺得gentoo太消耗能量了（包括系統管理員的精力和系統的耗電），后來 試了試有奔頭，一開始安裝的桌面是6.10版本，其內核是2.6.17，但美中不足的是he on-board NIC的驅動需要到2.6.18才內置，所以一開始兩個月，我們的小超算就用的7.04的測試版（內核是2.6.20），直到最后穩定版發行就換了穩定 版。
在其他三個計算節點上，安裝的是有奔頭的服務器版，因為它們不需要桌面功能。也就是：有奔頭桌面版+3個有奔頭服務器版
我們也試過其他的集群管理軟件：ROCKS, Oscar, 和 Warewulf.，但ROCKS和Oscar不支持無盤的節點。Warewulf工作良好，但因為本小超算實在太小，目前看不出其優勢來。因為這篇論文，曾經想使用iSCSI。不過為了盡快讓我們的集群運行起來，還是決定使用NFSroot，因為其配置非常簡單，只需要修改/etc/initramfs.conf ，讓其生成一個虛擬內存（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.
效果圖：直接點擊上面目錄連接，可查看
性能表現：
所獲得的性能表現
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.
下面看看歷年最強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，相比于一般超算放在一個大大的機房里，而且需要眾多芯片，這個4片、8芯的集群，只有11" x 12" x 17"，能有如此表現，很不錯了。
更進一步挖掘下這個列表：1993年11月的排名中，排在第五位的超算是用了512片核芯的Thinking Machines CM-5/512，運算速度達到300億次。本小超算的4核相當于當年的512核啊，哈哈。
1996年11月，此小超算排在第60位，下一個是用了256片核芯的Cray T3D MC256-8，現在8核俄性能都超過11年前的256核了，此處還沒說價格差異呢，T3D花費了上百萬美元！超算性能一般以每秒浮算次數（flops）來衡量。早期超算使用百萬次來衡量，隨著硬件飛躍，十億次已經是很落后的指標了，現在都流行用萬億次，甚至千萬億次來表示了。
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
- 峰值性能 --理論上最大的性能表現
- 測量性能 -- 用檢測軟件檢測出來的性能表現
另一個要注意的是精度，一般高性能運算都是用的雙精度，所以不可混淆了單精度和雙精度運算。
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.在最強500超算中，1996年的Cray T3D-256也才達到253億次，所以我們這個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.
性價比：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.
下面列表可作為參考，了解下這個性價比的意義:
- 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 深藍。價格是5百萬美元，性能是113.8億次，其性價比是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/億次，我們的小超算可以說是超算里面性價比最好的一個了，不過呢，還沒法提供千萬億次的運算，若有需要，或許可以突破這個價格限制，讓性能方面獲得更大的提升。
效能 - 世界記錄 功耗：
以2007年一月的價格，本小超算用了2470美元，獲得262.5億次的運算速度，平均9.41美元／億次。這個已經成為新的世界紀錄了。
另外，節能方面的事情最近也比較敏感，性耗比（耗電量/性能）也需要測量下了，性耗比對集群是非常重要的，尤其是成片的集群（比如谷歌的服務器場）。本小超算我們測試了下，- 待機需要消耗250瓦（平均30瓦每核），
- 運行是需要消耗450瓦，
對比下其他的超算。
專門進行節能設計的超算Green Destiny 使用了非常節能的芯片，只需要較低的冷切，240核消耗了3.2千瓦，獲得的運算性能是1010億次，性耗比為3.1瓦/億次。是我們這個自制的小超算的兩倍哦！！！
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.)
- 我們的小超算性價比上 遠超這些商業機器，其性耗比也居于前流。
節能500超算名單，是基于最強500超算的（本小超算沒有被列入，呵呵），排名按每瓦運算次數排列。我們的小超算是1.713瓦／億次，換算如下：
1 / 17.14 W/Gflop * 1000 Mflops/Gflop= 58.34 Mflops/W 2007年8月，我們的小超算超越了節能500超算的第二位，Mare Nostrum (58.23 Mflops/W) -- 可惜啊，和排名第一BlueGene/L (112.24 Mflops/W)的距離有點遠。結論
此小超算用了4塊芯片、8核集群，大小為11" x 12" x 17"，適合放在桌面上，也適合打包放到飛機上運輸。
除了小巧，HPL檢測本超算有262.5億次的運算性能，總花費是2470美元（2007年1月），性價比為9.41美元/億次。
本小超算能有如此神力的原因是：
- 多核芯片已經普及：這樣可以讓系統變得更小。
- 內存大降價： 此小超算最貴的部分就是這個，不過價格一直在快速下降中，8G內存應該夠用了吧？？
- 千兆網卡已經普及：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.
我們不打算保守我們的技術秘密，而是希望所有人都來嘗試這玩玩，嗯，其實很多部件都是可以替換的。
比如，隨著固態硬盤的降價，可以試試固態硬盤替換掉機械硬盤，看看對性能有何影響。
比如內存：因為內存降價，可以把內存換為2GB的，這樣每核可以2GB內存。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插槽，這個插槽剛好支持威盛新的4核Athlon64芯片，這樣就可以替換掉上文中的雙核芯片，使得整個系統變成 16核，性能更加強勁。有興趣的同學可以測測這么做的結果性能提升多少？性價比因此而產生的變化？千兆內部網的效能變化等……
等等……尤其是已經幾年后的今天（2012），這個列表幾乎可以全部替換掉了。
2007年8月配件價格：
各個部件的價格下降很快。芯片、內存、網絡、硬盤等，都降了好多價格。2007年8月在 新蛋（Newegg） 中的價格：
部件產品名稱
單價
數量 總價 主板 微星K9N6PGM-F MicroATX$50.32 4 $201.28 芯片
威盛 Athlon 64 X2 3800+ AM2 CPU$65.00 4 $260.00 內存 Corsair DDR2-667 2 x 1GByte RAM $75.99 4 $303.96 電源
LOGISYS Computer PS350MA MicroATX 350W Power Supply$24.53 4 $98.12 網卡 Intel PRO/1000 PT PCI-Express NIC (節點連接路由) $34.99 4 $139.96 網卡
Intel PRO/100 S PCI NIC (主控主板連接外部網絡) $15.30 1 $15.30 路由器
SMC SMCGS8 10/100/1000Mbps 8-port Unmanaged Gigabit Switch$47.52 1 $47.52 硬盤
希捷7200轉 250GB SATA 硬盤$64.99 1 $64.99 光驅
Liteon SHD-16S1S 16X$23.831$23.83 制冷設備
Zalman ZM-F3 120mm Case Fans$14.98 4 $59.92 風扇 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 機箱或外殼 12" x 11" 有機玻璃（來自物理實驗室的廢物） $0.00 4 $0.00 總價$1,255.80
(現在價格應該更低了!而且性能方面應該更強悍了！！！)
可見，2007年8月，這個性價比已經達到了4.784美元/億次，突破5美元/億次！！！！！
性耗比則保持不變。
如果融合價格、性能、功耗，則每百萬次/瓦/美元為0.04645，是原來的小超算兩倍。美元/瓦/百萬次為 73,255，也是原來的兩倍。
應用：
和其他超算一樣，本小超算可以運行一些并行運算軟件——需要特別設計，以利用系統的并行運算能力。
這些軟件一般會使用 通用信道和并行虛擬機。這幾個庫提供了分布式計算的最基礎功能，一是使得進程可以在網絡間溝通和同步，二是提供了一個分布執行最后匯總的機制，使得程序可以被復制成多份，分別在各個節點上運行。
有很多應用軟件已經可以在本小超算上使用，大部分是由特定領域的科學家寫的，用于解決特定問題：
- 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
這是我們使用小超算的領域：
- 給卡爾文大學的本科生做研究項目
- As a high performance computing resource for CS 374: High Performance Computing
- 正在做的事情：
- 給本地的高中學校也定制幾個，以提升學生了解計算的興趣
- 用于會議，作為一個個人超算的示例模型。
- 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.
否，主要是因為我們都不懂商業。
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 謝啦!某網友測試過評論如下
好多年前的事情了.....
不在于系統是ubuntu Linux
而問題的重點是:
你會組裝機器 硬件組裝； 會作系統優化配置， 會配置很多服務， 比如NFS（構建無盤系統），NIS， 構建用戶信息， MPI（高斯可以不用這個并行環境）， 網絡優化， 幾個機器之間通信能力的優化，
如果你僅僅是明白硬件， 而對于linux系統的水平只專注于3D桌面之類的桌面應用， 那么你要搞明白這套系統，
還是比較困難的。
我自己作過， 只不過是用的兩臺機器，也是無盤系統， 系統采用自己熟悉的RHEL， 5.3 ,
那位作者的組裝說明， 適合管理過linux系統， 熟悉linux網絡應用的人看，
沒有涉及過網絡管理， 網絡應用的， 要作下去比較費勁的。
他寫的只是一個方案， 不是具體的每一步的how-to,
誰有興趣的可以試試！
這套無盤系統， 性能很大程度取決于你的磁盤性能！
注意，這套系統， 適合并
自己組建spark集群,硬件方面以及網絡連接設備方面應該如何選擇
測試環境好些吧
spark運算速度超快
生產環境適合云計算（aws azure數據流入流量都是免費的）
比hadoop處理同樣數據能省很多機時和錢
spark如何實現一個快速的RDD中所有的元素相互計算？
在spark集群中需要實現每個元素與其他元素進行計算，比如
rdd = sc.parallelize(Array('a', 'b', 'c', 'd'))，
那么需要相互計算的元素對為
(a, b), (a, c), (a, d), (b, c), (b, d), (c, d)
我知道可以先進行cartesian，然后filter一下，但是對于數據量特別大的時候(比如，10w個)，這種方法貌似很慢，所以請問大家知道在spark中有什么好的解決方法呢？
Spark程序如何只輸出最后結果，隱藏中間的輸出？？？
由于spark的調試信息輸出在stderr 可以在命令后面加上 2>/dev/null 去掉調試信息
把spark/conf/log4j.properties下的
log4j.rootCategory=【Warn】=> 【ERROR】
log4j.logger.org.spark-project.jetty=【Warn】=> 【ERROR】
頭大，這幾種框架是什么關系？？？我現在想對hdfs上的文件做分析，spark是基于hadoop嗎？sparksql又是什么，獨立的項目嗎？可以搭建一個hadoop+spark的平臺嗎，比如說使用hadoop的hdfs，然后使用spark sql方式來查詢分析數據？？？對了還有hive on spark
瀉藥，水平有限，就科普一下吧。Hadoop是最早的MapReduce框架和Google File System的開源實現，被作為大數據處理的主流處理技術已經10多年了，其主要組件包括了MapReduce（計算）和HDFS（存儲），然后在這個基礎上發展成了一個生態系統，包括HBase，Hive等等。大約在2012年加州伯克利的Matei等人在MapReduce思想的基礎上提出了RDD模式對數據進行暫存，并實現了Spark的原始版本，然后一直發展到現在。二者從根源上講是基于同一種MapReduce思想的，但是Spark能完成的計算任務多樣化，同配置下在絕大多數場景下比Hadoop要快。二者并無直接關系。基于Spark的核心作業引擎，Matei等人又設計了Spark SQL，Spark Streaming和Spark MLib等框架用來提供對特定場景的作業的支持。Spark SQL是基于Spark的。但是Spark是支持從Hadoop HDFS讀取數據然后進行處理的，也支持S3和Tachyon，所以二者并不是密不可分的關系。
此外，題主問出這種問題讓我很震驚，這是在某度里度一下都可以解決的問題。上知乎前先自己去了解一下。
1、Hadoop提供存儲和離線計算，分別是HDFS和MapReduce（當然還有個HBase，題主既然沒說那么不提也罷）
2、Spark只是一種計算框架，和Hadoop對應起來就是里面的MapReduce這個角色，他的存儲系統可以使HDFS或者S3等，和MapReduce不同的是Spark是基于內存計算的
3、SparkSQL只是Spark中的一個核心擴展，在SparkSQL中用戶可以通過類似SQL語句對數據進行分析操作，相對比scala，sql可能能夠給大部分人所接受= =
對于題主的問題：
Hadoop并不是一定要上Spark，Spark也并不一定要依賴于Hadoop，所以這兩者不是強制一定要一起使用的，當然肯定也不會是“有你沒我，有我沒你”的關系，互補，互補！
SparkSQL肯定是和Spark有關系的了，父子關系嘛，他還有Mllib，Graphx，Spark Streaming這些兄弟呢。。
我猜題主的應該是測試型的數據集，上Spark玩看看吧，有時間也可以用MapReduce實現對比試試
通過對比的方式可以更加深刻的理解MapReduce和Spark RDD編程模型之間的優缺點
對于最后一個問題，完全可以。。
?
我很喜歡用python，用python處理數據是家常便飯，從事的工作涉及nlp，算法，推薦，數據挖掘，數據清洗，數據量級從幾十k到幾T不等，我來說說吧
百萬級別數據是小數據，python處理起來不成問題，python處理數據還是有些問題的
Python處理大數據的劣勢：
1. python線程有gil，通俗說就是多線程的時候只能在一個核上跑，浪費了多核服務器。在一種常見的場景下是要命的：并發單元之間有巨大的數據共享或者共用（例如大dict），多進程會導致內存吃緊，多線程則解決不了數據共享的問題，單獨的寫一個進程之間負責維護讀寫這個數據不僅效率不高而且麻煩
2. python執行效率不高，在處理大數據的時候，效率不高，這是真的，pypy（一個jit的python解釋器，可以理解成腳本語言加速執行的東西）能夠提高很大的速度，但是pypy不支持很多python經典的包，例如numpy（順便給pypy做做廣告，土豪可以捐贈一下PyPy - Call for donations）
3. 絕大部分的大公司，用java處理大數據不管是環境也好，積累也好，都會好很多
Python處理數據的優勢（不是處理大數據）：
1. 異常快捷的開發速度，代碼量巨少
2. 豐富的數據處理包，不管正則也好，html解析啦，xml解析啦，用起來非常方便
3. 內部類型使用成本巨低，不需要額外怎么操作（java，c++用個map都很費勁）
4. 公司中，很大量的數據處理工作工作是不需要面對非常大的數據的
5. 巨大的數據不是語言所能解決的，需要處理數據的框架（hadoop， mpi。。。。）雖然小眾，但是python還是有處理大數據的框架的，或者一些框架也支持python
6. 編碼問題處理起來太太太方便了
綜上所述：
1. python可以處理大數據
2. python處理大數據不一定是最優的選擇
3. python和其他語言（公司主推的方式）并行使用是非常不錯的選擇
4. 因為開發速度，你如果經常處理數據，而且喜歡linux終端，而且經常處理不大的數據（100m一下），最好還是學一下python
python數據處理的包：
1. 自帶正則包， 文本處理足夠了
2. cElementTree, lxml 默認的xml速度在數據量過大的情況下不足
3. beautifulsoup 處理html
4. hadoop(可以用python) 并行處理，支持python寫的map reduce，足夠了， 順便說一下阿里巴巴的odps，和hadoop一樣的東西，支持python寫的udf，嵌入到sql語句中
5. numpy, scipy, scikit-learn 數值計算，數據挖掘
6. dpark(搬樓上的答案）類似hadoop一樣的東西
1，2，3，5是處理文本數據的利器（python不就處理文本數據方便嘛），4，6是并行計算的框架（大數據處理的效率在于良好的分布計算邏輯，而不是什么語言）
暫時就這些，最好說一個方向，否則不知道處理什么樣的數據也不好推薦包，所以沒有頭緒從哪里開始介紹這些包
這要看具體的應用場景，從本質上來說，我們把問題分解為兩個方面：
1、CPU密集型操作
即我們要計算的大數據，大部分時間都在做一些數據計算，比如求逆矩陣、向量相似度、在內存中分詞等等，這種情況對語言的高效性非常依賴，Python做此類工作的時候必然性能低下。
2、IO密集型操作
假如大數據涉及到頻繁的IO操作，比如從數據流中每次讀取一行，然后不做什么復雜的計算，頻繁的輸入輸出到文件系統，由于這些操作都是調用的操作系統接口，所以用什么語言已經不在重要了。
結論
用Python來做整個流程的框架，然后核心的CPU密集操作部分調用C函數，這樣開發效率和性能都不錯，但缺點是對團隊的要求又高了(尤其涉及到Python+C的多線程操作)...所以...魚與熊掌不可兼得。如果一定要兼得，必須得自己牛逼。
奧利根神棍
1：Numpy+Scipy+Numba
2：Pandas+NLTK
答主是不是都沒用過。
我們公司每天處理數以P記的數據，有個并行grep的平臺就是python做的。當初大概是考慮快速成型而不是極限速度，但是事實證明現在也跑得杠杠的。大數據很多時候并不考慮太多每個節點上的極限速度，當然速度是越快越好，但是再更高層次做優化（比如利用data locality減少傳輸，建索引快速join，做sample優化partition，用bloomfilter快速測試等等），把python換成C并不能很大程度上提升效率。
很多機器學習，神經網絡，數據計算的算法已經存在幾十年了，這些零零散散的工具多被C和Fortran實現，直到有人開始用Python把這些工具集合到一起，所以，表面上是在用Python的庫，實際上是C和Fortran的程序，性能上也并無大的影響，如果你真的是大數據的話
使用python可以，但對速度要求較高的關鍵模塊，還是要用C重寫。
Python調用vtk庫對面片數量我測試過是沒有限制的好像，你所說的100萬多數據是不是都是存入了python的list中，list是有上限限制的。如果不存入list，應該是沒有渲染上限的。
求python在大數據環境下高效編程的方法。
在spark集群下，我對對原來scala程序進行python重寫。對過億行級數據進行數據清洗整合操作。從執行任務的時間來看，scala執行效率比python重寫程序高好多倍。
什么叫處理？ 100萬的數據，如果只是傳輸的話，python和c/c++差不多；如果用來計算話題模型的話，python的速度為c/c++的1/10，內存消耗為10倍多。
使用Python調用vtk庫對100萬行的數據進行可視化，結果內存爆滿，使用C++就沒有問題，Python很占內存，不知道為什么……
Python clone of Spark, a MapReduce alike framework in Python
https://github.com/douban/dpark
?
組建spark集群(生成環境)如何選擇硬件？修改
1、看過官方的一個文檔：https://spark.apache.org/docs/1.2.0/hardware-provisioning.html
2、集群主要用于spark streaming 和 機器學習這塊，在硬件選擇上有哪些注意點？
3、是否有同學能夠共享一個線上環境的配置。
首先推薦看一看新出爐的https://spark-summit.org/east-2015/
題主給出的官方文檔已經說得很好了，我只是結合自己的經驗補充一下：
首先估算數據量大小（總容量）、Spark作業復雜度（需要多少計算能力）、作業的Locality（是否容易緩存）、數據交換的流量（多少數據需要在不同節點交換）。另外也考慮一下實時性需求，比如一次作業能忍受多長時間出結果。
每個節點的CPU、Memory、Network要匹配上面作業的需求，換句話說別讓一個成為短板。
從成本上看，使用平民級硬件更好。比如RAID就沒必要用。但是生產系統，ECC是必須的。
可以超量部署一段時間，然后再減下來
Spark Streaming沒玩過，不過從用Storm的經驗看，CPU和Network更容易是瓶頸。
MLlib用的不多，如果數據集能放在內存中，CPU和Network是瓶頸。
如何利用spark快速計算笛卡爾積？修改
在在spark集群里面 需要計算a＊b的笛卡爾積 a為一列
b為一列 我將a作為一個rdd b作為一個rdd 直接調用cartesian方法，當數據量比較大的時候計算非常的慢，看sparkUI shuffleread的數據量較大，想請教下有可能是哪里出了問題或者有什么更好的方法在分布式上處理計算笛卡爾積。
作者：連城
鏈接：https://www.zhihu.com/question/39680151/answer/86174606
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
可以試試用 DataFrame API。
笛卡爾積映射到 SQL/DataFrame 上就是一個不帶 join 條件的 inner join。DataFrame API 相對于 RDD API 的好處在于整體執行引擎基于 Spark SQL 的 Catalyst optimizer，并且可以利用上 project Tungsten 引入的各種執行層面的優化。Spark 新近版本中無 join 條件的 inner join 被編譯為 CartesianProduct 時采用的已經是 UnsafeCartesianRDD 了。
此外，如果是兩個 DataFrame 中有一個顯著小于另一個，可以考慮將小的 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 ，我們原來的環境是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 根據這個jira單號 spark在處理笛卡爾集的時候如果是remote讀過來的數據 是計算后會釋放的導致做笛卡爾集反復的讀取和，如果spark有部分小的問題，我看了下源代碼很多類和方法都是private的，如果想要做一定的修復，只能修改源代碼重新打包 測試，比較麻煩，這個方面我想問下 spark可以開放更多的東西給開發者嗎。
這點比較糾結……開放 API 是相對謹慎的，因為一旦開放就要在長時間內保持向下兼容，一定程度上會束縛后期演化。所以只有比較成熟的 API 才會開放。
理解，當前來看想要維護spark的一些bug之類的，要么修改源代碼，要么只能等待spark升級了：），總之多follow，多研究，感謝回答
弱弱的問一句 使用jdbc進行join的執行效率會比使用dataframe API的執行效率低么？
不是很明白意思誒，啥叫使用jdbc進行join
研究過相關課題,看到delta join的問題格外的親切
更好的方法,看你問的是那一層面的優化了
spark本身研究不多,以前研究這個課題是基于hadoop
無條件情況計算量無法優化,因為計算量就是m*n這么多
大小表的情況,可以通過廣播小表等方法優化
兩個都是大表的情況,分布式計算模型中數據傳輸量可以優化,但是很有限
這是幾年前研讀論文的總結,現在說不定過時了,但希望對你有幫助
論文:https://github.com/effyroth/paper/blob/master/10487_080605_200915055%E6%9C%89%E5%AD%A6%E5%8F%B7.pdf
感謝回答，個人這段時間的思考是1.如果是分布式計算m＊n，可以將相對較大的m，較小的n變成（m1+m2+m3..mx）＊n，n遍成廣播變量這樣減少n的shuffle，同時并行計算笛卡爾集，或者將變換m1＊n＝（m11*n+m12*n+m13*n...+m1x*n）這樣可以串行計算減少單次計算的數據量以減少集群單節點的壓力。2.對于spark的話和我上面說的是對于spark計算cartesianjoin的話，本身的方法有瑕疵，而想要優化又只能修改源代碼帶來的不方便。3后面更多的思考是 怎么從業務邏輯本身去優化，減少m和n的數據量或者避免笛卡爾集的計算，畢竟隨便1w＊1w的笛卡爾集數據量是相當嚇人的。
?
關于Spark：
Spark是UC Berkeley AMP lab所開源的類Hadoop MapReduce的通用的并行計算框架，Spark基于map reduce算法實現的分布式計算，
擁有Hadoop MapReduce所具有的優點；但不同于MapReduce的是Job中間輸出和結果可以保存在內存中，從而不再需要讀寫HDFS，
因此Spark能更 好地適用于數據挖掘與機器學習等需要迭代的map reduce的算法
Spark與Hadoop的對比
Spark的中間數據放到內存中，對于迭代運算效率更高。
Spark更適合于迭代運算比較多的ML和DM運算。因為在Spark里面，有RDD的抽象概念。
Spark比Hadoop更通用。
Spark提供的數據集操作類型有很多種，不像Hadoop只提供了Map和Reduce兩種操作。比如map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort,partionBy等多種操作類型，Spark把這些操作稱為Transformations。同時還提供Count, collect, reduce, lookup, save等多種actions操作。
這些多種多樣的數據集操作類型，給給開發上層應用的用戶提供了方便。各個處理節點之間的通信模型不再像Hadoop那樣就是唯一的Data Shuffle一種模式。用戶可以命名，物化，控制中間結果的存儲、分區等。可以說編程模型比Hadoop更靈活。
不過由于RDD的特性，Spark不適用那種異步細粒度更新狀態的應用，例如web服務的存儲或者是增量的web爬蟲和索引。就是對于那種增量修改的應用模型不適合。
容錯性。
在分布式數據集計算時通過checkpoint來實現容錯，而checkpoint有兩種方式，一個是checkpoint data，一個是logging the updates。用戶可以控制采用哪種方式來實現容錯。
可用性。
Spark通過提供豐富的Scala, Java，Python API及交互式Shell來提高可用性。
Spark與Hadoop的結合
Spark可以直接對HDFS進行數據的讀寫，同樣支持Spark on YARN。Spark可以與MapReduce運行于同集群中，共享存儲資源與計算，數據倉庫Shark實現上借用Hive，幾乎與Hive完全兼容。
Spark的適用場景
Spark是基于內存的迭代計算框架，適用于需要多次操作特定數據集的應用場合。需要反復操作的次數越多，所需讀取的數據量越大，受益越大，數據量小但是計算密集度較大的場合，受益就相對較小
由于RDD的特性，Spark不適用那種異步細粒度更新狀態的應用，例如web服務的存儲或者是增量的web爬蟲和索引。就是對于那種增量修改的應用模型不適合。
總的來說Spark的適用面比較廣泛且比較通用。
Spark是一個基于內存計算的開源的集群計算系統，目的是讓數據分析更加快速。Spark非常小巧玲瓏，由加州伯克利大學AMP實驗室的Matei為主的小團隊所開發。使用的語言是Scala，項目的core部分的代碼只有63個Scala文件，非常短小精悍。
Spark 是一種與 Hadoop 相似的開源集群計算環境，但是兩者之間還存在一些不同之處，這些有用的不同之處使 Spark 在某些工作負載方面表現得更加優越，換句話說，Spark 啟用了內存分布數據集，除了能夠提供交互式查詢外，它還可以優化迭代工作負載。
Spark 是在 Scala 語言中實現的，它將 Scala 用作其應用程序框架。與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數據集。
盡管創建 Spark 是為了支持分布式數據集上的迭代作業，但是實際上它是對 Hadoop 的補充，可以在 Hadoop 文件系統中并行運行。通過名為Mesos的第三方集群框架可以支持此行為。Spark 由加州大學伯克利分校 AMP 實驗室 (Algorithms, Machines, and People Lab) 開發，可用來構建大型的、低延遲的數據分析應用程序。
Spark 集群計算架構
雖然 Spark 與 Hadoop 有相似之處，但它提供了具有有用差異的一個新的集群計算框架。首先，Spark 是為集群計算中的特定類型的工作負載而設計，即那些在并行操作之間重用工作數據集（比如機器學習算法）的工作負載。為了優化這些類型的工作負載，Spark 引進了內存集群計算的概念，可在內存集群計算中將數據集緩存在內存中，以縮短訪問延遲。
Spark 還引進了名為彈性分布式數據集(RDD) 的抽象。RDD 是分布在一組節點中的只讀對象集合。這些集合是彈性的，如果數據集一部分丟失，則可以對它們進行重建。重建部分數據集的過程依賴于容錯機制，該機制可以維護 "血統"（即允許基于數據衍生過程重建部分數據集的信息）。RDD 被表示為一個 Scala 對象，并且可以從文件中創建它；一個并行化的切片（遍布于節點之間）；另一個 RDD 的轉換形式；并且最終會徹底改變現有 RDD 的持久性，比如請求緩存在內存中。
Spark 中的應用程序稱為驅動程序，這些驅動程序可實現在單一節點上執行的操作或在一組節點上并行執行的操作。與 Hadoop 類似，Spark 支持單節點集群或多節點集群。對于多節點操作，Spark 依賴于 Mesos 集群管理器。Mesos 為分布式應用程序的資源共享和隔離提供了一個有效平臺。該設置充許 Spark 與 Hadoop 共存于節點的一個共享池中。
什么是Hive on Spark？修改
1.在Hive里設置hive.execution.engine=spark，然后在Hive CLI里執行查詢Hive中的表。
2.在Spark程序中通過hiveContext.sql()查詢Hive中的表。
這兩種都是Hive on Spark嗎？還是說有什么區別
Hive有兩個execution backend, 一個是Tez, 另一個是MapReduce.
意思就是你的HiveQL語句的最終執行程序可以選擇Tez或者MapReduce.
Hive On Spark: 其實就是多一個Spark作為execution backend的選擇而已. 三者共生平行關系.
以下摘自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.
你說的第二個是Spark On Hive:
可以理解為Hive外包了一層基于Spark的User Interface. 即通過Spark可以直接進行Hive的相關操作: Hive Table , Hive UDFs, HiveQL等均可正常使用無誤.
這樣已經有歷史遺留問題的Hive的相關資料也可以通過SparkSQL繼續使用.
如果是新的資料, 你想仍放在以Hive作為data warehouse的里面的話, 直接使用SparkSQL可以享用Spark針對RDD設計的相關優化, 會比Hive On Spark的效能更好.
所謂Hive on Spark只是Hive項目的一個新特性，和Spark項目的開發沒啥關系。
針對你列的1和2的區別是：
1. 就是所謂的Hive on Spark，就是把hive執行引擎換成spark。眾所周知的是這個engine還可以設置和成mr（MRv1時代）和tez（目前hive13默認用的引擎，性能更佳），所以目前新增的spark選項只是Hive把執行計劃放到spark集群上運行而已。
2. 是Spark SQL的一個特性。就是可以把hive作為一個數據源，這樣我除了textFile從HDFS直接讀文件，還可以直接用HiveQL查詢到RDD，這對于要獲取保存在Hive表的數據太方便了。這個特性早就支持了，至少我在之前用Spark1.2的時候已經可以從Hive里導入數據啦，最新的1.5新增了更多接口，用起來更方便了。
所以，簡單來說區別1是Hive調用Spark任務，2是Spark調用Hive任務。
1.Hive on Spark。主要是對mr的一種性能優化（并不是所有場景都更好）
2.這個只是把hive當數據源。和你在其它語言中訪問Hive沒有差別。
其實還有一種情況，在SparkSQL中訪問底層的Hive存儲。更像是Spark on Hive，但是其實也是當作數據源而已。但是由于被隱藏在SparkSQL的配置中，看起來會覺得結合更緊密。
前者 是交互式的，后者是 應用式的（本來想說 非交互式的，感覺還不夠專業→_→）
關于Hadoop
官方文檔是最重要的
----------------------------------
Hadoop: the definitive guide
Hadoop in action
這兩本書還不錯
----------------------------------
http://allthingshadoop.com
Coursera上有一門UCSD開設的Big Data的專項課程
總共分五個課程，第一節大數據導論主要介紹的是大數據，hadoop是啥，有什么作用等等背景。
第二節是Map Reduce，HDFS，Spark等等的設計框架，實現機制等等，每一周后面還會有一個在虛擬機上用hadoop完成的小作業。比較初級的map reduce任務等等。
第三節是HBase Hive PIG等等更細一點的設計框架，實現機制，也都有對應的小作業。
第四節是big data在機器學習里的應用。
第五節還沒有開課。
每節課程都是4周，如果只是為了完成課程內容的話還是比較簡單的，但是覆蓋的范圍挺廣的，這個課程適合作為引導去深入的了解big data，不會教你怎么去搭環境等等具體的問題，主要是講原理的，搭配官方文檔和其他更細致的資料服用更佳。反正對我這種沒有工程實踐的學生來說對了解big data 幫助很大。
在coursera上直接搜big data就可以了
我只能弱弱的說一句。。課程費略貴。。
http://course.tuicool.com/course/tag/hadoop
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
總結
以上是生活随笔為你收集整理的zhihu spark集群,书籍,论文的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 手机游戏简要介绍
- 下一篇： 计算机组成原理--复习简答题+答案