データチームがデータの検証に苦労する理由 (およびそれを変える方法)
公開: 2022-12-19編集者注: この記事は、もともと 2020 年 12 月 18 日に Iteratively ブログで公開されたものです。
「ガベージイン、ガベージアウト」という古いことわざを知っていますか？ おそらく、データ衛生に関連してこのフレーズを聞いたことがあるでしょう。 しかし、データの管理と品質が悪いゴミをどのように修正しますか? まあ、それはトリッキーです。 特に、トラッキング コードの実装を制御できない場合 (多くのデータ チームがそうであるように)。
ただし、データ リードがデータ設計からコミットまでのパイプラインを所有していないからといって、すべての希望が失われるわけではありません。 データ コンシューマー (プロダクト マネージャー、プロダクト チーム、アナリストなど) とデータ プロデューサー (エンジニア) の間の架け橋として、データの検証を開発および管理し、データの衛生状態を全体的に向上させることができます。
雑草に入る前に、データ検証と言うときは、データ チームがデータの品質を維持するのに役立つプロセスとテクニックについて言及しています。
それでは、データ チームがこの検証に苦労している理由と、その課題をどのように克服できるかを見てみましょう。
まず、データ チームがデータの検証に苦労するのはなぜでしょうか?
データ チームが分析のためのデータ検証に苦労している主な理由は 3 つあります。
- 多くの場合、イベント トラッキング コードの実装やトラブルシューティングに直接関与することはありません。そのため、データ チームは多くの場合、分析のためのデータ検証に関する標準化されたプロセスはありません。つまり、テストは一貫性のない QA チェックに翻弄されます。
- データ チームとエンジニアは、事前対応型のデータ検証方法ではなく、事後対応型の検証手法に依存しており、データの衛生上の問題を解決できません。
これら 3 つの課題はどれも、最高のデータ リード (およびそれらをサポートするチーム) でさえも挫折させるのに十分です。 その理由は理にかなっています。質の悪いデータは高価なだけではありません。IBM によれば、質の悪いデータには平均3 兆ドルの費用がかかります。 また、組織全体で、データ自体への信頼が損なわれ、データ チームとエンジニアがバグをつぶすために何時間もの生産性を失うことになります。
物語の教訓は？ データ検証が後回しにされても、勝者はいません。
ありがたいことに、これらの課題は、優れたデータ検証プラクティスによって克服できます。 それぞれの問題点について詳しく見ていきましょう。
多くの場合、データ チームはデータの収集自体を管理していません。
上で述べたように、データ チームがデータの検証に苦労する主な理由は、問題のイベント トラッキングのインストルメンテーションを実行していないことです (せいぜい、問題があることを確認できますが、修正することはできません)。 ）。
これにより、データ アナリストやプロダクト マネージャーだけでなく、意思決定をよりデータに基づいたものにしようとしている人は誰でも、事後にデータを解きほぐし、クリーンアップするというタスクに悩まされます。 そして、気晴らしにデータ変更を楽しんでいる人は誰もいません。
この問題点は、ほとんどのデータ チームにとって克服するのが特に困難です。エンジニア以外のデータ名簿には、データ検証を自分で行うための技術的スキルを持っている人がほとんどいないためです。 データ プロデューサーとデータ コンシューマーの間の組織的なサイロは、この問題点をさらに敏感にします。 それを軽減するために、データ リードはチーム間のコラボレーションを促進して、クリーンなデータを確保する必要があります。
結局のところ、データはチーム スポーツであり、プレーヤーが互いに話したり、一緒にトレーニングしたり、より良い結果を得るためにより良いプレーをブレインストーミングしたりできなければ、ゲームに勝つことはできません.
データのインストルメンテーションと検証も同じです。 データ コンシューマーは、データ プロデューサーと協力して、テストを含むデータ管理プラクティスをソースに配置して実施する必要があります。これにより、誰かがダウンストリームで変更を行う前に、データに関する問題をプロアクティブに検出できます。
これにより、次のポイントに進みます。
多くの場合、データ チーム (およびその組織) には、分析のためのデータ検証に関するプロセスが設定されていません。
エンジニアは、コードのテストが重要であることを知っています。 誰もがそれを好むとは限りませんが、アプリケーションが期待どおりに動作することを確認することは、優れた製品を出荷するための重要な部分です。
分析コードが意図したとおりにイベント データを収集して配信することを確認することも、優れた製品を構築して反復するための鍵となります。
では、どこが切断されているのでしょうか。 分析データをテストする手法は、エンジニアリング チームやデータ チームにとってまだ比較的新しいものです。 多くの場合、分析コードはコア機能ではなく機能へのアドオンと考えられています。 これは、精彩を欠いたデータ ガバナンス プラクティスと相まって、全体的に散発的に実装されている (またはまったく実装されていない) ことを意味する可能性があります。
簡単に言えば、これは多くの場合、データ チームの外部の人々がまだ日常業務にとってイベント データがどれほど価値があるかを理解していないためです。 彼らは、クリーンなイベント データが裏庭の金のなる木であり、定期的に水をやる (検証する) だけで銀行を儲けることができることを知りません。
イベント データである金のなる木を管理する必要があることを全員に理解させるために、データ チームは、十分に検証されたデータを組織全体で使用できるあらゆる方法を広める必要があります。 データ チームは組織内で制限されサイロ化されている可能性がありますが、データ品質を向上させるための適切なプロセスとツールが配置されていることを確認するために、データ チャンピオンと他の利害関係者の間の壁を壊す作業を最終的に行うのは、これらのデータ チャンピオンです。
このようなデータ管理のワイルド ウェストを克服し、適切なデータ ガバナンスを確保するために、データ チームは、いつ、どこで、どのようにデータを事前にテストする必要があるかを明確にするプロセスを構築する必要があります。 これは困難に聞こえるかもしれませんが、実際には、データ テストは既存のソフトウェア開発ライフ サイクル (SDLC)、ツール、CI/CD パイプラインにシームレスに組み込むことができます。
データ戦略を設計するデータ チームと、コードを実装してテストするエンジニアリング チームの両方に対する明確なプロセスと指示は、期待されるアウトプットとインプットを全員が理解するのに役立ちます。
データ チームとエンジニアは、プロアクティブではなくリアクティブなデータ テスト手法に依存しています
人生のほぼすべての場面で、受動的であるより積極的である方がよい。 これは、分析のためのデータ検証にも当てはまります。
しかし、多くのデータ チームとそのエンジニアは、反応的なデータ検証手法にとらわれていると感じています。 プロアクティブなテストを容易にする強固なデータ ガバナンス、ツール、およびプロセスがなければ、多くの場合、イベント トラッキングを実装してリリースに含める (または 1 つの出荷後にさかのぼって追加する) 必要があります。 これらにより、データ リードとそのチームは、事後に異常検出やデータ変換などの手法を使用する必要があります。
このアプローチでは、不良データの根本的な問題が解決されないだけでなく、データ エンジニアがバグをつぶすのに何時間も費やすことになります。 また、アナリストは不適切なデータを削除するために何時間も費やす必要があり、データが改善されていれば実現できたであろうすべての製品の改善による収益を失うことになります。
データ リードは、常にデータをキャッチアップするのではなく、早い段階でプロアクティブなテストを含むデータ管理プロセスを形成し、型の安全性などのガードレールを備えたツールを作成して、データ品質を向上させ、後工程での再作業を減らす必要があります。
では、プロアクティブなデータ検証手段とは何ですか? 見てみましょう。
データ検証の方法と技術
プロアクティブなデータ検証とは、データ パイプラインの各段階で適切なツールとテスト プロセスを採用することを意味します。
- 型安全性、単体テスト、A/B テストを活用するための Amplitude などのツールを備えたクライアント。
- スキーマ検証用の Amplitude、Segment Protocols、Snowplow のオープンソース スキーマ リポジトリ Iglu などのツールのほか、統合およびコンポーネント テスト、鮮度テスト、配布テスト用のその他のツールを使用したパイプライン。
- dbt、Dataform、Great Expectations などのツールを備えたウェアハウスで、スキーマ化、セキュリティ テスト、関係テスト、鮮度と分布のテスト、範囲と型のチェックを活用します。
データ チームは、積極的に積極的にデータ検証手段を維持し、実施することで、収集されたデータが有用で、明確で、クリーンであることを保証し、すべてのデータ所有者がそれを維持する方法を理解していることを確認できます。
さらに、データ収集、プロセス、およびテスト手法に関する課題は、単独で克服するのが難しい場合があるため、リードがデータ チームとエンジニアリング チームの間の組織のサイロを打破することが重要です。
より良い分析のためにデータ検証を変更する方法
分析のための機能的なデータ検証プラクティスへの第一歩は、データがチーム スポーツであることを認識することです。それは、データ リードであるあなたであろうと、一連の追跡コードを実装する個々のエンジニアであろうと、あらゆるレベルのデータ所有者からの投資を必要とします。
クライアントから倉庫まで、組織内のすべての人が、優れたデータ収集とデータ検証から恩恵を受けます。
これを推進するには、次の 3 つのものが必要です。
- ビジネス全体でデータを維持および使用するためのプロセスを確立する、データ リードおよび企業のリーダーシップからのトップダウンの指示
- 会社のすべての階層でのデータ エバンジェリズムにより、各チームは、データが仕事の改善にどのように役立つか、および定期的なテストがこれをどのようにサポートしているかを理解できます。
- 内部ツール、Segment Protocols や Snowplow と dbt などのツールの組み合わせ、さらには Amplitude などの組み込み分析プラットフォームなど、データを適切に管理するためのワークフローとツール。 これらの各ステップを通じて、データ リードが勝利を分かち合い、優れたデータに向けて早期かつ頻繁に前進することも重要です。 この透明性は、データの消費者がデータをより適切に使用する方法を理解するのに役立つだけでなく、データの作成者 (たとえば、テストを行うエンジニア) が自分の労力の成果を確認するのにも役立ちます。 それは双方にとって好都合です。
データ検証の問題を克服する
データの消費者は実装を制御できず、データの作成者は実装が重要な理由を理解できず、断片的な検証手法では誰もが悪いデータを防ぐのではなく反応することになるため、データ チームにとってデータの検証は困難です。 しかし、そうである必要はありません。
データ チーム (およびそれをサポートするエンジニア) は、協力し合い、優れたデータの機能横断的な利点を取り入れ、データの管理とテストを容易にする優れたツールを活用することで、データ品質の問題を克服できます。
