Workflow構築時に変数化すべきポイントはどこか

データマネジメントチームの冨田 恭平です。

今回はWorkflowを構築する際に変数化しておくことで実装が楽になる、運用負荷が軽減されるポイントをご紹介いたします。

そもそもWorkflowの変数について簡単に説明すると、digdagがデフォルトで用意している「session_time（セッション開始日時）」や _export: の中でユーザーが定義した項目を ${…} という形式で記述することで、処理が実行された際に値を代入してくれるものです。
参考URL：https://docs.digdag.io/workflow_definition.html#using-variables

例えば、このようなコードを書いた上で実行すると、

_export:
  td:
    database: sandbox_td
  env: dev

+check_database:
  echo>: "データベース名は ${td.database} です"

+check_env:
  echo>: "環境は ${env} です"

以下のように ${…} の部分が _export: で設定した値に変換されて出力されます。

2021-02-18 06:42:47.025 +0000 [INFO] 
(0147@[5891:tomi_test]+tomi_test+check_database) 
io.digdag.core.agent.OperatorManager: echo>: データベース名は sandbox_td です
データベース名は sandbox_td です
2021-02-18 06:42:47.200 +0000 [INFO] 
(0399@[5891:tomi_test]+tomi_test+check_env) 
io.digdag.core.agent.OperatorManager: echo>: 環境は dev です
環境は dev です

この ${…} の中ではjavascriptの関数が使えるので、タイムスタンプの操作を行ったり、文字列操作を行ったりと色々できるのですが、本題から逸れてしまうのでまた別の機会に紹介いたします。

さて、今回のテーマである「変数化すべきポイントはどこか」ですが結論から言うと、

1. 構築/運用中に切り替える頻度または可能性が高いフラグ系の項目
2. 複数テーブルに対して同じ処理を切り替える際のテーブル名
3. 同一プロジェクト内の別WFで共通の値を設定する必要がある項目

の3点だと考えております。ケースバイケースではあるのですが、これらの項目は変数化しておいて困ったことはなく、便利だったことが多かったです。

1.構築/運用中に切り替える頻度または可能性が高いフラグ系の項目

以下のような実装の形が一例となります。
呼び出すSQLファイルをIF分岐で処理していますが、他のタスクなどでも利用する場合にはこうした形で全体の切替ができるよう設計しておくと便利です。

_export:
  td:
    database: sandbox_td
  # 日次処理かどうか。初回は全件処理、日次は差分処理などのケースに利用
  is_daily: true
  
+get_rawdata:
  if>: ${is_daily}
  _do:
    td>: queries/step0_get_rawdata_daily.sql
  _else_do:
    td>: queries/step0_get_rawdata_all.sql

2.複数テーブルに対して同じ処理を切り替える際のテーブル名

for_each オペレータと組み合わせて、テーブルの数だけSQLを記載しなくても、テーブルのリストに対して処理を行えるよう実装できます。

_export:
  td:
    database: sandbox_td
  table_list:
    - table_a
    - table_b
    - table_c

+get_yesterday_data_pattern_1:
  for_each>:
    target_table: ${table_list}
  _do:
    td>:
    query: |
      select
        *
      from
        '${target_table}'
      where
        td_interval(time, '-1d', 'jst')

3.同一プロジェクト内の別WFで共通の値を設定する必要がある項目

エラー時に通知を行いたいSlackのチャネル設定や1、2の変数をWorkflowまたぎで使用したい場合などに、別ファイルで切り出し !include を用いることで反映するやり方です。
variable_test.dig

_export:
  !include : config/env_variables.dig
  td:
    database: sandbox_td
    
+task_1:
  echo>: 'task_1'
    
+task_2:
  echo>: 'task_2'

config/env_variables.dig

# エラー発生時の通知先
slack_ch: "#alert-xxx"

# 日次処理かどうか
is_daily: true

# 処理対象テーブル
table_list:
  - table_a
  - table_b
  - table_c

以上、簡単なご紹介ではありますが、Workflowを構築する際は変数化しておくことを意識してみていただけるとより運用しやすい形で構築できるかと思います。少しでも使えそうと感じていただけたら是非試してみてください。

WorkflowのエラーをSlack通知させる方法

2021年7月14日