Athena の「HIVE_CANNOT_OPEN_SPLIT: Error opening Hive split s3://awsdoc-example-bucket/: Slow Down (Service: Amazon S3; Status Code: 503; Error Code: 503 Slow Down;」というエラーの解決方法を教えてください。

簡単な説明

Amazon Simple Storage Service (Amazon S3) バケットは、バケット内のプレフィックスごとに毎秒 3,500 の PUT/COPY/POST/DELETE または 5,500 のGET/HEAD リクエストを処理できます。これらのエラーは、このリクエストのしきい値を超えた場合に発生します。この制限は、アカウントのすべてのユーザーとサービスの合計です。

デフォルトでは、Amazon S3 は非常に高いリクエストレートをサポートするように自動的にスケーリングされます。リクエストレートがスケーリングされると、S3 バケットは自動的にパーティション分割され、より高いリクエストレートがサポートされます。ただし、リクエストのしきい値を超えると、処理を遅くするか、後で試すかを尋ねる 5xx エラーが表示されます。

例えば、プレフィックス s3://my-athena-bucket/month=jan/ でサポートできるのは、毎秒 3,500 の PUT/COPY/POST/DELETE リクエストまたは毎秒 5,500 の GET/HEAD リクエストです。このプレフィックス内に 10,000 個のファイルがあり、このプレフィックスで Athena クエリを実行すると、503 Slow Down エラーが発生します。これは、Athena が GET/HEAD リクエストを使用してプレフィックス上の 10,000 ファイルをすべて同時に読み込もうとするためです。ただし、プレフィックスでサポートできるのは 1 秒あたり 5,500 の GET/HEAD リクエストのみです。その結果、S3 リクエストがスロットルされ、503 スローダウンエラーが発生する可能性があります。

解決方法

以下のいずれかの方法を使用して、リクエストのスロットリングを防止します。

S3 オブジェクトとリクエストを複数のプレフィックスに分散します。

データをパーティション分割すると、オブジェクトとリクエストを複数のプレフィックスに分散できます。単一の S3 プレフィックスに多くのファイルを格納することは避けてください。これらのプレフィックス間で S3 オブジェクトを分散できるよう、複数のプレフィックスを使用することを検討してください。データをパーティション分割することで、各クエリでスキャンされるデータの量を減らすことができます。詳細については、「データのパーティション分割」を参照してください。

例えば、s3: //my-athena-bucket/my-athena-data-files にすべてのファイルを格納するのではなく 、データをパーティション分割し、次の個々のプレフィックスの下に格納します。

s3://my-athena-bucket/jan

s3://my-athena-bucket/feb

s3://my-athena-bucket/mar

これらのファイルのデータをさらに分割して、オブジェクトの分散を増やすことができます (例: s3://my-athena-bucket/jan/01)。

Athena パーティションフォルダ構造の決定の詳細について、 Amazon S3 のパフォーマンスのヒントとテクニックを参照してください。

各プレフィックスのファイル数を減らす

このエラーは、多数の小さなオブジェクトを持つ S3 バケットをクエリするときに発生することがあります。例えば、S3 バケットに 100 MB のファイルが 1 つある場合、Athena はファイルを読み取るために 1 つの GET リクエストを行う必要があります。ただし、それぞれ 100 KB のファイルが 1,000 個ある場合、Athena は、同じ 100 MB のデータを読み取るために 1,000 の GET 要求を行う必要があります。この場合、リクエストは S3 リクエスト制限を超過します。

Amazon S3 リクエストの数を減らすには、ファイル数を減らします。例えば、S3DistCp ツールを使用して、多数の小さなファイル (128 MB 未満) を少数の大きなファイルにマージします。詳細については、「Top 10 performance tuning tips for Amazon Athena」の「4.Optimize file sizes」を参照してください。

例:

s3-dist-cp --src=s3://my_athena_bucket_source/smallfiles/ --dest=s3://my_athena_bucket_target/largefiles/ --groupBy='.*(.csv)'

上記のコマンドで、次の項目を置き換えてください。

• my_athena_bucket_source に、小さなファイルが存在するソース S3 バケットを指定します。
• my_athena_bucket_target に、出力を格納する宛先 S3 バケットを指定します。

groupBy オプションを使用すると、サイズの大きい少数のファイルに多数の小さいファイルを集約できます。これでクエリのパフォーマンスとコストの両方を最適化できます。

注意: S3DistCp は Parquet ファイルの連結をサポートしていません。代わりに PySpark を使用します。詳細については、「Amazon EMR で Parquet 形式ファイルを連結するにはどうすればよいですか?」を参照してください。

S3 バケットでバージョニングが有効になっているかどうかを確認する

バージョニングが有効なバケットからオブジェクトを削除すると、Amazon S3 では、オブジェクトが完全に削除されるのではなく、削除マーカーが挿入されます。S3 バケットに削除マーカー付きのファイルが大量にある場合、このエラーが発生する可能性があります。バージョニングが有効なバケットでクエリを実行する場合、Athena は各オブジェクトの異なるバージョンをチェックする必要があります。次に、Athena は、クエリ処理中に特定のオブジェクトを含めるかどうかを決定します。

このエラーを解決するには、S3 バケットから削除マーカーを削除することを検討してください。次のいずれかの操作を行って、削除マーカーを削除できます。

• 削除マーカーをマニュアルで削除する: ListObjectVersions API を使用して、S3 バケット内のすべてのバージョンのオブジェクトに関するメタデータを一覧表示します。返されたメタデータでオブジェクトの versionID を検索し、完全に削除マーカーを削除します。
• 削除マーカーを削除するライフサイクル設定を構成します。S3 ライフサイクルポリシーを使用して、オブジェクトのライフタイム中に Amazon S3 で実行するアクションを定義できます。

他のアプリケーションが同じ S3 プレフィックスを使用しているかどうかを確認する

Amazon CloudWatch 5xxErrors メトリクスと S3 サーバーアクセスログを使用して、Athena クエリを実行したときに他のアプリケーション (Hive on EMR、Spark、または AWS Glue) が同じ S3 プレフィックスを使用しているかどうかを確認します。複数のアプリケーションが同じ S3 プレフィックスからデータを読み込もうとすると、リクエストがスロットルされ、クエリが Slow Down エラーで失敗する可能性があります。同じプレフィクスに複数のアプリケーションが同時にアクセスするようなスケジュールは避けてください。また、Athena データソースとアプリケーションデータソースには異なる S3 プレフィックスを使用します。

S3 バケット内のすべてのオブジェクトに対して CloudWatch メトリックス設定を作成できます。これらのメトリクスを使用して、特定の時点における特定のプレフィクスの API 呼び出しレートメトリクスを監視します。プレフィックスの S3 リクエストメトリクスを有効にすると、特定の時点におけるプレフィクスの全体的な API ヒット率を理解するのに役立ちます。この情報を S3 サーバーアクセスログと一緒に使用して、プレフィックスへの API 呼び出しを使用していたアプリケーションを見つけることができます。

---

関連情報

Amazon S3 バケットでスロットリングを回避するため、Amazon S3 リクエスト制限を緩和するにはどうすればよいですか?

Athena でのトラブルシューティング

Athena でのパフォーマンスチューニング