Hadoop は死んだか — big data stack 進化史、Hadoop から Lakehouse まで（Spark・Iceberg・Delta、そして 2026 年の実情）

プロローグ — 「Hadoop は死にましたか」という質問が誤投された理由

新人 data engineer がよく問う。「Hadoop は死にましたか」。

シニアの答えは大抵 2 つに分かれる。1 つは consultant の答え — 「いいえ、まだ稼働している cluster はたくさんあります」。もう 1 つは startup の data lead の答え — 「はい、死にました。新しく始めるなら絶対 Hadoop で始めないでください」。

どちらも正しい。そしてこの 2 つの答えを同時に頭に置けないと、2026 年の data platform 設計を誤る。本稿はその進化の全体 — どうやって Hadoop が default の座から降り、その席を何が占め、どこに Hadoop がまだ生きているのか — を整理する。

質問をより正確に書き換えよう。「2026 年に新しい analytics stack を作るなら、Hadoop を選ぶ理由はあるか」。答えはほぼ常に no だ。しかし「すでに動いている Hadoop cluster を今すぐ止めるべきか」。答えはほぼ常に no だ。本稿はその 2 つの答えの間にあるすべての細部についてである。

プロローグ — 「Hadoop は死にましたか」という質問が誤投された理由
1. Timeline — big data 進化を一枚で
2. Classic Hadoop — 何が core で、何が限界だったか
3. 第 1 の転換 — Spark が MapReduce を置き換える
- Spark が速かった理由 — RDD と in-memory shuffle
4. 第 2 の転換 — object storage が HDFS を置き換える
- なぜ S3 が HDFS に勝ったか
- HDFS の新しい役割 — 「ほぼ使わない」
5. 第 3 の転換 — open table format が Hive metastore を置き換える
6. 第 4 の転換 — query engine の時代（Trino・DuckDB・ClickHouse）
7. 「何が何を置き換えたか」 — 一目 matrix
8. それでも Hadoop が生きている場所
9. なぜ open table format が勝ったか — 一段落で
10. 2026 年に新しい analytics stack を組むなら — 推奨 stack
- 何を避けるべきか
- 何をそのまま維持して良いか
11. 移行 pattern — classic Hadoop から Lakehouse へ
エピローグ — 「死んだか」が誤った質問である理由
参考 / References

1. Timeline — big data 進化を一枚で

まず全体像。big data stack は 2006 年から約 20 年で 4 回の大きな世代交代を経た。

   2006              2012-14           2017-20          2022-26
   ─────             ───────           ───────          ───────

   HDFS              HDFS              S3 / GCS         S3 / GCS / ADLS
    +                 +                  +                +
   MapReduce  ──▶   Spark      ──▶   Spark/Trino  ──▶  Spark/Trino/DuckDB
    +                 +                  +                +
   Hive          Hive metastore     Hive metastore   REST Catalog
   (file = table)  (file = table)   (file = table)   (Iceberg/Delta/Hudi)
    +                 +                  +                +
   YARN              YARN              K8s / EMR        K8s / Serverless

   "Hadoop"      "Hadoop + Spark"   "Spark on object   "Lakehouse"
                                     storage"

世代を分けるものは明確だ。

2006–2012、classic Hadoop の時代: HDFS と MapReduce と YARN 2.x と Hive。1 つの cluster に storage と compute と metastore がすべて束ねられていた。
2012–2017、Spark が MapReduce を置き換える時期: HDFS はそのまま、MapReduce の席に Spark が入る。Hive on Tez / Spark、Impala・Presto が interactive query を持ち込む。
2017–2022、storage と compute の分離期: HDFS の席に S3・GCS・ADLS が入る。Spark・Trino は object storage の上で動き始める。EMR・Dataproc・Databricks が登場。
2022–2026、Lakehouse 期: Hive metastore 時代が終わり、Apache Iceberg・Delta Lake・Apache Hudi — つまり「file = table」ではなく「metadata = table」という paradigm へ移行。Snowflake が Iceberg を native 対応し、Databricks が Tabular を買収、REST Catalog が標準に。

本稿の残りは各転換の 「何が何を置き換えたのか、なぜそうなったのか」 を解きほぐす。

2. Classic Hadoop — 何が core で、何が限界だったか

まず「Hadoop」が正確に何だったか押さえよう。2010 年代初頭の「Hadoop stack」は実質 3 つの component で構成されていた。

HDFS — 分散 file system。64 MB あるいは 128 MB の block 単位で data を分割し、複数 node の disk に複製（通常 3 複製）して格納する。
MapReduce — 分散計算 framework。Map 段階で data を key 別に散らし、Reduce 段階で集める。disk ベース。
YARN — resource manager。node の CPU と memory を管理し、job container を割り当てる。

この上に Hive が SQL interface を、HBase が OLTP 寄りの KV store を、Sqoop・Flume が ingestion tool を乗せた形が「Hadoop 生態系」だった。

この model の天才性は data locality にあった。計算を data 側へ移す — network が遅かった時代、「disk が付いている node でその disk の block を処理せよ」という発想は十分に革新的だった。

しかし時間とともに限界が積み重なった。

MapReduce が遅い。disk ベースの shuffle は中間結果をすべて disk に書く。反復作業（ML、多段 ETL）でひどく非効率。
HDFS は運用が重い。NameNode が単一障害点で、metadata を memory に持つため file 数に限界があり、small file 問題が慢性化し、disk 容量を増やすには node を丸ごと足す必要がある。
compute と storage が結びついている。disk が足りなければ CPU が余っても node を増やし、CPU が足りなければ disk が余っても node を増やす。cloud 時代に最も合わない model。
metadata 層（Hive metastore）が弱い。partition 単位の管理だけで、schema 進化・transaction・time travel といった近代 analytics 要件を満たせない。

要するに Hadoop は 「data center を 1 棟借りて 1 日中 batch job を回す」 workload に最適化されていた。cloud、interactive query、ML、streaming が順次入ってくるとその前提が崩れた。

3. 第 1 の転換 — Spark が MapReduce を置き換える

Spark は 2010 年に UC Berkeley AMPLab で始まり、2014 年に Apache TLP となって本格的に普及した。Spark の中核の価値提案は単純だった — 「MapReduce のように動くが 10–100 倍速い」。

Spark が速かった理由 — RDD と in-memory shuffle

Spark は data を RDD（Resilient Distributed Dataset） という抽象で model 化する。RDD は分散 partition の collection で、変換（map / filter / join）chain は DAG で表される。要点は:

中間結果を disk に書かない — 可能な限り memory に cache する。
演算 graph を見て最適化する — 同じ stage 内では shuffle なしで pipelining。
障害時は lineage で再計算 — memory にあっても RDD の系譜が分かれば部分再計算が可能。

同じ word count を Hadoop MR と Spark で比べてみる。

MapReduce（Java） — code が長い、disk に書く、遅い。

public class WordCount {
  public static class TokenizerMapper extends Mapper<Object, Text, Text, IntWritable> {
    private final static IntWritable one = new IntWritable(1);
    private Text word = new Text();
    public void map(Object key, Text value, Context context) throws IOException, InterruptedException {
      StringTokenizer itr = new StringTokenizer(value.toString());
      while (itr.hasMoreTokens()) {
        word.set(itr.nextToken());
        context.write(word, one);
      }
    }
  }
  public static class IntSumReducer extends Reducer<Text, IntWritable, Text, IntWritable> {
    private IntWritable result = new IntWritable();
    public void reduce(Text key, Iterable<IntWritable> values, Context context)
        throws IOException, InterruptedException {
      int sum = 0;
      for (IntWritable val : values) sum += val.get();
      result.set(sum);
      context.write(key, result);
    }
  }
  // main(): Job 生成、入出力 path 指定、waitForCompletion …
}

Spark（Scala / Python） — 同じことを 4 行で。

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("wordcount").getOrCreate()
df = spark.read.text("s3://logs/2026/05/14/")
counts = df.selectExpr("explode(split(value, ' ')) as word").groupBy("word").count()
counts.write.mode("overwrite").parquet("s3://output/wc/")

code 長の差がすべてを語るわけではない。しかし運用面でも Spark が勝った。

SQL が一級市民 — Spark SQL がほぼすべての workload を吸収。
MLlib・Streaming・GraphX 統合 — 同じ engine が batch・ML・streaming・graph を扱う。
API が良い — Scala・Python・R・Java・SQL すべて。

2018 年頃には新規 project で MapReduce を新しく書くことはほぼ消えた。Hadoop cluster は残ったが、その中で動く job のほぼすべてが Spark になった。

この段階で重要なのは HDFS はそのままだった という点だ。Spark on YARN、Spark on HDFS — つまり Spark は MapReduce の席を取ったが、Hadoop infrastructure（HDFS と YARN）はそのまま使った。

4. 第 2 の転換 — object storage が HDFS を置き換える

次の domino は storage だった。2010 年代半ば以降、AWS S3・Google Cloud Storage・Azure Data Lake Storage（以下 object storage または ADLS）が data lake の default になり始めた。

なぜ S3 が HDFS に勝ったか

object storage の利点は 5 つ。

compute と storage の分離 — CPU と disk を独立に増やせる。cloud 価格 model に合う。
相対的に無限に安い — S3 Standard は GB あたり月 0.023 USD 程度、S3 Glacier はさらに安い。HDFS 3 複製と比べて価格差は 1 桁。
運用不要 — NameNode・DataNode・disk 交換・rebalance — すべて AWS がやる。
耐久性 11 nine — S3 が約束する 99.999999999% の耐久性は HDFS 3 複製より安全。
ほぼ無限の拡張 — file 数の上限が事実上ない。NameNode memory 問題のようなものがない。

代わりに欠点もあった。

latency が高い — object 単位の GET が数十 ms。HDFS は ms 未満。
list 操作が高い — S3 LIST は 1000 件単位の page 化。
eventual consistency（S3 は 2020 年 12 月から strong read-after-write consistency へ移行）。
rename が存在しない — S3 の「rename」は copy + delete。directory 単位の rename は事実上不可。

これらの欠点のうち rename が存在しない という点が、Hive・Spark の従来の出力方式（_temporary に書いてから rename）を壊した。S3 上で安全に書くには committer（EMRFS S3-Optimized Committer、Magic Committer など）が必要になった。この不便さが次の domino — open table format — の動機の 1 つになる。

HDFS の新しい役割 — 「ほぼ使わない」

2020 年代半ばには cloud で新規に始める data platform が HDFS を使うことはほぼない。EMR・Databricks・Snowflake・BigQuery — すべて object storage を default とする。HDFS は 2 つの場合にのみ生き残る。

on-prem cluster — cloud に行けない / 行かない保守的な金融・通信・政府。
HDFS 互換分散 storage — Ozone・MinIO・JuiceFS のように S3 互換 interface を提供する新世代の分散 storage。

後者は実質「HDFS の名目上の後継者」というより「S3 の on-prem clone」に近い。つまり object storage model が勝利し、HDFS はその object storage を模倣する席に押しやられた。

5. 第 3 の転換 — open table format が Hive metastore を置き換える

これが最も最近の、最も重要な転換だ。

Hive の限界 — 「file = table」

Hive metastore 時代の中核の前提は単純だった — 「S3 や HDFS の上の directory が table である」。s3://warehouse/orders/dt=2026-05-14/ のような partition directory 内の Parquet file 群が 1 つの table を成す。metastore には「この table の partition column は何で、どこに directory があり、schema はどうか」が記録される。

この model の問題は積み重なった。

transaction の不在 — INSERT INTO ... PARTITION の途中で失敗すると、半分書かれた file が残る。idempotency を保証しにくい。
schema 進化が弱い — column 追加はできるが、column 名変更・型変更・nested 構造の変更は事実上できない。
time travel がない — 「1 時間前の状態を見たい」という要求を満たせない。
small file 問題 — streaming ingest で partition ごとに数千の小 file が貯まると query が悲惨。
metastore 自体が bottleneck — partition が巨大な table で SHOW PARTITIONS が分単位かかる。

open table format の三強 — Iceberg、Delta、Hudi

この限界を解くために、3 つの project がほぼ同時期に登場した。

Apache Iceberg（2018、Netflix） — metadata file にすべての data file 一覧を明示。snapshot 単位の ACID。catalog 中立。
Delta Lake（2019、Databricks） — _delta_log/ directory の transaction log（JSON・Parquet）で同じことをやる。Databricks と深く統合。
Apache Hudi（2017、Uber） — streaming・CDC に強み。Copy-on-Write と Merge-on-Read の 2 mode。

共通点は明確だ。「metadata を file と一緒に置き、その metadata で ACID・time travel・schema 進化を実装する」。

同じ table を Iceberg DDL で作ってみる。

CREATE TABLE catalog.db.orders (
  order_id     BIGINT,
  user_id      BIGINT,
  amount_cents BIGINT,
  status       STRING,
  created_at   TIMESTAMP
)
USING iceberg
PARTITIONED BY (days(created_at), bucket(16, user_id))
TBLPROPERTIES (
  'format-version'             = '2',
  'write.target-file-size-bytes' = '536870912',
  'write.parquet.compression-codec' = 'zstd'
);

-- time travel
SELECT count(*) FROM catalog.db.orders FOR TIMESTAMP AS OF '2026-05-13 00:00:00';

-- schema 進化 — column 追加・名前変更・型昇格すべて可能
ALTER TABLE catalog.db.orders ADD COLUMN refund_amount_cents BIGINT;
ALTER TABLE catalog.db.orders RENAME COLUMN status TO order_status;

意味のあること 2 つを押さえる。

PARTITIONED BY (days(created_at), bucket(16, user_id)) — Hive 時代は dt のような偽 column を自分で追加する必要があった。Iceberg は hidden partitioning で時間 / hash 変換を metadata が勝手に処理する。user は WHERE created_at >= '2026-05-01' と書くだけで partition pruning が効く。
format-version 2 — Iceberg v2 は row-level delete を支援。v3（2025–2026）は deletion vector や variant 型を追加し、Databricks が 2026 年に v3 を Public Preview に乗せた。

2024 年の 2 つの事件 — 戦争の終わり

2020–2023 年までの「Iceberg vs Delta vs Hudi」論争は、2024 年の 2 つの事件で事実上決着した。

Snowflake が Iceberg を native 対応し、Polaris Catalog を OSS 化（2024 Summit、2025 年に Apache TLP へ昇格）。
Databricks が Tabular を 10 億 USD 超で買収 — Tabular は Iceberg 創立者（Ryan Blue、Dan Weeks）の会社。つまり Delta の本陣が Iceberg 本陣を買収した形。

その後 Databricks は Delta UniForm で Delta を Iceberg として読めるようにし、2026 年 4 月には外部 Unity Catalog が管理する Iceberg table に Snowflake が write できる相互運用性を GA にした（Azure から）。REST Catalog が lingua franca になった。

要約: Iceberg が事実上の標準となり、Delta・Hudi は Iceberg との相互運用性を追求する図。

6. 第 4 の転換 — query engine の時代（Trino・DuckDB・ClickHouse）

Hive on Tez 時代の interactive SQL は限界が明確だった。その席を取ったのが Presto / Trino。

Presto — 2012 年に Facebook で開始。2018 年に Facebook 側と Starburst・Netflix 側が分裂し、後者が Trino として再出発。2020 年に PrestoSQL が Trino へ rebrand。
Trino — MPP（Massively Parallel Processing）分散 SQL engine。Iceberg・Delta・Hudi・Hive すべてに native connector。
Starburst — Trino の商用 distribution。Warp Speed のような acceleration layer を追加。

2026 年現在、Trino は Comcast・Goldman Sachs・LinkedIn・Lyft・Netflix・Pinterest・Salesforce などで稼働しており、open data lake 上で SQL を回す事実上の標準 engine だ。

その横に新しい流れがある。

DuckDB — embedded OLAP。1 node の Parquet・Iceberg analytics には圧倒的。「laptop で 1 TB までは DuckDB で十分」が真面目に言われる時代。
ClickHouse — columnar OLAP DB。real-time analytics に強み。Iceberg 外部 table 対応で lakehouse とも結合。
StarRocks・Doris — MPP analytics DB の新世代。Iceberg native。

核心: query engine はもう多極化した。batch は Spark、interactive analytics は Trino、single node は DuckDB、real-time は ClickHouse — 同じ Iceberg table の上で違う engine が自分の領域の workload を処理する。

7. 「何が何を置き換えたか」 — 一目 matrix

進化の全体像を表 1 つで整理する。

層	classic Hadoop（2010）	Hadoop+Spark（2015）	object storage（2020）	Lakehouse（2026）
分散 storage	HDFS	HDFS	S3 / GCS / ADLS	S3 / GCS / ADLS
batch compute	MapReduce	Spark	Spark on EMR / Databricks	Spark / Trino / Flink
interactive SQL	Hive	Hive on Tez、Impala	Presto / Trino	Trino / DuckDB / ClickHouse
table format	text・Sequence・ORC	Parquet on Hive	Parquet on Hive	Iceberg / Delta / Hudi
metadata	Hive Metastore	Hive Metastore	Hive Metastore / Glue	REST Catalog（Polaris・Unity・Nessie）
resource 管理	YARN	YARN	YARN / K8s / EMR	K8s / serverless
streaming	Storm	Spark Streaming	Spark Structured / Flink	Flink / Kafka / Iceberg streaming
運用 model	on-prem cluster	on-prem + cloud	cloud managed	multi engine / multi catalog

この表が語ることは明確だ。Hadoop の席にあったほぼすべての層が別物に交換された。HDFS が object storage に、MapReduce が Spark に、Hive metastore が REST Catalog と Iceberg に、YARN が Kubernetes に。

残ったのは 概念的影響力 のみ。「data を disk に置き、計算を分散する」という Hadoop の基本発想は今もすべての分散 data system の土台だ。しかしその土台に乗る具体的な component はほぼ全部交換された。

8. それでも Hadoop が生きている場所

「では本当に Hadoop はどこに生きているのか」。2026 年現在、次の 4 つの領域では依然として現役だ。

8.1 巨大な legacy cluster

10 年以上運用された petabyte 級 HDFS cluster を持つ大企業・通信会社・金融は、その cluster を一気に止められない。Cloudera・Hortonworks（現在は合併）の license、運用 team の know-how、移行 cost と risk — すべてが「とりあえず回す」方向に重みを掛ける。これらの cluster は通常 段階移行中 で、新しい data は S3・Iceberg へ、古い data は HDFS に残したまま順次移していく形だ。

8.2 Hive Metastore — 互換 layer として生き残る

興味深い事実: Hive Metastore 自体は死んでいない。Iceberg が catalog を抽象化したことで、Hive Metastore は Iceberg catalog の 1 実装 になった。つまり:

   従来: Hive table → Hive Metastore → directory (Parquet)
   現在: Iceberg table → Hive Metastore catalog → Iceberg metadata → Parquet

企業が Hive Metastore をそのまま残し、その中で Iceberg table を登録・管理する方式が一般的だ。Hive Metastore が「Iceberg catalog 互換 layer」になることで、段階的な移行が可能になった。同じ metastore を REST Catalog として公開すれば、Trino・Spark・Snowflake・Flink がすべて同じ table を見る。

8.3 on-prem 保守領域 — 金融・通信・政府

data 主権・規制・運用方針上、cloud object storage へ行けない組織がまだある。韓国・日本の一部金融、通信 3 社、政府 system が代表例。こうした場所では Apache Ozone（HDFS 後継 project）や MinIO・JuiceFS のような S3 互換 on-prem storage が定着しつつある。YARN は徐々に Kubernetes へ移行中。

8.4 YARN — 徐々に K8s へ

YARN は一時期 Hadoop の誇りだったが、2026 年現在の新規 deployment はほぼ Kubernetes。EMR on EKS、Databricks（元から自前 resource manager）、Spark on K8s — すべて YARN を迂回する。ただし既存 YARN cluster の安定性が良く、わざわざ移す動機が薄いところではそのまま運用されている。Hadoop 3.5（2026 年）も YARN を活発に保守中。

9. なぜ open table format が勝ったか — 一段落で

本稿で最も重要な洞察だ。open table format（特に Iceberg）が最終的に標準になった理由は単純だ。

「table の真実」が directory から metadata に移ったことで、誰がその table をどう読んでも同じ結果が保証できるようになったから。

Hive 時代は、同じ table を Spark・Presto・Hive で読むと結果が微妙に違うことがあった。partition directory に直接 file を投下する行為が止められておらず、transaction もなかったからだ。Iceberg は「snapshot = metadata file = その時点の真実」という model でその問題を断ち切った。1 つの table、複数 engine、同じ結果 — これが Lakehouse 時代の中核の約束だ。

Snowflake と Databricks がそれぞれの閉鎖 format の一部を譲って Iceberg に合流した理由も同じ。顧客が「特定 vendor に lock-in されたくない」を交渉で譲らなくなった。2026 年の analytics stack は format 中立・catalog 中立 が default の前提になった。

10. 2026 年に新しい analytics stack を組むなら — 推奨 stack

今から新しく始めるなら、次の組み合わせが無難な default だ。

   ┌──────────────────────────────────────────────────────────┐
   │  Storage:    S3 / GCS / ADLS（または on-prem S3 互換）   │
   │  Format:     Apache Iceberg（または Delta + UniForm）    │
   │  Catalog:    Polaris / Unity / Glue / Nessie             │
   │  Batch:      Spark（Databricks・EMR・Glue）または Flink  │
   │  Interactive:Trino（or Starburst Galaxy）                │
   │  Single-node:DuckDB（developer / BI workbench）          │
   │  Streaming:  Kafka + Flink + Iceberg streaming           │
   │  Orchestrator: Airflow / Dagster / Prefect               │
   │  Transform:  dbt（または SQLMesh）                        │
   │  Observability: OpenLineage + Marquez / DataHub          │
   └──────────────────────────────────────────────────────────┘

この組み合わせの美徳は lock-in が少ない ことだ。どの component も単一 vendor に縛られない。Iceberg は標準、Trino・Spark・Flink は OSS、Polaris・Nessie・Unity Catalog はすべて REST Catalog 仕様に従う。

何を避けるべきか

新しく始めるなら、次は避けよ。

HDFS 新規構築 — cloud であれ on-prem であれ。S3 互換（Ozone・MinIO）に行け。
MapReduce 新規 job — すでに Spark・Trino で可能だ。
Hive metastore を catalog としてそのまま公開する — Iceberg と組み合わせる形でのみ使え。可能なら REST Catalog で抽象化。
Hive table 新規作成 — Iceberg で作れ。変換 cost は時間が経つほど大きくなる。
vendor 固有の table format — Snowflake 内部 format・BigQuery native format に data を永続的に置くな。外部から読める形を維持せよ。
1 engine に依存する ETL — Databricks notebook・Snowpark・BigQuery SQL のみで ETL を書くと移行が地獄。Spark SQL や dbt のような portable な layer を挟め。

何をそのまま維持して良いか

逆に、既存の次のものは無理に置き換える必要はない。

よく回っている YARN cluster — 安定しているなら残せ。Kubernetes 移行は workload 単位で。
Hive Metastore — Iceberg catalog として再利用すればそれで良い。
Spark job — すでに Iceberg / Delta に書いているなら追加でやることはほぼない。
HDFS 上の旧 data — cold data は残したまま、新しい data から S3 へ。

11. 移行 pattern — classic Hadoop から Lakehouse へ

legacy から modern stack への一般的な移行 pattern は 3 つだ。

11.1 dual write

新しい ingest job が HDFS と S3・Iceberg の両方に同時に書く。一定期間、同じ data を両側で比較検証してから古い経路を止める。安全だが resource が 2 倍。

11.2 in-place migration

Iceberg の add_files procedure で既存 HDFS Parquet directory を「複製なしで」Iceberg table として登録する。file はそのまま、metadata だけ追加。速いが HDFS との結合はそのままだ。

-- 既存 Hive 外部 table を Iceberg table として登録（file 複製なし）
CALL system.add_files(
  table => 'iceberg_catalog.db.orders',
  source_table => 'hive.db.orders'
);

11.3 catalog 統合 → 段階移行

Hive Metastore の上に Iceberg catalog adapter を乗せる。新 table のみ Iceberg で作り、旧 Hive table は残したまま、両方を同じ catalog 経由で公開する。時間とともに旧 table が自然に retire する。最も推奨される approach。

エピローグ — 「死んだか」が誤った質問である理由

Hadoop は死んでいない。しかし 「default」の席からは降りた。

Linux が登場した時、人々は「Unix は死んだか」と問うた。正確な答えは「Unix System V はほぼ使われず、BSD 系列と Linux がその領土を取ったが、Unix の idea はどこにでも生きている」だった。Hadoop も同じ。HDFS・MapReduce は新規 workload にほぼ見えないが、「data を分散して disk に置き、計算を data 側へ移し、metadata で抽象化する」 という Hadoop の中核 idea は object storage + Iceberg + Trino というより良い実装で生き残っている。

2026 年の data engineer がやるべきことは「Hadoop が死んだか」を問うことではない。次の 3 つを問うことだ。

我々の data の真実はどこにあるべきか — object storage に、open table format で、標準 catalog の下に。
どの engine がどの workload を取るか — Spark は batch、Trino は interactive、DuckDB は single node、Flink は streaming、ClickHouse は real-time。
どうやって特定 vendor に縛られないか — Iceberg + REST Catalog + portable な SQL layer（dbt）という 3 段抽象。

checklist

新規 analytics platform 設計時、次を確認せよ。

よくある anti-pattern

2026 年の新 project で避けるべき pattern。

「とりあえず HDFS で始めて後で移す」 — 後は来ない。最初から S3。
「Hadoop 運用 team がいるから Hadoop で行く」 — 運用 team の親しみが新規 architecture 決定の第 1 基準になってはならない。
「Hive Metastore は慣れているのでそのまま使う」 — 残せ、ただし Iceberg catalog adapter で公開せよ。
「Snowflake / Databricks の中にすべての data を置く」 — vendor lock-in の始まり。外部から読める format（Iceberg）を維持。
「1 engine ですべての workload」 — batch・interactive・streaming・single node はそれぞれ別の engine が得意。
「file = table」 — directory に直接 file を書くな。常に table interface 経由で。
「catalog は 1 つで十分」 — multi catalog・federation の可能性を最初から想定。
「format は後で決める」 — format は ingest 時に決まる。移行は高い。

次回予告

次回は本 series の姉妹編 — 「Iceberg catalog 戦争 — Polaris vs Unity vs Nessie vs Glue、multi catalog federation をどう組むか」 — だ。REST Catalog 仕様の細部、各実装の違い、multi catalog 環境で権限・lineage・failover をどう設計するかを扱う。