이 게시물은 Amazon Redshift 기반 단일 클러스터 데이터 웨어하우스의 한계를 해결하기 위해 Apache Iceberg로 컴퓨팅/스토리지를 분리한 데이터 레이크 아키텍처를 구축한 배경과 과정을 소개합니다.

기존 구조의 문제

• 전체 재적재→증분/머지로 개선해도 배치 시간 증가, 병렬 처리 확대로 워커 증설 필요
• 단일 클러스터 리소스 경합으로 배치·대시보드·분석 쿼리 간 간섭, 장시간 쿼리/Lock 대응 부담
• 확장 시 비용 급증 및 Spectrum은 성능 한계로 적용 확대 어려움

Iceberg 선택 이유와 멀티 엔진 가치

• 오픈 테이블 포맷으로 벤더 종속을 줄이고, 같은 데이터를 Spark/BigQuery/Flink/Athena 등 여러 엔진에서 공유
• 워크로드별로 Spark(쓰기·ETL), BigQuery(읽기·분석)처럼 역할 분담하고 엔진 교체/클라우드 이전의 선택지를 확보

GCP 기반 구성과 핵심 컴포넌트

• 데이터는 GCS에 Iceberg(Parquet)로 저장, 메타데이터는 BigLake Metastore에서 중앙 관리
• Iceberg 메타데이터(스냅샷/매니페스트/통계)로 필요한 파일만 읽어 성능·비용을 개선

도입 과정의 어려움과 제약

• BigLake/BigQuery Metastore 등 명칭 혼재로 문서 이해가 어려웠고, 지원 버전(1.5.2) 및 라이브러리 호환/인증·네트워크 설정이 난관
• BigQuery는 Read-Only(DML 불가), Parquet만 지원, 자동 최적화 미지원 등 제약이 있어 Spark 쓰기/최적화 + BigQuery 조회 전략으로 운영