資料品質技術構建可靠資料系統

– 15 分鐘閱讀

隨著資料網格、串流資料和資料湖倉一體等架構的興起，資料品質的重要性日益凸顯。傳統的批次資料處理方式已不足以應付現代資料工程的需求，需要更即時、更彈性的資料品質控管機制。理解運算元據和分析資料的差異，以及延遲和吞吐量之間的權衡，是構建可靠資料系統的關鍵。資料倉儲和資料湖各有優劣，選擇適合的技術取決於具體的應用場景。透過後設資料管理和程式碼範例中的資料品品檢查函式，可以有效提升資料的可靠性和可信度。

為何資料品質值得關注——現在

在閱讀這本文時，你可能對使用不再相關的資料集的經驗並不陌生，而且你很可能不知道這一點！

導致當前時刻的其他行業趨勢

除了前述經常導致資料停機的因素外，隨著技術創新而發生的幾大行業變革也在推動資料領域的變革。這些變革都為資料品質的關注度提升做出了貢獻。

資料網格

資料網格在很多方面與軟體工程團隊從單體應用轉向微服務架構類別似，它是資料平台版本的微服務。值得注意的是，資料網格的概念尚處於初期階段，資料社群正在就如何在文化和技術層面上實施資料網格進行廣泛討論。

正如Zhamak Dehghani（Thoughtworks顧問和該術語的原始架構師）首次定義的那樣，資料網格（如圖1-1所示）是一種社會技術正規化，它認識到複雜組織中人員和技術架構之間的互動。資料網格透過採用導向領域的自助設計，利用企業中資料的普遍性。它利用Eric Evans的領域驅動設計理論，這是一種靈活、可擴充套件的軟體開發正規化，使程式碼的結構和語言與其對應的業務領域相匹配。

與傳統的單體資料基礎設施不同，資料網格支援分散的、特定領域的資料消費者，並將「資料視為產品」，每個領域處理自己的資料管道。連線這些領域及其相關資料資產的組織是通用互操作性層，它應用相同的語法和資料標準。

資料網格將資料所有權聯邦化，由領域資料所有者負責提供其資料產品，同時促進不同地點分散資料之間的通訊。

雖然資料基礎設施負責為每個領域提供處理方案，但領域負責管理資料的擷取、清理和匯總，以生成可供商業智慧應用使用的資產。每個領域負責擁有自己的管道，但有一套應用於所有領域的功能，用於儲存、編目和維護原始資料的存取控制。一旦資料被提供給特定領域並轉換，領域所有者就可以利用資料進行分析或營運需求。

  graph LR
    A[資料網格] --> B[分散式資料架構]
    A --> C[領域驅動設計]
    B --> D[通用互操作性層]
    C --> E[資料產品]
    D --> F[資料標準]
    E --> G[領域資料所有者]
    F --> G
    G --> H[資料品質監控]

圖表翻譯：

上圖展示了資料網格的架構與相關概念。資料網格是一種分散式資料架構，它採用領域驅動設計，將資料視為產品，並透過通用互操作性層實作資料標準化。領域資料所有者負責提供高品質的資料產品，並透過資料品質監控確保資料的可靠性和可信度。

資料網格的成功實施依賴於資料的可靠性和可信度，以及跨領域應用的「通用互操作性層」。確保資料品質的唯一方法？透過測試、監控和可觀察性密切關注資料品質。

許多公司正在採用資料網格正規化，尤其是需要多個資料領域的大型組織。例如，在Intuit的前資料工程副執行長Mammad Zadeh和Intuit的核心服務與體驗高階副執行長Raji Arasu於2021年1月撰寫的部落格文章中，Intuit將自己定位為一家「AI驅動的專家平台公司」，其平台「收集、處理和轉換持續的資料流為高品質資料的網格」。

另一個例子是摩根大通（JPMorgan Chase），該公司建立了資料網格架構，以幫助他們在不同的分析功能之間劃分資料所有權，並提高跨企業的資料共用可見性。

無論你對資料網格有何看法，它確實在資料社群中引起了廣泛關注，並引發了關於我們分散式資料架構和團隊結構未來的熱烈討論。

串流資料

串流資料是指將連續的資料流傳輸到管道中，以快速生成即時洞察。傳統上，資料品質透過在批次資料進入生產管道之前進行測試來實施，但越來越多的企業正在尋求更即時的分析。雖然這有可能使洞察更快，但也引發了與資料品質相關的更多問題和挑戰，因為串流資料是「動態」的資料。

越來越多的組織正在同時採用批次處理和串流處理，這迫使資料團隊重新思考他們的測試和觀察資料的方法。

資料湖倉一體

資料倉儲還是資料湖？這是個問題——至少對於資料工程師來說是如此。資料倉儲是一種結構化的資料儲存函式庫，而資料湖則是一個原始、非結構化的資料池，兩者都依賴高品質的資料進行處理和轉換。越來越多的資料團隊選擇同時使用資料倉儲和資料湖，以滿足業務日益增長的資料需求。這就是資料湖倉一體的由來。

資料湖倉一體首次出現在雲端倉儲供應商開始新增提供湖式功能的特性時，例如Redshift Spectrum或Databricks Lakehouse。同樣，資料湖也增加了提供倉儲式功能的技術，例如SQL功能和schema。如今，倉儲和湖之間的歷史差異正在縮小，因此你可以在一個套件中獲得兩者的最佳功能。

這種向湖倉一體模型的遷移表明，管道正變得越來越複雜，雖然有些人可能會選擇一個專門的供應商來處理兩者，但其他人正在將資料遷移到多個儲存和處理層，從而導致管道資料即使經過充分測試也可能中斷的機會增加。

程式碼範例：資料品品檢查
import pandas as pd

def check_data_quality(data):
    # 檢查資料是否為空
    if data.empty:
        print("資料集為空")
        return False
    
    # 檢查資料中是否存在缺失值
    if data.isnull().values.any():
        print("資料集中存在缺失值")
        return False
    
    # 檢查資料型別是否正確
    expected_types = {'column1': int, 'column2': str}
    for column, expected_type in expected_types.items():
        if not isinstance(data[column].iloc[0], expected_type):
            print(f"{column} 資料型別不正確")
            return False
    
    print("資料品品檢查透過")
    return True

# 使用範例
data = pd.DataFrame({
    'column1': [1, 2, 3],
    'column2': ['a', 'b', 'c']
})

check_data_quality(data)

內容解密：

上述程式碼用於檢查資料品質。首先，它檢查資料集是否為空。如果資料集為空，則輸出「資料集為空」並傳回False。接著，它檢查資料集中是否存在缺失值。如果存在缺失值，則輸出「資料集中存在缺失值」並傳回False。然後，它檢查特定欄位的資料型別是否正確。如果資料型別不正確，則輸出相應的錯誤訊息並傳回False。如果所有檢查都透過，則輸出「資料品品檢查透過」並傳回True。這個函式可以幫助確保資料的完整性和正確性，從而提高資料品質。

構建可靠資料系統的根本

在生產環境中解決資料品質問題是任何資料從業人員必備的技能，但透過合適的系統和流程，資料停機時間幾乎可以完全避免。

如同軟體開發，資料品質可能受到操作、程式設計或資料相關因素的影響，而這些因素可能出現在資料管道的各個階段。只需要一個架構變更或程式碼更新，就可能導致下游報表陷入混亂。

正如我們在第8章將要討論的，解決資料品質問題和構建更可靠的資料管道可以分為三個關鍵部分：流程、技術和人員。在本章中，我們將重點關注技術部分，梳理資料管道中的各個部分，以及在每個階段測量、修復和預防資料停機時間所需的條件。

資料系統極其複雜，資料管道中的各個階段都可能對這種混亂做出貢獻。隨著企業越來越多地投資於資料和分析，擴大建設規模的壓力使得資料工程師需要在資料進入管道之前就考慮品質問題。

在本章中，我們將重點介紹各種根據後設資料的構建模組——從資料目錄到資料倉儲和資料湖——以確保您的資料基礎設施在每個管道階段都能確保高品質資料。

瞭解運算元據和分析資料之間的區別

如果您詢問一位資料工程師關於他們組織內資料的最廣泛區別，可能會聽到“運算元據”和“分析資料”這兩個術語。運算元據與分析資料的區別只是劃分資料生態系統的一種方式，但它是一個重要的區別，如果您希望採用資料品質文化，就需要了解它。

雖然我們將在這裡稍微討論運算元據，但必須注意的是，就本文而言，我們一直並將繼續關注資料品質與分析資料的相關性。管理運算元據的品質和可靠性通常屬於DevOps、網站可靠性工程和其他與構建軟體產品更相關的軟體領域，而這些軟體產品是由分析資料所驅動的。

運算元據

運算元據是指在日常營運中產生的資料，即由組織的日常營運活動產生的資料。庫存快照、客戶互動和交易記錄都是運算元據的例子。

分析資料

分析資料是指用於分析的資料，即用於資料驅動的商業決策的資料。市場流失率、點選率和全球區域印象都是分析資料類別的例子。

簡而言之，運算元據記錄了實際業務流程的資料，以便快速更新系統和流程，而分析資料則用於更強健和高效的分析。一個簡單的思考方式是，運算元據使您的業務運轉，而分析資料則管理您的業務。鑑於分析資料以運算元據無法做到的方式驅動商業智慧，有人可能會認為這種資料對於組織的成功更為重要或更為“核心”。然而，分析資料往往建立在運算元據轉換和匯總的基礎上。

運算元據與分析資料之間的區別與交易處理和分析資料系統（OLTP與OLAP）之間的比較相同，例如在《設計資料密集型應用》（O’Reilly）中提到的那樣。

它們的不同之處

正如您可能已經猜到的，分析資料和運算元據在幾個關鍵方面存在差異，這些差異影響了我們如何管理它們的可靠性，如圖2-1所示。

  graph LR
    A[運算元據] -->|轉換與匯總|> B[分析資料]
    B --> C{資料倉儲}
    C --> D[資料分析]
    D --> E[商業智慧]

圖表翻譯： 上圖展示了運算元據如何透過轉換和匯總成為分析資料，並進一步用於資料倉儲、資料分析和商業智慧的過程。

幾乎總是，運算元據出現在分析資料的上游，這是因為分析資料通常包含運算元據儲存的匯總或增強。某個使用者在凌晨5點從瀏覽器點選的次數是一個運算元據，而12月份行銷活動的點選率則是相應的分析資料。

運算元據與分析資料之間區別的一個關鍵原因是所謂的吞吐量與延遲之間的權衡。吞吐量-延遲約束影響任何具有固定計算能力的系統。傳統上，吞吐量指的是在某單位時間內處理的資料量，而延遲則指的是資料處理之前的延遲。

內容解密：

上述Mermaid圖表展示了一個簡單的資料流程，運算元據透過一系列處理後轉變為分析資料，並最終支援商業智慧。圖中每一步驟都代表了資料處理的一個重要階段。

想像一家熱門的網路咖啡館，外面排著長隊。隊伍末端的人需要多久才能拿到咖啡？這個過程包括排隊、點單、付款，然後等待咖啡師製作咖啡。這個總時間就是延遲的例子。

技術細節與重要性

  • 資料管道設計：設計一個穩健的資料管道是確保資料品質的基礎。
  • 後設資料管理：有效的後設資料管理可以幫助跟蹤資料的來源、轉換過程和儲存位置，從而提高資料的可信度。
  • 資料倉儲與資料湖：資料倉儲和資料湖是儲存和分析資料的關鍵基礎設施。資料倉儲通常用於儲存經過處理的資料，而資料湖則用於儲存原始資料。
-- 示例SQL查詢，用於分析資料倉儲中的資料
SELECT 
    region,
    COUNT(*) as total_clicks,
    SUM(CASE WHEN action = 'purchase' THEN 1 ELSE 0 END) as total_purchases
FROM 
    user_actions
WHERE 
    event_date BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY 
    region;

內容解密：

上述SQL查詢用於分析使用者在不同地區的點選行為和購買行為。透過這個查詢，可以獲得每個地區的總點選次數和總購買次數，從而為業務決策提供資料支援。

  1. 查詢邏輯：查詢首先從user_actions表中篩選出2023年的資料，然後按地區分組，計算每個地區的總點選次數和總購買次數。
  2. 技術考量：在編寫這類別查詢時，需要考慮資料的粒度、查詢的效率以及結果的準確性。
  3. 最佳化建議：可以透過新增索引、最佳化查詢邏輯等方式來提高查詢效率。

結語

構建一個可靠的資料系統需要綜合考慮技術、流程和人員三個方面。在技術層面，透過採用適當的資料架構、有效的後設資料管理和高效的資料處理流程，可以大大提高資料的品質和可靠性。未來，隨著資料量的不斷增長和業務需求的變化，持續最佳化和改進資料系統將是一個持續的挑戰。

隨著技術的發展，資料系統將變得更加智慧和自動化。例如，透過使用機器學習技術，可以實作資料品質的自動監控和異常檢測。同時，雲端計算和分散式技術的發展也將進一步提高資料處理的效率和可擴充套件性。

總之，構建和維護一個可靠的資料系統是確保業務成功的重要根本。透過不斷地改進技術和方法，我們可以更好地支援業務決策，推動企業向前發展。

資料倉儲與資料湖：資料處理系統的核心元件

在資料工程領域中，資料倉儲（Data Warehouses）與資料湖（Data Lakes）是兩個極為重要的概念。儘管它們在功能和設計上有明顯的差異，但兩者正在快速融合，各自提供對方的優勢。

資料倉儲與資料湖的差異

資料倉儲

資料倉儲通常將資料儲存在結構化的表格格式（行-列）中。這些資料經過高度轉換（預處理程式的結果），並且只有在具有明確目的時才會被儲存。換言之，資料倉儲中的資料具有確定的結構和明確的業務目標。

資料倉儲需要「寫入時結構」（schema on write），也就是說，資料在進入倉儲時就必須定義其結構。後續的資料轉換也必須明確其新的結構。這種設計使得資料倉儲具有高度的整合性和管理性，使得構建和操作變得相對簡單。

資料倉儲的設計理念部分源自Kimball Group在1980年代提出的資料倉儲/商業智慧生命週期方法論（Data Warehouse / Business Intelligence Lifecycle Methodology）。這種方法論強調了資料儲存技術作為業務資產的重要性，而非僅僅是技術上的選擇。

現代的資料倉儲技術，如Amazon Redshift和Google BigQuery，均採用了欄儲存格式（columnar storage）和平行處理（parallel processing），使它們非常適合進行分析工作負載。

資料湖

資料湖則是一種可以儲存任何型別資料的系統，包括結構化、半結構化和非結構化資料。與資料倉儲不同，資料湖不需要嚴格的資料進入程式，你可以將任意格式的資料直接存入湖中並直接存取。這使得資料湖通常具有更高的資料量和更複雜的治理和資料管理。

資料湖的靈活性使其成為儲存和分析多樣化資料的理想選擇。然而，這種靈活性也帶來了資料治理和管理的挑戰。

資料倉儲與資料湖的比較

特性資料倉儲資料湖
資料結構結構化（行-列格式）任意結構（結構化、半結構化、非結構化）
資料進入程式寫入時結構（schema on write）讀取時結構（schema on read）
資料治理高度結構化，較簡單較為複雜，需要額外的治理
適用場景商業智慧、分析工作負載多樣化資料儲存和分析

資料處理系統的架構挑戰：延遲與吞吐量

在設計資料處理系統時，我們經常面臨兩個相互競爭的效能指標：延遲（latency）和吞吐量（throughput）。延遲指的是系統處理單個請求所需的時間，而吞吐量則是指系統在單位時間內能夠處理的請求數量。

延遲與吞吐量的權衡

這兩個指標之間的權衡關係可以透過一個簡單的類別比來理解：假設我們經營一家網咖。網咖的延遲可以理解為顧客從點單到拿到咖啡所需的時間，而吞吐量則是指網咖在單位時間內能夠服務的顧客數量。

在網咖的例子中，如果我們希望降低延遲（即加快服務速度），我們可能會將大部分員工分配到櫃台和咖啡機旁，以盡快處理顧客的訂單。然而，這樣做可能會降低吞吐量，因為沒有足夠的員工來清理桌子和為新顧客騰出空間。相反，如果我們將大部分員工分配到清理桌子和服務顧客，那麼延遲可能會增加，因為沒有足夠的員工來處理訂單。

同樣的權衡關係也存在於資料處理系統中。事務型資料函式庫（operational databases）通常需要快速檢索資料（如訂單詳情），因此它們的架構設計會最佳化延遲。分析型資料函式庫（analytical databases）則需要處理大規模的資料聚合，因此它們會最佳化吞吐量。

實際應用中的考慮

在實際應用中，我們需要根據具體的需求來選擇合適的資料處理系統。例如，如果我們需要在客戶介面中查詢大量的資料，那麼我們可能會選擇最佳化延遲的資料函式庫，如MySQL或Postgres。相反，如果我們需要進行大規模的資料分析，那麼我們可能會選擇最佳化吞吐量的資料倉儲，如Snowflake或Redshift。

資料倉儲技術

現代資料倉儲技術的發展使得資料分析和商業智慧變得更加高效和便捷。以下是一些常見的資料倉儲技術：

  • Amazon Redshift：Amazon Redshift是第一個廣泛流行的雲端資料倉儲，它建立在Amazon Web Services（AWS）之上，利用源聯結器將資料從原始資料來源匯入到關係儲存中。Redshift的欄儲存結構和平行處理使其非常適合分析工作負載。
  • Google BigQuery：Google BigQuery與Redshift類別似，利用其母公司Google的專有雲平台（Google Cloud Platform，GCP），採用欄儲存格式，並利用平行處理來實作快速查詢。與Redshift不同的是，BigQuery是一種無伺服器（serverless）解決方案，可以根據使用模式進行擴充套件。
內容解密：

在資料工程領域，資料倉儲和資料湖是兩個核心元件。資料倉儲適合結構化的資料和商業智慧應用，而資料湖則適合儲存和分析多樣化的資料。兩者之間的選擇取決於具體的業務需求和資料特性。

程式碼範例

-- 在Amazon Redshift中建立一個示例表
CREATE TABLE customer_orders (
    order_id INT,
    customer_id INT,
    order_date DATE,
    total_amount DECIMAL(10, 2)
);

-- 將資料插入表中
INSERT INTO customer_orders (order_id, customer_id, order_date, total_amount)
VALUES (1, 101, '2022-01-01', 100.00),
       (2, 102, '2022-01-02', 200.00),
       (3, 101, '2022-01-03', 50.00);

-- 查詢客戶訂單總金額
SELECT customer_id, SUM(total_amount) AS total_spent
FROM customer_orders
GROUP BY customer_id
ORDER BY total_spent DESC;

內容解密：

上述SQL程式碼展示瞭如何在Amazon Redshift中建立一個客戶訂單表，並進行簡單的資料查詢。第一步是建立一個名為customer_orders的表，包含訂單ID、客戶ID、訂單日期和總金額等欄位。接著，我們向表中插入了一些示例資料。最後，我們執行了一個查詢，以計算每個客戶的總消費金額，並按照總金額從高到低進行排序。

這個例子說明瞭資料倉儲如何有效地儲存和處理結構化的資料，以支援商業智慧和分析工作負載。

資料倉儲與資料湖的融合

隨著技術的發展，資料倉儲和資料湖正在逐漸融合，提供了兩者的優勢。這種融合使得組織可以在單一系統中同時享受資料倉儲的結構化資料管理和資料湖的靈活性。

圖表示例

  graph LR
    A[資料來源] -->|結構化資料|> B[資料倉儲]
    A -->|非結構化資料|> C[資料湖]
    B --> D[商業智慧工具]
    C --> E[資料分析工具]
    D --> F[決策支援]
    E --> F

圖表翻譯： 此圖表展示了資料倉儲和資料湖在資料處理流程中的角色。結構化的資料被匯入資料倉儲，而非結構化的資料則被儲存在資料湖中。兩者分別與商業智慧工具和資料分析工具相連，最終支援決策制定。

玄貓

玄貓

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