データレイクハウス & モダンデータエンジニアリング 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を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)
        |
        v
   [ Metadata file v0.json, v1.json ... ]
        |
        v
   [ Snapshot ] ─── ある時点のテーブル状態
        |
        v
   [ Manifest list ]
        |
        v
   [ Manifest ] ─ どのデータファイルがどこにあり統計は何か
        |
        v
   [ 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で)
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()

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

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

3.1 Deltaは何が違うのか

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

   [ Delta Table ]
        |
        v
   _delta_log/
       00000000000000000000.json   ← トランザクションログ (1行ずつ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) — ニッチな魅力

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 (オブジェクトストレージ)
   |
   v
S3 Tables (Iceberg一級)  ← コンパクション・期限・統計を自動管理
   |
   v
Athena · EMR · Glue · Redshift · Trino · Spark

この1歩の意味が大きい。クラウド事業者が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対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 — 日本のファッションコマース

ZOZOTOWNの親会社。データプラットフォームはBigQuery + Dataformの組み合わせがメイン。

BigQuery中心。
Dataform — Googleが買収したdbt代替。社内標準。
データメッシュ (Data Mesh) — ドメイン別の分散運用。カタログ・ガバナンスが核となる課題。

ZOZOはデータメッシュを早期に試した日本企業の1つとして知られる。2024年ZOZO Tech Blogで「ドメイン別責任分散」を強調した記事がよく引用される。

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
変換	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年代後半に「データレイク対データウェアハウス」の議論があった。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