本当にあった、Digdag(と Embulk)の怖い話 Data Pipeline Casual Talk vol.3 2019/06/28 id:@showyou 

自己紹介 id: showyou(twitter, hatena, github) Freelance engineer (ex-EMC(Pivotal), ex-DeNA, …) Hadoop, Bigdata, Python BigQuery, Digdag, Embulk 

注意事項 本件は私の技術力不足が招いた部分もあり、Digdag及びEmbulkを非難するものでは ございません 大体どのツールを使っていても、この様な事態に遭遇することはあるので、その時の対 処法と見てもらえれば幸いです 今日の参考資料：https://github.com/showyou/dpct_digdag また一連の問題に対し、きめ細かく応対いただきました @hiroysato さんにお礼を申し 上げます 

No content

目次 Digdagとは Embulkとは はまった点 

Digdagとは https://www.digdag.io TreasureDataが作成した、ジョブ実行エンジン yamlでジョブを記述 Web UIで進捗確認、retry可能 Slackなどに通知可能 HA構成可能 

Digdagの Slack通知 画像はhttps://dev.classmethod.jp/treasuredata/slack-notification-on-digdag/ 

Embulkとは https://www.embulk.org TreasureDataが作成した、バッチデータ転送ツール json, csvファイルを手軽にBigQuery, RDBに投入できる(逆も 当然可) yamlで設定記述 

システム構成の例 画像は https://www.m3tech.blog/entry/m3usa-development-data-platform 

はまった点 

はまった点 - 親子間のjobの依存関係 Digdagではjob毎に複雑な依存を書いて、DAGを制御することが不可能 トップダウンでjobを書く必要がある (<=>jenkinsではプラグインを使うことで、job毎に親子関係や並列処理をかけることが 可能だったはず) 親 子 

はまった点 require>:で一応制御することはできるが・・ (WebUIで画面右を選択してretryかけて再実行すると、親も再実行かかる) 以前のバージョンは画面右から飛べるページにRETRYボタンがあり、紛らわしかった RETRYを押すと、先行するjobが完了していても再実行された(RETRY FAILEDは再実 行しない) 

No content

No content

No content

No content

依存関係を考慮する場合の書き方 ※議論の余地はあり 

はまった点 - サブディレクトリの扱い Digdagはサーバにjobを投入する際、対象のディレクトリ以下のファイル(.で始まるもの を除く)を全て圧縮してコピーする 親ディレクトリを見に行くことができない - shared/ env.dig - query1/ calc_hoge.dig ↑shared/env.digを見に行くことができない - query2/ calc_foo.dig 対処方法：親ディレクトリに対してシンボリックリンクを張る https://www.m3tech.blog/entry/m3usa-development-data-platform 

はまった点 - サブディレクトリの呼び出し サブディレクトリで実行しているdigファイルを、親のディレクトリから呼ぶと失敗するケー スがある。サブディレクトリに設定ファイルが書かれている場合など 要はシェルスクリプトでいう所のcd sub && run.shというのができない 対処方法：　全digファイルをTopのディレクトリに設置 もっとうまい方法が山ほどある気がする 

はまった点 - 実行ディレクトリ (サーバモードだけ)step毎に実行するディレクトリが変わる - +step1: sh>: echo “hoge” > foo.txt +step2: sh>: cat foo.txt ローカルモード：hogeが出力 サーバモード：ファイルが無いとエラーになる 

はまった点 - 実行ディレクトリ 冪等性、並列実行などを考慮してstep毎に分けていると考えられるが、 ローカルのファイルを使用する処理が実行不能 対処方法： 1. /tmp/以下など固定のパスを指定する。 ただしsh>:オペレータ以外では使用不可、更にHA構成で分散して実行した場合当 然エラー 2. s3, GCSやRDBなどをファイル格納先に指定する 

はまった点 - Embulk (客先の環境だけ)Embulkがjarファイルを呼べずに起動できないことが、頻発する https://github.com/embulk/embulk/issues/1148 対処方法：Digdagのretry機能を使うことで、起動できなかったときに再実行 

はまった点 - Digdagのretry機能 retry機能　sh>:オペレータでは機能せず 対策　1段stepを挟むことでretry可能になる +step1: _retry: +setup: sh>: +run: sh>: +teardown: sh>: 

はまった点 - 日付の範囲指定 Digdag Serverに登録していないjobを、直に開始日と終了日を指定して実行することが できない 　シェルで日付をカウントする機構を作る必要がある 　Serverに登録しているならdigdag backfillで開始日は指定できるが、終了日は指定で きない(日数は指定できる) loop>: ${moment(end_date).diff(moment(start_date), 'day')}みたいなもの書けば いけるか？ Airflowなら開始日終了日指定できる 

Digdagあるある話 ファイルを取得、DBに格納するジョブ DB格納時に失敗 あとで、「最新のファイルをDBに格納」しようとdigdag runを実行 ↓ 過去のデータがDBに格納(成功したステップの実行までskipされるため) 対策： digdag run --rerunもしくはdigdag run --sessionを使う 

その他 Retry failed(失敗したところから再実行)が実行できない環境がある - 調査中 -> PR出ました https://github.com/treasure-data/digdag/pull/1163 どうも同名のstepがあるときにRetry failedできなくなることがある模様 (3ページ前のsetup, run, teardownが該当し得る) そもそもWeb UIから個別のステップの再実行できたっけ・・？ そもそもWeb UIに認証がかけられない 

Digdagのメリット yamlで設定を書けるため、言語非依存の設定が作成可能(Airflow, LuigiはPython) スクリプトを使ってジョブ設定の自動生成がしやすい 作成したyamlはgitでバージョン管理が可能(Jenkinsは管理が大変) ドキュメントは英語だが、日本人にはフレンドリー 

まとめ 恐らくどのツール(Jenkins, Luigi, Airflow, Digdag…) を使うにせよ、なんらかしら辛み はある Oozie, Azkabanはどこ行った・・ メリット/デメリットを把握できる環境が必要(複数のツール使いこなすのは大変) ベンダーでもないのに手放しで一つのツールを絶賛してるblogは危険 何かあったら公式でissue立てたりblog書いたりしよう！