資料管道監控效能調優實務

– 13 分鐘閱讀

在資料密集型應用中，資料管線的穩定執行至關重要。系統監控提供管線健康狀況的概覽，例如資料吞吐量和延遲，而資源監控則深入到 CPU、記憶體等底層資源的使用情況。透過結合這兩者，工程師可以快速診斷效能瓶頸，例如 Spark 任務中的記憶體不足或 Redis 快取的過期策略設定不當。精確的資源監控如同高解析度地圖，能引導我們找到問題根源，並採取相應的最佳化措施，例如調整資源組態或重構程式碼。此外，持續監控管線各階段的執行時間和錯誤率，有助於及早發現異常並預防潛在的系統故障。查詢監控則關注資料函式庫效能，透過分析查詢計劃和執行時間，可以最佳化資料模型和查詢邏輯，進一步提升管線效率。

系統監控與資源監控：資料管道的導航圖

在資料管道的開發和維護過程中，監控是一項至關重要的任務。如同在荒野中徒步旅行需要地圖導航一樣，系統監控和資源監控為我們提供了必要的資訊，以確保資料管道的健康和效能。在本章中，我們將探討系統監控和資源監控的重要性，以及如何利用這些資訊來最佳化資料管道的效能。

系統監控：資料管道的健康指標

系統監控提供了資料管道整體健康狀況的高層次檢視，包括資料量、吞吐量、消費者延遲和工作節點利用率等指標。這些指標幫助我們瞭解資料管道的執行狀況，並及時發現潛在的問題。

案例分析：工作節點死鎖

在一個實際案例中，我們觀察到資料管道的工作節點利用率始終保持在100%，導致任務無法完成。進一步調查發現，這是由於次級DAG（有向無環圖）的觸發任務佔用了所有的工作節點，從而導致死鎖。為瞭解決這個問題，我們重新設計了資料管道，消除了次級DAG，從而將工作節點的利用率降低了一半。


### 工作節點死鎖解決方案

#### 重構前
- 主DAG觸發次級DAG
- 次級DAG佔用額外的工作節點
- 導致工作節點死鎖

#### 重構後
- 消除次級DAG
- 簡化資料管道邏輯
- 工作節點利用率降低50%

如同地圖上的虛線代表著徒步小徑一樣，系統監控為我們提供了資料管道的整體檢視。然而，為了更好地瞭解資料管道的效能，我們需要更深入地觀察資源監控。

資源監控：深入瞭解資料管道的效能

資源監控關注的是資料管道的根本元素，包括記憶體、CPU、磁碟使用率和網路流量等。這些指標幫助我們瞭解資料管道的效能瓶頸，並找出最佳化機會。

識別資源瓶頸

透過資源監控，我們可以識別出資料管道的資源瓶頸。例如，如果一個任務的效能受限於記憶體，那麼增加CPU資源可能不會帶來明顯的改善。


### 資源瓶頸分析

#### 記憶體瓶頸
- 任務效能受限於可用記憶體
- 增加CPU資源無助於改善效能

#### I/O瓶頸
- 任務效能受限於I/O操作
- 增加CPU資源可能使問題惡化

理解可靠性影響

資源不足可能導致資料管道的故障或效能下降。透過監控服務重啟和資源利用率，我們可以及時發現資源不足的問題，並採取相應措施。


### 資源不足的影響

#### 直接影響
- 任務因資源不足而失敗

#### 間接影響
- 相關服務因資源不足而無法正常運作

總之，系統監控和資源監控是確保資料管道健康和效能的關鍵。透過結合這兩種監控方法，我們可以更好地瞭解資料管道的執行狀況，並及時發現和解決潛在的問題。就像地形圖為徒步旅行者提供了詳細的地形資訊一樣，資源監控為我們提供了資料管道效能的深入檢視，幫助我們最佳化資料管道的設計和運作。

監控系統中的資源利用與效能瓶頸分析

在系統維運過程中，資源利用率和效能瓶頸的監控至關重要。一個程式不斷被終止通常是系統出現問題的直接跡象。然而，有時資源不足的問題卻不容易被察覺。例如，在某個案例中，一個Spark任務陷入了停滯和進展的迴圈，當垃圾回收執行時，任務會暫時取得進展。這是因為垃圾回收釋放了足夠的記憶體，使任務能夠向前推進一小步，但隨後又會耗盡資源。

資源利用率的觀察與分析

觀察到高資源利用率並不一定意味著存在問題。例如，給定一塊記憶體且沒有對執行器的限制，Spark會盡可能地消耗所有可用的記憶體來實作資料處理的平行化。同樣，Java也會消耗可用的記憶體，並定期執行垃圾回收來清理不再使用的物件。

在這種情況下，僅觀察容器或叢集中的高記憶體消耗並不一定指向問題。如果觀察到高資源利用率，檢查資源設定有助於確定下一步的措施。資源利用率本身只是問題的一部分；需要考慮高利用率的影響來決定是否需要採取行動。

記憶體洩漏的檢測與處理

記憶體洩漏是另一個可能導致系統不穩定的隱蔽問題。記憶體利用率隨時間緩慢而穩定地增加可能是記憶體洩漏的跡象。這種情況下，較長的觀察視窗是有幫助的；如果監控記憶體的時間不夠長，就無法察覺到洩漏的發生。

案例分析：Redis記憶體最佳化

曾經有一個系統使用Redis來快取常見查詢的結果。某個時候，查詢開始失敗。調查發現，Redis耗盡了記憶體。透過檢查記憶體使用情況，維運團隊注意到Redis在查詢執行時間範圍之外佔用了大量記憶體。

開發人員重新評估了Redis條目的存活時間（TTL），發現TTL設定得太長，導致Redis條目沒有及時被刪除。最佳化措施包括將TTL調整到更合理的時間，並刪除了不再需要的條目。這些最佳化不僅修復了查詢失敗的問題，還減少了計算成本。

管道效能監控

除了系統級別的指標，如整體管道執行時和消費者延遲外，檢查管道內的效能可以提供關於任務過程中發生的詳細資訊。深入管道效能就像使用更高解析度的地形圖一樣，可以提供更詳細的資訊。

管道階段執行時間分析

以HoD批次管道為例，透過監控管道整體執行時間，發現了一些與預期基線不同的情況。進一步檢查管道內的執行時間，可以得到更詳細的資訊，如下表所示：

案例驗證Zip程式碼提取資料豐富總時間
基線2215
案例122130
案例2（a）230017
案例2（b）112306

透過分析每個階段的執行時間，可以清楚地瞭解哪個階段導致了整體執行時間的增加。在案例1中，資料豐富階段的執行時間顯著增加，而在案例2（a）和（b）中，則分別是Zip程式碼提取和資料豐富階段佔用了大部分時間。

# 以下是一個簡單的Python程式碼範例，用於模擬管道階段執行時間的分析
def analyze_pipeline_performance(stage_runtimes):
    total_time = sum(stage_runtimes.values())
    print(f"Total pipeline runtime: {total_time} seconds")
    for stage, runtime in stage_runtimes.items():
        print(f"{stage}: {runtime} seconds")
    # 識別最耗時的階段
    bottleneck_stage = max(stage_runtimes, key=stage_runtimes.get)
    print(f"Bottleneck stage: {bottleneck_stage}")

# 範例資料
stage_runtimes = {
    "Validate": 2,
    "Zip code Extract": 300,
    "Enrich": 1,
    "Other": 7
}

analyze_pipeline_performance(stage_runtimes)

內容解密：

此Python程式碼範例展示瞭如何分析管道階段執行時間。首先定義了一個函式analyze_pipeline_performance，它接受一個字典stage_runtimes作為輸入，其中包含了各個階段的執行時間。函式計算了管道的總執行時間，並列印預出每個階段的執行時間。然後，它識別出了最耗時的階段，即瓶頸階段，並將其列印預出來。在範例資料中，我們模擬了一個管道，其中"Zip code Extract"階段耗時最長，為300秒。透過執行此程式碼，可以快速瞭解管道中的效能瓶頸所在。

這樣的分析和最佳化有助於提高管道的整體效能，降低計算成本，並確保系統穩定執行。

資料管線的效能監控與調校

監控資料管線的效能對於確保系統的可靠性和效率至關重要。透過監控，我們可以及早發現潛在的問題並進行調校，從而避免效能下降或系統當機。

使用儀錶板進行初步監控

在處理資料管線時，通常會先使用儀錶板來視覺化監控各項指標，以找出異常情況。圖 11-10 展示了 Baseline 和 Case 1 的理想化追蹤結果。圖表上半部分顯示了整個管線的整體吞吐量，而下半部分則按管線階段分解了追蹤結果。

圖表示例

此圖示展示了 Baseline 和 Case 1 的管線效能比較：

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 資料管道監控效能調優實務

package "資料庫架構" {
    package "應用層" {
        component [連線池] as pool
        component [ORM 框架] as orm
    }

    package "資料庫引擎" {
        component [查詢解析器] as parser
        component [優化器] as optimizer
        component [執行引擎] as executor
    }

    package "儲存層" {
        database [主資料庫] as master
        database [讀取副本] as replica
        database [快取層] as cache
    }
}

pool --> orm : 管理連線
orm --> parser : SQL 查詢
parser --> optimizer : 解析樹
optimizer --> executor : 執行計畫
executor --> master : 寫入操作
executor --> replica : 讀取操作
cache --> executor : 快取命中

master --> replica : 資料同步

note right of cache
  Redis/Memcached
  減少資料庫負載
end note

@enduml

詳細分析與除錯

當我們發現 Case 1 的吞吐量與 Baseline 有顯著差異時，可以進一步檢視各階段的追蹤結果。在階段層級，我們觀察到 Enrich 階段的吞吐量明顯降低，這導致該階段的完成時間變長。

使用日誌進行進一步分析

進一步的步驟是查閱日誌，以確定潛在的原因。例如，在 Case 2 中，我們可能發現連線錯誤和重試嘗試對應的情況。透過分析日誌，我們可以進一步對 API 和資料函式庫進行故障排除。

Profiling：更細緻的效能分析

如果需要更深入地瞭解管線在哪裡花費了時間，可以使用 Profiling。Profiling 可以提供非常詳細的資訊，但需要注意的是，它可能會受到觀察者效應的影響，即測量執行時會對整體效能產生影響。

程式碼範例

import time
import logging

def enrich_with_social(data):
    start_time = time.time()
    # 進行資料豐富化處理
    result = merge_species_and_social(data)
    end_time = time.time()
    logging.info(f"enrich_with_social took {end_time - start_time} seconds")
    return result

def merge_species_and_social(data):
    start_time = time.time()
    # 合併物種和社交資料
    result = data.merge(social_data, on='species_id')
    end_time = time.time()
    logging.info(f"merge_species_and_social took {end_time - start_time} seconds")
    return result

# 呼叫 enrich_with_social 函式
data = enrich_with_social(input_data)

內容解密：

  1. enrich_with_social 函式用於豐富化資料，並記錄執行時間。
  2. merge_species_and_social 函式負責合併物種和社交資料，同樣記錄執行時間。
  3. 透過記錄每個步驟的時間，可以精確地找出效能瓶頸。

錯誤監控

除了效能監控外，錯誤監控也是資料管線監控的重要方面。我們需要追蹤各個階段的失敗率，並註解失敗原因，以便快速定位和解決問題。

指標分類別

  1. Ingestion 成功與失敗：追蹤資料攝入的成功和失敗情況，有助於瞭解系統的可靠性。
  2. Stage 失敗：監控各個管線階段的失敗率，可以幫助我們精確定位問題所在。

透過這些監控措施，我們可以有效地維護資料管線的穩定性和效能，確保系統運作順暢。

監控資料管線的效能與錯誤

在資料管線的開發與維護過程中，監控是確保系統穩定性和效能的關鍵。透過有效的監控，可以及時發現問題並進行修復，從而避免潛在的損失。本章節將重點介紹如何監控資料管線的效能與錯誤，以及相關的最佳實踐。

錯誤指標的重要性

錯誤指標提供了資料管線執行狀態的即時反饋，能夠幫助團隊快速定位問題。常見的錯誤型別包括驗證失敗、通訊失敗、認證失敗等。透過對這些錯誤的監控，可以有效地識別和解決問題。

驗證失敗

驗證失敗通常與資料品質或驗證邏輯相關。監控驗證失敗的趨勢可以幫助團隊判斷問題的根源。例如，如果在某次釋出後驗證失敗率突然上升，可能是程式碼變更引入了錯誤。如果驗證失敗率持續上升，則可能是資料特徵發生了變化。

import logging

def validate_data(data):
    try:
        # 驗證邏輯
        if not isinstance(data, dict):
            raise ValueError("Invalid data format")
        # 其他驗證邏輯...
        return True
    except Exception as e:
        logging.error(f"Validation failed: {e}")
        return False

內容解密：

  1. validate_data 函式：此函式負責驗證輸入資料的有效性。
  2. try-except 區塊：用於捕捉驗證過程中可能出現的異常，並記錄錯誤日誌。
  3. logging.error：將驗證失敗的原因記錄到日誌中，便於後續的故障排除。

通訊失敗

通訊失敗通常與外部依賴相關，例如與資料函式庫或第三方服務的連線問題。監控通訊失敗可以幫助團隊快速定位問題，例如連線超時或認證失敗。

import requests

def fetch_data(url):
    try:
        response = requests.get(url, timeout=5)
        response.raise_for_status()
        return response.json()
    except requests.exceptions.RequestException as e:
        logging.error(f"Failed to fetch data: {e}")
        return None

內容解密：

  1. fetch_data 函式：此函式負責從指定的 URL 取得資料。
  2. requests.get：發起 HTTP GET 請求，並設定超時時間為 5 秒。
  3. response.raise_for_status()：檢查請求是否成功，如果傳回狀態碼不是 2xx，則引發異常。
  4. logging.error：記錄請求失敗的原因，便於後續分析。

指標註解與基數問題

在監控資料中新增標籤或註解可以提供更多的上下文資訊。然而，這些標籤的基數（即唯一值的數量）會影響監控系統的成本和效能。過高的基數可能導致監控系統負擔過重。

節制使用高基數標籤

高基數標籤，例如包含大量唯一值的欄位（如郵政編碼），可能會導致監控系統產生大量的時間序列資料。這不僅增加了成本，也會影響查詢效能。因此，應謹慎使用高基數標籤，必要時可考慮將相關資訊記錄到日誌中。

階段超時與查詢監控

除了錯誤監控外，階段超時和查詢效能也是重要的監控指標。階段超時可以幫助團隊發現效能瓶頸，而查詢監控則能夠提供資料函式庫效能的洞察。

查詢監控

查詢效能直接影響資料管線的整體效能。監控查詢執行時間和成功率，可以幫助團隊最佳化資料模型和查詢邏輯。

EXPLAIN SELECT * FROM large_table WHERE condition = 'specific_value';

內容解密：

  1. EXPLAIN 陳述式：用於分析 SQL 查詢的執行計劃。
  2. SELECT * FROM large_table：查詢範例，用於檢索 large_table 中的資料。
  3. WHERE condition = 'specific_value'：查詢條件，用於篩選特定的資料。

透過上述方法，可以有效地監控資料管線的效能與錯誤，及時發現並解決問題，從而確保系統的穩定執行。

查詢監控與效能調優的洞察

捕捉查詢計劃可以讓你瞭解資料模型如何應對資料的使用方式。特別是在不知道事先執行的查詢（例如動態生成查詢的系統）的情況下，查詢監控是一個非常有價值的工具。沒有深入瞭解資料存取方式，就很難建立高效的資料結構，包括資料模型、檢視和分割策略。這些決策會回饋到資料管道的設計中。

我在為政策分析師提供保險資料的資料平台上工作時遇到了這種雞生蛋蛋生雞的問題。分析師執行了長達數頁的巨大查詢，產生了很多中間表來切割和處理資料。這種策略源自於在Spark平台出現之前的舊工查詢工具。

為了提高效能，我開發了一種策略，用於呈現和分析使用者查詢，您可以在文章《Spark中的使用者查詢監控》中閱讀更多相關內容。我將在這裡介紹更廣泛適用的步驟，提供如何推廣這種方法的建議：

取得使用者正在執行的查詢資訊

  1. 查詢陳述式：取得使用者執行的SQL查詢陳述式。
  2. 執行時間：記錄查詢的執行時間。
  3. 查詢計劃：捕捉查詢的執行計劃。

程式碼範例：記錄查詢資訊

-- 設定Postgres的日誌記錄，捕捉執行時間超過特定閾值的查詢
SET log_min_duration_statement = 1000;  -- 記錄執行時間超過1000毫秒的查詢

內容解密：

  1. SET log_min_duration_statement = 1000;：這行程式碼設定Postgres的日誌記錄功能，用於捕捉執行時間超過1000毫秒的查詢。這有助於識別慢查詢。
  2. 日誌記錄的重要性：透過記錄慢查詢，可以進一步分析和最佳化這些查詢，提高系統的整體效能。

識別高影響力的查詢

  1. 定義高影響力查詢：根據使用場景定義，例如最關鍵系統使用者執行的查詢，或被認為是最重要的查詢。
  2. 查詢模式分析：如果有太多不同的查詢難以獨立分析，可以尋找查詢模式，例如針對特定表的查詢，或常見的篩選條件。

指標計算公式

  • 總查詢時間 = 所有查詢時間的總和
  • 平均查詢時間 = 總查詢時間 / 查詢次數
  • 變異係數（CV）= 查詢時間的標準差 / 平均查詢時間

範例資料分析

| 查詢ID | 平均查詢時間（秒） | CV | 總查詢時間（秒） | |

-|

|

-|

| | 1 | 1 | 0.1 | 4,000 | | 2 | 40 | 0.2 | 3,200 | | 3 | 75 | 0.8 | 1,800 |

內容解密：

  1. 查詢ID 1：總查詢時間長，但平均時間短且CV低，表示是頻繁執行的簡單查詢。
  2. 查詢ID 2：平均查詢時間長且CV低，表示是值得最佳化的目標。
  3. 查詢ID 3：平均時間長但CV高，表示執行時間波動大，最佳化效果不確定。

最小化監控成本

  1. 持久化關鍵指標：長期儲存關鍵的離散指標，而不是所有的監控資料。
  2. 選擇合適的指標匯總方法：例如使用四分位數或百分位數（如P99）來排除異常值。

程式碼範例：計算P99指標

import numpy as np

# 假設query_times是某個查詢的所有執行時間列表
query_times = [/* query execution times */]
p99 = np.percentile(query_times, 99)
print(f"P99 query time: {p99} seconds")

內容解密：

  1. np.percentile(query_times, 99)：計算query_times列表中的第99百分位數，用於表示大多數查詢的執行時間上限。
  2. P99指標的重要性：透過關注P99指標，可以排除極端異常值，更準確地評估系統的效能。
玄貓 BlackCat

玄貓 BlackCat

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