Dagster基本のき

## はじめに
社でDagsterの導入をしているのですが、プロジェクトが進んでいく中でしっかり勉強せにゃダメだよねという話になり(当たり前)、エンジニアに勧められて[DagsterUniversity](https://courses.dagster.io/courses/dagster-essentials)を進めています。

せっかく勉強をするのでOutputをしていこうと思います。
この記事では「基本のき」ということで、具体的なツールの使い方ではなくDagsterって何するツールなの？と言うこととDagsterを理解する上で必要となるasset-centricと言う概念に関してのみ紹介をしていきます。
(個人の解釈も混ざっています、ご容赦ください)


## オーケストレーション
データエンジニアリングの分野には、データオーケストレーションツールなるものが存在しており、Dagsterもその一つです。

何なのか一言で言うと「データ処理のワークフローを管理したり実行したりできるツール」で、複数のデータ処理の実行順(依存関係)の定義や、定義したワークフローの定期実行が可能です。
また、ツール上で定義した依存関係や、各処理の実行ステータスはUI上で視覚的に確認することができます。(Dagsterの[Docs](https://docs.dagster.io/getting-started/what-why-dagster#why-dagster)に載っている図で何となくイメージを持っていただけるかと)


オーケストレーションツールがある嬉しさは「データがたくさんあっていろんな集計、分析を依頼されている」みたいな状況を想像すると分かりやすいと思います。

データがたくさんあり、集計や分析の処理が複数存在していると、必然的にデータの参照関係、処理の依存関係も複雑化して行きます。そう言った状況でそれらの関係性を確認できるツールが無いと、エラーが起きた時に「どの処理が原因なのか分からない」「そもそも関係している処理の全容が分からない」と言った状況に陥りかねません。
逆に依存関係が見えてエラー箇所をすぐに特定できていれば、修正や関係者への周知といった動きがスムーズに取れます。
また、ワークフローがどうなっているのか可視化されるので、複雑化している部分を作り直すと言った意思決定も一定し易くなります。

![compare.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1129879/792be6c1-42bb-7433-8e84-cd50d4659aab.png)



## Task-centric と asset-centric
Dagster University曰く、オーケストレーションには2種類のアプローチがあります。
一つはtask-centricでもう一つはasset-centricです。

データ処理のワークフローというと、データ処理A、データ処理B,...と処理を繋げていく下図のようなイメージを持つ方が多いのではないかと思いますが、この発想自体が実はtask-centricな考え方と言えます。

```plantuml
@startuml
<style>
root {
  Padding 0
  Margin 0
}
footer {
  FontColor black
  FontSize 17
}
</style>
footer Task-centricなワークフローの表現の例
title <img:https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1129879/76c3a5d0-8353-2b5e-35d6-2080be9c1ab1.png>
@enduml
```
<!--
![task_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1129879/76c3a5d0-8353-2b5e-35d6-2080be9c1ab1.png)
-->

このワークフローにおけるノードA, B, Cはそれぞれがデータを加工するタスクであると捉える事ができますね。あくまでもA, B, Cはタスク(処理そのもの)であり、ここにデータを流すことで最終的に欲しい形に加工されたデータが出力される訳です。

これに対してasset-centricアプローチの場合、タスクそのものではなくタスクによって得られたアウトプットに着目をします(Dagster Universityではtask-centricの場合howに重きを置き、asset-centricの場合whatに重きを置く、といった表現しています)


```plantuml
@startuml
<style>
root {
  Padding 0
  Margin 0
}
footer {
  FontColor black
  FontSize 17
}
</style>
footer asset-centricなワークフローの表現の例
title <img:https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1129879/88f0c1ce-7195-807a-8933-486e2a4e8ec8.png>
@enduml
```
<!--
![asset_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1129879/88f0c1ce-7195-807a-8933-486e2a4e8ec8.png)
-->


Dagsterはasset-centricなオーケストレーションツールであるため、ワークフローにおける一つ一つのノードはassetと呼ばれており、処理を実行することをmaterialize(実体化)と表現しています。
処理を実行することは、定義したassetを実体化することであり、着目しているのは処理を実行して得られたテーブルやCSV, レポートと言った成果物になります。

## 何でasset-centric?
二つのアプローチの違いは分かったが結局asset-centricにすると何が嬉しいのか、という疑問があると思います。 Dagster Universityではasset-centricの場合新しいassetを追加し拡張することが容易であると言われています。

例えば「既に存在している`Table B`と新しいassetである`Table D`をJOINして`Table E`を作ろう」と言った事がasset-centricだと直感的ですがtask-centricの場合は処理の過程を詳しく把握していないとパッとそれができるかどうか判断しづらいのではないかと思います。
```plantuml
@startuml
<style>
root {
  Padding 0
  Margin 0
}
footer {
  FontColor black
  FontSize 17
}
</style>
footer assetの追加・拡張
title <img:https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1129879/cb6190a4-82a2-0ee8-9d57-bd4874155101.png>
@enduml
```
<!--
![expanding_assets_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1129879/cb6190a4-82a2-0ee8-9d57-bd4874155101.png)
-->

ただ、どちらかのアプローチの方が優れているということでは決してないので「拡張が容易って言うならDagsterにしておくか」と言うノリで選ぶものではないかなと思います。

結局はtaskとasset(howとwhat)どちらに重点をおいて管理する方が自身の組織やプロジェクトにフィットするのかでツールを選ぶ必要がありますし、データエンジニア、データサイエンティストと言ったロールでも何を採用したいのか(何を採用すべきか)が変わるんじゃないかなと個人的には感じました。



## まとめ
感覚的には世の中にある「ワークフローを組んでデータ処理を行う」というツールはほぼtask-centricな気がしており、Dagsterのasset-centricという考え方はいまいちピンと来ない方も結構いるかもしれません。

私自身も初めはtask-centricにワークフローを組むものとして見てしまっていたのですが、dbtに触った事があったのでめちゃくちゃ自由度の高いdbtみたいなもんなのかな、という理解をして腑に落ちました(この理解が正しいのかは分かりませんが)

本記事の私の説明でDagsterに興味を持った方はぜひDagster University始めて見てください。