データパイプラインバッチ設計で私が考えること
© 2024 DATUM STUDIO Co. Ltd. データパイプラインの処理⽅法 データ処理にはバッチ処理とストリーミング処理の⼆つがある 源泉システム ストリーミング DWH Data Lake バッチ ü s3などにファイルを置いてもらう/ingestツールを使う ü 源泉システムの断⾯を保持するため扱いやすい ü Kafkaなどのメッセージングキューから連携 ü データの到着順が⼊れ替わることがあるので、ログ系のデータ向き ü バッチでのLoadが間に合わない場合にも採⽤される バッチ バッチ ストリーミング ü ⼀括ですべてのデータを処理 ü マシンパワーの強い近年のDWH製品と相性が良い ü viewやlambda viewによる実装 ü 分析に即時性が求められる場合に採⽤ される ü 複雑な処理設計が必要になる （個⼈的にはなるべく避けたい） （同左） ① ② ※ほんとは
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
Google Kubernetes Engine におけるバッチ処理のパターン
JapanContainerDays v18.04
【レポート】Workflow Engines Night #workflowenginesnight | DevelopersIO
DI部の川崎です。Digdag使ってます。 今日はDMM.comラボさんが開催された、ワークフローエンジンをテーマにした勉強会「Workflow Engines Night」に参加する機会がありましたので、Digdagの開発者古橋さんのセッションを中心に、参加レポートをお届けします。 勉強会のハッシュタグはこちら #workflowenginesnight はじめに 会場は、六本木一丁目のDMM.comラボさんのオフィスでした。勉強会の概要を引用します。 概要 今回はワークフローエンジンをテーマに勉強会を開催致します。 DMM.comラボからはビッグデータ部で『Digdag』を実際に導入・運用した話、 またインフラ本部からは『StackStorm』による運用コスト・リスク低減の取り組みについてお話しをさせていただきます。 なお、今回は『DigDag』の開発者である 古橋 貞之氏が帰国のタイ
Digdagへ日次バッチを移行して幸せになるお話
DMM.comラボではビッグデータ基盤の日次バッチ（ETL処理）のワークフローエンジンとしてDigdagを採用しました。 ワークフローの運用は、障害時のリカバリ、進捗状況に応じた他システム連携、JOB実行時間の局所化など様々な課題があります。 Digdag選定理由や設計の勘所（サーバ構成・ワークフローの設計方針）、Digdag Plugin実装、他チーム連携のためのClient実装など、課題解決のために取り組んだ内容について紹介させていただきました！
美しいバッチの壊し方 #cookpad_tech_kitchen - by shigemk2
青木峰郎 情報系(DWH)のSQLバッチ 大量のデータをひたすら集計(一個一個はそんなに重くない) ジョブ数が多くてフローが複雑 1000ジョブ DWH 13000くらいが多いけど、1000は少ない kuroko2 + bricolage http://techlife.cookpad.com/entry/2015/06/27/154407 SQLバッチ専用フレームワーク(OSS) 1ジョブ/1SQL文の強固な思想 よいバッチを作るために必要だから 良いバッチ=運用しやすい 落ちたときに如何に簡単に対処できるか 運用がしにくくなるようであるなら運用を優先したい 美しく壊れる 障害を直しやすい 美しい壊れ方とは どこで壊れたかすぐわかる 続きから実行できる リトライで直せる cf どこで壊れたか分からないプログラムは困る バッチはだいたい長時間実行しているし、処理が複数別れている 9割がた終
巨大なバッチを分割して構成する 〜SQLバッチフレームワークBricolage〜 - クックパッド開発者ブログ
トレンド調査ラボの青木峰郎（id:mineroaoki）です。 好きなRubyのメソッドは10年前からString#slice(re, nth)ですが、 最近はRubyよりCoffeeScriptとSQLのほうが書く量が多くて悩んでいます。 今日はわたしが開発している「たべみる」の背後で働いている 巨大バッチの構成について話したいと思います。 たべみるのバッチは約3000行のSQLで構成されており、 処理時間が1日で4時間程度かかる、そこそこの規模のプログラムです。 このバッチ処理プログラムをBricolage（ブリコラージュ）というフレームワークで構造化する手法について説明します。 「たべみる」とは まず最初に、「たべみる」がどういうものなのかごく簡単にお話ししておきましょう。 「たべみる」は企業のみに提供しているB2Bの分析サービスで、 クックパッドのレシピ検索の分析をすることができま
開発に役立つ，BATファイルの書き方・パターン集 （コマンドプロンプトの定石を体系的に学び，バッチ中級者になろう） - 主に言語とシステム開発に関して
バッチのまとめTOPへ Windows上の処理を自動化するプログラムが，BATファイルである。 「コマンドプロンプト」上での手作業を省略し，自動実行できる。 Windowsが存続する限り，BATファイルはなくならないだろう。 バッチ・プログラミングの需要は，何があろうとこの先生きのこる。 このWindows 10の時代でもそうだ。 BATは，MS-DOSの時代から長く使われてきた。 そのため，各コマンドに関する個別のノウハウや情報は多い。 だが，実用的なノウハウを体系的に整理したものは，あまり見かけない。 そこで以下では，BATをコーディングする際の良質なパターンを列挙する。 （０） BATプログラミングの特徴 （１） BATファイルの雛型 （１−１） 冒頭と末尾のテンプレート （１−２） 反復して実行可能に （２） バッチの構造化 （２−１） ルーチンの分割 （２−２） 実行ファイルや実
改行コード LF で日本語を含むバッチファイルの動作がおかしい件 - miauのブログ
ブログ書いている場合ではないんですけど、Hudson を触ってて結構ハマったので、さらっと現象＆推測を書いておきます。 きっかけ Hudson の「Windowsバッチコマンドの実行」で、 :（略） set TL_BACKUP_DIR=E:\TracLightBackup\%date:~0,4%%date:~5,2%%date:~8,2%-%time:~0,2%%time:~3,2%%time:~6,5% @echo "古いバックアップファイルを削除します。" cd /d E:\TracLightBackup :（略）みたいなジョブを登録していたんだけど、なぜか実行に失敗する。 コンソール出力を見ると、 C:\TracLight\projects\hudson\.hudson\jobs\TracBackup\workspace>E:\TracLightBackup\20100929-175
バッチメモ(Hishidama's bat-file Memo)
実行方法 引数の注意点 [2013-03-05] 定石 書き方 @echo off 別バッチの実行方法 [2007-03-07] タイトル変更方法 [2009-11-14] バッチの場所取得 [2009-11-14] 変数 バッチの戻り値 注意点 [/2007-06-15] 標準入力 [2007-10-26] 実行方法 バッチファイルの拡張子をbatにしておく。 このファイルがある場所を環境変数PATHに追加しておくか、ファイルのある場所まで移動して、 コマンドラインからファイル名を入力するか、拡張子を除いた部分を入力することによって バッチを実行する。 またはフルパスでファイル名を入力する。 ディレクトリやファイル名にスペースが入っている場合は、全体をダブルクォーテーションでくくらないと、スペースの所で区切られてしまう。（コマンド用のファイル名にスペースを入れることはあまり無いだろうが…
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
綱渡りバッチ脱出大作戦
Cookpad TechKitchen #8: Breaking BatchJobs Beautifully