2019の24日目です。operatorを使った開発の際に気をつけることを書いて行こうと思います。WorkflowとありますがOSSのdigdagでも活かせる内容があると思います。一通り試すことが出来ます。Workflowやdigdagのサーバーモードでは、タスク間の中間ファイルを置くためのストレージがないため、一つ一つのタスクの粒度が大きくなりがちです。Workflowでは一つ一つのtaskでコンテナが起動するため、そのオーバーヘッドを無視できません。一方で、一つの巨大なタスクは、開発時のデバッグを難しくさせます。そこで、開発時の戦略としては一つ一つは最低限の塊に分けた関数を用意します。必要に応じてそれらを束ねる関数を用意するのが良いでしょう。Workflow向けのworkflowをローカル環境で開発するにはいくつかの選択肢があります。Dataが提供している公式イメージを利用すると、本番環境と同じイメージが使うことができるので良いでしょう。その際には、他のPythonスクリプトの開発と同様に、切り分けた単体で実行できるようにして開発するのが良いでしょう。imageは以下の2つです。debuggerがアタッチできるので便利です。詳しくはPyCharmのドキュメントをご参照ください。呼ばれるモジュールがあります。これを使うことで他のプロジェクトと分離したパッケージの環境を作ることができます。digdag-python:3.7digdag-python:3.7と同様の環境を作るには、次のgistからrequirements.txtとconstraints.txtをダウンロードします。https://gist.github.com/chezou/d0a0fc62007af4d808752e78b31ae694その後、以下のようにコマンドを実行することでDockerイメージと同様のPython環境が構築できます。constraints.txtこの方法では、OSによる差異まで吸収ができない場合があります。使いますが、それをスクリプト内に書いても実行ができません。digdag-anaconda3:2019.03anacondaイメージと同じ環境を作りたい場合は、gistからenvironment.ymlをダウンロードします。https://gist.github.com/chezou/d0a0fc62007af4d808752e78b31ae694#file-environment-ymlその後、以下のコマンドを実行するとデフォルトの環境に依存するパッケージをインストールします。好きな名前に変更した後、以下のコマンドで新規仮想環境を作成してください。本番環境に近いdigdag環境が用意できます。Dataではv0_10を使っていますが、将来これは変わる恐れがあります。operatorにパラメータを渡すには2つの方法があります。いうスクリプトがあるとします。いう関数に渡す場合、以下のようなdigdagのtaskになります。"digdag/digdag-python:3.7"もし、複数の引数をPythonの関数へ渡したい場合、digdagの引数を増やせばよいでしょう。ここで注意してほしいのが、digdagの変数はPythonにシームレスに渡されるということです。引数を受け取る場合、意図しないdigdagの変数がPythonに渡る可能性に注意してください。いう辞書型の変数が代入されています。受けるのではなく、明示的な引数の指定を強くおすすめします。operatorの引数の衝突が起こる場合があります。以下のようなワークフローがあったとします。"digdag/digdag-python:3.7"このとき、Pythonのスクリプトは以下のような関数を持っているとします。いう辞書が格納されてしまいます。型(dict)が期待されていたもの(str)との不一致が起こりうるのです。このようなミスマッチを避けるために、digdagで予約されている変数やよく利用される変数を避けたほうが良いでしょう。いう変数や以下の変数は避けたほうが良いです。td.endpointtd.apikeytd.use_ssltd.proxy.enabledtd.proxy.hosttd.proxy.porttd.proxy.passwordtd.proxy.userこれらの既に利用されている変数は将来的に変更される可能性があります。digdagの組み込み変数は次のドキュメントをご参照ください。意図しない型の変換を行う場合があります。そのため、型のチェックや明示的な変換をおすすめします。operatorに変数を渡すためのもう一つの方法です。keyなどセキュアな情報はこの形式でやりとりすることが多いです。いうタスクがあったとします。以下のようにPythonから取得できます。格納するデータベースを提供しています。いう形式でworkflowに書き、環境変数経由でPythonにわたす環境変数での受け渡しをしないとsecretsはPythonに渡されません。いう情報が渡されます。executionしかし、以下のようにdigdagの引数として渡した場合はsecretsが評価されません。print(apikey)secretsに関する詳細は、digdagのドキュメントをご参照ください。することでdigdagモジュールを利用することが出来ます。呼ばれる変数に辞書のようにアクセスすることでdigdagの変数を直接読むことが出来ます。print(digdag.env.params["my_msg"])このとき、実行するworkflowは例えば以下のようなものになります。"digdag/digdag-python:3.7"なお、読み込みだけではなくdigdag.env.storeを使うことでdigdagの変数の書き込みもできます。大きな変数の受け渡しはしないほうが良いでしょう。operator実行時に動的に生成しているため、ローカルでは実行できないことに注意してください。利用するのが良いでしょう。subprocess.runを使い実行します。"pytd"])OSのパッケージのインストールの場合も同様です。一つのプロジェクトでは、以下のようなディレクトリ構成をおすすめしています。testこの構成に従ったdigdagプロジェクトをcookiecutter-digdagを使うことで簡単にテンプレートから生成できます。https://github.com/chezou/cookiecutter-digdag実行時のエラーを通知するPythonのスクリプト実行時に発生したエラーをSlackなどで通知したい事があると思います。workflowが失敗した際の処理をできますが、そのとき${error.message}の中にPythonの例外情報が入っています。scriptがあったとします。ValueErrorこのとき、以下のようなログが得られます。operatorでエラーを出力しているだけですが、Slack等に例外を送ることで定期実行しているPythonタスクの通知が簡単に行なえます。Workflowの開発をしやすくなるかと思います。digdagでもいくらかのポイントは使うことができるかと思います。