Posted at

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


TL;DR


  • 前任者が闇の魔法使いだったという話

  • Workflow Engine は混ぜるな危険

  • ポエムなのでコードとかない

  • 出てくる言葉については語らないのでいくらか前提知識が必要


Prologue

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

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

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

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

これ とは、


  • Digdag

  • Luigi

  • Cloud Dataflow (Apache Beam)

です。

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

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

... \(^o^)/


処理の流れ

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


  1. BigQuery にデータがたまる

  2. GKE (GCP のコンテナサービス) 上の Digdag コンテナが定期的にタスクを実行する


    1. タスク内では処理内容毎ステップが存在する

    2. 各ステップは Python を実行する

    3. Python は GKE に Luigi コンテナか Cloud Dataflow コンテナを起動する



  3. Luigi コンテナ) Luigi を使った Python が実行される


    1. 処理に必要な情報を取得する API などをコールする

    2. BigQuery 上のデータにクエリを実行して処理結果を保存する

    3. クエリがいくつか必要な処理は Apache Beam で更にワークフロー化してクエリ実行する



  4. Cloud Dataflow コンテナ) shell script を介して Apache Beam を使った Java が実行される


    1. BigQuery 上のデータにクエリを実行して処理結果を保存する

    2. ものによっては shell script で完結してたりする




読んだ時の感想

\(^o^)/


実際これで、何がオワッテたのか

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


  • Workflow Engine 毎に思想が違うから緩衝材に使われてる Python の書き方が場所によって異なるのでコードを追いにくい

  • 4. に至っては何故か Java が顔を出して来るので言語が変わって更に読みにくい

  • 更に言うと 3. 4. で使う Cloud Dataflow は言語が別なので、 Cloud Dataflow は両方の書き方を覚える必要がある

  • 上記の 2. 3. 4. は全て別のリポジトリで管理されてるので処理が追いにくい。本当に。

  • 全てで Cloud Dataflow まで使うならまだしも、一部なので、 Cloud Dataflow の UI から見ても全てのデータの処理は可視化されない

  • Digdag コンテナの死に実行中タスクが影響されない仕組みだが、そもそもタスクを分割しきれてないため、タスク用コンテナ内で更に Workflow Engine が動く羽目になっている

  • Bigquery でクエリを実行してるだけなのにコード化することで複雑に見える

  • ソースの階層が深くなり過ぎていつまで経ってもSQLに辿り着かない


どうしたか


  • Digdag コンテナを常時起動するのではなく、 CronJobs でスケジューリング

  • ワークフローは Digdag で完結させる

  • Python とか呼ばないで直接 bq コマンドを使う


CronJobs にした理由


  • Digdag コンテナはバッチサーバーだったわけですが、これが落ちた時に何がスケジュール実行されなかったのか分かりにくかった


    • CronJobs にしちゃえば落ちるのは特定の Job になる



  • どの処理にどれだけのリソースが消費されるのか分からなかった


    • CronJobs にしちゃえばその単位でモニタリングされるので確保すべきリソースが分かる



  • 常時起動しているサーバーを管理したくなかった


Digdag + bq コマンド にした理由


  • Yaml なのでコードよりシンプル

  • 基本は BigQuery 上でのクエリ実行なのでコードにしなくても bq コマンド使っていれば十分


    • Digdag の bq プラグインは bq コマンドと同等のことができないので個人的にはオススメしない




Epilogue


  • やってること、やりたいことに見合わない複雑さは要らない (ハリポタの賢者の石は適切に役割分担してると思います)