digdagを使っててハマった事メモ

S3にあるファイルを加工したり中間結果のファイルを保存したりTreasureDataに格納するような処理を書いていったときに発生したエラーメモ。

digdag version 0.9.24 github.com

サーバーモードでdownload_fileオプションが使えない

プロジェクトディレクトリ内にダウンロードしたはずのファイルが次のタスクで消え去った
ファイルに保存せずにスクリプトを書いてDigdag.envを使ってクエリ結果を変数に保持させて対応
別の方法も（参考 digdagのtd>のdownload_file）

プロジェクト外のディレクトリを参照できない

SQLファイル動的に生成してtdオペレータに渡すようなタスクを作った
生成したファイルをプロジェクトディレクトリに保存するようにしたが次のタスクでNo such file or directoryになり参照できず（ローカルモードでは成功するがサーバーモードでは失敗）
プロジェクトディレクトリがダメなら/var/tmp/等に置けばいいと思ってこんな感じtd>: /var/tmp/???.sql で試したがダメだった
ファイルに保存せずにSELECT * FROM hoge WHERE id=${id}みたいなテンプレートファイルを作り、スクリプトでDigdag.envを使って変数を設定して対応
（shオペレータはプロジェクト外のファイルもいけた。sh>: echo /var/tmp/hoge 等）

dockerでプロジェクト外のディレクトリも参照できなかった

ruby環境をサーバーに構築するのがだるかったのでdockerを使ってみた
/var/tmpに保存したファイルも消え去った
諦めた

サーバー複数台で実行したらファイルが参照できない

複数のサーバーで動作させたときに各サーバーがタスクをいい感じに取っていった
中間結果のファイルがサーバーに無いため参照できなかった（そりゃそうか）
処理順序を勘違いしていた（下記のコードの場合、number 1の処理step_a,b,cは同じサーバー上で実行すると勘違い）
goofysでS3をマウントして対応

# test.dig
+sample:
  for_each>:
    number: [1,2,3]

  _parallel: true

  _do:
    +step_a:
      echo>: a_${number}

    +step_b:
      echo>: b_${number}

    +step_c:
      echo>: c_${number}

$ digdag run test.dig --rerun
...
2018-05-18 20:26:03 +0900 [INFO] (0018@[0:default]+test+sample): for_each>: {number=[1, 2, 3]}
2018-05-18 20:26:03 +0900 [INFO] (0018@[0:default]+test+sample^sub+for-0=number=0=1+step_a): echo>: a_1
2018-05-18 20:26:03 +0900 [INFO] (0019@[0:default]+test+sample^sub+for-0=number=1=2+step_a): echo>: a_2
2018-05-18 20:26:03 +0900 [INFO] (0020@[0:default]+test+sample^sub+for-0=number=2=3+step_a): echo>: a_3
a_3
a_2
a_1
2018-05-18 20:26:04 +0900 [INFO] (0019@[0:default]+test+sample^sub+for-0=number=0=1+step_b): echo>: b_1
2018-05-18 20:26:04 +0900 [INFO] (0020@[0:default]+test+sample^sub+for-0=number=2=3+step_b): echo>: b_3
2018-05-18 20:26:04 +0900 [INFO] (0018@[0:default]+test+sample^sub+for-0=number=1=2+step_b): echo>: b_2
b_1
b_2
b_3
2018-05-18 20:26:04 +0900 [INFO] (0020@[0:default]+test+sample^sub+for-0=number=2=3+step_c): echo>: c_3
2018-05-18 20:26:04 +0900 [INFO] (0018@[0:default]+test+sample^sub+for-0=number=1=2+step_c): echo>: c_2
2018-05-18 20:26:04 +0900 [INFO] (0019@[0:default]+test+sample^sub+for-0=number=0=1+step_c): echo>: c_1
c_1
c_3
c_2

shオペレータでargument too long

調子に乗ってDigdag.envを使いまくっていたらshオペレータを使ったときにこれが発生
Digdag.envはシステムの環境変数らしい？（参考 Output 'java.io.IOException: Argument list too long' using by sh operator. · Issue #768 · treasure-data/digdag · GitHub）
なるべくDigdag.envにデータを持たせないようにした

for_eachオペレータを使っていたらファイル名が長すぎますエラー

for_eachの対象にかなり長い日本語名が入ったリストを指定していた
digdag側でワークスペースの名前に含めてディレクトリ作ってるからか、ファイル名が長すぎますというエラーが出た
for_eachに渡していたリストの内容をなんとか短縮して対応
既にPRが出ていたのでマージされることを祈った

タスクに異様に時間がかかる

どんな状況だったか忘れたがシンプルな処理にも異様に時間がかかるようになっていた
色々試した結果Digdag.envで持たせていたデータを減らしたら軽くなった
なぜか直ったので放置

タスクを増やしたら処理途中で必ず失敗

UIを見ると画面上エラーになるが_errorに引っかからない
OOMEでもない
traceまでログを出すようにしたら"too many tasks"と書いてあった
-X io.digdag.limits.maxWorkflowTasks=100000 をコマンドに追記して上限を増やした
参考1 [Q] How can I define max-task-threads in a task with "_parallel: true" parameter? · Issue #710 · treasure-data/digdag · GitHub
参考2 Increasing default value of active task limit · Issue #508 · treasure-data/digdag · GitHub

2018-04-27 04:41:10 +0000 [TRACE]
...
io.digdag.core.workflow.WorkflowExecutor: Task failed with error {"message":"Too many tasks. Limit: 1000, Current: 999, Adding: 4 (task limit exceeded)"