在第一部分中，我們將介紹什麼是資料產品，它們與產品團隊建立的傳統服務有何不同，並總結一些有助於創建成功資料產品的要求。
什麼是數據產品？
數據產品是精心策劃的數據集，被視為生產服務。它們不是公開 並使用正在運行的伺服器處理請求，而是部署到共用檔案系統、物件儲存或資料庫。
例如，訂閱電子商務企業可能會在
資料庫表中發布其使用者帳戶狀態和活動的每月摘要。或者，分析公司將儲存跨平台瀏覽和購買活動作為預測模型的輸入特徵。
理想情況下，數據產品為其消費者提供一系列保證。
SLO 和所有權保證
與其他產品一樣，我們希望向消費者保證，透過依賴該產品，他們自己的產品不會受到不利影響。
這通常涉及提供一組 SLO——一組具有可衡量目標的目標。通常，這些SLO反映服務行為：可用性（例如，每月正常運行時間）、錯誤率（每月呼叫百分比、總體回應比率）和延遲（每個百分位的毫秒數）。
然而，數據產品具有不同的風
險因素，並且通常對上述因素不太敏感。稍後我們將討論常見的部署模式，但在大多數情況下，底層資料系統（例如 S3 或 Snowflake）會為我 阿聯酋 WhatsApp 號碼數據 們處理這些 SLO。
我們關心的數據產品 SLO 與所提供的數據有關：
多久更新一次？它有多過時？ （新鮮）
數據必須有多正確？如果突然一半的行突然包含空值，則更難信任（正確性、資料完整性）
如果出現問題，人們應該多快做出回應並修復它？ （事件回應時間）
開發者經驗
雖然 SLO 定義了在生產環境中使用數據產品的風險，但我們也關心採用和建立利用我們的數據產品的有意義、有價值的產品的難易程度。
這需要幾個關鍵組件：
變更管理：就像 API 一樣，資料產品可能會以向後不相容的方式變更某些內容。架構變更是最常見的類型：重新命名現有欄位需要變更使用該欄位的每個相關查詢。
為了使服務有用，我們需要
製定一個關於如何管理這些服務以及如何傳達它們的策略。對於服務，通常使用版本控制：如果我現有的 API 在/api/v1下提供 和互動內容的價值。這也是為您的品牌 服務，並且我想引入重大更改，我將添加另一個端點/api/v2並提供一個棄用窗口，在此期間我都會支持兩者。最終，在給予消費者足夠的時間來相應修改其程式碼後，v1 將被刪除。
文件、元資料和結構：好的產品可
以輕鬆上手，並為高級用戶提供足夠的信息，以最大限度地提高他們從產品中獲取的價值。
資料產品的行為應該是相同的：如果我 加拿大數據 們的表格遵循廣泛使用的列名稱和含義等約定，表之間正確設計的關係和有意義的實體名稱，那麼臨時探索就會變得更加容易。
最後，好的數據產品也是可發現的，這意味著它們很容易在組織內找到和推理。這通常意味著我們有一個很好的資料發現故事，並且我們保留描述資料屬性的正確元資料：
模式
資料樣本
列的可能值
重要列的統計分佈
描述此數據源自何處的沿襲訊息
SLO 和提供的保證（見上文）
數據產品與微服務
對許多組織來說，常見的模式是建立小型、專注的產品團隊。這些是自給自足的，包括所有必要的技能：產品經理、技術主管、後端工程師，有時還包括前端或全端工程師。這些小團隊能夠快速、獨立地執行，將 Web 服務作為他們與外界的契約公開。