Back to Blog
ArticleJune 9, 20266分

ビジネスコンテキストのないデータ系譜は虚栄の指標

ほとんどの系譜ツールは美しい図を作成しますが、重要な質問に答えません。それは「このデータが間違っていると何が壊れるのか?」という質問です。ここでは、観測可能性の演技からビジネスに不可欠な系譜へと移行する方法を紹介します。

ビジネスコンテキストのないデータ系譜は虚栄の指標

Andrew Tanによる


嘘をつくダッシュボード

多くの企業はデータリネージツールに6桁以上の費用をかけています。そのデモは印象的で、データウェアハウス全体のテーブル、パイプライン、依存関係を示す広大なビジュアライゼーションを提供します。色は新鮮さを示し、矢印はデータフローを示します。それはまるで原子力発電所の制御室のようです。

これらすべては素晴らしく華やかですが、未解決の問題の1つは、テーブルXに不正なデータがある場合に何が起こるかです。

図をクリックして、ズームやパンを行い、テーブルを見つけ、下流の消費者とそれが供給した変換を調べることができます。そして、12のダッシュボードが「顧客住所」を使用していることがわかります。

しかし、本当の問題は、どのビジネスプロセスが壊れるのかということです。出荷が停止するのか?請求書が間違った場所に送られるのか?コンプライアンスレポートが失敗するのか?そのようなことを考えてみてください。

ダッシュボードは、データがAからBに流れたことを知っていますが、Bが実際に何のためにあるのかはわかりません。


リネージシアター

これが私が「リネージシアター」と呼ぶものです。印象的なデータフローダイアグラムを構築し、コンプライアンスチェックリストやベンダーデモを満たす実践ですが、問題が発生したときには実際には役立ちません。

ツールベンダーは間違ったことに最適化しています。彼らはビジュアライゼーションを販売しています。データチームが必要なのはコンテキストです。つまり、データ品質の問題をビジネスへの影響に60秒以内に追跡する能力です。

このパターンは多くの企業で見られます。彼らは大々的にリネージツールを導入します。ダイアグラムはオフィスのテレビに表示され(かっこいい)、データガバナンスチームはドキュメントについてのドキュメントを書きます。そして、6か月後、上流のシステムが列名を変更すると、リネージダイアグラムはクリスマスツリーのように点灯し、実際のビジネスへの影響は謎のままです。

チームは結局、ツールなしでやっていたことを行います。Slackを通じてページングし、ステークホルダーと確認し、どのレポートがどの決定に重要かを手動で追跡します。


ビジネスコンテキストのギャップ

ここに根本的な問題があります。技術的なリネージとビジネスリネージは異なるものであり、ほとんどのツールは最初のものしか行いません。

技術的なリネージは次の質問に答えます:このデータはどこから来て、どこに行くのか?

ビジネスリネージは次の質問に答えます:どの決定がこのデータに依存しており、それが間違っているとどうなるのか?

それらの間のギャップがデータ災害を引き起こします。パイプラインは技術的には100%正しいかもしれません:すべてのジョブが緑で、すべてのテストが合格している:しかし、ビジネスにとって壊滅的に間違った出力を生成しています。

例えば、あなたがフィンテック企業で、ローン承認モデルが技術的に完璧だとします。リネージは、アプリケーションから特徴エンジニアリング、モデルスコアリングまでのクリーンなデータを示しています。しかし、リネージが捉えていないのは、最近のスキーマ変更で「年収」と「月収」という似た名前のフィールドが入れ替わり、パイプラインの検証ルールがそれを検出しなかったことです。

モデルは今、月収を年収として扱っています。60,000ドル/年が必要な承認閾値が5,000ドル/月でトリガーされています。リネージダイアグラムは緑の矢印を示しています。ビジネスの結果は、6か月かけて解消する1か月の不良ローンです。


実際に役立つリネージとは

リネージをうまく行っているチームには共通点があります。それは、リネージを技術的なドキュメンテーションタスクではなく、ビジネスマッピングの演習として扱っていることです。

異なるアプローチを取る必要があります。あなたのウェアハウス内のすべてのデータassetには3つのタグがあります:

  1. 重要性:これは規制報告、運用上の決定、または分析のみに使用されているか?
  2. 下流プロセス:どのビジネス機能がこれに依存しているか?(どのテーブルではなく、どの機能:請求、臨床判断、コンプライアンス)
  3. エラーの影響:このデータが間違っていた場合に何が起こるか?(遅延、財務的損失、規制上の問題、患者の安全)

結果として得られるリネージツールは技術的にはシンプルです:単なる基本的な依存関係トラッカーです。しかし、これら3つのタグと組み合わせることで、何かが壊れたときに知る必要があることを正確に教えてくれます。

クレーム処理テーブルにデータ品質の問題がある場合、15の下流テーブルを追跡する必要はありません。タグを見て、「重要性:規制、下流:月次CMS提出、エラーの影響:遅延すると200万ドルの罰金」と表示され、すぐにCFOにエスカレートし、手動提出バックアッププロセスを開始することができます。

インシデント対応全体が数分で完了します。図のナビゲーションは不要です。


なぜ間違ったものを作るのか

では、なぜチームは実際の問題を解決しないビジュアライゼーション重視のリネージツールを購入し続けるのでしょうか?

一部は調達シアターです。ツールを購入する人は、午前2時のインシデントをデバッグする人ではありません。彼らはコンプライアンス監査や取締役会のプレゼンテーションのために徹底的に見えるものを購入しています。美しいダイアグラムはチェックボックスを満たします。ビジネスコンテキストマッピングは、写真には映えない組織的な作業を必要とします。

一部は、これらのツールが販売される性質にあります。ベンダーは、リネージが明らかなクリーンで合成的なデータ環境でデモを行います。実際の企業データ環境は非常に混沌としています:数十年にわたるレガシーシステム、文書化されていない変換、書かれたことのない部族的知識。ビジネスコンテキストのマッピングは、人々と話すことを必要とし、コードをスキャンするだけではありません。それは自動化された技術的発見ほどクリーンにはスケールしません。

そして一部は、技術的なリネージの方が構築しやすいということです。クエリログをスキャンし、SQLを解析し、DAGを検査することができます。ビジネスコンテキストはインタビュー、文書化、プロセスが変わるたびに継続的なメンテナンスを必要とします。それは技術的作業に偽装された組織的作業です。


リネージを修正する方法

すでにリネージツールに投資している場合(そしてほとんどの企業はこの時点でそうです)、それを取り除く必要はありません。ビジネスコンテキストを追加する必要があります。

インシデント履歴から始めます。実際のビジネスへの影響を引き起こした過去5つのデータ品質インシデントを見てください。それぞれについて、次のことを特定します:

  • どのデータが間違っていたか
  • どのビジネスプロセスが壊れたか
  • 誰が知る必要があったか
  • それを把握するのにどれくらいかかったか

次に、リネージツールを見てください。それがこれらの質問のいずれかに役立つかどうかを確認します。そうでない場合、改善のロードマップが見えてきます。

重要なassetを手動でタグ付けします。すべてをタグ付けしようとしないでください。ビジネスへの影響が大きいトップ20のデータassetから始めます。それぞれについて、どの決定に供給されているか、誰がその決定を所有しているか、データが悪い場合に何が起こるかを文書化します。

これは時間がかかります:assetごとに30分、場合によってはそれ以上。しかし、それによりリネージは美しいダイアグラムから運用ツールに変わります。

ビジネスに対応したアラートを構築します。ほとんどのデータ品質アラートは技術的です。「このジョブが失敗しました」または「この列にnullがあります」。ビジネスに対応したアラートを追加します:「日次収益サマリーに疑わしい値があり、CEOダッシュボードに午前8時に供給されます。」

アラートには、何が間違っているかだけでなく、それに依存しているものと誰が知る必要があるかも含めるべきです。

インシデント対応を練習します。テーブルトップ演習を実行します。重要な上流システムでデータ品質の問題をシミュレートします。次の質問に答えるのにどれくらいかかるかを計測します:どのビジネス決定が影響を受けるか、誰に通知する必要があるか、そして緩和策は何か。

5分以上かかる場合、リネージにはより多くのビジネスコンテキストが必要です。


私が望む製品

市場に出ているいくつかのリネージツールを見てきました。それらはすべて同じテーマのバリエーションです:インフラストラクチャをスキャンし、グラフを構築し、美しいビジュアライゼーションを表示します。

私が望むのは違います。私はビジネスプロセスから始めて逆方向に作業するツールが欲しいです。最初に決定をマッピングし、それからそれに供給されるデータを追跡します。何かが壊れたとき、どの決定が危険にさらされているかを教えてほしいのであり、どのテーブルが影響を受けているかではありません。

しかし、より良いリネージを得るために新しいプラットフォームは必要ありません。リネージを技術的な問題としてではなく、組織的な問題として扱う必要があります。図は製品ではありません。ビジネスコンテキストが製品です。


リネージツールのテスト

簡単なテストがあります。システム内の重要なデータassetを選んでください:それが間違っていると痛いものです。コードを見ずに次の質問に答えてください:

  1. どのビジネス決定がこのデータに依存しているか?
  2. 誰がその決定を行い、いつ行うか?
  3. 間違っている場合のコストは何か?
  4. 品質の問題がある場合、誰が知る必要があるか?

これらの質問に60秒以内に答えられない場合、リネージツールはその仕事を果たしていません:どれほど美しいダイアグラムであっても。

目標は完璧な可観測性ではありません。使えるコンテキストです。そして、それを構築するのは難しいですが、無限に価値があります。


Andrew Tanは、layline.ioの創設者であり、バッチとリアルタイムのワークロードを大規模に処理するエンタープライズデータ処理インフラストラクチャを構築するシリアルアントレプレナーです。

Share:

Enjoyed this article?

Subscribe to get more insights delivered to your inbox.