データ・コントラクトとは

データ・コントラクトとは、データの品質、構造、セマンティクス、可用性を定義する、データ・プロデューサーとデータ・コンシューマー間の正式な契約です。このような契約の作成と施行は、企業がデータ駆動型の意思決定を強化するのに役立ちます。

従来のビジネス契約と同様、データ・コントラクトには、ある当事者から別の当事者に提供される内容を管理する利用規約が含まれます。データ・コントラクトでは、データ品質ルール、スキーマの定義、サービス・レベル契約、データ・プロデューサー情報、サーバー情報などのコンポーネントが含まれます。

しかし、データ・コントラクトが本当に異なる点は、それがコードで書かれていることです。したがって、契約は手動プロセスではなく自動化を通じて実践できます。

データ・コントラクトがデータ・エンジニアリングに与える影響は、アプリケーション・プログラミング・インターフェース（API）がソフトウェア開発に与える影響と比較されてきました。APIはソフトウェア・アプリケーションが相互に通信できるようにするルールを定義し、データ・コントラクトはデータ・コンシューマーがさまざまなソースからのデータを正常に統合して使用できるようにするルールを定義します。

また、APIがソフトウェア開発の生産性を向上させ、イノベーションを加速すると考えられているように、データ・コントラクトの実装が成功すると、企業やデータ・ユーザーにさまざまなメリットがもたらされます。

その中で最も重要なのは、データ・パイプラインの障害の防止です。データ・コントラクトがなければ、データ生産の上流における変更が、下流のユーザーに悲惨な結果をもたらす可能性があります。データ・コントラクトは、このように破壊的変更がデータ・コンシューマーに影響を与える前に確実に特定され、対処されるようにします。

データ・コントラクトのその他のメリットとしては、データ品質、データ・ガバナンス、拡張性の向上が挙げられます。データ・コントラクトはまた、ビジネス・ユーザーが組織全体のデータから価値を見出し、解き放つことを可能にするデータ・プロダクトやデータ・メッシュ・アーキテクチャーの基礎となるサポートを提供します。

データ品質ツールやデータ・ガバナンス・プラットフォームを含む、企業がデータ・コントラクトを定義し施行するのに役立つツールやプラットフォームは数多くあります。

脆弱で破損したデータ・パイプラインは、多くのデータ・エンジニアにとって悩みの種です。ある調査によると、半数以上のエンジニアが、少なくとも月に1回、あるいはそれ以上の頻度で、データ・システムのパイプラインの障害に遭遇していることがわかりました。¹

あるデータ・アーキテクトが指摘するように、パイプラインは「ガムテープと自暴自棄でつなぎ合わされている」ことがあまりにも多いのです。それらが失敗すると、意思決定と人工知能（AI）の取り組みが悲惨な形で損なわれる可能性があります。

データ・コントラクトは、パイプライン障害の頻繁な原因、つまりデータ・プロデューサーとデータ・コンシューマー間の不整合をターゲットにすることで、そのような結果を防ぐのに役立ちます。不整合は、データ作成者が提供する新しいデータが消費者の期待を満たさない場合に発生します。消費者は、ユースケースに適合するために特定のデータ型、スキーマ、その他の制約に依存する可能性があります。

IBMの生涯チャンピオンであるJean-Georges Perrin氏によると、下流の消費者は「見つけたデータの安定性に疑問を抱く」ことがあるのは当然のことです。「信頼を生み出すためには、データ・プロデューサーやデータ所有者は約束を示し、それを保証する必要があります」とPerrin氏は書いています。

データ品質、検証、アクセス、構造などの約束は、データ・コントラクトの履行によって保証できます。データ・プロデューサーとデータ・コンシューマーがデータ要件について連携し、体系化すると、データ品質の問題が下流のワークフローに影響を与える前に防ぐことができます。

データ・コントラクトはAIワークフローにおいて特に顕著なものとして浮上しています。モデルのトレーニングやデータ分析に適切なデータを確保することは、正確な予測に不可欠だからです。

「システムにより良いデータを取り込むので、ゴミを入れてゴミを出すということにはなりません」とPerrin氏は言います。

主にデータ・プロデューサーとデータ・コンシューマーの間の不整合がデータ・コントラクトの必要性を高めるため、データ・エコシステム内でのこれらのグループとその役割の両方を詳しく調べることが役立ちます。

• データ・プロデューサーは、多くの場合、アプリケーションを構築する際にデータを収集して保管するソフトウェア・エンジニアです。多くの場合、このデータには、顧客の注文などのトランザクションのイベントが含まれており、スキーマ、サイズ、コンテンツなどの点で大きく異なる場合があります。²
  
  
• データ・コンシューマーには、技術的なデータ・コンシューマー（データ・エンジニア、データサイエンティスト、およびプログラミング言語を使用してデータを変換および分析し、データ・パイプラインを構築するその他のデータ・チーム・メンバー）と、非技術的データ・コンシューマー（変換されたデータを使用して意思決定を行うビジネス・ユーザー）が含まれます。

データ・コンシューマーは、データを下流で使用できるようにするために、プロデューサーに依存しています。しかし、この依存は、それだけでコンシューマーとプロデューサーの間に強固な関係を確立するわけではありません。これは、プロデューサーが自分たちのアプリケーションに最適な形式でデータを保管する傾向があり、下流のコンシューマーのデータ管理ニーズは本質的に焦点の対象外となっているためです。

そのため、ソフトウェア・エンジニアがアプリケーションやコードを更新する際、それらの更新が最終的にデータ・コンシューマーに提供されるデータにどのような影響を与えるかを考慮していない可能性があります。

このような変更が予期せぬものであれば（1,000列のテーブルから1列を削除するという比較的小さな変更であっても）、データ・コンシューマーに混乱が生じる可能性があります。こうしたいわゆる破壊的変更によって、データの流れが中断され、データ・セットの互換性が損なわれる可能性があります。

その結果、スクリプトは失敗し、ダッシュボードは古くなったり不正確になったりします。そして人間とAIエージェントのどちらも、重要な意思決定やオペレーションに必要な信頼性の高いデータを得ることができなくなります。

データ・コントラクトは、データ・プロデューサーとデータ・コンシューマーの間で明確な契約を確立することで、2つのグループを分離するサイロを解消し、不整合を防ぎ、より機能的なデータ・パイプラインをサポートできます。

支持者が指摘するように、データ・コントラクトは暗黙の想定を明示的な保証に変えるものです。データ・プロデューサーがデータ・コンシューマーに提供することと、その提供をどのように達成することが期待されているかを詳細に説明します。データ・コントラクトの主な要素は以下のとおりです。

• 基礎
• スキーマ
• データ品質
• サポート・チャネル
• 料金体系
• チーム
• 役割
• サービス・レベル契約（SLA）
• インフラストラクチャーとサーバー

デモグラフィックとも呼ばれる基礎には、契約に関する一般的な情報が含まれます。これには、一意の識別子、契約バージョン（1.0または2.0など）、契約ステータス（「アクティブ」または「廃止」など）、データの本来の目的、およびデータ使用の法的制限が含まれます。

スキーマ定義は、データがどのように編成されるかを詳述します。ここでは、オブジェクト（テーブルやドキュメントなどのデータ構造）、オブジェクトのプロパティ（テーブル内の列など）、タイムスタンプや文字列の長さの制限などのデータ型が含まれるメタデータを指定します。スキーマを管理するための一元化されたリポジトリであるスキーマ・レジストリーは、データ・コントラクトのサポートに役立ちます。

データ・コントラクトは、高品質のデータを保証するためのルールとパラメーターを定義します。精度、完全性、妥当性、null数など、複数のデータ品質メトリクスに対応できます。さらに、カスタムルールでは、データ品質ツールによる品質チェックが可能です。

データ・コントラクトには、データ・コントラクトに関するサポートを必要とするデータ・コンシューマーのために、Slackチャネル、Teamsチャネル、Discordチャット、Eメール配信リスト、Webサイトなどのサポート・ソースを記載することができます。

データ・コントラクトの料金体系セクションには、データ・コンシューマーがデータ・プロダクトに対して請求する金額がリストされています。これには、使用されている通貨と、コストの計算に使用できる測定単位（メガバイトやギガバイトなど）を含めることができます。

一部の古いデータ・コントラクト・テンプレートでは「利害関係者」と呼ばれるデータ・コントラクトのチーム・セクションには、データを所有するチームのメンバーと、データ・コントラクトとの関係に関する情報が含まれています。

データ・コントラクトのロール・セクションには、データ・コンシューマーにデータ・セットに対するさまざまなタイプのアクセス（読み取りアクセスや書き込みアクセスなど）を提供するロールがリストされています。

データ・コントラクトには、プロバイダーが達成すると期待される性能のレベルを定義するサービス・レベル契約の説明も含まれます。たとえば、SLAセクションには、データが利用可能になる時期や保持期間についての保証が記載される場合があります。

データのサーバーを指定することで、Kafka、Microsoft SQL、Google BigQuery、IBM Db2などをデータ・コンシューマーに検出可能にし、アクセスを自動化するために必要な情報をプラットフォーム・エンジニアに提供できます。このセクションには、開発環境や本番環境など、さまざまな環境に関する情報を含めることもできます。

利害関係者は、コアとなるデータ・コントラクト値に加えて、特定のニーズに合わせて、データ・コントラクトにカスタム・プロパティーを追加できます。一般的なデータ・コントラクトテンプレートの最近のバージョンには、プロパティ間の関係を文書化する機能、外部契約を参照する機能、一貫した品質チェックのための事前定義されたデータ品質ルールのライブラリにアクセスする機能も含まれています。

データ・コントラクトは、平易な言葉で書かれていないという点で、他の契約とは大きく異なります。むしろ通常は、人間や機械が読み取り可能なデータ・シリアライズ言語であるYAMLまたはJSONで記述されます。（シリアライズ言語のコーディングに不慣れなユーザーのために、データ・コントラクトはExcelで作成し、オープンソースのツールである Data Contract CLIを通じて YAMLファイルに変換することができます。）

シリアライズ言語でデータ・コントラクトを記述することの利点は、手間のかかる手動プロセスの代わりに自動化が可能なことです。機械で読み取り可能なデータ・コントラクトは、データ・プラットフォームや執行ツールに統合できます。組織はこれらのソリューションを導入して、データ・セットがデータ・コントラクトのルールに準拠しているかどうかをテストできるため、パイプラインの障害が発生する前に問題に対処できます。

多くのデータ・コントラクトは、 オープン・データ・コントラクト標準（ODCS）に基づいています。その名の通り、ODCSはデータ・コントラクトの標準化のためのオープンソースのフレームワークです。この標準は、Apache 2.0ライセンスに基づくLinux Foundation AI & Dataサンドボックス・プロジェクトであるBitolによって定義され、GitHubで入手できます。

この取り組みの支持者は、この取り組みにより、組織がベンダー・ロックインのリスクを負わずにデータ・アーキテクチャーをサポートするデータ・コントラクトを実装できるようになり、イノベーションが促進されると述べています。

データ・コントラクトは、データ・パイプラインの複数の問題点に対処し、組織がデータ資産から価値を解き放つ道を切り開くことができます。データ・コントラクトには、次のようなメリットがあります。

データ・コントラクトは、データ・プロダクトやデータ・メッシュに関する議論でよく言及されます。これには理由があります。データ・コントラクトは、これら両方のテクノロジーをサポートする上で重要な役割を果たすからです。

まずはデータ・プロダクトから見ていきましょう。データ・プロダクトは、 データ、メタデータ 、セマンティクス、テンプレートを組み合わせてさまざまなビジネスのユースケースをサポートする、再利用可能な自己完結型パッケージです。データ・コントラクトは、データ・プロダクトの「品質管理」の役割を果たし、データの一貫性、信頼性、フォーマットが正しいものであることを保証します。

データ・プロダクトとデータ・コントラクトの関係を家族の関係にたとえてPerrin氏は表現しています。「データ・コントラクトとデータ・プロダクトは切り離せないいとこのようなもので、常に協力し合い、足並みを揃え、物事が円滑に進むようにします。」

データ・プロダクトのためのデータ・コントラクトの重要性は、データ・メッシュの機能にとっても重要なものになっています。データ・メッシュとは、マーケティング、セールス、カスタマー・サービスといったビジネス・ドメインごとにデータを整理する分散型 データ・アーキテクチャーのことです。

データ・メッシュ・アーキテクチャーでは、ドメイン・データ・プロデューサーは、ビジネス・ユーザーが組織のさまざまな部門からデータを検索して使用できるようにするデータ・プロダクトを使用します。そのため、データ・コントラクトがデータ・プロダクトの性能を保証すると、データ・メッシュ全体での成功がサポートすることになります。

書籍『Data Contracts』では、データ専門家のChad Sanderson氏、Mark Freeman氏、B.E. Schmidt氏が、データ・コントラクトの仕組みについて、以下のプロセスを詳述しています。³

• データ・コンシューマーは、ビジネス目標を達成するために必要なデータを特定します。
  
  
• 技術的なデータ・コンシューマーは、ビジネス要件をデータの技術要件に変換します。
  
  
• データ・コンシューマーは、これらの要件に基づいてデータ・プロデューサーにデータ・コントラクトをリクエストします。
  
  
• データ・プロデューサーは、リクエストが実行可能かどうかを判断します。
  
  
• データ・コントラクトはYAMLなどのコードで記述されます。
  
  
• データ・プロデューサーは、データ・アセットを変更する必要がある場合に、プル・リクエスト（リポジトリーへの変更を提案する方法）を作成します。
  
  
• 要求された変更に対してデータ・コントラクト・ベースのチェックが、CI/CDパイプラインの一部として実行され、契約条件に違反していないことを確認します。
  
  
• 変更が契約に違反した場合、データ・プロデューサーにアラートが送られ、違反に対処するための措置が講じられます。

組織は、データ・コントラクトを作成および管理するために、さまざまなツールとプラットフォームから選択できます。これには以下が含まれます。

• Apache AvroやGoogle Protocol Buffers（protobuf）など、データをシリアライズおよびデシリアライズするオープンソース・プロジェクト
  
  
• Great ExpectationsやdBTなどのデータ品質およびテスト・ツール
  
  
• スキーマの互換性を確認するための、Confluentのレジストリーなどのスキーマ・レジストリー
  
  
• データ・リネージュ追跡やデータ・カタログなどの機能を備えたデータ・ガバナンス・プラットフォーム

組織固有のニーズと既存のデータ・スタックは、データ・コントラクトをサポートするのに最適なデータ・コントラクト・ソリューションまたはソリューションの組み合わせを判断するのに役立ちます。