S3 整合性モデルと Hadoop/Spark の話

S3 整合性モデルと Hadoop/Spark の話

• 1.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Noritaka Sekiyama Senior Cloud Support Engineer, Amazon Web Services Japan 2019.05.23 S3 整合性モデルと Hadoop/Spark の話
• 2.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 関山 宜孝 (Noritaka Sekiyama) Senior Cloud Support Engineer - AWS サポートの中の人 - 専門は Big Data (EMR, Glue, Athena, …) - AWS Glue の専門家 - Apache Spark 好き Who I am... @moomindani
• 3.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 今日話すこと • S3 整合性モデルの話 • Hadoop/Spark と S3 整合性モデルの関係と緩和方法 （Hadoop/Spark を使ったことのない方、あまり興味のない方にも、 ミドルウェアから S3 を活用する工夫の一例としてお聞きいただければ） 今日話さないこと • Hadoop/Spark の仕組み、最新動向 アジェンダ
• 4.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. オブジェクトストレージサービス • 高いスケーラビリティ、可用性、耐障害性 (99.999999999%)、セ キュリティ、およびパフォーマンスを提供 • 単一オブジェクトの最大サイズ： 5TB • オブジェクトはバケット配下のユニークなキー名で管理される • ディレクトリは S3 コンソール上では疑似的に表現されるが、実態としては存 在しない • ファイルシステムではない 従量課金 • 主に、保管されたデータサイズと、リクエストに対して課金 Amazon S3
• 5.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 新規オブジェクトの PUT: 書き込み後の読み込み整合性 存在しないオブジェクトの HEAD/GET: 結果整合性 PUT および DELETE の上書き: 結果整合性 オブジェクトの LIST: 結果整合性 https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel S3 整合性モデル
• 6.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 書き込み後の読み込み整合性 • PUT したオブジェクトを直後に GET すると一貫した結果が得られる • 結果整合性ではない 新規オブジェクトの PUT 1. PUT s3://middwaredeeptalks/path_to_objectA.txt 2. GET s3://middwaredeeptalks/path_to_objectA.txt
• 7.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 結果整合性 • PUT 前のオブジェクトを存在確認のために HEAD/GET して、 その後にオブジェクトを PUT して GET すると結果整合性となる 存在しないオブジェクトの HEAD/GET 1. HEAD or GET s3://middwaredeeptalks/path_to_objectB.txt 2. PUT s3://middwaredeeptalks/path_to_objectB.txt 3. GET s3://middwaredeeptalks/path_to_objectB.txt
• 8.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 結果整合性 • 既存オブジェクトを PUT して GET すると古いデータが返却される場 合がある • 既存オブジェクトを DELETE して GET すると削除済データが返却さ れる場合がある PUT および DELETE の上書き 1. PUT/DELETE s3://middwaredeeptalks/path_to_objectC.txt 2. GET s3://middwaredeeptalks/path_to_objectC.txt
• 9.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 結果整合性 • 新規オブジェクトを PUT して直後に LIST すると、追加されたオブ ジェクトがリストに含まれない場合がある • 既存オブジェクトを DELETE して直後に LIST すると、削除済のオブ ジェクトがリストに含まれる場合がある 特に LIST 結果整合性は、Hadoop/Spark に影響が大きい オブジェクトの LIST 1. PUT s3://middwaredeeptalks/path_to_objectD.txt 2. LIST s3://middwaredeeptalks/
• 10.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 入力データの取得 • 引数にとった S3 の任意のパスのデータを分散処理のために取得 1. 対象のパスを LIST 2. LIST で返却されたキーに対して HEAD (存在確認) 3. LIST で返却されたキーに対して GET (オブジェクト取得) • 複数のジョブを多段で構成してパイプラインを組む場合、前段の ジョブの出力を後段のジョブの入力に使用することになる ⎼ 例：複数ステップの ETL データ処理パイプライン – ステップ1: 入力の生データを整形、フォーマット変換 – ステップ2: 変換後のデータを入力として統計処理 Hadoop/Spark から S3 へのよくある操作その1
• 11.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 中間データの最終出力先への移動 • 中間出力先にデータを一時的に書きこみ、その後で対象のパスの データを LIST して最終出力先に MV/RENAME ⎼ 中途半端な状態のデータを見えなくするため • S3 には MV/RENAME の概念がないため、以下の手続きが必要 1. 中間出力先のパスを LIST 2. LIST で返却されたキーから最終出力先のキーへ COPY (オブ ジェクトコピー) 3. LIST で返却されたキーに対して DELETE (元オブジェクト削 除) （HDFS の MV/RENAME は非常に高速だが、S3 では時間がかかる） Hadoop/Spark から S3 へのよくある操作その2
• 12.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. S3 Guard (S3A), EMRFS Consistent view (EMRFS) • S3 の整合性 (特に LIST 整合性) をチェックする仕組み • S3 オブジェクトのメタデータ管理に DynamoDB を使用 • S3 と DynamoDB が返却する結果を突合して最新のビューを提供 https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-consistent-view.html Hadoop/Spark における S3 整合性の影響緩和 Cluster S3 HDFS App Temp data DynamoDB Object PUT/GET Metadata PUT/GET
• 13.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. S3A Committer, EMRFS S3-optimized committer • S3 マルチパートアップロードの仕組みを活用 • ジョブ/タスクコミットフェーズ中に S3 への LIST/RENAME オペレー ションを回避し、アプリケーションのパフォーマンスを向上 • ジョブ/タスクコミットフェーズで S3 結果整合性による問題を回避し、 タスク失敗時のジョブの正確性を向上 ⎼ 中間出力先にデータを一時的に書きこむ代わりに、マルチパートアップロードを開始 （この時点ではファイルは見えない） ⎼ 書き込みが完了したら MV/RENAME する代わりに、マルチパートアップロードを終了 （LIST してコピーとかしなくていい） https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-s3-optimized-committer.html https://aws.amazon.com/blogs/big-data/improve-apache-spark-write-performance-on-apache-parquet-formats-with-the-emrfs-s3-optimized- committer/ Hadoop/Spark における S3 整合性の影響緩和
• 14.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. マルチパートアップロードの開始 • 開始リクエストを送信してアップロードIDを取得 各パートのアップロード • アップロードIDとパート番号を添えてアップロード • 明示的に完了/中止しないとパートは残存し、ストレージ課金が継続 マルチパートアップロードの完了/中止 • パート番号に基づいて昇順に連結したオブジェクトを S3 上に生成 • 個々のパートは解放され、ストレージも解放される 参考：マルチパートアップロードの流れ マルチパート アップロード の開始 各パートの アップロード マルチパート アップロード の完了/中止
• 15.
  © 2019, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. パフォーマンス比較 • EMR 5.19.0 (マスター m5d.2xlarge / コア m5d.2xlarge x 8台) • 入力データ: 15 GB (100 Parquet ファイル) 参考: EMRFS S3-optimized committer の性能 EMRFS consistent view 無効 EMRFS consistent view 有効 INSERT OVERWRITE DIRECTORY ‘s3://${bucket}/perf-test/${trial_id}’ USING PARQUET SELECT * FROM range(0, ${rows}, 1, ${partitions});