💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「データウェアハウス」という言葉が古びた場所

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を10億ドル超で買収した。** Iceberg共同創設者Ryan Blueを迎え入れ、「Delta LakeとIcebergを同じメタデータとして扱う」というUniForm戦略を加速した。

- **Apache Hudi (Uber発)** はOnehouseという商用会社で生き残った。ニッチだがCDC・インデックス・差分処理では依然として最強。

- **Apache Paimon (Flinkチーム)** は「ストリーミング・レイクハウス」という新カテゴリを携えて登場した。LSMツリーを基盤に、同じテーブルで実時間更新と分析の両方をこなす。

- **クエリエンジン**は多様化した。Trino (旧PrestoSQL)が分散OLAPの標準になり、DuckDBが「Analytics版SQLite」として単一ノードでほぼあらゆる分析問題を捌き、ClickHouse Cloudがリアルタイムタイムスタンプ分析を取り、Apache DataFusion (Rust)が次世代の組み込みSQLエンジンの座を狙う。

- **dbt**がSQL変換の標準になった。アナリティクスエンジニアという職種が生まれた。

この記事では、その全景を — テーブルフォーマット3強 (Iceberg・Delta・Hudi)と挑戦者Paimon、エンジン (Spark 4・Flink 2・Trino・DuckDB)、クラウドデータプラットフォーム (Databricks・Snowflake・BigQuery・ClickHouse)、日本・韓国企業の実例まで — 一気に整理する。

1章 · 2026年データレイクハウスの地図 — 3つの軸

まず1枚の図から始めよう。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はニッチ、Paimonはストリーミング。

- **エンジン** — そのデータを読み書きし変換する。SparkはETL・バッチ、Flinkはストリーミング、Trinoは分散OLAP、DuckDBは単一ノードOLAP。

- **カタログ** — テーブル・スキーマ・権限を管理する。2025年に最も熱くなった領域。Unity Catalog (Databricksがオープンソース化)、Polaris (Snowflake、Iceberg REST準拠の参照実装)、BigLake (GCP)、Nessie (Project Nessie)。

この3軸が分離できることがレイクハウスの核だ。**テーブルフォーマットはIcebergを使い、エンジンはSpark/Trino/DuckDBから選び、カタログはUnity** — そんな組み合わせが自然になった。

従来のウェアハウス (Snowflake・BigQuery)は3軸すべてが一社内に閉じていた。レイクハウスはその鍵を外す。だからSnowflakeもPolarisを作り、BigQueryもBigLakeで外部Icebergを読めるようにした。**「鍵を外すこと」自体が2026年のデフォルトになった。**

2章 · Apache Iceberg — テーブルフォーマット戦争の勝者

2.1 なぜ「テーブルフォーマット」が必要なのか

Parquetファイルは優秀だ。列指向、圧縮、統計プッシュダウン。しかしそれだけでは足りない。

- 1万個のParquetファイルが入った「テーブル」に1列追加するには? スキーマ変更をどう記録するか。

- 2つのジョブが同じテーブルに同時に書き込んだら? ACIDは?

- 昨日の状態を見たい? タイムトラベルは?

- 100億行のうち100万行だけ更新したい? ファイル単位の上書き以外に道はあるか?

**テーブルフォーマット**はこれを解決するメタデータ層だ。Parquetファイル群の上にJSONやAvroファイルで「このテーブルの現在のスナップショットはX、スキーマはY、次のトランザクションはZ」のような情報を持つ。

Iceberg・Delta・Hudiは、同じ問題を解く異なる方法だ。

2.2 Icebergのデータモデル

Icebergは3階層のメタデータを持つ。

[ Catalog ] ─ カタログ (Glue・Nessie・Polaris・REST)

[ Metadata file v0.json, v1.json ... ]

[ Snapshot ] ─── ある時点のテーブル状態

[ Manifest list ]

[ Manifest ] ─ どのデータファイルがどこにあり統計は何か

[ Data files (Parquet/ORC/Avro) ]

核となるアイデア:

- **スナップショット基盤。** すべての書き込みは新しいスナップショットを作る。古いスナップショットは削除されるまで生きている → タイムトラベル・ロールバックがタダで手に入る。

- **メタデータがメタデータを指す。** カタログは「現在のmetadataファイルがどこにあるか」だけを知る。その中にスナップショット一覧が、その中にmanifest listが、その中にmanifestが、その中にデータファイルがある。

- **パーティションが隠される。** ユーザーは`event_time`カラムだけを書き、Icebergが内部的に`day(event_time)`のようなパーティションを管理する。パーティションevolutionが可能。

2.3 Icebergが勝った理由

2023年までは「Iceberg対Delta対Hudi」は本物の競争だった。2025年末時点で、業界の重心は明確にIcebergに傾いた。理由は1文で要約できる。

> Icebergは**標準**であり、Deltaは**製品**である。

- **ベンダーニュートラル。** Netflixが作り、Apacheに寄贈した。Databricks・Snowflake・AWS・GCP・Cloudera・Dremio・Tabularすべてが一級で支援する。

- **REST Catalog標準。** 2024年にIceberg REST Catalog仕様が安定化し、「どのベンダーのカタログでも同じAPIで話せる」が現実になった。

- **クラウドベンダーロックインの解消。** Snowflakeで使っていたテーブルをそのままDatabricks・Trino・Sparkで読める。「データを移動せずエンジンだけ変える」が本物になった。

- **Tabular買収。** Databricksが10億ドル超で買った事件が決定打だった。「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で)

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()

これがすべてだ。分散クラスタなしに、Python1行でIcebergテーブルを作り、読み、時点クエリまでする。**ここで「Icebergは『エンジン』ではなく『仕様』だ」ということが具体的になる。**

3章 · Delta Lake (Databricks) — 依然として強力な対抗馬

3.1 Deltaは何が違うのか

Delta Lakeは2019年にDatabricksがオープンソース化したテーブルフォーマットだ。本質はIcebergと同じ — Parquetファイル群の上にトランザクションログを載せてACID・タイムトラベル・スキーマ管理を提供する。違うのはメタデータ構造とエコシステム。

[ Delta Table ]

_delta_log/

00000000000000000000.json ← トランザクションログ (1行ずつJSON)

00000000000000000001.json

...

00000000000000000010.checkpoint.parquet

_last_checkpoint

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) — ニッチな魅力

4.1 Hudiのアイデンティティ

Hudiは2016年にUberが作り2019年にApacheへ寄贈したテーブルフォーマットだ。**「upsert-first」**がアイデンティティ。

最初から「データレイクにどう頻繁な更新を反映するか」を解いた。Uberが分単位でCDC (Change Data Capture)イベントを反映する必要があったのが出発点だ。

Hudiの2つのストレージタイプ

[ Copy-on-Write (CoW) ]

書込: 影響を受けたParquetファイル全体を再書き込み

読込: 速い (ただのParquet)

向き: 読込多・書込少の分析

[ Merge-on-Read (MoR) ]

書込: 差分を別のログファイル(Avro)に積む

読込: Parquetとログをマージ (リアルタイムビュー)

向き: 頻繁な更新・削除 (CDC)

4.2 Hudiの強み — インデックスと差分クエリ

Iceberg・Deltaがまだ追いつけない2つ。

- **レコードレベルインデックス。** Bloomフィルタ、HBase、bucket indexなどで「このuser_idがどのファイルにあるか」を即座に見つける。upsertが速い根本的な理由。

- **差分クエリ (Incremental Query)。** 「このコミット以降に変わった行だけ」のようなクエリを一級でサポート。CDCパイプラインの下流にそのまま繋げる。

この2つはまさに**Iceberg v3が追いつこうとしている**領域だ。Iceberg v3はrow-level deletes・equality deletes・merge-on-readを強化中で、2026年に追いつく可能性が高い。だからHudiは「ニッチな強者」の座を守っている。

4.3 Onehouse — Hudiの商用化の道

Hudi共同創設者Vinoth Chandarが2021年に作った会社。**「Universal Data Lakehouse」**を旗印に、Hudi・Iceberg・Deltaすべてを扱うマネージドサービスを売る。Hudiの会社がHudiだけを売らないのが興味深い。

2024-25年にOnehouseがリリースした2つのツールが意味深かった。

- **Apache XTable (旧OneTable)。** Hudi・Iceberg・Delta間のメタデータ変換を行う。同じParquetを3つのフォーマットのメタデータで同時に露出。UniFormのオープン版。

- **Open Engines。** Hudiのインデックス・差分処理を他のフォーマットにも適用できるエンジン層。

5章 · Apache Paimon (Flinkチーム) — 新しい挑戦者

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から即座に読む。

- **ストリーミングCDC。** Debeziumから受け取ったCDCイベントを分単位でPaimonテーブルに反映。Icebergより自然。

- **Lookup join。** FlinkジョブからPaimonテーブルをlookupテーブルとして使う。Kafka StreamsのGlobalKTableのような役割。

2025年時点でPaimonは中国のアリババ・バイトダンス内で最も使われ、西側へ広がっている。Icebergがバッチの標準なら、**Paimonは「ストリーミング・レイクハウス」の標準の座を狙う。**

5.3 IcebergとPaimonは競争か、補完か

これまでの流れを見ると**補完に近い。**

- Iceberg: 巨大な分析テーブル、スナップショットベース、タイムトラベル。

- Paimon: ストリーミング取り込み、頻繁な更新、マテリアライズドビュー。

2026年は両フォーマットを同じデータプラットフォーム内に共存させる構成が標準になるだろう。FlinkがPaimonに書き、キューブや集計が形になったらIcebergに固める形。

6章 · Tabular買収 (Databricks 2024年6月、10億ドル超) — 意味

6.1 何があったのか

2024年6月、DatabricksがTabularを10億ドル超で買収した。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)対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メタデータ互換層。オープンソース。

- **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 1本で、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 1本で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

これが1つのクエリで可能なのがTrinoのアイデンティティだ。**Trinoはデータレイクハウスの OLAP標準として定着した。**

9.3 誰がTrinoを使うのか

- **Netflix** — 作った会社。Iceberg + Trinoがそのまま彼らのデータプラットフォーム。

- **LinkedIn、Shopify、Lyft** — 一級採用組。

- **Starburst** — Trino創設者たちが作った商用会社。Trino Galaxy (マネージド)とTrino Enterpriseを売る。

- **AWS Athena**はPrestoベースだが次第にTrinoに近づいている。

9.4 Trino対DuckDB — 単一ノードの挑戦

興味深いのは、単一ノードではDuckDBがTrinoより速い場合が多いことだ。データが小さいか中程度 (数十〜数百GB)の時、DuckDBで十分でしばしばより速い。**Trinoは「本当に分散が必要な大きなクエリ」の場所に狭まりつつある。**

10章 · Spark 4 (2024年8月) + Apache Flink 2 — 処理エンジン

10.1 Spark 4の変化

Apache Spark 4.0が2024年8月に正式リリースされた。核となる変化3つ。

- **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・セッションウィンドウ)が1ノードのメモリに閉じ込められない。

- **Hybrid Source** — 同じソースからバッチ (過去)とストリーミング (現在)をシームレスに繋ぐ。

- **PyFlinkの成熟。** Pythonユーザーが一級市民になった。

Flink 2 + Paimonが2026年の「ストリーミング・レイクハウス」標準になりつつある。

10.3 Spark対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すべて1カタログに。

- **Delta + Iceberg両刀使い。** UniFormで同じデータを両フォーマットで露出。

- **Mosaic AI** — MosaicML買収後、モデル学習・サービングまで1プラットフォームで。

- **Photon** — ベクトル化されたネイティブクエリエンジン。Spark SQLがANSIを敷きPhotonがその下で速く回る。

2026年Databricksのメッセージ: 「データ + AI = 1プラットフォーム。」単純なETL・BIではなくモデル学習まで1箇所で。

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を1ワークベンチに。

- **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

この1歩の意味が大きい。**クラウド事業者がIcebergを直接扱い始めた。** 「Icebergが標準だ」という最後の釘が打たれた。

13章 · DuckDB — 「Analytics版SQLite」

13.1 DuckDBの正体

DuckDBは2019年にオランダのCWIで始まった**インプロセスOLAPデータベース**だ。核となるスローガンは「SQLite for analytics.」サーバを立てず、ライブラリとしてインポートしてそのプロセス内でSQLを回す。

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対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章 · 韓国 / 日本 — Toss、Kakao KaaP、メルカリ、ZOZO

15.1 Tossデータ — 単一データプラットフォーム

韓国のフィンテックTossは2025年にデータプラットフォームをApache Iceberg + dbt + Trino + Airflowの組み合わせで再構成した。SLASH 25カンファレンス発表から:

- **Iceberg上に事実上すべての分析データ。** S3 + Glue Catalog + Iceberg。

- **dbtで変換。** アナリティクスエンジニア職種を運用。

- **Trino + Athenaでクエリ。** ユーザーはSQLだけ。

- **Airflowでオーケストレーション。** dbtジョブとSparkジョブの両方を管理。

特にTossが強調したのが**「データセルフサービス」**だった。データエンジニアが取り込みとインフラだけを担当し、分析・モデリングはアナリティクスエンジニア・アナリスト自身が。

15.2 Kakao KaaP (Kakao as a Platform)

KakaoはKaaPという名の社内データプラットフォームを運用する。核はマルチテナント分析インフラ。

- **S3 + HDFSハイブリッド。** 社内データセンターHDFS + クラウドS3。

- **Spark・Trino共有クラスタ。** チーム別ワークスペース。

- **Airflowベースのワークフロー標準化。**

- **自前メタストア** — 社内ガバナンス・権限の統合。

2025-26年KaaPはIceberg採用を急速に増やしている。既存のHiveテーブルからIcebergへの移行が大きな課題。

15.3 メルカリ — 日本のデータプラットフォーム

メルカリは日本を代表するC2Cマーケットプレイス。データプラットフォームはBigQuery + dbt + Lookerの組み合わせが中心。

- **BigQuery中心。** GCP上で運用。

- **dbtで変換。** アナリティクスエンジニア職種を早期導入。

- **LookerでBI。**

- **DataformとBigLake** — Iceberg・外部テーブルを次第に受け入れている。

2024年のメルカリエンジニアリングブログが「BigLakeで外部Icebergを受け入れる」を扱ったのが印象的だ。日本企業の中で最も速くレイクハウス方向へ動いた。

15.4 ZOZO — 日本のファッションコマース

| データ | リアルタイム + 日別集計 |

データレイクハウスの一部というより、別エンジン。ミリ秒応答が必要な場所。

17章 · まとめ — 標準になってから始まること

2010年代後半に「データレイク対データウェアハウス」の議論があった。2020年代初頭に「Iceberg対Delta対Hudi」の戦争があった。2026年時点で、両方とも終わった。

- **レイクハウスが標準。** オブジェクトストレージ + Parquet + テーブルフォーマット。

- **Icebergがテーブルフォーマットの事実上の標準。** DeltaはDatabricks内部の最適化フォーマット、Hudiはニッチ、Paimonはストリーミング補完。

- **エンジンは分離された。** Spark・Flink・Trino・DuckDB・ClickHouseをワークロード別に選ぶ。

- **カタログが次の戦場。** Unity Catalog・Polaris・BigLakeが競争する。

- **dbtが変換の標準。** SQLはコードであり、アナリティクスエンジニアという職種が定着した。

Tabular買収後にRyan Blueが言った言葉をもう一度引用する。

> 「標準が決まったら、本当の競争はその上で始まる。」

これが2026年のデータエンジニアリングの1行要約だ。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

- Toss SLASH 25 — https://toss.tech/slash-25

- メルカリ Engineering — https://engineering.mercari.com

- ZOZO TECH BLOG — https://techblog.zozo.com