Datasets for Critical Operations by Dataform

Datasets for Critical Operations by Dataform Dinii inc. Junya Kimura
Dataform Meetup #1

自己紹介名前: Junya Kimura (kimujun) 所属: 株式会社ダイニーロール: Application Development,
Data Engineering 全般の Tech Lead

今日の話の流れ 1. Background: Dataset for Critical Operation 2. Problem: 堅牢性より大事なもの、ある？
3. Solutions: 堅牢性担保のアプローチ 4. Summary: アプリケーション設計の重要性

Background: Dataset for Critical Operation What アプリケーション上の重要なオペレーションに直接関わるデータセットビジネスプロセスに組み込まれている例えば… 09:00AMに顧客へのメール配信
12:00PMにLINE配信月次決算用データ

Architecture すべて Google Cloud 上で完結 E は Datastream, TL は
Dataform

Problem: 堅牢性より大事なもの、ある？データの不具合がビジネスに直結する堅牢性への投資が最も重要ポイント 1. 高可用性 - 壊れにくいシステム 2.
データ品質 - データが正しい 3. 適時性 - 必要な時に必要なデータがある

1. 高可用性 - スキーマ安全性の担保高可用性のためにやることスキーマ安全性を仕組みで担保するバックエンドサーバーとの整合性を守るダイニーのスキーマ管理 1. dataform
run で生成したデータセットのスキーマをファイルに抽出 2. バックエンドと Symbolic Link 等で共有 3. テスト前にスキーマ情報をもとに空のデータセットを生成 4. BigQuery に向けてバックエンドに定義された dry run テストを実行

1. 高可用性 - スキーマ安全性の担保重要なポイントスキーマが変わりうるタイミングで必ずスキーマファイルを更新する CI で各ステップの正確性を必ずチェックする

2. データ品質の担保品質テスト品質テストツールは色々あるが、自由度に不満がある AI Coding 時代なので必要な分を必要なだけ作るのが良さそうということで自前で品質テスト機構を実装している他のアプローチ -
Dataplex Data Quality Google Cloud 内で完結する嬉しさはあるが… コード管理がしにくいテーブル/データセットをまたいだ検証が定義しにくいあたりのデメリットも。今後の機能拡張に期待しています 💪

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", },

3. 適時性の担保適時性とは？特定のタイミングに必要なデータが用意されていること例: メール配信システム朝 09:00 に顧客にメール配信するユースケース 09:00
に必ず配信用のデータが存在している必要があるデータが遅延するとビジネスに直結

3. 適時性の担保品質テストのタイミング制御定義したタイミングで品質テストを実行する e.g. 08:00 にメール配信データの品質テストを実行するインフラ監視のシステムに統合し、オンコール体制を作る心構え -
パイプラインは必ずいつか壊れる！！！！！絶対にいつかパイプラインは壊れる (大事なことなので2回目) アプリケーション実装を安心設計にしておくべき冪等な API 実装をする、データ無い時はそもそも実装せずアラートをすぐに飛ばすなど、やれることはたくさんある

まとめ: 堅牢性担保の観点 1. 高可用性: スキーマ安全性の仕組み化スキーマ管理を仕組み化する CI での自動チェックさせる 2. データ品質:
自前テスト機構の実装 3. 適時性: タイミング制御と監視定義したタイミングでの品質テスト実行パイプラインは必ず壊れる！！！！！ (3回目)

今後の展望を書きたかった書く時間がありませんでした (土下座)

Thank you! このスライドは slidev と Claude Code によって作成されました

Datasets for Critical Operations by Dataform

Datasets for Critical Operations by Dataform

kimujun

More Decks by kimujun

Other Decks in Technology

Featured

Transcript