필사 모드: モダン Hadoop & ビッグデータエコシステム 2026 完全ガイド - Hadoop 3.4 · Spark 4 · Hive 4 · Kafka 4 · Flink 2 · Iceberg · Trino 徹底解説

プロローグ — 2026年、Hadoop は死んでいない。再配置されたのだ

「Hadoop は死んだ(Hadoop is dead)」という見出しは、2020年代初頭から毎年のように繰り返されてきた。だが 2026年の実際の風景は、そのスローガンよりずっと繊細だ。

- **新規に HDFS · YARN · MapReduce クラスタをゼロから組む人はほぼいない。** これは事実である。

- **しかし Spark、Hive、Iceberg、Kafka、Flink — Hadoop が生み出したツール群は史上もっとも強力だ。** ただ、それらが動く舞台が HDFS から S3/GCS/ADLS へ、YARN から Kubernetes へ移っただけだ。

- **Cloudera Data Platform 7** は健在で、オンプレ金融 · 公共 · 通信領域では今も大きな比重を占める。**MapR** は HPE に吸収されて HPE Ezmeral として再生した。

- **レイクハウス(Lakehouse) アーキテクチャ**こそ、Hadoop が約束した「データの単一保存場所」というビジョンの真の後継者だ。

本稿はその全景を一気に広げる。Hadoop 3.4 とその後継コンポーネント、Spark 4 · Hive 4 · Kafka 4 · Flink 2 の本当の 2026年仕様、Iceberg vs Delta vs Hudi のテーブルフォーマット戦争、Trino · Presto C++ · DuckDB · ClickHouse · StarRocks · Druid · Pinot の OLAP 風景、そして韓国 · 日本企業の実際の導入事例まで。

> 一行要約: **「Hadoop はインフラではなく語彙になった」**。HDFS/YARN/MR のような具体コンポーネントは引いていき、分散処理 · テーブルフォーマット · ストリーム · カタログのような概念だけが残り、クラウドの上で再び組み立てられている。

1章 · 全体像 — Hadoop エコシステム 25年の軌跡

2006年に Doug Cutting が Hadoop を始めた。2026年時点で、その上に育ったツール群は次の表に圧縮される。

| 時期 | キーワード | 代表ツール |

| --- | --- | --- |

| 2006~2012 | HDFS + MapReduce | Hadoop 1.x, Hive 0.x, Pig |

| 2013~2016 | YARN + インメモリ | Hadoop 2, Spark, Tez, Impala |

| 2017~2020 | クラウド移行 | EMR, Dataproc, HDInsight |

| 2021~2024 | レイクハウス | Iceberg, Delta, Hudi, Trino, dbt |

| 2025~2026 | モジュラー · ストリーム優先 | Kafka 4, Flink 2, Polaris, Lakekeeper |

「Hadoop = HDFS + YARN + MapReduce」と狭く定義することもできるが、現場の会話で「Hadoop エコシステム」は **それらと隣り合って成長してきた分散データツール全体**を指す語彙として定着している。本稿も広い意味に従う。

主要な変化を三つに絞ると次のとおりだ。

1. **ストレージ**が HDFS からオブジェクトストレージ(S3/GCS/ADLS) と Ozone へ分岐した。

2. **リソースマネージャ**が YARN から Kubernetes へ急速に移った。

3. **テーブル抽象**が Hive Metastore から Iceberg · Delta · Hudi のようなオープンテーブルフォーマットへ進化した。

この三軸が 2026年のデータプラットフォーム設計におけるほぼ全ての意思決定を支配する。

2章 · Hadoop 3.4 と 3.5 — 核心は Erasure Coding と Ozone

Apache Hadoop の現在の安定ラインは **3.4.x** で、3.5 は 2026年前半にベータとして動いている。新規クラスタを組むことはなくても、既存オンプレ運用チームにとっては依然として重要なラインだ。

3.x ラインの最大の変化は二つだ。

**第一に、Erasure Coding(EC)**。HDFS は伝統的にデータを 3重レプリケーション(3x replication) して信頼性を得ていた。1PB を保存するには実際 3PB が必要だった。EC はデータを k 個のブロックと m 個のパリティブロックに分けて保存する。RS-10-4(10 データ + 4 パリティ) を使うと約 1.4PB だけで同じ信頼度を得られる。**約 40% のストレージ節約**である。代わりに符号化 · 復号化に CPU をより使い、小さいファイルには不向きだ。だから EC は **コールド階層**にまず適用する。

**第二に、Apache Ozone**。Hadoop のサブプロジェクトとして始まったオブジェクトストレージだ。核は「S3 API を提供しながら HDFS のスループットと強整合性を保つ」こと。NameNode 単一ボトルネック問題を、分散型 Ozone Manager + Storage Container Manager 構造で解いた。数十億ファイルを扱うオンプレ環境で HPDF の実質的な後継者として定着しつつある。

3.4 ラインのその他の主な変更:

- **YARN の GPU · FPGA リソースモデル**安定化。ML ワークロードを YARN 上でも自然に。

- **HDFS Router-based Federation** 成熟。複数 NameNode をルーターの背後に隠して水平拡張。

- **Java 17/21 ランタイム**正式サポート。

「Hadoop を新規に敷く」シナリオは稀だが、通信 · 金融 · 公共 · 研究所の既存クラスタが 3.4 へ移行する流れは確かに存在する。

3章 · 「Hadoop は死んだか」— 事実関係

この問いに答えるには、まず何を「Hadoop」と呼ぶかを絞る必要がある。

**狭義の Hadoop(HDFS + YARN + MapReduce コア)**:

- 新規採用: 事実上停滞。新規 SaaS · スタートアップはほぼ全て、初日からクラウドオブジェクトストレージを使う。

- 既存運用: 依然として巨大。CDP 7 ベースの大規模クラスタが世界中で数千動いており、韓国でも通信 · 金融 · 公共 · ゲーム企業が運用中だ。

- 新機能追加: 鈍化。コアより Ozone · Erasure Coding のような補完コンポーネント中心へ。

**広義の Hadoop エコシステム(Spark/Hive/Kafka/Flink/Iceberg/...)**:

- 爆発的に成長中。Spark のダウンロードは毎年最高記録。Iceberg は標準化が進行。Kafka は KRaft への切り替え完了。

- ただし、それらが **HDFS の上で動く必要はない**。同じコンポーネントが S3/GCS/ADLS 上で、Kubernetes 上で、EMR/Dataproc/HDInsight/Databricks/Snowflake 上で動く。

**企業事情**:

- **Cloudera + Hortonworks** 合併後 CDP(Cloudera Data Platform) 7 へ統合。2021年に KKR · CD&R が約 53億ドルで買収して非公開化。売上は依然大きい。

- **MapR** は 2019年に HPE が買収、2024年時点で HPE Ezmeral Data Fabric として再ブランディング。

- **Pivotal** の Hadoop ラインは消えた。分離された Greenplum ラインのみ残る。

- **DataStax · Confluent · Databricks** のような「ポスト Hadoop」企業群が市場影響力としてはより大きい状態にある。

**結論**: HDFS/YARN/MR の新規採用は減ったが、「Hadoop が作った語彙の上で動く分散データツール」は史上もっとも活発だ。スローガンと現実の距離、そこに本稿の出発点がある。

4章 · HDFS + Ozone — オブジェクトストレージへの橋

HDFS はブロックベース · 強整合性 · POSIX-like なセマンティクスを持つ分散ファイルシステムだ。S3 はオブジェクトベース · 結果整合性(2020年以降は強整合性に改善) · HTTP API である。二つのモデルは遠く見えるが、2020年代半ばの大きな出来事は **HDFS ユーザが S3 互換 API へ自然に渡る通路ができた**ことだ。

代表的なツールは三つ:

- **Apache Ozone** — Hadoop サブプロジェクト。S3 互換オブジェクトストレージ + HDFS 級スループット。

- **MinIO** — S3 互換のセルフホストオブジェクトストレージ。Kubernetes ネイティブ。

- **JuiceFS** — オブジェクトストレージの上に POSIX 互換ファイルシステムを載せるメタデータレイヤー。

これらはみな同じ流れの産物だ。**「ファイルシステムのように見えるが、中身はオブジェクトストレージ」**。Spark/Hive/Trino のような計算エンジンが hdfs://、s3a://、ofs://、jfs:// など多様な URI スキームの背後で抽象化され、同じコードが動く。

韓国ではこの流れの代表が **Kakao i Cloud Object Storage**、**Naver Cloud Object Storage**、**NHN NCP Object Storage** のような自社オブジェクトストレージへの移行だ。日本では **NTT ドコモ**、**KDDI**、**SoftBank** がいずれも自社オブジェクトストレージを持つ。

5章 · Apache Spark 3.5 と 4.0 — ANSI モード、Spark Connect、English SDK

Spark は 2026年も依然として分散データ処理の事実上の標準だ。安定ラインは **3.5.x**、4.0 は 2024年 6月正式リリース後に安定化し、2026年には 4.x が本格普及する時期にある。

4.0 の核心的な変化は五つ。

**1. ANSI モードのデフォルト ON**。これまで Spark の SQL は PostgreSQL/Snowflake に比べ寛容(forgiving) な振る舞いだった。オーバーフローや誤ったキャストが黙って NULL を返すような挙動だ。4.0 から ANSI モードがデフォルトなので、明示的にオフにしない限り SQL 標準に沿った強い検査が走る。移行時に最もよく見る破綻原因である。

**2. Spark Connect の安定化**。クライアントとサーバーを gRPC で分離するアーキテクチャ。ノートブックで巨大な Spark Driver JVM を立ち上げる必要なく、軽いクライアントがリモートクラスタに接続する。Databricks Connect、JetBrains の Big Data Tools などがこの上で動く。

**3. PySpark の Python UDF 安定化と Pandas API on Spark**。Koalas で始まった取り組みが Pandas API on Spark に統合され、4.0 では Pandas 2.x と互換になる。

**4. Streaming 強化**。Structured Streaming のステートフル処理(stateful processing) API が整理された。`transformWithState` という統一 API を通じ、RocksDB · インメモリなどの状態ストアを同じ抽象で扱う。

**5. English SDK プレビュー**。「自然言語で PySpark を書く」試み。実験段階だが、LLM との統合が 4.x ラインの大きな方向性を示している。

Databricks の **Photon** エンジンは別の話だ。Spark API 互換の C++ ベクトル化実行器で、Databricks Runtime のみに入る。オープンソース Spark とは別トラックである。

6章 · Apache Hive 4.0 — 死ななかった SQL 標準、Iceberg を抱える

Hive はかつて「Hadoop の SQL」だった。2010年代後半には Spark SQL と Presto に押されて消えるように見えたが、**Hive 4.0**(2023年 4月 GA) を契機に明確な復活シグナルを送っている。

Hive 4.0 の核心:

- **Iceberg ネイティブ統合**。`CREATE TABLE ... STORED BY ICEBERG` 一行で Iceberg テーブルが作られる。既存 Hive テーブル ↔ Iceberg テーブル間の移行も SQL で支援。

- **LLAP(Live Long And Process)** 安定化。デーモンプロセスを生かしておくことでクエリ起動遅延を大きく削減。短いインタラクティブクエリに適する。

- **Tez を既定実行エンジンに**。旧 MapReduce エンジンは deprecated。Tez DAG が標準。

- **ACID トランザクション v2**。Merge · Update · Delete が安定。コンパクションが自動。

依然 Hive を使う領域は明確だ。**大規模バッチ、メタデータが巨大なデータウェアハウス、既存 Hive UDF 資産が大きい現場**である。2026年の韓国 · 日本 · 中国の通信 · 金融 · ゲーム企業の多くが Hive を中核 SQL エンジンとして維持している。

7章 · Apache Kafka 4.0 — Zookeeper の時代を終わらせる

Kafka は 2026年のビッグデータエコシステムにおいて最強の単一コンポーネントの一つだ。**Kafka 4.0**(2025年 3月 GA) はその地位を固めた。

核心的な変化:

- **KRaft モード GA、Zookeeper 削除完了**。Kafka はこれまで Zookeeper を依存として要求してきた。KRaft(Kafka Raft Metadata mode) が 2023年から段階導入され、4.0 で Zookeeper モードは完全に deprecated。運用が圧倒的に単純になった。

- **Tiered Storage の安定化**。ホットデータはローカルディスク、コールドデータは S3 のようなオブジェクトストレージへ自動移動。保持期間の長いトピックの保存コストを大きく下げる。

- **キューセマンティクスの導入**。従来のトピックは publish-subscribe だった。KIP-932 で「Share Group」概念が導入され、真のキューパターンが Kafka に到来。RabbitMQ 的ワークロードの一部が Kafka に移る可能性。

- **Kafka Streams** と **ksqlDB** も一緒に進化。Confluent が ksqlDB のオープンソースラインを整理し、Confluent Cloud 寄りに重心を移している。

Kafka のライバルも強くなった。

- **Apache Pulsar 4.0** — BookKeeper ベースの分離ストレージアーキテクチャ。マルチテナンシーとジオレプリケーションが強い。

- **Redpanda 24.x** — C++ で書き直された Kafka 互換ブローカー。Zookeeper も JVM も不要。Kafka API 100% 互換を保ちつつ単一バイナリ。

- **WarpStream** — Confluent に買収された「S3 上の Kafka」変種。

2026年に新規にキュー / ストリームのバックボーンを選ぶなら、「Kafka + KRaft + Tiered Storage」あるいは「Redpanda 単一バイナリ」の二つが最も一般的な選択だ。

8章 · Apache Flink 2.0 — Disaggregated State と ForSt

Flink はかつて Spark Streaming に押されているように見えたが、「ストリームを一級市民(stream-first)」とする哲学で、真の低遅延 · 厳密 1回(exactly-once) 処理が必要な領域を獲った。**Flink 2.0**(2025年 3月 GA) はその強みをさらに押し進めた。

Flink 2.0 の核心:

- **Disaggregated State Storage**。伝統的に Flink はタスクマネージャ(Task Manager) に張り付くローカルディスクに RocksDB の状態を置いていた。Kubernetes · クラウド環境ではノード入れ替え時の状態復元が高価だ。2.0 は状態をオブジェクトストレージ(S3 等) に置き、その上にキャッシュ · ローカル SSD を配する分離アーキテクチャを正式採用。

- **ForSt** — Flink 専用に作られた RocksDB ベースの状態エンジン。オブジェクトストレージ親和的に LSM ツリーを調整。

- **Materialized Tables**。SQL で「この結果をリアルタイムに保て」と宣言すれば、Flink がバックグラウンドのストリームジョブとしてそれを維持。dbt 風の宣言的モデリング + Flink ストリーミング。

- **Flink CDC** が独立したサブプロジェクトとして安定化。Debezium の代替。

ストリーミング SQL の風景は 2026年にこう整理される。

| ツール | モデル | 強み |

| --- | --- | --- |

| Flink SQL | DataStream 上の SQL | 厳密 1回、豊富な状態処理 |

| ksqlDB | Kafka Streams 上の SQL | Kafka 統合、軽量 |

| Materialize | 外部システム上の SQL view | OLTP 親和、Differential Dataflow |

| RisingWave | 新しいストリーミング DB | PostgreSQL 互換 |

| Arroyo | 新しい Rust ストリーミング SQL | クラウドネイティブ |

9章 · YARN vs Kubernetes — リソースマネージャの世代交代

Hadoop YARN は 2013年の登場以来、「分散データワークロードのリソースマネージャ」の事実上の標準だった。2020年代にその座を **Kubernetes** が急速に獲った。

| 項目 | YARN | Kubernetes |

| --- | --- | --- |

| 対象ワークロード | ビッグデータ中心 | 汎用(Web · ML · データ) |

| コンテナ | 独自(LXC/cgroups) | OCI |

| リソースモデル | CPU/メモリ/GPU | 豊富、拡張可能 |

| マルチテナンシー | キューベース | ネームスペースベース |

| エコシステム | Hadoop 中心 | CNCF 全体 |

| 学習曲線 | ビッグデータチームに馴染む | プラットフォームチームに馴染む |

K8s 上でビッグデータを動かす標準パターン:

- **Spark on Kubernetes** — 公式サポート。Spark Operator(Google) と native scheduler の二つの道。

- **Flink Kubernetes Operator** — Flink 1.15+ で公式。

- **Kafka は Strimzi Operator で**。

- **YuniKorn** — Apache YuniKorn は K8s 上でキュー · リソース共有 · スケジュールポリシーといった YARN 的機能を提供する。

依然 YARN の居場所はある。**CDP を運用している現場、巨大な単一クラスタにビッグデータだけを動かす場所、セキュリティ · 隔離要件が非常に強い場所**。だが新規プラットフォーム設計の最初の選択肢はほぼ常に K8s だ。

10章 · テーブルフォーマット戦争 — Iceberg、Delta、Hudi

データレイクに ACID トランザクション · スキーマ進化 · タイムトラベルといったデータウェアハウス機能を加えるのが **オープンテーブルフォーマット**の約束だ。2026年の風景は三候補に圧縮される。

**Apache Iceberg 1.7 と 1.8**

- 最も速く標準化中。AWS · Snowflake · Databricks · Google · Cloudera が皆サポート。

- **REST カタログ仕様** が標準化。エンジン非依存性が本物に。

- **Iceberg-Rust** — Rust 実装が安定化。DuckDB · Polars · Trino C++ のような軽量エンジンが Iceberg を直接読む。

- **Apache Polaris**(Snowflake 寄贈)、**Lakekeeper**(Rust ベース)、**Apache Gravitino**(データカタログ) のようなカタログ選択肢が豊富。

**Delta Lake 4.0**

- Databricks が作ったフォーマット。2022年に Linux Foundation に移管。

- Delta Universal Format(UniForm) — Delta で書けば Iceberg · Hudi としても読める。

- Delta Sharing — Delta テーブルを安全に共有。

- 強み: Databricks 統合、最も成熟した ACID 実装。

**Apache Hudi 1.0**

- Uber 発。アップサート · CDC に特化。

- Merge-on-Read と Copy-on-Write の 2モード。

- カタログ統合 · インデックスが強い。

**選び方ガイド**:

- エンジン非依存が最優先なら Iceberg。

- Databricks 中心なら Delta。

- 頻繁なアップサート · リアルタイム CDC が中心なら Hudi。

三フォーマットは次第に収束しつつある。2026年時点では、同じデータを Iceberg と Delta の両方で読めるようにする変換 · ミラーツールがありふれている。

11章 · カタログの時代 — Polaris、Lakekeeper、Gravitino、Unity

テーブルフォーマットが標準になると、次の戦線は **カタログ**だ。カタログとは「どのテーブルがどこにあり、どのスキーマで、誰がアクセスできるか」を管理するサービスだ。

- **Apache Polaris** — Snowflake が 2024年に寄贈した Iceberg REST カタログ実装。クラウド中立を標榜。

- **Lakekeeper** — Rust で書かれた Iceberg REST カタログ。軽量で K8s 親和的。

- **Apache Gravitino** — Datastrato が作ったメタカタログ。Iceberg · Delta · Hudi · Hive を一つのインターフェイスで。

- **Unity Catalog** — Databricks のカタログ。2024年に一部オープンソース化。データ · AI 資産を統合管理。

- **Nessie** — Dremio が始めた Git のようなデータカタログ。ブランチ · タグ · マージでデータバージョン管理。

- **AWS Glue Data Catalog**、**Google Dataplex** — クラウド事業者のカタログ。

選定時の核心質問は三つ。

1. **Iceberg REST 仕様**に従うか?

2. **権限管理**(RBAC/ABAC) が十分か?

3. **データ資産だけでなく AI 資産**(モデル · 特徴量 · ノートブック) まで含むか?

2026年に新たにカタログを定めるなら、Polaris · Lakekeeper · Unity の中から自分のインフラに合うものを選ぶ流れだ。

12章 · Trino、Presto、DuckDB — クエリエンジンの三階級

レイクの上で SQL を動かすエンジンは、2026年時点で三階級に分かれる。

**Trino 460+** — 旧 PrestoSQL の分岐。Starburst が商用化。ペタバイト規模のフェデレーション SQL。

- Fault-tolerant execution(FTE) — 大きなクエリでノード障害時に部分再起動。Exchange データを外部ストレージに置く。

- Pinot/Druid/Iceberg/Delta/Hudi などを一つの SQL で束ねる。

- Velocity が非常に速い。2025年中に 460 を超えた。

**Presto / PrestoDB**

- 元祖 Presto。2019年に Linux Foundation へ。Meta が主に貢献。

- 2024年以降 **Presto C++(Velox ベース)** が主力。Meta は社内で Presto C++ にデータを流している。

**DuckDB 1.x**

- 組み込み型分析 DB。単一バイナリ。Pandas · Polars · R · CSV · Parquet · Iceberg を全て SQL で。

- ノートブックの中、Lambda の中、エッジで動く新カテゴリ。

- 「クエリエンジンはもう巨大なクラスタである必要がない」というパラダイムの代表。

**MotherDuck** — DuckDB をクラウドホスティングで束ねる会社。ローカル + クラウドのハイブリッド。

**Velox** — Meta が作った C++ ベクトル化実行エンジン。Presto C++ · Spark Gluten · Verdict などが、その上で動く共通エンジンを目指す。

選択はデータ規模と実行モデルによる。

- 巨大なフェデレーション SQL → Trino

- Meta · 一部ビッグテックの社内標準 → Presto C++

- 単一ノード · 組み込み · ノートブック → DuckDB

13章 · OLAP の風景 — Druid、Pinot、ClickHouse、StarRocks

リアルタイム分析(OLAP) カテゴリの 2026年風景。

**Apache Druid** — 時系列 · イベント分析。2011年に Metamarkets で開始。リアルタイム取り込み + 事前集計。

**Apache Pinot** — LinkedIn 発。リアルタイム取り込み + ユーザー対向分析。Uber · LinkedIn · Stripe のような巨大トラフィックで実証済み。

**ClickHouse 24.x** — Yandex(現在は ClickHouse Inc.) が作ったカラム型 OLAP DB。単一ノード性能が圧倒的。ClickHouse Cloud は 2022年リリース後に急成長。

**StarRocks** — Apache Doris の商用分岐。MPP OLAP DB。Iceberg · Hudi · Delta を直接クエリ。

**Apache Doris** — Baidu 発の MPP OLAP。中国 · 東アジアで強い。

これらの共通点は、次の三つを同時に追求することだ。

1. **ミリ秒~秒単位の応答**。

2. **数十億行のスキャン**。

3. **ユーザー対向ダッシュボードに直接付く**(BI ツールではなくアプリのバックエンド)。

選び方ガイド:

- 単一クラスタ · 複雑なクエリ → ClickHouse

- リアルタイム取り込み · ユーザー対向 → Pinot、Druid

- Iceberg / レイクの上でクエリ → StarRocks、Trino

- 一つのノートブック · 組み込み → DuckDB

14章 · dbt 1.9 と dbt Mesh — 変換レイヤーの標準

dbt(data build tool) は「SQL でデータモデリングをする」という単純なアイデアで、モダンデータスタックの変換レイヤー標準になった。

dbt 1.9 の核心:

- **dbt Mesh** — 大組織で dbt プロジェクトをドメイン別に分割し、互いのモデルをコントラクトで公開。

- **Group / Access** — モデルをグループ化し、外部公開可否を明示。

- **Semantic Layer** が dbt Cloud の中核商品として定着。メトリック定義を一箇所で。

- **dbt Fusion**(2025年発表) — 既存の Python ベースコンパイラを Rust で書き直し。実行速度が大幅改善。

dbt のライバル:

- **SQLMesh** — Tobiko Data。dbt の限界(Jinja、実行モデル) を再設計。

- **Coalesce** — GUI ベースのデータ変換。

- **dbt Cloud** と **dbt Core** のライセンス分離が 2024年に話題となったが、コアは依然オープン。

15章 · オーケストレーション — Airflow 3.0、Dagster、Prefect、Argo

データパイプラインをスケジュール · 管理するオーケストレータの風景。

**Apache Airflow 3.0**(2025年 4月 GA)

- 最大の変化: **タスク隔離(task isolation) の安定化**。タスクが別コンテナで動くのが標準に。

- **Task SDK** が分離されワーカー依存性が軽量に。

- **複数 DAG バージョン**のような中核運用機能を整理。

- 依然として最大のコミュニティ。

**Dagster 1.9**

- Software-Defined Assets — DAG のノードが「どのデータを作る責任を持つか」で定義される。Airflow と異なるメンタルモデル。

- 資産カタログ、データ品質、バックフィルが一級市民。

- 次第にデータプラットフォームの一級ツールへ。

**Prefect 3.x**

- 「Pythonic」な使い心地。デコレータ一行で関数がタスクになる。

- 動的ワークフローに強い。

**Argo Workflows**

- Kubernetes ネイティブ。CI/CD のようなコンテナワークフローに強い。

- データパイプライン用にも使われる。

**Mage** — ノートブック + オーケストレーション。ノーコード / ローコード。

**Kestra** — YAML/JS ベースのオーケストレータ。Java バックエンド。

選び方ガイド:

- 大組織 · 既存資産 → Airflow 3

- 資産中心 · データプラットフォーム → Dagster

- 軽量な動的ワークフロー → Prefect

- コンテナ · K8s 中心 → Argo

16章 · CDC の風景 — Debezium 3、Flink CDC、Estuary

運用 DB からデータレイク / ウェアハウスへリアルタイム同期する **Change Data Capture(CDC)** の 2026年風景。

**Debezium 3**

- Red Hat が主導。PostgreSQL · MySQL · MongoDB · Oracle · SQL Server · Db2 などの DB のログを読み Kafka に流す。

- 3.x で運用性 · メモリ · スキーマ進化が大幅改善。

**Flink CDC**

- Debezium のコアを Flink に持ち込む。Kafka なしに DB → Flink → Iceberg を直結。

**Estuary Flow** — SaaS の CDC。

**Airbyte** — オープンソース ELT。CDC も支援するが強みはバッチコネクタ。

**Fivetran** — 最も成熟した商用 CDC/ELT。

**Sequin** — PostgreSQL 専門 CDC。Webhook · Kafka 出力。

**典型アーキテクチャ**:

[PostgreSQL] → [Debezium] → [Kafka] → [Flink/Spark] → [Iceberg] → [Trino/Spark SQL]

または

[PostgreSQL] → [Flink CDC] → [Iceberg]

運用 DB の変化が 1~30秒以内にレイクへ反映されるのが 2026年の標準だ。

17章 · レイクハウスアーキテクチャ — 単一真実保存所の復活

レイクハウスは「データレイク(安価な生保存所) + データウェアハウス(ACID、スキーマ、性能)」の結合だ。2026年標準アーキテクチャはこう整理される。

**Bronze · Silver · Gold メダリオンアーキテクチャ**:

| レイヤー | 形 | ツール |

| --- | --- | --- |

| Bronze(生) | CDC / イベントそのまま | Kafka, Iceberg, S3 |

| Silver(クレンジング) | 標準化 · 重複除去 | Spark, Flink, dbt |

| Gold(サービング) | 集計 · ドメインモデル | dbt, Spark, Trino |

ストレージはオブジェクトストレージ + Iceberg/Delta/Hudi テーブル。コンピュートは Spark/Flink/Trino/DuckDB といったエンジンが同じテーブルを共有する。カタログ(Polaris/Unity/Gravitino) が、どのテーブルがどこにあるか · 誰に見せるかを管理する。

このアーキテクチャの約束は単純だ。**一つのデータ、複数のエンジン、統一された権限**。Hadoop が約束したが実際には難しかったあのビジョンが、2026年クラウドオブジェクトストレージ + オープンテーブルフォーマットの上で本当に動く。

18章 · モダンデータスタックの進化 — 2020 → 2026

2020年代初頭「モダンデータスタック(MDS)」という用語が流行した。その核は **Fivetran(取り込み) + Snowflake(ウェアハウス) + dbt(変換) + Looker(BI)** という四ツールの組合せだった。

2026年にはその定義が揺らいだ。

- **取り込み** → Fivetran/Airbyte 以外に Flink CDC、Debezium のようなストリーム CDC が大きな比重を占める。

- **保存** → Snowflake 単独ではなく Snowflake + Databricks + セルフホストレイクハウスが共存。

- **変換** → dbt 以外に SQLMesh、dbt Fusion、Coalesce。

- **BI** → Looker 以外に Metabase、Superset、Hex、Mode が爆発的。

- **AI/ML 統合** → 以前は別トラックだった ML が同じデータの上で動く。フィーチャストア · ベクトル DB · LLM が追加レイヤーに。

要約すると **「モダンデータスタック → モダンデータ · AI スタック」** に語彙が移った。データエンジニアと ML エンジニアが同じカタログ · 同じテーブルを共有する図が標準になった。

19章 · 韓国企業のビッグデータ導入風景

韓国市場では 2026年時点で次のパターンが明確だ。

**通信 · 金融 · 公共: CDP/Hortonworks の残存**

- KT · SK テレコム · LGU+ · KB · 新韓 · ハナ · NH のような大手は依然として巨大な CDP/HDP ベースクラスタを動かしている。2026年もその上で数万件の Spark/Hive ジョブが動く。

- 同時に自社クラウド(KT Cloud、NCloud、NHN Cloud) の上で Iceberg · Trino ベースのレイクハウスを新規構築する流れ。

**ゲーム · インターネット: モダンデータスタック**

- **Naver** — 社内ビッグデータプラットフォームが Spark 中心。2024年以降 Iceberg と Trino を積極導入。

- **Kakao** — 独自 ML プラットフォームとデータプラットフォーム。Spark、Flink、Druid を広範に使用。

- **Coupang** — かつて Hadoop を広範に使ったが、2020年代半ばから AWS ベースの Iceberg/Spark/Trino へ転換し Hadoop 依存を縮小。

- **LINE+** — Snowflake と独自レイクハウスを併用。2024~2025年の間に一部ドメインを Snowflake へ移行。

- **NCsoft · Nexon · Netmarble** — ゲームログ · 決済 · ゲーム内イベントが巨大で、Kafka + Flink + Iceberg/Druid が中核。

**スタートアップ: クラウドマネージド優先**

- BigQuery · Snowflake · Databricks が第一選択肢。dbt は事実上の標準。

- 一部はセルフホスト ClickHouse/Trino でコスト最適化。

**韓国的特性**:

- 政府 · 公共データ規制により **オンプレ · 自社クラウド**比重がグローバル平均より高い。

- そのため CDP のようなオンプレビッグデータプラットフォームの寿命が長い。

- 同時にゲーム · EC · フィンテックは速やかにクラウドレイクハウスへ移行中。

20章 · 日本企業のビッグデータ導入風景

日本市場は韓国と似ているが、少し色合いが違う。

**Yahoo! Japan / LINE の統合 LY**

- 2023年に Yahoo! Japan と LINE が LY に合流。データプラットフォーム統合は進行中。両社ともに巨大な Hadoop/Spark 資産を持つ。

- 広告 · 検索 · メッセンジャーの巨大イベントストリームを Kafka + Spark Streaming + Hadoop で処理してきた歴史が長い。

**Cookpad** — レシピプラットフォーム。Redshift と BigQuery を中心とした比較的モダンなデータスタック。dbt 導入初期事例。

**Mercari** — 巨大な ML プラットフォーム。BigQuery + Vertex AI + Feast フィーチャストアといったクラウドネイティブ構成。

**Rakuten** — Hadoop ベースの巨大インフラを持つが、2020年代半ばからクラウド移行が進行中。独自のデータメッシュモデルを試行。

**DeNA · CyberAgent · GREE** — モバイルゲーム · 広告データを BigQuery · Snowflake へ。

**日本的特性**:

- 通信(NTT ドコモ、KDDI、ソフトバンク) の自社クラウド比重が大きい。

- 金融は **オンプレ + Cloudera** の比重が依然高い。

- 広告 · ゲーム領域は急速にクラウド + モダンデータスタックへ移行。

韓国 · 日本どちらも「オンプレビッグデータ資産が非常に大きく、その上に新レイクハウスを載せるデュアルトラック」が現実だ。

21章 · 実戦アーキテクチャパターン 5つ

2026年に頻出する五つのパターン。

**パターン 1 · クラシックバッチレイクハウス(中規模)**

[運用 DB] → [Airbyte/Fivetran] → [Iceberg on S3] → [dbt + Spark] → [Trino] → [Metabase]

**パターン 2 · CDC ストリーミングレイクハウス(イベント中心)**

[PostgreSQL/MySQL] → [Debezium → Kafka] → [Flink → Iceberg] → [Trino/Spark]

↘ [ClickHouse/Pinot] (リアルタイムダッシュボード)

**パターン 3 · ゲーム · 広告イベント分析**

[クライアント] → [Kafka] → [Flink] → [Druid/Pinot] → [ユーザー対向ダッシュボード]

↓

[Iceberg] → [Spark バッチ分析]

**パターン 4 · ML プラットフォーム**

[データレイク(Iceberg)] → [Spark/Polars 特徴量化] → [Feast フィーチャストア]

↓ ↓

[学習(Spark MLlib, Ray)] [オンラインサービング]

↓

[モデルレジストリ(MLflow)]

**パターン 5 · 組み込み分析(小チーム · ノートブック)**

[Parquet on S3] → [DuckDB/Polars] → [Streamlit/ノートブック] → [共有]

同じデータの上で五つの異なるアーキテクチャが共存するのが 2026年の風景だ。一つの会社の中で複数のパターンが同時に動くのもよくある。

22章 · 実戦の落とし穴 — やらないと必ず後悔すること

**1. Small file 問題** — オブジェクトストレージに小さなファイルが数億個積もるとメタデータ · リスティングコストが爆発する。Iceberg の compaction、OPTIMIZE のような作業を定期的に走らせること。

**2. スキーマ進化の合意** — Iceberg/Delta はスキーマ進化をサポートするが、「どの変化を許すか」は合意の問題だ。カラム名変更のような壊れる変化を防ぐコントラクトが必要。

**3. コスト可視化** — S3 リクエスト料金、Snowflake クレジット、BigQuery スロット — クラウドビッグデータの本当のコストは計算とデータ移動だ。最初からコストラベリングを強制すること。

**4. CDC のバックフィル** — 新規 CDC パイプラインを起動する時、過去データのバックフィルをどうするかが最も厄介だ。Debezium の snapshot モードと incremental snapshot を事前検証すること。

**5. カタログ · 権限の一元化** — 複数エンジンが同じテーブルを見るなら、権限もカタログ一箇所で管理しなければならない。エンジン別に権限が散る瞬間にガバナンスが崩れる。

**6. ストリームとバッチのセマンティクスの違い** — 「厳密 1回」の定義はシステムごとに違う。Flink · Kafka · Spark Streaming のセマンティクスを正確に理解すること。

**7. テスト環境のデータ** — 運用データをそのまま使うと GDPR/PIPA 違反だ。マスキング · 合成データツールを最初から設計すること。

23章 · 学習ロードマップ — どこから始めるか

2026年に新たにデータエンジニアになるなら、次の順序を勧める。

**0段階 · SQL と Python を深く**。あらゆるツールの共通言語だ。

**1段階 · Spark と dbt**。Spark で「分散処理がどう動くか」を体得し、dbt で「モデリングを SQL でする」という語彙を身につける。

**2段階 · Kafka と Flink**。ストリーム処理のセマンティクスを身につける。厳密 1回 · ウォーターマーク · チェックポイント。

**3段階 · テーブルフォーマット**。Iceberg を直接触り、Delta/Hudi と比較する。

**4段階 · オーケストレーション**。Airflow か Dagster のどちらかを深く。

**5段階 · 運用の視点**。コスト · 観測性(observability) · データ品質 · ガバナンス。ここが本物のシニアを決める段階だ。

**6段階 · ML との結合**。フィーチャストア、ベクトル DB、LLM パイプライン。

この順序で進めば 2~3年以内に「モダンデータプラットフォーム」の全領域を扱えるようになる。

24章 · 5年後、ビッグデータはどこへ向かうか

今後 5年の流れを五行に圧縮するなら。

1. **テーブルフォーマット統一**。Iceberg が事実上の標準として固まり、Delta/Hudi との互換が自然になる。

2. **カタログ標準化**。Iceberg REST カタログ仕様が確定し、誰がホスティングしても同じインターフェイス。

3. **コンピュートの分離**。巨大な単一クラスタから「必要な分だけ立ち上げる」サーバーレスコンピュートへ。DuckDB · MotherDuck · Snowflake · Databricks SQL · Athena が同じ道を歩く。

4. **AI 統合**。データカタログと AI 資産カタログが統合される。モデル · 特徴量 · ノートブックが全て同じガバナンスの中に。

5. **自然言語インターフェイス**。SQL を書く代わりに LLM に問い、データエンジニアが検証するワークフローが標準になる。dbt · Looker · Snowflake が皆その方向。

Hadoop の語彙は 25年経っても生き残る。だがその上で動くツールは進化し続ける。この流れの真ん中にいるということは、2026年でも依然興味深い場所だ。

エピローグ — 死のスローガンと本当の風景

「X is dead」というスローガンはほぼ常に強すぎる。2020年に「Hadoop is dead」だったなら、2024年には「Spark is dead、DuckDB がすべてをやる」、2026年には「データエンジニアは LLM に置き換えられる」が新しいスローガンだ。だが現場はもっと繊細でもっと興味深い。

**Hadoop は死んでいない**。それが作った語彙は 2026年も依然としてあらゆるデータシステムの骨格だ。ただし、その言葉が動く舞台が変わっただけだ。その変化のど真ん中に立っているということは、2026年もビッグデータエンジニアとして最高に面白い瞬間にいるということだ。

References

- Apache Hadoop project · [https://hadoop.apache.org](https://hadoop.apache.org)

- Apache Ozone documentation · [https://ozone.apache.org](https://ozone.apache.org)

- Apache Spark 4.0 release notes · [https://spark.apache.org/releases/spark-release-4-0-0.html](https://spark.apache.org/releases/spark-release-4-0-0.html)

- Apache Hive 4.0 announcement · [https://hive.apache.org](https://hive.apache.org)

- Apache Kafka 4.0 release announcement · [https://kafka.apache.org/blog](https://kafka.apache.org/blog)

- Apache Flink 2.0 release · [https://flink.apache.org/news](https://flink.apache.org/news)

- Apache Iceberg specification · [https://iceberg.apache.org/spec](https://iceberg.apache.org/spec)

- Apache Iceberg REST catalog · [https://iceberg.apache.org/docs/latest/rest-catalog](https://iceberg.apache.org/docs/latest/rest-catalog)

- Apache Polaris · [https://polaris.apache.org](https://polaris.apache.org)

- Lakekeeper Iceberg catalog · [https://github.com/lakekeeper/lakekeeper](https://github.com/lakekeeper/lakekeeper)

- Apache Gravitino · [https://gravitino.apache.org](https://gravitino.apache.org)

- Delta Lake project · [https://delta.io](https://delta.io)

- Apache Hudi · [https://hudi.apache.org](https://hudi.apache.org)

- Trino documentation · [https://trino.io/docs](https://trino.io/docs)

- Presto C++ on Velox · [https://prestodb.io/blog](https://prestodb.io/blog)

- DuckDB documentation · [https://duckdb.org/docs](https://duckdb.org/docs)

- dbt documentation · [https://docs.getdbt.com](https://docs.getdbt.com)

- Apache Airflow 3 release notes · [https://airflow.apache.org/blog](https://airflow.apache.org/blog)

- Dagster documentation · [https://docs.dagster.io](https://docs.dagster.io)

- Apache Druid · [https://druid.apache.org](https://druid.apache.org)

- Apache Pinot · [https://pinot.apache.org](https://pinot.apache.org)

- ClickHouse documentation · [https://clickhouse.com/docs](https://clickhouse.com/docs)

- StarRocks documentation · [https://docs.starrocks.io](https://docs.starrocks.io)

- Debezium project · [https://debezium.io](https://debezium.io)

- Apache Pulsar · [https://pulsar.apache.org](https://pulsar.apache.org)

- Redpanda documentation · [https://docs.redpanda.com](https://docs.redpanda.com)

- Cloudera Data Platform · [https://www.cloudera.com/products/cloudera-data-platform.html](https://www.cloudera.com/products/cloudera-data-platform.html)

- HPE Ezmeral Data Fabric · [https://www.hpe.com/us/en/software/ezmeral.html](https://www.hpe.com/us/en/software/ezmeral.html)