Read Original
#Backend

Hive에서 Iceberg로: 데이터 반영 속도 12배 향상의 비밀

Hive에서 Iceberg로: 데이터 반영 속도 12배 향상의 비밀
01

Summary

1시간 걸리던 데이터 반영을 5분으로, LINE의 Iceberg 도입기: 12배 속도 향상의 비밀

9억 건의 대규모 커머스 데이터를 실시간으로 동기화하는 Flink와 Iceberg의 환상적인 시너지

매번 수억 건의 데이터를 새로 쓰던 비효율적인 Hive ETL에서 벗어나, Apache Iceberg와 Flink를 통해 진정한 실시간 증분 처리 시스템을 구축한 기술적 여정을 다룹니다. 단순히 툴을 바꾸는 것에 그치지 않고, 대규모 트래픽 환경에서 발생하는 OOM, HDFS 병목, 데이터 정합성 이슈를 엔지니어링 관점에서 어떻게 해결했는지 상세한 트러블슈팅 사례를 공유합니다.

  • 01전체 덤프 방식의 한계를 극복하고 Iceberg 증분 적재로 데이터 반영 주기 12배 단축
  • 02Flink의 2단계 커밋(2PC)과 체크포인트를 결합해 '정확히 한 번' 처리하는 무결성 보장
  • 03ZSTD 압축 해제 시 발생하는 OOM 문제를 오프힙 메모리 재분배로 해결한 실전 인사이트
  • 04ID 기반 버킷 파티셔닝(Hidden Partitioning) 도입으로 대규모 테이블 읽기 성능 최적화
  • 05Flink Kubernetes Operator와 GitOps를 활용한 선언적 클러스터 운영 및 관리 효율화

RECOMMENDATION

대용량 배치 파이프라인의 지연 문제로 고민하는 데이터 엔지니어나, 데이터 레이크에서 실시간 CRUD 정합성을 확보하고 싶은 아키텍트에게 필독을 권장합니다. 특히 Spark Streaming의 배치 한계를 네이티브 스트리밍 엔진인 Flink로 돌파하려는 팀에게 매우 실무적인 가이드가 될 것입니다.

The Problem

기존 HBase 스냅숏과 Hive 기반 ETL 구조는 데이터 변경 시 수억 건의 전체 데이터를 매번 다시 써야 하는 Full Dump 방식이라 데이터 규모가 커질수록 반영 비용과 시간이 증가했다. 이로 인해 사내 하둡 리소스 부족 및 업데이트 지연이 발생하여 데이터의 최신성을 보장하기 어려운 한계가 있었다.

The Solution

Apache Iceberg 테이블 형식을 도입하여 행 단위 증분 업데이트 구조로 전환하고, Apache Flink의 네이티브 스트리밍 엔진과 2단계 커밋(2PC) 기반의 정확히 한 번(Exactly-once) 처리 메커니즘을 적용했다. 또한 HDFS I/O 병목을 해결하기 위해 ID 기반 버킷 파티셔닝 아키텍처를 도입하고 Flink Kubernetes Operator로 운영 환경을 구축했다.

The Result

데이터 반영 주기를 기존 60분에서 5분으로 약 12배 단축하였으며, 9억 건에 달하는 대규모 상품 데이터 환경에서도 데이터 정합성과 읽기 성능을 안정적으로 유지하는 데 성공했다. 특히 ID 기반 파티셔닝을 통해 대규모 데이터의 병합 및 최적화 작업 중 발생하던 HDFS 부하와 OOM 문제를 해결했다.

Trade-off

Spark Streaming 대비 높은 Flink의 운영 복잡도와 러닝 커브를 감수해야 했으며, 실시간 반영을 위해 MoR(Merge-on-Read) 방식을 채택함에 따라 주기적인 파일 최적화 작업과 HDFS I/O 자원 관리에 대한 지속적인 모니터링 비용이 발생하게 되었다.

03

Key Concepts

Concept · 01

Apache Iceberg

대규모 데이터셋을 위한 오픈소스 테이블 형식으로, 디렉터리가 아닌 메타데이터 기반 스냅숏 단위로 파일을 관리하여 증분 업데이트를 지원한다.

  • 전체 데이터를 다시 쓰지 않고 변경된 데이터만 행 단위로 Upsert/Delete 가능
  • 스냅숏 관리를 통해 데이터 일관성과 시간 여행(Time Travel) 기능 제공
Concept · 02

Exactly-Once (2PC)

분산 환경에서 데이터 중복이나 유실 없이 정확히 한 번만 처리됨을 보장하는 기술로, Flink는 이를 위해 2단계 커밋 프로토콜을 사용한다.

  • Iceberg 쓰기와 Kafka 메시지 발행이 모두 성공할 때만 최종 커밋되도록 연동
  • 장애 발생 시 체크포인트 지점부터 재시작하여 부분 성공 상태를 방지
Concept · 03

Merge-on-Read (MoR)

데이터 변경 시 원본 파일을 수정하는 대신 변경 내역(Delete file)만 별도로 기록하고, 읽기 시점에 이를 병합하여 보여주는 방식이다.

  • 스트리밍 환경에서 쓰기 지연을 최소화할 수 있으나 읽기 시 병합 연산 비용 발생
  • 과도하게 쌓인 삭제 파일 정리를 위해 rewrite_data_files와 같은 최적화 프로시저 주기적 실행 필요