基於 Flink-Starrocks 建設之家廣告實時數據

背景介紹

汽車之家作爲全球訪問量頭部的汽車網站，其廣告業務每天會產生大量的投放效果數據，以反饋執行進度供運營同學及時進行業務策略調整，具體數據包含廣告請求數據、廣告曝光數據、廣告可見曝光數據、廣告點擊數據等。

汽車之家廣告主題離線數倉從 2015 年開始建設至今, 一直能夠滿足核心廣告業務的日常分析及報表支持。然而數據的時效性對企業的客戶服務風控以及精細化運營越來越重要，商場如戰場，實時有效的分析出有價值的信息，對企業的決策運營策略調整有很大幫助，及時提升與保障對客戶的服務滿意度及交付效果。基於此，我們縱觀技術架構發展歷程，可選用的實時計算引擎有 Storm、Spark Streaming、Flink，存儲引擎有 StarRocks、Clickhouse、TiDB、Iceberg，我們就圍繞這些技術方案進行嚴謹的調研與對比，最終確立使用最適合當前廣告業務情景的方案，來支撐廣告核心業務數據。

當前離線數倉架構

隨着車智投、DSP、ADX 等核心系統的逐步建設迭代，我們依據 OneData 數據倉庫中臺核心方法論建設了對應的廣告主題數倉，完成了數據標準化、資產治理化、主題式數據服務等能力達成。在業務使用端輸出了包括廣告位、廣告計劃、廣告素材等核心業務數據集，置於面向業務分析人員的 OLAP 工具平臺上，業務人員即可自主查詢。

有兩個原因促使我們建設了針對核心數據集的小時級別輸出。首先僅面向品牌廣告部分業務，當時業務方對實時統計沒有剛性需求。我們自驅提供了小時級別的運營數據供使用。其次當時實時化技術未在業內得到廣泛應用，使用風險尚未探明，實時化技術對於廣告業務的應用一直在學習探查中。

經過長期的學習探查，已具備業務實時化能力和人員儲備。如果能及時獲取效果數據，縮短問題恢復時間和策略調整時間，對於服務滿意度以及交付度會有極大提升。

實時數倉技術架構

計算引擎選型對比

上圖是我們選擇業界比較流行的 3 個實時計算引擎進行選型分析：

**1. 首先放棄 Strom。**因爲我們要最大的保障數據準確性，所以對於 Exactly-Once 是強需求，在一致性保證上 Storm 的一致性語義是 At-least-once，只能保證數據不丟失，不能保證數據的精確一次處理。

2. 我們再來對比 Flink 和 Spark Streaming。

**a) 處理模式對比。**流處理有兩種模式：Native 和 Mirco-batch。Native 是數據進入後立即處理，而 Mirco-batch 是數據流入後，先劃分成 Micro-batch，再處理。Mirco-batch 數據會存在一定延遲，時效性相對不高。基於 reciver 的 Spark Streaming 使用了 Mirco-batch 模式，只能算是準實時；而基於 direct stream 的 Spark Streaming 則與 Flink 一樣是使用的 Native，是真正的實時處理，且能夠保障 Exactly-once 語義，與廣告業務需求契合。

**b) 開發維護對比。**我們團隊對於 Flink 和 Spark Streaming 的技術積累相差不大，且二者均支持相對友好的 SQL 任務開發模式。但是公司的開發維護平臺對於 Flink 是大力支持，而 Spark Streaming 的 SQL 模式幾乎沒有支持，考慮後續穩定性與維護性，最終我們決定使用 Flink 作爲實時處理引擎。

綜上，選用 Flink。

存儲引擎選型對比

當前廣告數據處理的存儲引擎幾乎全部依賴 Hive，而 Hive 是不能夠滿足高併發或低延遲，要滿足整體實時流程的順利串行，一個高性能的實時存儲引擎也是不可或缺的。

基於以上我們選擇了 Clickhouse、Starrocks、Iceberg、TiDB 等數據庫作爲調研對象：

1.Clickhouse、Starrocks、TiDB 時效性在秒級，而 Iceberg 則是分鐘級的，這裏我們放棄了 Iceberg。

2.TiDB 無預聚合功能且索引能力相對較弱，任何查詢過來都是借力於各個分節點的即時計算能力，造成集羣大量吞吐與計算，性能相對 Clickhouse 和 Starrocks 要弱。放棄 TiDB

3.Clickhouse 和 Starrocks 都能支持明細模型和預聚合模型，但是 Clickhouse 不支持標準 SQL 有一定的使用成本，而且對多表關聯查詢支持較弱，再考慮到運維成本較高，最終選擇了 Starrocks。

綜上，選擇 Starrocks。

實時數倉分層設計

我們繼續將 OneData 體系用於實時數倉建設，結合業務主題分爲 4 層：ODS 源數據層、DWD 明細層、DWA 彙總層、APP 主題層。

1.ODS 源數據層：埋點日誌投遞或者流量日誌採集實時存儲到 Kafka 中，線上業務數據庫通過 Flink 任務採集 MySQL Binlog。

2.DWD 明細層：Flink 對實時數據完成維度擴充，雙流 Join，實時聚合等處理通過 Sink  Connector 落到 Starrocks。

3.DWA 彙總層：由 DWD 層通過 ETL 得到明細寬表或者根據業務需求進行實際的指標聚合。

4.APP 應用層：基於業務需求將 DWA 層的數據進一步整合統計指標數據，面向前端展現，直接支持業務看板服務。

在廣告效果的應用實踐

廣告實時數據流程

  1. 服務端上報請求日誌到日誌收集服務；客戶端上報可見曝光日誌、點擊日誌數據到日誌收集服務。

  2. 日誌收集服務對埋點日誌進行統一處理，採集到 Kafka 中。

  3. 通過 Flink 消費 Kafka，對數據進行數據清洗、聚合等操作，將結果寫入到 Starrocks。

  4. 最終通過之家內部 OLAP 自助分析平臺配置呈現實時數據集。

Flink 開發詳細流程

ODS 層包括廣告點擊表、廣告曝光表和廣告可見曝光表。在 Flink 平臺通過原生的 DDL 語句定義 Kafka 表，將廣告點擊數據、廣告曝光數據、廣告可見曝光數據分別映射成一張 Flink 表。

本層輸出廣告流量寬表。在 Flink 平臺通過原生的 DDL 語句定義 Starrocks 表，將處理後的結果映射成一張 Flink 表。

1.Starrocks 明細模型，基於明細模型指定排序 Key 爲 dt、type、platform、click_filter_rule。

  1. 開啓動態分區，指定動態分區字段 dt，配置動態分區起始結束時間，超過動態分區時間範圍的分區會被自動刪除，以節省存儲和計算資源。

1.ODS 廣告點擊表和 ODS 廣告可見曝光表分別通過 pv_id 和 filter 字段過濾掉無效數據，之後合併兩張表爲一張表。

  1. 合併後的中間表同 ODS 廣告曝光表關聯以補充缺失維度，獲得完整的明細層數據寫入到 Starrocks。

我們通過建立 Starrocks 物化視圖來完成 DWA 層的建設工作。Starrocks 會自動維護物化視圖的數據，無論是新的導入，還是刪除操作都能保證 Base 表和物化視圖表的數據一致性。無需任何額外的人工維護成本。業務查詢時，會自動匹配到最優物化視圖，並直接從物化視圖中讀取數據，提升查詢效率。視圖 DDL 示例如下：

APP 層分爲廣告計劃主題分析表和廣告位主題分析表，在 OLAP 工具平臺上以數據集的形式呈現廣告請求量、廣告點擊量、廣告曝光 CRT、廣告點擊轉化率等指標。

綜上，從原始數據接入到最後報表呈現全部完成，且滿足業務方需求，爲業務運營提供決策支持手段。

問題與方案

1.Flink 導入數據到 Starrocks 時指定 sink.properties.format 爲 json, 併發達到 50 且批次大小超過 100MB 時導致導入數據失敗。

解決方式：將 sink 配置 sink.properties.format 改成 CSV，節省數據空間。

  1. 實際使用過程中 Starrocks 中出現複雜 view，比如包含去重、join、view 嵌套查詢、聚合等操作的 view，查詢時報錯 unknow error，通過重建 view 可以恢復正常查詢。此問題不能穩定復現。

針對此問題有以下 2 種方案：

（1）添加監控，定時檢測 view 狀態，並執行重建操作。

（2）已將問題反饋社區，社區給出解決方案：升級到 2.1.8 之後的版本。

方案 1 實現簡單，但不能根本解決問題，方案 2 在原服務上升級，如果新搭建一套需要並行來測試運行，耗時長。結合現狀，選擇方案 1 優先解決線上業務問題，同時對方案 2 充分測試並制定詳盡穩定的升級計劃。

  1. 點擊數據、可見曝光數據需要和曝光數據做延遲關聯，曝光數據需置於指定緩存窗口期內，以保障關聯效率。

經過測試，數據緩存窗口期爲 2 小時，與離線天數據對比準確率低於 90%，不具備可用性。數據緩存窗口期爲 4 小時與離線天數據對比準確率爲 95% 以上，4 小時內數據準確度爲 100%，可滿足實時業務需求。

服務穩定性保障

Kafka-connectors 監控

基於 Prometheus、Grafana 對 Kafka 消費速率及消費延遲等指標進行監控

Flink 任務監控

Flink 平臺任務告警配置中內置了任務延遲監控、任務重啓監控、任務保存點失敗監控、作業探活監控等告警策略

Starrocks 監控

基於 Prometheus、Grafana 對 Starrocks 服務器內存使用率、磁盤使用率、磁盤 IO 利用率、服務器 CPU IO 佔比，磁盤讀寫數據、集羣狀態等指標監控。

總結與規劃

在 Flink+Starrocks 實時數倉技術框架下，數據時效性從原來的小時提升至秒級，每秒處理約 10W+ 條數據，實時準確率達到 95% 以上，大幅提升了業務數據反饋效率。且相關產品人員充分體會到了實時數據使用的快感，後續相繼提出了許多實時化升級的需求，正在對接中。

後續我計劃在兩方面展開工作：第一，調研 Starrocks 外部表的使用，實現異構數據查詢功能探查，減去多引擎關聯情景下的數據遷移成本；第二，持續關注 Flink 和 Starrocks 社區動態，加強溝通學習，進一步提高廣告業務整體鏈路處理速度。

作者簡介

汽車之家

徐超

主機廠技術部 - 廣告技術及系統團隊

目前任職於主機廠事業部 - 技術部 - 廣告技術及系統團隊 - 數據系統組，負責之家廣告實時數倉架構設計及開發工作，致力於爲廣告業務提供實時、準確的數據服務。

之家技術

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/WlBDYCO9D-FCbL5IhRVgmg

猜你喜歡