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
AI真乃さんとLLMの発展
showyou
0
93
STEPの割り振りをStreamlit
showyou
0
210
k8s低価格で使う
showyou
0
260
Other Decks in Programming
See All in Programming
コードを読んで理解するko build
bells17
1
110
Rails 1.0 のコードで学ぶ find_by* と method_missing の仕組み / Learn how find_by_* and method_missing work in Rails 1.0 code
maimux2x
1
250
PRレビューのお供にDanger
stoticdev
1
240
ナレッジイネイブリングにAIを活用してみる ゆるSRE勉強会 #9
nealle
0
160
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
160
推しメソッドsource_locationのしくみを探る - はじめてRubyのコードを読んでみた
nobu09
2
340
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
8
1.5k
CSS Linter による Baseline サポートの仕組み
ryo_manba
1
160
もう僕は OpenAPI を書きたくない
sgash708
6
1.9k
How mixi2 Uses TiDB for SNS Scalability and Performance
kanmo
41
16k
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
950
Kotlinの開発でも AIをいい感じに使いたい / Making the Most of AI in Kotlin Development
kohii00
5
1.4k
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.4k
Designing Experiences People Love
moore
140
23k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
Embracing the Ebb and Flow
colly
84
4.6k
Thoughts on Productivity
jonyablonski
69
4.5k
Code Review Best Practice
trishagee
67
18k
The Cult of Friendly URLs
andyhume
78
6.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
520
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書いたりしよう!