Datasets for Critical Operations by Dataform

Dataform Meetup #1 の発表資料
https://dataform-jp.connpass.com/event/359348/

Transcript

1. Datasets for Critical Operations by Dataform Dinii inc. Junya Kimura Dataform Meetup #1
2. 自己紹介 名前: Junya Kimura (kimujun) 所属: 株式会社ダイニー ロール: Application Development, Data Engineering 全般の Tech Lead
3. 今日の話の流れ 1. Background: Dataset for Critical Operation 2. Problem: 堅牢性より大事なもの、ある？ 3. Solutions: 堅牢性担保のアプローチ 4. Summary: アプリケーション設計の重要性
4. Background: Dataset for Critical Operation What アプリケーション上の重要なオペレーションに直接関わるデータセット ビジネスプロセスに組み込まれている 例えば… 09:00AMに顧客へのメール配信 12:00PMにLINE配信 月次決算用データ
5. Architecture すべて Google Cloud 上で完結 E は Datastream, TL は Dataform
6. Problem: 堅牢性より大事なもの、ある？ データの不具合がビジネスに直結する 堅牢性への投資が最も重要 ポイント 1. 高可用性 - 壊れにくいシステム 2. データ品質 - データが正しい 3. 適時性 - 必要な時に必要なデータがある
7. 1. 高可用性 - スキーマ安全性の担保 高可用性のためにやること スキーマ安全性を仕組みで担保する バックエンドサーバーとの整合性を守る ダイニーのスキーマ管理 1. dataform run で生成したデータセットのスキーマをファイルに抽出 2. バックエンドと Symbolic Link 等で共有 3. テスト前にスキーマ情報をもとに空のデータセットを生成 4. BigQuery に向けてバックエンドに定義された dry run テストを実行
8. 1. 高可用性 - スキーマ安全性の担保 重要なポイント スキーマが変わりうるタイミングで必ずスキーマファイルを更新する CI で各ステップの正確性を必ずチェックする
9. 2. データ品質の担保 品質テスト 品質テストツールは色々あるが、自由度に不満がある AI Coding 時代なので必要な分を必要なだけ作るのが良さそう ということで自前で品質テスト機構を実装している 他のアプローチ - Dataplex Data Quality Google Cloud 内で完結する嬉しさはあるが… コード管理がしにくい テーブル/データセットをまたいだ検証が定義しにくい あたりのデメリットも。 今後の機能拡張に期待しています 💪
10. const emailConfigTestConfig: DataQualityTestConfig = { datasetName: "operation_mart", tableName: "emailConfig", nonNullColumns: ["id", "price", "quantity"], rangeConfigs: [{ columnName: "score", min: 0, max: 100 }], uniqueColumns: [tableKeys.email.primaryKey], // NOTE: RDB のユニークキーをそのまま参照している // NOTE: テーブル単体で担保できないドメイン制約を表現する customConfigs: [ { query: ` SELECT COUNT(emailTarget.id) AS emailTargetCount FROM operation_mart.emailConfig LEFT JOIN operation_mart.emailTarget ON emailConfig.id = emailTarget.emailConfigId GROUP BY emailConfig.id HAVING emailTargetCount < 1000 `, description: "email delivery target count should be over 1000", },
11. 3. 適時性の担保 適時性とは？ 特定のタイミングに必要なデータが用意されていること 例: メール配信システム 朝 09:00 に顧客にメール配信するユースケース 09:00 に必ず配信用のデータが存在している必要がある データが遅延するとビジネスに直結
12. 3. 適時性の担保 品質テストのタイミング制御 定義したタイミングで品質テストを実行する e.g. 08:00 にメール配信データの品質テストを実行する インフラ監視のシステムに統合し、オンコール体制を作る 心構え - パイプラインは必ずいつか壊れる！！！！！ 絶対にいつかパイプラインは壊れる (大事なことなので2回目) アプリケーション実装を安心設計にしておくべき 冪等な API 実装をする、データ無い時はそもそも実装せずアラートをすぐに飛ばすな ど、やれることはたくさんある
13. まとめ: 堅牢性担保の観点 1. 高可用性: スキーマ安全性の仕組み化 スキーマ管理を仕組み化する CI での自動チェックさせる 2. データ品質: 自前テスト機構の実装 3. 適時性: タイミング制御と監視 定義したタイミングでの品質テスト実行 パイプラインは必ず壊れる！！！！！ (3回目)
14. 今後の展望を書きたかった 書く時間がありませんでした (土下座)
15. Thank you! このスライドは slidev と Claude Code によって作成されました