提升資料可靠性實踐

– 13 分鐘閱讀

在資料驅動的時代，資料可靠性攸關企業成敗。本文將探討如何透過服務水平協定（SLA）、服務水平指標（SLI）和服務水平目標（SLO）確保資料可靠性，並以 Blinkist 案例說明如何應對資料挑戰。同時，我們也將深入研究事件管理流程，提供 Python 程式碼範例和流程圖，以協助讀者建立有效的資料品品檢查機制。最後，我們將探討資料可靠性的未來發展趨勢，幫助企業應對日益增長的資料挑戰。

衡量資料品質的投資回報率（ROI）

不可靠的資料可能導致時間浪費、收入損失、合規風險以及客戶信任的喪失。根據對Monte Carlo數百位客戶的調查，我們發現資料長官者表示，他們的資料科學家和工程師花費了40%或更多時間來排查或處理資料問題。Gartner估計，公司每年在資料停機（data downtime）上的花費高達1500萬美元，而超過88%的美國企業因資料品質問題而損失金錢。此外，五分之一的公司因資料品質問題而失去客戶。

計算資料停機的成本

在改善資料品質之前，衡量不良資料品質的影響並明確哪些資料集對組織最重要是至關重要的。正如您可能知道的，並非所有資料都具有相同的價值，但瞭解關鍵資料資產對業務的影響，將有助於向利害關係人傳達資料品質的重要性。

量化資料品質的價值

量化並傳達資料品質的價值是一項複雜的工作。我們發現，以下從DevOps實踐者借鑒的指標提供了一個良好的起點：檢測時間（Time to Detection, TTD）和解決時間（Time to Resolution, TTR）。

檢測時間（TTD）

TTD描述了資料團隊檢測到任何型別的資料品質問題所需的時間，從資料更新異常到導致整個資料管道當機的結構變更。對於許多團隊來說，TTD以天、周甚至月來衡量——因為大多數情況下，資料停機是由下游使用者在儀錶板或報告「看起來不對勁」時首先發現的。

這些時間段的成本極高，因為時間越長，透過重新處理或回填原始資料來還原資料就越困難。此外，每一個依賴錯誤資料的業務決策、行銷活動或產品路線圖更新都需要重新驗證或通知利害關係人。

解決時間（TTR）

TTR指的是團隊在收到警示後能夠解決資料事件的速度。這可以是分鐘、小時或天，取決於事件的複雜性、資料血統的可用性、資料發現或目錄的健全性以及可用資源。TTR指標使您能夠瞭解資料問題的嚴重性並跟蹤解決所需的時間。透過轉換為美元——也就是說，闡明因TTR而花費或節省的金額——可以更容易地向利害關係人傳達這次資料停機的影響：

(TTD小時 + TTR小時) × 停機每小時成本 = 資料停機成本

停機每小時成本

停機每小時成本是一個通用指標，用於表示每個停機小時所花費的工程時間以及資料停機對資料消費者和業務決策的影響。

def calculate_downtime_cost(ttd_hours, ttr_hours, downtime_hourly_cost):
    total_hours = ttd_hours + ttr_hours
    return total_hours * downtime_hourly_cost

# 使用範例
ttd_hours = 10  # 檢測時間（小時）
ttr_hours = 5  # 解決時間（小時）
downtime_hourly_cost = 300  # 停機每小時成本（美元）
downtime_cost = calculate_downtime_cost(ttd_hours, ttr_hours, downtime_hourly_cost)
print(f"資料停機成本：${downtime_cost}")

內容解密：

此程式碼計算資料停機的總成本。首先定義了一個函式calculate_downtime_cost，它接受三個引數：ttd_hours（檢測時間）、ttr_hours（解決時間）和downtime_hourly_cost（停機每小時成本）。在函式內部，計算總時間（total_hours）為ttd_hours和ttr_hours的總和。然後，將total_hours乘以downtime_hourly_cost來得出資料停機的總成本。最後，提供了一個使用範例，展示如何呼叫此函式並列印結果。

工程時間的成本可以根據停機小時數來計算。例如，我們可以估計，一位資料工程師在每個停機小時中花費四分之一的時間來監控和調查問題，這貢獻了約14.75美元的停機每小時成本（根據ZipRecruiter的美國資料工程師薪資資料，平均每小時59美元的薪水加上福利）。隨著時間的推移和技術債的積累，停機成本只會增加。

更新資料停機成本以反映外部因素

您的年度資料停機成本可以透過解決問題所需的工程或資源成本來近似計算。我們認為，正確的公式應該考慮到處理這些問題的勞動成本、您的合規風險（我們可以使用平均一般資料保護法規（GDPR）罰款來量化此風險），以及因失去利害關係人對您資料的信任而產生的機會成本。

根據現有資料以及對超過150個不同行業的資料團隊進行的訪談和調查，我們估計資料團隊花費了30%到40%的時間處理資料品質問題，而不是從事創造收入的活動。

def estimate_annual_downtime_cost(downtime_hours_per_month, downtime_hourly_cost):
    months_in_a_year = 12
    return downtime_hours_per_month * downtime_hourly_cost * months_in_a_year

# 使用範例
downtime_hours_per_month = 100  # 每月停機小時數
downtime_hourly_cost = 300  # 停機每小時成本（美元）
annual_downtime_cost = estimate_annual_downtime_cost(downtime_hours_per_month, downtime_hourly_cost)
print(f"年度資料停機成本：${annual_downtime_cost}")

內容解密：

此程式碼估計年度資料停機成本。定義了一個函式estimate_annual_downtime_cost，它接受兩個引數：downtime_hours_per_month（每月停機小時數）和downtime_hourly_cost（停機每小時成本）。函式內部，將downtime_hours_per_month乘以downtime_hourly_cost和一年中的月份數（12）來計算年度資料停機成本。範例展示瞭如何呼叫此函式並列印結果。

如何為你的資料設定SLA、SLO和SLI

如同DevOps領域中的做法，我們可以借鑒其經驗來設計資料系統的可靠性。網站可靠性工程師使用諸如SLA（服務水平協定）、SLI（服務水平指標）和SLO（服務水平目標）等框架來減少應用程式的停機時間並確保可靠性。本文採訪的多個資料團隊已經開始在其組織中實施這些框架，以優先考慮、標準化和衡量資料可靠性。

為什麼需要SLA、SLO和SLI

本質上，公司使用SLO來定義和衡量特定產品、內部團隊或供應商將交付的SLA，以及未達到這些SLA時的潛在補救措施。例如，Slack向其Plus計劃及以上的客戶承諾每季度99.99%的正常執行時間——如果他們未達到這一目標，Slack將在其帳戶中提供服務積分供未來使用。

許多軟體團隊制定內部SLO，以幫助工程、產品和業務團隊協調他們對應用程式最重要的方面，並優先處理傳入的請求。將SLO正式化的過程——而不是依賴每個人的最佳努力，爭取盡可能接近100%的正常執行時間——有助於設定明確的期望。有了這些SLO，工程團隊及其利益相關者可以確定他們關注的是相同的指標，使用相同的語言。

資料可靠性中的SLA、SLO和SLI

同樣，SLA可以幫助資料團隊及其消費者定義、衡量和跟蹤資料在其生命週期中的可靠性。設定資料可靠性SLA可以在你的資料、資料團隊和下游消費者之間建立信任。如果沒有達成一致的SLI，消費者可能會對資料的可靠性做出不準確的假設，或根據軼事證據進行判斷。有了SLO，您的組織可以變得更加“資料驅動”地處理資料。

def calculate_data_reliability_sla(uptime_percentage, total_time):
    """
    計算資料可靠性的SLA
    
    :param uptime_percentage: 正常執行時間的百分比
    :param total_time: 總時間
    :return: sla 值
    """
    # 計算停機時間
    downtime = total_time * (1 - uptime_percentage / 100)
    # sla 計算邏輯
    sla = uptime_percentage
    return sla

# 使用範例
uptime_percentage = 99.99  # 百分比
total_time = 365 * 24 * 60 * 60  # 一年的秒數
sla_value = calculate_data_reliability_sla(uptime_percentage, total_time)
print(f"SLA值: {sla_value}%")

內容解密：

此程式碼片段定義了一個函式calculate_data_reliability_sla，用於計算資料可靠性的SLA。該函式接受兩個引數：uptime_percentage（正常執行時間的百分比）和total_time（總時間，單位為秒）。首先，程式碼計算停機時間，方法是從總時間中減去正常執行時間（透過將uptime_percentage除以100轉換為小數後乘以total_time）。然後，將sla值設為uptime_percentage，直接傳回這個百分比作為SLA值。這表明在這個簡化的範例中，SLA直接等同於設定的正常執行時間百分比。

設定資料SLA的步驟

  1. 盤點業務優先事項：瞭解業務的優先目標。
  2. 評估業務優先事項如何與資料分析相關聯：分析這些目標如何依賴於資料分析。
  3. 瞭解消費者對高資料品質的需求/對不良資料的容忍度：收集消費者對資料可靠性的期望。
  4. 相應地設定SLO，並尋求利益相關者的反饋和一致意見：根據前述步驟的結果設定SLO，並與相關利益相關者溝通。
  5. 衡量SLO：持續監測和評估設定的SLO。

定義資料可靠性

設定SLA首先需要就可靠資料對業務的意義達成一致並明確定義。我們建議首先對資料進行清點，瞭解其使用方式和使用者——評估資料的歷史表現以獲得可靠性的基準指標。

  graph LR;
    A[開始] --> B{定義資料可靠性};
    B -->|是| C[收集資料使用情況];
    B -->|否| D[重新評估];
    C --> E[評估歷史表現];
    E --> F[設定SLA];
    F --> G[衡量SLO];

圖表翻譯： 此圖表呈現了定義資料可靠性和設定SLA的流程。首先，需要定義什麼是可靠的資料，接著收集資料的使用情況和評估其歷史表現。根據這些資訊，可以設定SLA並衡量SLO，以確保資料的可靠性。

確保資料可靠性的三大步驟：從SLA到SLO的實踐

在現代資料驅動的商業環境中，資料可靠性已成為企業成功的關鍵因素。為了確保資料的可靠性，企業需要建立完善的服務水平協定（SLA）、服務水平指標（SLI）以及服務水平目標（SLO）。本文將探討如何透過這三大步驟來確保資料可靠性，並透過實際案例進行分析。

步驟一：建立資料可靠性的基準與SLA

要確保資料可靠性，首先需要建立明確的基準和服務水平協定（SLA）。SLA是企業與資料消費者之間的契約，定義了資料的可靠性標準以及相關的責任。

建立基準的關鍵要素

  1. 定義資料可靠性：企業需要明確定義什麼是可靠的資料。這包括資料的準確性、完整性、時效性等指標。
  2. 瞭解資料消費者的需求：透過消費者訪談，瞭解資料使用者的需求和期望，從而確定資料可靠性的具體要求。
  3. 建立SLA：根據資料消費者的需求，制定明確的SLA，定義資料可靠性的標準和責任歸屬。

步驟二：使用SLI衡量資料可靠性

在建立SLA之後，下一步是定義服務水平指標（SLI），用於衡量資料的可靠性。SLI是具體的量化指標，用於評估資料是否符合SLA的要求。

常見的SLI指標

  1. 特定資料資產的事件數量（N）：衡量特定資料資產發生的事件數量，反映資料的穩定性。

    SELECT COUNT(*) 
FROM data_incidents 
WHERE data_asset = 'specific_asset';

    內容解密：

    • 這段SQL陳述式用於計算特定資料資產的事件數量。
    • data_incidents 表儲存了所有資料事件的記錄。
    • COUNT(*) 用於統計符合條件的記錄數。

  2. 關鍵表的更新頻率：衡量關鍵資料表的更新頻率，確保資料的時效性。

    SELECT MAX(updated_at) 
FROM critical_table;

    內容解密：

    • 這段SQL陳述式用於查詢關鍵資料表的最後更新時間。
    • MAX(updated_at) 傳回最新的更新時間。

  3. 資料集的預期分佈：檢查資料集是否符合預期的分佈範圍，異常分佈可能指示潛在問題。

    import pandas as pd

data = pd.read_csv('data_set.csv')
mean = data['value'].mean()
std_dev = data['value'].std()

print(f"Mean: {mean}, Standard Deviation: {std_dev}")

    內容解密：

    • 這段Python程式碼用於計算資料集的平均值和標準差。
    • pandas 函式庫用於資料處理。
    • 平均值和標準差可以用於判斷資料分佈是否正常。

步驟三：使用SLO跟蹤資料可靠性

一旦定義了SLI，下一步是設定服務水平目標（SLO），即資料可靠性的目標範圍。SLO根據實際情況，定義了可接受的資料停機時間範圍。

設定SLO的關鍵步驟

  1. 根據SLI設定SLO：根據定義的SLI指標，設定具體的SLO目標，定義可接受的資料可靠性範圍。
  2. 建立統一的評估框架：根據SLO，建立統一的事件嚴重性評估框架，以便快速回應資料事件。
  3. 建立監控儀錶板：使用監控工具或專門的資料可觀測性工具，建立儀錶板跟蹤資料可靠性。

案例研究：Blinkist的資料可靠性實踐

Blinkist是一家電子書訂閱服務公司，擁有超過1600萬使用者。為了實作業務成功，Blinkist需要確保資料的可靠性和實時性。以下是他們的實踐經驗：

面臨的挑戰

  1. 缺乏實時資料跟蹤：由於缺乏實時資料，導致行銷支出減少。
  2. COVID-19疫情的影響：疫情導致歷史資料無法反映當前現實，影響行銷策略的制定。

解決方案

  1. 建立資料可靠性指標：定義了資料可靠性的SLI指標，衡量資料的時效性和準確性。
  2. 設定SLO目標：根據SLI指標，設定了具體的SLO目標，定義可接受的資料停機時間。
  3. 實施資料可觀測性工具：使用資料可觀測性工具，建立監控儀錶板，跟蹤資料可靠性。

資料可靠性的關鍵：事件管理與解決方案

在現代企業中，資料已經成為決策的關鍵依據。無論是即時資料還是歷史資料，都對企業的營運至關重要。然而，資料品質問題卻時常困擾著資料團隊。這些問題不僅影響營運決策，還可能導致企業損失信任和收入。在本章中，我們將探討如何透過事件管理和解決方案來提升資料品質。

資料品質的重要性

在當今數位時代，資料品質對於企業的成功至關重要。無論是行銷策略、產品開發還是客戶服務，都需要依賴準確的資料來進行決策。資料品質問題可能源於多個方面，包括資料來源、資料處理流程和資料儲存方式等。這些問題可能導致企業做出錯誤的決策，從而影響業務的正常運作。

案例研究：Blinkist 的資料可靠性挑戰

Blinkist 是一家提供非小說類別書籍摘要服務的公司，他們面臨著嚴重的資料可靠性挑戰。隨著業務的快速增長，資料團隊需要處理越來越多的資料。然而，由於資料品質問題，資料團隊經常需要花費大量時間來解決資料相關的問題。這些問題包括資料品質不佳、儀錶板更新延遲和資料管道故障等。

Blinkist 的資料工程團隊負責人 Gopi 表示，他的團隊花費了 50% 的工作時間來解決資料相關的問題。這種情況不僅影響了團隊的工作效率，也降低了企業對資料的信任度。為瞭解決這些問題，Gopi 和他的團隊實施了一套嚴格的資料測試和可觀察性框架，追蹤關鍵的資料 SLA 和 SLI。

資料可靠性的三個關鍵要素

要實作資料可靠性，需要關注三個關鍵要素：

  1. 投資於受 DevOps 啟發的流程：這包括資料測試和可觀察性。透過這些流程，可以及時發現和解決資料品質問題。
  2. 建立一個具有彈性和效能的資料平台：這需要選擇合適的資料儲存和處理技術，並確保資料平台的擴充套件性和可靠性。
  3. 設定和協調跨組織的資料 SLA、SLI 和 SLO：這需要與企業內的其他團隊協調，設定清晰的資料可靠性目標和指標。

事件管理與解決方案

當資料品質問題發生時，需要有一套有效的事件管理與解決方案。參考 DevOps 和 SRE 的實踐，可以建立一個完整的事件管理流程。

DevOps 生命週期

DevOps 生命週期是一個連續的流程，包括八個階段：

  1. 計畫：與產品和業務團隊協調，瞭解軟體的目標和 SLA。
  2. 編碼：編寫新的軟體。
  3. 建置：將軟體釋出到測試環境。
  4. 測試：測試軟體。
  5. 釋出：將軟體釋出到生產環境。
  6. 監控：監控軟體的效能和可靠性。
  7. 反饋：收集使用者反饋，進行改進。
  8. 最佳化：最佳化軟體的效能和可靠性。

事件管理流程

事件管理流程可以參考 DevOps 生命週期，建立一個完整的事件管理流程：

  1. 檢測：及時檢測資料品質問題。
  2. 回應：回應資料品質問題，進行初步的調查。
  3. 分析：分析資料品質問題的原因。
  4. 解決：解決資料品質問題。
  5. 還原：還原資料的正常運作。
  6. 總結：總結事件的經驗教訓。
程式碼範例：資料品品檢查
import pandas as pd

def check_data_quality(data):
    # 檢查資料是否為空
    if data.empty:
        print("資料為空")
        return False
    
    # 檢查資料是否有重複值
    if data.duplicated().any():
        print("資料中有重複值")
        return False
    
    # 檢查資料是否有缺失值
    if data.isnull().values.any():
        print("資料中有缺失值")
        return False
    
    return True

# 載入資料
data = pd.read_csv("data.csv")

# 檢查資料品質
if check_data_quality(data):
    print("資料品質良好")
else:
    print("資料品質不佳")

內容解密：

此程式碼範例展示瞭如何使用 Python 的 pandas 函式庫來檢查資料品質。check_data_quality 函式檢查資料是否為空、是否有重複值和是否有缺失值。如果資料品質不佳，則輸出相應的錯誤訊息。

事件管理流程

  graph LR
    A[檢測] --> B[回應]
    B --> C[分析]
    C --> D[解決]
    D --> E[還原]
    E --> F[總結]

圖表翻譯： 此圖表展示了事件管理流程的各個階段，從檢測到總結，每個階段都與前一階段相關聯，確保事件能夠被及時有效地處理。

隨著資料量的不斷增長，資料可靠性將成為企業面臨的一大挑戰。未來，企業需要不斷改進資料品質和事件管理流程，以確保資料的可靠性和準確性。同時，企業也需要關注新興技術的發展，如人工智慧和區塊鏈，以提升資料的價值和可靠性。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。