최근 빠르게 증가하는 데이터와 다변화된 데이터 소스에 따라 기존 S3 + Parquet 기반 DataLake의 구조만으로는 운영 효율성, 데이터 신뢰성에 한계가 있었습니다.
이글에서는 Apache Iceberg를 도입하게 된 배경과, 기존 환경에서 마주친 구체적인 문제들, Iceberg가 어떻게 해결 할 수 있을지를 기대하고 작성한 글입니다.
배경
왜 Iceberg를 도입하게 되었을까요?
-
스키마 변경에 어려움
-
데이터 거버넌스와 신뢰도 문제
-
작은 인력으로 대규모 데이터 소스를 다루는 운영상의 한계
Athena + Glue + S3의 데이터 분석 환경과 서비스 별로 bronze, silver, gold 계층 구조로 데이터를 수집/처리 하고 있습니다.
일단 가장 큰 이유는 스키마 변경이 가능하다는 점입니다.
-
300명이 넘는 규모에서 생산되는 데이터를 데이터 엔지니어1명과 데이터 사이언티스트1명이서 개발에서 만드는 데이터들을 컨트롤 하기에는 벅찼고, 거버넌스/모니터링을 통해 개선을 요청해도, 실제 서비스에 반영되기까지 6개월 이상 소요됐고, 그것도 일부 버전에만 적용되었습니다.
-
실제 서비스 담당 개발자들은 매번 작업 할 때 마다 칼럼을 생성하고 개발을 하여, 어떤 값을 신뢰할 수 있는지 버전 마다 다른 값이 사용되고 있었습니다.
-
그 예로 하나의 기능을 담당하는 칼럼이 16개고, 버전 마다 적용 조건도 달라 실제 기능 사용 여부를 아는데 너무 어려웠습니다.
문제 정의
DataLake 중에서 어떤 것을 골라야 할까요?
스키마 변경은 다른 후보도(Hudi, Delta Lake) 가능한데 Iceberg를 선택했을까요?
- 파티셔닝 된 Parquet에서 스키마 변경이 어렵고 변경 시 이전 날짜와 호환이 되지 않았습니다.
- 스키마의 버전 관리가 되지 않아, 당시에 어떤 스키마였는지 확인이 어려웠습니다.
- 서비스 별로 다른 스키마가 상이했고 칼럼 별로 신뢰도가 매우 적은 상태였습니다.
- Athena, Glue, Spark와의 통합성과 AWS에서 지원해주는지 여부
Iceberg를 선택한 이유입니다. Delta Lake는 databricks에서 사용가능하며, Hudi는 스키마 진화 AWS 연동 측면에서 어려움이 있었습니다.
- 스키마 진화로 버전 관리를 지원하며, 스키마를 변경할 수 있다.
- 파티셔닝 진화도 지원
- AWS 환경에서의 연동 측면에서 Iceberg가 전체 버전은 아니지만 버전2를 지원함으로써 사용이 가능하다.
Apache Iceberg란?
Apache Iceberg는 DataLake로 아래 기능을 도와줍니다.
- 자유로운 스키가 변경, 진화 가능
- Hidden Partitioning을 통한 유저 실수 방지
- 파티셔닝 진화 가능
- 필요에 따라 과거 데이터 확인
- 버전 롤백 가능
- 분산 처리 기능 없이 하나의 테이블에도 10PB까지 포함, Read 처리 가능
- Table Metadata로 Parition, Column 처리
결론
요약하자면, Iceberg는 스키마 진화, 파티셔닝 유연성, 메타데이터 기반 관리 등에서 기존 방식의 한계를 극복하게 해준 솔루션이었습니다.
다음 회차에서는 Iceberg의 동작 원리와 AWS 환경에 어떻게 도입했는지 공유 드릴 예정입니다.