數據可觀察性
數據可觀察性是藉由收集和相互關聯數據、記憶體、計算和處理管線等區域的事件，來瞭解數據和數據系統的健康情況。
建置及操作彈性、可調整且高效能的數據平臺，需要跨代表功能網域的小組採用經過實證的DevOps啟發程式。 數據可觀察性可讓企業擁有者、DevOps 工程師、數據架構設計人員、數據工程師和網站可靠性工程師將問題偵測、預測和預防自動化，並避免停機而中斷生產分析和 AI。
數據可觀察性的主要領域
大部分的數據平臺都會在數據可觀察性的重要區域上運作：
端對端數據可觀察性不僅牽涉到擷取事件和測量所有元件中的計量，而且會相互關聯這些事件和計量。 這可讓您全面檢視企業數據環境的健康情況和可靠性。
本文說明每個元件，以及它如何促成數據可觀察性。
數據平臺服務監視
企業數據平臺的基礎基礎結構可以包含提供者管理的基礎結構和自我管理基礎結構的混合，以啟用記憶體和運算。 DevOps 工程師或基礎結構工程師必須監視此基礎基礎結構，以便識別並解決影響新式數據和分析管線的系統中斷和效能瓶頸。
監視資料庫和網路層的數據可以改善處理輸送量，並將網路等待時間降到最低。 Teams 需要工具，可用來擷取計量、通知、追蹤和補救事件，並與數據和分析問題相互關聯。
我們建議您的小組在建立資源時立即將可檢視性即程式代碼納入基礎結構即程式代碼層，以便立即啟用監視檢測。 大部分的 Azure 服務都會針對診斷數據等重要資源計量提供現用的檢測。
數據管線效能監視
包含多個階段和相依性的數據管線越來越複雜，現在會產生大量的監視數據。 此數據報含事件、計量和記錄。 您可以藉由收集和分析監視數據來優化數據管線效能。
您的數據小組應該追蹤跨多個相關數據產品和商務網域的數據管線狀態。 當小組在早期收到超過預期之失敗或運行時間的通知時，他們可以將停機時間降到最低並補救。 管線監視數據和平臺服務監視的相互關聯可以提供效能微調的建議，例如提升高負載管線的CPU和記憶體。
數據質量監視
數據質量是數據正確、完整、及時且符合組織需求的程度。 您必須持續監視數據集的品質，以確保它們所提供的數據應用程式保持可靠且值得信任。 DataOps 一直藉由自動化數據質量測試（單元、功能和整合）來持續改善數據可靠性和效能。 這些改進可讓錯誤偵測和數據分析更快且更有效率。
若要將 DevOps 和 SRE 原則納入數據品質，小組必須建置可重複、反覆的程式和架構，以攔截數據品質問題、追蹤儀錶板中的問題，以及針對任何偏差設定警示。
偵測時間（TTD）、復原時間（TTR）和其他數據品質計量可以從數據品質監視中追蹤。 TTD 是指數據小組偵測任何類型的數據質量問題所花費的時間長度，從新鮮度異常到中斷整個管線的架構變更。 TTR 是指小組在警示后解決數據事件所需的時間長度。 改善數據品質不僅僅是技術挑戰;它涉及重要的組織和文化支援。
數據品質的治理區段會探索如何在案例中實作數據品質。
資料譜系
數據譜系被廣泛理解為追蹤數據來源、轉換和在數據資產中一段時間移動的連續記錄。 數據譜系用於回顧性工作，包括疑難解答、偵錯和追蹤管線問題的根本原因。 譜系也用於數據分析、合規性和「假設狀況」案例，通常稱為 影響分析。
譜系會以可視化方式呈現，以顯示從來源移至目的地的數據，包括隨著時間轉換數據的方式。
數據譜系的治理區段會探索如何在案例中實作數據譜系。
資料探索
數據探索是取用者數據分析或數據控管工作負載的第一個步驟。 在企業 Data Lake 平臺中，數據取用者（例如數據科學家和分析師）很難找出所需的數據，並評估其可靠性。 具有精確元資料的數據目錄可讓搜尋更容易使用提供的數據索引：
- 可用數據的位置
- 數據品質偵測
- 數據結構瞭解
- 數據譜系理解
- 存取所需的數據
提供這些搜尋功能的數據目錄可提升所有數據探索程式的速度。
數據目錄的治理區段會探索如何在案例中實作數據探索。
設定 SLA、SLA 和 SLA
貴組織的小組可以採用 DevOps 樣式的網站可靠性工程 （SRE） 作法來進行數據監視。 服務等級協定（SLA）、服務等級指標（SLA）和服務等級目標（SLO）可協助您的組織減少停機時間，並確保數據的數據可靠性。
服務等級協定 （SLA）
SLA 需要定義完善的 SLA，這是服務品質的量化量值，以及同意的 SLO，這是每個 SLI 應符合的理想值或範圍。
設定數據 SLA 需要所有將受到 SLA 影響的利害關係人積极參與和共同作業。 這些項目關係人可以包含數據產生者、數據工程師、數據分析師、數據取用者、商務分析師和其他專案。
設定可靠性 SLA 通常包含三個步驟：定義、測量和追蹤。
藉由定義可靠性的意義，開始設定 SLA。 所有重要的項目關係人都必須就此定義達成一致。 請確定每個重要的項目關係人都參與並購買，特別是當您的下游取用者來自不同的小組或不同的地理區域和時區時。
您的 SLA 必須經過精心製作。 如果數據取用者是外部付費客戶，請洽涉到您的法律小組。 針對內部客戶，您的 SLA 定義應包含數據承諾、數據品質等重要領域，以及不符合承諾時處理數據事件的程式。
SLA 範例
假設 Contoso 是一家執行企業數據湖的媒體公司，而此 Data Lake 可跨不同的商務領域提供多個數據產品。 Contoso 的數據應用程式小組負責提供支援 Contoso 銷售儀錶板的前一天銷售數據。 當他們錯過數據傳遞或傳遞不完整的數據時，數據工程小組會面臨受挫高管的電子郵件，且必須手動分級應該傳遞銷售數據的中斷管線。 為了測量和改善其交付專案，數據小組會設定與銷售小組的 SLA，如下一節所示。
服務等級協定 - 數據小組至銷售小組
| 合約 | 描述 |
|---|---|
| 商務區域 | 數據小組承諾賦予銷售小組做出數據驅動決策的能力 |
| 承諾 | 數據小組承諾提供提供銷售儀錶板的前一天銷售數據。 此數據可為所有美國區域提供銷售和轉換率。 數據管線會在 6：00 UTC 之前提供數據給銷售儀錶板 |
| 數據品質 | Null 檢查： 客戶名稱不可為 Null。 遺漏值： 客戶區域無法遺失。 新鮮度： 銷售日期應包含UTC 24：00之前的任何交易 |
| 數據事件管理 | 如果不符合上述數據傳遞承諾，銷售小組可以回報問題，而數據小組承諾使用TTR < 6小時解決問題 |
服務等級指標 （SLA）
SLA 應該一律符合或超過 SLA 中所述的 SLA。 設定 SLI 時，請從識別您可以追蹤和測量的重要計量開始，以達成您同意的 SLA。
SLI 範例
假設 Contoso 的數據小組會識別來自不同區域的重要計量，以符合上一個範例中所述的 SLA。 它們也會建置儀錶板、設定重要計量是否偏離設定基準的警示，以及將動作自動化以減輕某些問題。
| 計量 | 目的 |
|---|---|
| Spark 叢集 CPU 和記憶體使用量 | 在用來執行數據管線的基礎結構中測量任何效能瓶頸 |
| 管線總運行時間以分鐘為單位 | 測量管線是否需要比預期更多的時間來執行 |
| 管線失敗和成功率 | 測量管線失敗或成功次數 |
| 資料品質計量（下游） | 確保數據管線所傳遞的數據符合預期 |
| 資料品質計量（上游） | 確保符合原始數據品質的上游減數 |
| 轉換元數據更新 | 確保從上游到下游的譜系包含套用至數據之所有轉換的相關元數據 |
| 下游數據索引編製和更新 | 確保銷售小組探索所有為儀錶板提供動力的數據集 |
| 測量 TTD 和 TTR 的已定義程式 | 測量 TTD 和 TTR，並確保 TTR < 6 小時 |
服務等級目標 （SLO）
SLO 包含 SLI、測量 SLI 的持續時間，以及實際可達成的目標成功率。 一開始，定義您的方向和目標成功可能是一項壓倒性的工作。 不要期望完美，而是在多個反覆項目上穩步改善。
SLO 可以相依於：
- 數據產品
- 資料類別
- 資料來源區域
- 數據可觀察性元件
SLO 範例
假設 Contoso 的數據小組跨七個不同的 美國 區域提供銷售數據。 每個日曆年度都會傳遞 210 個數據集，而且只有 200 個數據集已完成且符合 SLA。 這些成功的交付會轉化為該年 95.99% 的成功率。 10 個失敗（不完整）數據集以可接受的錯誤率發生 4%。
數據小組會建立監視儀錶板，追蹤匯總的 SLO，以在 30 天內監視此 SLO。 當目標成功率未達到時，數據小組和銷售小組都會收到通知。
數據可觀察性成熟度模型
數據可觀察性是 DataOps 架構中不可或缺的一部分，應該視為與改善組織 DataOps 程式的工作平行。 下列成熟度模型可協助您評估數據可觀察性的目前狀態，並決定旅程的後續步驟。
| 階段 | 數據平臺服務監視 | 數據管線效能監視 | 數據質量監視 | 資料譜系 | 資料探索 |
|---|---|---|---|---|---|
| 階段 5 （高度進階） | 數據會從統一檢視中的一或多個數據產品收集到所有數據可觀察性元件，並使用機器學習來尋找任何異常狀況相互關聯。 儀錶板會追蹤所有數據可觀察性元件的 SLO、SLI 和 SLA。 | 數據管線效能計量會追蹤多個數據產品。 根本原因分析已完成，並由系統驅動。 | 已建立對數據品質的高階信任。 數據取用者可以驗證數據的可靠性。 | 數據譜系會以可視化方式呈現，並透過多種方式使用，例如追蹤管線失敗的根本原因、數據品質分析和合規性。 | 數據取用者可以輕鬆地找到所需的可用數據。 |
| 階段 4 （進階） | 儀錶板會追蹤最重要數據可觀察性元件的 SLO、SLI 和 SLA。 平臺監視數據和管線效能監視數據會使用自動化相互關聯。 | 數據事件工具會監視和測量任何事件的TTD和TTR計量。 | 數據品質是透過跨多個數據產品使用且使用儀錶板追蹤的架構來維護。 | 數據譜系包含數據品質標籤，且已連線到數據可探索性。 | 數據譜系現在已連線到數據可探索性，也包含數據質量標籤。 |
| 階段 3 （進化） | 定義完善的 SLO、SLI 和 SLA 幾乎涵蓋數據可觀察性的所有元件。 數據事件是使用特殊化工具進行管理。 | 平臺監視數據會與使用某種程度的自動化進行數據管線效能監視相互關聯。 | 數據品質檢查已妥善定義並對應至自定義計量。 | 數據譜系已成熟，以包含決策所需的足夠元數據。 | 數據探索能力是使用特製化數據目錄工具達成的。 |
| 階段 2 （規劃） | SLO、SLI 和 SLA 的初始草稿涵蓋數據可觀察性所需的最重要元件。 平臺監視數據是集中式的，而且整個數據環境都有統一的檢視。 所有數據事件管理都是手動的。 | 數據管線效能計量是定義和測量的。 | 數據質量檢查存在，但未定義、測量和可視化標準計量。 | 數據譜系僅限於單一數據產品或未追蹤。 | 數據可探索性已達成，但不會使用複雜的工具。 |
| 階段 1 學習 | 每個重要的平台服務（提供者管理和自我管理）都會在數據環境中受到監視。 | 管線監視最少。 失敗會觸發警示，但沒有任何可能原因的見解。 | 您可以從管線執行數據質量測試，但不會測量或追蹤任何計量。 | 數據譜系不存在。 | 數據可探索性不存在。 |