Hadoopエコシステム & データエンジニアリング 2026 完全ガイド - Hadoop · Spark · Flink · Trino · Iceberg · Delta Lake · Hudi · Airflow · dbt 詳細分析

はじめに — Hadoopは死んだ、そしてHadoopはどこにでもいる

2026年5月、「Hadoopは死んだのか?」という問いはヘッドラインとしては魅力的だが、現場では誤った問いだ。正確な答えは「HDFSは縮小し、MapReduceは事実上消え、Cloudera/Hortonworks時代のフルスタックディストリビューションは終わった。しかしYARNは生きており、Hive MetastoreはIceberg/Deltaに衣替えし、『安価なオブジェクトストレージ + メタデータカタログ + 分散処理エンジン』というレイクハウスパターンはHadoopが残した遺産だ」である。

この記事は単一ツールの自慢ではなく、2026年5月時点でデータエンジニアが実際に触れるすべてのレイヤー — ストレージ、テーブルフォーマット、処理エンジン、クエリエンジン、オーケストレーション、変換、ウェアハウス、分析 — を一度に俯瞰する。クラウド(EMR、Dataproc、HDInsight、Synapse)、フルマネージド(Snowflake、Databricks、BigQuery、Redshift)、そして韓国・日本のオンプレミス事例まで、正直に整理する。

データエンジニアリング2026スタック — 8レイヤーへの分解

まず全体像。2026年の標準データエンジニアリングスタックは以下の8レイヤーに分かれる。

ストレージ(storage): HDFS、S3、GCS、ABFS、MinIO
テーブルフォーマット(table format): Iceberg、Delta Lake、Hudi
カタログ(catalog): Hive Metastore、Unity Catalog、Polaris、Nessie、AWS Glue
バッチ処理(batch): Spark、Trino-on-Spark、Dremio
ストリーミング(streaming): Flink、Spark Structured Streaming、Kafka Streams、Materialize
クエリ/フェデレーション(query): Trino、Presto、Dremio、StarRocks
変換(transform): dbt、SQLMesh、Coalesce
オーケストレーション(orchestration): Airflow 3.0、Dagster、Prefect、Mage、Kestra

ここに分析/OLAPレイヤーとして ClickHouse、DuckDB、Pinot、Druid が加わり、フルマネージドウェアハウスとして Snowflake、Databricks SQL、BigQuery、Redshift が加わる。すべてのレイヤーが一社のディストリビューションに収まっていたCloudera時代は終わり、現在は OSSコンポーネントを自分で組み合わせる 時代である。

Hadoopが死なない理由 — YARNとHive Metastoreの執拗な生存

「Hadoopが死んだ」という主張の出所は通常二つある。第一に、Cloudera + Hortonworksの2018年合併以降の新規ライセンス売上減少。第二に、S3/GCSのようなオブジェクトストレージがHDFSを圧倒し、「HDFS = Hadoop」という等式が崩れたこと。いずれも事実だが、「Hadoopエコシステム」が指す範囲ははるかに広い。

2026年現在、生きているHadoopコンポーネントは以下の通り。

YARN: リソースマネージャとして依然オンプレミスSpark/Flinkクラスタの基本。Kubernetesに徐々に押されているが、金融・通信ではYARN比率が高い。
Hive Metastore (HMS): Iceberg、Delta、Trino、Spark、FlinkがすべてHMSをカタログとして使う。「Hiveは死んだが、HMSは生きている」が正確な表現。
Hive LLAP: Hive 4.0と共にACIDテーブル + Icebergバックエンドとして再ポジショニング。
Ozone: HDFS後継のオブジェクトストレージ。オンプレミスS3互換を狙う。
Tez: Hiveの実行エンジン。MapReduceは事実上廃棄されたが、Tezは生きている。

一方 MapReduceは新規ワークロードからほぼ消えた。皆がSparkに移行し、残ったMapReduceはレガシーSqoop、一部Oozieバッチ、そして移行待ちのコードのみだ。

HDFS対オブジェクトストレージ — 勝者は誰か

2026年5月時点、新規ビッグデータワークロードの90%以上はオブジェクトストレージ上で動く。AWS S3、Azure ADLS Gen2、GCP GCS、オンプレならMinIOやCloudian。HDFSは次の3ケースでのみ生き残る。

金融機関のデータ主権: データが絶対に外部クラウドに出られない環境。この場合オンプレミスHDFSクラスタ + Spark/Trino。
レガシーETL資産: 数千個のHiveテーブルとOozieジョブがHDFSパスに固定されており、移行が多年プロジェクトの場合。
超低レイテンシシャッフル: 一部のグラフ/結合ワークロードでオブジェクトストレージのPUT/GETレイテンシがボトルネックとなる場合。HDFSやAlluxio相当のキャッシュレイヤーが勝つ。

S3が勝った理由は単純だ。ストレージ価格が約三分の一、運用負担がほぼゼロ、そしてコンピュートとストレージを分離できるため、同じデータをSpark、Trino、Snowflake、Athenaなど複数エンジンが同時に見る。これがレイクハウスの中核前提だ。

レイクハウス時代 — ウェアハウスとレイクの統合

「データレイク vs データウェアハウス」の二項対立は2026年にはほぼ意味がない。すべて レイクハウス(lakehouse) というパターンに収束した。中核アイデアは以下。

ストレージ: オブジェクトストレージ(S3/GCS/ABFS) — 安価、無制限、コンピュートと分離
ファイル形式: Parquet/ORC — カラム指向、圧縮、プルーニング
テーブル形式: Iceberg/Delta/Hudi — ACID、スキーマ進化、タイムトラベル、パーティショニング
カタログ: Hive Metastore / Glue / Unity Catalog / Polaris / Nessie
コンピュートエンジン: Spark、Trino、Flink、Dremio、StarRocks — 同じデータに複数エンジン

ウェアハウス(Snowflake、Redshift、BigQuery)は自社フォーマットに囲い込んでいたデータを段階的にIcebergへ開き始めた。2026年5月時点、SnowflakeとDatabricksの双方が Icebergテーブルを一級市民として支援 する。この変化が意味するのは「ベンダーロックイン時代の終了」だ。

テーブルフォーマット三強 — Iceberg vs Delta Lake vs Hudi

レイクハウスの心臓部はテーブルフォーマットである。2026年5月時点、三強構図が固まった。

項目	Apache Iceberg	Delta Lake	Apache Hudi
出自	Netflix → ASF	Databricks → LF	Uber → ASF
ACID	はい(Serializable)	はい(Serializable)	はい
スキーマ進化	強力(列ID方式)	はい	はい
パーティション進化	はい	限定的	限定的
MERGE/UPDATE	はい	はい	はい (CoW/MoR)
タイムトラベル	はい	はい	はい
カタログ	REST、Hive、Glue、Polaris、Nessie	Unity Catalog、HMS	Hive、Glue
代表的採用	Snowflake、Confluent、Apple、Netflix	Databricksエコシステム	Uber、Robinhood

2026年の流れは Icebergの漸進的標準化 だ。SnowflakeがIceberg外部テーブル + Polaris Catalogを強力に推し、DatabricksもUnity CatalogをIceberg互換にし、ConfluentのTableflowはKafkaトピックをそのままIcebergテーブルへマテリアライズする。DeltaはDatabricksエコシステム内では依然最強だが、「汎用OSS標準」の位置はIcebergが取った。

HudiはCDC(Change Data Capture)とincremental writeパターンで依然強いが、新規採用は減少傾向にある。

Iceberg DDLと実際の利用 — RESTカタログが標準

Icebergを実際に使うと次のようなDDLになる。Spark SQL基準。

CREATE TABLE iceberg_catalog.analytics.events (
  event_id BIGINT,
  user_id BIGINT,
  event_type STRING,
  occurred_at TIMESTAMP,
  payload MAP<STRING, STRING>
)
USING iceberg
PARTITIONED BY (days(occurred_at), bucket(16, user_id))
TBLPROPERTIES (
  'format-version'='2',
  'write.parquet.compression-codec'='zstd',
  'write.delete.mode'='merge-on-read',
  'write.update.mode'='merge-on-read'
);

ALTER TABLE iceberg_catalog.analytics.events
ADD COLUMN device_type STRING AFTER event_type;

MERGE INTO iceberg_catalog.analytics.events t
USING staging.events_delta s
ON t.event_id = s.event_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

SELECT count(*) FROM iceberg_catalog.analytics.events
  FOR SYSTEM_TIME AS OF '2026-05-01 00:00:00';

Icebergの強みは カタログが分離されている点 だ。同じテーブルをSparkで書き、Trinoで読み、Flinkからストリーミング書き込みし、Snowflakeから外部テーブルとしてクエリできる。RESTカタログ仕様が固まり、ベンダー依存が弱まった。

Delta LakeとDatabricksエコシステムの結束

Delta LakeはOSSだが、事実上Databricksのコントロールが強いフォーマットだ。2026年5月時点、Delta Lake 4.x系の核心は次の通り。

Liquid Clustering: パーティションの代わりに多次元クラスタリング。ZORDERの後継。
Predictive Optimization: 統計ベースの自動OPTIMIZE/VACUUM。
Delta Sharing: データ共有プロトコル。同じデータを別組織が読めるようにする。
UniForm: DeltaテーブルをIcebergクライアントがそのまま読めるようにする互換レイヤー。

Deltaのマージの典型は次の通り。

MERGE INTO delta.`s3://datalake/customers` AS t
USING (SELECT * FROM staging_customers) AS s
ON t.customer_id = s.customer_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN
  UPDATE SET *
WHEN NOT MATCHED THEN
  INSERT *
WHEN NOT MATCHED BY SOURCE AND t.is_active = true THEN
  UPDATE SET is_active = false;

OPTIMIZE delta.`s3://datalake/customers`
  WHERE updated_at >= current_date() - INTERVAL 7 DAYS;

VACUUM delta.`s3://datalake/customers` RETAIN 168 HOURS;

DeltaがDatabricks外で弱い理由は 運用ツール(OPTIMIZE、Z-Order、Predictive Optimization)がDatabricks内でのみ自動化される からである。OSS Deltaでも使えるが、運用自動化の面でDatabricks内体験との差が大きい。

Apache Hudi — CDCとincrementalのチャンピオン

HudiはUberで作られただけあって stream-to-batch CDC に最適化されている。2026年現在Hudi 1.0がGAし、二つのテーブルタイプが中核だ。

Copy-on-Write (CoW): 更新のたびにファイル再書き込み。読み高速、書き高コスト。
Merge-on-Read (MoR): デルタログに変更を蓄積し、コンパクション時にマージ。書き高速、読み高コスト。

HudiはまたTIMELINEというメタデータ構造で全コミットを時系列に並べ、incremental queryで「直近1時間の変更分だけ」を読めるようにする。これがCDCパイプラインで強力。

2026年の採用率は減少傾向だが、AWS EMR / OneHouse / Onehouse Open Enginesなどで依然活発だ。

Spark 4.0 — 依然データエンジニアリングの中心

「Sparkは死んだのか?」もよく出る問いだが、2026年の答えは明確にNoだ。Spark 4.0が2025年末GAし、データエンジニアリングの中心処理エンジンの位置を堅持している。4.0の主要変化は以下。

Spark Connect: クライアント・サーバ分離。薄いクライアントがリモートSparkクラスタへ命令する。IDE/ノートブック/CI統合が容易になった。
ANSIモード既定化: SQL標準互換の強化。
Variant型: 半構造化(JSON)データの一級扱い。
String Collation: ICUベースの多言語ソート。
Python UDF性能: Arrowベースシリアライゼーション + Python 3.13の積極利用。

PhotonはDatabricks専用のベクトル化エンジンで、同等のOSSは Apache Gluten + Velox/ClickHouseバックエンドが急速に追い上げる。EMR Serverless、Dataproc Serverless、Synapse Sparkはいずれも独自加速エンジンを付ける流れだ。

Spark Structured StreamingはFlink比でmicro-batchモデルだが、2026年基準で Continuous Processingモードの安定性が向上し、Flinkの領域を一部取り戻した。

Spark Structured Streamingの例 — Kafka → Iceberg

Spark Structured Streaming + Icebergの組み合わせは、2026年5月時点で最も一般的なリアルタイム取り込みパターンだ。コード例は次の通り。

from pyspark.sql import SparkSession
from pyspark.sql.functions import from_json, col, current_timestamp
from pyspark.sql.types import StructType, StringType, LongType

spark = (SparkSession.builder
    .appName("kafka-to-iceberg")
    .config("spark.sql.catalog.lakehouse", "org.apache.iceberg.spark.SparkCatalog")
    .config("spark.sql.catalog.lakehouse.type", "rest")
    .config("spark.sql.catalog.lakehouse.uri", "https://catalog.internal:8181")
    .getOrCreate())

schema = StructType().add("event_id", LongType()).add("user_id", LongType()).add("event_type", StringType())

stream = (spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "kafka:9092")
    .option("subscribe", "user_events")
    .option("startingOffsets", "latest")
    .load()
    .select(from_json(col("value").cast("string"), schema).alias("d"))
    .select("d.*", current_timestamp().alias("ingested_at")))

(stream.writeStream
    .format("iceberg")
    .option("checkpointLocation", "s3://lakehouse/_checkpoints/user_events")
    .outputMode("append")
    .toTable("lakehouse.analytics.user_events"))

IcebergカタログがRESTのため別途Hive Metastore依存が消え、チェックポイントはS3に保存される。2024年にはこのパターンは珍しかったが、2026年にはほぼ標準だ。

Flink — 本物のストリーミングが必要な時

Flinkは本物のイベントタイムストリーミング、exactly-once、複雑なウィンドウイングが必要な時に依然1番手だ。2026年5月時点でFlink 1.20 / 2.0が流れを主導する。

Flink SQL: SQLでストリーミングジョブを書くことが標準になった。カタログ統合(Hive、Iceberg、Paimon)も成熟。
Apache Paimon: Flink陣営のlakehouseテーブルフォーマット。Icebergと競合かつ補完関係。
Flink CDC: Debezium代替。PostgreSQL/MySQL CDCをFlink自身が直接処理。
Flink on Kubernetes: K8s Operatorが標準デプロイ方式。
ConfluentのFlink SaaS: Confluent CloudにFlinkが統合され、Kafka + Flinkフルマネージドの組み合わせ。

FlinkがSpark Streamingより強い領域は 低レイテンシ + 正確なイベントタイムウィンドウイング + バックプレッシャー処理 だ。Spark StreamingはETL向きで、バッチコード再利用が容易な代わりに、100ms未満レイテンシは難しい。

Flink SQLで同じKafka → Icebergパターンを書くと次のようになる。

CREATE TABLE kafka_events (
  event_id BIGINT,
  user_id BIGINT,
  event_type STRING,
  occurred_at TIMESTAMP_LTZ(3),
  WATERMARK FOR occurred_at AS occurred_at - INTERVAL '5' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'user_events',
  'properties.bootstrap.servers' = 'kafka:9092',
  'format' = 'json',
  'scan.startup.mode' = 'latest-offset'
);

CREATE TABLE iceberg_events (
  event_id BIGINT,
  user_id BIGINT,
  event_type STRING,
  occurred_at TIMESTAMP_LTZ(3)
) PARTITIONED BY (`occurred_at`) WITH (
  'connector' = 'iceberg',
  'catalog-type' = 'rest',
  'uri' = 'https://catalog.internal:8181',
  'warehouse' = 's3://lakehouse/'
);

INSERT INTO iceberg_events
SELECT event_id, user_id, event_type, occurred_at
FROM kafka_events;

TrinoとPresto — フェデレーテッドSQLの標準

Trino(旧PrestoSQL)は「多源にまたがるSQLフェデレーション」という一点に集中して標準となった。2026年5月時点でTrinoは450超のコネクタを持ち、次のパターンが一般的だ。

データレイクSQL: Iceberg/Delta/Hudi上のad-hocクエリ
フェデレーション: Postgres + MySQL + Iceberg + Kafkaにまたがる結合
BIバックエンド: Tableau/SupersetがTrinoを介してlakehouseに接続

PrestoはMetaが作った原本で、Trinoはfork。2026年現在OSSの活発度はTrinoが圧倒的で、Metaは自社インフラ用にPrestoを発展させ続けている。StarburstがTrinoの商用ディストリビューションを提供する。

フェデレーテッドクエリの典型は次の通り。

WITH iceberg_orders AS (
  SELECT order_id, user_id, total, ordered_at
  FROM iceberg.sales.orders
  WHERE ordered_at >= date '2026-05-01'
),
pg_users AS (
  SELECT id AS user_id, email, country
  FROM postgres.public.users
),
kafka_clicks AS (
  SELECT user_id, count(*) AS clicks
  FROM kafka.events.clickstream
  WHERE timestamp_kafka >= timestamp '2026-05-01 00:00:00'
  GROUP BY user_id
)
SELECT u.country, sum(o.total) AS revenue, sum(c.clicks) AS clicks
FROM iceberg_orders o
JOIN pg_users u USING (user_id)
LEFT JOIN kafka_clicks c USING (user_id)
GROUP BY u.country
ORDER BY revenue DESC;

Trinoは同じクエリ内でIceberg、PostgreSQL、Kafkaを一度に結合する。別途ETLなしでad-hoc分析が可能な点はBI/データアナリストにとって大きな価値だ。

dbt 1.9 + Iceberg — モダンELTスタックの融合

dbtはSQLベース変換の標準になった。2026年5月時点でdbt Core 1.9 / dbt Cloudは次の変化をもたらした。

Microbatch incremental strategy: 時間ベースのインクリメンタルビルド。
dbt Mesh: プロジェクト間依存関係管理。
dbt Semantic Layer + MetricFlow: メトリック定義の中央集約化。
Iceberg一級サポート: Snowflake/Databricks/Spark/TrinoアダプタすべてがIcebergテーブルをマテリアライゼーションターゲットとして認識。

典型的なdbtモデルは次のような形だ。

{{ config(
    materialized='incremental',
    incremental_strategy='microbatch',
    event_time='occurred_at',
    batch_size='day',
    file_format='iceberg',
    partition_by=['days(occurred_at)']
) }}

SELECT
  event_id,
  user_id,
  event_type,
  occurred_at,
  date_trunc('day', occurred_at) AS event_date
FROM {{ source('raw', 'events') }}

{% if is_incremental() %}
WHERE occurred_at >= (SELECT max(occurred_at) FROM {{ this }})
{% endif %}

SQLMeshがdbtの代替として浮上中で、仮想環境(virtual environments)、ディメンションモデリング強化、セマンティックバージョンなどで差別化する。CoalesceはUIベースSQL変換ツールで、非技術者ユーザーに親しみやすい。

オーケストレーション — Airflow 3.0が再び立ち上がった

長らく「Airflowは重く古臭い」と批判されてきたが、2025年末GAの Airflow 3.0 が局面を変えた。

Task SDK: 作業定義がAirflowインフラと完全に分離。リモートワーカーで実行。
Multi-version DAG: 同一DAGの複数バージョンが共存。
DAG Versioning: コード変更履歴をAirflowが直接管理。
Asset-centric scheduling: データセット(asset)ベースのトリガ。Dagsterを意識した変化。

代替オーケストレータの現在地は以下。

ツール	強み	採用パターン
Airflow 3.0	汎用性、エコシステム、コネクタ	あらゆる場所
Dagster	アセット中心、型安全、データ可視性	新規データプラットフォーム
Prefect 3	動的DAG、Pythonフレンドリー	データ/MLワークフロー
Mage AI	ノートブック + パイプライン統合	アナリスト/スタートアップ
Kestra	YAMLベース、マルチ言語	エンタープライズ
Argo Workflows	K8sネイティブ、コンテナ単位	インフラ/プラットフォームチーム

典型的なAirflow DAGは次のような形になる。

from airflow.sdk import dag, task
from datetime import datetime, timedelta

@dag(
    schedule="@daily",
    start_date=datetime(2026, 5, 1),
    catchup=False,
    tags=["lakehouse", "iceberg"],
)
def daily_iceberg_compaction():

    @task
    def list_partitions(target_date: str) -> list[str]:
        return [f"event_date={target_date}"]

    @task
    def compact(partition: str) -> str:
        import subprocess
        subprocess.run([
            "spark-submit", "/opt/jobs/compact.py",
            "--table", "iceberg.analytics.events",
            "--partition", partition,
        ], check=True)
        return partition

    partitions = list_partitions("{{ ds }}")
    compact.expand(partition=partitions)

daily_iceberg_compaction()

Airflow 3.0のTask SDKのおかげでワーカーはAirflow依存なしに動き、ダイナミックタスクマッピング(expand)でパーティションごとのコンパクションを並列化する。

Dagster — アセット中心オーケストレーションの代表

Dagsterは「DAG of tasks」ではなく「DAG of assets」という哲学を持つ。データセットが一級市民で、タスクはアセットを作る関数だ。

2026年のDagsterの位置は以下の通り。

新規データプラットフォーム で強い。データカタログ、リネージ、dbt統合が最初から自然。
dbtとの統合が最もスムーズ。load_assets_from_dbt_project 一行でdbtモデルがアセットになる。
Software-defined assets パターンがデータメッシュ運動とよく噛み合う。

Dagster Cloud(エンタープライズSaaS)とOSS Coreが明確に分かれており、ビジネスモデルが安定している。

Prefectは動的ワークフローに強みがあり、2024年Prefect 3.0以降perf/UXが大幅改善された。Mageはノートブックネイティブ + データネイティブのポジショニングでアナリスト向け。KestraはYAML DSL + Javaベースでエンタープライズ環境に適している。

ClickHouse、DuckDB、Pinot、Druid — 分析コンバージェンス

OLAPレイヤーで2026年の流れは明確だ。「一つのDBがすべての分析をする」時代は終わり、各々の得意領域が固まった。

ClickHouse: 大規模カラム指向OLAPの定石。ログ/イベント分析、observability。2026年のClickHouse 24.x系はベクトル検索(Vector Search) + Iceberg/Delta外部テーブルを追加した。
DuckDB: ローカル/組み込みOLAP。「ノートブックの中のSnowflake」。1.0 GA以降の爆発的成長。MotherDuckがクラウド版。
Apache Pinot: リアルタイムユーザー対面分析。LinkedIn Feed、Uber価格、Superset対話的ダッシュボード。
Apache Druid: 時系列 + リアルタイムOLAP。Pinotと類似領域だが運用ツールがより成熟。
StarRocks/Doris: MPP OLAP。中国陣営の強み、Iceberg互換強化。

DuckDBが2026年に最も急成長した理由は ローカルでS3 Parquet/Icebergを直接クエリでき、Python/CLI/SQLすべてをサポートし、単一バイナリ だからだ。データアナリストのノートブックでSnowflakeの代わりに入ることが普通になった。

Snowflake、Databricks、BigQuery、Redshift — フルマネージド四強

フルマネージドデータウェアハウス/レイクハウスの四強構図は次の通り。

Snowflake: SQL優先、使いやすさ、シンプルな料金モデル。2026年にIceberg外部テーブル + Polaris Catalog + Snowpark Container Servicesでlakehouse方向へ。AI/LLMコンピュート(Cortex)も強化。
Databricks: Spark/Deltaの親元。Unity Catalog + Photon + Mosaic AI。ML/LLM/エンジニアリング統合が最も強い。
Google BigQuery: サーバーレス + ペタバイト規模。BigQuery Studioがノートブック統合。Iceberg外部テーブルも対応。
AWS Redshift: SpectrumがIcebergサポート強化。Redshift Serverlessが徐々に主流化。

伝統的な「Snowflake vs Databricks」の二者対決構図は2026年には薄れた。理由は 両社が同じ方向に収束している からだ。SnowflakeはIceberg + コンテナでlakehouseを吸収し、DatabricksはDatabricks SQLでウェアハウス領域に入った。

BigQueryはGoogle Cloudのデフォルトオプションで、RedshiftはAWSユーザーでコスト最適化が重要な企業が選ぶ。

EMR · Dataproc · HDInsight — クラウドマネージドHadoopの今

三大クラウドはいずれもマネージドHadoopサービスを持つ。

AWS EMR: 最も成熟。EMR on EC2、EMR Serverless、EMR on EKSの三つの形態。Spark/Hive/Presto/Trino/Flink/HBaseなどほぼすべてのOSSコンポーネント。
GCP Dataproc: Spark + Hadoop中心。Dataproc Serverlessが急成長。
Azure HDInsight: 2026年に新規ワークロードはほぼなく、Synapse + Fabricへ吸収される流れ。
Azure Synapse / Microsoft Fabric: Azureデータプラットフォームの主流に定着。OneLakeが事実上Iceberg/Delta上の統合ストレージ。

EMR Serverlessは2026年に「Sparkジョブを少しだけ走らせて消える」パターンに適しており、採用率が高い。LambdaでなくEMR Serverlessでバッチ ETLを回すパターンが普通になった。

Cloudera + Hortonworks時代の遺産 — CDPの現在

Hadoopの商業的中心だったClouderaとHortonworksは2018年合併後、CDP(Cloudera Data Platform) という単一製品に統合された。2026年現在、CDPの位置は次の通り。

新規採用はほぼない。クラウドマネージド(EMR/Dataproc)もしくはフルマネージド(Databricks/Snowflake)が新規ワークロードを取った。
オンプレミス金融機関・通信事業者の更新 が売上の中心。データ主権、コンプライアンスが重要な大規模環境。
CDP Public Cloud: クラウド互換を試みたが、EMR/Dataproc/Databricks比で差別化が弱い。

Apache Bigtop、Apache Ambari、Apache RangerなどのOSS運用ツールは生き残った。特にRangerはlakehouse時代でもデータガバナンス/アクセス制御の標準として用いられる。

韓国のビッグデータ運用 — Naver · Kakao · KT · Coupang · Woowa Brothers

韓国の大手テック企業はOSS Hadoopエコシステムを深く運用してきた。

Naver: 自社クラスタでペタバイト級のHadoop/Sparkを運用。検索ログ、広告、CLOVA LLM学習データまで。2026年には自社K8s + Sparkプラットフォームへ漸進移行。Naver Search TechブログでIceberg導入記を公開。
Kakao: KEMI(Kakao Enterprise Machine Intelligence)データプラットフォームが標準。Hadoop + Spark + Hiveを経てIceberg + Trinoの組合せへ移行中。Techブログで多年の変遷史を公開。
KT: 通信BSS/OSSデータ用のオンプレHadoopクラスタ。KT GiGA Genie音声データ分析にも活用。CDPライセンスユーザー。
Coupang: AWS EMR + Iceberg + Trino + Airflow中心。クラウドネイティブデータスタックの韓国代表事例。
Woowa Brothers (Baemin): Spark + Airflow + Snowflake構成。配達データのリアルタイム/バッチ分析にKafka + Flink + Spark Streamingを併用。
NHN、LG CNS、Samsung SDS: 大手SI/プラットフォーム事業者も独自のデータプラットフォームを運用。Hadoopベースからlakehouseへの移行が進行。

採用市場でも「Hadoop、Spark、Hive経験」より「Iceberg、dbt、Airflow、Snowflake/Databricks」が明記されたポジションが増えた。2024年には韓国データエンジニア募集要項にIcebergはまれだったが、2026年5月時点では大手IT/金融機関で普通になった。

日本のビッグデータ運用 — LINE · ZOZO · NTT · Rakuten · Mercari

日本市場は韓国より保守的でオンプレ比率が大きいが、2026年に入って変化のスピードが速くなった。

LINE Yahoo: Hadoopクラスタを数年運用。検索、広告、メッセージ分析。LINE EngineeringブログにSpark/Hive運用記多数。2025年からIceberg + Trino導入段階。
ZOZO: Spark on Kubernetesの日本代表事例。ZOZO TECH BLOGでEKS + Spark + Iceberg運用記を公開。CDC、マルチテナントパターンまで。
NTTデータ: エンタープライズ/金融/公共データプラットフォームSI。CDPライセンスユーザー。日本ビッグデータベンチマーク/白書を多数発行。
楽天 (Rakuten): 自社データプラットフォームRIDEを運用。Hadoop + Spark + Hiveベース。AI統合が進行中。
メルカリ (Mercari): GCP BigQuery + dbt + Looker中心。クラウドネイティブ日本代表事例。
CyberAgent: 広告データプラットフォーム。Spark/Flink/Kafkaを運用。AI Labのデータパイプライン事例を公開。
DeNA、GREE、グリー: ゲーム/エンターテイメントデータプラットフォーム。Athena、Glue、EMRを活用。

日本市場の特徴は オンプレ比率が韓国より高い 点だ。金融、通信、製造業がデータ主権の問題からクラウド移行を慎重に進める。しかしlakehouseパターン自体は急速に採用されている。

Kafkaとストリーミングバックボーン — データの動脈

データエンジニアリングスタックの中央には Kafka がある。2026年5月時点でのKafkaの位置は以下。

Apache Kafka 4.0: KRaftモードが標準。ZooKeeper依存を完全排除。
Confluent Cloud: フルマネージドSaaS。TableflowでKafkaトピックをIcebergテーブルへマテリアライズ。
AWS MSK: AWSネイティブ。Serverlessオプションが人気。
Redpanda: C++で再実装したKafka互換ブローカ。低レイテンシ + シンプル運用。
WarpStream: Kafka互換 + S3バックエンド。コスト最適化。

ストリーミングSQLレイヤーはFlink SQLとksqlDBに分かれるが、2026年のトレンドは Flinkがより標準 だ。ksqlDBはConfluent内では強いが、OSSの活発さはFlinkが圧倒的。

CDC(Change Data Capture)は Debezium が標準で、Flink CDCが急速に追い上げている。AirbyteやFivetranのようなELT SaaSもCDCに対応するが、大規模トラフィックではDebezium + Kafkaが一般的だ。

Airbyte、Fivetran、Stitch — ELT自動化

ELTの取り込み(ingestion)部分はSaaSツールが標準となった。

Fivetran: 最多コネクタ(500超)。価格は高いが安定性/管理負担が小さい。
Airbyte: OSS + クラウド両方提供。コネクタ約350個。セルフホスト可能。
Stitch: Talend傘下。シンプルなSQL DB取り込みでコスパ良。
Meltano: SingerベースOSS。コードファーストユーザー向け。
Hevo Data: ノーコード + 変換統合。APAC市場で人気。
Estuary Flow: リアルタイムCDC + SQL。新規チャレンジャー。

Airbyteは2024年のConnector Builder + Low-Code CDKでコネクタ作成の障壁を大きく下げ、2026年にはLLMベースの自動コネクタ生成も試みている。

dbt + Airbyte/Fivetran + Snowflake/BigQuery + Looker/Mode/Hexという モダンデータスタック(Modern Data Stack) の組み合わせは2020-2022年に頂点を迎え、2026年ではlakehouseトレンドと結合してdbt + Iceberg + Trino/Databricksの方がより一般的だ。

データカタログとガバナンス — Unity、Polaris、Nessie、OpenMetadata

データ資産の急増に伴い、カタログが一級インフラとなった。

Unity Catalog: Databricks出身、2024年OSS化。Iceberg + Delta双方をサポートするマルチフォーマットカタログへ拡大。
Apache Polaris: Snowflakeが作ったIceberg RESTカタログ。ASFへ寄贈。
Project Nessie: Dremio後援。Git的なブランチ/マージ可能なカタログ。
OpenMetadata: メタデータ/リネージ/ガバナンスを統合するOSS。
DataHub: LinkedIn出身OSS。アセット検索、リネージ、オーナーシップ追跡。
Atlan、Alation、Collibra: エンタープライズカタログSaaS。

2026年の核心テーマは 「Iceberg RESTカタログ標準」 だ。Snowflake Polaris、Databricks Unity Catalog、Nessie、AWS Glueがすべてこの仕様に従えば、一つのカタログから複数エンジンが同じデータにアクセスする絵が完成する。Lakehouse時代のマルチエンジン約束がようやく実現する。

データ品質とオブザーバビリティ — Monte Carlo、Great Expectations、Soda

データパイプラインの品質を担保するツールが独立カテゴリになった。

Monte Carlo: データオブザーバビリティSaaSの第一世代。SLA、「data downtime」概念。
Great Expectations: OSSデータ検証。Pythonフレンドリー。
Soda: YAMLベースのデータ品質ルール。OSS + Cloud。
Bigeye: MLベースの異常検知。
Elementary: dbtネイティブのオブザーバビリティOSS。
Datafold: データdiffツール。dbt PRの自動レビュー。

dbt内で dbt test によりNULL/ユニーク検証を行い、その上にGreat Expectations / Sodaを重ねてビジネスルールを検証し、Monte Carlo / Elementaryで運用SLAを見る — というのが2026年の標準パターン。

データメッシュとデータコントラクト — 組織とインフラの結合

2020-2022年に登場した データメッシュ(Data Mesh) 概念は2026年に入って徐々に現実化してきた。シンプルな定義は以下。

データを製品と見なす — ドメインチームがデータプロダクトを所有。
データプロダクトは セルフサービスインフラ 上で動く — データプラットフォームチームがインフラを提供。
連邦ガバナンス(federated governance) — 中央の標準 + 分散運用。

これを実現するため データコントラクト(Data Contract) というパターンが浮上した。スキーマ + SLA + セマンティクスを明示した契約書だ。ツールとしては dbt contracts、Open Data Product Standard、Data Contract CLI、Soda Contracts がある。

データメッシュが向いている組織は(1)ドメインチームが独立しており、(2)データプロダクトの需要が多く、(3)中央データチームがボトルネックの大規模組織だ。小さい組織では単一データチームの方が効率的だ。

オンプレミスビッグデータの現実 — 銀行、通信、政府、製造

クラウド時代でも、2026年もオンプレミスのビッグデータは依然大きな市場だ。主な環境は以下。

銀行/証券: データ主権、コンプライアンス(GDPR/PIPA)、監査追跡要求。Hadoop + Hive + Spark + Ranger。
通信事業者: BSS/OSSデータがペタバイト級。網内分析。CDP/HDInsight + 自社OpenStack/K8s。
政府/公共: データセンター隔離、ネットワーク分離。自社lakehouse構築。Iceberg + Spark + Trino on K8s。
製造業: 工場OT(Operational Technology) + IT統合。時系列DB(InfluxDB、TimescaleDB) + Spark。
ヘルスケア/保険: 患者データ保護。自社HDFSまたはCeph + Spark。

オンプレミスビッグデータの近年の変化は Kubernetesへの漸進的移行 である。YARNの代わりにK8s、HDFSの代わりにMinIO/Ceph、Cloudera Managerの代わりにArgoCD + Spark Operator + Flink Operator。2026年には「オンプレでもlakehouseアーキテクチャを使える」が自然になった。

Spark Operatorのマニフェストは次のような形だ。

apiVersion: sparkoperator.k8s.io/v1beta2
kind: SparkApplication
metadata:
  name: nightly-iceberg-compaction
  namespace: data
spec:
  type: Scala
  mode: cluster
  image: registry.internal/spark:4.0.0
  mainApplicationFile: s3a://jobs/compaction.jar
  sparkVersion: "4.0.0"
  driver:
    cores: 2
    memory: 4g
    serviceAccount: spark
  executor:
    cores: 4
    instances: 8
    memory: 8g
  deps:
    jars:
      - "https://repo1.maven.org/maven2/org/apache/iceberg/iceberg-spark-runtime-3.5_2.13/1.6.0/iceberg-spark-runtime-3.5_2.13-1.6.0.jar"
  hadoopConf:
    "fs.s3a.endpoint": "https://minio.internal:9000"
    "fs.s3a.path.style.access": "true"

ビルドと投入は次の通り。

# Spark Operatorのインストール
helm repo add spark-operator https://kubeflow.github.io/spark-operator
helm install spark-operator spark-operator/spark-operator \
  --namespace spark-operator --create-namespace \
  --set sparkJobNamespaces='{data}'

# Iceberg RESTカタログのクイック起動
docker run -d --name iceberg-rest \
  -p 8181:8181 \
  -e CATALOG_WAREHOUSE=s3://lakehouse/ \
  -e CATALOG_IO__IMPL=org.apache.iceberg.aws.s3.S3FileIO \
  apache/iceberg-rest-fixture:latest

# ジョブ投入
kubectl apply -f nightly-iceberg-compaction.yaml
kubectl get sparkapplications -n data

データエンジニアリング採用市場 — 2026年5月のスナップショット

データエンジニアリング採用市場のキーワードも急速に変わった。

2020年: Hadoop、Hive、MapReduce、Sqoop、Oozie
2023年: Spark、Airflow、Snowflake/BigQuery、dbt、Kafka
2026年: Iceberg/Delta、Trino、Flink、dbt+SQLMesh、Airflow 3.0/Dagster、Spark 4.0、lakehouseアーキテクチャ

LinkedInで「data engineer」を検索した際の頻出ツール(2026年5月の体感観察):

ツール	頻度(体感)	備考
Spark	非常に高い	事実上必須
Airflow	非常に高い	事実上必須
dbt	非常に高い	新規ポジションの大半に明記
Snowflake/BigQuery/Databricks	非常に高い	1-2つの経験要求
Iceberg/Delta	高い	2024年比で激増
Trino/Presto	中	特定ドメインで必須
Flink	中	ストリーミングポジション
Kafka	非常に高い	事実上必須
Kubernetes	中〜高	プラットフォームポジション
Hadoop/Hive	低(レガシー)	保守ポジションのみ

新規ポジションで「Hadoop運用経験」が必須要件として挙がるケースは大幅に減った。代わりに「S3/Iceberg上でSpark/Trinoを運用した経験」が標準となった。

学習パス — 2026年データエンジニア入門推奨

データエンジニアを新たに始めるなら、2026年5月時点で以下の順序を推奨する。

SQLを深く習得する。PostgreSQL/MySQLいずれか一つを深く。
Python + pandas/Polars/DuckDB でローカルデータ処理。DuckDBはlakehouse学習にも直結。
Apache Spark: PySparkから開始。RDDからではなくDataFrame/SQLから。
Apache Airflow + dbt: オーケストレーション + 変換。モダンデータスタックの中核。
Apache Kafka + Flink/Spark Streaming: ストリーミング基礎。
クラウド一つ: AWS(S3 + EMR + Athena + Glue)もしくはGCP(GCS + Dataproc + BigQuery)。
テーブルフォーマット: Icebergを深く。DeltaはDatabricks環境で自然に学ぶ。
Trino: フェデレーテッドクエリ + ad-hoc分析。
Kubernetes基礎: Spark/Flink Operatorのレベルまで。
データモデリング/Kimball: ディメンションモデリングは依然重要な基本。

書籍: Designing Data-Intensive Applications (Martin Kleppmann)、Fundamentals of Data Engineering (Joe Reis & Matt Housley)、The Data Warehouse Toolkit (Kimball)。

動画/ブログ: Databricks Data + AI Summit、Snowflake Summit、Airflow Summit、Iceberg/Trino Summit基調講演 + 韓国データエンジニアリングカンファレンス(DEvFest、Pycon Korea Data Track)。

参考資料 (References)

Apache Hadoop — https://hadoop.apache.org/
Apache Spark — https://spark.apache.org/
Apache Flink — https://flink.apache.org/
Trino — https://trino.io/
Apache Iceberg — https://iceberg.apache.org/
Delta Lake — https://delta.io/
Apache Hudi — https://hudi.apache.org/
Apache Airflow — https://airflow.apache.org/
Dagster — https://dagster.io/
Prefect — https://www.prefect.io/
dbt — https://www.getdbt.com/
SQLMesh — https://sqlmesh.com/
Databricks — https://www.databricks.com/
Snowflake — https://www.snowflake.com/
Google BigQuery — https://cloud.google.com/bigquery
AWS Redshift — https://aws.amazon.com/redshift/
Confluent — https://www.confluent.io/
Apache Kafka — https://kafka.apache.org/
ClickHouse — https://clickhouse.com/
DuckDB — https://duckdb.org/
Apache Pinot — https://pinot.apache.org/
Apache Druid — https://druid.apache.org/
Apache Polaris — https://polaris.apache.org/
Project Nessie — https://projectnessie.org/
OpenMetadata — https://open-metadata.org/
DataHub — https://datahubproject.io/
Monte Carlo — https://www.montecarlodata.com/
Great Expectations — https://greatexpectations.io/
Airbyte — https://airbyte.com/
Fivetran — https://www.fivetran.com/
NAVER D2 Blog — https://d2.naver.com/
Kakao Tech Blog — https://tech.kakao.com/
LINE Engineering — https://engineering.linecorp.com/
ZOZO TECH BLOG — https://techblog.zozo.com/
Mercari Engineering — https://engineering.mercari.com/