LabHub

ブログ

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

2026-05-16 · 38 分で読めます · #japanese#hadoop#spark#hive#kafka#flink#iceberg#trino#big-data#hdfs#yarn#lakehouse

한국어English日本語

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

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

本稿はその全景を一気に広げる。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~2012HDFS + MapReduceHadoop 1.x, Hive 0.x, Pig
2013~2016YARN + インメモリ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 ラインのその他の主な変更:

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

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

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

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

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

企業事情:

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

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

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

代表的なツールは三つ:

これらはみな同じ流れの産物だ。「ファイルシステムのように見えるが、中身はオブジェクトストレージ」。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 の核心:

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

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

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

核心的な変化:

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 の核心:

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

ツールモデル強み
Flink SQLDataStream 上の SQL厳密 1回、豊富な状態処理
ksqlDBKafka Streams 上の SQLKafka 統合、軽量
Materialize外部システム上の SQL viewOLTP 親和、Differential Dataflow
RisingWave新しいストリーミング DBPostgreSQL 互換
Arroyo新しい Rust ストリーミング SQLクラウドネイティブ

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

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

項目YARNKubernetes
対象ワークロードビッグデータ中心汎用(Web · ML · データ)
コンテナ独自(LXC/cgroups)OCI
リソースモデルCPU/メモリ/GPU豊富、拡張可能
マルチテナンシーキューベースネームスペースベース
エコシステムHadoop 中心CNCF 全体
学習曲線ビッグデータチームに馴染むプラットフォームチームに馴染む

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

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

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

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

Apache Iceberg 1.7 と 1.8

Delta Lake 4.0

Apache Hudi 1.0

選び方ガイド:

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

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

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

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

  1. Iceberg REST 仕様に従うか?
  2. 権限管理(RBAC/ABAC) が十分か?
  3. データ資産だけでなく AI 資産(モデル · 特徴量 · ノートブック) まで含むか?

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

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

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

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

Presto / PrestoDB

DuckDB 1.x

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

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

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

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 ツールではなくアプリのバックエンド)。

選び方ガイド:

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

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

dbt 1.9 の核心:

dbt のライバル:

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

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

Apache Airflow 3.0(2025年 4月 GA)

Dagster 1.9

Prefect 3.x

Argo Workflows

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

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

選び方ガイド:

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

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

Debezium 3

Flink CDC

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年にはその定義が揺らいだ。

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

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

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

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

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

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

韓国的特性:

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

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

Yahoo! Japan / LINE の統合 LY

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

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

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

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

日本的特性:

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

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

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-modern-hadoop-big-data-2026-hadoop-3-4-spark-4-hive-4-kafka-4-flink-2-iceberg-trino-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます