Dagster Almanack、data platform を complexity から composability へ読む

Dagster は 2026年5月19日、Dagster を data platform の観点から振り返る長文ブログ「The Dagster Almanack」を公開しました。task/DAG から アセット-based orchestration へ、複雑な enterprise data stack を composable に扱う視点が主題です。

要点

• Dagster は task execution だけでなく、data アセット、リネージ、オブザーバビリティ、testability を統合する orchestrator として説明されている
• アセット-based orchestration は、function の順序ではなく、business/ユーザー が気にする data アセット を中心に設計する考え方
• リソース、partitions、software-defined アセット、control plane によって heterogeneous data stack を扱う
• open data platform として、dbt、Spark、DuckDB、object storage、BI ダッシュボード などを結びつける layer と読める

今回のブログ記事で語られていること

この記事は、Dagster を長年使ってきた実務者の視点から、data orchestration がどのように task-based DAG から data-aware platform へ変化したかを整理しています。初期の ETL は cron や bash スクリプト に依存し、失敗すると次の バッチ window まで待つような運用も珍しくありませんでした。Dagster はその課題に対し、パイプライン development と operation の距離を縮め、data processing と business プロセス を結びつける tool として登場した、と振り返られています。

中心にあるのは、アセット-based orchestration です。Airflow 的な task graph では、download、transform、serve のような function の順序が見えますが、その中でどの テーブル、ダッシュボード、レポート、ML モデル が作られているかは隠れがちです。Dagster の アセット モデル では、利用者が実際に気にする outcome を アセット として定義し、リネージ、メタデータ、freshness、check、partition をその アセット に近づけます。これにより、data エンジニア だけでなく analyst、platform team、business ユーザー が、どの data アセット がどの状態かを理解しやすくなります。

ブログはさらに、enterprise data stack の complexity をどう扱うかに進みます。企業には複数 cloud、複数 source システム、複数 compute engine、複数 team が存在します。Dagster は リソース によって storage と compute を decouple し、Polars、Pandas、Arrow、DuckDB、Spark、dbt などを組み合わせ、環境ごとに差し替え可能にします。これは「一つの platform がすべてを置き換える」のではなく、heterogeneous な stack を composable に統合する発想です。

また、Dagster の control plane は メタデータ を集める場所として描かれています。パイプライン run、アセット リネージ、materialization、check、schedule、sensor、backfill が一つの operational view にまとまることで、open data platform 的な役割を果たします。AI エージェント が data ワークフロー を扱う時代には、business definition だけでなく、パイプライン が成功したか、アセット が fresh か、どの upstream が壊れているかという operational context が必要になります。この意味でも Dagster の data-aware control plane は、AI-ready data stack の一部として読めます。

実務で確認したいポイント

1. DAG の task ではなく、利用者が必要とする data アセット を中心に設計できているか見る
2. compute、storage、連携 を リソース として差し替え可能にする
3. アセット リネージ、freshness、checks を operational ダッシュボード に集約する
4. AI エージェント に data ワークフロー を触らせる場合、business context と operational context の両方を渡す

どう読むべきか

この投稿は release note ではなく、Dagster の思想と使い方を整理する practitioner essay です。data platform が複雑になっているチームほど、orchestrator を job scheduler ではなく アセット-aware control plane として見る価値があります。