Digdag x Luigi x Beam が協力して賢者の石を取りに行くのをやめた

Posted at 2018-12-07

「ハリー・ポッターと賢者の石」でハリー・ポッター、ロン・ウィーズリー、ハーマイオニー・グレンジャーの三人はそれぞれが役割を分担してパスを繋ぎ賢者の石へと辿り着いていました。

Workflow Engine と呼ばれるようなものはようはそういう風にタスクで処理を独立させつつ順序に従って処理するための仕組みですね。

例えば YAML ベースの Digdag とか、 Python で記述する Luigi とか、Java や Python で Cloud Dataflow (Apache Beam) とか色々あります。

私は最近これを使ってログを分析して賢者の石に辿り着くためのデータ分析基盤の担当にアサインされたわけです。

これとは、

です。

お察しかと思いますが、担当しているデータ分析基盤は何と、 Workflow Engine が 3 つ使われて連結して出来ているのでした。

一体どうなるのでしょう。

... ＼(^o^)／

図にするのはめんどくさかったのですみません。

BigQuery にデータがたまる
GKE (GCP のコンテナサービス) 上の Digdag コンテナが定期的にタスクを実行する
1. タスク内では処理内容毎ステップが存在する
2. 各ステップは Python を実行する
3. Python は GKE に Luigi コンテナか Cloud Dataflow コンテナを起動する
Luigi コンテナ) Luigi を使った Python が実行される
1. 処理に必要な情報を取得する API などをコールする
2. BigQuery 上のデータにクエリを実行して処理結果を保存する
3. クエリがいくつか必要な処理は Apache Beam で更にワークフロー化してクエリ実行する
Cloud Dataflow コンテナ) shell script を介して Apache Beam を使った Java が実行される
1. BigQuery 上のデータにクエリを実行して処理結果を保存する
2. ものによっては shell script で完結してたりする

＼(^o^)／

(Workflow Engine とか関係なくコーディングとかで目に余る部分は割愛)

Workflow Engine 毎に思想が違うから緩衝材に使われてる Python の書き方が場所によって異なるのでコードを追いにくい
1. に至っては何故か Java が顔を出して来るので言語が変わって更に読みにくい
更に言うと 3. 4. で使う Cloud Dataflow は言語が別なので、 Cloud Dataflow は両方の書き方を覚える必要がある
上記の 2. 3. 4. は全て別のリポジトリで管理されてるので処理が追いにくい。本当に。
全てで Cloud Dataflow まで使うならまだしも、一部なので、 Cloud Dataflow の UI から見ても全てのデータの処理は可視化されない
Digdag コンテナの死に実行中タスクが影響されない仕組みだが、そもそもタスクを分割しきれてないため、タスク用コンテナ内で更に Workflow Engine が動く羽目になっている
Bigquery でクエリを実行してるだけなのにコード化することで複雑に見える
ソースの階層が深くなり過ぎていつまで経ってもSQLに辿り着かない

Digdag コンテナはバッチサーバーだったわけですが、これが落ちた時に何がスケジュール実行されなかったのか分かりにくかった
- CronJobs にしちゃえば落ちるのは特定の Job になる
どの処理にどれだけのリソースが消費されるのか分からなかった
- CronJobs にしちゃえばその単位でモニタリングされるので確保すべきリソースが分かる
常時起動しているサーバーを管理したくなかった

Yaml なのでコードよりシンプル
基本は BigQuery 上でのクエリ実行なのでコードにしなくても bq コマンド使っていれば十分
- Digdag の bq プラグインは bq コマンドと同等のことができないので個人的にはオススメしない