分析のための一般的なデータ検証手法とその必要性

公開: 2022-12-19

編集者注: この記事は、もともと 2020 年 12 月 14 日に Iteratively ブログで公開されたものです。

結局のところ、データ分析は他のコードと同様にテストする必要があります。このコードとそれが生成するデータを検証しないと、コストがかかる可能性があります (Gartner によると、年間 970 万ドルのコストがかかります)。

この運命を回避するために、企業とそのエンジニアは、多数の積極的および事後対応型のデータ検証手法を活用できます。以下で説明するように、前者を強くお勧めします。データ検証への積極的なアプローチは、企業が保有するデータがクリーンですぐに使用できる状態であることを保証するのに役立ちます。

リアクティブ対プロアクティブデータ検証手法: データの問題が問題になる前に解決する

「1オンスの予防は1ポンドの治療に値する。」これは、分析のためのデータ検証手法を含め、ほぼすべての状況に当てはまる古いことわざです。別の言い方をすれば、受動的であるよりも積極的である方がよいということです。

データ検証の目的は、データが不正確、矛盾、不完全、または欠落している可能性がある場所を特定することです。

定義上、リアクティブなデータ検証は事後に行われ、異常検出を使用してデータに発生する可能性のある問題を特定し、不良データの症状を緩和します。これらの方法は何もないよりはましですが、そもそも不良データの原因となっている核心的な問題を解決するものではありません。

代わりに、チームは、型の安全性やスキーマ化などの分析用の積極的なデータ検証手法を採用して、取得するデータが正確で完全で、期待される構造になっていることを確認する必要があると考えています (将来のチームメンバーは悪い分析コードと格闘するため)。

より包括的な検証アプローチを選択するのは当然のことのように思えるかもしれませんが、多くのチームは事後対応型のデータ検証を使用することになります。これにはいくつかの理由が考えられます。多くの場合、分析コードは、多くの非データチームにとって後付けであり、テストされないままになっています。

残念ながら、データが検証なしで処理されることもよくあります。さらに、不十分な分析コードは、それが本当に悪い場合にのみ気付かれます。通常は数週間後に、レポートが著しく間違っているか、欠落していることに誰かが気づきます。

リアクティブなデータ検証手法は、dbt や Dataform などのツールを使用してウェアハウス内のデータを変換するように見えるかもしれません。

これらの方法はすべて、データの問題を解決するのに役立ちますが (多くの場合、客観的に優れたツールを使用して)、悪いデータの主な原因 (プロジェクトに実装された断片的なデータガバナンスや分析など) を解決するのには役立ちません。チーム間のコミュニケーションなしでプロジェクトごとに) そもそも、毎回彼らに戻ってくる必要があります。

リアクティブなデータ検証だけでは不十分です。真に効果的であり、前述のコストのかかる問題を回避するには、積極的なデータ検証手法を採用する必要があります。理由は次のとおりです。

データはチームスポーツです。 データがクリーンであることを保証するのは、1 つの部門や 1 人の個人だけではありません。高品質のデータを確保し、問題が発生する前に解決するには、全員が協力する必要があります。
データ検証は、ソフトウェア開発ライフサイクル (SDLC) の一部である必要があります。 それを SDLC に統合し、既存のテスト駆動型開発および自動化された QA プロセスと並行して (後付けで追加するのではなく) 統合すると、データの問題を後でトラブルシューティングするのではなく、防止することで時間を節約できます。
プロアクティブなデータ検証は、既存のツールと CI/CD パイプラインに統合できます。 開発チームはテストの自動化にすでに投資しており、分析の範囲を追加するためにそれを迅速に拡張できるため、これは簡単です。
プロアクティブなデータ検証テストは、動きの速いチームが効率的に運営できる最良の方法の 1 つです。 これにより、迅速な反復が可能になり、データのドリフトやその他のダウンストリームの問題を回避できます。
プロアクティブなデータ検証により、後でつぶさなければならないバグの数を最小限に抑えながら、必要に応じてコードを変更および更新する自信が得られます。この積極的なプロセスにより、あなたとあなたのチームは、関心のあるデータに直接関連するコードのみを変更することができます。

プロアクティブなデータ検証が重要である理由を確認したので、次の質問は次のとおりです。どのように行うのですか? 問題が発生する前にデータが適切であることを確認するためにチームが採用しているツールと方法は何ですか?

飛び込みましょう。

データ検証の方法

データの検証は、特定の時点で行われる単なる 1 つのステップではありません。データライフサイクルの複数のポイント (クライアント、サーバー、パイプライン、またはウェアハウス自体) で発生する可能性があります。

これは、多くの点で大規模なソフトウェアテストに非常によく似ています。ただし、重要な違いが 1 つあります。出力だけをテストしているわけではありません。また、データの入力が正しいことも確認しています。

それぞれの場所でデータ検証がどのように行われているかを見てみましょう。

クライアントでのデータ検証手法

Amplitude Data などのツールを使用して、タイプセーフ、単体テスト、リンティング (静的コード分析) を利用して、クライアント側のデータ検証を行うことができます。

さて、これは素晴らしい出発点ですが、この種のツールがこの層でどのような種類のテストを可能にするかを理解することが重要です。内訳は次のとおりです。

タイプセーフとは、コンパイラがソースでデータ型と実装命令を検証し、入力ミスや予期しない変数によるダウンストリームエラーを防止することです。
単体テストとは、特定の選択したコードを分離してテストすることです。 残念ながら、ほとんどのチームは、分析の検証に関して、分析を単体テストに統合していません。
A/B テストは、ゴールデン状態のデータセット (完全であることがわかっている分析のバージョン) または運用データのコピーに対して分析フローをテストする場合です。これは、行っている変更が適切であり、既存の状況を改善しているかどうかを判断するのに役立ちます。

パイプラインでのデータ検証手法

パイプラインでのデータ検証とは、クライアントから送信されるデータがウェアハウスのデータ形式と一致することを確認することです。この 2 つが同じページにない場合、データの利用者 (プロダクトマネージャー、データアナリストなど) は、反対側で有用な情報を得ることができません。

パイプラインのデータ検証メソッドは次のようになります。

イベント追跡がスキーマレジストリで定義されているものと一致することを確認するためのスキーマ検証。
プラットフォーム間の追跡が適切に機能することを確認するために、dbt などのツールでのリレーショナル、一意、および代理キーユーティリティテストによる統合とコンポーネントのテスト。
dbt などのツールを使用した鮮度テストにより、ソースデータがどの程度「新鮮」であるか (つまり、どの程度最新で健全であるか) を判断します。
データセットやサンプルが予想される入力と一致しない場合にアラートを受け取り、追跡に加えられた変更が既存のデータストリームを台無しにしないことを確認する、Great Expectations などのツールを使用した分布テスト。

倉庫でのデータ検証技術

dbt テスト、Dataform テスト、および Great Expectations を使用して、ウェアハウスに送信されるデータが期待および必要な規則に準拠していることを確認できます。このレイヤーで変換を行うこともできます。これには、これらの変換内での型チェックと型安全性が含まれますが、この方法はリアクティブであるため、主要な検証手法としてはお勧めしません。

この時点で、チームが利用できる検証方法には、データが特定の規則に準拠していることを検証し、それらに一致するように変換することが含まれます。チームは、dbt を使用した関係テストと鮮度テスト、および Great Expectations を使用した値/範囲テストも使用できます。

このツールのすべての機能は、このレイヤーでのいくつかの重要なデータ検証手法に帰着します。

CRUDデータと変換が設定された規則に準拠していることを確認するためのスキーマ化。
データが GDPR などのセキュリティ要件に準拠していることを確認するためのセキュリティテスト。
あるモデルのフィールドが特定のテーブルのフィールドにマップされていることを確認するための dbt などのツールでの関係テスト(別名参照整合性)。
鮮度と配布のテスト(パイプラインのセクションで述べたとおり)。
クライアントから送信されるデータがウェアハウスの想定範囲または形式内にあることを確認する範囲およびタイプのチェック。

Lyft のディスカバリーおよびメタデータエンジンである Amundsen を掘り下げると、これらのテストの多くが実行されている好例を見つけることができます。このツールを使用すると、企業のデータコンシューマーはユーザーメタデータを検索して、使いやすさとセキュリティの両方を向上させることができます。データの品質と使いやすさを保証する Lyft の主な方法は、新しいデータがウェアハウスに追加されたときに古い重複データを削除するグラフクレンジング Airflow タスクによる一種のバージョニングです。

今こそ、より優れたデータ検証手法を採用するときである理由

以前は、組織がデータの衛生とガバナンスの重要性を認識していなかったため、データチームはデータの検証に苦労していました。それはもう私たちが住んでいる世界ではありません。

企業は、データ品質が重要であることを認識するようになりました。リアクティブな方法で不良データをクリーンアップするだけでは十分ではありません。データエンジニアのチームを雇って、変換によってデータをクリーンアップしたり、エンドレスな SQL クエリを作成したりすることは、時間とお金の不必要で非効率的な使い方です。

以前は、80% の精度 (ユースケースに応じてギブオアテイク) のデータは許容されていましたが、許容誤差は 20% でした。これは単純な分析には問題ないかもしれませんが、製品レコメンデーションエンジンの強化、異常の検出、ビジネスや製品に関する重要な意思決定には十分ではありません。

企業はエンジニアを雇って製品を作り、素晴らしい仕事をします。不良データの処理に時間を費やさなければならない場合、その時間を最大限に活用していません。しかし、データの検証により、組織に価値を創造するという最も得意なことに集中するための時間を取り戻すことができます。

良いニュースは、高品質のデータが手の届くところにあるということです。それを達成するために、企業は、データの生産者とデータの消費者の間のサイロを打破することによって、誰もがその価値を理解できるようにする必要があります。その後、企業はスプレッドシートを破棄し、バージョン管理やスキーマ化など、より優れたエンジニアリングプラクティスを分析に適用する必要があります。最後に、追跡とデータガバナンスの計画を立てて、組織全体でデータのベストプラクティスに従っていることを確認する必要があります。

プロアクティブな分析検証に投資して、データの配当を獲得する

今日の世界では、反応的で暗黙的なデータ検証ツールと方法ではもはや十分ではありません。時間、お金、そしておそらく最も重要な信頼を犠牲にします。

この運命を避けるために、積極的な哲学を受け入れてください。最初からソフトウェア開発ライフサイクル全体にわたって分析データを検証することで、費用のかかる問題になる前に問題を特定します。