戳藍字“CSDN云計算”關注我們哦！

由于統(tǒng)一訪問對象存儲（如S3）和HDFS數(shù)據(jù)的場景的出現(xiàn)和普及，Apache Spark結合Alluxio的大數(shù)據(jù)棧越來越受歡迎。此外，越來越流行的計算與存儲分離的架構導致計算端查詢延遲增大。因此，Alluxio常被用作貼近計算端的熱數(shù)據(jù)存儲以提高性能。為了能夠獲得最佳性能，用戶需要像使用其他技術棧組合一樣遵循最佳的實戰(zhàn)經(jīng)驗。本文介紹了在Alluxio上運行Spark時,對于實際工作負載性能調(diào)優(yōu)的十大技巧。

關于數(shù)據(jù)本地性

數(shù)據(jù)本地性就是盡量將計算移到數(shù)據(jù)所在的節(jié)點上進行，避免數(shù)據(jù)在網(wǎng)絡上的傳輸。分布式數(shù)據(jù)并行環(huán)境下，數(shù)據(jù)的本地性非常重要。提高數(shù)據(jù)本地性能夠極大地提升Spark作業(yè)的性能。如果需要計算的數(shù)據(jù)存儲在節(jié)點本地，那么Spark任務可以直接以內(nèi)存速度（當配置ramdisk時）從本地Alluxio worker中讀取Alluxio中的數(shù)據(jù)，而不必通過網(wǎng)絡進行數(shù)據(jù)傳輸。首先我們要介紹的幾個調(diào)優(yōu)技巧是關于數(shù)據(jù)本地性方面的。

1 檢查Spark作業(yè)讀取Alluxio時的數(shù)據(jù)本地性

當Spark worker與Alluxio worker同置部署(co-locate)在同一節(jié)點上時，Alluxio能夠通過支持短路讀寫（見文末鏈接1）為Spark計算任務提供最佳的性能。用戶有多種方法檢查I/O請求是否實際由Alluxio短路讀/寫提供數(shù)據(jù)訪問服務，具體方法如下：

方法1：當運行Spark任務時，觀察監(jiān)控頁面Alluxio metrics UI page（見文末鏈接2）上的Short-circuit reads和From RemoteInstance的兩個指標。此外，還可以觀察cluster.BytesReadAlluxioThroughput和cluster.BytesReadLocalThroughput兩個指標的值進行判斷。如果數(shù)據(jù)的本地讀寫吞吐量為零或遠低于總吞吐量，那么說明該Spark作業(yè)可能沒有本地的Alluxio worker進行數(shù)據(jù)交互。

方法2：利用dstat（見文末鏈接3）等工具檢測網(wǎng)絡流量，這樣我們就可以看到短路讀取是否發(fā)生以及實際的網(wǎng)絡吞吐量。YARN用戶還可以在/var/log/hadoop-yarn/userlogs日志中查找如下信息：INFO ShuffleBlockFetcherIterator: Started 0 remote fetches in 0ms，觀察遠程讀取是否發(fā)生，或者都是短路讀取。運行Spark作業(yè)時，用戶可以通過配置YARN相關參數(shù)（例如--master yarn--num-executors 4 --executor-cores 4）來開啟收集這些日志。

如果用戶通過上述方法發(fā)現(xiàn)Alluxio對Spark作業(yè)只提供了一小部分短路讀取或?qū)懭?#xff0c;請閱讀下面幾條技巧以提升數(shù)據(jù)本地性。

2?確保Spark Executor本地性

Spark中的數(shù)據(jù)本地性分為兩種：executor 層面的本地性（executor locality）、task 層面的本地性（task locality） 。Executor級別的本地性意味著當Spark作業(yè)由其他資源管理框架（如Mesos和YARN）部署時，Spark Executor會被分配在同時運行Alluxio worker的節(jié)點上，從而和Alluxio worker運行于統(tǒng)一的節(jié)點。如果Executor的本地性沒有達到，Alluxio就無法為Spark作業(yè)提供本地的數(shù)據(jù)服務。我們經(jīng)常會發(fā)現(xiàn)，相比于Spark Standalone模式部署，當Spark通過Spark on Yarn或Spark on Mesos等資源管理框架的模式進行部署時，executor本地性經(jīng)常難以保證。

較新版本的Spark在YARN和Mesos框架調(diào)度分發(fā)executors時能夠考慮數(shù)據(jù)本地性因素，此外還有方法可以強制在所需節(jié)點上啟動executors。因此，一個簡單的策略是在每個節(jié)點上都啟動executor，這樣能夠保證在每個所需節(jié)點上都至少有一個executor運行著。

然后，由于實際情況下的資源限制，在通常生產(chǎn)環(huán)境中的每個節(jié)點上都部署運行Alluxioworker還比較困難。為了能夠?qū)lluxioworker與計算節(jié)點同置部署(co-locate)，用戶可以利用類似于資源管理框架YARN中的節(jié)點標簽（見文末鏈接4）功能。具體地，首先，將包含Alluxioworker的NodeManagers節(jié)點標簽標記為alluxio（具體標簽取名不重要）。然后，用戶將Spark作業(yè)提交到該alluxio標簽指定的節(jié)點。最后，系統(tǒng)會在這些機器節(jié)點上啟動Spark作業(yè)的executors并與Alluxio workers進行協(xié)同工作。

3?確保Spark Task本地性

Task層面的數(shù)據(jù)本地性是屬于下一層次的本地性，它是由Spark本身決定的。達到Task本地性表示一旦啟動executor，Spark能夠?qū)?span lang="en-us">task調(diào)度到滿足數(shù)據(jù)本地性的executor上執(zhí)行（在與Alluxio結合的場景下，即在將task調(diào)度到通過Alluxio提供本地數(shù)據(jù)的executor上執(zhí)行）。為了達到該目標，Spark任務調(diào)度器需要首先從Alluxio收集所有數(shù)據(jù)的位置信息。該位置信息以Alluxio worker的主機名列表進行表示。然后，嘗試匹配Spark executor主機名進行調(diào)度。用戶可以從Alluxio master web UI中查看到Alluxio worker的主機名，也可以通過Spark driver web UI找到Spark executor的主機名。

然而，有時由于不同網(wǎng)絡環(huán)境或配置方面的原因，在同一臺機器上運行的Alluxio worker和Spark executor提供的主機名可能并不匹配。在這種情況下，Spark?的任務調(diào)度器將會混淆主機名的匹配從而無法確保數(shù)據(jù)本地性。因此，Alluxio worker的主機名與Spark executor的主機名采用相同的“主機名名稱空間”非常重要。用戶經(jīng)常會遇到的一個問題是：Alluxio worker和Spark executor一個使用IP地址標示，而另一個使用主機名標示。如果發(fā)生了這種情況，用戶仍然可以在Spark中手動設置Alluxio-client屬性alluxio.user.hostname（見文末鏈接5)，并將Alluxio worker中的alluxio.worker.hostname屬性設置為相同值來解決該問題。此外，用戶也可以查閱JIRASPARK-10149（見文末鏈接6）以獲取Spark開源社區(qū)的解決方案。

4?優(yōu)先考慮Spark調(diào)度器中的本地性因素

關于本地性， Spark客戶端有一些配置參數(shù)可供調(diào)優(yōu)。具體地，spark.locality.wait：即數(shù)據(jù)本地性降級的等待時間，默認是3000毫秒，如果超時就啟動下一本地優(yōu)先級別的task。該配置參數(shù)同樣可以應用到不同優(yōu)先級的本地性之間（PROCESS_LOCAL，NODE_LOCAL，RACK_LOCAL，ANY）。我們也可以通過將參數(shù)spark.locality.wait.node設置為特定的本地性級別，從而實現(xiàn)自定義每個節(jié)點的本地性等待時間。

負載均衡

負載均衡同樣非常重要，它能夠確保Spark作業(yè)的執(zhí)行能夠均勻地分布在不同可用節(jié)點上。以下的幾個技巧介紹如何避免由于Alluxio輸入數(shù)據(jù)傾斜導致負載或者任務調(diào)度不均衡。

5?使用DeterministicHashPolicy通過Alluxio從UFS冷讀數(shù)據(jù)

同一個Spark作業(yè)的多個task經(jīng)常會讀取相同的輸入文件。當該文件沒有加載到Alluxio中時，默認情況下，不同task的本地Alluxio worker將從UFS讀取相同的文件。這可能導致如下后果：

• 多個Alluxio worker同時競爭相同數(shù)據(jù)的Alluxio-UFS連接。如果從Alluxio到UFS的連接速度很慢，每個worker都會因為這些不必要的競爭而造成數(shù)據(jù)讀取速度變慢。

• 同一份數(shù)據(jù)會在Alluxio緩存空間中存儲多個副本，造成大量的空間浪費，并間接造成那些對其他查詢有用的數(shù)據(jù)被剔出出Alluxio緩存空間。

解決此問題的一種方法是將alluxio.user.ufs.block.read.location.policy設置為DeterministicHashPolicy以協(xié)調(diào)Alluxio worker從UFS讀取數(shù)據(jù)的過程，避免產(chǎn)生不必要的競爭。例如，編輯spark / conf /spark-defaults.conf以確保最多允許四個隨機Alluxio worker讀取給定數(shù)據(jù)塊。（具體數(shù)目由alluxio.user.ufs.block.read.location.policy.deterministic.hash.shards參數(shù)決定）

spark.driver.extraJavaOptions=-Dalluxio.user.ufs.block.read.location.policy=alluxio.client.block.policy.DeterministicHashPolicy

spark.executor.extraJavaOptions=-Dalluxio.user.ufs.block.read.location.policy.deterministic.hash.shards=4

注意，通過上述設置，系統(tǒng)將為不同的數(shù)據(jù)塊隨機選擇一組不同的四個worker與之對應。

6 采用更小的Alluxio數(shù)據(jù)塊獲得更高的并行度

數(shù)據(jù)塊（block）是Alluxio系統(tǒng)中最小的存儲單元。當Alluxio數(shù)據(jù)塊大小（默認為512MB）相較于一個文件本身很大時，就意味著該文件只包含少數(shù)幾個數(shù)據(jù)塊。因此，也就只有少數(shù)幾個Alluxio worker能夠為并行地讀取文件提供服務。具體地，為了獲得數(shù)據(jù)NODE_LOCAL本地性，在Spark的“文件掃描”階段，task可能只分配給少數(shù)幾個服務器處理。這會導致大多數(shù)服務器閑置，從而導致集群負載不平衡，處理并發(fā)度低下。在這種情況下，使用較小的塊來組織存儲Alluxio的文件（例如，將alluxio.user.block.size.bytes.default設置為128MB或更小），能夠增加文件的數(shù)據(jù)塊數(shù)量，使得文件的數(shù)據(jù)分散地存儲在更多的機器中，從而提升文件數(shù)據(jù)讀取的并行度。。請注意，當UFS是HDFS時，自定義調(diào)整Alluxio塊大小的方法會不適用，因為Alluxio的數(shù)據(jù)塊大小會被強制設置為HDFS塊大小。

7?調(diào)整優(yōu)化executor數(shù)目以及每個executor的task數(shù)目

在一個executor中運行過多的task并發(fā)地從Alluxio中讀取數(shù)據(jù)可能會造成網(wǎng)絡連接、網(wǎng)絡帶寬等資源的爭用。基于Alluxio worker節(jié)點的數(shù)量，用戶可以通過合理地調(diào)整executor的數(shù)量以及每個executor的task數(shù)量（ Spark中可配），從而更好地將task分配給更多節(jié)點（獲取更高的Alluxio帶寬），并減少資源爭用的開銷。

8?預加載數(shù)據(jù)到Alluxio

盡管Alluxio提供了透明性和異步緩存機制（見文末鏈接7），但是用戶的第一次冷讀取還是會存在性能開銷。為了避免這個問題，用戶通過使用以下命令行將數(shù)據(jù)預加載到Alluxio存儲空間中：

bash

$ bin/alluxio fs load /path/to/load

--Dalluxio.user.ufs.block.read.location.policy=alluxio.client.file.policy.MostAvailableFirstPolicy

注意：load命令只是簡單地從底層存儲的這臺節(jié)點中中加載目標文件到Alluxio，因此數(shù)據(jù)寫入到Alluxio的速度往往會受到單個服務器節(jié)點的限制。在Alluxio 2.0中，我們計劃實現(xiàn)分布式加載數(shù)據(jù)功能以提高加載的吞吐量。

容量管理

Alluxio為用戶提供一個高層的熱點輸入數(shù)據(jù)緩存服務。事實上，正確合理的分配和管理緩存的容量配額對取得好性能同樣非常重要。

9?使用SSD或HDD擴展Alluxio系統(tǒng)存儲容量

Alluxio workers也可以使用本地SSD（固態(tài)硬盤）或者HDD（硬盤）來和RAM（內(nèi)存）存儲資源進行互補。為了減少數(shù)據(jù)被剔除Alluxio存儲空間，我們建議在Alluxio存儲層中設置多級存儲目錄而非僅采用單一存儲層，詳情參見文末鏈接8。在AWS EC2上運行Alluxio workers的用戶需要注意：將EBS存儲掛載為本地磁盤會通過網(wǎng)絡傳輸數(shù)據(jù)，這可能會造成數(shù)據(jù)訪問速度可能很慢。

10?關閉被動緩存特性以防緩存垃圾

Alluxio客戶端的配置參數(shù)alluxio.user.file.passive.cache.enabled可以控制是否在Alluxio中緩存額外的數(shù)據(jù)副本。這個屬性是默認開啟的(即alluxio.user.file.passive.cache.enabled=true)。因此，在客戶端請求數(shù)據(jù)時，一個Alluxio worker可能會緩存已經(jīng)在其他worker上存在的數(shù)據(jù)。當該屬性為false時，Alluxio存儲空間中數(shù)據(jù)將不會有任何額外副本。

值得注意的是，當開啟該屬性時，相同的數(shù)據(jù)塊可以在多個workers處訪問到，這樣的多副本存儲會降低Alluxio空間的總存儲容量。根據(jù)數(shù)據(jù)集的大小與Alluxio的存儲容量，關閉被動緩存對于不需要數(shù)據(jù)本地性但希望更大的Alluxio存儲容量的工作負載是有益的。未來，?Alluxio 2.0將會支持更細粒度的數(shù)據(jù)副本設置，例如靈活配置Alluxio中給定文件的副本數(shù)最小值和最大值。

附錄鏈接：

鏈接1：

https://www.alluxio.org/docs/1.8/en/Architecture-DataFlow.html#local-cache-hit

鏈接2：

http://www.alluxio.org/docs/1.8/en/operation/Metrics-System.html

鏈接3：

https://linux.die.net/man/1/dstat

鏈接4：

https://hadoop.apache.org/docs/r2.9.1/hadoop-yarn/hadoop-yarn-site/ NodeLabel. html

鏈接5：

http://www.alluxio.org/docs/1.8/en/compute/Spark.html#advanced -setup

鏈接6：

https://issues.apache.org/jira/browse/SPARK-10149

鏈接7：

https://www.alluxio.com/blog/asynchronous-caching-in-alluxio-high-performance-for-partial-read-caching

鏈接8：

https://www.alluxio.org/docs/1.8/en/advanced/Alluxio-Storage-Management. html# single-tier-storage

本文作者：范斌, 馮濱, Gene Pang, Madan Kumar and Reid Chan (Momo)

作者簡介：范斌, 馮濱,?Gene Pang, Madan Kumar均為Alluxio maintainer。Reid Chan 陌陌大數(shù)據(jù)平臺開發(fā)工程師，負責Alluxio, HBase, Phoenix, Kerberos等開發(fā)運維工作，支持鼓勵開源工作，是HBase Committer之一。

1.微信群：

添加小編微信：color_ld，備注“進群+姓名+公司職位”即可，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

2.征稿：

投稿郵箱：liudan@csdn.net；微信號：color_ld。請備注投稿+姓名+公司職位。

推薦閱讀

• 2018，這一年的騰訊優(yōu)圖，我們總結一下！

• 有問有答 | AWS使用精華問答，帶您開啟 AWS 上的云計算之旅！

• 程序員的年度未解之謎：加班背鍋的是我，得優(yōu)秀員工的卻是他

• 特斯拉“撞死”機器人，是炒作還是事故？

• 買不到回家的票，都是“搶票加速包”惹的禍？

• 君士坦丁堡硬分叉姍姍來遲，以太坊2.0還要等多久？

• 剛剛！程序員集體榮獲2個冠軍，這份2018 IT報告還說這些！
  

點擊“閱讀原文”，打開 CSDN App 閱讀更貼心！

喜歡就點擊“好看”吧！

總結

以上是生活随笔為你收集整理的Spark+Alluxio性能调优十大技巧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。