データパイプラインバッチ設計で私が考えること

Transcript

1. データパイプライン バッチ設計で私が考えること DATUM STUDIO株式会社 向井 雄⼆
2. © 2024 DATUM STUDIO Co. Ltd. はじめに
3. © 2024 DATUM STUDIO Co. Ltd. データパイプラインの処理⽅法 データ処理にはバッチ処理とストリーミング処理の⼆つがある 源泉システム ストリーミング DWH Data Lake バッチ ü s3などにファイルを置いてもらう/ingestツールを使う ü 源泉システムの断⾯を保持するため扱いやすい ü Kafkaなどのメッセージングキューから連携 ü データの到着順が⼊れ替わることがあるので、ログ系のデータ向き ü バッチでのLoadが間に合わない場合にも採⽤される バッチ バッチ ストリーミング ü ⼀括ですべてのデータを処理 ü マシンパワーの強い近年のDWH製品と相性が良い ü viewやlambda viewによる実装 ü 分析に即時性が求められる場合に採⽤ される ü 複雑な処理設計が必要になる （個⼈的にはなるべく避けたい） （同左） ① ② ※ほんとはもっと⾊々あるけど本筋ではないので割愛 ①Extract/Load （データ抽出/取り込み） ②Transform （データ変換）
4. © 2024 DATUM STUDIO Co. Ltd. データパイプラインの処理⽅法 データ処理にはバッチ処理とストリーミング処理の⼆つがある 源泉システム ①Extract/Load （データ抽出/取り込み） ストリーミング DWH Data Lake ②Transform （データ変換） バッチ ü s3などにファイルを置いてもらう/ingestツールを使う ü 源泉システムの断⾯を保持するため扱いやすい ü Kafkaなどのメッセージングキューから連携 ü データの到着順が⼊れ替わることがあるので、ログ系のデータ向き ü バッチでのLoadが間に合わない場合にも採⽤される バッチ バッチ ストリーミング ü ⼀括ですべてのデータを処理 ü マシンパワーの強い近年のDWH製品と相性が良い ü viewやlambda viewによる実装 ü 分析に即時性が求められる場合に採⽤ される ü 複雑な処理設計が必要になる （個⼈的にはなるべく避けたい） （同左） ① ② 今⽇の話題
5. © 2024 DATUM STUDIO Co. Ltd. バッチ処理設計での考慮事項 ⼤きく分けて⼀つずつのジョブ設計、ジョブ同⼠の依存関係を定義するワークフロー設計が必要 システムB データ抽出 （スコープ外） 共通 データ変換＆テスト システムA データ抽出 システムA データ取り込み システムA データ鮮度チェック 外部連携 システムB データ取り込み システムB データ鮮度チェック 定時起動 システムA データ変換 システムB データ変換 バッチ処理設計例 ジョブ設計:各ジョブの詳細な処理を定義 ワークフロー設計:ジョブ同⼠の依存関係を定義
6. © 2024 DATUM STUDIO Co. Ltd. ワークフロー設計の考慮事項
7. © 2024 DATUM STUDIO Co. Ltd. 複数システム連携時の依存関係の設計 依存関係は増やすほどパイプラインの稼働率低下につながる。ビジネス要件とSLAを考慮して、本当に重要な ジョブにのみ厳格な依存関係を設定するのが吉 システムA データ抽出 システムB データ抽出 システムC データ抽出 システムD データ抽出 システムE データ抽出 共通（システム横断） データ変換 ❌ Bad 全システム処理の 正常終了を確認 システムDに障害発⽣︕ →関係のないパイプラインも⽌まってしまう... システムA データ抽出 システムB データ抽出 システムC データ抽出 システムD データ抽出 システムE データ抽出 共通（システム横断） データ変換 ⭕ Good 1つ以上のシステム処理 正常終了を確認 システムDに関係のないパイプラインは⽌めない →コスト⾯などで問題がなければ終了ステータスに関係なく 後続処理を継続するのが簡単
8. © 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 データ抽出 （スコープ外） 各取り込み処理が 正常終了するたびに都度実⾏
9. © 2024 DATUM STUDIO Co. Ltd. テストの実⾏について 変換処理後のテストは即時実⾏と、すべての処理終了後に実⾏の2パターンがある。利⽤⽤途やSLAを考慮 してシステムに合った⽅式を選択すること 中間層 データ変換 共通 データ変換＆テスト 中間層 テスト マート層 テスト … マート層 データ変換 外部連携 中間層 データ変換 共通 データ変換＆テスト 中間層 テスト マート層 テスト … マート層 データ変換 外部連携 … ①各層ごとに変換後即時テストを⾏う ü データ品質を重視するパターン ü テストが失敗すると後続の変換処理がすべて停⽌する ü テスト失敗に関係のないデータのみを更新するのはかなり難しい （ワークフローの複雑化につながる） ②すべての変換が終了後にテストを⾏う ü データの鮮度やシステム全体のSLAを重視するパターン ü 不正確なデータが提供されているため、利⽤者への迅速な通知が必要 ü 場合によっては特定テーブルの切り戻し処理を⾏ったりもする
10. © 2024 DATUM STUDIO Co. Ltd. ジョブ設計の考慮事項
11. © 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 データ変換処理 変 換 前 $ % & 変 換 後 $ % &
12. © 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
13. © 2024 DATUM STUDIO Co. Ltd. おわりに
14. © 2024 DATUM STUDIO Co. Ltd. まとめ システムB データ抽出 （スコープ外） 共通 データ変換＆テスト システムA データ抽出 システムA データ取り込み システムA データ鮮度チェック 外部連携 システムB データ取り込み システムB データ鮮度チェック ワークフロー ジョブ 定時起動 システムA データ変換 システムB データ変換 システムごとの処理は分割 ビジネス要件に依るが、ほとんどの場合鮮度チェックのみで⼗分 →データ品質チェックはデータ変換後 or waningで処理継続 テスト順序は利⽤⽤途に応じて議論する 厳格な依存関係は不要 1システムでも正常終了すれば処理継続して良い ①再現性 ü データを再取り込みしてもOK ü データの到着順が⼊れ替わってもOK ②冪等性 ü 同じ処理を繰り返しても結果が変わらない ü 副作⽤がない
15. © 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