架構︰大規模擷取分析事件和記錄最佳化

本文描述一種將 Google Cloud Platform (GCP) 上大規模擷取分析事件最佳化的架構。就本文的目的而言,「大規模」是指每秒超過十萬次事件,或全部匯總事件酬載大小超過每秒 100 MB。

您可以使用 GCP 的彈性、可擴充代管服務收集大量傳入的記錄和分析事件,然後進行處理,並輸入資料倉儲 (例如 BigQuery)。

針對任何大量擷取分析資料的架構,皆應考慮哪些資料需要以接近即時的方式存取,哪些則可短暫延遲後進行處理,並將適當分離資料。分離法有以下這些優點︰

  • 記錄完整性。您可以看到完整的記錄。不會因為串流配額限制或取樣而遺失記錄。
  • 降低成本。事件和記錄串流插入的計費費率,比使用批次作業從 Cloud Storage 插入要來得昂貴。
  • 保留查詢資源。將低優先順序的記錄移到批次載入,可以避免對保留的查詢資源造成影響。

下列架構圖顯示此種系統,並說明用於擷取的「熱路徑」和「冷路徑」的概念︰

一般擷取路徑

架構總覽

在這個架構中,資料來自兩個可能的來源︰

從任何一個來源擷取資料之後,系統會依據訊息的延遲時間要求,將資料放在「熱路徑」或「冷路徑」。熱路徑使用串流輸入,可以處理連續的資料流,冷路徑則為批次處理,會依據您決定的時間表載入資料。

記錄事件

您可以使用 Stackdriver Logging 來擷取標準作業系統記錄設備產生的記錄事件。Stackdriver 在許多 Compute Engine 環境上預設為可使用,其中包括標準映像檔,也可以透過 Stackdriver Logging Agent 在許多作業系統上安裝。記錄代理程式是 App Engine 和 Kubernetes Engine 的預設記錄接收器。

熱路徑

熱路徑記錄

在熱路徑中,您在 Stackdriver Logging 接收器 中指定篩選器,並串流至多個 BigQuery 表格,以選擇需要由您的服務監控和分析的重要記錄。對於 ERRORWARN 記錄等級,請使用獨立的資料表,如果預期出現高流量,可以依據服務進一步分割。此一最佳做法可使每資料表每秒的插入次數低於極限值十萬筆,並可使針對此資料的查詢保持良好運行。

冷路徑

冷路徑記錄

對於冷路徑而言,可使用指向位於 Cloud Storage 值區的 Stackdriver Logging 接收器選擇不需要以接近即時的方式處理的記錄。記錄會被批次處理,並以 Cloud Storage 分時批次的形式寫入記錄檔中。接下來,您可以使用標準 Cloud Storage 檔案匯入過程,透過 Google Cloud Platform 主控台、指令列介面 (CLI),或甚至一個簡單的指令碼,將這些記錄批次載入 BigQuery。批次載入並不會影響熱路徑的串流擷取或查詢效能。在大部分情況下,最好將冷路徑記錄直接合併至熱路徑記錄使用的同一份資料表,以簡化疑難排解和報表生成。

分析事件

分析事件可由應用程式的服務在 GCP 中產生,或從遠處的用戶端傳送過來。透過 Cloud Pub/Sub 擷取這些分析事件,並於 Dataflow 中處理,可提供延遲時間短、總處理量高的系統。儘管將熱分析和冷分析事件送到兩個獨立的 Cloud Pub/Sub 主題並非不可行,您應使用獨立的熱路徑和冷路徑 Cloud Dataflow 工作,將所有的事件傳送到同一個主題,然後處理它們。如此一來,您可以透過更新 Cloud Dataflow 工作,改變分析事件遵循的路徑,這比部署新的應用程式或用戶端版本要來得容易。

熱路徑

熱路徑事件

有些事件需要立即分析。例如,某一事件可能表明不受歡迎的客戶行為或行徑惡劣者。您應使用自動擴展的 Cloud Dataflow 工作,從 Cloud Pub/Sub 中挑出此種事件,然後將事件直接傳送到 BigQuery。Dataflow 工作可將此資料劃分,以確保不至於達到每個資料表每秒十萬列的極限。這也可以確保查詢作業的執行效能。

冷路徑

冷路徑事件

需要每小時或每天追蹤,但從來不需要立即處理的事件,可以由 Cloud Dataflow 推送到 Cloud Storage 上的物件。您可以使用 Cloud Platform 主控台、CLI 或甚至一個簡單的指令碼,從 Cloud Storage 啟動載入至 BigQuery 的作業。您可以把它們合併至與熱路徑事件相同的資料表。批次載入的分析事件如同記錄冷路徑,並不會對保留的查詢資源造成影響,還可以讓串流擷取路徑保持合理的負載。

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Architectures