モダン 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 エコシステム」は それらと隣り合って成長してきた分散データツール全体を指す語彙として定着している。本稿も広い意味に従う。

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

ストレージが HDFS からオブジェクトストレージ(S3/GCS/ADLS) と Ozone へ分岐した。
リソースマネージャが YARN から Kubernetes へ急速に移った。
テーブル抽象が 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 — クラウド事業者のカタログ。

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

Iceberg REST 仕様に従うか?
権限管理(RBAC/ABAC) が十分か?
データ資産だけでなく 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。中国 · 東アジアで強い。

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

ミリ秒~秒単位の応答。
数十億行のスキャン。
ユーザー対向ダッシュボードに直接付く(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年の流れを五行に圧縮するなら。

テーブルフォーマット統一。Iceberg が事実上の標準として固まり、Delta/Hudi との互換が自然になる。
カタログ標準化。Iceberg REST カタログ仕様が確定し、誰がホスティングしても同じインターフェイス。
コンピュートの分離。巨大な単一クラスタから「必要な分だけ立ち上げる」サーバーレスコンピュートへ。DuckDB · MotherDuck · Snowflake · Databricks SQL · Athena が同じ道を歩く。
AI 統合。データカタログと AI 資産カタログが統合される。モデル · 特徴量 · ノートブックが全て同じガバナンスの中に。
自然言語インターフェイス。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
Apache Ozone documentation · https://ozone.apache.org
Apache Spark 4.0 release notes · https://spark.apache.org/releases/spark-release-4-0-0.html
Apache Hive 4.0 announcement · https://hive.apache.org
Apache Kafka 4.0 release announcement · https://kafka.apache.org/blog
Apache Flink 2.0 release · https://flink.apache.org/news
Apache Iceberg specification · https://iceberg.apache.org/spec
Apache Iceberg REST catalog · https://iceberg.apache.org/docs/latest/rest-catalog
Apache Polaris · https://polaris.apache.org
Lakekeeper Iceberg catalog · https://github.com/lakekeeper/lakekeeper
Apache Gravitino · https://gravitino.apache.org
Delta Lake project · https://delta.io
Apache Hudi · https://hudi.apache.org
Trino documentation · https://trino.io/docs
Presto C++ on Velox · https://prestodb.io/blog
DuckDB documentation · https://duckdb.org/docs
dbt documentation · https://docs.getdbt.com
Apache Airflow 3 release notes · https://airflow.apache.org/blog
Dagster documentation · https://docs.dagster.io
Apache Druid · https://druid.apache.org
Apache Pinot · https://pinot.apache.org
ClickHouse documentation · https://clickhouse.com/docs
StarRocks documentation · https://docs.starrocks.io
Debezium project · https://debezium.io
Apache Pulsar · https://pulsar.apache.org
Redpanda documentation · https://docs.redpanda.com
Cloudera Data Platform · https://www.cloudera.com/products/cloudera-data-platform.html
HPE Ezmeral Data Fabric · https://www.hpe.com/us/en/software/ezmeral.html