Spark性能優化案例

Spark性能優化案例

主流大數據技術都是開源的：

Hadoop大數據存儲與計算產品

Hive、Spark SQL大數據倉庫

Storm、Flink這樣的大數據流計算產品

Mahout、MLlib大數據機器學習算法庫

如何參與Apache軟件開發，如何進行軟件性能優化及Spark源碼優化：

更深入、系統地了解軟件性能優化

更深入了解Spark的一些運行機制，同時也可以了解Apache開源社區的運作模式。因為我們在使用各類大數據產品的時候，一定會遇到各種問題，想要解決這些問題，你可以直接到官方的開源社區去求助并尋找答案。在使用過程中，如果這些大數據產品不能滿足你的需求，你可以閱讀源代碼并直接對源代碼進行修改和優化。因為你在實踐過程中產生的需求可能其他人也會有，你可以將你修改的源代碼提交到開源社區，請求合并到發布版本上，供全世界開發者使用。

Apache開源社區的組織和參與方式

Apache是一個以基金會方式運作的非盈利開源軟件組織，旗下有超過一百個各類開源軟件，如Apache、Tomcat、Kafka、Hadoop、Spark。

Apache每個項目的管理團隊叫項目管理委員會（PMC），一般由項目發起者、核心開發者、Apache基金會指定的資深導師組成，主導整個項目發展。項目主要開發者叫committer，是指有將代碼合并到主干代碼權限的開發者，而其他沒有代碼合并權限的開發者叫作contributor。

一般參與Apache開源產品開發，先從contributor做起。從GitHub項目倉庫fork代碼到自己的倉庫，在自己倉庫修改代碼然后創建pull request，提交到Spark倉庫后，若有committer認為沒問題，就merge到Spark主干代碼。

一旦你為某個Apache項目提交的代碼被merge到代碼主干，你就可以宣稱自己是這個項目的contributor了，寫入自己的簡歷！如果能持續提交高質量的代碼，甚至直接負責某個模塊，你就有可能被邀請成為committer，擁有apache.org后綴郵箱。

希望你提交的是質量代碼，而不僅是對代碼注釋里某個單詞拼寫錯誤修改。雖然修改注釋也有價值，但你的pull request總是修改注釋的拼寫錯誤，很難被認為是強力開發者。

軟件性能優化

熟悉開源社區的運作方式后，開始考慮開始進行性能優化了。性能優化具體要做些什么呢？有個著名論斷。

1.你不能優化一個沒有經過性能測試的軟件

2.你不能優化一個你不了解其架構設計的軟件

若無性能測試，你就不會知道當前軟件主要性能指標。通常來說，軟件的主要性能指標包括：

響應時間：完成一次任務（請求）花費的時間。

并發數：同時處理的任務數（請求數）。

吞吐量：單位時間完成的任務數（請求數、事務數、查詢數……）。

性能計數器：System Load，線程數，進程數，CPU、內存、磁盤、網絡使用率等。

如果沒有性能指標，我們也就不清楚軟件性能的瓶頸，優化前和優化后也是無從對比。這樣的優化工作只能是主觀臆斷：別人這樣做說性能好，我們也這樣優化。

而如果不了解軟件的架構設計，你可能根本無從判斷性能瓶頸產生的根源，也不知道該從哪里優化。

性能優化的過程

做性能測試，分析性能狀況和瓶頸點

針對軟件架構設計進行分析，尋找導致性能問題的原因

修改相關代碼和架構，進行性能優化

做性能測試，對比是否提升性能，并尋找下一個性能瓶頸

大數據軟件性能優化

在大數據使用、開發過程的性能優化一般可以從以下角度著手進行。

1. SQL語句優化。使用關系數據庫的時候，SQL優化是數據庫優化的重要手段，因為實現同樣功能但是不同的SQL寫法可能帶來的性能差距是數量級的。我們知道在大數據分析時，由于數據量規模巨大，所以SQL語句寫法引起的性能差距就更加巨大。典型的就是Hive的MapJoin語法，如果join的一張表比較小，比如只有幾MB，那么就可以用MapJoin進行連接，Hive會將這張小表當作Cache數據全部加載到所有的Map任務中，在Map階段完成join操作，無需shuffle。

2. 數據傾斜處理。數據傾斜是指當兩張表進行join的時候，其中一張表join的某個字段值對應的數據行數特別多，那么在shuffle的時候，這個字段值（Key）對應的所有記錄都會被partition到同一個Reduce任務，導致這個任務長時間無法完成。淘寶的產品經理曾經講過一個案例，他想把用戶日志和用戶表通過用戶ID進行join，但是日志表有幾億條記錄的用戶ID是null，Hive把null當作一個字段值shuffle到同一個Reduce，結果這個Reduce跑了兩天也沒跑完，SQL當然也執行不完。像這種情況的數據傾斜，因為null字段沒有意義，所以可以在where條件里加一個userID != null過濾掉就可以了。

3. MapReduce、Spark代碼優化。了解MapReduce和Spark的工作原理，了解要處理的數據的特點，了解要計算的目標，設計合理的代碼處理邏輯，使用良好的編程方法開發大數據應用，是大數據應用性能優化的重要手段，也大數據開發工程師的重要職責。

4. 配置參數優化。根據公司數據特點，為部署的大數據產品以及運行的作業選擇合適的配置參數，是公司大數據平臺性能優化最主要的手段，也是大數據運維工程師的主要職責。比如Yarn的每個Container包含的CPU個數和內存數目、HDFS數據塊的大小和復制數等，每個大數據產品都有很多配置參數，這些參數會對大數據運行時的性能產生重要影響。

5. 大數據開源軟件代碼優化。曾經和杭州某個SaaS公司的大數據工程師聊天，他們的大數據團隊只有5、6個人，但是在使用開源大數據產品的時候，遇到問題都是直接修改Hadoop、Spark、Sqoop這些產品的代碼。修改源代碼進行性能優化的方法雖然比較激進，但是對于掌控自己公司的大數據平臺來說，效果可能是最好的。

Spark性能優化

性能測試，使用Intel為某視頻網站編寫的一個基于Spark的關系圖譜計算程序，用于計算視頻的級聯關系。

使用5臺服務器對樣例數據進行性能測試，程序運行總體性能：

將4臺Worker服務器上主要計算資源利用率指標和這張圖各個job與stage的時間點結合，就可以看到不同運行階段的性能指標如何，從而發現性能瓶頸：

可見，CPU、內存、網絡、磁盤這四種主要計算資源的使用和Spark的計算階段密切相關。后面我主要通過這些圖來分析Spark的性能問題，進而尋找問題根源，并進一步進行性能優化。

FAQ

若性能測試發現，網卡是整個系統的瓶頸，程序運行過程中網卡達到了最大I/O能力，整個系統經常在等待網卡的數據傳輸，請問，你有什么性能優化建議

Hive spark 大數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。