spark優化
㈠ 為什麼說Spark SQL遠遠超越了MPP SQL
這里說的並不是性能，因為我沒嘗試對比過（下文會有簡單的說明），而是嘗試從某種更高一層次的的角度去看，為什麼Spark SQL 是遠遠超越MPP SQL的。
Spark SQL 和 MPP SQL 其實不在一個維度上。簡而言之，
MPP SQL 是 Spark SQL 的一個子集
Spark SQL 成為了一種跨越領域的交互形態
MPP SQL 是 Spark SQL 的一個子集
MPP SQL 要解決的技術問題是海量數據的查詢問題。這里根據實際場景，你還可以加上一些修飾詞彙，譬如秒級，Ad-hoc 之類。
在實際業務中
探索類業務，比如KPI多維分析，用戶畫像查詢，數據科學家摸底數據等
運營類業務，比如報表（現在很多BI系統基本上完全基於SQL來構建），各種運營臨時統計需求
分析類業務，不過這個會比較淺顯。顯然，真實的的分析應該主要依託一些統計類，機器學習等技術的支持
運維類業務，比如實時查詢查看海量的系統日誌等
MPP SQL 是有一定的性能優勢的，從HAWQ,Impala 等都是基於MPP架構的。然而僅限於此。這些功能Spark SQL 目前都已經涵蓋了，MPP SQL能做的事情，Spark SQL都完成的很漂亮。
依託於Spark 自身的全平台性(漂亮的DataSource API以及各個廠商的努力適配),Spark SQL 基本上可以對接任意多個異構數據源進行分析和查詢。大家可參考我的一個簡略實現 利用StreamingPro實現SQL-互動式查詢。
關於性能可以再多說兩句：
得益於一些具有復雜存儲格式的文件的誕生，譬如CarbonData, Spark SQL 已經實現海量數據的秒級查詢
Spark 自身通過Tungsten等項目的優化(尤其是代碼自動生成)，速度越來越生猛，而JVM譬如GC帶來的問題則可以進一步通過off-heap的方式減少。
所以 Spark SQL 和 MPP SQL在性能上的差距也會越來越小。
Spark SQL 成為了一種跨越領域的交互形態
Spark 通過使用DS（2.0統一了DF 和 DS，使用一套SQL引擎）極大的增強了交互語意，意味著你可以用SQL（DS）作為統一的交互語言完成流式，批處理，互動式查詢，機器學習等大數據領域常見場景。這在任何一個系統都是不多見的，也可見Spark團隊的抽象能力。
引言中的那篇文章其實是作者吐槽Spark 團隊對Spark core（RDD）那層關注太少了，所以開始發牢騷。
現在我們再回過頭來看我們常見的一些業務：
實時分析類業務
探索類業務
分析預測類業務
運營報表類業務
首先這些業務都可以使用Spark 來實現。其次統一的交互介面都是DS(DF/SQL),並且DS/SQL 是一套極度易用並且廣泛普及和接受的。
當然Spark 也不是一步就做到這點的，原來流式計算和批量計算就是兩套API, DF 和 DS 也是兩套API,後面經過發展，Databricks 團隊也在積極思考和慢慢成長，經過先前已經有的積累，才做到現在的這一步。
所以本質上DS/SQL 已經成為除了RDD API 以外，另外一套通用的，統一的互動式API，涵蓋了流式，批處理，互動式查詢，機器學習等大數據領域。這也是我們第一次達成這樣的統一，目前來看也僅在Spark平台上得以實現，它是的大數據的使用和學習門檻進一步降低，功在千秋。
RDD VS DS/SQL
DS/SQL 是一套數據類型首先，操作種類受限的表達語言，意味著Spark 團隊可以做更好的性能優化，也意味著門檻更低，在易用性和性能上都能取得良好的平衡
㈡ SparkSQL對於重復的計算怎麼優化
Sparksql是為了處理結構化數據的一個spark 模塊。
不同於spark rdd的基本API，spark sql介面更多關於數據結構本身與執行計劃等更多信息。
在spark內部，sql sql利用這些信息去更好地進行優化。
有如下幾種方式執行spark sql：SQL，DataFramesAPI與Datasets API。當相同的計算引擎被用來執行一個計算時，有不同的API和語言種類可供選擇。
這種統一性意味著開發人員可以來回輕松切換各種最熟悉的API來完成同一個計算工作。
㈢ spark 跑spark sql時cpu利用率特別高怎麼辦
優化過程中常用到方法
查看查詢的整個運行計劃
scala>query.queryExecution
查看查詢的Unresolved LogicalPlan
scala>query.queryExecution.logical
查看查詢的Analyzed LogicalPlan
scala>query.queryExecution.analyzed
查看優化後的LogicalPlan
scala>query.queryExecution.optimizedPlan
查看物理計劃
scala>query.queryExecution.sparkPlan
查看RDD的轉換過程
scala>query.toDebugString
SparkSQL調優
Spark是一個快速的內存計算框架，同時是一個並行運算的框架，在計算性能調優的時候，除了要考慮廣為人知的木桶原理外，還要考慮平行運算的Amdahl定理。
木桶原理又稱短板理論，其核心思想是：一隻木桶盛水的多少，並不取決於桶壁上最高的那塊木塊，而是取決於桶壁上最短的那塊。將這個理論應用到系統性能優化上，系統的最終性能取決於系統中性能表現最差的組件。例如，即使系統擁有充足的內存資源和CPU資源，但是如果磁碟I/O性能低下，那麼系統的總體性能是取決於當前最慢的磁碟I/O速度，而不是當前最優越的CPU或者內存。在這種情況下，如果需要進一步提升系統性能，優化內存或者CPU資源是毫無用處的。只有提高磁碟I/O性能才能對系統的整體性能進行優化。
SparkSQL作為Spark的一個組件，在調優的時候，也要充分考慮到上面的兩個原理，既要考慮如何充分的利用硬體資源，又要考慮如何利用好分布式系統的並行計算。由於測試環境條件有限，本篇不能做出更詳盡的實驗數據來說明，只能在理論上加以說明。
2.1 並行性
SparkSQL在集群中運行，將一個查詢任務分解成大量的Task分配給集群中的各個節點來運行。通常情況下，Task的數量是大於集群的並行度,shuffle的時候預設的spark.sql.shuffle.partitionsw為200個partition，也就是200個Task：
而實驗的集群環境卻只能並行3個Task，也就是說同時只能有3個Task保持Running：
這時大家就應該明白了，要跑完這200個Task就要跑200/3=67批次。如何減少運行的批次呢？那就要盡量提高查詢任務的並行度。查詢任務的並行度由兩方面決定：集群的處理能力和集群的有效處理能力。
l對於Spark Standalone集群來說，集群的處理能力是由conf/spark-env中的SPARK_WORKER_INSTANCES參數、SPARK_WORKER_CORES參數決定的；而SPARK_WORKER_INSTANCES*SPARK_WORKER_CORES不能超過物理機器的實際CPU core；
l集群的有效處理能力是指集群中空閑的集群資源，一般是指使用spark-submit或spark-shell時指定的--total-executor-cores，一般情況下，我們不需要指定，這時候，Spark Standalone集群會將所有空閑的core分配給查詢，並且在Task輪詢運行過程中，Standalone集群會將其他spark應用程序運行完後空閑出來的core也分配給正在運行中的查詢。
綜上所述，SparkSQL的查詢並行度主要和集群的core數量相關，合理配置每個節點的core可以提高集群的並行度，提高查詢的效率。
2.2 高效的數據格式
高效的數據格式，一方面是加快了數據的讀入速度，另一方面可以減少內存的消耗。高效的數據格式包括多個方面：
2.2.1 數據本地性
分布式計算系統的精粹在於移動計算而非移動數據，但是在實際的計算過程中，總存在著移動數據的情況，除非是在集群的所有節點上都保存數據的副本。移動數據，將數據從一個節點移動到另一個節點進行計算，不但消耗了網路IO，也消耗了磁碟IO，降低了整個計算的效率。為了提高數據的本地性，除了優化演算法（也就是修改spark內存，難度有點高），就是合理設置數據的副本。設置數據的副本，這需要通過配置參數並長期觀察運行狀態才能獲取的一個經驗值。
下面是Spark webUI監控Stage的一個圖：
lPROCESS_LOCAL是指讀取緩存在本地節點的數據
lNODE_LOCAL是指讀取本地節點硬碟數據
lANY是指讀取非本地節點數據
l通常讀取數據PROCESS_LOCAL>NODE_LOCAL>ANY，盡量使數據以PROCESS_LOCAL或NODE_LOCAL方式讀取。其中PROCESS_LOCAL還和cache有關。
2.2.2 合適的數據類型
對於要查詢的數據，定義合適的數據類型也是非常有必要。對於一個tinyint可以使用的數據列，不需要為了方便定義成int類型，一個tinyint的數據佔用了1個byte，而int佔用了4個byte。也就是說，一旦將這數據進行緩存的話，內存的消耗將增加數倍。在SparkSQL里，定義合適的數據類型可以節省有限的內存資源。
2.2.3 合適的數據列
對於要查詢的數據，在寫SQL語句的時候，盡量寫出要查詢的列名，如Select a,b from tbl，而不是使用Select * from tbl；這樣不但可以減少磁碟IO，也減少緩存時消耗的內存。
2.2.4 優的數據存儲格式
在查詢的時候，最終還是要讀取存儲在文件系統中的文件。採用更優的數據存儲格式，將有利於數據的讀取速度。查看SparkSQL的Stage，可以發現，很多時候，數據讀取消耗佔有很大的比重。對於sqlContext來說，支持 textFiile、SequenceFile、ParquetFile、jsonFile；對於hiveContext來說，支持AvroFile、ORCFile、Parquet File，以及各種壓縮。根據自己的業務需求，測試並選擇合適的數據存儲格式將有利於提高SparkSQL的查詢效率。
2.3 內存的使用
spark應用程序最糾結的地方就是內存的使用了，也是最能體現「細節是魔鬼」的地方。Spark的內存配置項有不少，其中比較重要的幾個是：
lSPARK_WORKER_MEMORY，在conf/spark-env.sh中配置SPARK_WORKER_MEMORY 和SPARK_WORKER_INSTANCES，可以充分的利用節點的內存資源，SPARK_WORKER_INSTANCES*SPARK_WORKER_MEMORY不要超過節點本身具備的內存容量；
lexecutor-memory，在spark-shell或spark-submit提交spark應用程序時申請使用的內存數量；不要超過節點的SPARK_WORKER_MEMORY；
lspark.storage.memoryFraction spark應用程序在所申請的內存資源中可用於cache的比例
lspark.shuffle.memoryFraction spark應用程序在所申請的內存資源中可用於shuffle的比例
在實際使用上，對於後兩個參數，可以根據常用查詢的內存消耗情況做適當的變更。另外，在SparkSQL使用上，有幾點建議：
l對於頻繁使用的表或查詢才進行緩存，對於只使用一次的表不需要緩存；
l對於join操作，優先緩存較小的表；
l要多注意Stage的監控，多思考如何才能更多的Task使用PROCESS_LOCAL；
l要多注意Storage的監控，多思考如何才能Fraction cached的比例更多
2.4 合適的Task
對於SparkSQL，還有一個比較重要的參數，就是shuffle時候的Task數量，通過spark.sql.shuffle.partitions來調節。調節的基礎是spark集群的處理能力和要處理的數據量，spark的默認值是200。Task過多，會產生很多的任務啟動開銷，Task多少，每個Task的處理時間過長，容易straggle。
2.5 其他的一些建議
優化的方面的內容很多，但大部分都是細節性的內容，下面就簡單地提提：
l 想要獲取更好的表達式查詢速度，可以將spark.sql.codegen設置為Ture；
l 對於大數據集的計算結果，不要使用collect() ,collect()就結果返回給driver，很容易撐爆driver的內存；一般直接輸出到分布式文件系統中；
l 對於Worker傾斜，設置spark.speculation=true 將持續不給力的節點去掉；
l 對於數據傾斜，採用加入部分中間步驟，如聚合後cache，具體情況具體分析；
l 適當的使用序化方案以及壓縮方案；
l 善於利用集群監控系統，將集群的運行狀況維持在一個合理的、平穩的狀態；
l 善於解決重點矛盾，多觀察Stage中的Task，查看最耗時的Task，查找原因並改善；
㈣ spark性能優化主要有哪些手段
其目的是在優化網路覆蓋的同時保證良好的接收質量，同時網路具備正確的鄰區關系，從而保證下一步業務優化時無線信號的分布是正常的，為優化工作打下良好的基矗 RF優化的特點決定其普遍存在於網路優化流程的各個階段..
㈤ spark driver會對任務進行優化嗎
會的。
這么說吧：spark中的一個application是由多個stages組成，一個stage又有多個tasks組成。那麼tasks執行先後可以組成一張有向無環圖（也就是我們常說的DAG），這個DAG的組織就是在driver端做的。driver端會根據寬依賴，窄依賴劃分stage，根據依賴關系，能並行處理的則盡量並行處理，這樣生成的dag深度則沒那麼深，也就進行優化了。
當然，每個executor也會對任務做優化了，比如pipeline執行，包括鎢絲計劃中的offheap等，這個可能要你深入理解了。
㈥ spark最佳實踐電子版 spark是什麼版本
《Spark大數據處理技術》以Spark 0.9版本為基礎進行編寫，是一本全面介紹Spark及Spark生態圈相關技術的書籍，是國內首本深入介紹Spark原理和架構的技術書籍。主要內容有Spark基礎功能介紹及內部重要模塊分析，包括部署模式、調度框架、存儲管理以及應用監控；同時也詳細介紹了Spark生態圈中其他的軟體和模塊，包括SQL處理引擎Shark和Spark SQL、流式處理引擎Spark Streaming、圖計算框架Graphx以及分布式內存文件系統Tachyon。《Spark大數據處理技術》從概念和原理上對Spark核心框架和生態圈做了詳細的解讀，並對Spark的應用現狀和未來發展做了一定的介紹，旨在為大數據從業人員和Spark愛好者提供一個更深入學習的平台。
《Spark大數據處理技術》適合任何大數據、Spark領域的從業人員閱讀，同時也為架構師、軟體開發工程師和大數據愛好者展現了一個現代大數據框架的架構原理和實現細節。相信通過學《Spark大數據處理技術》，讀者能夠熟悉和掌握Spark這一當前流行的大數據框架，並將其投入到生產實踐中去。
《Spark大數據處理：技術、應用與性能優化》根據最新技術版本，系統、全面、詳細講解Spark的各項功能使用、原理機制、技術細節、應用方法、性能優化，以及BDAS生態系統的相關技術。
通過上面兩本熟悉Spark的原理架構以及應用，想深入學習的話，還有《Apache Spark源碼剖析》，它全面、系統地介紹了Spark源碼，深入淺出。
㈦ 如何優化spark-streaming讀取kafka
spark streaming從1.2開始提供了數據的零丟失，想享受這個特性，需要滿足如下條件： 1.數據輸入需要可靠的sources和可靠的receivers 2.應用metadata必須通過應用driver checkpoint 3.WAL（write ahead log）
㈧ spark cg優化是什麼意思i
gc優化，垃圾回收優化。