Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
A horror story of digdag
Search
show you
June 27, 2019
Programming
1
1.1k
A horror story of digdag
#DPCT vol3で発表した、digdag(とEmbulk)の話です。
show you
June 27, 2019
Tweet
Share
More Decks by show you
See All by show you
ラブライブ!向けのRDFを作ったよ!
showyou
0
55
AI真乃さんとLLMの発展
showyou
0
130
STEPの割り振りをStreamlit
showyou
0
220
k8s低価格で使う
showyou
0
260
Other Decks in Programming
See All in Programming
DynamoDBは怖くない!〜テーブル設計の勘所とテスト戦略〜
hyamazaki
0
180
リバースエンジニアリング新時代へ! GhidraとClaude DesktopをMCPで繋ぐ/findy202507
tkmru
7
1.7k
Dart 参戦!!静的型付き言語界の隠れた実力者
kno3a87
0
160
Amazon Q CLI開発で学んだAIコーディングツールの使い方
licux
3
170
構文解析器入門
ydah
7
2k
Claude Code派?Gemini CLI派? みんなで比較LT会!_20250716
junholee
1
800
AI Ramen Fight
yusukebe
0
120
商品比較サービス「マイベスト」における パーソナライズレコメンドの第一歩
ucchiii43
0
270
Git Sync を超える!OSS で実現する CDK Pull 型デプロイ / Deploying CDK with PipeCD in Pull-style
tkikuc
4
520
CEDEC 2025 『ゲームにおけるリアルタイム通信への QUIC導入事例の紹介』
segadevtech
2
740
はじめてのWeb API体験 ー 飲食店検索アプリを作ろうー
akinko_0915
0
180
[SRE NEXT] 複雑なシステムにおけるUser Journey SLOの導入
yakenji
1
910
Featured
See All Featured
Speed Design
sergeychernyshev
32
1.1k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.2k
Practical Orchestrator
shlominoach
190
11k
Faster Mobile Websites
deanohume
308
31k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Code Review Best Practice
trishagee
69
19k
RailsConf 2023
tenderlove
30
1.2k
Transcript
本当にあった、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 さんにお礼を申し 上げます
None
目次 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>:で一応制御することはできるが・・ <s>(WebUIで画面右を選択してretryかけて再実行すると、親も再実行かかる)</s> 以前のバージョンは画面右から飛べるページにRETRYボタンがあり、紛らわしかった RETRYを押すと、先行するjobが完了していても再実行された(RETRY FAILEDは再実 行しない)
None
None
None
None
依存関係を考慮する場合の書き方 ※議論の余地はあり
はまった点 - サブディレクトリの扱い 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書いたりしよう!