データ基盤の品質維持にdbt Coreをスモールスタートで導入

ツール導入前の課題

オンプレミスの電子カルテデータ基盤のAmazon Redshift Servelessへの移行のプロジェクトも終盤となり、データ基盤を運用するフェーズも考えるタイミングになっていました。 運用する上で重要な事の1つとしてデータ品質の維持があります。製薬企業様、医療機器メーカー様を中心に幅広くご活用いただいているデータであるため、最重要と言っても良いものです。 そのデータ品質の維持をコストをかけず、短期間で実現できる方法はないかと考え、完成済データ基盤に対してもデータ品質チェックを行えそうなdbtを活用できないかを検討していました。 具体的に実現したいことは以下でした。

1. テーブル名のprefixが異なるだけの同一定義のテーブルに、同じデータ品質チェックをかけられること
   どの月のデータかを区別するためにテーブル名にprefixを付加して分けているためです。
2. 抽出したデータをcsv出力できること
   データ品質を他部門向けに可視化したり、確認を依頼することがあります。そのような際にある程度集計したデータを抽出し、そのまま提供、もしくはスプレッドシート等で可視化したりしますが、それに使えるデータをcsv出力したいためです。

どのような状態を目指していたか

• 毎月の運用で、同じ手順で再現性のあるデータ品質チェックが行えること
• 容易にデータ品質チェック内容の追加、変更ができること

• dbt Core →採用
• dbt Cloud

• アクセスの制限された環境でも利用出来ること
• お試し的な側面もあったので、利用料がなるべくかからないこと

改善したかった課題はどれくらい解決されたか

「ツール導入前の課題」に記載の実現したいことは全て実現できました。

1. テーブル名のprefixが異なるだけの同一定義のテーブルに、同じデータ品質チェックをかけられること
   モデルのaliasに、valiablesとテーブル名を連結したものを指定することにより、動的にテーブル名を変更できるようにして同一モデルとして扱うことにより実現できました。
2. 抽出したデータをcsv出力できること
   dbtのPackageのdbt-labs/redshiftでUNLOADコマンドを実行するunload_tableマクロがあり、そちらを活用しました。

詳しくはテックブログを参照ください。

どのような成果が得られたか

• 短期間で約470項目のテストを準備
  genericテストを3個自作、汎用性の高いGenericテストを中心に活用したので、比較的短期間でデータ品質維持の基礎も構築可能でした。
• データ基盤の結合テストやユーザ受け入れ試験のデータ抽出にも活用
  運用開始前から再現性のあるテストとしても活用できました。
  • 運用部門が評価するための集計データの抽出
  • ユニークとなるべき値の重複などデータの妥当性不備を早期発見、対処
  • テーブルの比較のテストで修正後の意図しないデータ差異がないかも容易に確認が可能
• 過去同様の対応事例（railsのwebアプリケーションで作りこみ）との比較
  • 工数
    今回：約3人月 / 過去事例：約9人月 = 1/3（同規模1システムあたり 6人月減）
  • データ品質チェック数
    今回：470 / 過去事例：117 = 約4倍