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

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

要点

• Dagster は task execution だけでなく、data asset、lineage、observability、testability を統合する orchestrator として説明されている
• asset-based orchestration は、function の順序ではなく、business/user が気にする data asset を中心に設計する考え方
• resources、partitions、software-defined assets、control plane によって heterogeneous data stack を扱う
• open data platform として、dbt、Spark、DuckDB、object storage、BI dashboard などを結びつける layer と読める

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

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

中心にあるのは、asset-based orchestration です。Airflow 的な task graph では、download、transform、serve のような function の順序が見えますが、その中でどの table、dashboard、report、ML model が作られているかは隠れがちです。Dagster の asset model では、利用者が実際に気にする outcome を asset として定義し、lineage、metadata、freshness、check、partition をその asset に近づけます。これにより、data engineer だけでなく analyst、platform team、business user が、どの data asset がどの状態かを理解しやすくなります。

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

また、Dagster の control plane は metadata を集める場所として描かれています。pipeline run、asset lineage、materialization、check、schedule、sensor、backfill が一つの operational view にまとまることで、open data platform 的な役割を果たします。AI agent が data workflow を扱う時代には、business definition だけでなく、pipeline が成功したか、asset が fresh か、どの upstream が壊れているかという operational context が必要になります。この意味でも Dagster の data-aware control plane は、AI-ready data stack の一部として読めます。

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

1. DAG の task ではなく、利用者が必要とする data asset を中心に設計できているか見る
2. compute、storage、integration を resources として差し替え可能にする
3. asset lineage、freshness、checks を operational dashboard に集約する
4. AI agent に data workflow を触らせる場合、business context と operational context の両方を渡す

どう読むべきか

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