使用Flink SQL進行實時效能監控：AdTech廣告用例

廣告技術（Ad Tech）是一個統稱，它描述用於管理和分析程式化廣告活動的系統和工具。數字廣告的目標是儘可能多地吸引相關受眾。因此，廣告技術本質上與處理大量資料有關。

在此部落格文章中，我們將研究如何關聯兩個事件流-廣告投放（所謂的展示次數）和點選次數，並計算重要的廣告技術指標-點選率（CTR）。我們的計算將使用Apache Flink的水平可擴充套件執行引擎基於執行中的資料進行。我們將專注於獲得結果，而無需使用Java或Scala編寫任何程式碼，而是完全依賴SQL。

在典型情況下，廣告的放置是通過稱為實時出價的機制執行的。從本質上講，實時競標是一種拍賣，眾多參與者競相向特定終端使用者顯示橫幅或視訊（統稱為Creative）。在此過程中，需求方平臺（DSP）獲得了向使用者顯示廣告的產品，這些廣告由使用者的裝置ID標識並用其投注進行回覆。

跟蹤顯示的印象和單擊的印象是數字廣告技術的關鍵任務之一。

儘管放置廣告的過程在很大程度上是自動化的，但廣告活動經理和業務分析師通常仍會採用相當程度的手動控制。通常，活動的定義和受眾的選擇器（如人口統計，原籍國以及活動的績效標準）是手動定義的。可能需要密切監視活動的績效並調整某些引數，尤其是在釋出後的早期階段（即驗證假設的時間）。

為什麼要進行流處理？

傳統上，通過使用批處理來解決獲取大量資料的見解的任務。這種方法與數字廣告業務的高度動態性相矛盾。實時獲取見解至關重要-等待一個小時或更長的時間以完成一個批處理任務，以完成原始資料的處理，同時由於活動的初始引數錯誤而耗盡預算是非常不可取的。此外，對於依賴於關聯兩個後續事件的任何度量標準，對於位於批處理“臨界值”相對側的事件，批處理將無法提供正確的結果，因此將由兩個不同的批處理作業進行處理。 

為什麼使用Flink SQL？

監視活動的任務通常由資料或業務分析師執行。由於業務的動態性質，可能會與新的資料饋送進行潛在的臨時整合，向現有資料流新增新維度以及進行其他類似的調整。在這種情況下，需要消除資料分析師在執行日常任務時對資料工程師的依賴性。為了實現這一點，需要具有低採用障礙的靈活工具集。SQL是資料分析的通用語言，其知識十分廣泛。在Flink中執行SQL語句使您可以利用Flink的水平可伸縮流處理引擎的功能，而無需成為Java或Scala開發人員。

示例

在我們的示例中，我們將使用兩個資料流。首先，通過定義它們的模式和表選項將這些流注冊為表。

第一個流是廣告展現流。這些事件中的每一個都表示在實時出價拍賣中獲勝，並向使用者成功展示了廣告素材。它包含諸如廣告素材的尺寸，國家/地區程式碼和廣告系列ID之類的詳細資訊。

CREATE TEMPORARY TABLE `impressions` (
 bid_id VARCHAR NOT NULL,
 `timestamp` VARCHAR,
 serve_time AS 
    TO_TIMESTAMP(`timestamp`, 'EEE MMM dd HH:mm:ss zzz yyyy'),
 campaign_id INT,
 creative_dimensions VARCHAR,
 country_code VARCHAR(2),
 WATERMARK FOR serve_time AS serve_time - INTERVAL '5' SECOND
)
WITH (
 'connector' = 'kafka',
 'format' = 'json',
 'properties.bootstrap.servers' = 'kafka.svc:9092',
 'properties.group.id' = 'impressions',
 'scan.startup.mode' = 'latest-offset',
 'topic' = 'impressions-ingest'
);

在此示例中，事件以JSON格式從Kafka獲得資料使用。

WATERMARK FOR serve_time AS serve_time - INTERVAL '5' SECOND

意味著我們可以容忍5秒的時間外的訂單交付的事件，仍然產生正確的結果。

點選廣告後，我們可以在顯示廣告後跟蹤的最重要結果之一。

CREATE TABLE TEMPORARY `clicks` (
 correlation_id VARCHAR NOT NULL,
 `timestamp` VARCHAR,
 click_time AS 
    TO_TIMESTAMP(`timestamp`, 'EEE MMM dd HH:mm:ss zzz yyyy'),
 tracker VARCHAR,
 WATERMARK FOR click_time AS click_time - INTERVAL '5' SECOND 
)
WITH (
 'connector' = 'kafka',
 'format' = 'json',
 'properties.bootstrap.servers' = 'kafka.svc:9092',
 'properties.group.id' = 'clicks',
 'scan.startup.mode' = 'latest-offset',
 'topic' = 'clicks-ingest'
);

的SQL

點選流的correlation_id對應於印象流的bid_id欄位。這將成為連線各個資料流和計算點選率（CTR）的基礎。但是在研究點選率計算之前，讓我們首先從更簡單的方法開始，檢查所有部件是否位於正確的位置。

以下查詢計算在60秒的翻轉視窗中按campaign_id和creative_dimensions細分的展示次數：

SELECT 
 campaign_id, 
 creative_dimensions, 
 TUMBLE_ROWTIME(event_time, INTERVAL '60' SECOND) 
   AS window_end, COUNT(*) AS c
FROM impressions
GROUP BY 
  TUMBLE(event_time, INTERVAL '60' SECOND), 
  campaign_id, 
  creative_dimensions
ORDER BY window_end, c DESC;

更多點選標題見原文

結論

儘管此部落格文章側重於將Flink SQL應用於Ad Tech用例，但一般主題適用於各種場景，並且具有以下要求的任意組合：

• 實時瞭解發生的事件資料
• 降低組織中訪問實時資料並對其執行分析的障礙 
• 減輕傳統資料庫的負擔