데이터 레이크하우스 & 모던 데이터 엔지니어링 2026 — Iceberg / Delta / Hudi / Paimon / Tabular (Databricks 인수) / Trino / Spark 4 / Flink 2 / DataFusion 심층 가이드

프롤로그 — "데이터 웨어하우스"라는 단어가 늙어버린 자리

2010년대 초반, "데이터를 어디에 두느냐"는 단순했다. 정형 데이터는 데이터 웨어하우스(Teradata·Oracle Exadata·Vertica), 로그·반정형 데이터는 Hadoop HDFS에 던졌다. 그 사이의 다리는 ETL 도구(Informatica·Talend)가 놓았고, 분석가는 SQL을, 데이터 엔지니어는 MapReduce·Spark를 썼다.

2026년의 풍경은 완전히 다르다.

레이크하우스가 표준이 되었다. S3·GCS·ADLS 위에 Parquet 파일을 두고, Apache Iceberg 같은 테이블 포맷이 그 위에 트랜잭션·스키마·타임 트래블을 얹는다. "레이크"의 유연함과 "웨어하우스"의 신뢰성을 한 지붕 아래에서 얻는다.
Apache Iceberg가 2024-25년 테이블 포맷 전쟁의 사실상 승자로 떠올랐다. Netflix가 만들었고 Apple·LinkedIn·Stripe·Airbnb가 합류했으며, AWS·Snowflake·Cloudera·Dremio가 일급 시민으로 지원한다.
Databricks가 2024년 6월 Tabular를 $1B 이상에 인수했다. Iceberg 공동 창시자 Ryan Blue를 데려와, "Delta Lake와 Iceberg를 같은 메타데이터로 본다"는 UniForm 전략을 가속했다.
Apache Hudi(Uber 출신) 는 Onehouse라는 상용 회사로 살아남았다. niche하지만 CDC·인덱싱·증분 처리에서는 여전히 가장 단단하다.
Apache Paimon(Flink 팀) 은 "스트리밍 레이크하우스"라는 새 카테고리를 들고 등장했다. LSM 트리 기반으로 실시간 업데이트와 분석을 같은 테이블에서 처리한다.
쿼리 엔진은 갈수록 다양해졌다. Trino(구 PrestoSQL)가 분산 OLAP의 표준이 되었고, DuckDB가 "Analytics용 SQLite"로 단일 노드의 거의 모든 분석 문제를 잡고, ClickHouse Cloud가 실시간 OLAP을 가져가고, Apache DataFusion(Rust)이 차세대 임베디드 SQL 엔진의 자리를 노린다.
dbt가 SQL 변환의 표준이 되었다. 분석 엔지니어링이라는 직군이 생겼다.

이 글은 그 풍경을 — 테이블 포맷 3대장(Iceberg·Delta·Hudi)과 도전자 Paimon, 엔진(Spark 4·Flink 2·Trino·DuckDB), 클라우드 데이터 플랫폼(Databricks·Snowflake·BigQuery·ClickHouse), 그리고 한국·일본 회사들의 실제 구성까지 — 한 호흡으로 정리한다.

1장 · 2026년 데이터 레이크하우스 지도 — 3개의 축

먼저 그림 한 장으로 시작하자. 2026년의 데이터 레이크하우스는 3개의 직교 축으로 이해할 수 있다.

                        [ 카탈로그 / 거버넌스 ]
                  Unity Catalog · Polaris · BigLake
                   Glue · Nessie · Snowflake Horizon
                                |
                                |
   [ 처리 / 쿼리 엔진 ] --------+--------- [ 테이블 포맷 / 스토리지 ]
   Spark 4 · Flink 2 · Trino   |          Iceberg · Delta · Hudi · Paimon
   Presto · DuckDB             |          Parquet · ORC · Avro
   ClickHouse · DataFusion     |          S3 · GCS · ADLS
                                |
                                |
                       [ 변환 / 오케스트레이션 ]
                       dbt · SQLMesh · Coalesce
                       Airflow · Dagster · Prefect

테이블 포맷 — Parquet 파일들 위에 트랜잭션·스키마·메타데이터를 입힌다. Iceberg가 표준이 되고, Delta는 Databricks 진영, Hudi는 niche, Paimon은 스트리밍.
엔진 — 그 데이터를 읽고 쓰고 변환한다. Spark는 ETL·배치, Flink는 스트리밍, Trino는 분산 OLAP, DuckDB는 단일 노드 OLAP.
카탈로그 — 테이블·스키마·권한을 관리한다. 2025년 들어 가장 뜨거워진 영역. Unity Catalog(Databricks가 오픈 소스화), Polaris(Snowflake·Iceberg REST 기준 구현), BigLake(GCP), Nessie(Project Nessie).

이 세 축이 분리될 수 있다는 게 레이크하우스의 핵심이다. 테이블 포맷은 Iceberg를 쓰면서, 엔진은 Spark/Trino/DuckDB를 골라 쓰고, 카탈로그는 Unity를 쓴다 같은 조합이 자연스러워졌다.

전통 웨어하우스(Snowflake·BigQuery)는 이 세 축이 모두 한 회사 안에 잠겨 있었다. 레이크하우스는 그 잠금을 푼다. 그래서 Snowflake도 Polaris를 만들었고, BigQuery도 BigLake로 외부 Iceberg를 읽도록 했다. 잠금을 푼다는 것 자체가 2026년의 기본값이 되었다.

2장 · Apache Iceberg — 테이블 포맷 전쟁의 승자

2.1 왜 "테이블 포맷"이라는 게 필요한가

Parquet 파일은 좋다. 컬럼형, 압축, 통계 푸시다운. 하지만 그것만으로는 부족하다.

1만 개 Parquet 파일이 들어 있는 "테이블"에서 한 컬럼을 추가하면? 스키마 변경을 어떻게 기록하나.
두 개의 잡(job)이 같은 테이블에 동시에 쓰면 어떻게 되나. ACID는?
어제의 상태를 보고 싶으면? 타임 트래블은?
100억 행 중 100만 행만 업데이트해야 한다면? 파일 단위 덮어쓰기 말고 다른 길이 있나?

테이블 포맷은 이걸 푸는 메타데이터 레이어다. Parquet 파일들 위에 "이 테이블의 현재 스냅샷은 X, 스키마는 Y, 다음 트랜잭션은 Z" 같은 정보를 JSON·Avro 파일로 들고 있다.

Iceberg·Delta·Hudi가 모두 이 문제를 푸는 서로 다른 방식이다.

2.2 Iceberg의 데이터 모델

Iceberg는 3단 계층의 메타데이터를 갖는다.

   [ Catalog ] ─ 카탈로그 (Glue·Nessie·Polaris·REST)
        |
        v
   [ Metadata file v0.json, v1.json ... ]
        |
        v
   [ Snapshot ] ─── 특정 시점의 테이블 상태
        |
        v
   [ Manifest list ]
        |
        v
   [ Manifest ]  ─ 어떤 데이터 파일이 어디에 있고 통계가 무엇인지
        |
        v
   [ Data files (Parquet/ORC/Avro) ]

핵심 아이디어:

스냅샷 기반. 모든 쓰기는 새 스냅샷을 만든다. 옛 스냅샷은 지우기 전까지 살아 있다 → 타임 트래블·롤백 공짜.
메타데이터가 메타데이터를 가리킨다. 카탈로그는 "현재 metadata file이 어디 있냐"만 안다. 그 안에 스냅샷 목록이, 그 안에 manifest list가, 그 안에 manifest가, 그 안에 데이터 파일이 있다.
파티션은 숨겨진다. 사용자는 event_time 컬럼만 쓰고, Iceberg가 내부적으로 day(event_time) 같은 파티션을 관리한다. 파티션 evolution이 가능하다.

2.3 Iceberg가 이긴 이유

2023년만 해도 "Iceberg vs Delta vs Hudi"는 정말로 경쟁이었다. 2025년 말 시점, 산업의 무게중심은 명확하게 Iceberg로 기울었다. 이유는 단 하나의 문장으로 요약된다.

Iceberg는 표준이고, Delta는 제품이다.

벤더 중립. Netflix가 만들었고 Apache로 기증했다. Databricks·Snowflake·AWS·GCP·Cloudera·Dremio·Tabular 모두 일급으로 지원한다.
REST 카탈로그 표준. 2024년 Iceberg REST Catalog 스펙이 안정화되면서, "어느 회사의 카탈로그든 같은 API로 말할 수 있다"가 가능해졌다.
클라우드 벤더 락인 해결. Snowflake에서 쓰던 테이블을 그대로 Databricks·Trino·Spark에서 읽을 수 있다. "데이터를 옮기지 않고 엔진만 바꾼다"가 진짜가 되었다.
Tabular의 인수. Databricks가 $1B+에 산 사건이 결정타였다. "Delta의 회사가 Iceberg의 창시자를 산다"는 것 자체가 시장에 보낸 신호가 컸다.

2024년 6월 Snowflake가 Polaris Catalog를 만들고 2025년 Apache에 기증한 것, AWS S3 Tables(2024년 12월)가 Iceberg를 일급으로 지원하는 것 — 모두 같은 흐름이다.

2.4 Iceberg를 직접 써보기 — PyIceberg

PyIceberg(Python 네이티브 Iceberg 클라이언트)로 가장 작은 예제.

from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import LongType, StringType, TimestampType, NestedField

# 1. 카탈로그 로드 (Glue·REST·SQL·Hive 다 지원)
catalog = load_catalog(
    "my_catalog",
    **{
        "type": "rest",
        "uri": "http://localhost:8181",
        "warehouse": "s3://my-bucket/warehouse",
    }
)

# 2. 스키마 정의
schema = Schema(
    NestedField(1, "event_id", LongType(), required=True),
    NestedField(2, "user_id", StringType()),
    NestedField(3, "event_time", TimestampType()),
    NestedField(4, "event_type", StringType()),
)

# 3. 테이블 생성
table = catalog.create_table(
    identifier="analytics.events",
    schema=schema,
    partition_spec=...  # day(event_time)
)

# 4. 데이터 추가 (Arrow Table로)
import pyarrow as pa
data = pa.table({
    "event_id": [1, 2, 3],
    "user_id": ["u1", "u2", "u3"],
    "event_time": [...],
    "event_type": ["click", "view", "purchase"],
})
table.append(data)

# 5. 읽기 (스캔)
result = table.scan(
    row_filter="event_type == 'purchase'",
    selected_fields=("event_id", "user_id"),
).to_pandas()

# 6. 타임 트래블
old_snapshot = table.history()[-2].snapshot_id
old_data = table.scan(snapshot_id=old_snapshot).to_pandas()

이게 다다. 분산 클러스터 없이, Python 한 줄로 Iceberg 테이블을 만들고 읽고 시점 조회까지 한다. Iceberg는 "엔진"이 아니라 "스펙"이라는 게 여기서 드러난다.

3장 · Delta Lake (Databricks) — 여전히 강한 경쟁자

3.1 Delta는 무엇이 다른가

Delta Lake는 2019년 Databricks가 오픈 소스로 공개한 테이블 포맷이다. 본질은 Iceberg와 같다: Parquet 파일들 위에 트랜잭션 로그를 얹어 ACID·타임 트래블·스키마 관리를 제공한다. 다른 점은 메타데이터 구조와 생태계다.

   [ Delta Table ]
        |
        v
   _delta_log/
       00000000000000000000.json   ← 트랜잭션 로그 (한 줄씩 JSON)
       00000000000000000001.json
       ...
       00000000000000000010.checkpoint.parquet
       _last_checkpoint
        |
        v
   data files (Parquet)

트랜잭션 로그가 JSON. 10개 로그마다 체크포인트(Parquet)로 압축. Iceberg가 metadata→snapshot→manifest의 트리라면, Delta는 평평한 로그 시퀀스다.
Databricks 생태계와 깊게 결합. Liquid Clustering, Predictive I/O, Photon — 가장 성숙한 최적화는 Databricks 안에 있다.
Delta Sharing. 데이터를 복사하지 않고 다른 조직에 공유하는 오픈 프로토콜. Iceberg에는 아직 동급의 표준이 없다.

3.2 UniForm — Delta가 Iceberg를 흉내내다

2023년 Databricks가 발표한 Delta UniForm은 시장이 어디로 가는지 보여준 사건이었다.

같은 Parquet 파일을 두고, Delta 로그와 Iceberg 메타데이터를 동시에 쓴다. 외부에서 보면 "그 테이블은 Iceberg 테이블이기도 하다."

Snowflake·Trino·BigQuery에서 Iceberg로 읽고, Databricks 안에서는 Delta로 쓰는 게 가능해진다. "Delta 진영"이라는 진영이 무의미해지는 길을 Databricks가 스스로 열었다.

2024년 6월 Tabular 인수 이후 이 전략은 더 진해졌다. 2025년에는 "Delta와 Iceberg를 별도 포맷으로 다루지 말고 같은 메타데이터로 보자"는 방향이 굳어졌다.

3.3 그래도 Delta가 살아남는 이유

Databricks 안에서는 Delta가 더 빠르다. Liquid Clustering, Predictive I/O, Photon 같은 최적화는 Delta 전용이 많다.
Spark Structured Streaming과의 통합. Delta가 가장 자연스럽다.
Delta Sharing. 데이터 공유 표준으로 자리잡았다.

요약하면: "Iceberg가 표준이 된 세계에서, Delta는 Databricks의 내부 최적화 포맷으로 자리잡았다." 이게 2026년의 그림이다.

4장 · Apache Hudi (Uber) — niche한 매력

4.1 Hudi의 정체성

Hudi는 2016년 Uber가 만들고 2019년 Apache로 기증한 테이블 포맷이다. "upsert-first" 가 정체성이다.

처음부터 "데이터 레이크에 어떻게 자주 업데이트를 적용할까"를 풀었다. CDC(Change Data Capture)로 들어오는 변경을 분 단위로 반영해야 했던 Uber의 요구가 그 출발점이었다.

   Hudi 테이블의 두 가지 스토리지 타입
   
   [Copy-on-Write (CoW)]
     쓰기: 영향받은 Parquet 파일 전체를 다시 쓴다
     읽기: 빠르다 (그냥 Parquet)
     적합: 읽기가 많고 쓰기가 드문 분석
   
   [Merge-on-Read (MoR)]
     쓰기: 변경분을 별도 로그 파일(Avro)에 쌓는다
     읽기: Parquet + 로그를 머지 (실시간 뷰)
     적합: 빈번한 업데이트·삭제 (CDC)

4.2 Hudi의 강점 — 인덱싱과 증분 쿼리

Iceberg·Delta가 못 따라가는 두 가지가 있다.

레코드 레벨 인덱스. Bloom filter, HBase, bucket index 등으로 "이 user_id가 어느 파일에 있나"를 즉시 찾는다. upsert가 빠른 근본 이유.
증분 쿼리(Incremental Query). "이 커밋 이후 바뀐 행만 달라" 같은 쿼리를 일급으로 지원한다. CDC 파이프라인의 다운스트림에 그대로 꽂힌다.

이 두 가지는 Iceberg가 v3 명세에서 따라잡으려고 하는 영역이다. Iceberg v3는 row-level deletes·equality deletes·merge-on-read를 강화하고 있고, 2026년에 따라잡을 가능성이 높다. 그래서 Hudi는 "niche한 강자"의 자리를 지키는 중이다.

4.3 Onehouse — Hudi의 상용 길

Hudi 공동 창시자 Vinoth Chandar가 2021년 만든 회사. "Universal Data Lakehouse" 라는 캐치프레이즈로 Hudi·Iceberg·Delta를 모두 다루는 매니지드 서비스를 판다. Hudi 회사가 Hudi만 팔지 않는다는 점이 흥미롭다.

2024-25년 Onehouse가 푼 두 도구가 의미가 컸다.

Apache XTable(구 OneTable). Hudi·Iceberg·Delta 사이의 메타데이터 변환을 한다. 같은 Parquet을 세 포맷의 메타데이터로 동시에 노출. UniForm의 오픈 버전.
Open Engines. Hudi의 인덱싱·증분 처리를 다른 포맷에도 적용할 수 있는 엔진층.

5장 · Apache Paimon (Flink team) — 새로운 도전자

5.1 왜 또 새로운 테이블 포맷인가

Iceberg·Delta·Hudi 모두 출발이 "배치 분석"이다. 스트리밍은 그 위에 얹어 쓰는 식이었다.

Paimon은 출발이 "스트리밍"이다. Apache Flink 팀에서 2022년에 시작해 2024년 Apache Top Level Project로 졸업했다. 핵심 차이는 LSM 트리(Log-Structured Merge Tree)다.

   Paimon = "LSM 트리 위에 만든 테이블 포맷"
   
   - LevelDB·RocksDB가 쓰는 그 구조
   - 메모리 → L0 → L1 → L2 ... 점진적 머지
   - 빠른 쓰기 + 효율적인 읽기 + 자연스러운 컴팩션
   - Flink의 체크포인트와 자연스럽게 결합

5.2 Paimon이 푸는 문제

실시간 머티리얼라이즈드 뷰. Flink로 만든 집계를 Paimon 테이블에 넣고, Trino·Spark로 즉시 읽는다.
Streaming CDC. Debezium에서 받은 CDC 이벤트를 Paimon 테이블에 분 단위로 반영. Iceberg보다 자연스럽다.
Lookup Join. Flink 잡 안에서 Paimon 테이블을 lookup table로 쓴다. Kafka Streams의 GlobalKTable 같은 역할.

2025년 시점, Paimon은 중국 알리바바·바이트댄스 안에서 가장 많이 쓰이고 서구권으로 확산 중이다. Iceberg가 배치의 표준이라면, Paimon은 "스트리밍 레이크하우스"의 표준 자리를 노린다.

5.3 Iceberg와 Paimon은 경쟁인가, 보완인가

지금까지의 흐름을 보면 보완에 가깝다.

Iceberg: 거대한 분석 테이블, 스냅샷 기반, 시간 트래블.
Paimon: 스트리밍 인입, 잦은 업데이트, 머티리얼라이즈드 뷰.

2026년에는 두 포맷을 같은 데이터 플랫폼 안에 함께 두는 구성이 표준이 될 것이다. Flink가 Paimon에 쓰고, 큐브·집계가 만들어지면 Iceberg로 굳히는 식.

6장 · Tabular 인수 (Databricks 2024.6, $1B+) — 의미

6.1 무엇이 있었나

2024년 6월, Databricks가 Tabular를 $1B 이상에 인수했다. Iceberg 공동 창시자 Ryan Blue·Daniel Weeks·Jason Reid가 만든 회사로, Iceberg 기반 매니지드 데이터 플랫폼을 팔고 있었다.

같은 시기 Snowflake도 Tabular를 사려고 했다는 소문이 강하게 돌았다. 결국 Databricks가 가져갔고, 인수가는 Tabular의 ARR 대비 매우 높았다. Databricks가 본 것은 매출이 아니라 사람과 표준이었다.

6.2 무엇이 바뀌었나

Databricks가 Iceberg 표준에 직접적인 영향력을 갖게 되었다. Iceberg PMC와 커미터 다수가 Databricks 내부로 들어왔다.
Delta UniForm이 가속됐다. Delta가 Iceberg를 "흉내"내는 게 아니라, 같은 회사에서 두 포맷을 함께 발전시킨다.
Polaris (Snowflake) vs Unity Catalog (Databricks) 라는 카탈로그 전쟁이 본격화됐다. Snowflake가 2024년 6월 Polaris 발표한 것도 같은 흐름. Databricks는 2024년 6월 Unity Catalog를 오픈 소스화했다.

이 사건은 "테이블 포맷의 전쟁이 끝났다"는 신호였다. Iceberg가 표준이 되고, 카탈로그·엔진·서비스 층에서 진짜 경쟁이 시작된다.

6.3 Ryan Blue가 가져간 메시지

인수 후 첫 컨퍼런스(Iceberg Summit 2024)에서 Ryan Blue가 한 말이 인상적이다.

"테이블 포맷은 표준이어야 한다. 표준이 정해지고 나면, 진짜 경쟁은 그 위에서 시작된다."

이 말 그대로다. 2026년의 데이터 엔지니어링은 "어느 포맷을 고르느냐"가 아니라, "Iceberg 위에서 어떤 엔진·카탈로그·UX를 고르느냐" 의 문제가 되었다.

7장 · Onehouse — Hudi 진영의 상용화

Onehouse는 다윗과 골리앗의 싸움에서 다윗 쪽이다. Databricks·Snowflake가 수십억 달러를 굴리는 데 비해, Onehouse는 시리즈 B를 마친 작은 회사다. 하지만 자기 자리를 분명히 가졌다.

Apache XTable — Hudi·Iceberg·Delta 메타데이터 호환 레이어. Open Source.
Onehouse Cloud — 매니지드 레이크하우스. Hudi 기반이지만 Iceberg·Delta로 동시 노출.
Open Engines — 인덱싱·머티리얼라이즈드 뷰·CDC 최적화를 다른 포맷에도 적용.

Onehouse의 가설은 단순하다.

"한 회사에 한 포맷이라는 시대는 끝났다. 회사 안에 Iceberg·Delta·Hudi가 동시에 존재할 것이다. 그 사이를 매끄럽게 잇는 자가 이긴다."

2026년 시점 이 가설은 점점 맞아 들어가고 있다. 실제 엔터프라이즈에서 "Databricks는 Delta, Snowflake는 Iceberg, 자체 분석은 Hudi"가 한 회사 안에 공존하는 풍경이 흔해졌다.

8장 · dbt — 변환의 표준

8.1 dbt가 무엇을 바꿨는가

dbt(data build tool)는 2016년 Fishtown Analytics(현 dbt Labs)가 시작했다. 핵심 아이디어는 단순하다.

"SQL로 모델을 짜라. 의존성은 우리가 푼다. 테스트도 SQL이다. 문서도 SQL에서 뽑는다."

이전에는 분석가가 SQL을 직접 짜서 BI 도구에 박았다. 변환 로직이 어디에 있는지, 의존성이 무엇인지, 테스트는 어떻게 하는지 — 다 흩어져 있었다.

dbt가 정리한 것:

   models/
     staging/
       stg_orders.sql      ← 원본 → 정제
       stg_customers.sql
     marts/
       core/
         dim_customers.sql
         fct_orders.sql    ← stg_orders, dim_customers 참조
   
   tests/
     not_null_dim_customers_id.sql
   
   dbt_project.yml         ← 프로젝트 설정

SQL이 곧 모델. 각 파일은 SELECT 한 줄이고, dbt가 그걸 CREATE TABLE AS 또는 CREATE VIEW로 바꾼다.
참조는 jinja 매크로로. ref('stg_orders') 같은 식. dbt가 의존성 그래프를 자동으로 만든다.
테스트는 SQL. "이 컬럼은 not null이어야 한다", "unique해야 한다" 같은 어설션을 SQL 쿼리로 표현.
문서는 YAML. 각 컬럼·모델에 설명을 달면 dbt docs로 시각화.

8.2 분석 엔지니어링이라는 직군

dbt가 만든 가장 큰 변화는 "Analytics Engineer" 라는 직군의 등장이다. SQL을 도구 삼아 변환·모델링·테스트·문서까지 책임지는 사람. 데이터 엔지니어와 분석가의 중간이다.

2026년에는 이 직군이 데이터 팀의 다수가 되었다. Python·Spark를 다루는 데이터 엔지니어가 데이터 인입과 인프라를 보고, 분석 엔지니어가 dbt로 모델을 짜고, 데이터 분석가가 그 위에서 BI를 한다.

8.3 dbt의 경쟁자들

dbt가 표준이 된 이후 도전자가 나타났다.

SQLMesh — Tobiko Data가 만든 dbt 대안. virtual data environments(스키마 복사 없이 변경 테스트)와 column-level lineage(컬럼 수준 의존성)가 차별점. CI/CD를 더 진지하게 다룬다.
Coalesce — UI 기반의 dbt 대안. 코드를 직접 쓰지 않고 GUI로 변환을 짜는 게 가능.
dbt Mesh / dbt Cloud — dbt Labs의 엔터프라이즈 답. 프로젝트 간 의존성, 모델 거버넌스.

2026년 시점, dbt는 압도적이지만 SQLMesh가 빠르게 따라잡고 있다. 두 도구 모두 핵심 가치는 같다: SQL은 코드다. 그러니까 버저닝·테스트·CI/CD가 있어야 한다.

9장 · Trino (구 PrestoSQL) / Presto — 분산 OLAP 쿼리 엔진

9.1 Presto의 분기점

Presto는 2012년 Facebook이 만든 분산 SQL 엔진이다. 2019년 핵심 개발자 그룹이 회사를 떠나 Trino(처음 이름 PrestoSQL)로 분기했다. Presto Foundation(Linux Foundation)에 남은 쪽이 PrestoDB로, 사실상 Meta 내부 중심.

2026년 시점:

Trino — 산업의 사실상 표준. Starburst가 상용화. Iceberg·Delta·Hive·MySQL·PostgreSQL·MongoDB·Kafka 등 50개 이상 커넥터.
Presto (PrestoDB) — Meta 안에서만 살아 있음. 외부 채택은 거의 멈췄다.

분기한 지 6년이 넘은 지금, Trino가 사실상 Presto의 정통 후계자가 되었다.

9.2 Trino의 자리

Trino는 "연결(federated) 쿼리 엔진"이다. 자기 자신은 데이터를 저장하지 않는다. S3의 Iceberg 테이블, MySQL의 운영 DB, Kafka의 토픽을 같은 SQL 한 줄로 JOIN한다.

-- Iceberg 테이블 ⋈ MySQL 테이블 ⋈ PostgreSQL 테이블
SELECT
    i.user_id,
    m.user_name,
    p.last_login,
    SUM(i.amount) AS total_spent
FROM iceberg.analytics.purchases i
JOIN mysql.app.users m ON i.user_id = m.id
JOIN postgres.crm.profiles p ON i.user_id = p.user_id
WHERE i.event_date >= DATE '2026-05-01'
GROUP BY 1, 2, 3

이게 한 쿼리에서 가능한 게 Trino의 정체성이다. 데이터 레이크하우스의 OLAP 표준으로 자리잡았다.

9.3 누가 Trino를 쓰는가

Netflix — 만든 회사. Iceberg + Trino가 그 자체로 그들의 데이터 플랫폼.
LinkedIn, Shopify, Lyft — 일급 채택.
Starburst — Trino 창시자들이 만든 상용 회사. Trino Galaxy(매니지드)·Trino Enterprise를 판다.
AWS Athena는 Presto 기반이지만 갈수록 Trino에 가까워졌다.

9.4 Trino vs DuckDB — 단일 노드의 도전

흥미로운 건 DuckDB가 단일 노드에서 Trino보다 빠른 경우가 많다는 것이다. 데이터가 작거나 중간 크기일 때(수십~수백 GB), DuckDB로 충분하고 종종 더 빠르다. Trino는 "분산이 정말로 필요한 큰 쿼리"의 자리로 좁아지고 있다.

10장 · Spark 4 (2024.8) + Apache Flink 2 — 처리 엔진

10.1 Spark 4의 변화

Apache Spark 4.0이 2024년 8월에 정식 출시됐다. 핵심 변화 셋.

Spark Connect 안정화 — 클라이언트와 서버를 분리. gRPC로 통신. Python·Scala·Go·Rust 클라이언트가 모두 가능. 노트북·CI에서 가벼운 클라이언트로 무거운 클러스터를 조작.
Pandas API on Spark의 성숙. import pyspark.pandas as ps로 Pandas 코드를 거의 그대로 분산 실행.
ANSI SQL이 기본. 4.0부터 ANSI 모드가 디폴트. 묵시적 형변환·NULL 처리가 표준에 맞춰졌다.

Spark는 더 이상 "Hadoop의 다음"이 아니다. "Iceberg·Delta·Hudi 어떤 포맷에든 쓰고 읽는 ETL·배치 엔진의 표준" 이다.

10.2 Flink 2의 변화

Apache Flink 2.0이 2025년 초 출시됐다. 핵심은 상태 관리의 클라우드 네이티브화다.

Disaggregated state — 상태를 RocksDB 로컬에서 분리해 S3·GCS에 두는 모드. 큰 상태를 가진 잡(joins·세션 윈도우)이 노드 한 대 메모리에 갇히지 않는다.
Hybrid Source — 같은 소스에서 배치(과거)와 스트리밍(현재)을 끊김 없이 잇는다.
PyFlink의 성숙. Python 사용자가 1급 시민이 됐다.

Flink 2 + Paimon이 2026년의 "스트리밍 레이크하우스" 표준이 되어가는 중이다.

10.3 Spark vs Flink — 무엇을 언제 쓰는가

축	Spark	Flink
배치	표준	가능
스트리밍	Structured Streaming (마이크로배치)	진짜 스트리밍 (이벤트 단위)
지연	초 단위	밀리초 단위
상태 관리	약함	일급
ML / DataFrame	매우 강함	약함
사람 풀	매우 큼	중간

ETL·배치·ML은 Spark, 진짜 스트리밍은 Flink. 2026년에도 이 구도는 유지된다. 다만 Spark의 Structured Streaming이 충분히 좋아져서, "초 단위 지연이면 Spark로 충분"한 경우가 늘어났다.

11장 · Databricks · Snowflake · BigQuery · ClickHouse — 클라우드 데이터 플랫폼

11.1 Databricks — 레이크하우스의 원조

Unity Catalog — 2024년 6월 오픈 소스화. 데이터·AI·노트북·feature·model 모두 한 카탈로그.
Delta + Iceberg 양손잡이. UniForm으로 같은 데이터를 두 포맷으로 노출.
Mosaic AI — MosaicML 인수 후, 모델 학습·서빙까지 한 플랫폼에서.
Photon — 벡터화된 네이티브 쿼리 엔진. Spark SQL이 ANSI를 깔고 Photon이 그 아래서 빠르게 돈다.

2026년 Databricks의 메시지: "데이터 + AI = 한 플랫폼." 단순한 ETL·BI가 아니라 모델 학습까지 한 곳에서.

11.2 Snowflake — 웨어하우스에서 레이크하우스로

전통 웨어하우스로 시작했지만, 2024-25년에 빠르게 레이크하우스 방향으로 갔다.

Polaris Catalog — 2024년 6월 발표, 2025년 Apache에 기증. Iceberg REST 표준 구현.
Iceberg Tables — Snowflake 안에서 Iceberg 테이블을 일급으로. 외부 엔진(Spark·Trino)이 같은 데이터를 읽음.
Snowpark — Python·Java·Scala로 Snowflake에서 코드 실행. UDF·UDTF·Stored Proc.
Cortex — LLM·ML 기능을 SQL로 호출.

Snowflake의 메시지: "Iceberg가 표준이 되어도 우리는 그 표준의 일급 시민이다."

11.3 BigQuery — Google의 답

BigLake — 외부 Iceberg·Delta·Hudi 테이블을 BigQuery에서 읽기·쓰기.
BigQuery Studio — 노트북·SQL·Python을 한 워크벤치에.
Gemini in BigQuery — 자연어로 SQL 작성·코드 보완.

BigQuery는 GCP 안에 있는 한 가장 매끄러운 선택이다. BigLake로 Iceberg를 받아들인 게 2025년의 큰 변화.

11.4 ClickHouse Cloud — 실시간 OLAP의 강자

ClickHouse는 정통 OLTP/HTAP이 아니라 실시간 분석에 특화된 컬럼형 DB다. 2022년 Yandex에서 분리되어 ClickHouse Inc.로 시작했고, 2024-25년 Cloud가 크게 성장했다.

밀리초 단위 응답. 수십억 행에서 1초 안에 집계.
Materialized View가 일급. 인입 시점에 집계가 만들어진다.
사용처: 제품 분석(Plausible·PostHog), 관측성(Logs·Metrics), 광고 분석.

ClickHouse는 "데이터 레이크하우스의 일부"라기보다 "실시간 OLAP을 위한 별도 엔진" 으로 자리잡았다. Iceberg와는 외부 테이블로 연결한다.

12장 · AWS Athena + Glue — 클라우드 매니지드

12.1 Athena — S3 위의 서버리스 SQL

AWS Athena는 Presto/Trino 기반의 서버리스 쿼리 엔진이다. S3에 있는 Parquet·ORC·Iceberg·Delta 파일을 SQL로 바로 쿼리한다. 클러스터를 띄우거나 관리하지 않는다.

-- Iceberg 테이블 쿼리 (Athena v3 엔진)
SELECT
    event_date,
    COUNT(*) AS events,
    COUNT(DISTINCT user_id) AS dau
FROM iceberg_catalog.analytics.events
WHERE event_date BETWEEN DATE '2026-05-01' AND DATE '2026-05-15'
GROUP BY 1
ORDER BY 1

과금은 스캔한 데이터 양 기준 ($5/TB).
Iceberg 일급 지원 (2022년부터).
Athena for Spark (2022)로 Spark 잡도 서버리스로 돌릴 수 있음.

12.2 Glue — 카탈로그 + ETL

Glue Data Catalog — AWS의 표준 메타스토어. Hive Metastore 호환. Athena·Redshift Spectrum·EMR·SageMaker가 모두 여기를 본다.
Glue ETL — Spark 기반의 서버리스 ETL.
Glue Studio — 시각적 ETL 빌더.

Glue Data Catalog가 Iceberg REST를 흉내내는 어댑터를 2024년에 내놓았다. AWS 안에서 "Iceberg + Athena + Glue Catalog + S3"가 가장 자연스러운 조합이 되었다.

12.3 S3 Tables (2024.12)

2024년 12월 AWS가 발표한 S3 Tables가 큰 변화였다. S3 자체가 Iceberg 테이블을 일급으로 관리한다. 자동 컴팩션·스냅샷 만료·메타데이터 관리까지 S3가 직접.

S3 (객체 저장소)
   ↓
S3 Tables (Iceberg 일급)  ← 컴팩션·만료·통계 자동 관리
   ↓
Athena · EMR · Glue · Redshift · Trino · Spark

이 한 발이 의미가 크다. 클라우드 사업자가 Iceberg를 직접 다루기 시작했다. Iceberg가 표준이라는 마지막 못이 박혔다.

13장 · DuckDB — "Analytics용 SQLite"

13.1 DuckDB의 정체

DuckDB는 2019년 네덜란드 CWI에서 시작된 인-프로세스 OLAP 데이터베이스다. 핵심 슬로건은 "SQLite for analytics." 서버를 띄우지 않고, 라이브러리로 임포트해서 그 프로세스 안에서 SQL을 돈다.

import duckdb

# Parquet 직접 쿼리. 클러스터·서버 없음.
result = duckdb.sql("""
    SELECT
        user_id,
        COUNT(*) AS events,
        SUM(amount) AS total
    FROM 's3://my-bucket/events/*.parquet'
    WHERE event_date >= '2026-05-01'
    GROUP BY user_id
    ORDER BY total DESC
    LIMIT 100
""").df()  # → Pandas DataFrame

이게 끝이다. PostgreSQL 클라이언트도, Spark 클러스터도, Snowflake 계정도 필요 없다.

13.2 왜 DuckDB가 폭발했나

2024-25년 DuckDB의 GitHub 스타가 4배 가까이 늘었다. 이유는 단순하다.

클라우드 메모리·디스크가 너무 커졌다. 128GB·256GB RAM 인스턴스가 시간당 몇 달러. 수십 GB 분석은 단일 노드에서 충분히 빠르다.
Apache Arrow / Parquet과 일급 통합. Pandas·Polars와도 zero-copy.
인-프로세스. Lambda·노트북·CI 어디서나 돈다.
MotherDuck — 2022년 만들어진 상용. 로컬 DuckDB와 클라우드를 잇는 "hybrid execution."

13.3 DuckDB가 점유한 자리

노트북 분석. Pandas보다 빠르고 SQL이 더 자연스러운 경우 많음.
CI·테스트. Spark·BigQuery보다 빠르게 검증.
임베디드 분석. 데스크탑 앱·CLI·BI 도구 안에 임베드. Tableau·Hex가 내부적으로 DuckDB 쓰는 경우 늘었다.
edge analytics. WASM 빌드로 브라우저 안에서 돈다.

Spark·Trino가 "분산이 정말로 필요한가"라는 질문을 받기 시작했다. 데이터가 1TB 이하면, DuckDB로 충분한 경우가 많다.

14장 · Apache Arrow / Parquet / ORC / DataFusion — 저수준 표준

14.1 Apache Arrow — 인-메모리 컬럼 표준

데이터를 디스크에 두는 표준이 Parquet라면, 메모리에서 다루는 표준은 Apache Arrow다.

컬럼형 인-메모리 포맷. 같은 데이터를 Python·Java·C++·Rust·Go가 zero-copy로 공유.
Arrow Flight — gRPC 기반의 데이터 전송 표준. Snowflake·BigQuery 결과를 Arrow로 받는 게 일반화됐다.
Arrow DataFusion — 아래에서 다룸.

Pandas 2.0(2023)부터 Arrow가 백엔드로 들어왔고, Polars는 처음부터 Arrow 기반. "DataFrame은 Arrow 위에 있다"가 표준이 됐다.

14.2 Parquet vs ORC — 디스크 포맷

Apache Parquet — Twitter·Cloudera 출신. 사실상 표준. Iceberg·Delta·Hudi·Paimon이 모두 기본으로 Parquet을 쓴다.
Apache ORC — Hortonworks·Hive 출신. Hive·Presto 생태에서 한때 강했고 지금도 살아 있지만, 신규 프로젝트는 거의 Parquet.

차이는 작다. 압축률·스캔 성능에서 시나리오마다 엎치락뒤치락. 하지만 생태계 모멘텀이 Parquet에 압도적이다. 2026년에 새 프로젝트를 Parquet 아닌 다른 걸로 시작할 이유는 사실상 없다.

14.3 Apache DataFusion — Rust 쿼리 엔진

DataFusion은 Apache Arrow 프로젝트의 일부로 시작된 Rust로 짠 SQL 쿼리 엔진이다. Andy Grove가 만들었고 2021년 Apache로 들어갔다.

Arrow 네이티브. 인-메모리 표현이 Arrow.
임베디드. 라이브러리로 임포트해서 자기 프로세스 안에서 SQL.
빠르다. 벡터화된 실행. SIMD 활용.

DataFusion의 자리는 흥미롭다. DuckDB와 직접 경쟁하는 게 아니라, 다른 시스템의 내부 엔진으로 채택되고 있다.

InfluxDB 3.0 — 시계열 DB. 내부 SQL 엔진을 DataFusion으로 교체.
Comet — Spark의 일부 연산을 DataFusion으로 가속.
LanceDB·GreptimeDB·Sail — 신생 DB들이 DataFusion을 코어로.
Ballista — DataFusion 기반의 분산 실행.

"Rust로 짠 DBMS 만들 때 SQL 엔진은 DataFusion에서 시작하라" 가 2026년의 디폴트가 되었다.

15장 · 한국 / 일본 — 토스, 카카오 KaaP, 메르카리, ZOZO

15.1 토스 데이터 — 단일 데이터 플랫폼

토스(Toss)는 2025년 데이터 플랫폼을 Apache Iceberg + dbt + Trino + Airflow의 조합으로 재구성했다. 인용된 카날리아 컨퍼런스 발표(SLASH 25)에서:

Iceberg 위에 사실상 모든 분석 데이터. S3 + Glue Catalog + Iceberg.
dbt로 변환. 분석 엔지니어 직군 운영.
Trino + Athena로 쿼리. 사용자는 SQL만.
Airflow로 오케스트레이션. dbt 잡과 Spark 잡 모두 관리.

특히 토스가 강조한 건 "데이터 셀프서비스" 였다. 데이터 엔지니어가 인입과 인프라만 책임지고, 분석·모델링은 분석 엔지니어·분석가가 자체적으로.

15.2 카카오 KaaP (Kakao as a Platform)

카카오는 사내 데이터 플랫폼을 KaaP라는 이름으로 운영한다. 핵심은 멀티 테넌트 분석 인프라.

S3·HDFS 하이브리드. 사내 데이터센터 HDFS + 클라우드 S3.
Spark·Trino 공용 클러스터. 팀별 워크스페이스.
Airflow 기반 워크플로 표준화.
자체 메타스토어 — 사내 거버넌스·권한 통합.

2025-26년 KaaP는 Iceberg 채택을 빠르게 늘리는 중이다. 기존 Hive 테이블에서 Iceberg로 마이그레이션하는 게 큰 과제.

15.3 메르카리(メルカリ) — 일본의 데이터 플랫폼

메르카리(Mercari)는 일본의 대표 C2C 마켓플레이스. 데이터 플랫폼은 BigQuery + dbt + Looker 조합이 중심.

BigQuery 중심. GCP 위에서 운영.
dbt로 변환. 분석 엔지니어 직군 일찍 도입.
Looker로 BI.
Dataform·BigLake — Iceberg/외부 테이블 점점 받아들이는 중.

2024년 메르카리 엔지니어링 블로그가 "BigLake로 외부 Iceberg 받아들이기"를 다룬 게 인상적이다. 일본 회사 중에서 가장 빠르게 레이크하우스 방향으로 움직였다.

15.4 ZOZO — 일본 패션 커머스

ZOZOTOWN의 모회사. 데이터 플랫폼은 BigQuery + Dataform 조합이 메인.

BigQuery 중심.
Dataform — Google이 인수한 dbt 대안. 사내 표준.
데이터 메시(Data Mesh) — 도메인별 분산 운영. 카탈로그·거버넌스가 핵심 과제.

ZOZO는 데이터 메시를 일찍 시도한 일본 회사 중 하나로 알려져 있다. 2024년 ZOZO 테크 블로그에서 "도메인별 책임 분산"을 강조한 글이 자주 인용된다.

16장 · 누가 무엇을 골라야 하나 — SMB / 엔터프라이즈 / 스트리밍 / 분석

규모와 요구사항별로 정리.

16.1 SMB · 스타트업 (월 비용 $5,000 이하)

영역	추천
스토리지	S3 + Parquet
테이블 포맷	시작은 그냥 Parquet, 커지면 Iceberg
엔진	DuckDB + (선택) Athena
변환	dbt-core
오케스트레이션	dbt 스케줄 + GitHub Actions
BI	Metabase · Lightdash

핵심: 클러스터를 띄우지 마라. DuckDB가 100GB까지 충분하다. Athena는 SQL만 던지면 된다. Snowflake·Databricks는 데이터가 정말 커지고 분석가가 5명 넘기 전까지는 비싸다.

16.2 미드사이즈 (월 $5,000 ~$ 50,000)

영역	추천
스토리지	S3 / GCS / ADLS
테이블 포맷	Iceberg
엔진	Trino (Starburst Galaxy) · Spark (managed)
변환	dbt Cloud 또는 SQLMesh
카탈로그	Glue · Polaris · Unity Catalog
BI	Looker · Hex · Mode

여기서부터 Iceberg가 의미를 갖는다. 데이터 엔지니어가 2-3명 있고, 분석가가 10명 이상, 비용이 데이터 인프라의 큰 비중이 되는 구간.

16.3 엔터프라이즈

영역	추천
스토리지	멀티 클라우드 (S3 + GCS)
테이블 포맷	Iceberg (Delta UniForm 병행 가능)
엔진	Databricks (전사) + Snowflake (특정 부서) + Trino (셀프서비스)
변환	dbt + 분석 엔지니어 조직
카탈로그	Unity Catalog 또는 Polaris (조직 표준 잡기)
거버넌스	Atlan · Collibra · OpenMetadata

엔터프라이즈에서 가장 어려운 건 거버넌스다. 카탈로그가 표준이 되어야 100개 이상의 팀이 같은 데이터를 보는 게 가능하다.

16.4 스트리밍 중심

영역	추천
인입	Kafka
처리	Flink 2
테이블 포맷	Paimon (또는 Hudi)
다운스트림 분석	Iceberg + Trino

스트리밍 머티리얼라이즈드 뷰는 Paimon, 거대 분석 테이블은 Iceberg. 두 포맷을 같은 플랫폼 안에서 운영.

16.5 실시간 OLAP (제품 분석·관측성)

영역	추천
엔진	ClickHouse Cloud
인입	Kafka → ClickHouse 직접
데이터	실시간 + 일별 집계

데이터 레이크하우스의 일부라기보다, 별도 엔진. 밀리초 응답이 필요한 곳.

17장 · 마무리 — 표준이 되고 나서 시작되는 것들

2010년대 후반 "데이터 레이크 vs 데이터 웨어하우스" 논쟁이 있었다. 2020년대 초반 "Iceberg vs Delta vs Hudi" 전쟁이 있었다. 2026년 시점, 둘 다 끝났다.

레이크하우스가 표준이다. 객체 저장소 + Parquet + 테이블 포맷.
Iceberg가 테이블 포맷의 사실상 표준이다. Delta는 Databricks 내부 최적화, Hudi는 niche, Paimon은 스트리밍 보완.
엔진은 분리되었다. Spark·Flink·Trino·DuckDB·ClickHouse를 워크로드별로 골라 쓴다.
카탈로그가 다음 전장이다. Unity Catalog·Polaris·BigLake가 경쟁한다.
dbt가 변환의 표준이다. SQL은 코드, 분석 엔지니어가 자리 잡았다.

Tabular 인수 후 Ryan Blue가 한 말을 다시 인용한다.

"표준이 정해지고 나면, 진짜 경쟁은 그 위에서 시작된다."

이건 2026년 데이터 엔지니어링의 한 줄 요약이다. Iceberg가 표준이라는 사실은 더 이상 논의거리가 아니다. 이제 진짜 일은 그 위에서 일어난다 — 카탈로그·거버넌스·UX·AI 통합·실시간 동기화·멀티 클라우드.

우리가 지금 짓는 데이터 플랫폼은, 5년 뒤에도 같은 Iceberg 메타데이터를 들고 있을 것이다. 그게 표준이라는 단어가 의미하는 바다.

참고 / References

Apache Iceberg — https://iceberg.apache.org
Apache Iceberg REST Catalog Spec — https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml
Delta Lake — https://delta.io
Delta UniForm — https://docs.databricks.com/aws/en/delta/uniform
Apache Hudi — https://hudi.apache.org
Apache Paimon — https://paimon.apache.org
Tabular acquisition (Databricks blog, Jun 2024) — https://www.databricks.com/blog/databricks-tabular
Unity Catalog OSS — https://www.unitycatalog.io
Apache Polaris — https://polaris.apache.org
AWS S3 Tables (re:Invent 2024) — https://aws.amazon.com/s3/features/tables/
dbt Labs — https://www.getdbt.com
SQLMesh — https://sqlmesh.com
Trino — https://trino.io
Starburst — https://www.starburst.io
Presto — https://prestodb.io
Apache Spark — https://spark.apache.org
Spark Connect — https://spark.apache.org/docs/latest/spark-connect-overview.html
Apache Flink — https://flink.apache.org
Databricks — https://www.databricks.com
Snowflake — https://www.snowflake.com
BigQuery / BigLake — https://cloud.google.com/biglake
ClickHouse Cloud — https://clickhouse.com/cloud
AWS Athena — https://aws.amazon.com/athena/
AWS Glue — https://aws.amazon.com/glue/
DuckDB — https://duckdb.org
MotherDuck — https://motherduck.com
Apache Arrow — https://arrow.apache.org
Apache Parquet — https://parquet.apache.org
Apache ORC — https://orc.apache.org
Apache DataFusion — https://datafusion.apache.org
Onehouse — https://www.onehouse.ai
Apache XTable — https://xtable.apache.org
Project Nessie — https://projectnessie.org
토스 SLASH 25 — https://toss.tech/slash-25
메르카리 Engineering — https://engineering.mercari.com
ZOZO TECH BLOG — https://techblog.zozo.com