📌

Data Contractの概要

2024/04/15に公開

某コミュニティにて Data Contract に関して議論する際に書き下したメモを本記事で公開します。本業でも特にデータプロダクトをビジネスに共有する際に Data Contract に類似する概念の必然性を感じています。

概要

Data Contract (データコントラクト)は、オーナーシップがはっきりしたデータ送付側とデータ受領側の2つの間でデータをやり取りする際に交わされる契約。データ送付側が、データを送付する際に満たすべき要件を記述したもの。記述にはデータスキーマ、品質要件、などが含まれる。Data Contractを満たさないデータは送付できなくする。

以下は、Pay PalのData Contractの例をオープンソース化したもの。実際のData Contractがどういうものか参考になる。あくまでData Contractの内容をスキーマとして表現したものであり、データ品質検証を行うバックエンド部分はOSS化されていない。

PayPal のOSSがLinux Foundationに寄贈され、それをベースにしたOpen Data Contract Standardという標準化が行われている。プロジェクト名はBitol。オープン標準を訴えるブログ記事が出たのが2023年末、ODCSを紹介する記事が出たのが2024年1月。2025年あたり標準に準拠したプロダクトが出始める可能性あり。

https://bitol.io/

Open Data Contract Standard　Getting started with ODCS

類似の概念

Data Contractと類似の概念として、ビジネスの現場でよく見るものとして以下がある。

請負開発の契約書・・・何を持って受け入れとするか、品質要件など細かく決めるはず。
SLA・・・サービスの提供元と提供先の間で交わされるサービスの品質に関する合意事項。可用性を99.99%にするなど。

また、すでに技術の世界で実績があるものとして以下がある。

KafkaのSchema Registry・・・ ProducerがKafkaにメッセージを投げ込む際のスキーマを事前に登録しておく。Producerはメッセージを投げる際にSchema Registryでスキーマを確認して、スキーマ違反だと送信できない。バージョン管理機能がある。品質要件はない。

（先に結論）Data Contractに取り組む際の留意事項

詳細は後述するが、Data Contractそのものより、順番としては、データ品質の問題意識、データのオーナーシップ (= データプロダクト）、それを担保する組織体制を関係者で合意する方が重要。

もしビジネス上重要なドメインで、データ品質上の課題がある場合は、その文脈に沿った形で、課題意識と組織体制を議論することを優先した方が議論がスムーズになる。Data Contractという概念が世間に存在するという話は、体制が固まった後に、手段の話をする際に参考になる概念の1つとして紹介するくらいがちょうど良い。

Data Contractまたはそれに類似する概念を簡易的に実装する際は、最初の一歩としては、Data Contractのスキーマ定義をチームで決めたり、dbtのパッケージやGreat Expectationsのような既存のデータ品質チェックフレームワークで実装するのがちょうど良い。

以下はdbtの機能としてData Contractの類似の概念を実装したもの。model contractと呼ばれている。dbtの世界で実践する場合は、既存の機能を使うと良い。

一方で、Data Contractを一定の規模で実践するには、

データ提供元に契約を強制する仕組み
データプロダクトの契約準拠状況をSLAのような形で利用者に提示すること

が重要になる。Data Contractの考え方が浸透した暁には、このような仕組みを検討しても良いかもしれない。

Data Contractが登場してきた背景

Data Contractという概念を提唱したのは、欧州の決済系サービスGoCardlessのPrincipal EngineerであるAndrew Jones氏。考案者のブログでは、データプラットフォームでのCDC（Change Data Capture）を例に重要性が紹介されている。CDCでは、OLTP DB上の変更をOLAP DBに転送し、データ変換し、モデリングし、分析用途で利用する。一方で、データそのものは、分析用途とは無関係に設計されたものであり、スキーマ変更やマイグレーションなど、ダウンストリームの用途から見ると破壊的変更が行われることがある。この破壊的変更がダウンストリームのパイプライン、レポート、ダッシュボードなどを破壊する可能性がある。

基本的な考えとしては、データの提供元と受領先で契約を明確に結んでおき、それをバージョン管理しておき、両者で合意しておく。データを提供する前に契約への準拠を確認することで、データ提供先への破壊的変更を防ぐ。

CDCを例に挙げたのは、バッチの場合、冪等性が担保されていれば、データ品質を直して再実行して問題を解消できる可能性があるためと考えられる。CDCなど連続的にデータが流れてくる場合、冪等性の担保や再実行が非常に困難であり、粗悪な品質のデータを堰き止める仕組みが重要となるため。

Data Contractの前提

Data Contractを導入する際には一定の前提が存在すると考えられる。

データ品質に対する課題意識が組織内で共有されており、データやその品質のオーナーシップを取る方法が合意形成がされており、組織体制に反映されていることが重要。Data Contractそのものを実際にどう実装するかは、チーム内で既存のツールを使って適度な落とし所を決めることができる。

データ提供元とデータ提供先でオーナーシップがあり、受け入れの要件を合意できる。また、データが実際に受け入れ要件を満たしているか継続的に監視できる体制が存在する。

ELTパイプラインの場合、データ取り込み箇所向けにData Contractを実装する組織が存在する。サードパーティのデータで、データ提供元と直接、契約を結ぶのが難しい場合は、DDDの腐敗防止レイヤーのように生データとデータ活用のレイヤーの間にレイヤーを設け、一定のデータ品質を確保したデータだけ利用できるようにする。

データメッシュアーキテクチャの場合、ビジネスドメインごとにオーなシップがはっきりしており、サービスやデータプロダクトの境界のところで、Data Contractを実装する組織が存在する。

データプロダクトがData Contractに準拠しているかどうかは、データプロダクトのSLAの一部であり、データのオーナシップおよび品質の責任所在がはっきりしないと、このアプローチはそもそも成立しない。これができない場合、ダウンストリームで問題になった箇所を必ずしもビジネスドメインやデータの知識がないデータエンジニアが対症療法的にData Contractのようなものをベストエフォートで実装する構造になるが、機能しないものとなる可能性が高い。

Data ContractのスキーマをOSS化したPay Palは、Data Meshのアーキテクチャを採用しており、各ビジネスドメインごとにデータプロダクトにオーナシップを持ったチームが存在する。データをプロダクトとして使いやすく、信頼性のあるものとして整備する責務を負う。

一般的な企業のデータ品質の対応状況

Data Contractを導入しているケースはあまり公開されていない。

一般的な企業で多い状況としては、何がしかのトランザクション系システム、もしくはサードパーティのシステムがオペレーションを行った結果をそのままELTパイプラインでDWHに取り込んでいき、取り込んだ後でデータ利用者がデータ品質の検証やデータのクレンジングを行う。

データの提供元は、データ品質に責任を負っていない、利用状況に関心がない、利用されていることをよく知らないケースも多い。

データの利用者は、ビジネスの重要な要件に実際にデータを活用する必要があるため、様々な方法でデータの品質に対処する。

データ品質の可視化・・・事前に問題が予見できるものに対するテストとしてdbt testなど。事前に予見できない問題の検出としてData Observarbility。

下流での要件に使いやすい形でデータを整形し、品質を担保した形でエンタープライズデータモデルを整備する。

データの提供と活用までの流れが都市鉱山（スマホなど廃棄された家電）からレアメタルなど価値のあるものを抽出して利益を上げるビジネスのような状況。

データを活用する側にデータエンジニアリングの能力がないため、中央集権的なデータエンジニアリングチームにデータ品質問題に対処するように依頼することが多い。一方で、中央のチームはデータ提供元ドメインの状況を知らないので、品質問題が発生する原因やメカニズムを知ることができない。あくまで対症療法的に処理するだけで、根本的な問題解決は時間がかかるし、難しい。

最後に

今回は Data Contact の概要や登場の背景について紹介しました。次回、機会あれば実際に利用する上で必要な事項について記事にしたいと思います。