データ製品とは
すべてのアプリケーションは、一時的または永続的にデータを作成して格納します。 また、多くのアプリケーションでは、エラー ログや稼働状況の監視など、運用管理の目的でデータを作成して保存します。 一元化されたデータ チームは、ETL プロセスを使用して、これらのアプリケーションによって生成されたデータを利用および処理します。 多くの場合、アプリケーション運用チームは、アプリケーションの正常性や KPI 状態の監視などの追加のデータ処理フローを使用します。
チームのウォーターフォールや、データ統合における責任といった従来型のアプローチは理想的ではありません。 これにより、データの品質、タイムライン、エンド ユーザーにとっての価値に影響を与える知識のギャップ、所有権の問題、コミュニケーションの競合につながる可能性があります。 アプリケーション チームは、アプリケーションのパフォーマンスと成功に責任を持っています。 彼らの仕事では、他のチームが所有するダウンストリーム プロセスに変更を加える必要がありますが、多くの場合、これらの変更は計画に従っていません。 たとえば、いわゆるマイナー アップストリームの変更によって KPI の傾向が大幅に変わる場合があります。 このようなデータの問題は、重要な意思決定を行う能力に影響を与える可能性があります。
データ メッシュ アプローチでは、製品としてデータの概念を採用することで、これらの問題を防ぐことができます。 アプリケーションの所有者とアプリケーション チームは、データを、他のユーザーが管理する一部のプロセスの副産物ではなく、自分たちが責任を持つ完全包含製品として扱います。 アプリケーションと分析データ提供タスクの両方が、責任ドメインの領域内にあります。
データ製品は、分析用に特別に作成されます。 これらは、形状、消費インターフェイス、メンテナンス、更新サイクルについて定義および合意され、すべて文書化されます。
データ製品は、SLO 内のインターフェイスを介してダウンストリーム プロセスと共有される、処理済みのドメイン データ資産/データセットです。 特に必要な場合を除き、合意された品質基準を満たすために、生データを処理、整形、クレンジング、集計、正規化してから使用できるようにする必要があります。
次のセクションでは、優れたデータ製品が持つ一般的な特性について説明します。
データ製品の特性
適切に設計されたデータ製品とは次のようなものです。
検出可能、理解可能、および信頼できる: ドメイン チームは、各データ製品、そのデータ、その意味、データの形式、および更新サイクルに関する情報を共有および更新することで、検出可能性と理解可能性を実現します。 データや形状の変更をダウンストリームのコンシューマーにタイムリーに伝えます。 インターフェイスは、データ製品の形状に対して期限付きの下位互換性を提供することで、信頼性を保証します。
アドレス指定可能、ネイティブにアクセス可能、およびセキュリティ保護: 各データ製品を検索してアクセスするための定義済みのプロセスにより、アドレス指定が可能になります。 さまざまなアクセス要件に必要なセキュリティ対策が講じられています。 データ ドメインの所有権のメンタリティは、データのゲートキーピングから、明確に定義されたセキュリティ対策を使用したデータの提供にシフトします。 提供されるアクセス インターフェイスは適切に文書化されており、さまざまなテクノロジによって異なる場合があります。 ネイティブにアクセスできるデータ製品で一般的に使用されるインターフェイスには、API、データベース ユーザー、テーブルまたはビュー、必要なアクセス権が指定されたファイルが含まれます。
相互運用可能、真実性、価値: データは、同じ値が常に同じ名前とデータ型を持つといった、定義された一般的な標準に従うことで相互運用性を提供します。 たとえば、顧客識別データを含む列には、すべてのデータ製品で CustomerID というタイトルが付けられ、そのデータはすべてのインスタンスで常に整数であるか、snake_case または camelCase を使用する場合があります。 データ製品は、顧客に価値を提供し、同じドメインまたは異なるドメインで新しいデータ製品のアップストリーム ソースとして使用することもできます。 ただし、同じデータ製品を複数の場所に移動してコピーすることはできません。 以前のデータ製品から取得した各データ製品は、ダウンストリームのコンシューマーに新しい価値と情報を提供する必要があります。 また、データ製品は、常に真実でエラーのないデータを提供する必要があります。
適切に設計された適切に管理されたデータ製品とそのインターフェイスは、組織が、データの重複を回避し、ネイティブの単一の真実のソースを作成するのに役立ちます。
データ製品の設計に関する推奨事項
データ製品の提供要件を満たすために、ドメイン チームは新しいスキル セットを取得し、新しいツールとプラットフォームを使用する必要があります。
データ アプリケーションを構築し、データ製品を生成または提供できるように、ドメイン アプリケーション チームに完全な装備を提供します。 チームは、使い慣れたテクノロジ スタックを使用してデータ製品を構築できます。 また、可能であれば、独自の Spark インスタンスまたはパイプライン エンジンの使用を選択することもできます。 たとえば、多くのデータ製品を提供する大規模なドメインでは、独自の Azure Synapse Analytics からデータ製品を処理して提供することを決定する場合があります。 小規模な組織や大企業の小規模なドメインでは、中央に配置された Azure Data Factory、Azure Synapse Analytics、Azure Databricks などの共有プラットフォーム上でデータ アプリケーションを開発して実行することを決定する場合があります。
データ製品に、この記事で説明されている一般的な特性があること、データ系列リポジトリにデータ アプリケーションの系列が反映されていること、および実装とアクセスが管理されていることを確認します。
Azure のデータ製品とデータ アプリケーションのガイダンス
ドメイン アプリケーション チームが共有プラットフォームと一連のサービスを使用している場合は、Azure データ ランディング ゾーン内のデータ アプリケーション環境に考えられるすべてのアプローチを配置できます。
「Azure でのクラウド規模の分析データ製品- サンプル データ アプリケーション」に、Azure データ ランディング ゾーン用の 3 つの異なるデータ アプリケーション パターン テンプレートが記載されています。