なぜS3から非常に速く読み書きするのですか

Question

並列とメモリ内で大規模なデータを処理するという点で、私はスパークの利点を理解しています。

しかし、S3との間でデータを読み書きする際に、S3への読み書きのボトルネックはありません。それはS3ストレージサービスによって効率的な形で処理されますか？ S3はストレージを分散していますか？可能であれば、いくつかの説明を提供してください。 AWS内

Answer 1

唯一のボトルネックは、以下のとおりです。

• インスタンスタイプ（基本的には、より大きなインスタンスはより多くのネットワーク帯域幅を持っている）
• Amazon EBS storage volumes（プロビジョニングIOPS支持体の速度に基づいてAmazon EC2インスタンス上network bandwidth limitation、最大20,000 IOPS）

Amazon EC2とAmazon S3の間など、リージョン内のスループットは非常に高く、データ転送の能力は制限されません（EC2ネットワーク帯域上記の幅制限）。

Amazon S3は、リージョン内の複数の可用性ゾーンにまたがる多数のサーバーに分散しています。非常に高速では、Amazon S3にはいくつか推奨されているRequest Rate and Performance Considerationsがありますが、これは特定のバケットに対して1秒あたり300件以上のPUT/LIST/DELETE要求または1秒あたり800件以上のGET要求を行う場合のみです。

Apache Sparkは、通常、複数のノードのに配置されます。各ノードは、そのインスタンスタイプに基づいて利用可能なネットワーク帯域幅を持っています。 並列性のSparkは、単一のインスタンスで実行できるよりもはるかに高速にAmazon S3との間でデータを転送できることを意味します。

Answer 2

Apache Sparkは、EMRのAmazonのクライアントライブラリまたは他の場所のApache HadoopチームからS3への通話を行います。 s3a：// URLを使用する場合は、最新のASFクライアントを使用しています。

私たちは高速化に多くの作業をしています。HADOOP-11694を参照してください。 （コードであまりにも多くの チェック）が存在し

パフォーマンスキラーは、ファイルをワークアウトHEADリクエストの

1. 過剰な数であることが判明しています。修正：これらを減らす

2. シーク時の接続を閉じて再開する。修正：（a）レイジーシーク（ シークはread（）であり、seek（）コールではない）、（b）前方にシークして のデータを読み込み、廃棄する。でも数百KB （メーリングリストへ、など）までの効率的なバイナリORC /寄せ木ファイルの場合

3. 、代わりに読み込み、ソースファイルの完全なGETをしようとしない特殊なfadvise =ランダムモード、 を追加ブロック内の 私たちが前向きにやりたい場合は、ブロックの残りの部分が破棄され、HTTP 1.1接続が再利用されます。接続を中止して新しいものを再交渉する必要はありません。 それはで（多分CDHいくつかの時間では、Hadoopの2.8）（今後、HDP 2.5（出荷）で）新しいものには触れませんが、Spark and Object Stores：

いくつかの詳細は、先月からこの話であります深さパフォーマンスにはさまざまな設定が推奨されますが、これは今日有効です。

また、使用する圧縮がsplittable（LZO、snappy、...）であること、ファイルのサイズが小さすぎてディレクトリの一覧を表示して開くことができないことを確認してください。