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