返回文章列表
玄貓（BlackCat）

查詢監控提升資料平台效能

本文探討查詢監控在資料平台效能調校中的重要性，涵蓋查詢計畫分析、高影響力查詢識別、指標評估、最佳化策略以及成本控制方法。同時，文章也探討資料管道監控、雲端資料管道開發以及雲端成本預算準備等議題，提供實務案例與程式碼範例，幫助讀者全面掌握資料平台效能最佳化與成本效益的關鍵。

資料函式庫 效能調校
查詢監控 效能分析 成本最佳化 雲端成本 資料管道 最佳化

在資料密集型應用中，查詢效能往往是決定系統成敗的關鍵因素。透過查詢監控，我們可以深入瞭解資料函式庫的執行狀況，找出效能瓶頸，並據此制定最佳化策略。查詢監控不僅能提升系統效能，還能降低營運成本，提升使用者經驗。對於動態生成的查詢陳述式，查詢監控尤為重要，它能幫助我們理解資料模型如何應對實際的資料使用模式，並及時發現潛在問題。除了資料函式庫層面的監控，建立完善的資料管道監控機制也是至關重要的，這能幫助我們追蹤資料流的每個環節，確保資料的完整性和一致性。此外，在雲端環境下，成本控制是另一個需要重點關注的議題。透過有效的成本管理策略，我們可以最大限度地利用雲端資源，避免不必要的開銷。

效能調校洞察：查詢監控的重要性

在資料平台的開發與維護過程中，查詢監控是一項不可或缺的工具，尤其是在面對動態生成的查詢陳述式時。透過捕捉查詢計畫（query plans），可以深入瞭解資料模型如何應對實際的資料使用模式。

查詢監控的價值

查詢監控能夠提供關於資料存取模式的寶貴資訊，從而幫助開發者建立高效的資料結構，包括資料模型、檢視和分割槽策略。這些決策最終會影響到資料處理管線的設計。

實際案例：保險資料平台

在一個保險資料平台的專案中，分析師執行了大量複雜的查詢，這些查詢生成了許多中間表來切片和切塊資料。為了改善效能，開發了一套策略來監控和分析使用者查詢。

如何實施查詢監控

  1. 收集查詢資訊：包括查詢陳述式、執行時間和查詢計畫。

    • 例如，在Postgres中，可以透過設定特定的引數來記錄查詢陳述式和執行時間。

  2. 識別高影響力查詢：

    • 根據使用案例，定義什麼是高影響力查詢，例如由最重要的系統使用者執行的查詢，或是被認為最關鍵的查詢。
    • 分析查詢模式而非個別查詢，例如，針對特定表格的查詢是否特別慢，或是常見的查詢過濾條件是否與目前的分割槽策略不符。

  3. 使用指標評估查詢影響力：

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

例項分析

查詢ID平均查詢時間（秒）CV總查詢時間（秒）
110.14,000
2400.23,200
3750.81,800
  • 查詢ID 1：總查詢時間長，但平均查詢時間短且CV低，可能是一個頻繁但不一定需要最佳化的查詢。
  • 查詢ID 2：平均查詢時間長且CV低，是一個需要最佳化的目標。
  • 查詢ID 3：平均查詢時間長但CV高，表示執行時間波動大，最佳化的效果不確定。

最佳化機會

識別出高影響力查詢後，可以針對這些查詢進行最佳化。例如，向分析師提供最慢查詢的資訊，幫助他們重新設計作業以獲得更好的效能。

最小化監控成本

長期儲存遙測資料的成本較高，可以選擇儲存部分重要的離散指標，以減少資料足跡。在選擇要儲存的指標時，需要考慮未來的使用需求，例如儲存平均消費者延遲的四分位數或百分位數（如P99），以排除異常值。

監控資料管道：導航效能、可靠性和成本的關鍵

在處理資料管道時，瞭解系統的行為就像擁有一張詳細的地圖，能夠幫助你規劃未來的路徑，從被動反應轉變為主動預防。系統監控提供了基本的「路線圖」，透過資料量、吞吐量、消費者延遲和工作負載利用率等指標，讓你掌握資料管道的全貌，瞭解資料變化如何影響效能和基礎設施需求。

建立監控地圖

系統監控提供了資料管道的基本概覽，包括資料量、吞吐量、消費者延遲和工作負載利用率等指標。這些指標讓你能夠理解資料變化對效能和基礎設施的影響。

資料量的重要性

資料量的變化可能反映了資料來源的變化，也可能是管道中存在 bug 的跡象。結合資料量指標和對管道運作及資料特性的瞭解，可以幫助你判斷變化的原因。

容量規劃與預算

監控資料量有助於進行容量規劃和預算編制。例如，鳥類別遷徙資料中的季節性變化可以幫助你決定資源預留和調整雲端支出預測。

深入瞭解管道效能

除了監控資料量，還需要關注管道的吞吐量、消費者延遲和工作負載利用率等指標，以全面瞭解管道的效能。

吞吐量的變化

吞吐量的下降可能指示資源不足，進而引發可靠性問題。相反，吞吐量的提升可能意味著有機會節省成本。

消費者延遲的影響

對於串流管道，消費者延遲可以顯示發布者和消費者之間的資料量是否匹配。持續的訊息積壓可能會限制效能，甚至影響可靠性，因此設定消費者延遲的警示閾值非常重要。

工作負載利用率的監控

工作負載利用率反映了管道對資源的利用效率。如果持續低於可用工作負載，意味著資源浪費，可以減少工作負載。結合工作負載利用率和消費者延遲，可以幫助你判斷如何改善效能。

資源利用率與垂直擴充套件

監控資源利用率（包括記憶體、CPU、磁碟和網路資源）可以幫助你瞭解哪些資源限制了處理程式，從而選擇合適的垂直擴充套件方案。

常見問題與解決方案

  • 程式被終止、容器頻繁重啟或作業執行時間過長，都可能是資源利用率不足的跡象。
  • 結合資源限制和組態檢查，可以幫助你瞭解限制發生的位置，並進行相應的調整。

詳細監控與效能分析

除了高層次的吞吐量監控，還需要深入分析各階段和流程的效能。雖然效能分析（profiling）可以提供非常詳細的資訊，但也可能降低系統效能。因此，建議在測試環境中使用，並可選擇性地關閉以平衡效能與洞察力。

監控管道故障與錯誤處理

監控管道故障時，如果能夠註解錯誤指標並標明失敗原因，將有助於快速進行根因分析，並區分間歇性問題和需要立即關注的趨勢。

日誌記錄與偵錯策略

記錄高基數（high-cardinality）資訊可以提供詳細的日誌，有助於偵錯。結合低基數（low-cardinality）資訊（如管道階段和錯誤來源），可以快速定位問題。

查詢效能最佳化

資料存取是資料管道的重要目標。監控查詢效能是最佳化成本與效能的重要機會。分析最耗費運算資源的查詢，可以幫助最佳化資料模型或查詢本身，從而降低運算成本並提升分析客戶的滿意度。

長期監控與統計分析

雖然能夠即時檢視儀錶板對於偵錯很有幫助，但長期儲存大量遙測資料並不必要，也不符合成本效益。建議捕捉連續監控資料的統計資訊，以進行長期追蹤。

推薦閱讀

  • 《Spark：The Definitive Guide》第18章，提供了關於Spark監控和常見問題解決策略的建議。
  • Google的《Site Reliability Engineering》第6章，提出了監控分散式系統的四大關鍵訊號。

圖表翻譯：

此圖示呈現了監控資料管道的重要指標及其相互關係，包括資料量、吞吐量、消費者延遲、工作負載利用率等。透過這些指標，可以全面瞭解資料管道的運作狀況，並及時發現潛在問題。

@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

圖表翻譯： 此圖示顯示了監控資料管道中的關鍵指標之間的關係，包括資料量如何影響吞吐量和消費者延遲，以及這些指標如何進一步影響工作負載利用率和資源利用率，最終指導效能最佳化的方向。

雲端資料管道開發的關鍵要點

開發雲端資料管道是一項複雜的任務，需要仔細規劃和執行。就像小時候學習騎乘波浪板一樣，需要掌握時機和技巧，才能順利抓住波浪。在雲端開發中，這意味著需要了解如何控制成本、最佳化效能和確保資料品質。

預防勝於治療

在雲端資料管道開發中，偵錯和修復問題可能非常耗時和昂貴。為了避免這些問題，需要了解潛在的風險並採取措施加以緩解。本文著重於闡述雲端資料管道開發中的風險，並提供緩解策略。

控制運算成本

動態的資料管道工作負載加上多種雲端運算購買選項，使得很容易超支。為了避免這種情況，需要進行基準測試，以確定所需的運算組態，並採用自動擴充套件等成本最佳化策略。

基準測試的重要性

基準測試可以幫助您確定所需的運算組態，以確保可靠性和效能。這也可以讓您瞭解在考慮無伺服器運算時所需的資源。

自動擴充套件的優勢

自動擴充套件可以根據工作負載和管道操作的可變性，動態調整運算資源，以實作成本最佳化。

組織雲端資源

在雲端中，很容易失去對資源的追蹤。為了避免這種情況，需要在設計過程的早期花時間組織雲端資源。這可以幫助您限制和追蹤成本，避免不必要的浪費。

標記和標籤資源

雲端服務提供者提供了多種工具來幫助您組織雲端資源。您可以標記和標籤運算資源和雲端儲存，以追蹤不同專案、組織或客戶的成本。

生命週期策略和日誌過濾

生命週期策略和日誌過濾可以幫助您限制收集和保留的資料量，從而降低成本。

為中斷做好準備

在雲端中，中斷是不可避免的。無論是由於低成本中斷運算例項的終止、API 速率限制還是臨時服務中斷，中斷都可能發生在資料管道中的任何地方。

防禦性設計策略

為了減少中斷的影響，需要採用防禦性設計策略，例如重試管道階段或低階服務呼叫。

資料去重複策略

在某些情況下，冪等設計可能不可行。在這種情況下，計劃資料去重複策略可以幫助減少不必要的影響。

確保資料品質

在資料管道中，產生不良資料可能是最糟糕的事情。為了避免這種情況，需要採用綜合的方法，包括測試、驗證和監控。

使用架構驗證資料

可以使用架構來驗證資料在管道中的移動過程中是否正確。可以根據需要停止執行或丟棄不良資料。

重點關注關鍵欄位

不需要對所有資料進行架構驗證，可以重點關注關鍵欄位。

雲端成本預算準備

在整本文中，你已經學會如何以具成本效益的方式設計和開發資料管道。你評估了不同的計算和儲存分配方案，根據當前和近期的資料管道營運目標做出適當的決策。你實施了設計策略以降低資料損壞和重新計算的成本，並採用開發策略以最小化雲端服務成本。在此基礎上，你建立了監控機制，以便觀察管道在你所做的設計選擇和資源分配下的表現。

這個過程不僅幫助你建立具成本效益的設計，還為你提供了有關雲資源支出去向和原因的寶貴資訊。即使你的日常工作不涉及預算報告，溝通如何節省成本也將有助於推動你的職業發展。瞭解成本權衡的工程師對於那些主要關注公司財務狀況的人來說是寶貴的合作夥伴。你有能力根據節省成本的要求採取行動，並告知他人這樣做的權衡。

在本附錄中，你將學習如何利用這些資訊，並使用歷史帳單資料、估計成本和管道工作負載預期來建立基本的雲支出預算。

這只是預算和預測的冰山一角，但它將幫助你利用本文所學的知識來傳達一些關於雲支出預期的基本數字。如果你想了解更多關於這個主題的資訊，請檢視 FinOps Foundation 及其官方《Cloud FinOps》。正如 FinOps Foundation 網站上所述，「FinOps 是關於賺錢的」。透過提高雲成本的可見度並鼓勵跨功能部門對這些費用的所有權，FinOps 幫助公司投資於有助於收入和利潤的系統。

設計可變性

在設計資料管道時，保持對變化的敏感性至關重要。資料來源會變化，新的資料來源會被新增，新的分析使用者會請求額外的資料轉換——這樣的例子不勝列舉。在設計、測試和監控資料管道時，牢記這一點將減少工程開銷。

為變化設計

不要浪費工程時間在次優的程式碼函式庫上。遵循軟體開發的最佳實踐，旨在建立易於更改的程式碼函式庫。模組化設計將使管道與特定的技術解耦，使您更容易新增、刪除或修改依賴項。根據功能將程式碼隔離到單獨的元件中，將使重構和測試變得更容易。

組態設計

可組態的設計是適應變化的強大工具。尋找機會將變化的來源抽象到組態中，使您能夠在進行最少程式碼更改的情況下快速測試和佈署更新。

自動化測試

自動化測試是為變化而設計的另一個關鍵要素。作為CI的一部分的單元測試和端對端測試對於在程式碼或資料更改時驗證管道功能至關重要。同樣，使用模式自動化測試資料建立將幫助您保持偽資料與資料來源的變化保持同步。

監控變化

觀察是意識到效能、成本和可靠性變化的必要條件。資源利用率是否下降？也許您有機會縮減規模，或者也許有一個錯誤阻止了資料的攝取。

監控資源、效能和系統級別的指標將有助於快速回答這些問題。這些指標的趨勢可以揭示降低成本的機會，並提前提醒您需要重新審視容量規劃或效能。一旦您進行了更改，這些指標將幫助您評估影響。

隨著時間的推移，您將瞭解管道健康狀況下的指標表現，以及哪些變化是危險訊號。根據這些條件建立警示將幫助您保持在問題的前沿。

重點回顧

  • 設計可變性：模組化設計、可組態設計和自動化測試是應對變化的關鍵。
  • 監控變化：透過監控資源、效能和系統級別的指標，您可以快速識別問題並評估更改的影響。
  • 預算和成本管理：瞭解雲資源的支出去向和原因，利用歷史帳單資料、估計成本和管道工作負載預期來建立基本的雲支出預算。

結語

撰寫一本技術書籍是一項艱鉅的任務，閱讀它也是如此。如果你已經讀到這裡，我想說謝謝！我希望在閱讀完這本文後，你在應對資料管道開發的多維挑戰時能夠更加得心應手，並在雲端開發中具有更高的成本效益信心。

內容解密：

本文旨在幫助讀者掌握以具成本效益的方式設計和開發資料管道的技能，透過實踐本文中的策略和技術，讀者可以在雲端環境中更有效地管理和最佳化資料管道，從而提高開發效率並降低成本。

雲端預算準備：成本效益與細節的重要性

在當今的商業環境中，雲端運算已成為企業營運的重要組成部分。準備一份詳盡的雲端預算不僅能夠幫助企業掌握成本，還能提升利益相關者的信任度。本篇文章將探討雲端預算的關鍵要素、成本結構分析以及如何進行準確的成本估算。

細節決定成敗

在購買昂貴商品時，人們總是希望瞭解所支付的對價。試想一下，如果你正在市場上尋找一台昂貴的筆記型電腦，並遇到兩個不同的廣告，如圖 A-1 所示。

圖 A-1：不同詳細程度的筆記型電腦廣告

兩台筆記型電腦的價格相同，但左側廣告缺乏詳細資訊。儘管它可能表現得與右側的筆記型電腦一樣好甚至更好，但沒有更多的資訊，你無法確定。你知道右側的筆記型電腦提供了更多的細節，因此你對所花的 3,000 美元更有信心。同樣地，缺乏詳細資訊可能會讓人懷疑是否有某些東西被隱瞞了。

這種感覺正是你在向利益相關者展示預算時應該避免的。提供雲端預算的詳細資訊有助於建立信任，並展示你在成本效益方面所做的努力。

展示系統的影響力

雖然傳達雲端支出細節很重要，但企業更關心的是系統的影響力。最終，這個系統如何造福公司？這與「計算設計的需求收集」相關：與利益相關者合作，以確定如何最好地滿足他們的需求，並在系統設計中做出正確的權衡。在討論預算時，務必包含系統的影響力。

雲端預算的結構

在最高層級上，您的預算是您在特定時間內預期發生的雲端服務成本。從這一點出發，下一個需要考慮的層級是成本來源的不同領域。儲存、資料輸出和計算往往是主導類別。其他領域包括資料函式庫、監控、網路和 CSP 管理的服務，如 AWS Lambda 或 Athena。

歷史資料的作用

如果您的管道已經執行了一段時間，歷史雲端成本可以幫助您啟動預算。CSP 提供了按不同服務分類別帳單的方法，並按標籤、標籤和專案進行篩選，以幫助您找出與管道相關的費用。圖 A-2 顯示了一個非常簡單的雲端帳單，您可以看到不同服務的明細。

圖 A-2：世界上最小的雲端帳單，按服務型別分類別

如果您以前從未看過雲端帳單，那麼看到您被收取費用的各種專案絕對會讓您大開眼界。深入瞭解細節可以幫助您瞭解成本如何分解。如同在第三章中所學到的，雲端儲存成本包括儲存靜態資料以及請求、建立和刪除物件的事件。圖 A-3 顯示了圖 A-2 中 S3 成本的儲存成本明細。

圖 A-3：簡單儲存服務成本明細

在這種情況下，主要成本驅動因素是資料儲存，您可以看到服務請求非常少，以至於它們根本沒有增加整體成本。

將這些帳單明細與您對管道的瞭解相結合，將有助於您建立一個關於雲端成本如何在系統中分佈的心智模型。即使是計算成本與儲存成本的大致比例，也可以幫助您估計未來的支出。

建立心智模型以評估預測資料

主要 CSP 提供了預測工具，作為其帳單服務的一部分，利用歷史使用情況來預測未來的雲端帳單。這些預測並不總是正確。您對系統的瞭解加上歷史使用資料，可以幫助您確定預測是否可靠。

實際案例

在一個我參與的專案中，我們曾經進行了一次性事件，調整自動擴充套件設定。在幾週內，我們執行了大型測試匯入作業，以評估不同的自動擴充套件規則，從而增加了我們的雲端計算成本。

當我們檢視帳單預測時，這次性增加被預測為月度增加，使我們的未來雲端計算支出看起來似乎正在上升。這是在審查雲端預算時向公司長官層澄清的重要點，因為 CSP 提供的預測並不準確。

新專案的成本估算

如果您正在開展新專案，或者很難從雲端帳單中分離出管道成本，您可以進行粗略的成本估算。CSP 提供了成本估算工具，例如 AWS 價格計算器、Azure 價格計算器和 Google Cloud 價格計算器，可以幫助進行估算。

程式碼範例：使用 AWS 價格計算器進行成本估算

# 使用 AWS Pricing Calculator 進行成本估算
def estimate_cost(instance_type, usage_hours, storage_gb):
    # 假設價格（實際價格需查詢 AWS Pricing Calculator）
    instance_price_per_hour = 0.1  # 示例價格
    storage_price_per_gb = 0.05  # 示例價格
    
    # 計算例項成本
    instance_cost = instance_type * usage_hours * instance_price_per_hour
    
    # 計算儲存成本
    storage_cost = storage_gb * storage_price_per_gb
    
    # 總成本
    total_cost = instance_cost + storage_cost
    
    return total_cost

# 示例用法
instance_type = 1  # 例項數量
usage_hours = 720  # 每月使用小時數
storage_gb = 1000  # 儲存容量（GB）

total_cost = estimate_cost(instance_type, usage_hours, storage_gb)
print(f"預估總成本：${total_cost:.2f}")

內容解密：

此程式碼範例展示瞭如何使用 Python 簡單估算 AWS 資源的成本。主要功能 estimate_cost 需要三個引數：例項型別（數量）、使用小時數和儲存容量（GB）。根據假設的價格（需查詢 AWS Pricing Calculator 取得實際價格），分別計算例項成本和儲存成本，最終傳回總成本。這種簡單模型可以根據實際需求進行擴充套件和調整，以滿足更複雜的成本估算需求。