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;" 오류를 해결하려면 어떻게 해야 하나요?

최종 업데이트 날짜: 2021년 5월 4일

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 오류가 발생합니다. 이는 아테나가 GET/HEAD 요청을 사용하여 접두사에 있는 10,000개의 파일을 동시에 읽으려고 시도하지만 접두사는 초당 최대 5,500개의 GET/HEAD 요청만 지원할 수 있기 때문입니다. 이로 인해 S3 요청이 제한되어 503 Slow Down 오류가 발생할 수 있습니다.

다음 중 1가지 이상의 방법으로 요청 조절을 방지할 수 있습니다.

데이터를 파티셔닝하면 객체와 요청을 여러 접두사로 분산하는 데 도움이 될 수 있습니다. 단일 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 버킷에 100MB 크기의 파일이 1개 있는 경우 Athena는 파일을 읽기 위해 1개의 GET 요청을 해야 합니다. 그러나 크기가 각각 100KB인 파일이 1,000개 있는 경우 Athena는 동일한 100MB의 데이터를 읽기 위해 1,000개의 GET 요청을 해야 합니다. 이로 인해 요청이 S3 요청 제한을 초과하게 됩니다.

Amazon S3 요청 수를 줄이려면 파일 수를 줄입니다. 예를 들어, 크기가 작은(128MB 미만) 여러 개의 파일이 있는 경우 S3DistCp 도구를 사용하여 파일 크기가 큰 소수의 파일로 병합합니다. 자세한 내용은 Amazon Athena 성능 튜닝을 위한 10대 유용한 팁을 참조하고 4. 파일 크기 최적화 섹션을 검토하세요.

예:

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에서 Paquet 파일을 연결하려면 어떻게 해야 하나요?를 참조하세요.

버전이 활성화된 버킷에서 객체를 삭제하면 Amazon S3는 객체를 영구적으로 제거하는 대신 삭제 마커를 삽입합니다. S3 버킷에 삭제 마커가 있는 파일이 많이 있는 경우 이 오류가 발생할 수 있습니다. 버전 관리가 활성화된 버킷에서 쿼리를 실행할 때 Athena는 각 객체의 서로 다른 버전을 확인해야 합니다. 그런 다음 Athena는 쿼리 처리 중에 특정 개체를 포함할지 여부를 결정합니다.

이 오류를 해결하려면 S3 버킷에서 삭제 마커를 제거하는 것이 좋습니다. 다음 중 하나를 수행하여 삭제 마커를 제거할 수 있습니다.

• 삭제 마커 수동 삭제: ListObjectVersions API를 사용하여 S3 버킷의 모든 객체 버전에 대한 메타데이터를 나열합니다. 반환된 메타데이터에서 해당 객체의 versionID를 찾은 후 삭제 마커를 영구적으로 삭제합니다.
• 삭제 마커를 삭제하도록 수명 주기 구성 설정: S3 수명 주기 정책을 사용하여 객체의 수명 주기 동안 Amazon S3가 수행할 작업을 정의할 수 있습니다.

Amazon CloudWatch 5xxErrors 지표 및 S3 서버 액세스 로그를 사용하여 Hive on EMR, Spark, 또는 AWS Glue 등 다른 애플리케이션이 Athena 쿼리를 실행할 때 동일한 S3 접두사를 사용하는지 확인합니다. 여러 애플리케이션 동일한 S3 접두사로부터 데이터를 읽으려고 하는 경우 요청이 제한되고 Slow Down 오류와 함께 쿼리가 실패할 수 있습니다. 동일한 접두사에 동시에 액세스하는 애플리케이션을 예약하지 않도록 합니다. 또한 Athena 데이터 원본 및 애플리케이션 데이터 원본에 대해 서로 다른 S3 접두사를 사용합니다.

S3 버킷의 모든 객체에 대해 CloudWatch 지표 구성을 생성할 수 있습니다. 이러한 지표를 사용하여 특정 시점에 특정 접두사에 대한 API 호출 속도 지표를 모니터링할 수 있습니다. 접두사에 대해 S3 요청 지표를 활성화하면 특정 시점에 접두사에 대한 전반적인 API 적중률을 이해하는 데 도움이 될 수 있습니다. 이 정보를 S3 서버 액세스 로그와 함께 사용하여 해당 접두사에 대해 API 호출을 사용하고 있는 애플리케이션을 찾을 수 있습니다.