Google Cloud Dataplex を使ったデータ品質の向上
Posted on
こんにちわ、プレイドでエンジニアをしている塩澤（@hshiozawa）です。
プレイドはミッションとして「データによって人の価値を最大化する」を掲げています。私たちにとって「データ」は会社のミッションに掲げるほどの重要な存在です。プレイドは多種多様なデータを扱っていますが、データから価値を生み出すためにはその品質（Data Quality）が非常に重要となります。
この記事では Google Cloud Dataplex の自動データ品質（Auto Data Quality）機能を使ったデータ品質向上の取り組みについてご紹介します。
データ品質
プレイドでは Google Cloud の BigQuery を利用して多種多様な大量のデータを扱っています。データパイプラインやテーブルも数多くあり、マイグレーションも頻繁に行っています。このような大量のデータから価値を生み出すために、データ品質の向上は必要不可欠なものです。
たとえば、ユーザーの Web サイト上での行動データを考えてみます。サイトの運営者はサイトでのユーザー体験をよりよくするためにデータを使ってユーザーを理解しようとします。その時、行動データが次のような状況だとどうなるでしょうか？
- ユーザー ID が含まれていないレコードが存在する
- 行動イベントのレコードが一部抜け落ちている
- 購入イベントのレコードが重複して存在する
このような状況ではデータからユーザーを正確に理解することはできませんし、ユーザー体験を向上することもできません。これはあくまで一例ですが、ユーザーのイベントに限らずデータの品質が低い場合には、そこから価値を生み出すことが難しくなります。
定義
ここまでは曖昧に「データの品質」という言葉を用いてきましたが、『データマネジメント知識体系ガイド 第二版』（通称 DMBOK）ではデータ品質を次のように定義しています。
データ品質は、データ品質の各評価軸が要件を満たす度合いとして定義できる。これは要件を、（関連する）それぞれの評価軸ごとに策定する必要があることを意味する。データ品質の定義を簡潔にすると、「目的に適合している」となる。
このようにデータ品質を考えるためにはデータを評価するための一定の軸を定める必要があります。DMBOK では一般的な合意が得られているデータの評価軸として次のようなものを挙げています（抜粋しています）。
- 有効性（Validity）：定義された領域と一致しているかどうか
- 完全性（Completeness）：必要なデータが存在するかどうか
- 一貫性（Consistency）：同じルールで表されているかどうか
- 適時性（Timeliness）：ユーザーがデータにアクセスできるまでの時間
- 一意性（Uniqueness）：一意であるべきデータが重複してないかどうか
データ品質を向上させるためには、データの特性に応じてこれらがどの程度満たされるべきかの要件を定める必要があります。その後、この評価軸がどれだけ満たされているかを実際に測定し、必要な修正を行います。そして最も重要な点は、この一連の活動を継続して続けていくことです。
課題
ここからはプレイドにおけるデータ品質に対しての課題について述べます。話を簡単にするため以下のようなシンプルなパイプラインを想定してみます。
データソースで発生したデータは BigQuery に書き込まれます。その後、解析などのアプリケーションによってデータが変換され、他のテーブルに書き込まれます。このような構成のパイプラインはプレイドに多く存在します。
このようなパイプラインに対していくつかの方法でデータの正しさをチェックしていました。
- データソースがデータを書き込む際に、書き込む側がデータを確認
- データを変換した後に Transformer がデータの正しさを確認
- テーブルのチェックジョブが定期的にデータのぬけもれを確認
- 他のパイプラインがデータを使う前にデータの整合性を確認
このようにして様々な箇所で独自のデータのチェックが行われていました。また、これらはすべてのパイプラインで実現されていたわけではなく、それぞれのパイプラインの特性や重要度に応じて実装されていました。
これらの手法は必要に応じて要求に特化したチェックができるのでメリットもありますが、本質的には次のような問題を抱えていました。
評価軸が不明瞭
データ品質の定義で述べたように、データ品質には評価軸という考え方があります。しかし、この確認方法では、それぞれがどの評価軸に対応したチェックなのかが不明瞭です。この曖昧さによって問題を正確に捉えることが困難になり、効果的な施策が実行されない要因となっていました。
また、評価軸が不明瞭であることでデータ品質という概念自体をチームに浸透させることが難しいという面もありました。
要求が分かりづらい
評価軸の問題に加えて、それぞれのデータに求められている要求が明らかになっていないことは大きな問題でした。これらの方法によって「データに問題がない」ことは確認できています。しかし、データが満たすべき要求が明確になっていません。
これは要求をコード上に手続き的に記述したり、確認用の SQL クエリの実行で実現していることも要因です。手続き的なコードや確認用の長いクエリを見ただけでは、何が満たすべき基準なのかを判断することは難しくなってしまいます。
観測可能性が低い
既存の確認方法では「データがテストケースを満たしたかどうか」の単純な事柄しか分かりません。「テストケースは満たしているが品質が徐々に劣化している」ようなケースが把握できません。そのため、問題が起きる前に早めに手を打つことができません。また、過去の履歴を統一的に記録する仕組みがないため昔の品質や、品質の推移を確認できていません。
仕組みの乱立
それぞれの部分で独自の仕組みを作ったことで、プロダクトを横断する統一的な基準を作ることが難しくなってます。また、それぞれでデータの確認の実現方法が異なるため、あるチームは SQL クエリとして実現し、あるチームは API を利用して確認する、といったように確認方法が乱立しました。
実現方法が異なることでメンテナンスコストが高くなり、最悪の場合はメンテナンスされなくなり放置される可能性もあります。こうなるとデータ品質を保つことは難しくなります。
Dataplex 自動データ品質の採用
Google Cloud Dataplex はデータを管理・統合するためのデータファブリックです。BigQuery に限らず分散したデータを統合・統制するためのデータカタログやデータメッシュなど、様々な機能を提供しています。
自動データ品質はこの Dataplex 内の機能の一つです。BigQuery のテーブルに対してルールを定義し、ルールを満たしているかどうかを確認することができます。
ここからは Google Cloud Dataplex の自動データ品質機能（以下、自動データ品質）を採用した理由について述べます。ここでは自動データ品質の利用の仕方については詳しく書きません。利用方法はドキュメント等を参考にしてください。
自動データ品質の概要 | Dataplex | Google Cloud
理由1：ルールを YAML で記述できる
自動データ品質ではルールを下記のような YAML で記述することができます。
rules:
- uniquenessExpectation: {}
column: transaction_id
dimension: UNIQUENESS
- nonNullExpectation: {}
column: amount
dimension: COMPLETENESS
threshold: 1
- setExpectation :
values :
- 'USD'
- 'JPY'
- 'INR'
- 'GBP'
- 'CAN'
column : currency_id
ignoreNull : true
dimension : VALIDITY
threshold : 1
データが満たすべきルールを宣言的な形で記録できるのは大きな利点です。これによってそれぞれのカラムが満たすべき要求を把握することが簡単になります。また、Single Source of Truth となっているので、満たすべき要求を変えたい場合はこの YAML を変えるのみです。
理由2：スコアリング
自動データ品質のチェック結果には 0~100 のスコアが含まれています。これまではテストの成功か失敗しか把握できませんでしたが、ある程度の尺度で品質を評価できるようになりました。また、全体のスコアに加えて YAML で設定した dimension（評価軸）ごとのスコアも取得することができるため、評価軸ごとの品質評価も可能となります。
理由3：シンプルな仕組み
BigQuery のデータ品質を確認するツールは自動データ品質以外にもいくつかあります。dbt や dataform などがありますが、これらはデータ管理ツールの一種でテーブル自体をそれらのフレームワーク上で管理するのが一般的です。
その点、自動データ品質は BigQuery のデータ品質を確認する部分だけで利用できることができます。すでにある BigQuery のデータに対して変更を加える必要はありません。また、自分でインスタンス等のリソースを準備する必要もありません。これらは自動でデータ品質を採用した大きな理由です。
理由4: BigQuery との親和性
自動データ品質は BigQuery を前提に作成されているので BigQuery との親和性が非常に高いです。弊社は多くのデータを BigQuery で扱っているのでこの点はとても重要です。
具体的にはパーティションごとのインクリメンタルスキャンや、ネイティブテーブル以外にも多く対応しています。また、BigQuery の既存のテーブルをスキャンし、自動でそれを満たすようなルールを作成してくれるような便利な機能もあります。
理由5：実行履歴の記録
チェックの結果は Google Cloud コンソールから GUI で確認できます。それ以外にも結果を BigQuery のテーブルに保存することもでき、ほぼ永続的にデータ品質の推移を保持することが可能です。
また、前述したスコアリングに加え、カラムごとの細かいチェック記録も保存されているで、あとからカラムごとの品質推移を追うこともできます。
アーキテクチャ
ここからは構築したシステムのアーキテクチャについて説明します。
Dataplex の自動データ品質が持っているマネージドな機能をベースにして、プレイドの状況に合わせて補助的なアプリケーションを作成してシステムを構築しました。構築したアーキテクチャの全体像は次のとおりです。
スキャン実行アプリケーション
自動データ品質を実行するためのアプリケーションは独自に実装しました。このアプリケーションは API を利用して自動データ品質を実行します。自動データ品質はマネージド機能なので実行アプリケーションを作らずとも利用することもできます。ただ、プレイドの状況に合わせるため、下記のような機能を実装して自動データ品質を補完していますました。
- 複数のルールを指定可能にし、同時並行で実行できるようにした
- 日付を指定可能にして、日付シャーディングテーブルに対応した
- リージョンを指定可能にして、同じルールを異なるリージョンでチェックできるようにした
このように独自のアプリケーションを作ることで、自動データ品質の機能を補ってより柔軟なチェックが可能になりました。
ルールの管理
上述したようにテーブルの満たすべきの仕様は YAML ファイルとして定義しています。この YAML はスキャン実行アプリケーションのソースコードと同一の Git リポジトリでバージョン管理しています。こうすることであるべき仕様とルールの管理が一元的に管理できるようになっています。また、Git を利用するため変更履歴の確認が容易になっています。
Google Kubernetes Engine で実行
作成したスキャンアプリケーションは Docker Image としてビルドしたあと Google Kubernetes Engine で実行しています。Docker Image にはルールの YAML も含めて実行に必要な一式がすべて含まれているので再利用が容易になっています。通常、このアプリケーションを CronJob として実行することで定常的な品質チェックに利用しています。
現時点ではチェックアプリケーションは GKE で動作させていますが、Cloud Run などのよりマネージドな環境で動作させることも可能です。また、ルールの更新（コミット＆プッシュ）と、そのデプロイは分離されているため検証環境での検証も容易になっています。
プレイドでは GKE 上で使えるワークフローツールを利用してパイプラインを構築しています。作成したスキャンアプリケーションはこのパイプラインとも連携可能です。こうすることで特定のジョブワークフローの最後にスキャンを実行し、パイプライン実行の結果に対する品質をすぐにチェックすることもできます。
モニタリングツール
実行アプリケーションを独自に実行したことで、外部のモニタリングツールと連携することが可能です。プレイドでは横断的なモニタリングツールとして Datadog を用いています。Datadog にすべての結果を送ることは現実的ではないため、結果の一部をカスタムメトリクスとして送信してモニタリングに利用しています。
成果
データ品質の導入
既存のデータパイプラインを変更せずにデータ品質を観測するための仕組みを導入することができました。これに伴ってデータに対する要求を明確にし YAML 形式で表すことができました。評価軸がきちんと明確になったことでデータ品質に対する精度が高まりました。また、スコアリング値によって以前よりもより品質をより詳細に把握できるようになったことも大きな利点です。
観測可能性の向上
品質チェックを定常的で統一的に実行できるようになりました。スキャン結果は Google コンソールや Datadog 上で確認できるようになっています。このような定常的で統一した仕組みがあることでチームでの品質のコミュニケーションが円滑になっています。
また、データ品質の劣化を検知できるようになりました。その結果、問題が発生する前にアクションをとれるようになっています。実際にいくつかのテーブルで品質の劣化は検知することができアクションをとることができました。このように、間違いなく観測可能性が高まりました。
スケーラブルな仕組み
これまでばらばらだったデータのチェックの仕組みを統一的な仕組みに変更し、プロダクトの種類が増えた場合にも対応できるようなスケーラブルな仕組みになりました。統一された仕組みを活用することで、チェックの導入コストを大幅に削減し、チェックに一貫性が生まれています。新しい品質チェックの導入と運用の負荷を大幅に削減することができましたし、ルールを作るときは YAML ファイルを作るだけですむため開発者体験も向上しています。
まとめ
今回は Google Cloud Dataplex の自動データ品質を用いて、データ品質管理の仕組みを構築しました。Dataplex を活用することで既存のデータパイプラインに影響を与えることなく、アドインの形でデータ品質を測定し、品質改善の仕組みを整えることができました。この仕組みによって、データに対する一貫した品質チェックが可能となり、異常検知・品質の劣化への迅速な対応によって信頼性を向上させることができました。
今後もこうした取り組みをさらに加速させ、プレイドが提供するデータへの信頼を着実に高めるとともに、データによる価値を最大化するように取り組んでいきます。