データ品質の向上: Lyft とのデータ契約の検討

データ品質に関する私のシリーズのパート 2 のようです。

前回の投稿では、インセンティブを通じてデータ品質を向上させるAirbnbの戦略について考察しました。データ作成者と消費者の間に共通の理解を確立するために、単一スコアと明確なスコア基準を実装し、真の当事者意識を育みました。

現在、Lyft は独自のアプローチを採用しており、同じことを別の方法で試みるのではなく、データ品質のさまざまな側面に焦点を当てています。そして、Lyftの戦略はAirbnbの取り組みを補完するものである。私はAirbnbのDQスコア（または類似のスコア）を、データ品質を向上させるためのさまざまな試みを統合する効果的な手段だと考えていますが、Lyftは別の角度からこの課題に取り組んでいます。

Airbnb の DQ スコアは、データ品質を具体的に視覚化するための貴重なツールとして機能します。基本的に、データ品質を向上させる取り組みは、このスコアに明らかな影響を与える必要があります。一方、Lyft は、特定の品質基準に照らしてデータをテストおよび検証することで、品質を積極的に向上させる可能性のある取り組みの 1 つを示しています。

基本的に、これはデータ品質ライフサイクルの異なる点です。品質を向上させる仕組みを導入するには、最初に品質を測定する能力が必要です。

そのため、 Airbnbはデータ品質の測定と観察に重点を置き、この品質を高めて「見栄えをよくする」というプロデューサーの関心に依存していますが、Lyft は異なるアプローチを採用しています。 Lyft は、データ品質の積極的なテストと検証に重点を置き、生産者と消費者の両方に品質を効果的に改善および管理する手段を提供します。

これらのアプローチを総合すると、ライフサイクル全体を通じてデータ品質に対処し、向上させるための包括的な戦略が提供されます。

このため、私は Lyft のアプローチを詳しく調べることに特に興味を持っていました。

私が興味をそそられたもう 1 つの要因は、テスト、より具体的には契約テストです。これは、マイクロサービス アーキテクチャの出現により、基本的なソフトウェア エンジニアリングで長年使用されてきました。ただし、データ コントラクトは、データ エンジニアリングの分野では比較的最近のものであり、高品質のデータ パイプラインを構築するための頂点、または最終的なステップの 1 つとみなされています。これが、Lyft のアプローチをより詳細に調査し、いくつかの潜在的な類似点を探りたいと思った理由です。

前述したように、Airbnb と Lyft が採用したアプローチは補完的であり、データ品質の向上という同じ目標の達成を目指しています。

Airbnb は、データ品質の 4 つの異なる側面の測定と強化に焦点を当てた DQ スコアを開発しました。

DQ スコアには、完全なカバレッジ、自動化、実用性、多次元性、進化可能性などの指針があります。これには、精度、信頼性、管理性、使いやすさなどの側面があります。

Lyft の Verity は、 5 つの次元にわたってデータ品質を向上させるように設計されたプラットフォームです

データ品質を、データが意図したとおりにどの程度使用できるかを示す尺度として定義し、セマンティックな正確性、一貫性、完全性、一意性、整形式性、適時性などの側面をカバーします。

Lyft の Verity によって改善された 5 つのデータ品質の側面と、Airbnb の DQ スコアによって測定された 4 つのデータ品質の側面の間で類似点を描くのは簡単です。たとえば、適時性などの側面は確実に DQ スコアの信頼性に寄与しますが、精度はデータの意味論的な正確さ、完全性、一意性に依存します。一方、ユーザビリティ スコアは、他の要素の中でも特にデータの一貫性に影響されます。

Lyft の Verity は、意味の正確さ、一貫性、完全性、一意性、整形式性、および適時性に関するチェックの定義に重点を置いています。 Airbnb の統一 DQ スコアは、さまざまな側面を通じてデータ品質を評価することに重点を置いているのに対し、これはテストファーストと検証のアプローチに従っています。

DQ スコアをこの最後のスキーマに組み込みたい場合は、アラート/デバッグ ステップの側に含めることになります。

Airbnb の DQ スコアは、さまざまなシグナルを使用して、正確性、信頼性、管理性、使いやすさの側面全体のデータ品質を評価します。

また、より直接的に品質を測定する一連の入力シグナル (Midas 認証、データ検証、バグ、SLA、自動 DQ チェックなど) もありましたが、他のシグナルは品質の代理に近いものでした (例: 有効な所有権、適切なガバナンスの衛生状態、舗装されたパスツールの使用）。

前述したように、Airbnb の DQ スコアと Verity の間には重複がある可能性があります。 Airbnb が測定とスコアリングを重視してデータ品質を右に推し進めることに重点を置いているのに対し、Lyft の Verity は、チェック定義の構成、テスト、検証プロセスを左にシフトし、データ品質のプロアクティブな改善を強調するという積極的なアプローチをとっています。

さて、私の主な関心は左側、チェック定義の構成、テスト、および検証の側面にあります。

Lyft はデータ品質テストをどのようにプロセスに統合していますか?

まず実行パスを調べてみましょう。

現在、Lyft の Verity は主に、Hive データ ウェアハウスに保存されているデータの品質を確保することに重点を置いています。ただし、将来的には他のデータ ソースをサポートするためにその機能を拡張する計画があります。

彼らは Hive をデータ ワークハウスと呼んでいますが、実際にはハイブリッド データ ストレージ ソリューションとして利用し、構造化、処理、クレンジングされたデータ (シルバー レイヤー) のデータ ウェアハウスとして動作すると同時に、生のイベントのデータ レイクとしても機能することに注意してください。データ（ブロンズ層）。

Hive のデータ品質が低いため、実験メトリクスが汚染され、機械学習機能が不正確になり、エグゼクティブ ダッシュボードに欠陥が生じました。

Verity のチェックを Airflow DAG に統合して、高品質の生データのみが処理され、派生データとして Hive に保存されるようにすることができます。

データの作成者と利用者は、データ品質チェックを定義し、データの作成時または内部で使用される前にデータを検証できます。気流またはフライト。

…

VerityAirflowOperator をブロック方式で使用すると、チェックが失敗したときに DAG を停止し、不正なデータが運用環境に到達するのを防ぐことができます。これは「」を利用します。 ステージ・チェック・交換」パターン: ステージングされたスキーマでデータを作成し、ブロッキング オペレーターでデータを検証し、品質チェックに合格した場合は本番環境にプロモートします。

チェックを手動で実行することも、自動でスケジュールを設定して、生データと派生データの両方を検証することもできます。

Verity Scheduled Check はデータ オーケストレーション エンジンから分離されているため、Airflow または Flyte が完全に停止している場合でも実行されます。これにより、Airflow タスクが実行されなかったためにチェックが警告を発しないという一般的な問題が解決されます。

したがって、チェックをトリガーするには基本的に 3 つの主な方法があります。Airflow DAG の一部として、手動で、または Verity プラットフォーム/UI を通じてスケジュール設定します。

現在のチェックをリアルタイム ストリーミング パイプライン (Flink + Kafka など) に統合して、たとえばデータが Hive に入るとき (またはそれ以前) に検証できるとは思いません。

このタイプのリアルタイム チェックを実装すると、不一致を迅速に検出できるようになり、ストレージと処理のコストが削減され、全体的なデータ品質が向上します。

厳密に言うと、Verity チェックは API サーバーを通じて管理されており、一部の API を通じてプログラムでチェックをトリガーするために使用できます。

Verity API サーバー— このサービスは、チェックの実行およびその結果の永続化と取得に関するすべての外部 API を処理します。 API サーバーはチェックを実行せず、チェック キューにメッセージを書き込みます。 SimpleQueueService (SQS)。

そのため、おそらく、ストリーミング ジョブから、または Hive 変更データ キャプチャ (CDC) と統合することで、長期的にはこれらのジョブをよりリアルタイムにトリガーできる可能性があります。

ただし、Airflow の外部で実行された場合、これらのジョブはデータ処理ジョブをブロックできません。代わりに、チェック キューにプッシュされる非同期アラートを生成します。一部の消費者は、チェックが失敗した場合にデータ処理を遅らせたいと考えていますが、他の消費者はむしろ続行してアラートを受け取りたいと考えています。

次に、これらのデータ品質テストを見てみましょう。

以下は、 rider_events.session_id null でないことを確認する例です。これは、クエリと条件コンポーネントの組み合わせによって実現されます。

 core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]

Verity は、完全なデータ スキーマの定義ではなく、データ品質チェックの定義と実施に主に重点を置いています。

スキーマ検証は新しい概念ではありません。 JSON スキーマ、プロトコル バッファー、Avro、または Parquet などのストレージ形式など、イベントベースのシステムでイベント データ スキーマを定義するためのいくつかの方法が存在します。最適な選択は、技術スタック、用途、特定の要件によって異なります。

データ スキーマは、データ オブジェクトやテーブル行の全体的な構造を定義するのに役立ちますが、データ分散、ビジネス ルール、SLA、しきい値など、消費者に固有のより高度な検証チェックを取得するには不十分です。

データ コントラクトは、構文エラーの特定に焦点を当てたスキーマ検証を超えています。私は個人的に、JSON スキーマが、これらの構造的および構文的な検証機能をシリアル化やストレージの問題から効果的に分離する、より適切で読みやすいオプションを提供していると感じています。

ただし、セマンティック エラーに対処し、データの精度を高めるために、データ チェックを定義する効果的な手段があれば、データ コントラクトの別の側面を定義できるようになります。

ここで Verity DSL が活躍します。

データ コントラクトは、意味的な検証を超えて、注目に値するもう 1 つの重要な側面を提供します。

構文の観点から見ると、関与するコンシューマーまたはプロデューサーに関係なく、検証チェックは一貫性を保ちます。一連の検証ルールは特定のコンシューマやプロデューサに結び付けられず、単一のスキーマとして一度だけ定義できます。

ただし、Verity データ コントラクト DSL は、小さな独立したルールを定義するより細かい粒度を提供します。これは、データの意味論的な意味と使用法が特定の消費者によって異なるというこの状況に特に適しています。さらに、すべてのコンシューマーがオブジェクトのすべてのプロパティを利用する必要があるわけではありません。彼らの期待は異なります。これは、それらが矛盾していることを意味するのではなく（確かに問題になるでしょう）、むしろ補完的であり、異なるものであることを意味します。

したがって、すべての消費者が、協力して組み合わせることでデータ品質の意味論的重要性を包括的に理解できる独自のルールを確立できるようにすることが非常に重要です。

そして、私が特に心に響くのは、この協力的な側面です。ご容赦ください、これは言い過ぎのように思えるかもしれませんが、私の観点からは、これは言及する価値があります。 :)

データ交換により、さまざまなチーム (プロデューサーとコンシューマー) が効果的にコラボレーションできるようになります。従来のソフトウェア開発における API と同様に、これらのデータ交換についての共通理解を確立することが最も重要です。マイクロサービス アーキテクチャでは、消費者主導コントラクト (CDC) として知られる共同テスト アプローチが登場しており、消費者はプロデューサーが提供する API の期待される動作を定義します。プロデューサーは、新しいバージョンをリリースする前にこれらの契約を検証する責任があります。

データ契約も同様の協力精神を共有していると思います。データ検証はリリース時ではなく実際のデータに対して実行され、リリースをブロックしませんが、協力に基づいており、データ作成者と利用者間のチームワークを促進します。私は、この協力的なアプローチがデータ品質を向上させるための鍵であり、プロセスにさらに統合されるべきであると強く信じています。

そうですね、私は類似点を描くのが大好きなんです…

実際、この協力的な側面は、Lyft の verity 憲章の一部としても言及されていることに注目してください。

VerityUI は、Verity ホームページを介して合理化されたデータ検出エクスペリエンスを提供します。チェック定義メタデータの全文検索により、ユーザーは現在実施されているすべてのチェックとそのチェック結果を確認できます。これには、所有チーム、テーブル名、タグなどの便利な集計が含まれています。

データ契約の問題が Verity プラットフォーム UI を通じて消費者と生産者の間でどのように共有されるかについては完全に明確ではありませんが、ダッシュボードを通じたコラボレーションの重要性は間違いなく認識しています。

• データ製品インターフェイスの作成者は、予期せぬダウンストリームの破損を不用意に引き起こしていないことを自信を持って保証できます。

• インターフェースの利用者は、インターフェースへの依存が損なわれず、今後も損なわれないことを安心して得ることができます。

Verity はデータ品質チェックを定義するための優れたツールですが、残念ながらオープンソースではありません。

幸いなことに、同様の機能を提供する Soda Core と呼ばれる別のオープンソース データ品質フレームワークがあります。

Soda Core は、データ エンジニアがデータ品質をテストできるようにする、無料のオープンソース コマンドライン ツールおよび Python ライブラリです。ユーザー定義の入力を利用して SQL クエリを生成し、データ ソース内のデータセットのチェックを実行して、無効なデータ、欠落しているデータ、または予期しないデータを見つけます。チェックが失敗すると、チェックで「不良」と定義したデータが表面化します。

データセットのスキャン中に、Soda Core は事前定義されたチェックを評価して、無効なデータ、欠落しているデータ、または予期しないデータを特定します。

以下は、以前に定義された Verity DSL テストの Soda.core 構文を使用した同等のチェックです。

 name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."

 soda run --check checks/rider_events_session_id_check.yaml

Soda Core は、データの品質を確保するための強力なツールです。ビジネスに問題が生じる前に、データの問題を早期に特定して修正するのに役立ちます。

Soda Core は Spark DataFrame とシームレスに統合することで、ストリーミング データのデータ品質チェックも容易にできることは注目に値します。

Verity の Hive 用のデータ品質チェックは静的データセットに適用されますが、ストリーミング データのチェックはより軽量で効率的である必要があります。

データは通常、非常に低い遅延で小さなイベントのバッチとして処理されるため、リアルタイムのチェックや異常検出などの特定のユースケースに適しています。

最後に、DeeQu、Great Expectations など、利用可能なデータ検証ツールが他にもあることにも触れておきます。

最後に、データ品質の取り組みを強化するために実行できる手順をより明確に理解していただければ幸いです。

データ品質を向上させるための 2 つの異なるアプローチを見てきましたが、それぞれに独自の強みと方法論があります。 1 つは、可視性と可観測性の向上に焦点を当て、データ作成者に品質基準を引き上げる動機を与えます。もう 1 つは、テストと検証を優先したアプローチを通じて品質基準を高めることを優先します。どちらも補完的なものです。

Verity は、データ チェックを定義するための単なるドメイン固有言語 (DSL) ではありません。これは、データ実務者が効果的に共同作業できるようにする一元化されたプラットフォームです。このプラットフォームは、形式、構造、精度などのデータ品質に対する期待を生産者と消費者が一致させるのに役立ちます。

Verity のデータ コントラクト管理機能は、メタデータの管理や検出などのより広範な機能セットと統合することでさらに強化され、より高度なデータ品質のニーズに対応できるようになります。

Airbnb の DQ スコアと同様に、Lyft の Verity は、データ作成者と消費者間の協力的なフィードバック ループを促進します。 Verity は、各チームがデータ品質を管理するよう奨励し、権限を与えることで、データ品質が継続的に向上する支援的な環境を構築します。

この記事は役に立ちましたか?フォローしてくださいリンクトイン、ハッカーヌーン、 そして中くらい！ぜひ👏この記事をシェアしてください！