공부/데이터 2026. 4. 27. 21:38

레이크하우스 오픈 테이블 포맷 완전 비교

Delta Lake · Apache Iceberg · Apache Hudi · Apache Paimon · DuckLake(2026) 포맷의 메타데이터 구조, 카탈로그 아키텍처, 심화 기술 특징을 비교합니다. Apache XTable(상호운용 레이어)도 별도 정리합니다.

레이크하우스란?

레이크하우스(Lakehouse) = 데이터 레이크의 유연성·비용 효율성 + 데이터 웨어하우스의 ACID 트랜잭션·스키마 관리·거버넌스를 오픈 파일 포맷 위에서 직접 제공하는 통합 아키텍처

전통 2계층 아키텍처의 문제

구분 데이터 레이크 데이터 웨어하우스

장점	정형·비정형 대량 저장, 비용 효율적	ACID 트랜잭션, 스키마 강제, 우수한 쿼리 성능
단점	품질·일관성·거버넌스 관리 어려움	ETL 필수, 높은 비용, 비정형 데이터 미지원

두 계층 혼용 시 데이터 중복 · ETL 복잡성 · 시스템 간 불일치 · 높은 TCO 문제가 발생합니다.

오픈 테이블 포맷이 해결하는 문제

오픈 테이블 포맷(Delta Lake, Iceberg, Hudi, Paimon 등)은 객체 스토리지(S3/OSS) 위에서 데이터 웨어하우스 수준의 기능을 직접 제공합니다.

ACID 트랜잭션: 병렬 읽기/쓰기 충돌 방지
스키마 관리: 강제(enforcement) + 진화(evolution)
데이터 버전 관리: Time Travel로 과거 스냅샷 조회
멀티 워크로드 지원: BI/SQL · ML/AI · 실시간 스트리밍을 단일 플랫폼에서

포맷 분류 체계

분류 포맷 핵심 패러다임

전통 파일 기반	Delta Lake	Flat JSON 로그 + Parquet 체크포인트, 카탈로그 독립
전통 파일 기반	Apache Iceberg	계층적 스냅샷 트리, 외부 카탈로그 필수
전통 파일 기반	Apache Hudi	Timeline 기반 CDC/Upsert 특화, COW/MOR 이중 구조
전통 파일 기반	Apache Paimon	LSM Tree + 스트리밍 네이티브, Flink 통합
SQL DB 기반	DuckLake	SQL DB가 카탈로그 + 메타데이터 역할 (2025~2026 신흥)
상호운용 레이어	Apache XTable	포맷 간 메타데이터 변환 (독립 포맷 아님)
실시간 스트리밍 스토리지 (Lakehouse 포맷 아님)	Apache Fluss	분산 스트리밍 스토리지 시스템. Kafka 후계자. Paimon/Iceberg의 hot tier 보완재 (ASF Incubating, 2025~2026)

핵심 비교 요약

항목 Delta Lake Apache Iceberg Apache Hudi Apache Paimon DuckLake

기원	Databricks	Netflix	Uber	Alibaba/Flink 커뮤니티	DuckDB Labs
출시	2019	2018	2019	2023	2025 (v1.0: 2026.04)
메타데이터 저장	_delta_log/ (JSON + Parquet)	metadata.json → Manifest 계층	.hoodie/ Timeline	Snapshot → Manifest 계층	SQL DB (SQLite / DuckDB / PostgreSQL)
외부 카탈로그 필수	아니오 (경로 기반 독립)	예 (필수)	아니오 (HMS 권장)	아니오 (FilesystemCatalog 기본)	아니오 (SQL DB 자체가 카탈로그)
저장 구조	Flat 로그 + Checkpoint	계층적 스냅샷 트리	Timeline + COW/MOR	LSM Tree • 스냅샷	Parquet + SQL 메타데이터
핵심 강점	Spark 생태계, 배치 처리	멀티 엔진 호환성	CDC/Upsert 특화	스트리밍 네이티브	경량·단순·DuckDB 최적화
동시성 제어	OCC + Coordinated Commits	OCC (CAS)	OCC + NBCC (1.0)	OCC (스냅샷 격리)	SQL DB 트랜잭션
Time Travel	버전/타임스탬프	스냅샷 ID/타임스탬프	타임스탬프/커밋	스냅샷 ID/타임스탬프	SQL DB 쿼리 기반
파티션 진화	X (Liquid Clustering 대체)	O (재작성 불필요)	제한적	O	X (단순 설계)
스트리밍 지원	보통	보통	우수	최우수 (Flink 네이티브)	미지원 (배치 중심)
Small File 자동화	Databricks 전용	수동 트리거	비동기 서비스 분리	Flink 내장 자동화	Data Inlining으로 회피
벤더 중립성	중간 (Databricks 주도)	높음 (30개+ 기업)	높음 (ASF)	중간 (Alibaba 주도)	중간 (DuckDB Labs)

전통 파일 기반 포맷

1. Delta Lake

메타데이터 구조: _delta_log/

Delta Lake는 카탈로그 없이 독립 동작이 가능한 설계입니다. 모든 트랜잭션 정보가 _delta_log/ 디렉토리에 완전히 내재화되어 있습니다.

<table-root>/
├── _delta_log/
│   ├── 00000000000000000000.json   # 최초 커밋
│   ├── 00000000000000000001.json
│   ├── 00000000000000000010.parquet  # 체크포인트 (10번째마다 자동)
│   ├── _last_checkpoint              # 최신 체크포인트 포인터
│   └── _sidecars/                    # V2 체크포인트 사이드카 (3.0+)
└── part-00000-xxxx.snappy.parquet

JSON 커밋 파일 액션 타입: protocol · metaData · add (파일 추가 + min/max 통계) · remove (논리 삭제) · commitInfo

파일 번호 자체가 순서를 보장하므로 외부 포인터가 불필요합니다.

카탈로그 아키텍처

방식 설명

경로 기반 (카탈로그 없음)	spark.read.format("delta").load("s3://...") — 외부 서비스 불필요
Hive Metastore	가장 범용적. Spark, Trino, Presto 호환
Unity Catalog	Delta 네이티브. 멀티클라우드 거버넌스, Row-level Security/Column Masking 지원
AWS Glue	서버리스. Athena/EMR 연동
Apache Polaris	Iceberg REST 스펙 준수 오픈소스

ACID 트랜잭션

기본 OCC (Optimistic Concurrency Control). Delta 4.0부터 Coordinated Commits 도입 — DynamoDB 등 외부 Commit Coordinator가 커밋을 중재하여 멀티엔진 동시 쓰기를 안전하게 보장합니다.

Deletion Vector (DV)

Delta 3.1에서 Compressed Bitmap 방식 GA. 파일 재작성 없이 _delta_log/*.bin 사이드카 파일에 삭제 위치를 비트맵으로 저장합니다.

주요 기능

Time Travel: VERSION AS OF 42 / TIMESTAMP AS OF '2025-01-01'
스키마 진화: mergeSchema (컬럼 추가), Column Mapping (컬럼명 변경/삭제, 파일 재작성 없음)
Liquid Clustering (3.0+): 내부적으로 Hilbert Curve 사용. Z-ORDER 대비 고차원 데이터 locality 우수. 증분 클러스터링으로 전체 재작성 불필요
Delta Sharing: 크로스 플랫폼 데이터 공유 프로토콜 (데이터 복제 없이 서명된 URL 공유)
UniForm (3.0+): 동일 Delta 파일 위에 Iceberg/Hudi 메타데이터 자동 생성 → Snowflake, Athena 직접 읽기 가능

단점 & 주의사항

Databricks 전용 기능: Auto Optimize, Auto Loader, Bloom Filter Index, Primary Key 제약 — OSS Delta에는 없음
파티션 진화 미지원: 파티션 변경 시 전체 데이터 재작성 필요
Small File 자동화: Databricks 환경 전용. OSS에서는 OPTIMIZE 수동 실행 필요

2. Apache Iceberg

카탈로그가 필수인 이유

오브젝트 스토리지(S3)는 원자적 파일 교체를 보장하지 않음
  → v1.metadata.json vs v2.metadata.json — 어느 것이 현재 유효한 버전인지 파일 목록만으로 알 수 없음
  → 외부 서비스가 원자적 CAS(Compare-and-Swap)로 단일 포인터를 관리해야 함

카탈로그가 저장하는 것은 단 하나:
  prod_db.orders → s3://.../metadata/v4.metadata.json

메타데이터 4계층 구조

Catalog
  └── Namespace (Database)
        └── Table
              └── metadata.json  ← 카탈로그가 가리키는 유일한 포인터
                    └── Snapshot
                          └── Manifest List (Avro, 파티션 범위 통계 포함)
                                └── Manifest File (Avro, 컬럼 min/max 통계 포함)
                                      └── Data Files (Parquet/ORC/Avro)

여러 버전 메타데이터 파일 관리

metadata/
  v1.metadata.json   ← 최초 생성
  v2.metadata.json   ← INSERT 후 (v1은 삭제되지 않음)
  v3.metadata.json   ← UPDATE 후
  v4.metadata.json   ← 현재 버전 (카탈로그가 이 경로만 가리킴)

카탈로그는 여러 버전 중 가장 최신 버전 파일 경로 하나만 포인터로 유지합니다. 이전 버전들은 Time Travel을 위해 보존됩니다.

3단계 프루닝 메커니즘

1단계: Manifest List → 파티션 범위로 불필요한 Manifest File 스킵
2단계: Manifest File → 컬럼 min/max 통계로 불필요한 Data File 스킵
3단계: Data File 내부 → Parquet Row Group 통계로 Row Group 스킵

ACID 트랜잭션: Snapshot Isolation + OCC

모든 파일은 불변(immutable). Writer는 새 파일을 생성하고 카탈로그 포인터를 CAS로 원자 교체합니다. 충돌 시 rollback + retry.

Deletion Vector (Iceberg v3, 2025 GA)

v2의 Position/Equality Delete File 방식을 개선하여 v3에서 Puffin 파일 기반 DV 도입.

Puffin 파일 (compact binary sidecar) 에 압축 비트맵으로 삭제 위치 저장
데이터 파일 1개당 DV 1개만 허용, 신규 삭제 시 기존 DV와 merge
AWS 벤치마크: v2 대비 delete 속도 55% 향상, 저장 크기 73.6% 감소

주요 기능

Hidden Partitioning: month(order_date), bucket(16, user_id) 등 변환 함수로 물리 파티션 자동 관리
파티션 진화: ALTER TABLE ... SET PARTITION SPEC (day(order_date)) — 기존 데이터 재작성 없이 파티션 전략 변경
Time Travel: Snapshot ID 또는 타임스탬프 기반
REST Catalog 표준: OpenAPI 스펙 기반 Vendor-neutral 카탈로그 인터페이스

지원 카탈로그 구현체:

구현체 특징

Apache Polaris	Snowflake 오픈소스 기증. RBAC + Credential Vending
Project Nessie	Git 스타일 브랜치/태그. 다중 테이블 트랜잭션 지원
Lakekeeper	Rust 기반 경량 구현
AWS Glue	관리형. AWS 생태계 최적화
Hive Metastore	레거시 호환성

단점

카탈로그 없이 동작 불가 — 운영 복잡도 증가
Delete 파일(v2) 누적 시 읽기 성능 저하 → 주기적 Compaction 필요
Small File 자동화 도구 없음 (수동 rewrite_data_files 실행 의존)
Clustering 알고리즘: Z-order만 지원, Hilbert Curve 미지원 (2026 기준)

3. Apache Hudi

Delta Lake와 유사한 설계 철학을 가지나, CDC/Upsert에 특화된 포맷입니다. Uber가 설계한 목적 자체가 record-level upsert입니다.

메타데이터 구조: .hoodie/ Timeline

<table_base_path>/
├── .hoodie/
│   ├── hoodie.properties          # 테이블 핵심 설정
│   ├── <instant>.commit           # 완료된 커밋
│   ├── <instant>.inflight         # 진행 중
│   ├── <instant>.requested        # 요청됨
│   ├── archived/                  # 아카이브된 타임라인
│   └── metadata/                  # Hudi Metadata Table (파일 목록, Bloom Filter, RLI)
└── partition_col=value/
    └── *.parquet / *.log

Timeline 파일명 자체가 순서를 표현하며, completed 상태 인스턴트만 Reader에 가시적입니다.

카탈로그 아키텍처

자체 카탈로그 서버 없음. HMS에 스키마/파티션 자동 싱크(HiveSyncTool). 경로 기반 직접 접근도 가능합니다.

테이블 타입: COW vs MOR

특성 Copy-on-Write (COW) Merge-on-Read (MOR)

업데이트 방식	파일 전체 재작성	.log 파일에 변경 기록
읽기 성능	우수 (base file만)	보통 (base + log 병합)
쓰기 성능	낮음	높음 (log append)
적합 케이스	배치 중심, 변경 빈도 낮음	CDC/스트리밍, 고빈도 upsert

ACID 트랜잭션: NBCC (Hudi 1.0의 핵심)

기본 OCC: 파일 그룹 단위 충돌 감지
NBCC (Non-Blocking Concurrency Control): 여러 스트리밍 Writer가 동일 File Slice에 Log File을 자유롭게 병렬 기록, 충돌 해소를 Compaction 단계로 위임. 명시적 락 불필요

Walmart 사례: 대규모 뮤터블 워크로드에서 Delta/Iceberg OCC가 반복 실패한 반면, Hudi NBCC만 안정적으로 동작했습니다.

Upsert 특화: Record-Level Index

인덱스 특징

Bloom Filter	기본. 파일 footer에 저장, 2단계 프루닝
HBase Index	O(1) 조회, 외부 HBase 서버 필요
Bucket Index	Hash 기반 결정론적 라우팅, 인덱스 조회 불필요
Record-Level Index (RLI, 0.14+)	외부 서버 없이 HBase 수준 성능. 현재 권장

Clustering 알고리즘

Hudi는 Linear Sort, Z-order, Hilbert Curve 모두 지원합니다. 인라인(write 시 동시) 또는 비동기(별도 서비스) 두 모드 선택 가능하며 파티션 내 fine-grained clustering이 가능합니다.

주요 기능

Incremental Query: 특정 시점 이후 변경된 레코드만 조회 (설계 초기부터, Delta CDF보다 앞서 구현)
CDC Query (0.13+): before/after 이미지 + 작업 유형(insert/update/delete) 포함
이벤트 타임 정렬: RecordPayload / RecordMerger API로 늦게 도착한 데이터도 정확하게 병합
Hudi Metadata Table: 파일 목록, Bloom Filter, 컬럼 통계, 레코드 인덱스 캐싱 → S3 LIST 비용 절감
LSM Timeline (1.0): 수백만 히스토리 인스턴트를 LSM Tree 방식으로 효율 관리

단점

HMS 강한 의존성, Unity Catalog 같은 통합 거버넌스 부재
MOR 테이블은 주기적 Compaction 없이 읽기 성능 저하
Snowflake, BigQuery 등 클라우드 DW에서 네이티브 지원 미흡

4. Apache Paimon

Iceberg와 유사한 스냅샷 기반 구조를 가지나, 스트리밍 네이티브 설계와 LSM Tree 저장 구조가 핵심 차별점입니다.

Flink Table Store로 출발(2022) → Apache Paimon으로 개명 후 ASF 독립 프로젝트(2023).

메타데이터 구조: 이중 Manifest List

Snapshot
  ├── Base Manifest List   ← S-1까지 누적 뷰 (배치 리더용)
  └── Delta Manifest List  ← 직전 스냅샷 대비 변경분만 (스트리밍 리더용)
        └── Manifest File (Avro)
              └── Data File / Changelog File / Index File

스트리밍 리더는 Delta Manifest만 읽어 최신 변경분만 소비, 배치 쿼리는 Base + Delta 결합으로 전체 뷰를 얻습니다.

카탈로그 아키텍처

카탈로그 특징

FilesystemCatalog (기본)	외부 서비스 불필요. 파일 어휘 정렬로 최신 스냅샷 파악
HiveCatalog	Hive에서 직접 접근 가능
JdbcCatalog	MySQL/PostgreSQL 활용
REST Metastore	표준 REST 인터페이스

LSM Tree 기반 저장

Write → Memory Buffer (Primary Key 기준 정렬)
     → Flush (Level 0 Sorted Runs)
     → Background Compaction → Level 1, 2, ...N

Primary Key Table: CRUD 완전 지원. Merge Engine: Deduplicate / Partial Update / Aggregation / First Row
Append-Only Table: INSERT 전용. 메시지 큐 대체용

Flink 통합 및 스트리밍 차별점

항목 Iceberg Paimon

스트리밍 레이턴시	높음 (마이크로배치)	100ms 미만
Changelog 생성	없음 (별도 CDC 툴 필요)	내장 Changelog Producer
Flink 통합	커넥터 수준	네이티브 (Materialized Tables, 2-Phase Commit)
워터마크	미지원	내장 지원

Changelog Producer 모드: input (CDC 소스 그대로) · lookup (before/after 이미지 생성) · full-compaction (안정성 우선)

Exactly-once 처리 보장: Paimon은 Flink의 체크포인트 메커니즘과 완벽하게 연동됩니다. Flink 작업 장애 복구 시 중복 쓰기나 데이터 유실 없이 exactly-once semantics를 보장합니다.

Flink 외부 상태 저장소로 활용: Paimon Primary Key Table을 Flink 스트리밍 작업의 외부 상태 저장소로 사용할 수 있습니다. Kafka 소비 오프셋 관리와 연동하여 체크포인트 기반 일관된 복구가 가능합니다. (Fluss PK Table이 이 역할을 더 최적화하는 방향으로 진화 중)

Iceberg 호환성

'metadata.iceberg.storage' = 'hadoop-catalog'

Iceberg v3 Deletion Vector 지원 시 Paimon Primary Key Table을 Iceberg 리더로 완전히 읽기 가능합니다.

Small File 자동화

Flink 스트리밍 파이프라인 안에서 LSM compaction이 상시 자동 실행됩니다. 별도 compaction 스케줄러가 필요 없습니다.

단점

상대적으로 신생 프로젝트 (커뮤니티 성숙도 낮음)
Flink 중심 생태계 (Spark/Trino에서 일부 기능 제한)
배치 처리 성능은 Iceberg/Delta 대비 낮을 수 있음

SQL DB 기반 포맷

5. DuckLake

2025~2026년 가장 주목받는 신흥 포맷. "파일 기반 메타데이터" 패러다임과 완전히 다른 축입니다.

배경

2025년 5월: DuckDB Labs가 DuckLake v0.1 발표
2026년 4월 13일: v1.0 production-ready 출시 (DuckDB v1.5.2 내장)
DuckDB 핵심 확장 중 다운로드 Top-10 진입, 수십 개 기업 프로덕션 사용 중

핵심 아이디어: SQL DB가 카탈로그 + 메타데이터

기존 포맷의 "Iceberg + Polaris 카탈로그" 조합 전체를 SQL DB 하나로 대체합니다.

기존 패러다임:
  오브젝트 스토리지 파일들 + 외부 카탈로그 서비스 (HMS/Polaris)

DuckLake 패러다임:
  SQL DB (SQLite/PostgreSQL/DuckDB) ← 카탈로그 + 메타데이터 모두 여기
  오브젝트 스토리지 ← 실제 Parquet 데이터 파일만

항목 Delta/Iceberg/Hudi DuckLake

메타데이터 저장	JSON 로그/Avro (object storage)	SQL DB 테이블
카탈로그	별도 Hive Metastore / REST 카탈로그	SQL DB 자체가 카탈로그
데이터 파일	Parquet / ORC	Parquet
동시성 제어	OCC (파일 레벨)	SQL DB 트랜잭션

Data Inlining: Small File 문제 원천 해소

소량 변경(수십~수백 행)을 Parquet으로 저장하지 않고 카탈로그 SQL DB에 직접 인라인 저장합니다. 누적되면 CHECKPOINT 명령으로 Parquet으로 플러시합니다. 소규모 스트리밍 쓰기에서 소파일 폭발 문제를 원천적으로 회피합니다.

메타데이터 규모

1PB 데이터 기준 메타데이터 크기 약 10GB 수준. SQL DB가 처리하기에 적합한 크기입니다.

지원 클라이언트

DuckDB 외에도 Apache DataFusion, Apache Spark, Trino, Pandas 클라이언트 구현이 완료되었습니다.

단점 & 주의사항

SQL DB가 단일 장애점(SPOF): PostgreSQL 등 외부 DB에 의존 — 순수 object-storage 아키텍처를 선호하는 팀에 부적합
커뮤니티 성숙도 낮음 (생태계 초기 단계)
멀티 엔진 대규모 동시성에서의 검증 부족
파티션 진화, 스키마 진화 기능이 기존 포맷 대비 단순

적합한 케이스

DuckDB 중심 소규모 팀 / 단일 엔진 환경
로컬 또는 소규모 클라우드 분석 워크로드
운영 복잡도를 최소화하고 싶은 경우
기존 SQL 인프라(PostgreSQL 등)를 메타데이터 저장소로 재활용하고 싶은 경우

스트리밍 스토리지 레이어 (Hot Tier)

6. Apache Fluss

[스트리밍 스토리지 — Lakehouse 테이블 포맷 아님] Fluss는 Delta Lake/Iceberg/Hudi/Paimon 같은 레이크하우스 파일 포맷이 아닙니다. 분산 스트리밍 스토리지 시스템으로, Paimon/Iceberg의 hot tier 보완재입니다. Kafka + RocksDB의 schematized 후계자에 가깝습니다.

배경 및 거버넌스

출처: Alibaba/Ververica → Flink Forward Asia 2024 오픈소스 공개
거버넌스: Apache Software Foundation Incubating (2025년 6월)
라이선스: Apache 2.0
최신 버전: v0.9.0 (2026년 3월)
운영 규모 (Taobao): 3PB+, 40 GB/s ingest, 500K QPS 포인트 룩업, 단일 테이블 500B+ rows

클러스터 아키텍처

[Flink Job / Spark Client]
        │
        ▼
CoordinatorServer ── 메타데이터 관리, Tablet 할당, 리밸런싱, Tiering 조정
        │
        ▼
TabletServer (N개)
  ├── LogStore (Apache Arrow IPC Columnar)
  │     → append-only, Kafka 스타일 복제, 서버 측 Column Pruning
  └── KvStore (RocksDB)
        → PK 기반 mutable 저장소, 500K QPS 포인트 룩업
        → CDC Changelog 출력 (+I / +U / -U / -D)
ZooKeeper ── 분산 조정 (향후 KvStore로 대체 예정)

파일 기반 포맷과의 핵심 차이: 파일 + 메타데이터 규약이 아닌 서버 클러스터가 필수인 분산 시스템입니다.

데이터 포맷 이중 구조

계층 포맷 저장 위치 레이턴시

핫 (Fluss 직접)	Apache Arrow IPC (열 기반, zero-copy)	TabletServer NVMe/SSD	밀리초 미만 (sub-second)
콜드 (Tiering 이후)	Parquet (Paimon / Iceberg / Lance)	S3/OSS 객체 스토리지	분~시간 단위

테이블 타입

타입 특징 적합 사용처

Log Table	append-only, schematized Kafka topic. Arrow IPC 저장	이벤트 스트림, 메시지 큐 대체
Primary Key (PK) Table	RocksDB KvStore + WAL. CRUD + CDC Changelog 출력 (+I/+U/-U/-D)	실시간 차원 테이블, A/B 카운터, CDC 핫 경로, Lookup Join 외부화

Union Read — 핫·콜드 통합 쿼리

-- 핫(Fluss) + 콜드(Paimon/Iceberg) 통합 조회
SELECT * FROM fluss_table;

-- 콜드(Paimon/Iceberg) 전용 — $lake suffix
SELECT * FROM fluss_table$lake;

Flink SQL에서 hot/cold 데이터를 자동 통합합니다. Tiering Service가 백그라운드에서 Fluss → Paimon/Iceberg로 데이터를 자동 이관합니다.

엔진 지원

엔진 지원 수준

Apache Flink	1급 네이티브 (설계 1순위)
Apache Spark	v0.9부터 추가
Trino / StarRocks	로드맵 단계 (Union Read 포함)
Paimon / Iceberg 클라이언트	Tiering 후 표준 방식으로 자동 지원

Fluss vs Paimon vs Kafka 비교

항목 Fluss Paimon Kafka

본질	분산 스트리밍 스토리지 시스템	레이크하우스 파일 포맷	분산 메시지 큐
쓰기 레이턴시	밀리초 미만	초~분 단위	밀리초 미만
스키마 강제	예 (강한 타입)	예	아니오 (기본)
PK/Upsert	예 (RocksDB, 500K QPS)	예 (LSM Tree)	아니오
Time Travel	제한적 (cold 계층 의존)	예 (스냅샷)	아니오
OLAP 직접 쿼리	Tiering 후 가능	예 (Spark/Trino)	아니오
서버 클러스터 필요	예 (CoordinatorServer + TabletServer)	아니오 (라이브러리)	예
핫 데이터 포맷	Apache Arrow IPC	없음 (파일 직접)	바이너리 로그

카탈로그 아키텍처

자체 분산 카탈로그 (CoordinatorServer + ZooKeeper). Hive Metastore, Glue, Polaris 같은 파일 기반 외부 카탈로그와 다른 모델입니다. Tiering 시 Iceberg/Paimon 카탈로그에 메타데이터를 자동 등록합니다.

단점 & 주의사항

서버 클러스터 필수: 파일 기반 포맷 대비 운영 복잡도 높음 (k8s 배포 필요)
Flink 중심 생태계: Spark(0.9 신규), Trino/StarRocks(로드맵) — 성숙도 제한
ASF Incubating 단계: v0.9, 아직 안정화 진행 중
Time Travel 약함: 사용자 대면 Time Travel은 Paimon/Iceberg에 의존
채택 사례 편중: 대부분 Alibaba 그룹 (외부 기업 공개 사례 제한적)

적합한 케이스

sub-second freshness가 요구되는 실시간 대시보드 및 서비스
Flink Lookup Join 외부 상태 저장소 (Fluss PK Table)
CDC 핫 경로 처리 후 Tiering으로 자동 배치 분석 연동
실시간 개인화 추천, A/B 테스트 카운터, 실시간 특성 저장소
Kafka에 스키마 강제 + OLAP 쿼리 연동이 동시에 필요한 경우

상호운용 레이어

Apache XTable (구 OneTable)

새로운 포맷이 아니라 포맷 간 메타데이터 변환 레이어입니다. 데이터 파일 복사 없이 메타데이터만 변환합니다.

2024년 2월: Apache Incubating 프로젝트 편입
Delta Lake ↔ Apache Iceberg ↔ Apache Hudi 간 양방향 변환
Paimon 지원 로드맵 포함

Delta UniForm과의 차이

항목 Delta UniForm Apache XTable

주체	Databricks (Delta Lake 내장)	독립 오픈소스
방향	Delta → Iceberg/Hudi (단방향 중심)	모든 포맷 간 양방향
의존성	Delta Lake 필수	포맷 무관
거버넌스	Databricks 주도	ASF 중립

적합한 케이스

기존 Delta Lake 테이블을 Iceberg 기반 툴에서도 읽어야 하는 경우
포맷 전환 없이 멀티 포맷 환경을 운영해야 하는 경우
특정 벤더에 종속 없이 포맷 상호운용성을 유지하고 싶은 경우

심화 비교

Deletion Vector 구현 방식 비교

포맷 방식 저장 위치 특이사항

Delta Lake	Compressed Bitmap (3.1+)	_delta_log/*.bin 사이드카	REORG로 물리 정리
Iceberg v3	Puffin 파일 + Compressed Bitmap	데이터 파일 옆 sidecar	파일당 DV 1개 제한, v2 대비 삭제 55% 빠름
Iceberg v2	Position Delete File (행 위치) + Equality Delete File (값 기반)	별도 Parquet 파일	파일 폭발 문제 있음
Hudi	Delta Log File (append-only)	.log 파일	이벤트 타임 정렬 지원이 강점
Paimon	LSM multi-level compaction	LSM 구조 자체	별도 DV 없음, LSM이 삭제/갱신 흡수

Iceberg v3 + Delta가 유사한 DV 방식으로 수렴 중. Hudi는 이벤트 타임 처리에서 차별화. Paimon은 LSM 구조 자체가 DV 역할.

Small File 문제 해결 전략

포맷 발생 원인 해결 메커니즘 자동화 수준

Delta Lake	스트리밍 micro-batch마다 파일 생성	OPTIMIZE 수동 실행 + Auto Optimize (Databricks 전용)	낮음 (OSS) / 높음 (Databricks)
Iceberg	스냅샷 기반 쓰기로 파일 누적	rewrite_data_files 수동 트리거	낮음
Hudi	MOR log 파일 누적	파일 그룹 단위 비동기 compaction (writer와 독립)	중간
Paimon	스트리밍 flush마다 소규모 SST 파일 생성	LSM compaction이 Flink 파이프라인 내 상시 자동 실행	높음
DuckLake	소량 변경	Data Inlining (SQL DB에 직접 저장 후 CHECKPOINT)	원천 회피

데이터 레이아웃 최적화 (클러스터링)

포맷 알고리즘 자동화 비고

Delta Lake	Hilbert Curve (Liquid Clustering)	Databricks 전용 Auto	Z-ORDER는 레거시
Iceberg	Z-order	수동	Hilbert Curve 미지원 (2026 기준)
Hudi	Linear Sort, Z-order, Hilbert Curve 모두	인라인 또는 비동기	알고리즘 선택 폭 가장 넓음
Paimon	Primary Key 기준 자동 정렬 (LSM)	자동	별도 clustering 명령 불필요

동시 다중 Writer 지원

포맷 메커니즘 특이사항

Iceberg	OCC — metadata.json atomic swap	충돌 시 rollback + retry
Delta Lake	OCC + 비겹침 파일 변경 동시 허용	Coordinated Commits (4.0)로 클라우드 환경 보강
Hudi	OCC + NBCC (1.0)	TrueTime 기반 completion-time ordering. 명시적 락 없이 여러 writer 동시 진행
Paimon	Snapshot isolation + 버킷 레벨 writer 제한	DV 모드에서 버킷 내 병렬 읽기 가능

Hudi NBCC 가장 유리 — 대규모 스트리밍 upsert 파이프라인에서 lock contention 없이 다중 writer 동시 실행

오픈소스 거버넌스 & 벤더 독립성

포맷 거버넌스 실질 주도 벤더 독립성

Apache Iceberg	Apache Software Foundation	Netflix, Apple, AWS, Snowflake 등 30개+ 기업 공동	최고 — 클라우드 3사 모두 네이티브 지원
Apache Hudi	Apache Software Foundation	Onehouse(구 Uber 팀) 주도	높음
Apache Paimon	Apache Software Foundation	Alibaba/Ververica 주도	중간 (Flink 의존성)
Delta Lake	Linux Foundation	Databricks 코드 기여 대부분	중간 — OSS에 없는 Databricks 전용 기능 다수
DuckLake	DuckDB Labs	DuckDB Labs	중간 (DuckDB 의존)

Delta Lake Databricks 전용 기능 (OSS에 없음): Auto Optimize · Auto Loader · Bloom Filter Index · Primary Key 제약

카탈로그 Federation & 글로벌 메타데이터 서비스

서비스 역할 지원 포맷

Apache Gravitino	"Catalog of Catalogs" — Hive, Iceberg REST, Kafka Schema Registry 통합	Delta, Iceberg, Hudi, Paimon 1등급 목표
Project Nessie	Git 스타일 브랜치/태그, 멀티 테이블 트랜잭션	Iceberg 주력
Apache Polaris	Iceberg REST 표준 구현	Iceberg 중심
Unity Catalog	Delta 네이티브 + 외부 Iceberg 테이블 지원. RLS/Column Masking	Delta 네이티브
AWS Lake Formation	Tag 기반 ABAC, 행/열 수준 접근 제어	Iceberg, Delta

멀티 테이블 트랜잭션: 포맷 자체 스펙에는 없음. Project Nessie + Iceberg가 현재 가장 성숙한 크로스 테이블 원자 커밋 솔루션입니다. (Branch → 여러 테이블 변경 → Merge 패턴)

카탈로그 의존성 핵심 차이

1. Iceberg — 카탈로그가 필수인 이유

[카탈로그 없이]
  v1.metadata.json  ← 구버전?
  v2.metadata.json  ← 최신 버전? 어느 것이 현재인지 알 수 없음
  v3.metadata.json  ← 충돌로 중복 생성?

[카탈로그 있을 때]
  Catalog: orders → v2.metadata.json  ← 원자적 CAS로 관리되는 단일 진실 공급원

2. Delta Lake — 카탈로그 없이 동작 가능한 이유

_delta_log/
  00000000000000000000.json  # 버전 0
  00000000000000000001.json  # 버전 1
  00000000000000000010.parquet  # 체크포인트
  _last_checkpoint  # "최신 체크포인트는 버전 10" 명시

→ 파일 번호 자체가 순서를 보장, 별도 포인터 불필요

3. Hudi — Delta Lake와 유사

.hoodie/
  20250101000000.commit   # 완료됨
  20250101000100.commit   # 완료됨
  20250101000200.inflight # 진행 중

→ 파일명 자체가 순서 표현, inflight/completed로 원자성 보장
→ HMS에 스키마 싱크하지만 테이블 자체는 독립 동작 가능

4. Paimon — FilesystemCatalog로 외부 서비스 없이 동작

FilesystemCatalog:
  파일시스템 내 파일의 어휘 정렬로 최신 스냅샷 파악
  → Iceberg의 Hadoop Catalog와 유사한 개념
  → 외부 서비스 없이 동작 가능

5. DuckLake — SQL DB가 카탈로그 자체

SQL DB (SQLite / PostgreSQL):
  테이블명 → 스냅샷 ID → 파일 목록 매핑 모두 SQL 테이블로 관리
  → SQL ACID 트랜잭션으로 원자성 보장
  → 외부 파일 기반 카탈로그 불필요

6. Fluss — 자체 분산 카탈로그 (CoordinatorServer + ZooKeeper)

CoordinatorServer + ZooKeeper (자체 분산 카탈로그):
  테이블 메타데이터, Tablet 위치, Tiering 상태를 직접 관리
  → Hive/Glue/Polaris 같은 파일 기반 카탈로그와 전혀 다른 모델
  → Flink Job이 CoordinatorServer에 직접 연결하여 메타데이터 조회
  → Tiering 시 Iceberg/Paimon 카탈로그에 메타데이터 자동 등록
  → 서버 클러스터가 카탈로그 역할 통합 (ZooKeeper 향후 KvStore로 대체 예정)

포맷 혼합 사용 아키텍처 패턴

단일 포맷보다 두 가지 포맷을 역할에 따라 분리해 사용하는 패턴이 2024~2025년부터 급증하고 있습니다. 실시간 수집의 강점과 배치 분석 생태계를 동시에 활용하는 것이 핵심 동기입니다.

혼합 패턴 비교

혼합 패턴 주요 채택 기업 핵심 동기 브리징 수단 운영 복잡도

Paimon + Iceberg	알리바바, ByteDance, Bondex	Flink 실시간 + 멀티엔진 분석	Paimon Iceberg 호환 스냅샷 (네이티브)	중간
Hudi + Iceberg	Uber, Robinhood, Onehouse	CDC/Upsert + 다중 엔진 분석	Apache XTable (양방향 변환)	중간
Delta + Iceberg	Capital One, Databricks	Spark 최적화 + 멀티클라우드	Delta UniForm (단방향)	낮음~중간
Fluss + Paimon + Iceberg	알리바바/Ververica	핫-웜-콜드 3계층 Streamhouse	Flink SQL Union Read	높음
DuckLake + Iceberg	MotherDuck 생태계	로컬 처리 + 중앙 공유 분석	Iceberg 메타데이터 임포트	낮음

1. Paimon + Iceberg — 가장 주목받는 조합

실제 사례: 알리바바(Taobao/Tmall, 수백 PB), ByteDance/TikTok, Bondex, StreamNative

각 포맷의 강점이 명확하게 분리됩니다.

역할 Paimon Iceberg

설계 철학	스트리밍 우선, LSM Tree	배치 분석 우선, 불변 스냅샷
갱신 방식	초단위 CDC/Upsert (LSM 흡수)	Copy-on-Write (배치 최적화)
Flink 통합	네이티브 1급 지원	커넥터 수준
분석 생태계	성장 중	Spark, Trino, Snowflake, BigQuery 폭넓게 지원

데이터 흐름:

Kafka / Flink CDC
        │
        ▼
[Flink + Paimon]  ─── 실시간 수집 레이어 (초~분 단위 freshness)
   LSM Tree              ├── Lookup Join / 실시간 OLAP (StarRocks, Doris)
   Changelog Producer    └── Flink SQL 집계 / 대시보드
        │
        │ Paimon Iceberg 호환 스냅샷 자동 생성
        │ (metadata.iceberg.storage = 'rest-catalog')
        ▼
[Iceberg REST Catalog]  ─── 배치 분석 레이어 (시간~일 단위)
   불변 스냅샷                 ├── Spark 대용량 배치 집계
   Time Travel                ├── Trino / Athena 다중 엔진
   Hidden Partitioning        └── Snowflake / BigQuery 분석 서비스

브리징 메커니즘: Paimon 테이블에 metadata.iceberg.storage = 'rest-catalog' 설정 시 쓰기 커밋마다 Iceberg 메타데이터를 REST Catalog에 자동 등록합니다. Iceberg 클라이언트는 동일 Parquet 파일을 Iceberg 테이블로 인식합니다.

주의사항:

기존 대형 테이블은 신규 커밋 전까지 Iceberg 클라이언트에 비가시 (lazy generation)
Paimon 메타데이터 + Iceberg 메타데이터 이중 유지 필요
LSM compaction 타이밍과 Iceberg 스냅샷 생성 타이밍 별도 튜닝 필요

2. Hudi + Iceberg — CDC 특화 수집 + 멀티엔진 분석

실제 사례: Uber(Hudi 창시, CDC 수집), Robinhood(Kafka→Hudi→Iceberg), Onehouse(XTable 기반 다중 포맷)

데이터 흐름:

MySQL / PostgreSQL / MongoDB
        │ (Debezium CDC)
        ▼
    Kafka Topics
        │ (Hudi DeltaStreamer)
        ▼
[Hudi MOR Tables]  ─── 수집 레이어 (분 단위 freshness)
   Record-level Upsert      ├── 실시간 조회 (Read Optimized View)
   NBCC 다중 Writer          ├── CDC 히스토리 보존
   이벤트 타임 정렬          └── 증분 처리 파이프라인
        │
        │ Apache XTable (메타데이터 양방향 변환)
        │ (실제 Parquet 파일 복사 없음)
        ▼
[Iceberg Tables]  ─── 분석 레이어
   COW 최적화                 ├── Spark 대용량 배치 분석
   파티션 진화                ├── Trino / Presto OLAP
   Time Travel               ├── Snowflake / BigQuery 외부 테이블
                             └── Dremio 셀프서비스 분석

Apache XTable 브리징: 소스 포맷의 메타데이터를 읽어 타겟 포맷의 메타데이터를 재생성합니다. Parquet 데이터 파일은 복사 없이 메타데이터만 변환됩니다. Hudi ↔ Iceberg ↔ Delta 3방향 양방향 지원합니다.

Delta UniForm과의 차이: Delta UniForm은 Delta → Iceberg 단방향이며 Databricks 종속. XTable은 완전 양방향, 벤더 중립입니다.

3. Delta + Iceberg — Spark 최적화 + 멀티클라우드

실제 사례: Capital One(Lakehouse Convergence 패턴 공개), Databricks(2024년 Tabular 인수 후 Unity Catalog에서 Delta+Iceberg 동시 지원)

데이터 흐름:

Spark Structured Streaming / Batch
        │
        ▼
[Delta Lake]  ─── Spark 처리 레이어
   _delta_log/           ├── ETL/ELT 변환 (Databricks)
   Auto-Optimize         ├── ML/AI 워크플로우
   ACID 트랜잭션          └── Delta Live Tables
        │
        │ Delta UniForm (Delta 커밋 시 Iceberg 메타데이터 자동 생성)
        │ 또는 Apache XTable (양방향 변환)
        ▼
[Iceberg 메타데이터 레이어]  ─── 멀티엔진 분석
   (동일 Parquet 파일 공유)      ├── AWS Athena / Glue
   Time Travel                  ├── Snowflake External Tables
   Partition Pruning            ├── Google BigQuery Iceberg
                                └── Trino / Dremio

주의사항: Delta UniForm은 단방향(Delta → Iceberg 읽기 전용). Iceberg 엔진에서 쓰기 불가. 최적 경험을 위해 Unity Catalog 의존성이 생깁니다.

4. Streamhouse: Fluss + Paimon + Iceberg (핫-웜-콜드 3계층)

실제 사례: 알리바바/Ververica — "From Kappa Architecture to Streamhouse" (2025)

2025년 주목받는 신규 아키텍처 패턴입니다. 단순 레이크하우스를 넘어 실시간 스트리밍과 배치 분석을 통합하는 Streamhouse 개념을 구현합니다.

데이터 소스 → Kafka
        │
        ▼
[핫 레이어: Fluss]  ─── 초~분 단위 freshness
   스트리밍 스토리지       ├── Flink 실시간 처리
   Changelog 네이티브     ├── 실시간 집계/조인
   낮은 레이턴시           └── 이벤트 시간 처리
        │ (Fluss → Paimon 자동 싱크)
        ▼
[웜 레이어: Paimon]  ─── 분~시간 단위 freshness
   LSM Tree 갱신          ├── OLAP 엔진 쿼리 (Doris, StarRocks)
   Iceberg 호환 스냅샷    ├── Flink Lookup Join
   배치 처리 가능          └── 중기 데이터 보존
        │ (Paimon Iceberg 호환 스냅샷)
        ▼
[콜드 레이어: Iceberg]  ─── 시간~일 단위 freshness
   불변 스냅샷              ├── Spark 대용량 배치
   멀티엔진 접근           ├── Trino / Athena
   장기 보존               └── Snowflake / BigQuery

Flink SQL에서 UNION ALL로 핫·웜·콜드 레이어를 통합 쿼리합니다.

메달리온 아키텍처에서의 레이어별 포맷 전략

2024~2025년 기준 메달리온 아키텍처(Bronze → Silver → Gold)에서 레이어별 포맷을 달리 사용하는 패턴이 증가하고 있습니다.

┌──────────────────────────────────────────────────────────┐
│  Gold Layer (비즈니스 집계, BI/분석 소비 준비)            │
│  → Iceberg 또는 Delta  (멀티엔진, BI 도구 연동)          │
│  → 소규모 고활용 테이블, 파티션 최적화                   │
├──────────────────────────────────────────────────────────┤
│  Silver Layer (정제, 표준화, 도메인 모델)                 │
│  → Iceberg  (스키마 진화, Time Travel, 검증)             │
│  → Hudi  (CDC 소스의 경우 Upsert 정합성 유지)            │
├──────────────────────────────────────────────────────────┤
│  Bronze Layer (원시 데이터, 수집 즉시 저장)               │
│  → Paimon  (Flink 실시간 수집, 초단위 갱신)              │
│  → Hudi MOR  (CDC 소스, 고처리량 upsert)                 │
│  → Iceberg  (단순 Append-only, S3 Tables)                │
└──────────────────────────────────────────────────────────┘

2025년 주류 구현 패턴 4가지:

패턴 Bronze Silver/Gold 브리징 적합 조직

A. Hudi → Iceberg	Hudi MOR (CDC/Upsert)	Iceberg (Spark 정제 + 집계)	XTable 변환	CDC 중심, 멀티엔진 필요
B. Paimon → Iceberg	Paimon (Flink 실시간)	Iceberg (Spark 정제 + 집계)	Iceberg 호환 스냅샷	Flink 중심 조직
C. Delta 단일 + UniForm	Delta (Spark Streaming)	Delta (Spark 처리)	Gold에만 UniForm 적용	Databricks 전용 환경
D. Iceberg 단일 포맷	Iceberg (Append-only)	Iceberg (Spark/Flink 정제)	불필요	멀티클라우드, 벤더 중립 우선

2025년 트렌드: AWS S3 Tables · Snowflake · Google BigQuery · Azure 모두 Iceberg 네이티브 지원으로, Silver/Gold는 Iceberg로 통일하고 Bronze만 수집 특성에 맞는 포맷(Hudi/Paimon)을 쓰는 패턴이 급증하고 있습니다.

사용 사례별 선택 가이드

사용 사례 권장 포맷 이유

Databricks 기반 배치 ETL	Delta Lake	가장 깊은 Databricks 통합, Unity Catalog
멀티 엔진 (Spark + Trino + Flink + Snowflake)	Apache Iceberg	최고 수준 엔진 호환성, REST Catalog 표준, 벤더 중립
고빈도 CDC/Upsert 파이프라인	Apache Hudi	Record-level upsert 특화, NBCC 다중 Writer
Flink 기반 실시간 스트리밍	Apache Paimon	스트리밍 네이티브, 100ms 미만 레이턴시, Flink 네이티브
DuckDB 중심 소규모 분석	DuckLake	운영 단순성, SQL DB 기반 메타데이터, Data Inlining
Snowflake/BigQuery 연동	Apache Iceberg	Snowflake Iceberg Tables, BigQuery BigLake
실시간 집계/부분 업데이트	Apache Paimon	Partial Update Merge Engine, Aggregation Engine
멀티 테이블 원자 트랜잭션	Iceberg + Nessie	현재 유일하게 성숙한 크로스 테이블 원자 커밋
포맷 혼용 환경 상호운용	Apache XTable	데이터 복사 없이 포맷 간 메타데이터 변환
동시 다중 스트리밍 Writer	Apache Hudi (NBCC)	락 없는 다중 writer 동시 실행
벤더 독립성 최우선	Apache Iceberg	ASF 30개+ 기업 공동 거버넌스, 클라우드 3사 네이티브
sub-second freshness + Flink Lookup Join + CDC 핫 경로	Apache Fluss	PK Table 500K QPS 포인트 룩업, Flink 차원 테이블 외부화, A/B 카운터 — Paimon/Iceberg Tiering으로 배치 쿼리까지 자동 연동
실시간 수집 + 배치 멀티엔진 동시 필요	Paimon + Iceberg 혼합	Flink 실시간 수집은 Paimon, 멀티엔진 분석은 Iceberg — Iceberg 호환 스냅샷으로 무복사 브리징
CDC 수집 + 장기 대용량 배치	Hudi(Bronze) + Iceberg(Silver/Gold)	CDC/Upsert는 Hudi MOR, 정제·집계는 Iceberg — XTable로 메타데이터 변환
Databricks Spark + 멀티클라우드 분석	Delta + Iceberg (UniForm)	Delta 단일 쓰기, UniForm으로 Iceberg 메타데이터 자동 생성 — Snowflake/Athena 직접 읽기
Flink 실시간 스트리밍 + 장기 마이크로배치	Fluss + Paimon + Iceberg	핫(Fluss) → 웜(Paimon) → 콜드(Iceberg) 3계층 Streamhouse — Flink SQL Union Read 통합

참고 자료

저작자표시 (새창열림)

ABOUT ME

레이크하우스 오픈 테이블 포맷 완전 비교

레이크하우스란?

전통 2계층 아키텍처의 문제

오픈 테이블 포맷이 해결하는 문제

포맷 분류 체계

핵심 비교 요약

전통 파일 기반 포맷

1. Delta Lake

메타데이터 구조: _delta_log/

카탈로그 아키텍처

ACID 트랜잭션

Deletion Vector (DV)

주요 기능

단점 & 주의사항

2. Apache Iceberg

카탈로그가 필수인 이유

메타데이터 4계층 구조

여러 버전 메타데이터 파일 관리

3단계 프루닝 메커니즘

ACID 트랜잭션: Snapshot Isolation + OCC

Deletion Vector (Iceberg v3, 2025 GA)

주요 기능

단점

3. Apache Hudi

메타데이터 구조: .hoodie/ Timeline

카탈로그 아키텍처

테이블 타입: COW vs MOR

ACID 트랜잭션: NBCC (Hudi 1.0의 핵심)

Upsert 특화: Record-Level Index

Clustering 알고리즘

주요 기능

단점

4. Apache Paimon

메타데이터 구조: 이중 Manifest List

카탈로그 아키텍처

LSM Tree 기반 저장

Flink 통합 및 스트리밍 차별점

Iceberg 호환성

Small File 자동화

단점

SQL DB 기반 포맷

5. DuckLake

배경

핵심 아이디어: SQL DB가 카탈로그 + 메타데이터

Data Inlining: Small File 문제 원천 해소

메타데이터 규모

지원 클라이언트

단점 & 주의사항

적합한 케이스

스트리밍 스토리지 레이어 (Hot Tier)

6. Apache Fluss

배경 및 거버넌스

클러스터 아키텍처

데이터 포맷 이중 구조

테이블 타입

Union Read — 핫·콜드 통합 쿼리

엔진 지원

Fluss vs Paimon vs Kafka 비교

카탈로그 아키텍처

단점 & 주의사항

적합한 케이스

상호운용 레이어

Apache XTable (구 OneTable)

Delta UniForm과의 차이

적합한 케이스

심화 비교

Deletion Vector 구현 방식 비교

Small File 문제 해결 전략

데이터 레이아웃 최적화 (클러스터링)

동시 다중 Writer 지원

오픈소스 거버넌스 & 벤더 독립성

카탈로그 Federation & 글로벌 메타데이터 서비스

카탈로그 의존성 핵심 차이

1. Iceberg — 카탈로그가 필수인 이유

2. Delta Lake — 카탈로그 없이 동작 가능한 이유

3. Hudi — Delta Lake와 유사

4. Paimon — FilesystemCatalog로 외부 서비스 없이 동작

5. DuckLake — SQL DB가 카탈로그 자체

6. Fluss — 자체 분산 카탈로그 (CoordinatorServer + ZooKeeper)