什麼是資料產品？
每個應用程式都會暫時或永久建立及儲存資料。 許多應用程式也會針對作業管理目的建立和儲存資料，例如錯誤記錄和健康情況監視。 集中式資料小組會使用 ETL 程式來取用和處理這些應用程式所產生的資料。 應用程式作業小組通常會有額外的資料處理流程，例如應用程式健康情況和 KPI 狀態監視。
資料整合中團隊和責任瀑布的傳統方法並不理想。 這可能會導致知識差距、擁有權問題，以及影響使用者資料品質、時程表和價值通訊衝突。 應用程式小組負責應用程式效能和成功。 在其工作中，他們需要對其他小組所擁有的下游程式進行變更，但這些變更通常不會根據計畫進行。 例如，您可能會發現所謂的次要上游變更大幅改變 KPI 的趨勢。 這類資料問題可能會影響您做出重大決策的能力。
資料網格方法可藉由採用資料的概念作為產品來防止這些問題。 應用程式擁有者和應用程式小組會將資料視為其負責的完整產品，而不是由其他人管理之程式的產品。 應用程式和分析資料服務工作都在領域責任區域內。
資料產品是專為分析取用而建立。 它們已定義並同意圖形、取用介面，以及維護和重新整理週期，其中所有都記載。
資料產品會透過 SLO 中的介面，處理與下游進程共用的網域資料資產/資料集。 除非另有需要，否則原始資料應該經過處理、成形、清理、匯總和正規化，以符合已同意的服務品質標準，才能供取用。
下列各節概述良好資料產品具有的常見特性。
資料產品特性
設計良好的資料產品如下：
可探索、可瞭解且值得信任： 網域小組藉由共用和更新每個資料產品、其資料、其意義、其形狀的格式，以及其重新整理週期，來提供可探索性和瞭解性。 它們會及時將資料變更或圖形傳達給下游取用者。 介面可藉由提供資料產品圖形的時間界限回溯相容性，以確保值得信任。
可定址、可原生存取且安全： 用來尋找和取得每個資料產品存取權的已定義程式可提供可定址性。 已針對不同的存取需求採取必要的安全性措施。 資料欄擁有權心態會從閘道管理員資料轉移到使用定義完善的安全性預防措施來提供資料。 提供的存取介面已妥善記載，而且可能會因不同技術而異。 原生存取資料產品的常用介面包括 API、資料庫使用者、資料表或檢視，以及具有必要存取權限的檔案。
互通、真實且有價值： 資料會遵循定義的一般標準來提供互通性，例如相同的值一律具有相同的名稱和資料類型。 例如，包含客戶識別資料的資料行可能會在每個資料產品中標題為 CustomerID ，而且其資料可能一律是整數，或在每個實例中使用snake_case或 camelCase。 資料產品為客戶提供價值，而且也可以作為相同或不同網域中新資料產品的上游來源。 不過，您不只要在多個位置攜帶並複製相同的資料產品。 來自先前資料產品的每個資料產品都應該提供新的價值和資訊給下游取用者。 資料產品也必須一律提供真實、非錯誤的資料。
妥善設計、妥善維護的資料產品及其介面可協助組織避免複製資料，並有助於建立原生單一事實來源。
資料產品設計建議
若要滿足資料產品服務需求，您的網域小組必須取得一組新的技能，並使用新的工具和平臺。
為您的領域應用程式小組提供完整的功能，以建置資料應用程式，並產生或提供資料產品。 您的小組可以使用熟悉的技術堆疊來建置資料產品。 如果可行，他們也可能偏好有自己的 Spark 實例或管線引擎。 例如，提供許多資料產品的大型領域可能會決定處理資料產品，並從自己的分析Azure Synapse服務資料產品。 較小的組織和較小的大型企業網域可能會決定在共用平臺上開發和執行其資料應用程式，例如集中Azure Data Factory、Azure Synapse Analytics 或 Azure Databricks。
請確定您的資料產品具有本文中所述的通用特性，您的譜系存放庫會反映您的資料應用程式歷程，以及您的實作和存取權受到控管。
Azure 的資料產品和資料應用程式指引
如果您的網域應用程式小組使用共用平臺和一組服務，您可以在 Azure 資料登陸區域中放置資料應用程式環境的所有可能方法。
您可以在 Azure 中的雲端規模分析資料產品中找到三個不同的資料應用程式模式範本 - 範例資料應用程式。