💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — 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レイヤーに分かれる。

1. **ストレージ(storage)**: HDFS、S3、GCS、ABFS、MinIO

2. **テーブルフォーマット(table format)**: Iceberg、Delta Lake、Hudi

3. **カタログ(catalog)**: Hive Metastore、Unity Catalog、Polaris、Nessie、AWS Glue

4. **バッチ処理(batch)**: Spark、Trino-on-Spark、Dremio

5. **ストリーミング(streaming)**: Flink、Spark Structured Streaming、Kafka Streams、Materialize

6. **クエリ/フェデレーション(query)**: Trino、Presto、Dremio、StarRocks

7. **変換(transform)**: dbt、SQLMesh、Coalesce

8. **オーケストレーション(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ケースでのみ生き残る。

1. **金融機関のデータ主権**: データが絶対に外部クラウドに出られない環境。この場合オンプレミスHDFSクラスタ + Spark/Trino。

2. **レガシーETL資産**: 数千個のHiveテーブルとOozieジョブがHDFSパスに固定されており、移行が多年プロジェクトの場合。

3. **超低レイテンシシャッフル**: 一部のグラフ/結合ワークロードでオブジェクトストレージの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月時点、三強構図が固まった。

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

| スキーマ進化 | 強力(列ID方式) | はい | はい |

| パーティション進化 | はい | 限定的 | 限定的 |

| MERGE/UPDATE | はい | はい | はい (CoW/MoR) |

| タイムトラベル | はい | はい | はい |

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:

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年もオンプレミスのビッグデータは依然大きな市場だ。主な環境は以下。

1. **銀行/証券**: データ主権、コンプライアンス(GDPR/PIPA)、監査追跡要求。Hadoop + Hive + Spark + Ranger。

2. **通信事業者**: BSS/OSSデータがペタバイト級。網内分析。CDP/HDInsight + 自社OpenStack/K8s。

3. **政府/公共**: データセンター隔離、ネットワーク分離。自社lakehouse構築。Iceberg + Spark + Trino on K8s。

4. **製造業**: 工場OT(Operational Technology) + IT統合。時系列DB(InfluxDB、TimescaleDB) + Spark。

5. **ヘルスケア/保険**: 患者データ保護。自社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月時点で以下の順序を推奨する。

1. **SQLを深く習得する**。PostgreSQL/MySQLいずれか一つを深く。

2. **Python + pandas/Polars/DuckDB** でローカルデータ処理。DuckDBはlakehouse学習にも直結。

3. **Apache Spark**: PySparkから開始。RDDからではなくDataFrame/SQLから。

4. **Apache Airflow** + **dbt**: オーケストレーション + 変換。モダンデータスタックの中核。

5. **Apache Kafka** + Flink/Spark Streaming: ストリーミング基礎。

6. **クラウド一つ**: AWS(S3 + EMR + Athena + Glue)もしくはGCP(GCS + Dataproc + BigQuery)。

7. **テーブルフォーマット**: Icebergを深く。DeltaはDatabricks環境で自然に学ぶ。

8. **Trino**: フェデレーテッドクエリ + ad-hoc分析。

9. **Kubernetes基礎**: Spark/Flink Operatorのレベルまで。

10. **データモデリング/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/