資料可靠性成熟度曲線與平台建構

– 15 分鐘閱讀

隨著企業對資料的依賴日益加深，確保資料可靠性成為關鍵挑戰。本文介紹資料可靠性成熟度曲線，從被動式應對問題到可擴充套件的預防機制，逐步提升資料品質管理水平。同時，文章也探討如何建構一個值得信賴的資料平台，強調將資料視為產品的重要性，並分析中心輻射模型的優勢，以兼顧集中管理和分散應用。此外，文章還提供實務案例和程式碼範例，說明如何設定資料可靠性基準指標、選擇自建或採購資料平台，以及明確資料品質的責任歸屬，最終建立一個穩固的資料平台，推動企業的資料驅動決策和業務增長。

  graph LR;
    A[資料收集] --> B[資料處理];
    B --> C[資料儲存];
    C --> D[資料分析];
    D --> E[資料視覺化];
    E --> F[業務決策];

圖表翻譯： 此圖展示了資料從收集到最終用於業務決策的整個流程。首先，資料被收集並進行處理，接著儲存起來供後續分析使用。分析結果透過視覺化的方式呈現，最終用於支援業務決策。這個流程體現了資料在企業中的重要角色，以及如何透過資料驅動決策。

資料可靠性的成熟度曲線：從被動到可擴充套件的進化

在現代資料驅動的企業中，資料品質的管理已經成為企業成功的關鍵因素。隨著企業對資料依賴程度的增加，如何確保資料的可靠性和準確性成為一大挑戰。資料可靠性成熟度曲線提供了一個框架，幫助企業評估和提升其資料品質管理的水平。該曲線將資料品質管理分為四個層級：被動式（Reactive）、主動式（Proactive）、自動化（Automated）和可擴充套件（Scalable）。每個層級代表了企業在資料品質管理上的不同成熟度。

被動式（Reactive）：問題發生後的應對

在被動式階段，團隊大多數時間都花在應對突發的資料問題和排查資料錯誤上。這種模式下，團隊缺乏有效的預防機制，資料問題頻發，嚴重影響業務決策和產品的可靠性。團隊成員疲於奔命地處理突發事件，導致重要專案進展緩慢，組織整體上難以有效地利用資料進行業務決策或推動產品改進。

被動式管理的特點

  • 頻繁的故障應對：團隊需要不斷地處理突發的資料問題，例如資料管道的中斷或資料不一致。
  • 缺乏前瞻性措施：團隊主要是在問題發生後進行排查和修復，而不是預先採取措施防止問題的發生。
  • 業務決策受限：由於資料問題頻發，業務決策往往需要延遲或根據不完整的資訊進行。

主動式（Proactive）：建立檢查機制

主動式團隊開始在資料管理過程中引入手動檢查和自定義的品質驗證查詢，以提前發現潛在問題。例如，團隊可能會驗證資料管道關鍵階段的行數，或者跟蹤時間戳記以確保資料的新鮮度。雖然偶爾仍會遇到問題，但透過這些主動措施，團隊能夠捕捉到許多潛在的資料問題，從而減少了對下游業務的影響。

主動式管理的改進

  • 手動檢查和自定義查詢：團隊開始建立手動檢查流程，並編寫自定義查詢來驗證資料品質。
  • 跨部門協作：工程師、資料工程師、資料分析師和資料科學家之間開始進行協作，共同推動資料品質的提升。
  • 減少突發事件：雖然問題仍會發生，但透過主動的檢查，團隊能夠及時發現並解決問題，減少了對業務的幹擾。

自動化（Automated）：定期驗證與監控

在自動化階段，團隊開始使用定期的驗證查詢來全面監控資料管道的健康狀況。團隊利用資料健康儀錶板來跟蹤問題、進行故障排除，並向組織內的其他成員提供狀態更新。例如，團隊可能會跟蹤和儲存有關維度和測量的指標，以觀察趨勢和變化，或者在資料攝取階段監控和執行結構檢查。

自動化管理的關鍵

  • 定期的驗證查詢：團隊建立定期的驗證查詢，以全面監控資料管道的健康狀況，確保資料的準確性和一致性。
  • 資料健康儀錶板：利用資料健康儀錶板，團隊可以及時跟蹤和處理資料問題，並與組織內的其他成員分享狀態更新。
  • 趨勢監控：透過跟蹤關鍵指標，團隊能夠觀察資料的變化趨勢，提前發現潛在問題。

可擴充套件（Scalable）：成熟的資料品質管理

在可擴充套件階段，團隊借鑒成熟的DevOps概念，建立了階段性環境、可重用的驗證元件，並實施了硬性和軟性警示機制，以即時監控資料錯誤。團隊對關鍵資料進行了全面的監控和品品檢查，大多數問題能夠在對下游使用者產生影響之前被發現和解決。例如，團隊可能會對所有關鍵指標進行異常檢測，並使用工具監控每個任務和資料表的品質。

可擴充套件管理的特點

  • 全面的監控和警示機制：團隊建立了全面的監控和警示機制，能夠及時發現並處理資料問題。
  • 階段性環境和可重用元件：借鑒DevOps的概念，團隊建立了階段性環境，並開發了可重用的驗證元件，提高了資料品質管理的效率。
  • 高品質的資料管理：透過全面的監控和預警機制，團隊能夠確保資料的高度可靠性和準確性，減少了對業務的影響。

為您的資料組織找到合適的團隊結構

團隊結構對於企業如何日常處理資料有著巨大的影響。不同的企業可能需要不同的團隊結構來滿足其特定的業務需求。集中式的資料團隊負責所有資料管理和應用的事務，或者將分析師嵌入各個業務單元，以滿足特定的需求並取得領域專業知識，但這可能會導致資訊孤島和缺乏統一的治理。

許多資料長官者發現，採用**中心輻射模型（Hub and Spoke Model）**能夠取得最佳的效果。在這種模型中，集中式的資料平台團隊負責基礎設施和資料品質管理，而分散的、嵌入式的分析師和工程師則負責語義層的構建，並將資料應用於業務。這種模式特別適合快速成長的企業，因為它能夠在保持資料品質和治理的同時，靈活應對業務需求。

中心輻射模型的優勢

  • 集中管理與分散應用的結合：中心輻射模型結合了集中式和分散式的優點，既能確保資料品質，又能滿足業務單元的特定需求。
  • 靈活性和可擴充套件性：這種模型能夠隨著企業的成長而靈活調整，適合快速變化的業務環境。
  • 業務價值的最大化：透過集中管理和分散應用，團隊能夠更有效地利用資料推動業務發展，提升整體的業務價值。

案例分析：Toast的資料團隊演變

Greg Waldman是Toast這家餐廳POS軟體公司的商業智慧高階總監，他的團隊經歷了五年的組織架構演變，從集中式到分散式，再到中心輻射模型。在與Greg的討論中，他建議成長型企業的資料長官者遵循產品管理的一個重要原則——保持敏捷：

「我們認為資料團隊應該盡可能地為業務創造價值。我們對變化保持開放態度，並嘗試不同的做法。我們意識到，在200人、500人或1000人的公司中，合適的做法是不同的，這是可以的。當你到達某些關鍵節點時，就需要嘗試新的做法。」

Greg的經驗表明，資料團隊需要根據企業的發展階段調整其結構和工作方式，以最大化業務價值。

分散式分析師的優勢

對於Jessica Cherny來說，分散式分析師和工程師的最大優勢在於他們能夠深入理解業務需求背後的真正原因：

「我想了解如何設計一個真正滿足他們需求的交付成果。最近，有人要求我立即提供一組特定的資料。我問她：『我們真的需要使用這種複雜的聚類別方法來回答這個問題嗎？實際需求是什麼？』透過深入瞭解業務需求，我們最終重新組織了她的請求，並以簡單、易於理解的方式提供了所需的資料。」

將資料視為產品的意義

將資料視為產品並不僅僅是一個流行的趨勢，而是一種有意識的思維轉變，能夠帶來有意義的結果：提高資料的民主化程度和自助服務能力，改善資料品質以支援準確和自信的決策，並在整個組織中擴大資料的整體影響力。

資料產品化的好處

  • 提高資料民主化：透過將資料視為產品，企業能夠提高資料的可存取性和可用性，使更多的人能夠利用資料進行決策。
  • 提升資料品質：資料產品化強調資料的品質和可靠性，從而支援更準確的業務決策。
  • 擴大資料影響力：透過系統化地管理和應用資料，企業能夠在整個組織中擴大資料的影響力，推動業務增長和創新。

總之，資料可靠性成熟度曲線為企業提供了一個清晰的路線圖，幫助企業從被動應對資料問題逐步提升到自動化和可擴充套件的資料品質管理。同時，採用合適的團隊結構，例如中心輻射模型，能夠進一步提升資料管理的效率和業務價值。將資料視為產品的思維轉變，不僅能夠提升資料的品質和可用性，還能夠推動企業的業務增長和創新。

隨著資料在企業中的角色日益重要，資料品質管理將繼續成為企業關注的焦點。未來，我們可以預見更多的企業將採用自動化和可擴充套件的資料品質管理方法，並透過將資料視為產品來推動業務創新和增長。同時，隨著技術的進步，例如機器學習和人工智慧的應用，資料品質管理將變得更加智慧和高效，為企業帶來更大的競爭優勢。

程式碼示例：資料品品檢查

import pandas as pd

# 假設我們有一個包含客戶資料的DataFrame
customer_data = pd.DataFrame({
    'customer_id': [1, 2, 3, 4, 5],
    'name': ['Alice', 'Bob', 'Charlie', 'David', 'Eve'],
    'email': ['alice@example.com', 'bob@example.com', 'charlie@example.com', 'david@example.com', 'eve@example.com']
})

#### 內容解密：
此段程式碼建立了一個包含客戶資料的Pandas DataFrame，包括客戶ID、姓名和電子郵件地址。這是用於示範資料品品檢查的基礎資料集。

# 資料品品檢查：檢查是否有缺失值
def check_missing_values(data):
    missing_values = data.isnull().sum()
    return missing_values

missing_values_report = check_missing_values(customer_data)
print(missing_values_report)

#### 內容解密：
此函式`check_missing_values`用於檢查DataFrame中的缺失值。它使用Pandas的`isnull().sum()`方法來計算每個欄位中的缺失值數量，並傳回結果。這是資料品品檢查中的一個重要步驟，可以幫助我們及時發現並處理缺失資料。

# 資料品品檢查：檢查電子郵件地址的有效性
import re

def check_email_validity(email):
    pattern = r'^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$'
    return re.match(pattern, email) is not None

valid_emails = customer_data['email'].apply(check_email_validity)
print(valid_emails)

#### 內容解密：
此函式`check_email_validity`用於檢查電子郵件地址的有效性。它使用正規表示式來匹配電子郵件地址的格式，確保電子郵件地址的有效性。這是確保資料準確性的另一個重要步驟，可以幫助我們過濾掉無效的電子郵件地址。

資料可靠性成熟度曲線

  graph LR
    A[被動式（Reactive）] --> B[主動式（Proactive）]
    B --> C[自動化（Automated）]
    C --> D[可擴充套件（Scalable）]
    D --> E[持續改進]
    

#### 圖表翻譯：
此圖表展示了資料可靠性成熟度曲線的四個主要階段：被動式、主動式、自動化和可擴充套件。企業可以透過這些階段逐步提升其資料品質管理的水平，從而實作資料的高度可靠性和業務價值的最大化。

在資料平台中建立信任關係

在瞭解將資料視為產品的概念後，我們需要在實踐中實施這種方法。
在第二章中，我們討論了構建資料平台所需的條件，但我們該如何確保：

  1. 團隊使用該平台
  2. 相關利益者信任其輸出結果

換句話說，我們該如何讓利益者將資料平台視為產品？無論您是剛開始還是正在擴充套件資料平台，以下最佳實踐將幫助您避免常見的陷阱並在資料平台中建立信任。

將產品目標與業務目標對齊

幾十年來，資料平台被視為達到目的手段，而非核心產品。
儘管資料平台支援多項服務，為我們生活中的應用程式提供了豐富的洞察，但直到最近才獲得應有的重視和關注。

在構建或擴充套件資料平台時，第一個問題應該是：資料如何與公司的目標相符？
要回答這個問題，您需要扮演資料平台產品經理的角色。與特定產品經理不同，資料平台產品經理必須瞭解整體目標，而非特定領域的目標，因為資料滿足了各個功能團隊的需求，從行銷、招募到業務開發和銷售。

實際案例分析

例如，如果公司的目標是增加收入，那麼資料如何幫助實作這一目標？
讓我們考慮以下問題：

  • 哪些服務或產品推動收入增長？
  • 這些服務或產品收集了哪些資料？
  • 在使用資料之前，我們需要對其進行哪些處理？
  • 哪些團隊需要這些資料？他們將如何使用它？
  • 誰將有權存取這些資料或其分析結果？
  • 這些使用者需要多快獲得資料存取許可權？
  • 平台需要解決哪些合規或治理方面的問題？

透過回答這些問題，您將更好地瞭解如何優先安排產品路線圖，以及需要為哪些人開發（通常是工程師）和設計（日常平台使用者，包括分析師）。
此外，這種全面的KPI開發和執行策略將使您的平台在各團隊中產生更具規模的影響。

取得正確利益者的反饋和支援

毫無疑問，在產品開發過程中獲得初始的支援並在整個過程中獲得反饋，是資料平台開發旅程中的必要組成部分。
然而，人們並不十分清楚應該關注哪些人的意見。

您需要最終從CTO或資料副執行長那裡獲得對成品的認可，但他們的決定往往受到他們信任的顧問的影響，例如：

  • 技術主管工程師
  • 技術專案經理
  • 其他日常資料實踐者

在為公司開發新的資料目錄系統時，我們採訪的一位產品經理花了三個月時間試圖向工程副執行長推銷她的團隊想法，但最終卻被他的幕僚長在一封電子郵件中否決了。

具體實施步驟

我們建議採取以下三個平行步驟：

  1. 向長官層推銷願景
  2. 向實際使用者推銷具體實施方案和日常應用場景
  3. 採取以客戶為中心的方法，無論您正在與誰溝通。將平台定位為資料生態系統中不同使用者角色的賦能工具，包括資料團隊（資料工程師、資料科學家、分析師和研究人員）和資料消費者（專案經理、執行官、業務開發和銷售等）。

優秀的資料平台不僅能讓技術使用者輕鬆高效地工作，還能讓非技術使用者在無需太多工程師和分析師協助的情況下，利用豐富的洞察或建立視覺化報表。

資料平台中的多重角色考量

在為公司構建資料平台時，您需要考慮各種資料角色（圖8-2），從工程師到資料科學家、產品經理、業務功能使用者和總經理。
最終，重要的是，這種體驗能夠培養一個資料愛好者社群，大家共同構建、分享和學習。由於您的平台有可能服務於整個公司，每個人都應該對其成功感興趣，即使這意味著在某些方面需要妥協。

圖表解讀：資料平台中的多重角色

圖8-2展示了在取得支援以構建或擴充套件資料平台時，來自核心使用者和利益相關者的意見至關重要。
來源：圖片由Atul Gupte提供

將長期成長與永續性置於短期利益之上

與其他型別的產品不同，資料平台的成功並不僅僅取決於「搶先上市」。
由於資料平台幾乎都是內部工具，我們發現最好的資料平台是從永續性的角度構建的，而非僅僅追求特定功能。

請記住：您的客戶是您的公司，公司的成功就是您的成功。
這並不是說您的路線圖不會多次變更（它確實會），但當您進行變更時，請以成長和成熟為目標。

實際案例：Uber與LinkedIn的資料平台發展

例如，Uber的大資料平台是在五年內不斷演進的，
Pinterest也經歷了多次核心資料分析產品的迭代，
而領先的LinkedIn自2008年以來一直在構建和迭代其資料平台。

我們的建議是：選擇在您的組織背景下長期有效的解決方案（圖8-3），並將您的計劃與這些期望和截止日期相符。
短期內易於使用的資料解決方案可能更容易啟動，但長期來看，最終會比具有永續性的平台更昂貴。
有時，作為更大產品開發策略的一部分，快速獲勝有助於獲得內部支援——只要這種做法不短視。
羅馬不是一天建成的，您的資料平台也是如此。

圖表解讀：長期與短期考量

圖8-3展示了在選擇資料平台解決方案時，應考慮長期永續性而非短期利益。
在規劃資料平台時，應選擇符合公司長期發展預期的方案，而非僅僅追求短期效益。

最終建議

在未來的資料平台發展中，我們應持續關注以下幾點：

  1. 業務目標對齊：確保資料平台的發展與公司業務目標保持一致。
  2. 利益相關者支援：持續取得並整合正確的利益相關者的反饋。
  3. 永續性發展：優先考慮長期成長與永續性，而非短期利益。

透過這些策略，我們可以在資料平台中建立穩固的信任關係，推動業務的持續成長與成功。

建立資料平台的信任基礎：資料品質與責任歸屬

在現代企業中，資料平台的成功取決於資料的可信度。如果資料不可信，那麼無論資料平台多麼強大，都無法發揮其應有的價值。資料品質對於不同的利益相關者有著不同的意義，因此，在資料平台的建設過程中，確保所有利益相關者對資料品質的定義達成一致至關重要。

設定資料可靠性的基準指標

資料可靠性的定義是指在整個資料生命週期中，提供高資料可用性和健康度的能力。為了確保資料可靠性，必須設定明確的服務水平目標（SLOs）和服務水平指標（SLIs），這是資料團隊在建立資料管道時必須考慮的。

# 資料可靠性指標示例
def calculate_data_reliability(data_availability, data_health):
    """
    計算資料可靠性指標
    :param data_availability: 資料可用性指標
    :param data_health: 資料健康度指標
    :return: 資料可靠性指標
    """
    data_reliability = (data_availability + data_health) / 2
    return data_reliability

# 使用範例
data_availability = 0.99  # 99% 的資料可用性
data_health = 0.98  # 98% 的資料健康度
reliability = calculate_data_reliability(data_availability, data_health)
print(f"資料可靠性指標：{reliability:.2f}")

內容解密：

此範例程式碼展示瞭如何計算資料可靠性指標。透過將資料可用性和健康度指標平均，可以得到資料可靠性指標。這種簡單的計算方法可以幫助資料團隊快速評估資料的整體可靠性。

自建還是採購資料平台

在決定是否自建資料平台或採購現有技術時，需要考慮多種因素。像Uber、LinkedIn和Facebook這樣的公司選擇自建資料平台，但這不一定適用於所有企業。自建資料平台的決定取決於以下因素：

  • 是否需要處理敏感或機密資訊（例如財務或健康記錄），而這些資訊不能與外部供應商分享。
  • 是否需要進行特定客製化，以確保與內部工具或系統的相容性。
  • 是否具有戰略價值，例如為企業帶來競爭優勢或有利於人才招募。
  graph LR
    A[決定自建或採購] --> B{是否涉及敏感資訊?}
    B -->|是| C[自建資料平台]
    B -->|否| D{是否需要特定客製化?}
    D -->|是| C
    D -->|否| E[採購現有技術]

圖表翻譯： 此圖表展示了決定自建或採購資料平台的流程。首先，需要判斷是否涉及敏感或機密資訊。如果是，則選擇自建資料平台。如果否，則進一步判斷是否需要特定客製化。如果需要客製化，則自建；否則，採購現有技術。

將資料平台視為產品

將資料平台視為產品有助於確保資料優先順序的一致性、標準化資料品質和其他關鍵績效指標（KPIs），促進協作，並最終為企業帶來價值。這種方法不僅有助於資料管理、可靠性和普及化，還可以：

  • 引導銷售工作
  • 驅動應用產品路線圖
  • 改善客戶體驗
  • 標準化資料治理和合規措施

責任歸屬與資料品質

在現代資料組織中，資料品質的責任歸屬問題有許多不同的答案，取決於公司的規模和業務需求。資料專業人員在資料品質問題出現時常常會互相指責，但很少有人能夠成功解決問題並將影響傳達給下游。

# 資料品質責任歸屬示例
class DataQualityOwner:
    def __init__(self, name, responsibility):
        """
        初始化資料品質責任人
        :param name: 責任人姓名
        :param responsibility: 責任描述
        """
        self.name = name
        self.responsibility = responsibility

    def __str__(self):
        return f"{self.name}: {self.responsibility}"

# 使用範例
owner1 = DataQualityOwner("資料工程師", "確保資料管道的穩定性")
owner2 = DataQualityOwner("資料分析師", "監控資料品質指標")
print(owner1)
print(owner2)

內容解密：

此範例程式碼展示瞭如何定義資料品質責任人。透過建立一個類別來表示責任人，可以清晰地描述每個人的責任和義務，從而提高資料品質管理的效率。

玄貓

玄貓

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