FLINTERS Engineer's Blog

FLINTERSのエンジニアによる技術ブログ

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

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

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

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

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

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

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)"

終わり

  • 色々ハマりましたが本来の用途と異なる使い方をしたのかなと思います
  • digdagは色々なオペレータが用意されていたり、記述がシンプルなのでさくっと書けて便利です
  • ローカルモードとサーバーモードとで挙動が少し違う部分があるため、早めに本番に近い環境で開発を進めるのがいいのかなと思いました