spark最佳實踐源碼

1. 《深入理解SPARK核心思想與源碼分析》epub下載在線閱讀，求百度網盤雲資源

《深入理解SPARK》（耿嘉安）電子書網盤下載免費在線閱讀

資源鏈接：

鏈接：

書名：深入理解SPARK

作者：耿嘉安

豆瓣評分：7.2

出版社：機械工業出版社

出版年份：2016-1-1

頁數：469

內容簡介：

《深入理解SPARK：核心思想與源碼分析》結合大量圖和示例，對Spark的架構、部署模式和工作模塊的設計理念、實現源碼與使用技巧進行了深入的剖析與解讀。

《深入理解SPARK：核心思想與源碼分析》一書對Spark1.2.0版本的源代碼進行了全面而深入的分析，旨在為Spark的優化、定製和擴展提供原理性的指導。阿里巴巴集團專家鼎力推薦、阿里巴巴資深Java開發和大數據專家撰寫。

本書分為三篇：

准備篇（第1～2章），介紹了Spark的環境搭建、設計理念與基本架構，幫助讀者了解一些背景知識。

核心設計篇（第3～7章），著重講解SparkContext的初始化、存儲體系、任務提交與執行、計算引擎及部署模式的原理和源碼分析。通過這部分的內容，讀者可以通過源碼剖析更加深入理解Spark的核心設計與實現，以便在實際使用中能夠快速解決線上問題並對性能進行調優。

擴展篇（第8～11章），主要講解基於Spark核心的各種擴展及應用，包括SQL處理引擎、Hive處理、流式計算框架Spark Streaming、圖計算框架GraphX、機器學習庫MLlib等內容。通過閱讀這部分內容，讀者可以擴展實際項目中對Spark的應用場景，讓Spark煥發活力。

作者簡介：

耿嘉安，10年IT行業相關經驗。就職於阿里巴巴商家業務事業部，任資深Java工程師，專注於開源和大數據領域，目前與小夥伴們基於ODPS構建阿里的大數據商業解決方案——御膳房。在大量的工作實踐中，對J2EE、JVM、Tomcat、Spring、Hadoop、Spark、MySQL、Redis都有深入研究，尤其喜歡剖析開源項目的源碼實現。早期從事J2EE企業級應用開發，對Java相關技術有獨到見解。業余時間喜歡研究中國古代歷史，古詩詞，旅遊，足球等。

2. 求《深入理解spark核心思想及源碼分析》全文免費下載百度網盤資源,謝謝~

《深入理解spark核心思想及源碼分析》網路網盤pdf最新全集下載:
鏈接：https://pan..com/s/1iOq9-MrepVdWcIrbALPMPg

3. Spark源碼分析之SparkSubmit的流程

本文主要對SparkSubmit的任務提交流程源碼進行分析。 Spark源碼版本為2.3.1。

首先閱讀一下啟動腳本，看看首先載入的是哪個類，我們看一下 spark-submit 啟動腳本中的具體內容。

可以看到這里載入的類是org.apache.spark.deploy.SparkSubmit，並且把啟動相關的參數也帶過去了。下面我們跟一下源碼看看整個流程是如何運作的...

SparkSubmit的main方法如下

這里我們由於我們是提交作業，所有會走上面的submit(appArgs, uninitLog)方法

可以看到submit方法首先會准備任務提交的環境，調用了prepareSubmitEnvironment，該方法會返回四元組，該方法中會調用doPrepareSubmitEnvironment，這里我們重點注意 childMainClass類具體是什麼 ，因為這里涉及到後面啟動我們主類的過程。

以下是doPrepareSubmitEnvironment方法的源碼...

可以看到該方法首先是解析相關的參數，如jar包，mainClass的全限定名，系統配置，校驗一些參數，等等，之後的關鍵點就是根據我們 deploy-mode 參數來判斷是如何運行我們的mainClass，這里主要是通過childMainClass這個參數來決定下一步首先啟動哪個類。

childMainClass根據部署模型有不同的值:

之後該方法會把准備好的四元組返回，我們接著看之前的submit方法

可以看到這里最終會調用doRunMain()方法去進行下一步。

doRunMain的實現如下...

doRunMain方法中會判斷是否需要一個代理用戶，然後無論需不需要都會執行runMain方法，我們接下來看看runMain方法是如何實現的。

這里我們只假設以集群模式啟動，首先會載入類，將我們的childMainClass載入為位元組碼對象mainClass ，然後將mainClass 映射成SparkApplication對象，因為我們以集群模式啟動，那麼上一步返回四元組中的childMainClass的參數為ClientApp的全限定名，而這里會調用app實例的start方法因此，這里最終調用的是ClientApp的start方法。

ClientApp的start方法如下...

可以看到這里和之前我們的master啟動流程有些相似。
可以參考我上一篇文章 Spark源碼分析之Master的啟動流程 對這一流程加深理解。

首先是准備rpcEnv環境，之後通過master的地址獲取masterEndpoints端點相關信息，因為這里運行start方法時會將之前配置的相關參數都傳進來，之後就會通過rpcEnv注冊相關clientEndPoint端點信息，同時需要注意，這里會把masterEndpoints端點信息也作為構造ClientEndpoint端點的參數，也就是說這個ClientEndpoint會和masterEndpoints通信。

而在我上一篇文章中說過，只要是setupEndpoint方法被調用，一定會調用相關端點的的onStart方法，而這會調用clientEndPoint的onStart方法。

ClientEndPoint類中的onStart方法會匹配launch事件。源碼如下

onStart中匹配我們的launch的過程，這個過程是啟動driverWrapper的過程，可以看到上面源碼中封裝了mainClass ，該參數對應DriverWrapper類的全限定名，之後將mainClass封裝到command中，然後封裝到driverDescription中，向Master申請啟動Driver。

這個過程會向Mster發送消息，是通過rpcEnv來實現發射消息的，而這里就涉及到outbox信箱，會調用postToOutbox方法，向outbox信箱中添加消息，然後通過TransportClient的send或sendRpc方法發送消息。發件箱以及發送過程是在同一個線程中進行。

而細心的同學會注意到這里調用的方法名為SendToMasterAndForwardReply，見名之意，發送消息到master並且期待回應。

下面是rpcEnv來實現向遠端發送消息的一個調用流程，最終會通過netty中的TransportClient來寫出。

之後，Master端會觸發receiveAndReply函數,匹配RequestSubmitDriver樣例類，完成模式匹配執行後續流程。

可以看到這里首先將Driver信息封裝成DriverInfo，然後添加待調度列表waitingDrivers中，然後調用通用的schele函數。

由於waitingDrivers不為空，則會走LaunchDriver的流程，當前的application申請資源，這時會向worker發送消息，觸發Worker的receive方法。

Worker的receive方法中，當Worker遇到LaunchDriver指令時，創建並啟動一個DriverRunner，DriverRunner啟動一個線程，非同步的處理Driver啟動工作。這里說啟動的Driver就是剛才說的org.apache.spark.deploy.worker.DriverWrapper

可以看到上面在DriverRunner中是開辟線程非同步的處理Driver啟動工作，不會阻塞主進程的執行，而prepareAndRunDriver方法中最終調用 runDriver..

runDriver中主要先做了一些初始化工作，接著就開始啟動driver了。

上述Driver啟動工作主要分為以下幾步：

下面我們直接看DriverWrapper的實現

DriverWrapper，會創建了一個RpcEndpoint與RpcEnv，RpcEndpoint為WorkerWatcher，主要目的為監控Worker節點是否正常，如果出現異常就直接退出，然後當前的ClassLoader載入userJar，同時執行userMainClass，在執行用戶的main方法後關閉workerWatcher。

以上就是SparkSubmit的流程，下一篇我會對SparkContext的源碼進行解析。

歡迎關注...

4. 深入理解spark核心思想與源碼分析 怎麼樣

SparkSQL主要的推動者是Databricks。提到SparkSQL不得不提的就是Shark。Shark可以理解為Spark社區這邊搞的一個」HiveonSpark」，把Hive的物理執行計劃使用Spark計算引擎去執行。這裡面會有一些問題，Hive社區那邊沒有把物理執行計劃到執行引擎這個步驟抽象出公共API，所以Spark社區這邊要自己維護一個Hive的分支，而且Hive的設計和發展不太會考慮到如何優化Spark的Job。但是前面提到的HiveonSpark卻是和Hive一起發布的，是由Hive社區控制的。所以後來Spark社區就停止了Shark的開發轉向SparkSQL（「坑了」一部分當時信任Shark的人）。SparkSQL是把SQL解析成RDD的transformation和action，而且通過catalyst可以自由、靈活的選擇最優執行方案。對資料庫有深入研究的人就會知道，SQL執行計劃的優化是一個非常重要的環節，SparkSQL在這方面的優勢非常明顯，提供了一個非常靈活、可擴展的架構。但是SparkSQL是基於內存的，元數據放在內存裡面，不適合作為數據倉庫的一部分來使用。所以有了SparkSQL的HiveContext，就是兼容Hive的SparkSQL。它支持HiveQL,HiveMetastore,HiveSerDesandHiveUDFs以及JDBCdriver。這樣看起來很完美，但是實際上也有一些缺點：SparkSQL依賴於Hive的一個snapshot，所以它總是比Hive的發布晚一個版本，很多Hive新的feature和bugfix它就無法包括。而且目前看Spark社區在Spark的thriftserver方面的投入不是很大，所以感覺它不是特別想朝著這個方向發展。還有一個重要的缺點就是SparkSQL目前還不能通過分析SQL來預測這個查詢需要多少資源從而申請對應的資源，所以在共享集群上無法高效地分配資源和調度任務。