廣告資料管道的基礎架構選項 (第 2 部分)

本文將著重說明各種廣告平台通用的資料管道與機器學習工作,並且對提供廣告工作負載的基礎架構選項 (第 1 部分) 提供補充說明。這兩篇文章都為以下系列文章提供必要的脈絡資訊:

本文是下列系列文章的一部分:

如要瞭解這些平台如何搭配運作,以及本系列文章中使用的廣告技術術語,請參閱建構廣告平台 (總覽) 的相關說明。

資料管道中使用的資料儲存庫 (在第 1 部分中說明) 有 (不重複的) 使用者個人資料儲存庫內容儲存庫 (在第 1 部分中說明) 和報表/資訊主頁儲存庫 (在第 1 部分中說明)。這些資料儲存庫主要有兩個資料來源:事件和第三方資料。本文將著重說明事件管理。如要進一步瞭解第三方資料及其如何用於充實使用者資料,請參閱充實資料相關頁面 (第 4 部分)。

事件生命週期

從原始事件成為實用資料的資料管道可分為以下三個部分:

  • 收集及儲存 (擷取):透過訊息系統或將檔案重複上傳至儲存系統來收集和儲存。
  • 處理:分批處理或透過串流模式即時處理 (如果資料更新間隔很重要)。
  • 匯出 (或載入):直接從資料處理工具匯出或透過自訂工作流程匯出。目的地通常就是前述的儲存庫。

廣告技術中最常見的事件如下:

  • 廣告與出價要求:通常會從外部系統收到,要求中包含的詳細資料構成了選擇廣告的輸入部分。
  • 曝光:廣告素材會加載在網頁上,但並不一定是可見的。
  • 可收費曝光:已轉譯及/或可見的曝光。
  • 點擊:使用者可透過點擊廣告素材來採取的動作。
  • 轉換:目標使用者對廣告客戶網站執行的動作。

與即時出價相關的事件會在 RTB 出價工具的基礎架構選項 (第 4 部分) 中說明

收集

事件的建立方式如下:

  • 廣告或出價要求執行個體:收到要求的執行個體會傳回廣告素材或出價回應的網址。
  • 收集器執行個體:執行個體會傳回不可見的像素,來記錄曝光與/或收集目標使用者對廣告執行的動作 (例如點擊或播放影片)。
  • Stackdriver Logging:在某些情況下,這個記錄會取代收集器執行個體與伺服器記錄檔。

事件的收集方式如下:

  • 將事件發佈至 Cloud Pub/Sub 等訊息傳遞系統,或寫入至本機記錄檔的自訂程式碼。
  • 第三方工具或網路伺服器上的原生記錄功能。
  • 支援所選第三方軟體並與 Stackdriver Logging 整合的 GCP 記錄代理程式。

事件的擷取方式如下:

  • 在本機寫入記錄檔時,能以幾乎即時的方式擷取,然後定期複製到共用儲存空間 (例如 Cloud StorageBigQuery Capacitor) 進行處理。如果處理涉及分析查詢,則通常會使用 BigQuery 儲存空間。
  • 使用 Stackdriver Logging 時,或者收集器直接寫入至 Cloud Pub/SubApache KafkaRabbitMQ 等低延遲資料儲存庫或訊息傳遞系統時,能即時擷取。即時處理系統通常會使用這個選項。

Stackdriver Logging 可以協助執行這些工作,因為 Stackdriver Logging 會直接從 Compute Engine、Google Kubernetes Engine,甚至是 HTTP 負載平衡等 GCP 產品擷取資料。Logging 也可以將資料直接匯出至 BigQuery 進行臨時分析、將資料串流至 Cloud Pub/Sub 進行快訊與即時處理,還可以分批匯出至 Cloud Storage 進行備份或聯合分析。

以下一些範例說明了前面幾個重點,並考慮到作業、費用與資料更新間隔等因素:

選項 費用 營運負擔 資料更新間隔
使用 bq load,每 X 秒將記錄檔複製到 Cloud Storage 一次,然後複製到 BigQuery Cloud Storage 不收取輸入費用

BigQuery 不收取擷取費用

BigQuery 儲存費用
需要管理檔案、失敗、重試和同步處理 幾乎即時
使用Cloud Functions,每 X 秒將記錄檔複製到 Cloud Storage 一次,然後將檔案複製到 BigQuery Cloud Storage 不收取輸入費用

BigQuery 不收取擷取費用

Cloud Functions 需額外收費

BigQuery 儲存費用
Cloud Functions 有利於負載管理。仍須撰寫邏輯方面的程式碼。 幾乎即時
使用 Stackdriver Logging 匯出至 Cloud Pub/Sub Cloud Pub/Sub 費用 即時
使用本機 Daemon 將記錄串流至 Kafka 執行 Kafka 需要儲存與運算費用 除非使用 GCP 代管選項,否則需要 Kafka 的設定與管理費用 幾乎即時或即時,視 Kafka 的設定而定

提示:使用運算執行個體收集事件時,請務必考慮使用先佔 VM 來節省費用 (如運算平台一節所述)。

儲存資料

您儲存資料的位置受到以下因素的影響:資料的格式、存取及使用資料的方法,以及儲存資料的費用。如果資料格式為非結構化格式,或者需要在處理前先儲存,那麼如前文所建議,請考慮使用 Cloud Storage。對於結構化資料,您也需要考慮存取記錄的費力程度。下圖可以協助您評估存取模式,藉以將作業數與費用降到最低。

協助您匯出資料的建議

讀取密集儲存模式一節 (第 1 部分) 敍述用來儲存及提供服務的選項,本節的其餘部分則說明如何透過串流及批次處理的方式使用分析資料儲存庫。

您可以透過串流的方式在儲存資料之前先處理原始資料。如果您也想要讓臨時查詢作業能夠立即使用資料,請考慮串流至 BigQuery。您可以使用這個從 Cloud Pub/Sub 到 BigQuery 的 Cloud Dataflow 範本輕鬆達成此目的。

如要使用重複批次處理的方式,您可以將資料儲存在共用及可擴充的環境中來合併資料。有一種常見的模式,就是每隔幾分鐘將記錄檔從本機位置移到物件儲存空間一次。檔案名稱通常會加上前置與後置字串,例如:logs_serverABC_timestamp123.txt

您可在下列儲存系統執行分析工作負載:

  • Cloud Storage:您可以使用其標準、NearlineColdline 儲存空間級別來儲存資料,以快速存取、備份或封存。如有可能,請將標準儲存空間 (建議的分析選項) 設定為地區值區。請將儲存空間的地區設定為與處理資料的運算資源所在的相同地區。Cloud Storage 可從大部分的 GCP 產品存取,包括 Cloud DataprocCloud DataflowCloud Dataprep by Trifacta 與 BigQuery。
  • BigQuery:BigQuery 不僅是一款功能強大的查詢引擎,還具有自己的儲存空間,稱為 Capacitor。Capacitor 可以讓您儲存 EB 規模的資料,您可以從 Cloud Dataproc、Cloud Dataflow 與 BigQuery 查詢引擎存取 BigQuery 儲存空間。BigQuery 的長期儲存方案可讓您 90 天未編輯的分區儲存費用下降約 50%。
  • Cloud Bigtable:當您每天有數以億萬計的事件需要收集時,如果需要在幾毫秒內讀寫巨量資料,Cloud Bigtable 就是您的絕佳選擇。您可以透過 HBase API 及其他用戶端存取本產品。Cloud Bigtable 也適用於圖表、時間序列與分析等大數據生態系統。

以下是我們的一般性建議:

  • 將原始資料儲存在 BigQuery,同時進行其他任何處理工作。您可以輕鬆在此以每小時、每天、每週或每月的頻率執行匯總作業,載入選項則視您的需求而定。詳情請參閱 BigQuery 載入資料說明文件
  • 如果您很重視費用問題,可以將儲存在 Cloud Storage 的資料免費載入至 BigQuery,或者以相較於串流更低的價格使用 bq loadCloud Functions、Job API 或聯合查詢。前兩個選項有配額限制。
  • 您可以使用 BigQuery 的儲存功能 (例如分區叢集) 來將查詢時間與費用降到最低。

處理事件

選擇建構處理管道的技術時,請考慮以下幾點:

  • 延遲時間:決定哪些資料需要即時處理。例如,您可能需要盡快計算預算需求。
  • 正確性:某些價值儘管也許不用立即計算,但也必須精確計算,例如帳單金額。
  • 高可用性:在每天輸入數以億萬計的資料時,幾分鐘的停機時間都可能導致產生巨大的財務影響。
  • 營運負擔:「全年無休」可能並不是技術資源的最佳用法。

請見如下範例:

  • HTTP 負載平衡記錄會使用 Stackdriver Logging 即時擷取。
  • 某些記錄必須立即處理,才能計算出剩餘的預算。
  • 曝光次數是以小時為單位匯總及要求;廣告活動展示頻率上限則以日為單位計算。

一般公司利用 lambda 架構來平衡其資料處理管道是一件很平常的事情:

  • 透過即時處理管道來快速估算近似值。
  • 透過其他離線批次處理管道來獲得精確性。

Lambda 資料處理管道

本節說明您可以用來實作 lambda 與 kappa 資料處理架構的一些 GCP 產品,以及 Cloud Dataflow

  • Cloud Dataproc (批次與串流):如果您已有現成的 Hadoop 或 Spark 工作及指令碼,可將其依原樣遷移至 Cloud Dataproc、GCP 代管的 Spark 或 Hadoop。
  • Cloud Dataflow (批次與串流):如果您有新的工作負載,並且正在考慮使用進階串流功能,或者想要整合式模型程式設計模型,Cloud Dataflow 提供了一種全代管服務可以執行 Apache Beam,Google 也對外開放其原始碼。Cloud Dataflow 也支援許多輸入與輸出方式,例如 Cloud Pub/Sub 與 Kafka。Cloud Dataflow 也同樣為支援僅處理一次概念的串流與批次資料提供整合式程式設計模型。
  • BigQuery (批次):考慮 ELT (擷取、載入與轉換) 方法,或在將資料載入至資料倉儲之後執行後續轉換時,可以針對 SQL 轉換使用 BigQuery。BigQuery 除了具有代管特性以外,也提供使用者定義函式。如要對這些查詢進行自動化調度管理,請考慮 Cloud Composer,Cloud Composer 是代管的 Apache Airflow
  • 第三方工具:您可從 Hadoop 生態系統或 Compute Engine 上的 Storm 或 Google Kubernetes Engine (GKE) 等工具安裝及管理工具。

以下架構根據這些需求描述了建議事項:

  • 即時擷取事件。
  • 每秒運算一些計數器。
  • 每小時匯總一次曝光次數。
  • 每天計算廣告的點閱率。

使用 Cloud Pub/Sub 的資料處理管道

資料處理工作流程如下:

  1. 將事件寫入至 Cloud Pub/Sub。
  2. Cloud Dataflow 將事件層級資料直接寫入至 BigQuery。
  3. Cloud Dataflow 也會將資料範圍限定在 1 秒的間隔之內,藉以執行必要的匯總作業,並將計數器寫出到地區 Cloud BigTable 執行個體。
  4. BigQuery 會重複執行查詢,以匯總資料並具體化結果。這可以透過 Cron 工作或透過 Cloud Composer 使用排程選項來排程。
  5. 使用者前端可以使用 BigQuery 做為 OLAP 資料庫。詳情請參閱報表相關頁面 (第 1 部分)。
  6. 地區廣告伺服器會查詢附近的 Cloud BigTable 執行個體,藉以快速擷取計數器。

請按照下列一般性建議來建構資料處理管道:

  • 使用 Cloud Pub/Sub 將營運負擔降到最低,或考慮將 Apache Kafka 做為在 GCP 上代管的服務執行。
  • 考慮使用 Apache Beam 撰寫您的管道,透過整合式程式設計模型達成批次與串流的目標。
  • 在 Cloud Dataflow 上執行 Apache Beam,藉以享有全代管服務的優勢,這類服務可在工作的完整生命週期中自動調度工作站資源數,並動態重新平衡工作,減少工作的整體處理時間。

如果您的事件或其他資料需要以視覺化的方式探索、清理及準備分析,請考慮使用 Cloud Dataprep。您不需要撰寫程式碼,Cloud Dataprep 可允許您匯出 Cloud Dataflow 範本,讓您重複使用及排程。

匯出項目

擷取及處理事件之後,可以將結果匯出至以下位置:

  • 匯出至 BigQuery 或 Cloud Storage 等離線儲存庫進行離線處理,包括匯總與分析。
  • 匯出至 Cloud Bigtable、Cloud Datastore、Cloud Memorystore 及第三方儲存庫等提供服務的儲存庫。舉例來說,前端伺服器會使用這些儲存庫來擷取有關使用者個人資料的資訊,並於選取廣告時更新計數器。
  • 當資料需要進一步下游處理,或正傳送成為快訊時 (例如在管理預算時) 匯出至 Cloud Pub/Sub 或 Kafka 等訊息傳遞系統。

資料複製是另一個匯出使用案例。舉例來說,當您需要讓資料接近您的前端伺服器,甚至可能就「在」伺服器上時,可以採取兩種方法:

  • 在某些情況下,如果您選擇的技術支援的話,可以使用原生複製功能。像 Redis 與 Aerospike 等技術則支援地區內的複製,但是,跨地區複製可能比較困難。
  • 其他技術可能不支援複製,在這種情況下,您可以使用在 Compute Engine 或 Cloud Pub/Sub 上執行的訊息傳遞系統與處理器實作複製功能。

下圖顯示了一些不同的方法:

使用 GCP 儲存庫複製資料的結構

使用 Cloud Dataflow 可以即時處理資料,而使用 BigQuery 則可離線處理資料,在此之後:

  • Cloud Dataflow 可使用 Apache Beam Redis IO 將資料直接寫入至 Redis 叢集,然後接著將複製資料轉送至本機工作站。
  • Cloud Dataflow 會將訊息發佈至 Cloud Pub/Sub。然後自動調度資源的訂閱者集區會讀取訊息,並將訊息部署到 Compute Engine,由 Compute Engine 將訊息寫入至在 Compute Engine 執行的 Aerospike 叢集。
  • 來自 BigQuery 離線工作的記錄會透過 Cloud Composer 排程匯出至 Redis 與 Aerospike 叢集。

以下是匯出資料時的建議事項:

  • 確認選擇的資料儲存庫能夠處理您的讀取與寫入模式。否則,請考慮為讀取基礎架構去耦,如讀取密集儲存模式一節 (第 1 部分) 詳述。
  • 對於分析,請使用 BigQuery 的叢集分區功能將查詢費用與持續時間降到最低。
  • 針對個位數毫秒讀取與寫入,請考慮使用 Cloud Bigtable。請針對高可用性啟用複製功能。
  • 如要即時寫入至 BigQuery,請使用 Apache Beam BigQuery IO 的預設 Streaming API。有了 Apache Beam Java SDK,您可以使用 FILE_LOADS,透過 Cloud Storage 進行微批次寫入來降低費用。
  • 對於短於 1 毫秒的繁重寫入作業,請考慮使用安裝於 Compute Engine 或 Cloud Pub/Sub 的第三方資料儲存庫。

自動化

您的資料管道可能會透過其中一種離線工作流程來達成以下目的:

  • 將 BigQuery 匯總資料複製到其他儲存庫以進行快速的 OLAP 資訊主頁處理。
  • 將更新的客戶區隔等提供資料複製到 Redis、Aerospike 或 Cloud Bigtable。
  • 跨資料中心複製資料。
  • 將中繼資料從使用者前端資料庫 (在第 1 部分中說明) 複製到可以處理密集讀取作業的儲存庫 (在第 1 部分中說明)。

針對端對端自動化與失敗管理,請考慮使用 Apache Airflow 適用的 Cloud Composer。Airflow 是在 GCP 上管理工作流程的建議開放原始碼技術。DAG 可由事件手動觸發,或排程重複執行。

如果您需要更簡單的事件驅動動作,可對在 Cloud Storage 上建立的新檔案,或對發佈至 Cloud Pub/Sub 的新事件觸發 Cloud Functions。Cloud Functions 是全代管服務,可消除營運負擔。對於自訂程度更高的無伺服器選項,請考慮閱讀 Knative,這是前景看好的 Kubernetes 型外掛程式,可用來建構、部署及管理無伺服器工作負載。

分析

BigQuery 是建議用於分析處理與臨時查詢的資料倉儲,因為 BigQuery 具有以下特性:

提示

請考慮使用 BigQuery 授權資料檢視。授權資料檢視可以讓您共用查詢結果,而不授予基礎資料表的存取權,並限制使用者能夠查詢的資料欄。

如果您想要從 Hive 遷移,請考慮將 Parquet 檔案載入至 BigQuery

雖然我們建議針對您的分析與 SQL 離線處理使用 BigQuery,GCP 還是提供了其他選項:

  • 針對 Hadoop 工作負載,包括 Apache Spark、Hive 與 Pig 在內,請考慮 Cloud Dataproc。Cloud Dataproc 連接器可讓您在 Cloud Storage 上執行 Apache Spark 與 Hadoop 工作,並且有一些優點,包括高資料可用性、與其他 GCP 服務之間的互通性,以及 HDFS 相容性。
  • 您可在 Compute Engine 或 Cloud Pub/Sub 上安裝及管理第三方工具。 對於前端使用者而言,Druid 是除了 BigQuery 以外較常用的一款低延遲 OLAP 資料庫。

建構機器學習功能

處理事件不僅僅只是與清除和匯總有關。為您的資料管道加上機器學習功能,便可新增一些智慧功能,例如建議更佳的廣告或建立虛擬使用者區隔條件來做為模型特徵使用。GCP 提供完整的機器學習 AI 基礎知識,包括:

您的資料湖泊或倉儲每天可能會收集和儲存數以億萬計的事件,無論是 Cloud Storage 還是 BigQuery,您都可以利用這些資料訓練與出價相關的強大模型,例如:

  • 決定是否出價。
  • 預估 CTR。
  • 最佳化出價價格。
  • 區隔客戶。
  • 計算客戶效期價值 (LTV)。
  • 建議選取的廣告。

選擇您的機器學習平台時,必須回答一些問題:

  • 我對我的資料有多瞭解?
  • 我有多少資料?
  • 會有多少資料用在訓練上?
  • 訓練會在線上還是離線進行?
  • 預測會在線上還是離線進行?
  • 廣告放送是否可以不依據預測執行?

下圖顯示一般機器學習流程,其中包含以下步驟:

  1. 使用 BigQuery 清除/準備資料集。
  2. 將訓練與評估資料集匯出至 Cloud Storage。
  3. 使用 AI 平台訓練模型。
  4. 將模型匯出至 Cloud Storage。
  5. 初始化工作站時,從 Cloud Storage 匯入模型。
  6. 使用 TensorFlow 模型以低延遲時間在本機執行預測。

一般機器學習工作流程

準備資料與特徵工程

準備好將資料饋給至機器學習模型之前,請執行下列工作:

  1. 匯出資料集以瞭解手上工作的資料適切性。
  2. 彙整多個資料表的資料,並篩選出不適用的記錄,藉以清除及準備資料集。
  3. 擷取、建構及選取特徵,為觀察的對象建立資訊充足、具有區別能力的屬性。

對於儲存在 BigQuery 中的資料,以及外部聯合資料來源,BigQuery 都非常適合執行這些工作。將您篩選、選取的資料集匯出至 Cloud Storage 進行特徵工程之前,可以使用 BigQuery 查詢及探索資料。

提示:除了使用 BigQuery 探索資料以外,您還可以將 Cloud Dataprep 連線至 BigQuery 來進行取樣,並以視覺化方式剖析資料

下一個工作通常需要您考慮是要在線上還是離線進行預測。進行線上預測時有一點很重要,就是要考慮如何從預測的要求資料中擷取特徵:

  • 對於線上預測,您需要在訓練與預測期間執行相同的特徵建立步驟,藉以防止出現偏差。 tf.Transform 可以讓您定義這些預先處理步驟,在訓練與評估期間利用 Apache Beam 大規模執行這個工作,也可將步驟做為 Tensorflow 圖形的一部分匯出以提供預測。 這個網誌提供有關此程序的一些不錯的額外見解。
  • 如要進行離線預測,您可以使用與訓練及預測階段相同的方法。您可以使用 BigQuery 建立特徵做為批次預先處理的一部分。例如,您可以使用 hash 函式向量化特徵,或透過彙整作業尋找關聯值。

訓練與評估

GCP 提供各種選項,讓您訓練及評估模型,包括:

  • 使用 AI Platform 在全代管的環境中執行 XGboostScikit-Learn 和 TensorFlow 訓練和評估工作。AI Platform 也提供如自動化超參數調整分散式訓練等額外功能。

  • 直接對 Compute Engine 執行個體執行訓練與評估工作。您將必須安裝所需軟體套件。在適合的情況下,您也可以利用 GPUTPU 或先佔 VM 來降低費用與處理時間。

  • 使用 Kubeflow 安裝及執行 TensorFlow 與許多機器學習工具,例如 Kubernetes 的容器化環境中的筆記本。

  • 直接從 SQL 介面使用 BigQuery 機器學習來進行結構化資料的離線訓練。

您可根據以下需求選擇機器學習平台:

  • 如要降低成本,請搭配使用 Compute Engine 與先占 VM。
  • 如果您需要全代管的環境來進行訓練、部署和內容提供,請使用 AI Platform。
  • 如要建立可在任何 Kubernetes 叢集上執行的可重現擴充式機器學習環境,請使用 Kubeflow。
  • 當您擁有結構化資料時、想離線預測,並且希望實作線性或邏輯回歸時,請使用 BigQuery 機器學習。

預測

使用訓練一節中提及的相同產品進行離線或線上預測。Compute Engine、Kubeflow 和 AI Platform 都可以使用 TensorFlow Serving 進行預測。這些選項的差異在於營運負擔、調整選項和價格。

如果您要求低延遲時間,也可以直接使用序列化或經過編譯的模型,這在資料管道中可能也很實用。如需其他連結,請參閱後續步驟

提供內容

預測與提供內容有時會歸類為同一種工作,對於線上預測而言也是如此。但是,如果您離線進行預測,然後將相同結果送至資料儲存庫,您將需要在提出要求時從這個儲存庫提供預測內容。

如要快速提供預測內容,您將必須在有效性與效率之間進行取捨。您可以使用不同的方法,或某些方法的組合。如果您決定使用 TensorFlow Serving 來即時預測,請考慮使用 GPU 或 TPU 等加速器,並使用以下其中一種方法來最佳化您用來提供內容的模型:

  • 透過 tf.quantize 進行量化。
  • 將圖形變數凍結為常數。
  • 結構化程式碼,確認預測程式碼中不包含在訓練或評估中產生的任何負擔,例如額外的記錄。
  • 使用 GPU 時,請考慮融合作業,例如融合批次標準化

如果您決定從快速鍵/值儲存庫中使用預先完成的預測,則需要根據特徵的排列建立鍵。假設您要預測是否根據洲別與裝置類型出價:

  1. 建立洲名與行動裝置/網路的所有可能組合。
  2. 儲存這些組合的預測結果。

    預測
    antarctica_mobile 0
    antarctica_web 1
    asia_mobile 1
    asia_web 0
    europe_mobile 1
    europe_web 0
    northamerica_mobile 1
    northamerica_web 1
    southamerica_mobile 1
    southamerica_web 0
    oceania_mobile 1
    oceania_web 0

    然後您可在收到要求時對正確的鍵執行快速擷取。Redis、Aerospike 與 Cloud Bigtable 都很適合這種使用案例。

實作之前,請記住以下幾點:

  • 如果您有許多特徵,組合的大小可能大於鍵的大小上限。
  • 如要支援大量要求及大量的鍵,並且要避免在特定資料列上出現資源使用率不均的情形,請考慮發佈鍵及雜湊鍵 (的部分)。Cloud Bigtable 的鍵視覺化工具可協助您診斷出此類問題。
  • 如果您沒有這種連續值的類別資料,則必須對這些資料進行值區化作業。確認每個特徵的值區大小的工作,可由特徵自行完成。
  • 請使用嵌入功能來計算鍵之間的距離。如果鍵不存在,您可以尋找最近的相鄰鍵。您可以透過不同的技巧建立區域敏感雜湊法。運算這些雜湊就是機器學習的工作。

後續步驟