Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ugmuka
March 21, 2024
600

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

ugmuka

March 21, 2024
Tweet

Transcript

  1. © 2024 DATUM STUDIO Co. Ltd. データパイプラインの処理⽅法 データ処理にはバッチ処理とストリーミング処理の⼆つがある 源泉システム ストリーミング

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

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

    (スコープ外) 共通 データ変換&テスト システムA データ抽出 システムA データ取り込み システムA データ鮮度チェック 外部連携 システムB データ取り込み システムB データ鮮度チェック 定時起動 システムA データ変換 システムB データ変換 バッチ処理設計例 ジョブ設計:各ジョブの詳細な処理を定義 ワークフロー設計:ジョブ同⼠の依存関係を定義
  4. © 2024 DATUM STUDIO Co. Ltd. 複数システム連携時の依存関係の設計 依存関係は増やすほどパイプラインの稼働率低下につながる。ビジネス要件とSLAを考慮して、本当に重要な ジョブにのみ厳格な依存関係を設定するのが吉 システムA

    データ抽出 システムB データ抽出 システムC データ抽出 システムD データ抽出 システムE データ抽出 共通(システム横断) データ変換 ❌ Bad 全システム処理の 正常終了を確認 システムDに障害発⽣︕ →関係のないパイプラインも⽌まってしまう... システムA データ抽出 システムB データ抽出 システムC データ抽出 システムD データ抽出 システムE データ抽出 共通(システム横断) データ変換 ⭕ Good 1つ以上のシステム処理 正常終了を確認 システムDに関係のないパイプラインは⽌めない →コスト⾯などで問題がなければ終了ステータスに関係なく 後続処理を継続するのが簡単
  5. © 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 データ抽出 (スコープ外) 各取り込み処理が 正常終了するたびに都度実⾏
  6. © 2024 DATUM STUDIO Co. Ltd. テストの実⾏について 変換処理後のテストは即時実⾏と、すべての処理終了後に実⾏の2パターンがある。利⽤⽤途やSLAを考慮 してシステムに合った⽅式を選択すること 中間層

    データ変換 共通 データ変換&テスト 中間層 テスト マート層 テスト … マート層 データ変換 外部連携 中間層 データ変換 共通 データ変換&テスト 中間層 テスト マート層 テスト … マート層 データ変換 外部連携 … ①各層ごとに変換後即時テストを⾏う ü データ品質を重視するパターン ü テストが失敗すると後続の変換処理がすべて停⽌する ü テスト失敗に関係のないデータのみを更新するのはかなり難しい (ワークフローの複雑化につながる) ②すべての変換が終了後にテストを⾏う ü データの鮮度やシステム全体のSLAを重視するパターン ü 不正確なデータが提供されているため、利⽤者への迅速な通知が必要 ü 場合によっては特定テーブルの切り戻し処理を⾏ったりもする
  7. © 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 データ変換処理 変 換 前 $ % & 変 換 後 $ % &
  8. © 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
  9. © 2024 DATUM STUDIO Co. Ltd. まとめ システムB データ抽出 (スコープ外)

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