Iceberg 에 대해 알아보자 | Architecture 및 도입 이유

목차 LIST

 

 

Iceberg의 등장 배경

HDFS에 Hive를 연동하여 사용하다 보면, 데이터가 수정/삭제되지 않아 불편한 상황이 발생할 수 있습니다.

HDFS는 파일 단위로 삭제가 가능하지만, 데이터는 수정이 불가능해 재적재해야 하는 상황이 종종 발생합니다. 이러한 문제를 해결하기 위해 Kudu와 같은 대안과 다양한 방법들이 제시되었습니다.

참고로, Kudu는 실시간 분석을 위한 스토리지 엔진으로 데이터 삽입, 업데이트, 삭제가 가능합니다.

Apache Iceberg는 이러한 방법들 중 하나로 Netflix에서 개발된 기술로, 이후 Apache 프로젝트로 오픈소스화 되었습니다. Iceberg는 대규모 데이터셋에서 효율적인 데이터 관리와 성능 유지를 목표로 하며, 데이터 수정 및 삭제 기능을 유연하게 제공합니다.

Iceberg Architecture?

 

들어가기 전에 간단히 정리하면, Iceberg는 메타데이터를 통해 매니패스트 파일을 조회함으로써 원하는 데이터 파일을 찾을 수 있습니다.

특정 파티션을 조건으로 검색할 경우, Iceberg는 매니패스트 리스트에서 해당 파티션 정보로 필터링을 수행하고, 필터링된 매니패스트 파일만을 조회하여 관련 데이터 파일을 가져옵니다.

https://iceberg.apache.org/spec/#goals

1. 개별 파일 관리

기존의 HDFS 방식은 데이터를 디렉토리 단위로 관리하는 반면, Iceberg는 개별 데이터 파일을 추적하여 관리합니다. 이로 인해 데이터를 더욱 세밀하게 관리할 수 있으며, 특정 파일만 업데이트하거나 추가되는 작업이 더 효율적으로 이루어집니다.

2. 명시적 커밋 시스템

Iceberg의 명시적 커밋(commit) 시스템을 통해 데이터 변경 사항이 테이블에 반영되기 전에 검토할 수 있습니다. 커밋이 완료된 이후에만 데이터가 테이블의 일부로 확정되므로, 데이터의 일관성과 안전성이 보장됩니다.

3. 메타데이터 파일 관리

테이블의 상태는 메타데이터 파일에 의해 관리되며, 이를 통해 스냅샷을 사용하여 특정 시점의 테이블 상태를 조회할 수 있습니다. 매니페스트 파일은 테이블에 포함된 데이터 파일들을 관리하고, 매니페스트 목록은 이를 최적화된 방식으로 추적하여 성능을 높입니다.

4. 스냅샷 파일

테이블 상태의 모든 변경은 새로운 메타데이터 파일을 생성하며, 이전 메타데이터는 원자적 교체(atomic swap) 방식으로 대체됩니다. 테이블 메타데이터 파일에는 테이블 스키마, 파티셔닝 설정, 사용자 정의 속성, 테이블 내용의 스냅샷이 포함됩니다. 스냅샷은 특정 시점에서 테이블의 상태를 나타내며, 테이블의 모든 데이터 파일 세트를 참조하는 데 사용됩니다. (스냅샷은 아래 이미지에서 s0, s1 로 표기되어 있음)

5. 매니페스트 파일

매니페스트 파일은 변경이 적은 메타데이터를 반복해서 작성하는 것을 방지하기 위해 여러 스냅샷 간에 재사용됩니다. 매니패스트 파일은 특정 파티션에 한정되지 않으며, 테이블의 여러 파티션에 걸친 데이터를 추적할 수 있습니다.

6. 데이터 파일

스냅샷 내의 데이터 파일은 테이블 내 각 데이터 파일에 대한 정보를 담고 있습니다. 여기에는 각 파일의 행, 파일이 속한 파티션 데이터, 그리고 해당 파일의 메트릭(예: 파일 크기, 레코드 수 등)이 포함됩니다. 이 데이터 파일들의 목록은 매니페스트 파일에 저장되어 관리됩니다.

 

 

CDC 시스템에 Iceberg를 도입한 이유?

 

널리 알려진 것처럼, CDC(Change Data Capture) 시스템은 주로 MySQL에서 MySQL로의 데이터 동기화에 사용됩니다. 하지만 이러한 구조에서는 다음과 같은 문제가 발생할 수 있습니다.

 

1. 타겟 MySQL 장비와 관련된 문제

MySQL은 확장성 측면에서 물리적인 한계가 있으며, 이를 확장하는데 많은 비용이 발생합니다.

 

Iceberg 를 사용하여 다음와 같이 해결할 수 있습니다.

Iceberg는 분산 파일 시스템과 같은 데이터 레이크 상에서 데이터를 관리하는 테이블 포맷을 제공합니다.

MySQL은 물리적인 한계로 무한 확장이 불가능하지만, Iceberg는 이러한 제약을 극복하여 대규모 데이터를 처리할 수 있습니다.

이는 Iceberg 자체 장점이라기보다는, Iceberg를 사용함으로써 HDFS, S3와 같은 분산처리 저장소를 활용할 수 있어 얻는 이점입니다.

 

 

2. 원천 MySQL에서 DDL(Data Definition Language)문이 빈번하게 발생하게 될 경우, 타겟 DB 연동 과정에서 부하 발생

 

MySQL에서 DDL 명령어가 자주 발생할 경우, 타겟 DB에 동기화하는 과정에서 부하가 발생하는 이유는 다음과 같습니다.

 

1) 락(Lock) 발생

• DDL 명령어는 테이블의 구조를 변경하는 작업으로 테이블에 락을 거는 경우가 많습니다. 이로 인해 동시 다발적인 읽기/쓰기 작업이 차단되거나 지연될 수 있으며 이로 인해 시스템의 성능이 저하될 수 있습니다.

2) 복제(Replication) 부하

• MySQL에서는 데이터베이스 간의 복제를 위해 바이너리 로그(Binary Log)를 사용합니다. DDL 명령어는 일반적인 DML(Data Manipulation Language) 명령어에 비해 생성되는 바이너리 로그의 크기나 내용이 크거나 복잡할 수 있으며, 이로 인해 복제 과정에서 부하가 발생할 수 있습니다.

3) 캐시 무효화(Cache Invalidation)

• DDL 명령어가 실행되면, MySQL 서버는 해당 테이블과 관련된 캐시를 무효화합니다. 이로 인해 캐시 효율성이 떨어지고 다음 쿼리 실행 시 더 많은 디스크 I/O가 발생하여 전체 시스템 성능이 저하될 수 있습니다.
• 참고로, 캐시 무효화와 캐시 삭제는 다른 개념입니다. 삭제는 캐시에 저장된 데이터를 완전히 제거하는 것을 의미하지만 무효화는 캐시에 저장된 데이터가 더 이상 유효하지 않다는 것을 표시하는 과정입니다.

이러한 이유로 인해 MySQL에서는 빈번한 DDL 명령어 실행이 시스템 부하를 증가시킵니다.

 

하지만 다음과 같은 Iceberg의 특징을 사용하여 문제를 해결할 수 있습니다.

• 독립적인 스키마와 파티션 관리:
  • Iceberg는 스키마와 파티션을 독립적으로 관리합니다. 즉, 데이터 파일과 메타데이터 파일이 분리되어 관리되며, 스키마 변경이 기존 데이터 파일에 직접적인 영향을 주지 않도록 설계되어 있습니다. MySQL과 같은 전통적인 DB에서는 DDL 명령어가 실행되면 즉시 테이블에 반영되고, 그 과정에서 테이블이 잠기거나 성능 저하가 발생할 수 있습니다. 하지만 Iceberg에서는 이러한 변경이 메타데이터 수준에서 이루어지고, 기존 데이터 파일은 그대로 유지되며, 새로운 구조가 다음 쓰기 작업에서 반영되도록 처리됩니다.
• 스키마 진화 지원:
  • Iceberg는 '스키마 진화' 기능을 지원합니다. 이는 새로운 스키마를 기존 데이터와 충돌 없이 추가하거나 변경할 수 있는 기능입니다. MySQL에서는 DDL 명령어로 테이블 구조를 변경하면 기존의 데이터와 충돌이 생길 수 있고, 성능에 영향을 미칠 수 있습니다. 반면, Iceberg에서는 스키마가 변경되더라도 기존 데이터는 그대로 유지되며, 새로운 데이터만 새로운 스키마에 따라 저장됩니다. 이 과정에서 기존 데이터에 대한 재처리나 수정이 필요 없기 때문에 시스템 부하가 크게 줄어듭니다.

 

 

References

https://developers-haven.tistory.com/50

https://iceberg.apache.org/spec/#goals