爲什麼火花的讀寫速度如此之快S3

我明白spark在處理並行和in-mem大規模數據方面的優勢。爲什麼火花的讀寫速度如此之快S3

但是，在從S3讀取/寫入數據時，它如何在讀取/寫入S3方面沒有遇到瓶頸。 S3存儲服務是否以某種有效形式處理？ S3分佈式存儲？請提供一些解釋，並在可能的情況下提供關於如何瞭解更多信息的鏈接。

來源

2016-11-05 Dnaiel

好笑的是，我總是問自己，爲什麼他們這麼慢:) – 2016-11-05 14:09:33

笑。我的意思是與非分佈式存儲系統相比，硬盤的I/O速率是一個巨大的瓶頸。 – Dnaiel

內AWS唯一的瓶頸是：

甲network bandwidth limitation在Amazon EC2實例，基於實例類型（基本上，較大的情況下，有更多的網絡帶寬）
的Amazon EBS storage volumes速度（置備IOPS支撐高達20,000 IOPS）

某個區域內的吞吐量（例如Amazon EC2和Amazon S3之間）非常高，並且不太可能限制您傳輸數據的能力（除了EC2網絡頻帶上面提到的寬度限制）。

Amazon S3分佈在跨區域內多個可用區域的許多服務器上。在非常高的速度下，Amazon S3確實推薦使用Request Rate and Performance Considerations，但這隻有在每秒對特定存儲桶進行每秒超過300次PUT/LIST/DELETE請求或每秒超過800次GET請求時纔會發生。

Apache Spark通常部署在多個節點之間。每個節點都有基於其實例類型的可用網絡帶寬。 Spark的並行屬性意味着它可以比單個實例更快地向/從Amazon S3傳輸數據。

來源

2016-11-05 06:42:18

@jrotenstein謝謝！更具體地說，讓我們說我在S3中保存了X TB/PB的教科書數據，並且我在火花集羣中執行了典型的字數映射減少示例。讓我們還假設一半的數據可以適用於公羊（按照所有火花工人的公羊總和定義）。什麼時候將數據存入內存的時間百分比與執行映射的時間相比，減少步驟與將（字，數）元組寫回到磁盤的時間相比較。至於每個工人的CPU速度，我會假設一個標準的EC2實例（即r3.2xlarge或sthg）。 – Dnaiel

你必須運行一個spark工作，並查看統計數據來弄清楚。第一次運行數據總是最慢的，當它被加載到Spark和（可能）被緩存。隨後訪問該數據的速度會更快。因此，Spark適用於多次處理相同數據的情況（例如機器學習）。如果您只訪問一次數據，與非內存駐留查詢引擎相比，您看不到什麼好處。 –

Apache Spark通過EMR上的Amazon客戶端庫或其他地方的Apache Hadoop團隊與S3進行通信。如果您使用s3a：// URL，則使用最新的ASF客戶端。

我們一直在做很多工作以加快速度，請參閱HADOOP-11694。

性能殺手已被證明是制定文件時，HEAD請求

過度數字存在（太在代碼中的許多檢查）。修復：減少這些
關閉並重新打開連接尋求。修正：（a）懶尋找（只有在read（）上進行查找，而不是seek（）調用），（b）通過正向查找並丟棄數據。高效的甚至達幾百KB （YMMV等）
對於二進制ORC /鑲文件，加入了特殊fadvise =隨機模式，不嘗試源文件的完整GET，而不是讀以塊爲單位。如果我們需要尋求回退或長途前行，則丟棄該塊的其餘和重新使用HTTP 1.1連接：不需要來中止連接並重新協商新連接。

一些細節是從上個月這次談話：Spark and Object Stores，雖然它並沒有進入新的東西（在Hadoop中2.8（即將出版），HDP 2.5（運費），也許在CDH一些時間）深度。它會推薦各種性能設置，雖然今天有效。

而且一定要確保你使用任何壓縮可分裂（LZO，活潑的，...），以及你的文件不能太小以致有在列出目錄，並打開他們太多的開銷。

來源

2016-11-10 13:57:35

爲什麼火花的讀寫速度如此之快S3

回答

相關問題