"HIVE_CANNOT_OPEN_SPLIT" Athena 쿼리 오류를 해결하려면 어떻게 해야 하나요?

간략한 설명

---

Amazon Simple Storage Service(Amazon S3) 버킷은 버킷의 접두사당 초당 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개의 파일을 모두 읽으려고 시도했습니다. 그러나 접두사는 초당 최대 5,500개의 GET/HEAD 요청만 지원하기 때문에 S3 요청이 제한되고 "5xx Slow Down" 오류가 발생합니다.

해결 방법

요청이 제한되지 않도록 다음 방법 중 하나 이상을 사용합니다.

S3 객체 및 요청을 여러 접두사에 분산합니다.

객체와 요청을 여러 접두사에 분산하는 데 도움이 되도록 데이터를 분할합니다. 단일 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 버킷에 100MB 파일이 하나 있는 경우 Athena는 파일을 읽기 위해 한 번의 GET 요청을 해야 합니다. 그러나 각각 100KB인 파일 1,000개의 경우 Athena는 동일한 100MB의 데이터를 읽기 위해 1,000개의 GET 요청을 해야 합니다. 그런 다음 요청은 S3 요청 제한을 초과합니다.

Amazon S3 요청 수를 줄이려면 파일 수를 줄입니다. 예를 들어, S3DistCp 도구를 사용하여 128MB 미만의 많은 수의 작은 파일을 더 적은 수의 큰 파일로 병합할 수 있습니다. 자세한 내용은 Amazon Athena를 위한 상위 10가지 성능 튜닝 팁의 파일 크기 최적화 섹션을 참조하세요.

명령 예시:

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는 객체를 영구적으로 제거하지 않습니다. 대신 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 직접 호출을 사용한 애플리케이션을 찾습니다.

단일 파티션 내에서 데이터를 분할하려면 데이터를 버킷으로 만들 수도 있습니다. 자세한 내용은 버킷팅이란 무엇인가요?를 참조하세요.

관련 정보

Amazon S3에서 발생하는 HTTP 500 또는 503 오류 문제를 해결하려면 어떻게 해야 하나요?

Athena에서의 문제 해결

Athena의 성능 튜닝