[Snowflake <> AWS] Iceberg 테이블 연동성과 관련한 특이사항

• 해당내용은 2024-02-28 일자 기준으로 작성된 업데이트 기능사항 기준으로 작성된 문서임으로 AWS상의 기능 변경 및 Snowflake 의 기능변경으로 인하여 내용이 상이해질수 있습니다.

최근 스노우플레이크 ICEBERG TABLE 테스트를 하면서 알게된 내용들 정리해서 공유드립니다.

먼저 ICEBERG에 대한 간단한 소개를 드리자면 object storage(S3)에 아래의 4가지 기능을 통해서 보다 쉽고 간편하게 데이터를 관리할 수 있도록 설계된 오픈소스입니다.

• ACID (atomicity, consistency, isolation, durability) transactions
• Schema evolution
• Hidden partitioning
• Table snapshots

이외 에도 ICEBERG, Hudi, Delta Lake 같은 오픈소스들을 레이크하우스라고도 불러지고 있으며 각 레이크하우스(혹은 오픈테이블 포맷)에 대한 자세한 설명은 아래의 링크를 참고하시면 됩니다

AWS에서도 Glue, EMR, Redshit, Athena등 다양한 데이터 관련 서비스들에서 해당 오픈테이블 포맷 이용이 가능합니다.

따라서 이러한 방식으로 데이터를 관리하고 처리 및 보관하는 고객이 늘어남에 따라서 작년 Snowflake Seoul Summit 에서 해당 기능이 소개되었고 PrPr에서 PuPr 이 된 기능입니다.
아직은 Iceberg만 지원하고 있으며 차후 지원하는 테이블 포맷이 늘어날지는 지켜봐야 할 거 같습니다.

현재 Snowflake에서 지원하고 있는 ICEBERG의 테이블 형태는 크게 두 가지(Managed, Unmanaged) 가 있으며 세부적으로는 3가지가 있다고 보는 것이 맞습니다.

# Snowflake Iceberg Table Type

• Managed
  • iceberg table : 메타데이터 / 데이터 모두 snowflake에 맞게 저장하는 형태이며 일반적인 iceberg 오픈소스에 호환되는 형태는 아닙니다(ㅠㅠ) 해당 테이블을 생성할 경우 외부에서 해당 테이블을 활용할 수 있으나 AWS에서는 Athena에서는 지원이 안되고 Spark 베이스 서비스인 EMR에서 지원하는 것으로 확인됩니다.
    장점 : snowflake에서 사용하였을떄 속도가 일반적인 snowflake 테이블과 매우 유사하게 나옴, 일부 서비스에서 같이 활용가능, snowflake에서 update delete 쿼리등 데이터 변경가능, Refresh가 필요가 없음
    단점 : 오픈소스와 동일한 형태는 아니기에 사용하기 다소 어려운 부분이 있음
• Unmanaged
  • from Glue Catalog
    장점 : 오픈소스베이스와 거의 유사하기 때문에 대부분의 AWS 서비스와 연계성이 높음, 다소쉬운 Refresh 가능
    단점 : Snowflake에서 데이터에 대한 변경쿼리가 불가능
  • from ex-vol 
    장점 : 오픈소스베이스와 거의 유사하기 때문에 대부분의 AWS 서비스와 연계성이 높음, 
    단점 : Snowflake에서 데이터에 대한 변경쿼리가 불가능, 어려운 Refresh 가능(메타데이터 JSON)의 파일을 직접 타케팅 할 필요가 있습니다.

현재 출시된 기능이 다음과 같이 되어있다보니 Managed를 쓰기에는 기존에 EMR혹은 Spark를 활용하셨던 상황이 아니라면 사용이 어려울거 같다는 생각이 들었습니다.

따라서 Unmanaged가 일반적으로는 적합할 수 있으며(ETL을 Snowflake에서 안한다는 가정하에) Glue Catalog를 이용하는 편이 보다 편할것으로 예상됩니다.

Athena Iceberg DELETE Query에 관한 공식문서 설명

다만 최근에 테스트 하면서 알게 된 사실이지만  snowflake iceberg table은 iceberg v2의 MOR(Marge On Read) 기능인 row-level delete 기능을 지원하는 않는다는 것 이였습니다. 이것이 문제가 되는 이유는 위의 사진과 같이 Amazon Athena 에서는 기본적으로 Iceberg v2 형식의 테이블을 사용하며 Delete의 Query를 실행할때 신규기능을 사용하기 때문에 만약 아래와 같은 케이스일 경우 정상적으로 snowflake에서 사용하기가 어려운 부분이 있습니다.

 

Athena Create Table(DDL-Iceberg) > Snowflake Create Table(DDL-Iceberg) > Select(Worked)

Athena Create Table(DDL-Iceberg) > Snowflake Create Table(DDL-Iceberg) > Athena Insert Row (DML-Iceberg) >  Select(Worked)

Athena Create Table(DDL-Iceberg) > Snowflake Create Table(DDL-Iceberg) > Athena Update(or Delete) Row (DML-Iceberg) > Snowflake Refrash Table(DDL-Iceberg | Error) >  Select(Showing Old Data)

위의 케이스를 말로 풀어서 설명하자면 Athena에서 테이블을 만들고 Snowflake의 Unmanaged Iceberg Table을 만드는 것은 크게 문제가 없습니다. 다만 해당 테이블을 Athena에서 UPDATE 혹은 DELETE 쿼리를 날려서 변경을 했을경우 Snowflake에서는 아래와 같은 에러가 발생합니다.

snowflake snow-site 에서 Refrash 쿼리시 발생하는 에러 문구

 

이 에러는 실제로 snowflake docs에서 적혀있는 limitation 에 적혀있는 아래 문구에 있는 사항입니다.

(개인적인 생각으로는 iceberg v1의 기능을 fork 해서 개발했기 때문에 MOR기능을 모두 지원하지 못하는게 아닐까 합니다만..)

snowflake tables iceberg - limitations

 

해당 문제는 오픈소스iceberg와 정확하게 동일한 기능 및 버전이 snowflake에서 지원이 안되는 것으로 보여서 방법은 결국 Glue or EMR 같은 Spark를 사용하는 서비스를 기준으로 테이블 버전을 1v 혹은 2v으로 만들어서 사용해야합니다(Spark의 경우 기본적으로 COW를 사용합니다)

# 관련자료
https://docs.snowflake.com/en/user-guide/tables-iceberg - snowflake iceberg tables
https://aws.amazon.com/ko/blogs/big-data/choosing-an-open-table-format-for-your-transactional-data-lake-on-aws/ - 오픈 테이블 포맷을 어떻게 선정하면되나요?

Updating Iceberg table data - Amazon Athena - Athena Iceberg table에서 쿼리를 사용하는 방법