Data Quality Fundamental / Chapter 9. Data Quality in the Real World: Conversations and Case Studies
9章もくじ
Building a Data Mesh for Greater Data Quality
Why Implement a Data Mesh?
A Conversation with Zhamak Dehghani: The Role of Data Quality Across the Data Mesh
Case Study: Kolibri Games' Data Stack Journey
ここでは以下の節を解説します：
Making Metadata Work for the Business
メタデータがますます重要になってきていることを解説Unlocking the Value of Metadata with Data Discovery
メタデータ収集には目的が必要で、さらに現在ではデータカタログではなくデータディスカバリーによるメタデータ収集が重要Deciding When to Get Started with Data Quality at Your Company
いつデータ品質への取り組みを開始すればよいか、7つの指標を解説
Making Metadata Work for the Business
過去10年間で、データチームは大量のデータを収集する能力を格段に向上させてきました。これによりデジタルイノベーションやより賢明な意思決定を推進する可能性がありますが、同時に企業は理解できない、または使用できないデータで溢れています（Industry Week: Drowning in Data: Concequences of Having Too Much of a Good Thing）。データドリブンになりたいと願う組織はしばしば木を見て森を見ずの状況に陥っています：明確なアプリケーションやユースケースがなければ、データはデータベースのファイルやスプレッドシートの列以上のものではありません。
現在、企業は自社のデータに関するより多くのデータ、つまりメタデータを収集しています。dbtのようなETLソリューションはメタデータの追跡と使用を容易にし、クラウドプロバイダーはスタック内のデータソリューション間でメタデータの相互運用性をよりシームレスにします。
私たちがよりメタデータに依存するにつれて、同じ過ちを繰り返さないように心に留めておくことが重要です。文脈なしのデータが単なる一連の数字に過ぎないのと同じように、単体のメタデータは役立ちません - それは単に他の情報についての更なる情報に過ぎません。好きなだけ収集しても、実用的なユースケースがなければ、メタデータは大部分が無意味です。
例えば、データパイプライン内の上流と下流の依存関係を追跡するメタデータの一種であるデータリネージを考えてみてください。ネオンカラーやグラフィカルな表現が印象的なリネージですが、コンテキストがなければただの目の保養であり、あなたのエグゼクティブとのデモには素晴らしいかもしれませんが、正直言ってそれ以外にはあまり役立ちません。リネージの価値はそれを持つという単純な行為からではなく（図9-13）、それが特定のユースケースやビジネスアプリケーションに関連性を持つことによって生じます。
実際にリネージが有用となるのはどこでしょうか？ デモやプレゼンテーションで見栄えが良いだけでなく、データリネージは次の事項を理解するための強力なツールとなります：
消費者に影響を与えるデータの変更をどのように理解し、そのユースケースを解決するための最善の行動を決定するか
データアセットが壊れたときに問題の根本原因をどのようにトラブルシューティングするか
壊れたデータについて、どうやって消費者とコミュニケーションをとるか
メタデータの真の力は、それをどこで、いつ、どのように使用するかにあります―特に、我々が解決しようとしている特定の、タイムリーな問題にどのように適用するかです。メタデータの収集とメタデータソリューションの構築に加えて、データチームは自身に問いかける必要があります：
このメタデータはどのような問いに答えることができるか？
このメタデータを消費者の課題を解決するためにどう利用できるか？
次の節では、ビジネスバリューを念頭においたメタデータの理解と活用に向けた、新しいアプローチについて議論します。
Unlocking the Value of Metadata with Data Discovery
（ここからしばらく、データウェアハウスとデータレイクの話が交互に登場します）
過去数年間で、クラウド上のデータウェアハウスとデータレイクは現代のデータスタックに必須のものとして浮上してきました。しかし、データへのアクセスと分析を可能にする技術が成熟している一方で、分散環境でこのデータを理解するためのメカニズムは遅れています。ここでは、データカタログが不足している点と、データディスカバリーツール（または連携カタログ）がどのようにデータ環境がデータスワンプにならないように保証するかを説明します。カタログの構築と使用についてのより堅牢な技術ガイダンスについては、第2章を再訪してください。
Data Warehouse and Lake Considerations
データプラットフォームを構築する際にデータチームが最初に決定しなければならないことの一つは、分析のためのストレージとコンピューティングを担当するデータウェアハウスかデータレイクのどちらを選択するかです。
データウェアハウスはデータチームがデータを効率的に運用するための構造を提供します（つまり、分析的な洞察を得て機械学習能力を支援します）。しかし、その構造は特定のアプリケーションに対しては柔軟性がなく、コストがかかる可能性があります。
一方、データレイクは幅広いユースケースをサポートするために無限に柔軟でカスタマイズ可能ですが、その大きな敏捷性にはデータの組織化とガバナンスに関連する他の問題が伴います。
データレイクやレイクハウスを選択するデータチームでは、次のような質問に回答するのに苦労するでしょう：
そのデータはどこにあるか？
そのデータは誰がアクセスしたか？
どうやったらそのデータを利用できるか？
このデータは最新の状態か？
このデータをどうやってビジネスに活用したらよいか？
データオペレーションが成熟し、データパイプラインが複雑になるにつれ、伝統的なデータカタログではこのような質問に回答するのが難しくなります。そのため、データカタログを構築するアプローチと、データレイクにはどのようなデータディスカバリーツールが必要かを考え直さなければなりません。
Data Catalogs Can Drown in a Data Lake - or Even a Data Mesh
データカタログはメタデータの目録として機能し、データの健康状態、アクセシビリティ、保存場所に関する情報を提供します。それらはデータチームがどこでデータを探すべきか、データが何を表しているのか、そしてそれがどのように使用できるのかといった質問に答えるのに役立ちます。しかし、そのデータがどのように組織化されているのかわからないと、私たちの計画（パイプライン）は全て無駄になります。
歴史的に、多くの企業はデータ品質とデータガバナンスの基準を強制するためにデータカタログを使用し、これらは伝統的にデータチームがデータ資産が進化するにつれてカタログ情報を手動で入力・更新することに依存していました。データレイクでは、データは分散しており、データがそのライフサイクルの過程で進化するにつれて文書化することが難しくなります。
非構造化データは、それが組織化されておらず、もしそうであっても組織化されているとは宣言されていないため、データカタログに関連して問題となります。それはデータウェアハウスで蓄積された構造化または半構造化データには適用できるかもしれませんが、分散データレイクの文脈では、データが進化するにつれてガバナンスを手動で強制することは、一定の自動化なしではスケールしません。
同様に、伝統的なカタログに保存されたデータは、データメッシュのような分散データアーキテクチャの要求に対応し、進化するためにスケーリングするのが困難です。本章の初めに議論したように、データメッシュは分析データが分散環境で処理され、変換され、全領域にわたる統一された連携ガバナンスとディスカバリの層が存在すると主張しています。データカタログは手動運用が必要なため、情報を更新し続けるのが困難で、データのライフサイクルの各段階でのデータの現状を理解するのが難しくなります。
Moving from Traditional Data Catalogs to Modern Data Discovery
時間とともに進化する様々なデータ資産の関係を理解することは、伝統的なデータカタログにおいて重要ながらもしばしば欠けている点です。現代のデータアーキテクチャ、特にデータレイクは、しばしば分散していますが、データカタログは通常そうではなく、データを一次元のエンティティのように扱います。非構造化データは、多くのデータカタログが仕事をするために依存するような事前に定義されたモデルを持たず、使用可能にするためには複数の変換を経る必要があります。
それでも、企業は自分たちのデータがどこに存在し、誰がアクセスできるのかを知り、その全体的な健康状態を測定できる必要があります－倉庫ではなくレイクに保存されている場合でも。データディスカバリツールからのデータリネージの可視性がなければ、チームはデータ問題がさらに下流で発生した際に消防活動とトラブルシューティングに貴重な時間を費やし続けるでしょう。
伝統的なデータカタログはしばしばウェアハウス内の構造化データの要求を満たすことができますが、データレイクの複雑な水域を航行するデータエンジニアはどうでしょうか？ 多くのデータカタログはUI中心のワークフローを持っていますが、データエンジニアはカタログとプログラム的に対話する柔軟性を必要としています。彼らはカタログをスキーマとメタデータの管理に使用し、広範なデータ管理タスクを達成するためにAPIドリブンのアプローチが必要です。
さらに、データは複数のエントリーポイントを介してレイクに入ることができ、エンジニアはそれぞれに適応し、対応できるカタログが必要です。そして、データウェアハウスとは異なり、データレイクは生のデータを取り込みます。
レイク内では、データの保存は安価で柔軟であることが多いですが、それはあなたが何を持っていて、それがどのように使用されているのかを知ることを難しくしてしまいます。データはJSONやParquetなど、さまざまな方法で保存されることがあり、そのフォーマットに適した方法でデータを扱う必要があります。集約ジョブにSparkを使用したり、レポートやアドホッククエリにPrestoを使用したりすることがありますが、その場合には壊れたデータや悪いデータが失敗を引き起こす可能性が多いです。データディスカバリツールとデータリネージがなければ、データレイク内のこれらの失敗は混乱を招き、診断が難しくなる可能性があります。
データディスカバリ、つまり連邦データカタログとは、Zhamakのデータメッシュモデルで提唱された分散ドメイン指向アーキテクチャに根ざした新しいアプローチです。このフレームワークの下では、ドメイン固有のデータオーナーは、自分のデータをプロダクトとして、そして分散データ間のコミュニケーションを促進するために責任を負います。以下の行動により、現代のデータディスカバリツールは伝統的なデータカタログが不足していた箇所を埋めることができます:
データレイク上でスケールするように自動化する
機械学習を利用したデータディスカバリーツールは、テーブルやフィールドレベルの系統を自動で追跡し、上流と下流の依存関係をマッピングします。データが進化するにつれて、データディスカバリーツールは、データの理解とその使用方法が同時に進化することを保証します。データヘルスの可視化をリアルタイムで提供する
伝統的なデータカタログとは異なり、データディスカバリーツールは、データの「カタログ化」または理想的な状態ではなく、現在の状態についてリアルタイムの可視性を提供します。ディスカバリーはデータの取り込み、保存、集約、および消費者による利用方法を包括するため、廃止できる古いデータセットや、特定のデータセットの品質を確認したり、特定のテーブルが最後に更新された時間などの洞察を得ることができます。ビジネスインパクトを理解するため、データリネージを活用する
データディスカバリーツールは、データリネージをデータレイクにもたらします。データリネージを利用すると、スキーマの変更などのよく見落とされる問題が検出され、関連する依存性がマッピングされるため、データパイプラインが壊れた場合でも問題をより迅速に解決することができます。ドメインをまたいだセルフサービスディスカバリーを強化する
データディスカバリーツールはセルフサービスも可能にし、専用のサポートチームなしにチームが自分たちのデータを簡単に利用し理解できるようにします。このデータが信頼できるものであることを確保するために、データの可視性にも投資するべきです。これは、データレイクや下流のパイプラインで何か問題が発生したときにリアルタイムの警告と監視を提供するために、機械学習とカスタムルールを使用します。データレイク上でのガバナンスと最適化を保証する
現代のデータディスカバリーツールは、企業がデータのライフサイクルを通じてどのデータが使用され、消費され、保存され、廃止されるかだけでなく、それがどのように行われるかを理解することを可能にします。これはデータガバナンスにとって重要であり、データレイク全体での最適化に役立つ洞察を提供します。
ガバナンスの観点から、データレイクでのクエリと処理は、さまざまなツールとテクノロジーを使用して行われることが多く（このためにはDatabricksのSpark、あれのためにはEMRのPrestoなど）、その結果、読み書きのための単一で信頼性の高い情報源（ウェアハウスが提供するもの）がしばしば存在しません。適切なデータディスカバリツールはその情報源として機能します。最適化の観点から、データディスカバリツールは、ステークホルダーが最も重要なデータ資産（常にクエリされているもの）や使われていないものを特定するのを容易にし、それぞれがパイプラインの最適化のための洞察を提供することができます。
あなたのデータがどれだけ「発見可能」であっても、それを信頼できなければ意味がありません。よくあるのは、チームがデータプラットフォームを構築しているとき、データ品質は最初の項目ではない（結局のところ、それを取り込み、保存し、処理することができなければならない）が、早い段階でデータ品質を優先することで、不必要なデータダウンタイムを避けることができます。
次のセクションでは、いつデータ品質を優先し始めるべきかを議論します。
Deciding When to Get Started with Data Quality at Your Company
（この節は MONTE CAROLO 社の以下のブログの引用のようです：
https://www.montecarlodata.com/blog-building-a-data-platform-7-signs-its-time-to-invest-in-data-quality/ ）
この本ではこれまでに、チームが高いデータ品質を達成するために適用しなければならない技術、プロセス、指標について学びました。また、Fox、Toast、Blinkistなどの主要企業のデータチームがこれらを適用し、すばらしい結果を得た成功事例も見てきました。それにもかかわらず、我々はまだ「いつ」について話していません。実際、我々が話をするデータリーダーから最も頻繁に質問されるのは、「いつデータ品質に投資するのが理にかなっているのか？」ということです。
データプラットフォームを構築するときの最初の考えは、おそらく「このデータを信頼できますか？」ではないでしょう。あなたはおそらく、ただデータの取り込みを行い、色々なツールを起動させたり動かしたりすることに より関心があるでしょう。したがって、データ品質に投資すべきタイミング、それはケースバイケースである、というのが答えです。より詳しく理解するために、データプラットフォームのデータ品質に投資する時期が来たという7つの先行指標をここに共有します：
1) You've Recently Migrated to the Cloud
あなたの組織がデータレイクへの移行やクラウドプラットフォーム間の移行（例えば、Amazon RedshiftからSnowflakeへ）のプロセスにある場合、移行理由はいずれかの以下に該当するでしょう：
* 現在のデータプラットフォームが時代遅れで、データ信頼性が低いため、誰もデータを信頼しない。
* 現在のプラットフォームはビジネスと一緒にスケーリングできず、複雑なデータニーズをサポートするのに多くの手動介入が必要。
* 現在のプラットフォームは運用が高価で、新しいプラットフォームは適切に管理された場合、より安価です。
データ移行に際し、データ品質の維持はデータチームのやるべきことリストの上位にあるべきです。AutoTrader UK（中古車販売会社）の事例では旧来のシステムを使っているユーザに対して、新しいシステムを信頼してもらうためにはデータオブザーバビリティが非常に重要であったと述べています：
https://www.montecarlodata.com/blog-scaling-data-trust-how-auto-trader-migrated-to-a-decentralized-data-platform-with-monte-carlo/
オブザーバビリティの取り組みとして、Looker -> Slack の自動アラートシステムの解説など）
2) Your Data Stack is Scaling with More Data Sources, More Tables, and More Complexity
データプロダクトの規模はデータ品質への、唯一ではありませんが重要な投資基準の一つです。どの組織も、テーブルの数が50以上ある場合、データオブザーバビリティに投資すべきだという一般的なガイドラインがあります。
3) Your Data Team Is Growing
あなたの組織がデータを価値あるものとして認識しているため、より多くのデータスタッフを雇い、データスタックにモダンなツールを導入しています。しかし、このような変化はしばしばデータチームの構造（集中型から分散型への移行）、新しいプロセスの採用、そして初期のデータチームメンバーしか持たないデータセットへの知識の偏りを引き起こします。
例えば、私たちが「あのテーブルを使っているの！？」問題があります。データプラットフォームが拡大するにつれ、どのテーブルが正しく管理されているか、古いかを識別することは困難になっていきます。
4) Your Team is Spending at Least 30% of Their Time Firefighting Data Quality Issues
私たちがMonte Carloを立ち上げたとき、データシステムの管理に関する痛みの点を理解するために100人以上のデータリーダーにインタビューしました。60%以上がデータ信頼性の旅の初期段階にあり、チームは1日の半分をデータ品質問題の消防活動に費やしていると答えました。
5) Your Team Has More Data Consumers Than They Did One Year Ago
あなたの組織は急速に成長しており、それは素晴らしいことです。データはあなたの採用決定、製品機能、予測分析を推進しています。しかし、ほとんどの場合、急速な成長は、データに依存するビジネスステークホルダーの増加、より多様なデータニーズ、そして最終的にはより多くのデータをもたらします。
6) Your Company Is Moving to a Self-Service Analytics Model
あなたはデータエンジニアリングの時間を節約し、すべてのビジネスユーザーがデータに直接アクセスし、データと対話できるように、セルフサービスの分析モデルに移行しています。データチームは興奮しています、なぜなら彼らはもはやビジネスユーザーからのアドホックなリクエストを満たす必要がないからです。
一方でデータ利用者はデータを信頼する必要があり、信頼できなければ意思決定にデータを活用しなくなるでしょう。セルフサービスの分析モデルへの移行も失敗してしまいます。
データ活用が日々の業務に取り入れられるにつれ、信頼できるデータへのニーズはますます高まります。
7) Data Is a Key Part of the Customer Value Proposition
すべてのアプリケーションは間もなくデータアプリケーションになるでしょう。データリーダーとして、会社がデータの新たなユースケースを見つけたとき、特にそれが顧客向けであるとき、私たちは非常に興奮します。
例えば Toast 社では、ビジネスインサイトをクライアント（レストラン側）に提供している点で同業他社と一線を画します。前日比、時間経過による変化などさまざまな指標を提供しています。
これはデータスタックがコア製品と同じ程度の信頼性をもつ必要があることも意味しており、データ品質に関する取り組みの優先順位が高くない場合、炎上は免れないでしょう。
Data Quality Starts with Trust
ガス会社がガスとオイルを消費者に提供するために石油掘削設備を信頼する必要があるのと同じように、組織は自身のデータを信頼する必要があります。プロアクティブなアプローチをデータ品質に採用することで、データ品質問題については、あわただしいSlackメッセージや短気なメール、その他のデータダウンタイムの遅れる指標が現れるよりも前に、あなたのチームが最初に知ることができます。そうでなければ、貴重なエンジニアリングの時間はデータダウンタイムの消防活動に無駄になり、データ駆動型の会社になろうとするあなたの努力は時間とともに妨げられ、ビジネスユーザーはデータを信頼しなくなるでしょう。ビジネスによって状況は異なりますが、できるだけ早期にデータ品質をデータプラットフォームに組み込むことが最善です。
Summary
この章では、データ品質を高めるために重要なテクノロジーやトピック、例えばデータメッシュやデータディスカバリーツールに新たな視点を当てました。
また、スタートアップ企業であるKolibri Gamesが、よりスマートで自動化されたソリューションとデータを管理するためのドメイン指向のアプローチを用いて、ゼロからデータスタックを構築し、データ信頼性の問題を事後的に解決する方法を紹介しました。
最後に、データ品質への投資を早期に検討するべき7つの主要な指標について具体的に議論しました。もちろん、データのニーズについては各組織で異なるでしょうが、スケールのためのデータ戦略を設計する際には、これらの考慮事項を見逃さないよう強く勧めます。
最終章である第10章では、いくつかの重要な学びを再確認し、データ品質に適切な尽力とリソースを投入するための強力な新しいアプローチを紹介し、より広い業界のトレンドと関連するデータ信頼性の未来についての予測を共有します。