Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】Automating Data Quality Checks: A Practical Guide Using Dagster and Great Expectations

2025年09月30日に「Dev.to」が公開したITニュース「Automating Data Quality Checks: A Practical Guide Using Dagster and Great Expectations」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

データ品質はビジネスの意思決定に不可欠。手動チェックの限界から、DagsterとGreat Expectationsで自動データ品質チェックを導入する。これにより、データ整合性、エラー削減、効率向上、リアルタイム監視、コンプライアンス対応が実現。具体的なテスト実装例やデモも提供されている。

ITニュース解説

企業がデータに基づいた意思決定を行う際、データの品質は極めて重要である。しかし、扱うデータ量が増大し、データソースが多様化する現代において、手動でのデータ品質チェックはもはや現実的ではなく、ヒューマンエラーのリスクも高まる。このような背景から、データの整合性と信頼性を大規模に維持するためのスケーラブルな解決策として、データ品質チェックの自動化が不可欠となる。

自動化されたデータ品質チェックは、ビジネスに多くの利点をもたらす。第一に、データ整合性が向上する。事前に定義された品質基準に基づいて信頼性の高いデータを収集することで、誤った仮定やデータに基づかない意思決定のリスクを低減できる。第二に、エラーが最小化される。エラーの可能性を完全に排除することはできないが、自動化によりその発生確率を大幅に減らせる。特に、データパイプラインの早い段階で異常を特定できれば、後の工程での修正コストやリソースの無駄を大きく削減し、戦術的な間違いが戦略的な問題に発展するのを防ぐ。第三に、効率性が向上する。手動でのデータチェックは時間と人手を要するが、自動化によりデータチームは、データの洞察を見つけたりレポートを作成したりといった、より価値の高い業務に集中できるようになる。第四に、リアルタイム監視が可能になる。自動化はリアルタイムでの問題検出を可能にし、問題が大きくなる前に対応できる。第五に、コンプライアンス遵守に貢献する。個人情報保護規制のように、データ品質に関する規制が存在する場合があり、特に重要インフラでデータが使用される場合、データ品質のコンプライアンスが求められる。自動化された品質チェックを導入することで、データの品質に関する具体的な証拠を提供でき、監査プロセスも効率化される。

このような自動化されたデータ品質チェックを実現するために、オープンソースのツールであるDagsterとGreat Expectationsが強力な役割を果たす。Dagsterはオープンソースのデータオーケストレーターであり、ETL(抽出・変換・読み込み)、分析、機械学習のワークフローで利用され、データパイプラインの構築、スケジュール設定、監視を可能にする。Pythonベースで開発されており、データサイエンティストやエンジニアはデータ実行のデバッグ、アセットの検査、ステータス、メタデータ、依存関係の詳細な確認を容易に行える。これにより、データパイプラインの信頼性、スケーラビリティ、保守性が向上する。

Great Expectationsは、その名の通り「期待値」という概念を用いてデータ品質を維持するオープンソースのデータ検証フレームワークである。これはPythonライブラリであり、「Expectation(期待値)」はデータに対する「こうあるべき」というアサーション(主張)を意味する。Great Expectationsは、データのスキーマ(構造)や値に基づいた検証を提供する。例えば、最大値や最小値の範囲、特定のカラムの件数といったルールを設定できる。また、入力データから期待値を自動生成する機能も持ち、手動での調整が必要な場合もあるものの、初期設定の時間を節約できる。

具体的なデータ品質テストの実施方法として、データ提供組織ではテストをデータの種類と品質チェックの種類によって分類している。データの種類には、リアルタイムでスクレイピングしない「静的データ」と、リアルタイムでウェブからデータをスクレイピングする「動的データ」がある。品質チェックの種類には、事前定義されたフィクスチャ(固定の入力と期待される出力)を使用する「フィクスチャテスト」と、一連のルールに基づいてデータ品質をチェックする「カバレッジテスト」がある。

「静的フィクスチャテスト」は静的データカテゴリに属し、リアルタイムのスクレイピングは行わない。代わりに、以前保存した静的フィクスチャ(例えば、ウェブページのHTMLファイル)を入力として使用する。このテストでは、パーサーが静的フィクスチャを処理して出力データを生成し、その出力が事前に定義された期待される出力と一致するかを確認する。日付のような変更が予想される一部のフィールドを除き、これは比較的シンプルな比較プロセスである。このテストは、CI/CDパイプラインのマージリクエスト時に実行され、パーサーの変更が既存の機能を壊していないかを確認する第一線として機能する。しかし、このテストではリアルタイムのスクレイピングが機能しているか、またはウェブページのレイアウトが変更されていないかを確認することはできない。

この限界を克服するのが「動的フィクスチャテスト」である。これは基本的に静的フィクスチャテストと同じだが、入力データをリアルタイムでスクレイピングする点が異なる。これにより、パーサーだけでなく、スクレイパーの動作やページレイアウトの変更もチェックできる。動的フィクスチャテストは、スクレイパーとパーサーの両方をテスト実行時に起動し、その間のデータフローを管理する必要があるため、Dagsterがオーケストレーターとして、スクレイパーとパーサー間のデータフロー管理を支援する。具体的なプロセスは、スクレイピングしたいURLをキューに投入し、スクレイピングを実行し、パースし、最後にパースされたドキュメントを保存されたフィクスチャと照合するという4つのステップからなる。このテストはスクレイパーとパーサーの両方をチェックし、ページレイアウトの変更も検知できるため、定期的に実行される。しかし、このテストには、結果を予測できる(制御可能な)プロファイルのデータ品質しかチェックできないという大きな制限がある。

「動的カバレッジテスト」は、この制限を解消するために導入される。これも動的データカテゴリに属するが、特定の値をチェックする動的フィクスチャテストとは異なり、定義されたルールのセットに対してデータ品質をチェックする。これにより、制御できないプロファイル(例えば、ウェブサイトのデータが頻繁に変動し、個々の結果を予測するのが難しい場合)のデータ品質も検証できる。動的カバレッジテストは、データ品質保証プロセスの中で最も複雑なテストであり、Dagsterがオーケストレーションを担い、Great Expectationsがデータ検証を行う。まず、テスト対象とするプロファイル(例えば、高いフィールドカバレッジを持つデータベース内のプロファイル)を選択する。次に、選択したプロファイルを使用してGreat Expectationsでルール(期待値)を生成する。これらのルールは「すべてのプロファイルが名前を持つべきである」「少なくとも50%のプロファイルが姓を持つべきである」「教育カウントの値は0より小さくてはならない」といった形で定義される。期待値が生成された後、URLをキューに投入し、スクレイピング、パース、そしてGreat Expectationsを用いたパース済みドキュメントの検証というパイプラインを実行する。このテストは、スクレイピングからパースまでのパイプライン全体をチェックし、制御できないプロファイルのデータ品質を検証する点で非常に重要であり、すべてのターゲットに対して定期的に実行される。

DagsterとGreat Expectationsを用いた自動化されたデータ品質チェックの具体的な実装例として、デモプロジェクトがある。このデモは動的カバレッジテストの主要部分であるデータ品質検証に焦点を当てている。デモグラフは「load_items(ファイルからJSONデータを読み込む)」「load_structure(ファイルからデータ構造をSparkスキーマ形式で読み込む)」「get_flat_items(データをフラット化する)」「load_dfs(フラット化されたデータをSpark DataFrameとして読み込む)」「ge_validation(各DataFrameに対してGreat Expectationsの検証を実行する)」「post_ge_validation(Great Expectationsの検証結果をチェックする)」という操作で構成されている。

特に注目すべきは、データ構造の生成とデータ準備、そして期待値の生成である。「load_structure」操作で読み込まれるデータ構造はSparkスキーマ形式であり、これはGreat ExpectationsがSpark DataFrameと連携するためである。また、Pydanticモデルで定義されたネストされたオブジェクトは、Great Expectationsがネストされたデータをうまく扱えないため、個別のSparkスキーマとして表現される。例えば、「Company」モデルとその中にネストされた「CompanyHeadquarters」モデルがある場合、それぞれが個別のSparkスキーマとして扱われる。

「get_flat_items」操作は、データ検証のためにデータを準備する役割を果たす。ネストされた各オブジェクトが別々のSpark DataFrameの行として表現されるように、データをフラット化する。例えば、複数の会社情報を含むJSONリストがあった場合、フラット化後には「会社」と「会社の本社」のリストが別々に分離されたJSONオブジェクトになる。このフラット化されたデータは、「load_dfs」操作で、読み込まれた構造に基づいて個々のSpark DataFrameとして読み込まれる。ここでDagsterのDynamicOut機能が活用され、読み込まれたデータ構造に応じて動的にグラフが生成される。これにより、構造内のネストされたオブジェクトごとに独立したge_validation操作が並列で作成され、検証プロセスが高速化されるだけでなく、どのようなデータ構造にも対応できる柔軟なグラフが構築される。

期待値の生成も重要である。デモでは期待値がすでに用意されているが、Great Expectationsは提供されたデータと構造に基づいて期待値スイートを自動生成できる。生成された期待値スイートには、データの各フィールドに関する多くの期待値が含まれる。しかし、自動生成された期待値は、手動で調整する必要がある場合が多い。例えば、「フォロワー数」のフィールドでは、最小値が0より大きいことや値が整数であることは期待できるが、時間の経過とともに変動する最大値、平均値、中央値に関する期待値は削除する必要がある。一方、「完全性スコア」のように0から100の間に収まるべきフィールドでは、最大値と最小値の両方の期待値が有効である。このように、各フィールドの特性を理解し、適切な期待値を残し、不適切なものを削除・調整することが、質の高いデータ検証には不可欠である。

デモを実行すると、DagsterのUIであるDagit(localhost:3000でアクセス可能)で、動的に生成されたge_validation操作が各ネストされたオブジェクトに対して実行される様子を確認できる。検証がすべて成功すれば緑色で表示され、一部でも失敗すれば赤色で失敗した操作が示される。失敗した場合は、該当するge_validation操作をクリックし、「Expectation Results」を表示することで、具体的にどの期待値が満たされなかったかを確認できる。

結論として、データパイプラインの様々な段階においてデータ品質をテストする方法は数多く存在するが、データの正確性と信頼性を確保するためには、自動化されたデータ品質チェックのメカニズムを確立することが不可欠である。DagsterやGreat Expectationsといったツールは、必ずしもすべてのテストに必須というわけではないが(例えば静的フィクスチャテストでは使用しない)、これらを活用することで、より堅牢で効率的なデータ品質保証プロセスを構築できる。既存のデータ品質プロセスを強化する場合でも、全く新しいシステムをゼロから構築する場合でも、これらのツールと実践は貴重な洞察を提供するだろう。

関連コンテンツ

関連IT用語

関連ITニュース