Apache Iceberg 간략 정리 하기

Apache Iceberg 공식 로고

• Apache iceberg는 방대한 분석 데이터 세트를 위한 오픈 테이블 포맷
• SQL 테이블처럼 작동하는 고성능 테이블 포맷 사용
• Spark, Trino, PrestoDB, Flink, Impala를 포함한 컴퓨팅 엔진에 테이블을 추가

주요 특징

• 스키마 진화(Schema Evolution)
  • 추가, 삭제, 업데이트 또는 이름 바꾸기를 지원 → 테이블의 스키마를 유연하게 변경
  • Hive와의 차이
    • Hive에서 스키마 변경은 제한적
    • Hive는 새로운 컬럼 추가는 가능 기존 컬럼의 삭제나 데이터 타입 변경은 어려움
• 숨겨진 파티셔닝(Hidden Partitioning)
  • 파티션 관리 방식을 단순화하여 실수로 인한 잘못된 결과나 성능 저하를 방지 → 복잡한 쿼리에서도 잘못된 파티셔닝 회피
  • Hive와의 차이
    • Hive에서도는 파티셔닝을 사용자가 명시적으로 관리 → 잘못된 파티션키 지정시 비효율적인 쿼리나 잘못된 결과 발생 가능
• 파티션 레이아웃 진화(Partition Layout Evolution)
  • 데이터의 양이나 쿼리 패턴이 변화함에 따라 파티션 레이아웃을 업데이트 할 수 있음→ 쿼리 성능을 최적화하고 데이터 저장 효율성 향상
  • Hive와의 차이
    • Hive는 파티션 레이아웃을 변경하여면 테이블 새로 만들거나 기존 테이블을 수정
    • Hive는 파티션을 추가할 수 있지만, 기존 파티션 구조를 변경하거나 재구성하는 것은 어려움
• 시간 여행(Time Travel)
  • 데이터 변경 이력을 쉽게 탐색할 수 있으며, 특정 시점의 데이터 상태를 확인 가능
  • Hive와의 차이
    • Hive는 기본적으로 시간여행 기능을 제공하지 않음
• 버전 롤백 (Version Rollback)
  • 테이블을 이전의 안정적인 상태로 신속하게 되돌릴 수 있는 기능
  • Hive와의 차이
    • Hive는 기본적으로 버전 롤백 기능이 없음

Iceberg의 구조

iceberg architecture

• Catalog Layer
  • catalog는 특정 데이터 소스에 접근을 가능하게 만들어주는 설정
  • 현시점의 테이블 metadata를 찾을 수 있게 도와줌
  • 쿼리 실행시 해당 쿼리가 찾는 metadata file을 찾기 위해 사용
• Metadata Layer
  • metadata file
    • 스키마, 파티션, 스냇샷에 대한 정보를 저장
    • 테이블 형상은 metadata file로 관리
    • 테이블 내용에 변경이 생기면 새로운 metadata file이 생성되어 기존 것을 대체
    • 스냅샷 기능을 통해 특정 시점의 테이블 형상을 파일로 기록
  • manifest list
    • 스냅샷은 하나의 manifest list를 참조, manifest list는 하나 이상의 manifest file에 대한 메타 정보 저장
    • manifest list를 통해 스냅샷과 연관된 manifest file 위치를 찾아내는 것
  • manifest file
    • 스냅샷은 하나 이상의 manifest file로 이루어짐
    • manifest file은 data file에 대한 모든 정보( data file의 위치, 파티션 정보)와 통계 정보(null, nan 개수)를 저장
• Data Layer
  • 실제 데이터를 저장하는 곳
  • manifest file의 메타 정보를 이용하여 필요한 데이터 파일에 접근
• Iceberg의 데이터 접근 방식
  •  metadata → manifest list → manifest file → data file
  • 특정 파티션 값의 데이터 조회시
    • manifest list의 파티션 정보로 필터링 → 필터링된 manifest file을 거쳐 데이터 파일 로드
    • 이러한 점을 통해 더 빠르게 데이터 조회 가능

Iceberg 데이터 쓰기 과정

1. Data Files
   • 먼저 새로운 데이터 파일이 생성
   • Parquet, ORC, Avro 같은 포맷으로 저장
2. Manifest Files
   • 데이터 파일 생성 이후 Iceberg는 메타데이터를 담는 매니페스트 파일 생성
   • 데이터 파일의 위치, 크기, 파티션 정보, 파일의 스키마 등 다양한 정보 저장
3. Manifest List
   • 모든 매니페스트 파일이 생성된 후, 매니페스트 리스트 파일을 업데이트
   • 현재 테이블에서 사용 중인 모든 매니페스트 파일의 목록
4. Metadata File
   • 모든 쓰기 작업 완료 후 메타데이터 파일 업데이트
   • 메타데이터 파일의 업데이트가 완료되면 새로운 스냅샷을 생성하여 현재의 테이블 상태를 기록 → 시간 여행 및 버전 관리 가능

Iceberg 데이터 삭제 과정

• 실제 데이터를 물리적으로 삭제하지 않고 논리적으로 삭제하는 방식으로 처리

1.  Data Files
   • 데이터 삭제가 요청되면, 삭제할 데이터가 포함된 데이터 파일 식별
   • 삭제할 조건(예: 특정 파티션 또는 조건) 기준
2. Manifest Files
   • 삭제할 데이터 파일에 대한 정보를 포함하는 매니페스트 파일 업데이트
   • 기존 매니페스트 파일에서 삭제할 데이터에 대한 참조를 제거
   • 삭제된 데이터를 나타내는 새로운 매니페스트 파일을 생성
3. Manifest List
   • 삭제가 발생한 후, 매니페스트 리스트 파일이 업데이트
   • 매니페스트 파일과 새로운 삭제 마커 매니페스트 파일이 포함되도록 조정
4. Metadata File
   • 메타데이터 파일을 업데이트하여 삭제 작업의 결과를 반영
   • 메타데이터 업데이트가 완료되면 새로운 스냅샷을 생성되어 현재 테이블 상태를 기록 → 시간 여행 및 버전 관리 가능

정리

많은 빅데이터를 운영하는 회사들이 hive를 통한 빅데이터 테이블에서 iceberg 테이블로 마이그레이션하여 사용하고 있다.

공부하기 전에는 메타데이터를 RDBMS로 관리하는 hive가 파일 형태로 관리하는 iceberg보다 더욱 빨라야할 것 같다고 나는 생각했다.

 

그러나, 데이터의 양이 계속해서 방대해짐에 따라서, hive 환경에서는  많은 문제에 직면하게 된다는 것을 알 수 있었다.

 

hive는 스키마 변경, 이전 데이터 롤백이 매우 제한적이며, 많은 데이터로 인하여 hive metastore는 많은 메모리 문제를 유발과 잘못된 파티셔닝으로 인한 부하로 프로세스 중단이 쉽게 발생할 수 있다.

 

그렇기에 iceberg는 메타데이터 파일로 메타데이터를 관리하지만, 페타바이트 이상의 규모에서는 파일 접근 I/O 비용이 발생하더라도 metadata, mainfest 파일들을 사용하여 최적화된 데이터 조회가 가능하게 만들었고 주기적으로 최적화하여 데이터양이 방대해지더라도 성능을 최대한 유지할 수 있게됨을 알 수 있었다.