データ コントラクト
フェデレーション アーキテクチャではドメイン間で責任が分散されるため、依存関係を監視してデータ使用の分析情報を入手するのが難しい場合があります。 データ コントラクトがあれば、各データ製品の所有者についての情報が得られるため、データ使用状況に関する分析情報が得やすくなります。 データ コントラクトによって基準の設定が促され、データ パイプラインを確実に管理できるようになります。 これらは堅牢なデータ管理に欠かせないものであり、そこから次のような情報が得られます。
どのデータ製品が使用されているか。
どのユーザーがどのデータ製品を使用しているか。
特定のデータ製品をユーザーが使用している目的は何か。
データ製品の分散と使用には、技術上の問題とビジネス上の問題の 2 つのディメンションがあります。 技術上の問題には、データ パイプラインの処理、そしてデータの安定性への相互の期待が含まれます。 ビジネス上の問題には、データを共有する目的の取り決めが含まれ、制限を含むその取り扱い、プライバシー、目的が定義されます。
2 つのディメンションには、それぞれ異なる役割があります。 一般に、技術上の問題はアプリケーション所有者またはデータ エンジニアが担い、ビジネス上の問題は製品の所有者またはビジネス担当者が担います。
データ コントラクト
データ コントラクトは、サービス コントラクトやデータ配信コントラクトに似ています。
大規模または分散アーキテクチャでは、変更を監視するのが難しい場合があります。 広く使われるデータ製品がある場合には、バージョン管理を導入し、互換性を管理することで監視を単純化できます。
アプリケーションが結合されている場合、それらのアプリケーションの間には当然、強い相互依存関係があります。 結合されているアプリケーションが他のアプリケーションのデータにアクセスしたり、そのデータを使用したりする際には、常に課題が伴います。 たとえば、データ構造に対する変更は、そのデータにアクセスしたり使用したりする他のアプリケーションに直接影響する可能性が高くなります。 多数のアプリケーションが結合されている状況では、1 つのアプリケーションに対する小さな変更が他の多くのアプリケーションに影響を与えるカスケード効果がよく発生します。 ささいな変更でも意図しない影響が生じる可能性が高まることから、多くのアーキテクトやソフトウェア エンジニアは、結合アーキテクチャの構築を避けます。
データ コントラクトは、インターフェイスの互換性を保証します。また、データ コントラクトには、サービス利用規約とサービス レベル アグリーメント (SLA) が含まれます。 サービス使用条件は、開発、テスト、運用に使用を制限するなど、データの使用方法についてその枠組みを記したものです。 データの配信やインターフェイスに必要な品質は、SLA に記述されます。 SLA で規定される品質情報の例を次に示します。
- 稼働時間
- エラー発生率
- 可用性
- 非推奨
- ロードマップ
- バージョン番号
これらの情報を収集するメタデータをソース管理下に置くことで、検証とデプロイの自動トリガーを実現できます。 ソース管理の詳細については、「Azure Data Factory のソース管理」を参照してください。
データ コントラクトでは、ドメインとアプリケーションの結合と依存関係に関する詳細情報が提供されます。 コントラクトはテストにも対応します。コントラクトのテストでは、アプリケーションとインターフェイスのすべての変更がコンシューマーのデータ要件と照らして検証されます。 スキーマ ドリフトを検出することにより、アップストリームのデータ ソースの変更に対してデータ フローが無防備になるタイミングを把握できます。 詳細については、「マッピング データ フローのスキーマの誤差」を参照してください。
メタデータ駆動型のインジェスト フレームワークには多くの場合、データ コントラクトが含まれています。 データ コントラクトは、一元管理されたメタストア内のメタデータ レコードに格納できます。 その中央の場所から、データ インジェストのさまざまなデータ領域でデータ コントラクトは重要な役割を果たします。その例を次に示します。
パイプラインの実行
データ製品の作成
データ型の検証
スキーマ
相互運用性の標準
プロトコルのバージョン
欠落データに関する既定値の規則
データ コントラクトには、大量の技術メタデータが含まれます。 データ パイプラインとデータ製品を文書化するには、データ ソース、データが辿ったすべての変換、そして最終的にデータを配信する方法が明確に記述されている必要があります。
分散アーキテクチャでは、データ パイプライン フレームワークが複数の異なるドメインに分散され、それらのドメインが共通の処理方法に従います。 データは各ドメインで処理されるため、制御と責任はドメインに課される一方、フレームワークとメタデータは中央のガバナンスの下で維持されます。
フェデレーション方式を導入する際は小さな規模から始めるようにします。 まず、スキーマ検証、エンタープライズ識別子、その他のデータセットの参照用のメタデータを共有メタデータ リポジトリに格納するなど、基本から開始します。 さらに、データ系列をサポートすれば、データの移動を視覚化しやすくなります。 プロセスを立ち上げ、Great Expectations などのライブラリを使用して、データ品質の技術的検証のための制御を実装します。
すべてのコントロールは、継続的インテグレーション手順の一部である必要があります。 メトリックやログなど、あらゆるランタイム情報を収集し、その情報を、データ パイプラインの安定性に関する分析情報を得るためのメタデータ基盤の構成要素とします。 このセットアップによって、ドメインと一元管理コックピットとの間にフィードバック ループが形成されます。
あらゆるデータ移動を安定化させながら、どのデータ コンシューマーによって、どのデータ属性 (テーブル、列など) が使用されるかを収集し、その情報を使ってスケーリングを継続します。 この情報は、一元管理されたメタストアに含めることができます。 データ使用状況の情報から破壊的変更を検出し、データ プロデューサーとデータ コンシューマーへの影響を見極めることができます。 データ製品のデータセットにコンシューマーが存在しない場合は、破壊的変更を発生させることができます。 データのプロバイダーとコンシューマーとの間のハンドシェイク プロセスには、ソース管理 (Git など) を使用して対処できます。
データ共有契約
データ共有契約は、データ コントラクトの延長です。 あらゆる制限事項を含め、データの使用、プライバシー、目的の枠組みがこの契約に記述されます。 データ共有契約はインターフェイスに依存せず、特定の目的に対し、どんなデータが使用されるかについての分析情報を提供します。 また、データ セキュリティ制御の入力としても機能します。 データに適用すべきフィルターまたはセキュリティ保護の枠組みは、データ共有契約を使用して示すことができます。
データ共有契約には、データの使用に関する誤解を防ぐ効果もあります。 データを共有する前に、ドメインの所有者がデータの共有と使用に関する問題について話し合う必要があります。 データとその使用を規制し、組織に価値をもたらすためには、共通の理解が欠かせません。 ドメインの所有者全員が共通の理解に達したら、それをデータ共有契約で文書化する必要があります。 この契約で、次のような領域に対処することもできます。
実用的なデータの品質
ヒストライゼーション
データのライフサイクル管理
さらなるデータの配布
データのセキュリティは、秘密度ラベルやフィルタリング条件などの分類や条件を適用することで確保します。
前セクションの図を見ると、"データ製品サイドカー" として分類された特定の要素があります。 データ製品サイドカーは、データ アクセスの制御や使用データの出力方法など、ポリシーの実行を挿入するためのコンポーネントまたはレイヤーです。 これはセキュリティを抽象化したものであり、データ コントラクトを使用して、ドメイン データに対するセキュリティ適用を担います。 データ製品サイドカーは、データ コントラクト リポジトリからアクセス制御リスト (ACL) やサーバーレス ビューとして作成できるほか、特定のコンシューマー用に選択、抽出した複製データセットを使用して作成できます。 どちらの方法も、最終的な目的は、セキュリティ ビューをデータ コントラクトから全自動で派生させることです。
データ コントラクトの属性とドキュメントを結び付けます。 実際の実装に対してビジネス要件がどう変換されるかをコンシューマーが理解できるよう、用語集との関係や意味上のコンテキストを提供します。 ビジネス用語との関係が組織にとって重要な場合は、すべてのデータ製品属性がビジネス用語エンティティにリンクされた後にのみデータ コントラクトを確立できるようにするなどのポリシーを実装することを検討してください。 この種類のポリシーは、関係や定義の調整などのコンテキストの変更にも適用できます。
データ コントラクトを使用する
データ コントラクトは時間をかけて導入してください。 一度にあまりにも多くの変更を導入しないでください。データ コントラクトは文化的変化を伴うものであり、ユーザーがそれらに慣れ、そしてデータ所有権の重要性を理解するまでには時間が必要です。 また、データ コントラクト内のメタデータ属性については、多すぎず、少なすぎることもない適度な中間点を見つける必要があります。
次の手順は、社内にデータ コントラクトを導入するプロセスを簡単にまとめたものです。
技術データ パイプラインが安定していることを確認します。 辿るパイプラインに予期しない中断が発生するようでは、ユース ケースは運用に到達できません。
共有契約の使用を開始する際は、簡素で実用的なプロセスを設定します。 最初は、Microsoft Forms で単純なフォームまたはテンプレートを設計しましょう。 読者が理解しやすい明瞭かつ簡潔な言葉で記述します。 文化的変化と要件の収集が、この最初のフェーズのねらいです。 むやみに複雑化することは避けてください。手動でのプロセスを受け入れ、初期メタデータ要件を制限して、それらの要件が安定するまで繰り返します。
最初のプロセスがしっかり整ったら、手動フォームを Web ベースのアプリケーション、データベース、メッセージ キューに置き換えてみます。 中央データ ガバナンス チームは、このフェーズ中も監視の責任を負う必要があります。 通常、この時点でのデータ アクセスの粒度は粗く、フォルダーまたはファイルに主眼が置かれます。 可能であれば REST API を使用して自動的にデータ アクセス ポリシーまたは ACL をプロビジョニングしてください。
承認管理のための強力なワークフローを担当するデータ所有者またはデータ スチュワードを配置します。 それ以後、中央のデータ ガバナンス ロールは、後方支援的な役割からのみ承認を監視し、すべてのデータ コントラクトを定期的に確認する必要があります。 この時点で、使用する準備の整ったすべてのデータ製品を表示する Azure Purview などのデータ カタログを稼動させておくようにしてください。 きめ細かな選択とフィルタリングを可能にすることでデータとセキュリティの適用能力を高めると共に、動的データ マスクなどの手法を使用して、データの複製を防ぐことを検討してください。
データ コントラクト導入への取り組みの最終段階では、すべてがセルフサービスになっていて、完全に自動化されている必要があります。 データの承認は、自動機械学習で予測する必要があります。 セキュリティ
最後に、すべてをセルフサービス化し、完全に自動化します。 これには、自動セキュリティ適用と、データの承認を予測する機械学習が含まれます。 たとえば、セキュリティで保護されたビューは、承認後に自動デプロイされます。
データ コントラクトは、追加されたのは比較的最近ですが、データ メッシュ アーキテクチャの重要な要素であり、データの使用と依存関係に透明性をもたらすものです。 最初にデータ コントラクトを使い始める際には技術的な安定性と標準化に焦点を当て、次に、反復する過程で得た教訓が反映されたプロセスを使用します。 社内のオーバーヘッドを増やさないように、データ ガバナンスを徐々に構築して自動化してください。
監視とデータ共有契約の詳細については、「クラウド監視ガイド: 可観測性」を参照してください。
データ コントラクトのドキュメントには、サービス使用条件とサービス レベル アグリーメント (SLA) も含まれている必要があります。 SLA を使用して、データ配信とインターフェイスの品質要件の枠組み、たとえば稼働時間、エラー発生率、可用性を定めます。 非推奨化やロードマップ、バージョン番号について定義すべき要件も、SLA に含めることもできます。