「我們查詢超過 2 PB 的分析數據和數 TB 的交易數據，每天處理 10 億個事件。Apache Beam 使我們能夠平行化數據處理、最大化吞吐量，並加速這些數據集的移動/ETL。」
Booking.com 使用 Beam 進行大規模廣告競價
背景
Booking.com 透過投資於消除旅行障礙的技術，並讓每個人都能更輕鬆地體驗世界，將數百萬的旅客無縫連接到難忘的體驗。Booking.com 是 Booking Holdings 的品牌，Booking Holdings 是全球最大的線上旅遊及相關服務供應商，服務對象為消費者和當地合作夥伴。為了協助人們在 220 多個國家和地區探索目的地，Booking Holdings 整體在 2022 年的行銷支出為 $59.9 億 美元，其中 Booking.com 是 Google Pay Per Click (PPC) 搜尋廣告上主要的旅遊廣告商。
Booking.com 行銷技術部門的 PPC 團隊負責運行此規模 PPC 廣告所需之基礎設施和內部工具。PPC 團隊的主要目標是可靠且有效率地最佳化所有搜尋引擎供應商的 PPC、衡量並分析廣告成效資料、管理廣告階層，並調整廣告條件。Apache Beam 透過提供有效的抽象化，協助建立可靠、高效能且符合成本效益的大規模資料處理基礎設施，來支援此目標。
邁向 Beam 的旅程
PPC 廣告是 Booking.com 行銷的關鍵業務促銷管道。由於搜尋引擎每天有數十億次的搜尋量，他們使用 PPC 搜尋廣告來確保使用者在搜尋結果中獲得最相關的產品。在幕後，PPC 團隊管理營運基礎設施，以處理廣告成效回饋、評估歷史成效、支援產生競價的機器學習作業，並將競價回報給搜尋引擎供應商。
Booking.com 先前實作的大規模廣告競價是自訂堆疊批次管線，包含 MySQL 資料儲存、cron 排程，以及實作商業邏輯的 Perl 腳本。此設計最終遇到效能瓶頸，難以跟上每秒競價不斷增加的輸送量需求。失去的機會成本加上維護複雜性的成本，已大於完全重寫的成本。
在 Apache Beam 發揮作用之前，大規模競價基礎設施已多次重寫。PPC 團隊最新實作以 Apache Beam 為基礎的資料生態系統的核心概念，起源於 2020 年底。參加 Beam Summit 和 Beam College 社群活動，協助團隊了解開源 Apache Beam 抽象模型，該模型也可以透過 Dataflow 執行器作為受管理服務使用。
將此概念介紹給團隊其他成員很簡單，因為 Apache Beam 模型很容易理解，它可以隔離商業邏輯，並協助建立心理模型。
PPC 團隊決定透過建立新的原型 Java 管線來下載廣告成效報告，以試用此框架。
有了 Apache Beam，我們在開發時間上實現了多倍的加速。我們實際上在 3 週內交付了一個管線。如果我們必須使用任何其他框架來實作管線，則可能需要花費整整三個月的時間。
第一個 POC 證明成功後，PPC 團隊將 Apache Beam 置於其資料基礎設施的核心位置。執行 Dataflow 受管理服務提供了一個機會，讓團隊專注於新功能，而不是維護自己的運算和儲存基礎設施。Apache Beam 將執行階段實作細節抽象化，讓 PPC 團隊能夠專注於商業邏輯，並利用平行處理來輕鬆進行水平擴展。他們是各種 GCP 產品的重度使用者，也利用 Apache Beam I/O 連接器與各種接收器和來源進行原生整合，例如 BiqQuery、Firestore 和 Spanner。
Apache Beam 作為我們資料基礎設施和處理的有效抽象化。有了 Dataflow 執行器，我們也不需要擔心維護執行階段和儲存基礎設施，以及雲端供應商鎖定的問題。
文件品質，以及蓬勃發展的 Apache Beam 開源社群、郵寄清單中的熱烈討論，以及大量使用者建立的內容，讓新使用案例的加入變得非常容易。
在設計和實作新的生態系統時，Apache Beam 開源社群、文件和 Youtube 內容都非常有幫助。
目前，Apache Beam 為 PPC 團隊的大規模廣告競價基礎設施提供批次和串流管線的支援。
大規模廣告競價
在概念上，大規模廣告競價基礎設施會接收廣告競價請求和資產，並提供提交至多個服務的暫存，以大規模處理廣告成效結果。廣告競價基礎設施依賴 Apache Beam 批次和串流管線來與 Big Query、Spanner、Firestore、Pub/Sub 來源和接收器互動，並使用 Beam 的狀態處理來進行廣告服務 API 呼叫。
在設計資料基礎設施時，PPC 團隊的主要目標是最大化每秒競價的輸送量，同時仍遵守搜尋引擎廣告 API 在帳戶層級上設定的請求速率限制。PPC 團隊實作了串流 Apache Beam 管線，利用鍵控 PCollection，根據帳戶 ID 將外寄廣告修改分群、將其分組成批次，並平行執行資料處理。此方法協助最佳化團隊數千個廣告帳戶的輸送量，並實現大規模的效能和可靠性提升。
Apache Beam 使我們能夠平行化數據處理，並以非常大的規模最大化吞吐量。
PPC 團隊使用內部 API 介面將查詢提交至大規模競價基礎設施，該基礎設施會將查詢路由到 Google 和 Bing 的對應廣告競價管線。對於 Google 分支，API 會呼叫 Invoker 雲端函式，該函式會從 BigQuery 讀取資料、彙總資料，並執行分析，然後將中間結果儲存到 BigQuery 的暫存表中。然後，Invoker 會呼叫 Ingestor Apache Beam 批次管線，該管線會將資料發佈到 Pub/Sub。
另一方面，Google Ad Mutator Apache Beam 串流管線會監聽每天超過 10 億個 Pub/Sub 事件，並將對應的請求傳送至 Google Ads API。此作業在設計時考慮了背壓，確保最佳效能，同時也考慮了 分割、平行處理和鍵順序傳遞保證等因素。然後，結果會寫入 BigQuery 的結果表和 Spanner 的庫存，每天處理超過 100 GB 的資料。
最後，Daily Importer Apache Beam 批次管線會抓取庫存資料並將其散佈以供下游工作使用，每天也會處理 100 GB 的資料。然後，資料分析師會將飯店預訂的傳入串流與所廣告的庫存資料進行比對，並評估 PPC 廣告成效。
Apache Beam 框架的多功能性和彈性是整個流程的關鍵，因為它允許將批次和串流處理組合到統一的流程中，同時還能與各種具有不同特性和語義的來源和目的地進行整合。該框架還為交付和順序提供保證，所有這些都以大規模的方式進行，並為串流處理提供最佳的權衡。
Google Ads Mutator 和 Bing Ads Mutator 管線是 Booking.com 大規模競價基礎設施不可或缺的一部分。這些串流 Apache Beam 管線會處理所有來回搜尋引擎廣告 API 的資料，並將大量廣告成效報告寫入 Cloud Spanner 的庫存中。Apache Beam 內建的 Cloud Spanner SpannerIO。寫入轉換可透過將變更 分組為批次來更有效率地寫入資料，以最大化輸送量，同時也遵守 Spanner 的每次交易限制。由於 Apache Beam 減少了變更的鍵範圍，PPC 團隊得以在 Spanner 中實現成本最佳化並改善處理效能。
同樣地，為了保持在廣告 API 速率限制等級內，PPC 團隊利用 Apache Beam 及時和 狀態處理以及基於 Redis 的微服務，來維護競價的速率限制。PPC 團隊具有自訂的「彙總並傳送」函式，可將傳入的變更命令累積到緩衝區中，直到緩衝區填滿為止。此函式會從速率限制器請求變更配額，並將請求傳送至廣告 API。如果內部速率限制器或廣告 API 要求等待，此函式會啟動重試計時器並繼續緩衝傳入的命令。如果沒有要求等待，此函式會清除命令緩衝區，並將查詢發佈至 Pub/Sub。
Apache Beam 提供視窗化的聚合功能，以預先聚合變更命令，並透過使用計時器和具狀態的操作來確保傳遞保證。透過使用BagState，Apache Beam 可以將元素新增至集合中，以累積一組無序的變更。ValueState 則儲存批次、批次大小和緩衝區大小的類型化值，這些值可以在 DoFn 的 ProcessElement 和 OnTimer 方法中讀取和修改。
支援分頁讀取的執行器可以處理比可用記憶體大的個別資料包。Apache Beam 重試計時器用於輸出在經過一段處理時間後儲存在狀態中的緩衝資料。快閃計時器用於防止命令在緩衝區中停留太久，尤其是在命令不頻繁且無法填滿緩衝區的情況下。
Beam 模型的具狀態功能使我們能夠藉由緩衝傳入的資料直到可以被消耗，來精細控制每秒的競標次數，並維持比其他潛在解決方案更高的處理效能。
為了提高可觀測性並為使用者提供監控其提交狀態的方法，PPC 團隊還開發了一個自訂函數，該函數會產生帶有自訂鍵的指標，以計算已接收和已傳送的請求數量。Apache Beam 的可擴展性使 PPC 團隊能夠在廣告變更器管道中以額外區塊的形式實作這個額外的監控工具。
成果
Apache Beam 為 Booking.com 大規模績效行銷「飛輪」背後的資料物流提供動力，每月針對跨多個資料系統的廣告競標工作流程進行 100 萬次以上的查詢，每日掃描 2 PB 以上的分析資料和數 TB 的交易資料，在尖峰時每秒處理超過 10 億個事件，傳送數千則訊息。
Apache Beam 提供了急需的平行處理、連接和分割功能，以及強大的按鍵順序傳遞保證，以平行處理 Booking.com 數千個廣告帳戶，優化成本，並確保大規模廣告競標處理的效能和可靠性。
Apache Beam 將串流管道的處理時間從 6 小時縮短到 10 分鐘，這是一個驚人的 36 倍執行時間縮短。高效能且快速的 PPC 廣告競標基礎設施現在每天從搜尋廣告推動 200 萬個以上的住宿晚數預訂。Apache Beam 抽象化簡化了新團隊成員的入職，使編寫和維護管道更容易，並將從設計文件到在生產環境上線的上市時間縮短多達 4 倍。
PPC 團隊計畫擴大使用 Apache Beam 統一處理功能，將多個批次和串流管道合併為單一管道。
Apache Beam 作為一個模型，允許我們以非常宣告式的方式編寫業務邏輯。在下一個開發迭代中，我們計畫將多個廣告變更器管道合併為單一串流管道。
此資訊是否對您有幫助？