오픈 테이블 포맷 설명: Iceberg vs. Delta vs. Hudi

오픈 테이블 포맷은 오브젝트 스토리지의 데이터 파일 상위에 위치하는 메타데이터 레이어로, 데이터 레이크에 저장된 데이터에 ACID 트랜잭션, 스키마 진화(schema evolution), 타임 트래블 기능을 추가합니다. Apache Iceberg, Delta Lake, Apache Hudi는 오늘날 프로덕션 환경에서 사용되는 세 가지 주요 오픈 테이블 포맷이며, 각각 Parquet 또는 ORC 파일 모음을 데이터베이스처럼 작동하는 테이블로 변환합니다. 읽기 작업자는 일관된 결과를 보고, 쓰기 작업자는 행을 안전하게 업데이트 및 삭제할 수 있으며, 모든 변경 사항이 추적되므로 이전 버전을 계속 쿼리할 수 있습니다.

이 개요에서는 주요 오픈 테이블 포맷의 작동 방식, ACID 트랜잭션 지원 및 스키마 진화 측면에서의 비교, 그리고 데이터 레이크하우스 아키텍처와의 관계를 설명합니다. 카탈로그 조정 트랜잭션, 행 계보(row lineage), 통합 메타데이터와 같은 스토리지 레이어의 혁신을 활용하여 Delta Lake와 Apache Iceberg가 어떻게 융합되고 있는지 보여줍니다.

데이터 레이크란 무엇이며, 오픈 테이블 포맷이 왜 중요할까요?

데이터 레이크는 저비용 오브젝트 스토리지(Amazon S3, Azure Data Lake Storage 또는 Google Cloud Storage)를 기반으로 구축된 중앙 집중식 저장소로, 정형, 반정형, 비정형 데이터를 원시 형태 그대로 보관합니다. 기업들이 데이터 레이크를 도입한 이유는 오브젝트 스토리지가 저렴하게 확장되고 스토리지와 컴퓨팅을 분리하여 모든 쿼리 엔진이 동일한 데이터를 읽을 수 있도록 지원하기 때문입니다. 하지만 오브젝트 스토리지는 일관성을 보장하도록 설계되지 않았습니다. 테이블, 스키마 또는 트랜잭션이라는 고유한 개념이 없습니다.

데이터 레이크하우스는 이러한 원시 스토리지 위에 테이블과 유사한 구조, 거버넌스, 성능을 계층화하여 데이터 레이크의 저렴한 비용과 데이터 웨어하우스의 신뢰성을 결합합니다. 이 둘을 연결하는 교량 역할을 하는 것이 바로 오픈 테이블 포맷입니다. 데이터를 독점 웨어하우스로 복사하지 않고도 오브젝트 스토리지의 개별 파일들을 관리되고 쿼리 가능한 테이블로 변환합니다.

오픈 테이블 포맷이 존재하기 전에는 기존 데이터 레이크에서 분석을 실행할 때 지속적인 문제가 발생했습니다. 동시에 여러 작업자가 데이터를 쓰는 과정에서 데이터가 손상될 수 있었고, 업데이트와 삭제를 하려면 파티션 전체를 다시 작성해야 했으며, 어떤 파일이 테이블의 현재 정확한 상태를 나타내는지 신뢰할 수 있는 방법이 없었습니다. 오픈 테이블 포맷은 오브젝트 스토리지의 데이터 파일에 대한 메타데이터를 관리하여 어떤 파일이 테이블에 속하는지 정확히 추적합니다. 이러한 표준화 덕분에 데이터 레이크는 마침내 레코드 수준의 업데이트와 같은 데이터베이스 유사 기능을 지원할 수 있게 되었습니다.

알아야 할 오픈 테이블 포맷 및 파일 포맷

Apache Iceberg

원래 Netflix에서 개발되어 현재는 Apache Software Foundation 프로젝트가 된 Apache Iceberg는 느리게 변경되는 거대한 테이블을 빠르게 쿼리하고 안전하게 진화시킬 수 있도록 설계되었습니다. Apache Iceberg는 효율적인 메타데이터 관리를 위해 트리 구조를 사용합니다. 매니페스트 파일과 매니페스트 목록이 테이블의 모든 데이터 파일을 추적하므로, 쿼리 엔진은 스캔을 시작하기 전에 관련 없는 데이터를 정리(pruning)할 수 있습니다. Iceberg 테이블은 기본 파일을 다시 작성하지 않고도 스키마 진화 및 파티션 진화를 지원합니다.

Delta Lake

Databricks가 개발하고 오픈 소스로 출시한 Delta Lake는 write-ahead 트랜잭션 로그를 통해 Apache Spark 워크로드에 ACID 트랜잭션을 도입했습니다. Delta Lake는 Databricks에서 시작되어 Spark와 기본적으로 통합되지만, 현재는 독립적인 커넥터를 통해 광범위한 엔진을 지원합니다. Delta Lake 테이블은 모든 쓰기 작업을 순서가 지정된 원자성 로그 항목으로 기록하므로, 새로운 데이터가 작성되는 중에도 읽기 작업자에게 일관된 뷰를 제공합니다.

Apache Hudi

Hadoop Upserts Deletes and Incrementals의 약자인 Apache Hudi는 빠르고 빈번한 레코드 수준 업데이트를 중심으로 구축되었습니다. Apache Hudi는 특정 레코드가 포함된 정확한 파일의 위치를 찾는 인덱스를 유지함으로써 빈번한 업데이트와 스트리밍 데이터에 최적화되어 있으며, 전체 테이블 스캔 없이도 효율적인 레코드 수준 업데이트를 가능하게 합니다. 이러한 설계 덕분에 Hudi는 변경 데이터 캡처(CDC) 파이프라인 및 실시간에 가까운 수집(ingestion)에 자주 선택됩니다.

Parquet 및 ORC

Parquet와 ORC는 테이블 포맷이 아닌 열 지향(columnar) 파일 포맷입니다. 이들은 파일이 어떻게 관리되는 테이블이 되는지가 아니라 개별 데이터 파일이 어떻게 구성되는지를 정의합니다. Iceberg, Delta Lake, Hudi는 모두 Parquet 파일을 기반으로 구축되었으며(Iceberg와 Hudi는 ORC도 지원), 쿼리 엔진이 데이터를 읽기 전에 Parquet가 저장하는 파일 수준 통계를 사용하여 데이터를 정리합니다. 파일 포맷과 테이블 포맷의 이러한 구분은 각 레이어의 책임이 어디서부터 시작되는지에 대한 기업들의 혼란을 대부분 해결해 줍니다.

Iceberg vs. Delta Lake vs. Hudi: 빠른 비교

세 가지 주요 오픈 테이블 포맷은 이제 차이점보다 더 많은 기능을 공유하고 있지만, 아래 표는 설계 역사가 여전히 드러나는 부분을 강조하여 보여줍니다.

Apache Iceberg 내부 구조: 테이블 및 메타데이터

Iceberg 메타데이터 트리

Iceberg 테이블은 단일 파일이 아니라 메타데이터 트리에 의해 정의됩니다. 메타데이터 파일은 매니페스트 목록을 가리키고, 매니페스트 목록은 스냅샷을 구성하는 실제 데이터 파일을 나열하는 매니페스트 파일을 가리킵니다. 이러한 계층적 구조 덕분에 쿼리 엔진은 단 하나의 파일도 열지 않고 저장된 열 통계를 사용하여 관련 없는 매니페스트와 데이터 파일을 정리할 수 있으므로, 수백만 개의 파일이 있는 테이블에서 쿼리 성능이 향상됩니다.

스냅샷 및 타임 트래블

Iceberg 테이블에 쓸 때마다 해당 시점에 존재했던 데이터 파일의 불변 기록인 새로운 스냅샷이 생성되며, 메타데이터 트리는 이전 스냅샷의 이력을 유지합니다. 이를 통해 타임 트래블이 가능해집니다. 엔진은 특정 스냅샷 ID 또는 타임스탬시점에 존재했던 테이블을 쿼리할 수 있어 감사, 재현 가능한 ML 트레이닝 세트, 잘못된 쓰기 작업 후 마지막 안정 상태로의 롤백을 지원합니다.

파티션 진화

Iceberg는 파티션 진화를 통해 테이블의 물리적 파티셔닝을 쿼리 패턴과 분리하므로, 팀은 기존 파일을 다시 작성하거나 이전 스키마에 대한 쿼리를 중단하지 않고도 새로운 데이터의 파티셔닝 방식을 변경할 수 있습니다. 숨겨진 파티셔닝(hidden partitioning) 덕분에 분석가는 파티션 정리를 적용하기 위해 물리적 파티션 열을 직접 참조할 필요가 없습니다.

Iceberg 테이블 내부 구조 및 유지 관리

모든 쓰기 작업은 자체 매니페스트 목록이 포함된 새로운 스냅샷을 생성하기 때문에, 활발하게 쓰기가 수행되는 Iceberg 테이블을 관리하지 않고 방치하면 수천 개의 작은 매니페스트 및 데이터 파일이 누적될 수 있습니다. 쿼리 엔진은 여전히 각각의 관련 매니페스트 파일을 열고 평가해야 하므로, 매니페스트 파일의 무분별한 증가(sprawl)는 메타데이터 트리가 제공하도록 설계된 쿼리 성능 이점을 저하시킵니다.

일반적인 해결책은 예약된 압축(compaction)입니다. 이는 수집량에 따라 매일 밤 또는 매시간 실행되어 작은 데이터 파일을 더 적고 큰 파일로 다시 작성하고 매니페스트를 통합하는 유지 관리 작업입니다. 압축 작업을 정기적인 스냅샷 만료(보존 기간이 지난 메타데이터 제거)와 결합하면 타임 트래블이 도달할 수 있는 과거 범위를 제한하지 않으면서 스토리지 및 메타데이터 크기를 제어할 수 있습니다.

Delta Lake 및 ACID 트랜잭션

Delta Lake 트랜잭션 로그

Delta Lake 테이블은 모든 추가, 제거, 메타데이터 변경 사항을 기록하는 일련의 JSON 항목인 순서가 지정된 추가 전용 트랜잭션 로그를 더 빠른 읽기를 위해 로그를 요약하는 주기적인 체크포인트 파일과 함께 저장합니다. 역사적으로 파일 시스템 자체가 커밋 코디네이터 역할을 했기 때문에, 파일 수준의 액세스 권한이 있는 모든 클라이언트는 관리 카탈로그를 거치지 않고 Delta 테이블에 직접 쓸 수 있었습니다.

Delta Lake에서 ACID 트랜잭션이 작동하는 방식

ACID 트랜잭션은 모든 쓰기 작업자가 현재 로그 버전을 확인하고, 새로운 항목을 생성하며, 그 사이에 충돌하는 변경 사항이 발생하지 않은 경우에만 커밋하도록 요구함으로써 동시 쓰기 작업 중 데이터 일관성을 보장합니다. 충돌이 감지되면 쓰기 작업자는 다시 시도합니다. ACID 준수는 읽기 작업자가 부분적으로 작성된 상태의 Delta Lake 테이블을 절대 보지 못하게 하므로 데이터 손상을 방지하며, ACID 트랜잭션은 겹치는 파티션 간의 충돌 없이 복잡한 데이터 작업을 가능하게 합니다.

Spark 네이티브에서 멀티 엔진 지원으로의 확장

Delta Lake의 원래 커밋 모델은 파일 시스템 액세스에 의존했기 때문에, Apache Spark 외부의 서드파티 엔진은 관리 카탈로그 대신 정적 파일 경로를 통해 테이블에 액세스해야 했습니다. 이로 인해 이러한 액세스는 거버넌스 없이 방치되어 스키마 관계를 자동으로 손상시킬 수 있었습니다. Databricks는 Unity Catalog와 같은 카탈로그가 커밋 코디네이터 역할을 하도록 하는 오픈 표준인 카탈로그 커밋을 통해 이 문제를 해결했습니다. 이를 통해 모든 읽기, 쓰기 및 검색 요청이 중앙에서 승인됩니다. 이제 카탈로그 커밋을 정식 버전(GA)으로 사용할 수 있게 되어, Delta Lake를 Iceberg가 처음부터 사용해 온 카탈로그 지향적 접근 방식과 일치시키고 다중 테이블 트랜잭션을 지원합니다.

파일 포맷 기본 사항: Parquet가 데이터 스키핑을 지원하는 방식

Parquet 파일은 데이터를 행이 아닌 열(column) 단위로 구성하며, 동일한 열의 값들을 '행 그룹(row groups)'이라고 불리는 연속된 블록으로 그룹화합니다. 이러한 열 지향 스토리지 덕분에 쿼리 엔진은 쿼리가 참조하는 열만 읽고 나머지는 건너뛸 수 있습니다. 이는 스캔 작업이 많은 워크로드에서 Parquet가 행 지향 포맷보다 성능이 훨씬 뛰어난 주요 이유입니다.

모든 행 그룹에는 파일의 메타데이터 푸터에 기록된 열별 최소값 및 최대값, null 개수, 값 분포 등의 통계 정보가 포함되어 있습니다. 이러한 통계 정보를 통해 엔진은 데이터를 압축 해제하지 않고도 특정 행 그룹이 쿼리의 필터 조건과 일치할 가능성이 있는지 판단할 수 있습니다.

오픈 테이블 포맷은 이 원칙을 한 단계 더 확장합니다. Iceberg의 매니페스트 파일과 Delta Lake의 트랜잭션 로그는 모두 메타데이터 레이어에서 Parquet 수준의 통계를 캐싱하므로, 엔진은 오브젝트 스토리지에서 데이터 파일을 나열하기 전에 전체 데이터 파일을 건너뛸 수 있습니다. 이러한 2단계 데이터 건너뛰기(data skipping)는 대규모 테이블에서 쿼리 성능을 향상시키는 데 크게 기여합니다. Databricks는 또한 현재 Parquet, Delta Lake, Iceberg의 일부인 Variant 데이터 타입을 통해 이 모델을 확장했습니다. 이 데이터 타입은 반정형 페이로드를 원시 JSON 대신 타입이 지정된 바이너리 형태로 저장하므로, 엔진이 비용이 많이 드는 파싱 과정 없이 중첩된 필드를 추출할 수 있습니다.

데이터 버전 관리, 시간 여행(Time Travel) 및 증분 처리

데이터 버전 관리는 데이터를 제자리에서 덮어쓰는 대신 이전의 모든 테이블 상태 기록을 유지하는 오픈 테이블 포맷의 기능이며, 시간 여행은 버전 번호, 스냅샷 ID 또는 타임스탬프를 사용하여 이러한 이전 버전 중 하나를 읽는 기능입니다. 오픈 테이블 포맷은 설계상 데이터 세트의 시간 여행과 버전 관리를 지원합니다. 모든 쓰기 작업이 이미 독립적으로 주소를 지정할 수 있는 새로운 스냅샷이나 로그 항목을 생성하기 때문입니다.

증분 처리(incremental processing)는 전체 데이터 세트를 다시 스캔하는 대신 테이블이 마지막으로 처리된 이후 변경된 행만 읽는 방식입니다. 이는 파이프라인이 소스 테이블에 적용된 삽입(insert), 업데이트(update), 삭제(delete)만 소비하는 CDC(Change Data Capture)의 핵심 패턴입니다. Delta Lake에 도입되고 Iceberg v3를 통해 Iceberg에 적용된 행 계보(row lineage) 및 삭제 벡터(deletion vectors)는 이 작업을 더 저렴하게 만들었습니다. 행 계보는 테이블이 마지막으로 스캔된 이후 어떤 행이 변경되었는지 추적하고, 삭제 벡터는 데이터 파일을 다시 쓰는 대신 삭제된 행을 컴팩트한 비트맵으로 표현합니다.

모든 기록 버전을 무기한 보관하는 것은 비용이 많이 들기 때문에, 오픈 테이블 포맷은 버전 관리를 보존 정책 및 보존 기간 내에서 더 이상 참조되지 않는 데이터를 제거하는 vacuum 또는 스냅샷 만료(expire-snapshots) 작업과 결합합니다. vacuum을 너무 자주 실행하면 이전 버전을 여전히 참조하는 시간 여행 쿼리가 실패할 수 있으므로, 보존 기간은 해당 버전이 필요할 수 있는 가장 오래 실행되는 쿼리에 맞춰 설정됩니다.

프로덕션 테이블에 권장되는 주기적인 방식은 수집 주기에 맞춘 증분 처리(스트리밍 데이터 수집의 경우 보통 5~15분 간격)와 쿼리 사용량이 적은 시간대에 매일 실행되는 vacuum 및 스냅샷 만료 작업을 함께 구성하는 것입니다.

메타데이터 관리 및 성능 최적화

오픈 테이블 포맷은 레이어별로 구성된 메타데이터 관리를 통해 쿼리 성능을 향상시킵니다. 매니페스트 파일이나 로그 항목은 개별 데이터 파일을 설명하고, 스냅샷이나 로그 버전은 특정 시점의 테이블 상태를 설명하며, 카탈로그는 현재 어떤 버전이 유효한지 추적합니다. 현재 Unity Catalog는 전 세계 기업 배포 환경에서 오픈 테이블 포맷으로 저장된 17엑사바이트 이상의 데이터를 거버닝하고 있으며, 이는 현대적인 레이크하우스 카탈로그가 얼마나 방대한 메타데이터를 관리하고 있는지 보여줍니다.

테이블이 커짐에 따라 매니페스트 파일과 트랜잭션 로그 체크포인트 자체가 쿼리 계획 수립 속도를 늦출 수 있으므로, 매니페스트를 더 적고 큰 파일로 다시 쓰고 체크포인트 간격을 쓰기 빈도에 맞게 조정하는 유지 관리 작업이 필요합니다. Databricks와 오픈 소스 커뮤니티는 Delta Lake의 빠른 쓰기 로그와 Iceberg의 빠른 읽기 매니페스트 트리를 결합하여 Delta Lake와 Iceberg 전반에 걸친 통합 메타데이터 구조를 개발하고 있으며, 이는 3분기에 프리뷰로 제공될 예정입니다.

메타데이터 캐싱(최근에 액세스한 매니페스트, 체크포인트 또는 카탈로그 응답을 메모리에 유지하는 것)은 요청할 때마다 전체 메타데이터 트리를 탐색하지 않도록 하여 반복 쿼리 대기 시간을 줄여줍니다. 이는 동일한 대규모 테이블에 대해 많은 소규모 쿼리를 실행하는 BI 워크로드에서 가장 중요합니다.

ACID 트랜잭션 및 동시성 제어

Apache Iceberg, Delta Lake, Apache Hudi는 모두 단일 테이블 쓰기에 대해 직렬화 가능(serializable) 또는 스냅샷 격리(snapshot isolation) 수준을 보장하므로, 동시에 액세스하는 리더(reader)는 항상 완전하고 일관된 버전을 보게 되며 불완전한 쓰기 상태를 보지 않습니다. 이들의 차이점은 조정 방식에 있습니다. Iceberg는 항상 카탈로그를 단일 진실 공급원(source of truth)으로 사용해 왔고, Hudi는 자체 타임라인 서비스를 사용하며, Delta Lake는 카탈로그 커밋을 통해 카탈로그 조정 모델과 일치시키기 전에는 파일 시스템 원자성에 의존했습니다.

세 가지 포맷 모두 낙관적 동시성 제어(optimistic concurrency control)를 사용합니다. 즉, 쓰기 전에 테이블을 잠그는 대신 작성자(writer)가 현재 버전을 읽고 변경 사항을 준비한 다음, 그 사이에 다른 작성자가 충돌하는 변경 사항을 커밋하지 않은 경우에만 커밋합니다. 충돌이 감지되면 트랜잭션은 안전하게 실패하고 최신 버전에 대해 다시 시도하거나 중단되므로, 테이블이 일관되지 않은 상태로 남지 않습니다.

쓰기 경합을 줄이는 가장 효과적인 방법은 동시 작성자 간의 겹치는 영역을 줄이는 것입니다. 서로 다른 파이프라인이 서로 다른 파티션에 쓰도록 수집 작업을 파티셔닝하고, 소규모 쓰기를 더 적고 큰 커밋으로 일괄 처리하며, 병합(merge) 작업의 범위를 해당 작업이 영향을 미치는 파티션으로만 제한하십시오. 카탈로그 커밋도 도움이 됩니다. 다중 테이블 트랜잭션을 사용하면 여러 프로세스에서 별도의 쓰기로 경쟁하는 대신 관련 업데이트를 함께 커밋할 수 있기 때문입니다.

데이터 레이크에 적합한 테이블 포맷 선택하기

Apache Iceberg는 다중 엔진 읽기 액세스가 가장 중요한 경우, 즉 Trino, Snowflake, Flink, Spark에서 동일한 테이블을 동시에 쿼리하는 조직에 가장 적합합니다. Delta Lake는 다중 테이블 트랜잭션과 세분화된 거버넌스가 필요한 Spark 중심 파이프라인에 가장 적합합니다. Apache Hudi는 CDC 복제와 같이 빈도가 높은 레코드 수준의 업서트(upsert) 워크로드에 가장 적합하며, 이 경우 Hudi의 전용 인덱싱이 범용 병합 작업보다 성능이 뛰어납니다.

엔진 호환성은 단순한 기능 목록이 아니라 이미 프로덕션 환경에 있는 쿼리 엔진을 기준으로 평가해야 합니다. 기술적으로 우수하더라도 팀의 기본 엔진을 위한 성숙한 커넥터가 없는 포맷은 위험을 줄이기보다 오히려 더 많은 위험을 초래합니다. Java 및 Rust로 작성된 오픈 소스 라이브러리인 Delta Kernel은 엔진이 프로토콜을 다시 구현하지 않고도 Delta Lake 지원을 추가하는 일반적인 방법이 되었습니다. 이미 DuckDB 및 ClickHouse 통합을 지원하고 있으며, 두 구현은 공유 Rust 코어로 수렴되고 있습니다.

포맷을 표준화하기 전에 대표적이고 적당히 복잡한 프로덕션 테이블을 대상으로 개념 검증(PoC)을 실행해 보세요. 동시 부하 상태에서 쓰기 대기 시간을 측정하고, 대상 엔진이 느린 커넥터 대신 기본적으로 포맷을 읽는지 확인하며, 스키마 진화(schema evolution) 및 시간 여행이 예상대로 작동하는지 검증하십시오.

상호 운용성, 카탈로그 및 벤더 고려 사항

카탈로그 옵션 및 교차 포맷 상호 운용성

카탈로그는 어떤 테이블이 존재하는지, 데이터가 어디에 있는지, 어떤 스냅샷이 유효한지 추적하는 기록 시스템입니다. 옵션으로는 기존 Hive Metastore, AWS Glue Data Catalog, 그리고 단일 액세스 정책 세트 하에서 Delta Lake 및 Apache Iceberg 테이블을 함께 거버닝하는 Unity Catalog 등이 있습니다. Delta Lake UniForm은 한 걸음 더 나아가 스토리지를 복제하지 않고도 단일 Delta Lake 데이터 사본을 Iceberg 테이블로 기본 읽을 수 있도록 지원하여, 팀이 표준화를 미루게 만드는 포맷 종속(lock-in) 우려를 해결합니다.

벤더 종속 위험 및 완화 방법

벤더 종속 위험을 완화하는 가장 확실한 방법은 둘 이상의 독립적인 엔진 구현이 있는 포맷을 선택하고, 파일 액세스뿐만 아니라 카탈로그 액세스도 향후 팀에 필요할 수 있는 플랫폼 간에 이식 가능한지 확인하는 것입니다. Iceberg와 Delta Lake는 오픈 소스이므로 두 포맷 중 하나에 데이터를 저장하는 것 자체로 조직이 하나의 처리 엔진에 종속되지는 않지만, 그 위에 구축된 거버넌스 레이어의 이식성은 다를 수 있습니다.

운영, 모니터링 및 모범 사례

테이블 유지 관리는 임시 작업이 아니라 런북(runbook)으로 체계화해야 합니다. 압축(compaction)이 필요한 테이블과 파일 크기 임계값을 정의하고, 작업이 데이터를 얼마나 오래전까지 쿼리하는지 기준에 따라 vacuum 및 스냅샷 만료의 보존 기간을 설정하며, 두 작업 모두 쿼리 사용량이 많은 시간대를 피해 예약하십시오.

테이블 상태 모니터링에서는 테이블당 파일 수 및 평균 파일 크기, 커밋 실패율, 압축 일정 대비 가장 오래된 데이터 파일의 수명을 추적해야 하며, 작은 파일 수나 충돌률이 급증할 때 알림을 보내야 합니다. 이러한 메트릭은 메타데이터 비대화 및 쓰기 경합이 쿼리 속도 저하로 나타나기 전에 미리 감지해 줍니다.

오픈 테이블 포맷은 기존 쿼리를 손상시키지 않고 스키마 진화를 지원하므로 스키마 변경 사항이 프로덕션 테이블에 직접 적용되는 경우가 많지만, 이러한 편리함 때문에 테스트를 건너뛰기 쉽습니다. 팀은 대표적인 다운스트림 쿼리에 대해 변경 사항을 검증하고 주기적으로 이전 스냅샷으로의 롤백을 연습해야 합니다. 그래야 잘못된 변경 사항으로부터 복구하는 과정이 압박감 속에서 처음 시도하는 일이 아니라 연습된 절차가 될 수 있습니다.

결론: 오픈 테이블 포맷의 절충점 및 다음 단계

Apache Iceberg, Delta Lake, Apache Hudi는 각 포맷의 시작점에 따라 형성된 메타데이터 설계를 통해 저렴한 오브젝트 스토리지에 저장된 데이터에 ACID 트랜잭션, 스키마 진화, 시간 여행 기능을 제공한다는 동일한 핵심 문제를 해결합니다. Iceberg는 다중 엔진 분석, Delta Lake는 Spark 네이티브 파이프라인, Hudi는 고빈도 업서트를 지향합니다. Parquet는 세 가지 포맷 모두의 기반이 되는 공통 파일 포맷으로 유지되고 있으며, 최근의 혁신 기술인 삭제 벡터, 행 계보, Variant, 카탈로그 조정 커밋 등은 각 포맷에 고립되어 있기보다 서로 수렴해 가고 있습니다.

대부분의 팀에게 실질적인 다음 단계는 범위가 지정된 개념 검증(POC)을 수행하는 것입니다. 기존 엔진 스택과 일치하는 형식을 선택하고, 실제 프로덕션 데이터 볼륨을 대상으로 테스트한 다음, 이를 관리하는 카탈로그가 나중에 두 번째 형식으로 확장될 수 있는지 확인하는 것입니다. Databricks의 개방형의 형식에 구애받지 않는 레이크하우스 스토리지를 사용하면 데이터를 한 번만 저장하고 단일 카탈로그의 거버넌스 하에 Delta Lake 또는 Apache Iceberg로 기본 쿼리할 수 있으므로, 데이터를 복제하거나 단일 형식에 종속될 필요가 없습니다.

오픈 테이블 형식에 대해 자주 묻는 질문

오픈 테이블 형식이란 무엇인가요?

오픈 테이블 형식은 오브젝트 스토리지의 데이터 파일 상위에 위치하는 오픈 소스 메타데이터 레이어로, 데이터 레이크에 ACID 트랜잭션, 스키마 진화(schema evolution), 타임 트래블과 같은 데이터베이스와 유사한 기능을 추가합니다. Apache Iceberg, Delta Lake, Apache Hudi는 프로덕션 환경에서 사용되는 세 가지 주요 오픈 테이블 형식이며, 각각 Parquet 또는 ORC 파일 모음을 지원되는 모든 엔진이 안전하게 읽고 쓸 수 있는 테이블로 변환합니다.

테이블 형식과 파일 형식의 차이점은 무엇인가요?

Parquet나 ORC와 같은 파일 형식은 개별 데이터 파일이 디스크에 압축되고 구성되는 방식을 정의하는 반면, Apache Iceberg나 Delta Lake와 같은 테이블 형식은 이러한 여러 파일이 함께 모여 하나의 일관되고 쿼리 가능한 테이블을 구성하는 방식을 정의합니다. 오픈 테이블 형식은 파일 형식 위에 구축되어 파일 형식만으로는 제공할 수 없는 매니페스트, 트랜잭션 로그, 카탈로그와 같은 메타데이터 레이어를 추가합니다.

Delta Lake와 Apache Iceberg 테이블을 함께 사용할 수 있나요?

예, 가능합니다. Delta Lake UniForm을 사용하면 스토리지를 복제하지 않고도 단일 Delta Lake 테이블 데이터 복사본을 Apache Iceberg 테이블로 기본 읽을 수 있으며, Unity Catalog와 같은 카탈로그는 하나의 액세스 정책 세트 하에서 두 형식을 함께 거버닝할 수 있습니다. 이러한 상호 운용성을 통해 조직은 모든 엔진에 동일한 테이블 형식을 강제하지 않고도 공유 거버넌스를 표준화할 수 있습니다.

어떤 오픈 테이블 형식을 선택해야 하나요?

가장 적합한 오픈 테이블 형식은 이미 프로덕션에 도입된 쿼리 엔진 및 워크로드에 따라 다릅니다. Apache Iceberg는 Trino 및 Snowflake와 같은 도구 전반의 다중 엔진 분석에 적합하고, Delta Lake는 다중 테이블 트랜잭션이 필요한 Spark 중심 파이프라인에 적합하며, Apache Hudi는 CDC 복제와 같이 빈도가 높은 레코드 수준의 업서트(upsert) 워크로드에 적합합니다. 실제 프로덕션 데이터를 대상으로 한 개념 검증(POC)을 통해 가장 적합한 형식을 확인할 수 있습니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)