「HIVE_CANNOT_OPEN_SPLIT」という Athena のクエリに関するエラーを解決する方法を教えてください。

簡単な説明

Amazon Simple Storage Service (Amazon S3) バケットがサポートできるのは、バケット内のプレフィックスごとに 1 秒あたり 3,500 件の PUT/COPY/POST/DELETE リクエスト、または 5,500 件の GET/HEAD リクエストのみです。このハードリミットは、AWS アカウントのすべてのユーザーとサービスに適用されます。

デフォルトでは、Amazon S3 は高いリクエストレートをサポートするように自動的にスケーリングします。リクエストレートが高くなると、S3 バケットはより高いリクエストレートをサポートするように自動的にパーティション化されます。ただし、リクエストのしきい値を超えると、「5xx Slow Down」エラーが表示されます。

例えば、内部に 10,000 個のファイルがあるプレフィックスで Athena のクエリを実行するとします。Athena は GET/HEAD リクエストを使用して、10,000 個のファイルすべてを同時に読み取ろうとします。ところが、プレフィックスは 1 秒あたり最大 5,500 件の GET/HEAD リクエストしかサポートしないため、S3 リクエストがスロットリングされて「5xx Slow Down」エラーが発生します。

解決策

リクエストがスロットリングされないように、次の 1 つまたは複数の操作を実行します。

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

オブジェクトとリクエストを複数のプレフィックスに分散しやすくするために、データをパーティション化します。1 つの S3 プレフィックスの下に多数のファイルを保存しないでください。代わりに、複数のプレフィックスを使用して、これらのプレフィックス全体に S3 オブジェクトを分散します。詳細については、「Athena でのデータのパーティション化 」を参照してください。

例えば、すべてのファイルを 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 などのオブジェクトをさらに分散させることができます。

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

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

Amazon S3 リクエストの数を減らすには、ファイルの数を減らします。例えば、S3DistCp ツールを使用すると、128 MB 未満の多数の小さなファイルを、少数の大きなファイルにマージできます。詳細については、「Top 10 performance tuning tips for Amazon Athena 」の「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 は Apache Parquet ファイルの連結をサポートしていません。代わりに PySpark を使用してください。詳細については、「Amazon EMR で Parquet ファイルを連結する方法を教えてください」を参照してください。

S3 バケットのバージョニングが有効になっていることを確認する

バージョニングを使用する S3 バケットからオブジェクトを削除しても、Amazon S3 ではそのオブジェクトが完全に削除されず、代わりに削除マーカーが挿入されます。S3 バケット内の多くのファイルに削除マーカーがある場合は、「HIVE_CANNOT_OPEN_SPLIT」エラーが表示されることがあります。バージョニングが有効になっているバケットでクエリを実行すると、Athena は各オブジェクトの異なるバージョンを確認する必要があります。クエリが処理されると、特定のオブジェクトを含めるかどうかが Athena によって決定されます。

この問題を解決するには、S3 バケットから削除マーカーを削除します。削除マーカーを削除するには、次のいずれかの操作を行います。

• 削除マーカーを手動で削除します。ListObjectVersions API を使用して、S3 バケット内のオブジェクトのすべてのバージョンに関するメタデータを一覧表示します。メタデータからオブジェクトの versionID を検索し、削除マーカーを完全に削除します。
• 削除マーカーを削除するようにライフサイクル設定を指定します。S3 ライフサイクルルールを使用して、オブジェクトの存続中にAmazon S3 が実行するアクションを定義します。

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

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

S3 バケットのすべてのオブジェクトの CloudWatch メトリクス設定を作成します。これらのメトリクスを使用して、特定の時点における特定のプレフィックスの API コールレートメトリクスをモニタリングします。プレフィックスの S3 リクエストメトリクスを有効にすると、特定の時点におけるプレフィックスの API コールの全体的なレートを把握できます。この情報を S3 サーバーアクセスログと一緒に使用して、プレフィックスの API コールを使用したアプリケーションを見つけてください。

データを 1 つのパーティションに分割する場合は、データをバケット化することもできます。詳細については、「バケット化とは」を参照してください。

関連情報

Amazon S3 の HTTP 500 エラーまたは 503 エラーをトラブルシューティングする方法を教えてください。

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

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