はじめに（翻訳者から）
こんにちは、primeNumberマーケティングチームの齋藤です。
みなさまは、「Data Contract（データコントラクト）」という概念をお聞きになったことはございますか。
データの「コントラクト(契約)」とは一体どういった意味でしょうか。
本日ご紹介するChad Sandersonさんの記事では、この「データコントラクト」の重要性について解説しています。
ここで取り扱われるデータコントラクト(データにまつわる契約(合意))は、社内でデータのガバナンスをきかすためのさりげない仕組みです。
ユーザーによって自由奔放に活用されうるデータ。時にはデータチームが想像しなかったような使われ方をしていることもありそうです。
データを全社で活用していく際の統制をきかせるには、どのような仕組みを取り入れられるでしょうか。
今回紹介する「データコントラクト」の考え方から、ヒントを得ていただければ幸いです。
少し長めの記事ですが、ぜひ最後までお付き合いください。
目次
推奨される読者
- 「データコントラクト」というコンセプトについて知りたい方
- 基盤のデータ品質の統制に課題を抱えているデータチームの方
- 基盤にあるデータの使い方に関して、社内のルール制定に興味のある方
この記事は、Chad Sanderson氏のこちらの記事(↓)を許諾のもとで翻訳したものです。
The Rise of Data Contracts
And Why Your Data Pipelines Don’t Scale
Coordinated and reviewed by Brett Torenvlied of primeNumber, Inc.
データ分析基盤総合支援SaaS trocco®︎は、データエンジニアやアナリストの負担を減らすための機能が充実したツールです。ぜひ、LPから機能面をチェックして無料トライアルで触ってみていただけますと幸甚です。
前置き
👋 こんにちはみなさん、僕のニュースレターを購読してくださっている方は有難う。
僕はチャド・サンダーソン (Chad Sanderson) といいます。
データ、データプロダクト、データモデリング、そしてデータエンジニアリングの未来とデータアーキテクチャについて記事を執筆しています。
今日は僕が最も好きなトピックの一つである「Data Contract (データコントラクト)」について取り上げた記事です。
データコントラクトとは何であり、どんな課題を解決するのか？データコントラクトという概念をどのように活用したら良いのかについて解説していきます。
もしまだ僕のニュースレターに登録していない方がおられたらぜひ購読をご検討ください。僕と繋がりたかったらLinkedInで声をかけてください。そして、SlackコミュニティであるData Quality Campに参加して、実務家からのデータコントラクトやデータクオリティ(品質)に関する豊富なアドバイスをチェックしてみてください！
Garbage In / Garbage Out “ゴミを入れたらゴミが出てくる”
もしあなたがコンピューターサイエンス、数学、もしくはデータの業界で働いたことがあれば、恐らくこのフレーズをきいたことがあるはずだ。
「Garbage In, Garbage Out (GIGO). “ゴミを入れたら、ゴミがでてくる。」
GIGOが言い表すのは「インプットのクオリティがアウトプットのクオリティを決める」ということだ。
シンプルで明白で、僕が好きなタイプのフレーズだ。
GIGOのコンセプトについてはほぼ世界共通で頷けるところだと思うが、現代におけるデータチームのほとんどが根源のデータソースからデータの品質問題に苦戦している。
モデルを崩壊させるようなパイプラインの失敗、NULL値、頭をかきむしりたくなるようなエラー、そしてデータ消費者からの怒りは、もはや週単位の日常茶飯事と言ってもいい。そしてデータエンジニア組織は、その板挟みとなる。
この問題は、初期段階のデータチームに限って発生することではない。
僕はテクノロジーによって企業のビジネスや業務を推進してきたエンタープライズ規模のデータ組織、レガシー企業、モダンデータスタックを採用するトップ企業と話してきたが、全てのケースにおいてGIGOへの対処に手間取っているという課題が顕在化していた。
僕が信じるところでは、データコントラクトこそ、プロダクションレベルのデータウェアハウスを構築するのに鍵となるコンセプトだ。
データコントラクトはデータの生産者と消費者の間に存在するサイロを打ち破ってくれる。
それにしても、データコントラクトとは何で、どうしてそれがあなたに必要なのであろうか？
「#ProblemsNotSolutions (解決ではなく課題に着目せよ)」の精神にのっとって、今世界がどうなっているか理解するところから始めよう。
ELT、意図しないAPI、存在しない合意
現代において、エンジニアは運用におけるユースケース(operational use cases)以外において自分たちが生産するデータの品質についてオーナーシップを握る動機(インセンティブ)を有していない。
これは彼らのせいでは無い。エンジニアは今、分析やMLといった断面から完全にかけ離れた場所にいる。
プロダクトマネージャーは、データチームに対して分析的なニーズに基づいてアプローチをかけてくる。そしてデータチームはSQLやPythonで仕事をするよう鍛えられてきた。重厚な要件定義やSLAを上流の生産者に提示するための鍛錬ではなかったのだ。
モダンデータスタックは、サービス/プロダクト側のエンジニアと、分析やML側のエンジニアの間に距離を空けたことで、責任の逆流を生じさせた。
ビジネス上重要な分析に使用されるオペレーショナルデータを生産しているソフトエンジニアと話すと、かなりの割合で、そのデータが扱う顧客が誰なのか、データがどのように使われているのか、なぜそのデータが重要なのか、ほとんど知らないという状況がある。
→どいつか知らんがそのテーブルを削除したやつは我々の価格モデルを破壊したで。
(元記事より)
基幹データベースにETL/CDCツールを接続するというのは、重要なデータを容易かつ迅速にロードするための素晴らしいアイディアに見える。しかし、これは不可避的にデータベースのスキーマを、合意の無いAPIにしてしまうことに等しい。
エンジニアは大抵、ここにあるデータをデータの消費者に提供することに合意していない(し、合意したいと思っていない)。
こうした合意を欠いたまま前に進むと、データは信頼できないものになってくる。
エンジニアはデータに変更をかけていかなる運用上のユースケースに対してもデータを提供できるようにしておきたい。
警告を出すべきケースでも、エンジニアが警告を出すべきだと気づかなかったり、なぜ出すべきなのかわからないから、出されるべき警告がなされないこともあるだろう。
この課題が顕在化するのは、例えば、カラムが上流のプロダクションテーブルから一つ無くなったことにより、企業の収益の80%を作り出す価格決定アルゴリズムが崩壊したりしたときだ。
確かに、より下流でモニタリングを取り入れて、問題を早期に発見するという手段も有効だろう（何が起きてエラーの原因となったかについては不問に終わるが）。しかし、カラムが最初から削除されない方が桁違いに良いのではないだろうか？あるいはデータセットがバージョン管理されていて、下流のチームが移管に備えることができていたら？
今述べたようなことは僕がGIGOサイクルと呼ぶものに結実していく。
GIGOサイクル：
1. データベースが合意無しのAPIと化する(接続し放題の状態)
2. そもそもの合意が無いため、いかなるときにもデータベースに変更をかけられる
3. データ生産者は、データが下流でどのように使われているのか知らない
4. クラウドプラットフォーム(例) Snowflake)が、本番システムとして扱われなくなる
5. 上流で変更が加えられるので、データセットが壊れる
6. 雑然とした状況を整頓するために、データエンジニアが関与せざるをえなくなる
7. データエンジニアが、データ生産者と消費者の間の仲介役として扱われ始める
8. 技術的な負債が素早く積み上がっていく（リファクタリングが唯一の離脱手段）
9. データチームが、より良いオーナーシップとデータの責任者を求め始める
10. クラウド上の重要な本番システム（ML/Finance）がワークしなくなる
11. 見えないエラーが見過ごされると、最末端の従業員に対してSev1(重大度最大)の影響が露骨に出る
12. データの信頼性が無くなる
13. 大企業は、問題を解決するために人力を投下し始める
14. 残った人々は、終わりなき苦戦を強いられる
根本的なデータの問題が大きくなるにつれ、この壊れた信頼性の低いアーキテクチャの上にさらにツールが積み上げられる。
カオス的状況の中で多少の休息にはなるかもしれないが、貧相なクオリティ、データモデリングの欠如、欠損したデータ、そしてひびの入ったオーナーシップのままでは、混沌としてスケーラブルではない基盤基礎ができあがる。
「シンプルなデータパイプライン」から始めた企業は、技術的負債が山積みになるにつれ大惨事を味わう。
データ組織のライフサイクルの初期で最も重要な時期(IPO前もしくはIPO直後)においてデータインフラストラクチャは、ビジネスが抱える最もクリティカルな課題に対して、信用できる答えを提示できないことがある。ML/AIプロジェクトは価値を生み出さず、重要なデータベースが信頼できないという状況だ。
解決策：データコントラクト
データコントラクトは、サービスに責任を持つソフトウェアエンジニアと、ビジネスを理解するデータ消費者の間で交わされる、APIに似た契約(合意)の総体だ。
データコントラクトの目的は、よくモデリングされ、高品質で、信頼に足り、リアルタイムで提供されるデータを創出することである。
データチームが受動的に、本番システムから分析や機械学習に適さない形状で投げ落とされるデータを受け入れるのではなく、データの消費者が、エンティティ、イベント、アトリビュート、オブジェクト間の関係性でできた世界観を反映した内容で、データコントラクトをデザインできるのだ。
この抽象化によりソフトウェアエンジニアは、「データベース/サービス」と「分析/ML的要求」を切り離すことができるようになる。
エンジニアは、データベースに変更を加える際に本番環境を壊すようなインシデントに震え上がらずに済むようになる。データチームは、SQLを使って後付けで、全体像をさかのぼって構築しようとしなくても良くなり、必要なデータを記述することに集中することができる。
例として、僕のチームが機械学習モデルをマネジメントしているとしよう。想像するのは、オークションでの最適な入札価格を予測するために、出荷が確定したある時点のデータを吸収する機械学習モデルだ。
僕らのトレーニングセットは、応札者のサービスからのデータ、荷送人のデータテーブル、そして現在の市場価格を含んでいる。それぞれのデータは、別々のPostgresテーブルに格納されている。
僕らはカラムが削除されることなんて絶対に起きないし、各フィールドの値や、重要なビジネスロジック(例えば、出荷数と出荷機会数は1:1の関係にある)は常に変わらない、と期待している。
もし今挙げたことの一つでも期待から外れれば、僕らのモデルは崩壊し、本番環境にかなりの影響が出る。
データコントラクトは、オペレーショナルデータ(基幹業務のデータ)と、下流にいる分析用途でデータを消費する人間との関係を、ある程度抽象化するために利用することができる。
Convoyでは、Protobuf(内部的なIDF(インターフェース記述言語))に似た技術とKafkaを活用し、エンジニアチームにSDKを提供している。このSDKを使ってエンティティのCRUD(作成(Create)、読み出し(Read)、更新(Load)、削除(Delete))ルールとサービスに特化したイベントを強く型付けされたスキーマとして埋め込めるようにしているのだ。
このモデルを採用することで、エンジニアチームは下流のチームに対してそのチームが望む形式でデータを提供することができる。
データのAPIは、強力なCI/CDと変更管理でバージョニングされている。
内部的なサービスの詳細は、個々人の柔軟性を許容する大きな組織レベルには開示されていない。
データの消費者は、スキーマやプロパティを必要な形式に定義できる。データの生産側から与えられるデータを、ユースケースに対するデータの品質や重要なコンポーネントの欠損が存在するにもかかわらず無理に受容するといったことがなくなる。
なかなか快適な副産物として、スキーマがこうして明確な意味論をもって強く強制されていれば、イベント駆動型のアーキテクチャに対する道が開かれてくれることになる。
しかし、その話はまた別の機会にしよう。
現存しているELT/CDCパイプランはどうなる？
僕がデータコントラクトについてよくきく質問として、「現存しているパイプラインについてはどうしたらいいのか？取り払ってしまうのか？」というものがある。
僕の意見としては、答えは「NO」だ。
データレイクやデータレイクハウスに入っているデータについて確固として存在する２つのユースケースがある。
①データチームは、データのベストな使い方について理解するためにデータを探究する必要がある。
スピード、柔軟性、反復といったことにフォーカスを当てている既存のモダンデータスタックにおいては理想的だ。
データがどういう意味を持つのかについてある程度の共通理解が固まり次第、データチームは運用用途のパイプライン(運用パイプライン)構築を開始する。
②運用パイプラインは、明確なユースケースを持つ。例えば機械学習のモデルを回したり、ファイナンシャルレポートや企業の核となるダッシュボードに使われていたりする。
データはよくモデリングされていなければならず、現実世界の事実に沿ったものであり、データの生産者からデータコントラクトが明示されていなければならない。
そのデータコントラクトは、データの生産者から消費者に対して、データの変更事項に関する情報提供を義務づけたり、運用上のユースケースと分析上のユースケースを分離する「抽象化」を作り出すものである。
運用パイプラインには信頼性があり、高品質で、パイプラインの所有者と責任者が明確であり、データの意味について明確なドキュメンテーションがなされている。
また、ビジネスサイドの人間からもこのパイプラインが活用可能で、時間とともに反復的に開発していくことが可能になっている。
これら２つのユースケースはデータディスカバリー（データの発掘／発見）、MVP(実用最小限)のデータパイプライン構築、検証、デプロイ、プロダクション(本運用)に値する品質のデプロイ(真のデータプロダクトに至るための、開発のワークフロー)、というライフサイクルを描く。(下図)
よくある質問
Q：データコントラクトを作成するために、データの消費者は自分たちが必要とするデータを全て知っておかなければなりませんか？
A：いいえ。サービスとデータの消費者(分析者)の間に、「抽象化(分離)」のレイヤーを置くことで、この二者間に存在するデータコントラクトが時間と共に変化可能だということです。反復的に、逆に戻る互換性もあるということです。
チームにとっては、ビジネスにおけるニーズを迅速に満たすということと同時に、高品質なデータモデリングの余地も残しておくことができます。
Q：データの生産者はデータの消費者の数ごとにデータコントラクトを作成し、複数のコントラクトを管理することが求められますか？
A：いいえ。データの生産者は各エンティティ(CRUD)もしくはイベントごとに単一のデータコントラクトのもとで作業します。データの消費者はエンティティもしくはイベントごとに用意された契約を活用します。
データの消費者は、要求事項の増加に伴い、各データコントラクトに対して変更や修正の要求を出すことになります。
Q：ソフトウェアエンジニアにとって要求が多い話ではないでしょうか？
A：僕の個人的な経験では、そんなことはありません。
データコントラクトを実装するために、シンプルで使いやすいインターフェースがあれば、本番環境のインシデントを回避できるというのは自分たちにとってもビジネスにとっても、あまり手間をかけずに価値が高い取り組みになるはずです。これはROIとして考えてみればとても良質です！
Q：伝統的にデータの生産者は分析的なユースケースに対して拡張を行うことに後ろ向きになりがちです。データコントラクトは何かこの状況に変化をもたらしますか？
A：ソフトウェアエンジニアであれば誰しも、データベースを重要でない情報で、リクエストベースでアップデートしたくはないでしょう。
データコントラクトによる「抽象化」は、リクエストをシンプルにさばく手段を提供します。
次に、カラムレベルのリネージュをソーステーブルに実装することをおすすめします。
こうすることによって、ソフトウェアエンジニアはデータベースへの各変更が、ダウンストリームで流れていくアセットに対してどのような影響を与えているか理解できる方法を得ることになります。
何を扱っているのかの認識無しには、アカウンタビリティを負うのは難しいです。
Q：データコントラクトのような仕組みを、どうやって作ったらいいのか？
A：Convoy Techの公式ブログで記事投稿がある予定ですので、ぜひお楽しみに！
オープンソースツールを活用したデータコントラクトの実装方法について、詳しく解説いたします。
Q：データコントラクトのような仕組みは、高度なデータアーキテクチャを採用することでハンドリングできないのでしょうか？
A：YESでもあり、NOとも言えます。現代のテクノロジー企業において核となる挑戦の一つとして、データアーキテクチャがソフトウェアの急速なイテレーションの犠牲になっているという点があります。
何年に及ぶデータの負債が積み重なり、アーキテクチャを完全にリファクタリングするコストは控えめに行っても企業にとってはチャレンジとなるでしょう。
データコントラクトは、よくモデリングされたデザインを兼ね備えるコアなデータパイプラインの構築を促す仕組みです。
データモデルのアジャイルな開発を容易にしてくれます。
Q：データコントラクトの導入は、どこから始めたら良いでしょうか？
A：僕が推薦するとしたら、最も直近で重要度がSev1もしくはSev2レベルのデータの集合体に対してからでしょう。
上流のソースデータを明確に定義して、データコントラクトのデザインをチェックします。SLAを作り、データコントラクトを影響力の高い一つのユースケースに対して導入します。
データチームが確実にこの計画にオンボーディングしてくれるよう、きちんと根回しもしておきましょう！
もしその他に質問などあれば、ぜひ僕とLinkedInで繋がってコメントを投げてください！
もしこの記事を面白いと感じたら、ぜひ僕の投稿にライクを押して、そして購読者になってくださったらとても嬉しいです！よろしくお願いいたします！
-チャドより
データコントラクトの実装方法
データコントラクトを実際にどうやって実装するかについて興味があれば、ぜひこちらの投稿を参考にしてほしい。
この投稿では、どこから始めるべきかステップを踏んで説明している。(英語)
An Engineer’s Guide to Data Contracts – Pt. 1
Implementing Data Contracts for Entities
https://dataproducts.substack.com/p/an-engineers-guide-to-data-contracts
最後に (翻訳者から)
いかがでしたでしょうか。
翻訳者にとってはかなり難しい内容だったのですが、少しでも頷いていただける部分があれば大変嬉しいです。
最後にChadさんが紹介したご自身の別の記事では、ProtobufやKafkaを用いたより詳細なアーキテクチャ図を見ることができます。
スキーマから逸脱させないガードレールを埋め込むことで、データベースのデータがぐちゃぐちゃにならないよう、整備しています。
Chadさんが「抽象化」という言葉で表現する、データの生産者と消費者の間を取り持つデータコントラクトがどのような仕組みで実装されうるのか興味がある方はぜひこちらの記事もご覧ください。
今回の記事は以上です。
Have a Happy Data Engineering Day!
Credit: Chad Sanderson (https://www.linkedin.com/in/chad-sanderson/)
Thank you for letting us translate this article!!
