Andrew Tanによる
スキーマモニタリングの問題
スキーマモニタリングは破壊的変更を検出するはずですが、実際にはそうではありません。
パイプラインは数ヶ月間問題なく稼働します。そして、上流のサービスがrevenue_v2フィールドを追加します。古いrevenueフィールドはまだ存在しますが、今では非推奨で常にnullです。パイプラインはそのnullを問題なく取り込みます。エラーはありません。すべてのライトが緑です。
ビジネスメトリックが間違っています。
これは、モニタリングが構造的な変更を監視し、意味的な変更を監視しないために起こります。
なぜモニタリングは失敗するのか
ほとんどのチームは、新しいカラム、型の変更、欠落フィールドに対してアラートを設定します。人間がすべてのアラートをレビューします。
50回目の「新しいオプションフィールド」の通知を受け取った後、読むのをやめます。脳が自動承認します。INTからBIGINT？無害です。承認して次に進みます。
本当の問題は見逃されます。上記の問題は構造的ではなく、意味的なものでした。新しいフィールドが現れましたが、安全だと思われていました。古いフィールドは存在していました。破壊的な変更は検出されませんでした。
契約は破られました。誰も気づきませんでした。
モニタリングは事故をキャッチします。あなたが必要なのは嘘をキャッチするものです。
契約対レジストリ
スキーマレジストリは構造をチェックします。フィールド名、型、null許容性。重要ですが、十分ではありません。
データ契約は約束をチェックします。
- 数字を送信しましたか？
- それはあなたが言ったことを意味しますか？
- 正の数ですか？範囲内ですか？参照的に一貫していますか？
REST APIを考えてみてください。JSONが解析されるだけでなく、エンドポイントがドキュメントに記載されていることを確認します。その約束を破ると、JSONが技術的に有効であっても破壊的な変更です。
データパイプラインも同じことが必要です。下流システムは暗黙の約束に基づいて構築されます。それらが破られると、すべてが壊れます。
良い契約の姿
これをうまく行うチームは、すべてのデータセットに対して次の3つのことを定義します：
構造的保証。 しかしひねりがあります：どんな逸脱も破壊的です。新しいオプションフィールド？バージョンアップ。痛そうですが、「ステルス意味的変更」を完全に排除します。
意味的期待。 ビジネスルールとしての検証。患者の年齢は0〜120。診断コードは参照テーブルに存在しなければなりません。タイムスタンプはファイル作成から24時間以内。
消費者のコミットメント。 下流システムは依存関係を宣言します。3つの重要なパイプラインが使用するフィールドを変更しますか？高リスクです。構造的に「安全」に見えても。
スキーマ変更は数日の調整から数時間に短縮されます。静かな意味的ドリフトはゼロに近づきます。
難しいのは組織的な部分
契約はほとんどの人がしたくない会話を強制します。
プロデューサーは完全に制御していないデータについて約束しなければなりません。CRMチームはすべての下流消費者を知りません。モバイルチームはデータサイエンスが彼らのイベントをどのように使用しているかを知りません。
所有権の3つのパターン：
プロデューサー所有。 データを作成するチームが契約を定義します。理論的にはクリーンです。しかし、プロデューサーが利便性のために最適化し、下流のニーズを考慮しないため、しばしば失敗します。
消費者所有。 下流が要件を定義します。消費者を保護しますが、プロデューサーが常に従うことができるわけではありません。紙上での契約が実際には違反されることがあります。
プラットフォーム仲介。 中央チームが会話を仲介します。オーバーヘッドが増えますが、実際に機能します。
四半期ごとのレビューを伴うプラットフォーム仲介は、会議時間において高価です。インシデントと比較すると安価です。
小さく始める
始めるのにプラットフォームは必要ありません。
重要なデータセットに対して次の3つのことを書きます：
これは何を表していますか？ フィールド定義ではありません。ビジネスコンセプトです。「アクティブなサブスクリプションのデイリースナップショット」は「テーブルにはcustomer_id、plan_type、renewal_dateがある」とは異なります。
人々は何を頼りにできますか？ Null許容性、更新頻度、保持。みんなが暗黙的に仮定していること。
それが壊れたときに何が起こりますか？ 誰に連絡しますか？どれくらい早く？ロールバックはどうしますか？
最も重要な3つのAssetsから始めます。それだけです。
契約も問題を引き起こす
それらは硬直化します。契約を変更するには調整が必要です。それがポイントです — 破壊的な変更を防ぎます — しかし良い変更も遅らせます。チームは調整コストのために変更を提案することを避けます。
それらは嘘をつきます。契約はその検証の良さにかかっています。「すべてのcustomer_idが存在しなければならない」と言ってチェックしない？演劇です。誤った信頼はないよりも悪いです。
それらは責任を転嫁します。消費者が違反を検出します。応答：「プロデューサーが約束を破った」。事実です。役に立ちません。目標はデータを修正することであり、責任を追及することではありません。指摘ではなく、回復手順が必要です。
ツール
Great ExpectationsとSodaは契約機能を追加しました。完全なプラットフォームではありませんが、境界で意味的期待を強制します。
Data Contract ClubとAICPが登場しています。バージョン管理と検証を備えた一流の契約です。
データカタログ — Collibra、Alation、Atlan — は現在契約管理を備えています。通常はワークフローが重く、検証が軽いです。ドキュメントには適していますが、強制には向いていません。
layline.ioでは、契約をWorkflowsに組み込みます。データの移動を定義し、約束を定義します。スキーマの期待、検証ルール、品質基準。実行時に強制され、後でチェックされません。
しかし、豪華なツールは必要ありません。検証ステップを含むJSON Schemaファイルは機能する契約です。組織的な実践が技術を上回ります。
テスト
重要なデータAssetを選びます。間違っていると痛手を被るものです。
上流がフォーマットを変更します。技術的には有効です — 新しいフィールド、同じ型。意味的には間違っています。どれくらいで気づきますか？
答えが「誰かが文句を言うとき」であれば、契約が必要です。
「モニタリングでキャッチする」と言うなら、もっと深く掘り下げてください。あなたのモニタリングは意味的な変更をキャッチしていますか、それとも構造的な変更だけですか？
目標は完璧なデータ品質ではありません。愚かな問題を防ぐことです。誰も書き留めなかった仮定から生じるものです。
Andrew Tanはシリアルアントレプレナーであり、layline.ioの創設者で、バッチとリアルタイムの両方のワークロードをスケールで処理するエンタープライズデータ処理インフラストラクチャを構築しています。
