Chaos and Order

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

はじめに — 51ポイントの地図、そして地図が決めてくれないもの
五つの層と、各層の本当の決定
収集 — 決定はコネクタではなく所有権
保存 — フォーマット戦争は終わり、争いはカタログへ移った
変換とオーケストレーション — コンパイラの居場所、そして失敗処理モデル
境界が崩れる地点 — 計算がローカルへ引き寄せられる
市場はどこへ合流しているか
ツールを実際に選ぶ六つの質問
おわりに — 地形は変わっても問いは残る
参考資料

はじめに — 51ポイントの地図、そして地図が決めてくれないもの

2026年7月28日、GeekNewsに開発者のためのデータツール地形ガイドが投稿され、51ポイントを獲得しました。原文は、データの世界に初めて足を踏み入れたソフトウェア開発者を対象に、収集から保存・処理・オーケストレーション・消費・ガバナンスまでを一通り扱います。ファイルフォーマット(CSV、Parquet、ORC、Avro、Arrow)、ウェアハウスとレイクとレイクハウス、収集ツール(Fivetran、Airbyte、dlt、Debezium)、変換(dbt、SQLMesh)、分散処理(Spark、Dask、Ray、Flink)、オーケストレーション(Airflow、Dagster、Prefect)、メダリオンアーキテクチャ、セマンティックレイヤーとカタログ、BIツールまで — 一覧として充実しています。

良い地図です。ただ、地図は目的地を決めてくれません。この分野の本当の難しさは「AirbyteかFivetranか」ではなく、この層で自分が実際に下している決定が何かを知らないままツールを選ぶことにあります。だから半年後、同じ層で同じ悩みをもう一度することになります。

この記事は同じ地形を描き直しますが、各層でツール名の代わりに決定の軸を立てる形で整理します。そして2026年現在、その軸がどこで崩れつつあるかを押さえます。

五つの層と、各層の本当の決定

層の分け方はいろいろありますが、決定の性質が変わる地点で切ると五つになります。

層	よく並べられるツール	この層の本当の決定	境界が崩れる方向
収集	Fivetran、Airbyte、dlt、Debezium	コネクタを買うか、所有するか	変換ベンダーが収集まで吸収
保存・テーブルフォーマット	S3、Snowflake、BigQuery、Iceberg、Delta、Hudi	データが誰のストレージにあるか	フォーマットは収束、ロックインはカタログへ移動
変換	dbt、SQLMesh、Spark	SQLをどこでコンパイルし、どこで実行するか	コンパイラとエンジンの分離
オーケストレーション	Airflow、Dagster、Prefect	失敗したとき何が自動で復旧するか	タスクグラフからアセットグラフへ
サービング・消費	ClickHouse、Druid、Pinot、Tableau、Metabase、Cube	指標定義がどこに一元化されているか	セマンティックレイヤーがカタログに吸収

三列目がこの記事の全てです。ツール名は3年ごとに変わりますが、あの問いは変わりません。以下で一つずつ見ていきます。

収集 — 決定はコネクタではなく所有権

収集層で人々が比較するのは、たいていコネクタの数と価格です。実際に分かれるのは別の軸です。

コネクタを自分で保守するか、他人に任せるか。 SalesforceやStripeのようなSaaS APIは、予告なくスキーマが変わり、レートリミットが静かに絞られ、ページネーション方式がある日変わります。マネージド収集サービスの価値はコネクタそのものではなく、その変更を代わりに追いかけてくれる人員です。逆にソースが社内のPostgresが数個だけなら、その人員は買わなくてよく、この場合マネージドサービスの行単位課金は純粋な無駄になります。

変更データキャプチャが必要か。 バッチで全体を読み直すのと、WALを読んで変更だけを流すのとでは、運用負担がまったく違います。Debezium系のCDCはソースDBに論理レプリケーションスロットを確保する必要があり、スロットが遅れるとソースDBのディスクが埋まります — つまり収集パイプラインの障害がプロダクションDBの障害に波及する経路が生まれます。この危険を冒すだけ鮮度が重要かどうかが実際の決定です。

抽出したデータのスキーマを誰が定義するか。 元のスキーマをそのまま複製する方式(ELTのデフォルト)は始めるのが速いですが、ソースチームがカラムを削除すると下流全体が壊れます。契約を明示する方式は遅いですが、その破損は収集地点で止まります。組織の規模がこの選択を決めます — ソースチームとデータチームが同じ部屋にいれば前者で十分で、部署が違えば後者が必要です。

Pythonライブラリでパイプラインを直接書く選択肢(dlt系)が最近勢いを得ているのもここに理由があります。コネクタは所有しつつ定型作業はライブラリに任せる中間地帯で、ソースが10個以下のとき大体最も安く済みます。

保存 — フォーマット戦争は終わり、争いはカタログへ移った

数年間、この層の問いは「Icebergか、Deltaか、Hudiか」でした。2026年現在、その問いはおおむね決着しています。

Iceberg v3仕様は2025年半ばに批准され、1.10〜1.11のリリース系列を経て削除ベクター(deletion vectors)、半構造化データ向けvariant型、行系譜(row lineage)、地理空間型が入りました。Snowflake、Databricks、Amazon S3 Tablesがいずれもv3サポートをGAと宣言しています。ここで重要なのは、v3が吸収した機能群がもともとDelta Lakeの差別化ポイントだったということです。削除ベクターと行系譜がIcebergに入ったことで、「性能か相互運用性か」という選択そのものが消えました。Databricksはさらに一歩進んで、Iceberg v4の適応型メタデータツリーを提案し、Delta 5.0も同じ構造を採用すべきだと表明しました。方向は収束です。

フォーマットが収束すると、ロックインはどこへ行くのか — カタログです。どのテーブルが存在し、その最新メタデータファイルが何かを教えるサービスで、ここにアクセス制御と監査と資格情報のベンディングが付きます。Iceberg RESTカタログ仕様が事実上のインターフェースになり、Apache Polaris・Unity Catalog・AWS Glue・各クラウドの実装がその上で競っています。

そしてカタログ層はまだ足並みが揃っていません。v3機能はカタログAPIを通って入ってきますが、すべてのカタログがv3テーブルの作成をサポートしているわけではありません — 2026年半ば時点でAWS GlueはRESTのCreateTable経路でv3テーブルを作れないと報告されています(エンジン側では扱える場合があります)。つまり「Icebergを使っている」という言葉はもう十分な説明ではないということです。実際に問うべきはこうです。

どのカタログを使っているか、そしてそのカタログを別のものに変えるときデータを書き直さずに済むか
自分たちのエンジン(Spark、Trino、DuckDB、各ウェアハウス)がそのカタログのREST実装に接続できるか
書き込み権限を持つエンジンがいくつあるか — 複数なら同時書き込みの競合処理を誰が保証するか

この三つを言葉ではなく手で確認する方法があります。ベンダーのコンソールではないツールで同じテーブルを読んでみることです。 30分で終わり、開放性の主張に対する最も正直な検証です。

-- DuckDBからRESTカタログに直接接続してみる。
-- ウェアハウスのコンソールを経由せずにこれができれば、そのテーブルは本当に開かれている。
INSTALL iceberg; LOAD iceberg;
INSTALL httpfs;  LOAD httpfs;

CREATE SECRET catalog_auth (
    TYPE ICEBERG,
    CLIENT_ID     'svc-analytics',
    CLIENT_SECRET 'redacted'
);

ATTACH 'my_warehouse' AS lake (
    TYPE ICEBERG,
    ENDPOINT 'https://catalog.internal.example.com/api/catalog'
);

SHOW ALL TABLES;
SELECT count(*) FROM lake.analytics.orders WHERE order_date >= DATE '2026-07-01';

-- スナップショット履歴が見えれば、タイムトラベルとロールバックも自分たちのものだ
SELECT * FROM iceberg_snapshots('lake.analytics.orders');

# カタログを経由せず、オブジェクトストレージだけを見てもテーブル構造が残っているか
aws s3 ls s3://lake-prod/analytics/orders/metadata/ --human-readable | tail -5
# v00042-....metadata.json と snap-....avro が見えれば
# カタログを差し替えてもデータはそのままだ

行系譜のようなv3で新たに入った機能が実際どう保存され何を保証するかは、Iceberg v3ロウリニージ — 行IDはファイルに保存されない編に別途まとめています。

一方でこの層には別方向からの挑戦者もいます。DuckDB財団が作ったDuckLakeは、メタデータをファイルツリーで管理する代わりにSQLデータベースに入れます。カタログバックエンドとしてPostgreSQL、SQLite、DuckDBを使え、データは依然としてParquetです。v1.0が2026年4月に後方互換保証とともにリリースされました。論点は単純です — メタデータの照会はもともとデータベースが得意な仕事なのに、なぜオブジェクトストレージ上のファイルツリーを漁っているのか、というものです。ただし採用規模はIcebergと比較できる段階になく、複数エンジンが共有する組織標準にするにはまだ早いです。

変換とオーケストレーション — コンパイラの居場所、そして失敗処理モデル

変換層の本当の決定は「SQLをどこでコンパイルし、どこで実行するか」です。 dbt系のツールはデータを直接触りません。SQLテンプレートを展開して依存グラフを作り、ウェアハウスの方言にコンパイルして投げ、結果をテーブルやビューとしてマテリアライズします。つまりコンパイラでありビルドシステムでもあるということです。だからこの層で実際に問うべきはこうです。

モデル間の依存グラフをツールが静的に知れるか、それとも実行してみないと分からないか。静的に分かるなら影響分析と部分再実行が可能になります。
コンパイル結果がどのエンジンでも動くか。ウェアハウスを変えるとき変換コードをどれだけ書き直す必要があるかがここで決まります。
増分マテリアライゼーションの正確性を誰が保証するか。遅れて到着するデータとバックフィルがこの層で最もバグを生みます。

この三つを踏まえると、近年の動きが読めます。Pythonのテンプレート文字列をレンダリングする方式から、SQLを実際にパースして列単位の系譜まで静的に把握する方式へ移りつつあり、dbt FusionエンジンとSQLMeshは同じ方向です。

オーケストレーション層の本当の決定はスケジューリングではなく失敗処理です。 cronでもスケジュールはできます。オーケストレーターを導入する理由は「3時のジョブが失敗したら5時のジョブが自動で止まり、原因を直した後にその二つだけが再実行される」という挙動のためです。だから問うべきはこうです。

失敗の単位がタスクかデータアセットか。後者なら「このテーブルが最新か」をシステムが把握しており、再実行の範囲を自ら計算します。
バックフィルがファーストクラスの概念か。過去90日をやり直す作業がボタン一つか臨時スクリプトかが運用負担を決めます。
ストリーミングはこのグラフに入るか。ほとんどのオーケストレーターはバッチDAG向けで、ストリーミングパイプラインは別のライフサイクルを持ちます。無理に一つのツールに詰め込むと両方とも扱いにくくなります。

Airflow 2がEOLを過ぎ、この層は今まさに引っ越し中です。3.xへ移るとき実際の作業リストが何かはAirflow 2 EOL以降 — 2から3への実際の作業リスト編にまとめています。

境界が崩れる地点 — 計算がローカルへ引き寄せられる

過去10年の基本前提は「データは大きいのでクラスタへ行く」でした。この前提が二方向から侵食されています。

一つはハードウェアです。 ノートパソコンに32〜64GBのメモリが当たり前になり、NVMeがGB/s単位で読み込みます。そしてほとんどの分析クエリが実際に触るデータは、思われているよりずっと小さいのです — カラム指向ストレージで必要な列だけ、パーティションプルーニングで必要なパーティションだけを読めば、テラバイト級テーブルから数百MBだけスキャンする場合が珍しくありません。

もう一つは単一ノードエンジンの成熟です。 DuckDB、Polars、DataFusionはベクトル化実行とメモリを超えるデータのディスクスピルを備え、S3のParquetとIcebergテーブルを直接読みます。結果として、「クラスタを立てノートパソコンを接続してSQL一行を動かす」ことが必要だった作業のかなりの部分が、単一バイナリまで降りてきました。

この流れが生む実務的な変化は三つです。

開発ループが短くなります。 変換ロジックをローカルで実データのサンプルに対して動かしてコミットします。クラスタの待ち行列が消えます。
コスト構造が変わります。 ウェアハウスのコンピュート課金はクエリ単位ですが、探索的分析がローカルへ降りるとその請求書は消えます。
境界があいまいになります。 DuckDBにクライアント・サーバープロトコルができたことで(2026年5月のv1.5.3のQuackリモートプロトコル)、「組み込みエンジン」と「クエリサービス」の区別があいまいになりました。この変化が実際に何を変え何を変えないかはDuckDBにクライアント・サーバープロトコルができた編で扱っています。

もちろんクラスタが消えるわけではありません。分かれる地点は明確です — 一回のクエリが触るデータが一台のメモリとディスクに収まるか、そして複数人が同時にその作業をするかです。前者でなければ分散が必要で、後者ならサーバーが必要です。組織全体の夜間バッチをローカルエンジンで回すという計画は、大抵半年後に後悔します。逆にアナリスト一人の探索のためにSparkクラスタを立てるのも同じです。

Sparkの側もじっとしてはおらず、Python UDF経路がArrowベースに再整備され、PythonとJVMの間のシリアライズコストが大きく減りました — PySpark 4.2でArrow UDFがデフォルト化編を参考にしてください。

市場はどこへ合流しているか

層ごとの決定を話したので、その層が一つに合流していく流れも見る必要があります。2026年最大の出来事はFivetranとdbtLabsの合併です。2025年10月13日に発表され2026年6月1日に完了し、全株式交換で、プレスリリース基準で10万を超えるデータチームを相手にしています。George FraserがCEO、Tristan HandyがPresidentです。(合算ARR規模としてよく引用される数字がありますが、プレスリリースには数値がないため、ここでは引用しません。)

この合併の意味は前掲の表の四列目です。収集と変換が一つの会社にまとまりました。 これまで「収集はA、保存はB、変換はC、オーケストレーションはD」と各層のベストを組み合わせるのがモダンデータスタックの美徳でしたが、その組み合わせコスト(メタデータが層ごとに途切れ、系譜がつながらず、失敗原因を層をまたいで追跡しなければならない)が実際には大きかったという認めでもあります。

同時にこの会社が狙う相手は明確です — Snowflake、Databricks、Microsoft Fabricのようなオールインワンプラットフォームです。そして差別化として掲げるのがオープン標準です。SQLとIcebergの上に立つということで、実際にdbt Fusionエンジンのランタイムをapache 2.0でdbt Core v2.0(アルファ)に入れました。

ここで読み取るべきことは二つです。

第一に、層の境界がベンダーの境界と一致しなくなります。 「私たちは層ごとに最適なツールを使う」という戦略が、実際には「私たちは三つのベンダーのバンドルを使う」になりつつあります。ツールを選ぶとき、そのツールが属するバンドルが何を一緒に引き連れてくるかを見る必要があります。

第二に、統合の代償は常に移行コストです。 オープンフォーマットの上にあるという約束が実質的かどうかを確認する方法は一つしかありません — ベンダーを消したとき何が残るかを数えることです。テーブルがIcebergのまま残り、カタログを別実装に向けられ、変換SQLが別エンジンで動けば、その約束は実質的です。三つのうち一つでも違えば、それはマーケティングです。

ツールを実際に選ぶ六つの質問

層ごとの決定を一つのチェックリストに圧縮するとこうなります。ベンダー比較表よりこちらのほうがずっと速く答えを絞り込めます。

このデータを誰が読み、どれだけ新鮮である必要があるか。 ダッシュボードを朝見る人だけならバッチで終わり、製品画面に入るならサービング層と遅延予算が必要です。この一問がストリーミング導入の要否をほぼ決めます。
最大の単一クエリが触るデータは一台に収まるか。 収まるなら分散エンジンはまだ不要です。前節の境界です。
このパイプラインが失敗したとき何が自動で復旧し、何を人がやらねばならないか。 ここで答えが「全部人」なら、オーケストレーターより先に運用モデルを直すべきです。
指標の定義がどこに一元化されているか。 BIツールとノートブックと製品コードがそれぞれ「アクティブユーザー」を計算しているなら、ツールをもう一つ買っても解決しません。
このツールを消したとき、データはどこにどんな形で残るか。 オープンフォーマットという主張を検証する唯一の質問です。
これを運用する人が何人いるか。 最も無視されがちで、最もプロジェクトを潰しがちな質問です。Airflow一つをきちんと運用するのにも人が要ります。二人チームが五つの層を自前運用すると決めた場合、半年後そのチームはデータの仕事ではなくインフラの仕事をしています。

原文ガイドが最後に扱うガバナンスは、実は6番と同じ話です。アクセス制御、所有権、個人情報の系譜、保存ポリシーはツールとして買うものではなく人が遂行するものであり、ツールはその遂行を安くするだけです。

おわりに — 地形は変わっても問いは残る

まとめるとこうなります。

層ごとにツールを選ぶのではなく、層ごとの決定をまず明確にし、その決定に合うツールを選びます。ツール一覧は3年ごとに変わり、決定の軸はそのままです。
テーブルフォーマット戦争は、Iceberg v3がDeltaの差別化機能を吸収したことで事実上終わりました。実質的なロックインとガバナンスはカタログ層へ移り、カタログの実装群はまだ機能が揃っていません。
単一ノードエンジンがクラスタの仕事のかなりの部分をローカルへ引き寄せてきました。分かれる基準はデータサイズそのものではなく、「一台に収まるか」と「複数人が同時にやるか」です。
市場は層を横断して合流しつつあります。FivetranとdbtLabsの合併がその兆候で、対応の軸はオープンフォーマットの上に立っているかを実際に検証することです。
ツール選びはたいてい六つの質問の中で決着します。中でも最後の質問(運用する人が何人か)が最も無視されがちです。

地形図は有用ですが、地形図を覚えることと道を決めることは別の作業です。次にツール比較表を開く前に、その層で自分が何を決めようとしているのかを一文で書いてみることをお勧めします。その一文が書けなければ、比較表は役に立ちません。