Slide 1

Slide 1 text

データパイプライン バッチ設計で私が考えること DATUM STUDIO株式会社 向井 雄⼆

Slide 2

Slide 2 text

© 2024 DATUM STUDIO Co. Ltd. はじめに

Slide 3

Slide 3 text

© 2024 DATUM STUDIO Co. Ltd. データパイプラインの処理⽅法 データ処理にはバッチ処理とストリーミング処理の⼆つがある 源泉システム ストリーミング DWH Data Lake バッチ ü s3などにファイルを置いてもらう/ingestツールを使う ü 源泉システムの断⾯を保持するため扱いやすい ü Kafkaなどのメッセージングキューから連携 ü データの到着順が⼊れ替わることがあるので、ログ系のデータ向き ü バッチでのLoadが間に合わない場合にも採⽤される バッチ バッチ ストリーミング ü ⼀括ですべてのデータを処理 ü マシンパワーの強い近年のDWH製品と相性が良い ü viewやlambda viewによる実装 ü 分析に即時性が求められる場合に採⽤ される ü 複雑な処理設計が必要になる (個⼈的にはなるべく避けたい) (同左) ① ② ※ほんとはもっと⾊々あるけど本筋ではないので割愛 ①Extract/Load (データ抽出/取り込み) ②Transform (データ変換)

Slide 4

Slide 4 text

© 2024 DATUM STUDIO Co. Ltd. データパイプラインの処理⽅法 データ処理にはバッチ処理とストリーミング処理の⼆つがある 源泉システム ①Extract/Load (データ抽出/取り込み) ストリーミング DWH Data Lake ②Transform (データ変換) バッチ ü s3などにファイルを置いてもらう/ingestツールを使う ü 源泉システムの断⾯を保持するため扱いやすい ü Kafkaなどのメッセージングキューから連携 ü データの到着順が⼊れ替わることがあるので、ログ系のデータ向き ü バッチでのLoadが間に合わない場合にも採⽤される バッチ バッチ ストリーミング ü ⼀括ですべてのデータを処理 ü マシンパワーの強い近年のDWH製品と相性が良い ü viewやlambda viewによる実装 ü 分析に即時性が求められる場合に採⽤ される ü 複雑な処理設計が必要になる (個⼈的にはなるべく避けたい) (同左) ① ② 今⽇の話題

Slide 5

Slide 5 text

© 2024 DATUM STUDIO Co. Ltd. バッチ処理設計での考慮事項 ⼤きく分けて⼀つずつのジョブ設計、ジョブ同⼠の依存関係を定義するワークフロー設計が必要 システムB データ抽出 (スコープ外) 共通 データ変換&テスト システムA データ抽出 システムA データ取り込み システムA データ鮮度チェック 外部連携 システムB データ取り込み システムB データ鮮度チェック 定時起動 システムA データ変換 システムB データ変換 バッチ処理設計例 ジョブ設計:各ジョブの詳細な処理を定義 ワークフロー設計:ジョブ同⼠の依存関係を定義

Slide 6

Slide 6 text

© 2024 DATUM STUDIO Co. Ltd. ワークフロー設計の考慮事項

Slide 7

Slide 7 text

© 2024 DATUM STUDIO Co. Ltd. 複数システム連携時の依存関係の設計 依存関係は増やすほどパイプラインの稼働率低下につながる。ビジネス要件とSLAを考慮して、本当に重要な ジョブにのみ厳格な依存関係を設定するのが吉 システムA データ抽出 システムB データ抽出 システムC データ抽出 システムD データ抽出 システムE データ抽出 共通(システム横断) データ変換 ❌ Bad 全システム処理の 正常終了を確認 システムDに障害発⽣︕ →関係のないパイプラインも⽌まってしまう... システムA データ抽出 システムB データ抽出 システムC データ抽出 システムD データ抽出 システムE データ抽出 共通(システム横断) データ変換 ⭕ Good 1つ以上のシステム処理 正常終了を確認 システムDに関係のないパイプラインは⽌めない →コスト⾯などで問題がなければ終了ステータスに関係なく 後続処理を継続するのが簡単

Slide 8

Slide 8 text

© 2024 DATUM STUDIO Co. Ltd. ELTにおける依存関係の設計パターン 原則Load(データ取り込み)からTransform(データ変換)は前⾴のような、システムを横断した⼀括で の処理となるように依存関係を設定することが推奨 システムA データ抽出 システムA データ取り込み 共通(システム横断) データ変換 1つ以上の取り込み処理 正常終了を確認 システムA データ取り込み 共通(システム横断) データ変換 1つ以上の取り込み処理 正常終了を確認 共通(システム横断) データ変換 ①EL+T(システム横断で⼀括処理) ü APIを叩く場合や、Fivetranなどのingest toolを使う場合 ü 基本的な設計⽅針 ②L+T(システム横断で⼀括処理) ü S3にファイルを置いてもらう場合など ü データ抽出が失敗した際の取り決めが必要 ③システムごとにELTを実⾏する ü 各システムのデータ取り込みが終了後、都度変換を実⾏ ü 即時にデータ変換することが求められるユースケース以外では不要 →共通ジョブが重複実⾏される可能性があるため システムA データ抽出 (スコープ外) システムB データ抽出 システムB データ取り込み システムA データ抽出 システムA データ取り込み システムB データ抽出 システムB データ取り込み システムB データ取り込み システムB データ抽出 (スコープ外) 各取り込み処理が 正常終了するたびに都度実⾏

Slide 9

Slide 9 text

© 2024 DATUM STUDIO Co. Ltd. テストの実⾏について 変換処理後のテストは即時実⾏と、すべての処理終了後に実⾏の2パターンがある。利⽤⽤途やSLAを考慮 してシステムに合った⽅式を選択すること 中間層 データ変換 共通 データ変換&テスト 中間層 テスト マート層 テスト … マート層 データ変換 外部連携 中間層 データ変換 共通 データ変換&テスト 中間層 テスト マート層 テスト … マート層 データ変換 外部連携 … ①各層ごとに変換後即時テストを⾏う ü データ品質を重視するパターン ü テストが失敗すると後続の変換処理がすべて停⽌する ü テスト失敗に関係のないデータのみを更新するのはかなり難しい (ワークフローの複雑化につながる) ②すべての変換が終了後にテストを⾏う ü データの鮮度やシステム全体のSLAを重視するパターン ü 不正確なデータが提供されているため、利⽤者への迅速な通知が必要 ü 場合によっては特定テーブルの切り戻し処理を⾏ったりもする

Slide 10

Slide 10 text

© 2024 DATUM STUDIO Co. Ltd. ジョブ設計の考慮事項

Slide 11

Slide 11 text

© 2024 DATUM STUDIO Co. Ltd. ジョブ設計の考慮事項①: 再現性 データの順序が⼊れ替わったり、再取り込みを⾏う際に容易に再処理を⾏えるような設計が必須。Stateless な処理とStatefulな処理を意識して設計しておくのがよい 注⽂ID 顧客ID 作成⽇ データ到着⽇ aaa xxx 2024-01-01 2024-01-01 bbb yyy 2024-01-02 2024-01-05 ccc zzz 2024-01-03 2024-01-03 キャンセルID 注⽂ID 作成⽇ データ到着⽇ 1 bbb 2024-01-04 2024-01-04 受注キャンセルテーブル 受注テーブル 受注レコードが遅れて到着 受注がないのにキャンセル...︖ Statelessな処理例: 受注ファクトテーブルの作成 Statefulな処理例: 受注キャンセルファクトの作成 注⽂ID 顧客ID 受注⽇ aaa xxx 2024-01-01 bbb yyy 2024-01-02 ccc zzz 2024-01-03 キャンセルID 注⽂ID 顧客ID 受注⽇ キャンセル⽇ 1 bbb yyy 2024-01- 02 2024-01- 04 単純にレコードを追加すればOK 受注テーブルから得られる情報を NULLからupdate データ変換処理 変 換 前 $ % & 変 換 後 $ % &

Slide 12

Slide 12 text

© 2024 DATUM STUDIO Co. Ltd. ジョブ設計の考慮事項②: 冪等性 複数システムと接続するとデータの再集計が頻発する。何度実⾏しても副作⽤が発⽣せず同じデータが連携さ れるように処理を設計すること ❌ Bad ⭕ Good ID aaa bbb ccc ddd eee ID aaa bbb ccc ddd eee 新しく到着したレコードにいい感じの変換をして そのままinsert 2回実⾏すると...︖ ID aaa bbb ccc ddd eee ID aaa bbb ccc ddd eee いい感じの変換をして insert ID aaa bbb ccc ddd eee 新しく到着したレコードが すでにある場合はdelete 変換前テーブル 変換後テーブル 変換後テーブル 変換前テーブル 何回実⾏してもOK

Slide 13

Slide 13 text

© 2024 DATUM STUDIO Co. Ltd. おわりに

Slide 14

Slide 14 text

© 2024 DATUM STUDIO Co. Ltd. まとめ システムB データ抽出 (スコープ外) 共通 データ変換&テスト システムA データ抽出 システムA データ取り込み システムA データ鮮度チェック 外部連携 システムB データ取り込み システムB データ鮮度チェック ワークフロー ジョブ 定時起動 システムA データ変換 システムB データ変換 システムごとの処理は分割 ビジネス要件に依るが、ほとんどの場合鮮度チェックのみで⼗分 →データ品質チェックはデータ変換後 or waningで処理継続 テスト順序は利⽤⽤途に応じて議論する 厳格な依存関係は不要 1システムでも正常終了すれば処理継続して良い ①再現性 ü データを再取り込みしてもOK ü データの到着順が⼊れ替わってもOK ②冪等性 ü 同じ処理を繰り返しても結果が変わらない ü 副作⽤がない

Slide 15

Slide 15 text

© 2024 DATUM STUDIO Co. Ltd. 参考 以下の資料/記事を参考にしました • https://aws.amazon.com/jp/what-is/batch-processing/ • https://maximebeauchemin.medium.com/functional-data-engineering-a-modern- paradigm-for-batch-data-processing-2327ec32c42a • https://netflixtechblog.com/2-diving-deeper-into-psyberg-stateless-vs-stateful-data- processing-1d273b3aaefb