はじめに
はじめましてイタンジ株式会社の藤井と申します、更新退去くんという管理会社向けのSaaSを開発しています。
先日開催されたトレジャーデータさま主催のテックトーク非常に楽しく拝見させていただきました。CDPというアプリケーションがどのように構築されているのか、非常に興味深かったです。
上記セッションの場でdigdagでerbやhttp_callオペレーターを用いた動的ワークフローを扱う手法の紹介がありましたが、私も過去Rubyのlanguage APIを用いた別の手段で動的ワークフローを利用したことがあるので、この場を借りて紹介させていただきます。
digdag × Rubyによる動的ワークフロー
まずdigdagとRubyの接着面のコードを読んでみましょう、#add_subtask
というメソッドに着目してみてください。
digdag/runner.rb at 42ea7cb71270957ea6424c2df88dd7c65d248789 · treasure-data/digdag · GitHub
ドキュメントではRubyからタスクを動的生成する際に #add_subtask
メソッドにクラス名とインスタンスメソッド名を渡す手法が紹介されています
が、該当メソッド#add_subtask
の上部にコメントされている通り実際はそれ以外にもハッシュを渡す方法やシングルトンメソッド名を渡す手法もあることが分かります。
# add_subtask(params) # add_subtask(singleton_method_name, params={}) # add_subtask(klass, instance_method_name, params={})
また該当コードを読み進めていくと、クラス名やメソッド名を渡す方法は実際はdigdagの rb>
オペレーターを用いたkey-valueによるdigdag固有のワークフローを表現していることが分かります。
つまり結論、#add_subtask
にはdigdag固有のkey-valueによるワークフロー表記をそのまま詰め込むことが出来、それがタスク実行時に評価されるのです。この性質を利用して色々試した内容を下記github gistにまとめてありますので、お時間ある人は試してみてください。
Dag for debug with digdag · GitHub
おわりに
今回紹介した手法は、digdag本体のリポジトリにあるサンプルコードにコミットさせていただいたので、こちらも併せてご確認ください。
私事ですがdigdagは素晴らしいツールだと思っており、専用のgemを作ってしまう程に愛用しております。
テックトークの場でembulkのメンテナンス体制がオープンになるというアナウンスがありましたが、digdagにも同様の議論がある事を風の噂で伺っております。 メンテナンス体制がオープンになった際には、私も積極的にdigdagの発展に貢献しようと考えております。
embulkと同じ議論をdigdagでも始めています。こんがらかってしまったコミュニケーションを解きほぐすまでしばらくお時間をください。
— Hiroshi Nakamura (@nahi) November 29, 2022