파티션이 있는 테이블의 업데이트

Athena에서 테이블과 그 파티션은 동일한 데이터 형식을 사용해야 하지만 스키마는 다를 수 있습니다. 새 파티션을 만들면 파티션은 보통 테이블의 스키마를 상속합니다. 시간이 지남에 따라 스키마는 달라지기 시작할 수 있습니다. 이유는 다음과 같습니다.

• 테이블의 스키마가 변경되더라도 파티션의 스키마는 테이블의 스키마와 동기화 상태를 유지하도록 업데이트되지 않습니다.

• AWS Glue 크롤러를 사용하여 다른 스키마가 있는 파티션의 데이터를 검색할 수 있습니다. 즉 AWS Glue로 Athena에 테이블을 만든다면 크롤러가 처리를 마친 후 테이블과 그 파티션의 스키마가 다를 수 있습니다.

• AWS API를 사용하여 파티션을 직접 추가하는 경우

파티션이 있는 테이블이 다음 제약을 충족하면 Athena는 이를 처리합니다. 이러한 제약을 충족하지 않는다면 Athena는 HIVE_PARTITION_SCHEMA_MISMATCH 오류를 표시합니다.

• 각 파티션의 스키마가 테이블의 스키마와 호환됩니다.

• 테이블의 데이터 형식이 수행하려는 업데이트 유형(예: 열 추가, 삭제, 재정렬 또는 열의 데이터 형식 변경)을 허용합니다.

  예를 들어 CSV 및 TSV 형식의 경우 열 이름을 바꾸고, 테이블 끝에 새 열을 추가하고, 형식이 호환되는 경우 열의 데이터 형식을 변경할 수 있으나, 열을 제거할 수는 없습니다. 다른 형식의 경우 열을 추가 또는 제거하거나 형식이 호환되는 경우 열의 데이터 형식을 다른 형식으로 변경할 수 있습니다. 자세한 정보는 요약: Athena의 업데이트 및 데이터 형식을 참조하세요.

파티션이 있는 테이블의 스키마 불일치 오류 방지

쿼리 실행을 시작할 때 Athena는 각 열 데이터 형식이 테이블과 파티션 간에 호환되는지 확인하여 테이블의 스키마를 검증합니다.

• Parquet 및 ORC 데이터 스토리지 형식의 경우 Athena는 열 이름을 토대로 이를 열 이름 기반 스키마 검증에 사용합니다. 이렇게 하여 Parquet 및 ORC에 파티션이 있는 테이블의 HIVE_PARTITION_SCHEMA_MISMATCH 오류를 제거합니다. (SerDe 속성이 이름을 기준으로 인덱스에 액세스하도록 설정된 경우(orc.column.index.access=FALSE) 이 사항은 ORC에 해당됩니다. Parquet은 기본적으로 이름을 기준으로 인덱스를 읽습니다.)

• CSV, JSON 및 Avro의 경우 Athena는 인덱스 기반 스키마 검증을 사용합니다. 즉, 스키마 불일치 오류가 발생한다면 Athena가 실패하지 않고 쿼리할 수 있도록 스키마 불일치를 발생시키는 파티션을 삭제하고 다시 생성해야 합니다.

Athena는 테이블의 스키마를 파티션의 스키마와 비교합니다. AWS Glue 크롤러로 Athena의 CSV, JSON 및 AVRO에 테이블을 만들 경우 크롤러가 처리를 마친 후 테이블과 그 파티션의 스키마가 다를 수 있습니다. 테이블의 스키마와 파티션 스키마 간에 불일치가 있으면 다음과 유사한 스키마 검증 오류로 인해 Athena에서 쿼리가 실패합니다. 'crawler_test.click_avro'는 '문자열' 형식으로 선언되었는데, 'partition_0=2017-01-17' 파티션은 'col68'열을 'double' 형식으로 선언했습니다."

그러한 오류의 일반적인 해결 방법은 오류를 발생시키는 파티션을 삭제하고 다시 생성하는 것입니다. 자세한 내용은 ALTER TABLE DROP PARTITION 및 ALTER TABLE ADD PARTITION 단원을 참조하세요.