導讀

本文詳細闡述了基於Flink構建的實時反作弊流式過濾系統，針對大流量場景下的複雜特徵計算、高頻策略熱更新、模擬過濾驗證及多場景數倉對接等核心挑戰，提出來多項解決方案，實現了秒級特徵計算的實時過濾功能，有效支撐高併發場景下的精準風控判定，並通過ClickHouse與圖靈雙鏈路數據輸出，滿足實時監控與離線分析的多樣化需求，為互聯網業務提供了高吞吐、低延遲、強穩定的實時反作弊解決方案。

01 簡介

在互聯網業務高速發展的今天，反作弊已成為APP廠商生態穩定運行的重要保障。作弊行為層出不窮，包括惡意點擊、刷單、羊毛黨等，這些行為不僅會破壞平台公平性，還可能造成巨大的經濟損失。因此，構建一個高效、靈活、可擴展的實時反作弊系統變得尤為重要。

反作弊系統根據業務屬性和時效性可分為三類：在線反作弊、實時反作弊與離線反作弊。其中，在線反作弊具備最高的時效性，能夠即時響應風險；離線反作弊依託最全面的信息，支持深度分析與建模；而實時反作弊則兼具二者優勢，提供平衡的時效性與信息豐富度。

在線反作弊系統通過快速處理簡單指標進行判斷，例如分析當前請求攜帶的字段信息，並結合基於 Redis 的簡單累計值（如訪問頻率或特定行為計數）來制定策略。這種系統以低延遲為核心，能夠在毫秒級別響應反作弊判定結果，適用於攔截時效要求高的風控需求。

離線反作弊系統通過對完整的離線數據進行大規模、長週期的數據挖掘和樣本分析，為優化線上策略、構建特徵黑產庫和訓練高精度模型提供支持。然而，由於依賴離線數據的批量處理，其時效性相對較低，通常難以滿足實時風控的需求，更適合用於長期策略優化和深度分析場景。

實時反作弊系統能夠在秒級別和分鐘級別對用户的異常行為做出反饋，及時識別作弊用户並對業務進行止損。雖然其時效性略低於在線反作弊，但得益於對豐富維度和行為序列特徵的分析，實時反作弊可以實現更加精準的策略判定，在精準性與時效性之間達到良好的平衡。

本篇文章我們將重點分析實時反作弊流式系統的相關實現。

02 流式系統面臨的核心問題

在實際建設過程中，我們需要解決以下關鍵挑戰。

2.1 複雜的特徵計算

在實時反作弊場景中，用户行為數據規模龐大且動態變化（如電商大促、搜索點擊等），系統需要處理海量的用户行為數據，並需基於時間窗口快速計算多維特徵（如用户點擊頻率、IP集中度、設備關聯賬户數）。這些特徵需覆蓋不同窗口粒度（秒級、分鐘級、天級）和窗口類型（滑動、滾動、會話窗口），以捕捉異常行為模式。

• 窗口特徵計算的挑戰（多維度多窗口多指標聚合）：反作弊策略通常需要基於不同時間窗口（如分鐘級、小時級、天級），不同維度（用户、設備、IP等）進行特徵累積計算。例如，計算某個用户在過去1小時內的點擊次數，或者某個IP在過去24小時內的訪問頻率。這些計算涉及滑動窗口、滾動窗口等多種窗口類型，計算量大且複雜。
• 數據亂序問題：網絡延遲或分區消費不均可能導致事件亂序到達，若未正確處理，會導致特徵計算不準確，進而影響反作弊策略的判定。
• 高併發下的狀態存儲優化：在高併發場景下，特徵累積計算需要頻繁訪問狀態後端（如RocksDB），導致性能瓶頸。例如，當QPS達到數十萬甚至上百萬時，狀態後端的訪問壓力會顯著增加，影響系統的吞吐量和延遲。長週期窗口（如月級）到期時，大量Key需同時清理狀態，引發瞬時資源爭搶，導致作業卡頓。

詳見 3.2 大規模窗口特徵計算，通過 內存緩存+微批處理減少狀態訪問、事件時間排序緩解亂序影響、keyBy和trigger優化降低狀態後端壓力，最終支撐高吞吐場景下的精準計算。

2.2 高頻的策略更新迭代

反作弊策略需要快速響應新型作弊行為。例如，當出現新的刷單手段或惡意點擊行為時，風控團隊需要迅速調整策略，以應對新的威脅。此外，不同業務場景（如廣告點擊、電商交易、社交互動）的反作弊策略差異較大，策略的複雜性和多樣性增加了系統維護的難度。

• 高頻迭代需求：
• 反作弊策略需要根據業務需求和作弊手段的變化進行高頻更新，傳統開發模式（修改代碼→測試→發佈）無法滿足時效性。部分策略需“熱生效”，避免作業重啓導致數據丟失或計算中斷。
• 策略複雜性升級：
• 多規則嵌套：單一策略可能需組合字段匹配（如IP黑名單）、模型評分（如行為異常概率＞90%）、時間窗口特徵（如近5分鐘同一設備註冊賬號數＞3）等多層條件，這些策略的複雜性增加了開發和維護的成本。
• 配置管理風險：
• 人工修改配置文件易出錯(如語法錯誤、字段誤配),導致作業崩潰或策略漏判。

詳見 3.3 配置化，通過全流程的配置化升級和配置文件託管，將策略規則、特徵計算、字段抽取等邏輯抽象為配置文件，支持快速策略調整和上線，減少對底層代碼的依賴，提升策略迭代效率。

2.3 模擬過濾的支持

在反作弊策略上線前，風控團隊需要對策略進行測試和驗證，以確保其有效性和穩定性，這一過程稱為模擬過濾。在實時反作弊系統中，模擬過濾是策略上線前的核心驗證環節，其必要性體現在以下三個關鍵維度：

提前規避線上風險，防止“誤殺”與“漏殺”：直接在生產環境上線新策略存在風險，可能導致誤判或漏判，影響業務正常運行。因此，需要在測試環境中對策略進行模擬過濾，確保其準確性和穩定性。

驗證策略性能，避免作業過載：模擬過濾歷史峯值流量（如大促期間數據），驗證作業在極限負載下的穩定性。

歷史回溯與極端場景覆蓋：從HDFS讀取數月前的全量數據（如黑產攻擊事件日誌），驗證策略對歷史攻擊的檢測能力和進行數據回溯。

詳見 3.4 模擬過濾的實現，通過配置化、線上流與測試流隔離、數據Source改造等方式，加速策略效果驗證環節。

2.4 多場景數倉對接與平台整合

我們的系統產出的數據需要支持業務方的複雜分析需求。例如，基於反作弊結果進行策略優化，實時監控作弊行為的影響，對歷史數據進行深度挖掘。

目前我們支持多種數倉形式（如實時ClickHouse與離線Hive）的數據產出，滿足不同業務場景下的需求，包括實時數據看板、策略評估、歷史回溯等應用。

• 數據產出的便利性：反作弊系統需要將計算結果輸出到多種存儲系統（如ClickHouse、Hive、Redis等），以滿足不同業務場景的需求。例如，實時數據需要寫入ClickHouse用於實時監控，離線數據需要寫入Hive用於歷史分析。
• 自助分析能力：業務方需要對反作弊結果進行多維度的分析，例如按時間、地域、用户羣體等維度進行統計分析。傳統的固定報表無法滿足這種靈活的分析需求。所以支持業務方進行自助分析，能夠根據需求靈活查詢和分析數據，而不依賴開發團隊的支持。

詳見 3.5 便捷的數據分析，通過將反作弊結果輸出到ClickHouse和Hive，支持實時和離線分析。同時，接入TDA（Turing Data Analysis自助分析平台），業務方可以通過簡單的SQL查詢或可視化工具，靈活分析反作弊數據，滿足複雜的分析需求。

03 反作弊流式框架介紹

3.1 反作弊系統整體框架

整個實時反作弊的生效流程圖如下：

上圖展示了 Flink 反作弊流式實時過濾系統 的整體架構，包括 風控平台、實時作業、外部存儲 三大核心模塊，整體流程如下：

• 風控平台（配置分發）：反作弊工程師在平台上編輯策略規則、配置特徵計算邏輯，並一鍵生成配置文件和啓動模擬過濾驗證策略效果。測試通過後，策略配置通過平台分發至實時作業。
• 實時作業（配置解析與執行）：Flink 作業解析平台下發的配置文件後，構建作業各個模塊，包括數據接入、ETL處理、特徵計算、規則匹配等，最後提交併執行流式任務。
• 作業結果存儲（結果輸出）：ClickHouse，存儲實時計算結果，支持快速查詢與監控。Hive：存儲離線數據，用於歷史回溯與深度分析。Redis：提供低延遲查詢，支持在線服務實時訪問反作弊結果。消息隊列：將判定結果傳輸至下游業務系統，供下游實時決策。

Flink作業內部，實時流運行各個模塊拆解如下：

流式作業的主要模塊可以分為：

• 數據接入Source：業務事件日誌數據（用户行為、支付、點擊、搜索等）接入。
• 數據ETL處理：數據清洗、轉換、標準化；簡單維度拼接（ip 映射城市等）；第三方字段請求（風險評分、黑設備、用户畫像等）。
• 多重窗口特徵計算：時間窗口（分鐘級、小時級、天級、周級、月級）、滑動、滾動窗口等，多種維度多種聚合函數進行特徵累積聚合。
• Join階段：負責將特徵和原始日誌進行join。
• 規則策略匹配與判定：機器學習模型打分，配置化規則引擎基於之前的所有信息進行最終判定。
• 下游輸出：實時反饋給線上服務、下發給業務方、入數倉表等方式將判定結果進行輸出落盤。

3.2 大規模窗口特徵計算

對於整個作業而言，主要計算資源就是用於累積基於窗口的特徵。對於業務需求而言，不同窗口下的特徵聚合結果是提升判定的準確率和召回率最重要的信息。

我們的窗口累積邏輯主要基於 Flink 窗口功能實現，包括TumblingWindows、SlidingWindows和SessionWindows，Session窗口使用較少。我們未使用其原生Aggregate 函數，而是採用了更底層的 WindowProcessFunction實現窗口聚合邏輯。這種方式的優勢在於為後續優化提供了更大的靈活性和定製空間。

為了滿足業務訴求，我們也對原生的窗口機制進行了多項優化，主要升級點有以下幾個：

• 提前觸發：無需等待窗口結束即可實時下發累積結果，滿足業務對於數據時效性的要求。
• 批量更新和抗亂序：採用批量狀態更新方式，減少頻繁讀取與寫入，同時在微批更新時進行局部重排序，以降低亂序影響。
• 鍵縮減-粗粒度KeyBy：優化keyBy和窗口觸發器設計，減少狀態訪問頻次，提高緩存命中率，降低計算開銷。

下邊將分別進行介紹。

3.2.1 時效性優化-提前觸發

默認情況下，Flink 的每個窗口自帶一個觸發器（Trigger），在窗口結束時觸發計算並生成聚合結果。然而，在實時性要求較高的反作弊場景中，如果窗口長度長達一天，等待窗口結束再下發結果顯然不符合要求的。因此，我們需要在窗口尚未結束時，通過特定條件提前觸發窗口計算，這種機制稱為“提前觸發”。

Flink 提供了多種現成的窗口觸發方式，包括按ProcessTime定時觸發、按EventTime定時觸發、按固定條數觸發等，同時也支持自定義觸發方式。針對我們的業務需求，目前採用的是按事件時間的間隔提前觸發方式。具體觸發間隔依據不同業務場景設定，能夠在秒級或分鐘級就能得到窗口的聚合結果。

上圖: 展示了 Flink 原生窗口的觸發機制及其聚合過程。每個綠色矩形表示一個窗口，窗口範圍內累積了多個事件，編號為 1、2、3 、4、5。紅色圓圈表示觸發時下發的特徵數據，從上圖可以看到，窗口觸發是在窗口結束時統一執行的，下發了2、5、3、1四條特徵。

下圖：改造後 - 提前觸發機制，展示了優化後的窗口觸發機制，通過提前觸發減少延遲。每個綠色矩形依舊錶示一個窗口，但觸發時間提前，避免了窗口結束時的集中計算，紅色圓圈同樣表示輸出結果。提前觸發機制在窗口中按事件到達順序多次輸出，窗口中的事件可以更早地被處理，提升了時效性。

3.2.2 亂序和性能優化-批量更新和亂序糾正

在大流量場景下的測試表明，當前吞吐瓶頸主要受限於窗口聚合時RocksDB 狀態後端讀寫。由於一條數據會抽取多條特徵，所以特徵窗口累積算子會對 Source 輸入數據進行爆炸式擴展，例如當輸入數據 QPS 達到 10 萬時，特徵累積算子的 QPS 可能攀升至數十萬甚至上百萬，導致大量狀態讀寫請求集中在 RocksDB，使其難以支撐高吞吐需求。

Flink 默認的窗口機制會在每條數據到達時更新累積值，並與狀態後端交互，進一步加劇了 RocksDB 的負擔。為優化性能，我們將窗口觸發和累積調整為微批模式，每次批量更新數據，並引入內存緩存層，微批內優先訪問內存緩存，有效減少狀態的訪問次數。

在百度搜索和點擊流量場景下的測試結果顯示，該優化方案使內存緩存命中率提升至 90% 以上，意味着特徵累積階段減少了約 90% 的狀態後端訪問。

同時，在微批數據內部，我們會進行排序，還能有效緩解數據亂序問題，提高計算準確性。如下圖所示。

上圖：Flink 默認窗口累積機制，**綠色矩形代表窗口的時間範圍，窗口中的每一條數據（標記為 1、2 等）都會觸發累積操作。圖示中展示了 5 條pv的狀態後端訪問，每條pv都需要與 狀態後端（圖中黃色區域）進行交互，包括查詢、更新、寫入等操作。紅色圓圈是輸出的累積結果，紅色邊框標記的條目表示亂序數據。上圖存在兩個問題，第一，對狀態後端的頻繁隨機訪問會導致性能瓶頸，尤其是在高併發和大流量場景下。第二，輸入數據是亂序的情況下，輸出數據也是亂序的。

下圖：優化後的窗口累積機制，**優化引入了內存緩存和微批模式。數據小批量更新（如標記為2、1、4為一批、3、5為一批）。每次窗口觸發時，首先會對本次微批內的數據進行排序(2,1,4被糾正為1,2,4)，然後再累積。累積時，窗口內的累積查詢會先訪問內存緩存，如果內存miss，再訪問狀態後端。最終圖示中僅有 4 次狀態後端交互，較優化前的15次減少11次。數據亂序也得到了緩解。

3.2.3 大流量場景優化-鍵縮減(粗粒度KeyBy)

窗口聚合過程中累積器需要頻繁讀寫狀態後端。此前，我們通過引入緩存層和微批模式大幅減少窗口累積器對狀態的訪問頻次，優化效果顯著。然而，在實際應用中，我們發現窗口觸發器（Trigger） 也會頻繁訪問狀態後端，帶來額外的性能開銷。

在實際業務場景中，特徵累積的窗口劃分通常較細粒度，例如基於ip、query、uid進行 keyBy，且隨着業務接入的線索和特徵增多，key的數量變多，計算壓力進一步加大。這導致兩個主要問題：

• Key 數量激增，觸發頻繁訪問狀態：keyBy 後的Key量級極大，每個 Key 維護獨立的Trigger，這些Trigger需要不斷訪問狀態後端進行觸發註冊，造成高頻狀態交互，影響吞吐。
• 窗口清理（clear）導致計算壓力驟增：當水位（watermark）推進到窗口末端時，大量Key需要同時觸發Clear操作，瞬時狀態訪問量暴增，可能導致作業卡頓甚至崩潰，特別是在窗口長度較長、窗口內Key數量龐大的情況下。

針對上述問題，我們探索了更高效的Trigger機制，以降低狀態訪問開銷，提高作業穩定性。

第一，減少 Trigger 數量：

舉個例子，我們基於UID進行特徵聚合，如果我們在對特徵數據執行keyBy操作時，直接按照最細粒度的UID維度進行分區處理。那麼每個唯一的key都會綁定一個觸發器（trigger），而觸發器的數量直接影響狀態訪問的頻次和資源佔用。

為了解決這個問題，我們採用了按UID進行取模分區的方式（例如按uid%100 進行keyBy分區）。這種方式顯著減少了觸發器的數量，從而降低了狀態存儲和訪問的開銷。同時我們定製了聚合函數，保證每個分區內進行聚合計算的時候還是會按照原本的UID作為key進行特徵累積，保證特徵累積的準確性。

第二，狀態放入內存：

進一步優化時，我們發現，當按照固定數量（如100個分區）取模後，key的數量和值是確定且有限的。基於此特性，我們將觸發器的狀態從Flink的狀態後端遷移到內存中管理，這樣能夠進一步提升性能，避免頻繁訪問狀態存儲帶來的開銷。

有人可能擔心：觸發器狀態遷移到內存後，作業一旦發生重啓，內存中的數據會丟失，這可能導致窗口數據無法正常觸發。例如，若按UID進行keyBy計算，某個UID僅有一條數據，且此時作業重啓導致其觸發器狀態丟失，那麼作業恢復後這條數據永遠可能無法下發。

但通過固定分區取模（如按 %100 分區）後，我們有效解決了這個問題：

• 取模分區的 key 數量是有限的（如 100 個），並且這樣能保證每個分區會持續接收到新的數據。
• 當作業重啓時，新數據的到來會自動重新註冊觸發時間，即便原有內存狀態丟失，後續的數據流動能夠重新觸發正常的處理邏輯。因此，即使觸發器狀態短暫丟失，取模後的分區會很快自愈，確保數據下發的正確性和完整性。

上圖最左邊-原始設計，數據流按照 uid 進行 keyBy 分組，每個 uid 都對應一個獨立的 trigger。每個trigger需要與狀態後端 (StateBackend) 頻繁交互，包括保存和更新狀態。存在問題是：狀態後端需要頻繁訪問，尤其在高併發場景下，性能瓶頸明顯。每個 uid 都維持一個獨立的窗口觸發器，資源消耗較高。

上圖中間-第一版優化，將原始 uid 進行取模操作 (uid % 100)，將原本細粒度的分組合併為粗粒度的分組。即多個 uid 合併到同一個分組中，減少了窗口觸發器的數量。狀態後端的訪問頻率有所減少，降低資源消耗，提升了整體吞吐量。

上圖右邊-第二版優化，內存的引入，每個trigger相關的信息存儲於內存中，而不是直接與狀態後端交互。大幅減少狀態後端的訪問次數。提升了系統性能，確保作業穩定運行。

綜上，在 Flink 反作弊系統的窗口特徵累積優化中，我們針對高吞吐、低延遲、抗亂序等業務需求，進行了多項改進。

1.提升時效性：反作弊策略依賴實時特徵，默認窗口觸發方式無法滿足業務需求。因此，我們採用提前觸發機制，基於事件時間間隔觸發計算，使特徵聚合結果能夠秒級或分鐘級輸出，避免長窗口帶來的數據滯後問題。

2.優化性能瓶頸：在高併發場景下，特徵計算涉及海量狀態存儲訪問，容易導致RocksDB負載過高，影響作業穩定性。我們引入批量更新、內存緩存 、trigger優化、分區縮減等方式，大幅提升吞吐量。

綜合優化後，該方案使 Flink 反作弊系統具備更快的特徵計算能力、更高的吞吐性能，有效支撐高併發業務場景下的實時風控需求。

3.3 配置化

為了滿足反作弊策略的高頻上線和模擬過濾等需求，我們的實時系統實現了高度配置化。並且配置文件全部託管到風控平台。通過配置化驅動的架構，無論是字段抽取、特徵加工、策略規則定義和數倉產出，均可以通過簡單的配置操作快速完成，極大地縮短了開發週期，同時降低了對底層框架代碼開發的依賴。只需要在風控平台上編輯好策略，就可以一鍵分發並啓動對應的測試或線上作業。

如上圖所示，相關配置文件可以分為兩類分別是工程配置（綠色）和策略配置（黃色），策略配置主要用於定義業務過濾規則和邏輯，工程配置側重於系統的底層運行，比如輸入輸出、並行度等配置。並且部分配置文件為非必需項，這意味着如果某個計算模塊不需要使用，則相應的配置文件可以省略。

3.3.1 工程配置

工程配置是管理流式作業運行的系統層面參數。針對反作弊場景的實時流式任務，與 Flink CDC YAML的設計思路類似，也是通過 YAML 文件對通用工程配置進行抽象和統一管理，確保流式作業能夠靈活適配多種業務場景。

為了保證一個 Flink 流式作業的正常運行，完整的工程配置需要包含以下幾個關鍵部分：輸入配置、輸出配置、併發配置。

• 輸入配置：決定了 Flink 作業如何接收和解析源數據，定義數據源類型（如Kafka、HDFS）、連接參數、消費策略等。
• 輸出配置：定義了 Flink 作業的計算結果如何存儲或傳輸到下游系統，指定結果存儲方式（如ClickHouse表、Redis集羣、Kafka Topic）。
• 併發配置：直接影響 Flink 作業的性能、吞吐量以及資源使用情況，設置算子並行度、檢查點間隔等，優化作業性能。

3.3.2 策略配置

策略配置是指將反作弊攔截策略的核心邏輯規範化，以配置文件的形式靈活定義和管理。通過策略配置化設計，能夠快速調整或部署反作弊策略，無需修改底層代碼。

策略的配置主要由字段抽取配置、特徵配置、詞表配置、模型配置和規則配置等組成。

字段抽取配置：字段是反作弊策略和數倉的最基礎的信息，根據抽取方式不同分為：

• 基礎字段：直接從原始數據流中提取的字段，例如設備 ID、用户 ID 等。
• 二次計算字段：通過基礎字段計算生成的派生字段，設備ID是否合法，UID是否為歷史黑用户等。
• 外部服務字段：通過調用外部服務接口動態獲取的字段，例如 IP 地址歸屬地、安全風控標籤等。
• 維表字段：通過查詢詞表映射關係獲得的字段，例如黑名單匹配結果、分類標籤等。

我們將字段抽取邏輯進行了配置化抽象，策略開發人員使用類似於寫sql的方式即可完成簡單字段的etl邏輯的開發，如常見的json字段抽取，字符串處理，反作弊內部的常用UDF等，配置能覆蓋大部分字段抽取，對於複雜的字段抽取邏輯仍舊使用Flink的Datastream API開發實現。

特徵配置：特徵是策略的重要判定依據，特徵配置包括以下幾個關鍵方面：

• 特徵類型：數據的聚合方式，如sum、count、distinct等。
• 窗口信息：設置聚合特徵的時間窗口範圍和窗口形式，時間範圍如：1 分鐘、1 小時等，窗口形式如：滑動窗口、滾動窗口等。
• 特徵維度：特徵的聚合維度，如用户、設備、IP 地址等。

詞表配置：詞表通常是離線挖掘得到的黑名單、字段映射（如ip映射城市）等固定維表信息，配置內容需包括以下幾個方面：

• 詞表路徑：指定詞表的存儲位置，支持文件路徑或分佈式存儲地址。
• 詞表類型：支持多種形式的詞表，包括集合（set）、鍵值對映射（kv）、正則表達式（regex）等。

模型配置：通過模型實現複雜的行為預測和風險判定，關鍵配置內容包括：

• 模型路徑：指定模型的存儲位置，支持本地或遠程加載。
• 模型類型：支持多種模型形式，例如線性迴歸、GBDT等，目前模型的加載是通過PMML框架實現的。
• 模型輸入輸出：明確模型所需的輸入字段和輸出字段等。

規則配置：規則配置決定了作弊行為的最終判定規則和處置方式：

• 策略判定閾值：定義觸發策略的條件，例如基礎字段匹配、詞表匹配、風險評分的閾值、特徵累積閾值、模型打分閾值等。
• 策略判黑等級：設定風險等級，區分低、中、高風險及對應的處置措施。

如下圖所示，規則配置能夠獲取所有字段信息，並基於這些信息進行最後的策略判定。

這張圖展示了反作弊規則的判定流程：

1.輸入數據：每條PV包含多個字段，包括基礎字段（如IP、手機號、UID等）、外部抽取字段（如IP歸屬地、是否異常等）、計算得到的特徵（如統計特徵fea1、fea2等）以及模型得分（多個模型計算的分值）。

2.策略判定：系統基於預設的反作弊規則，對各字段、特徵、模型分數進行綜合評估。例如，規則1要求【fea1 > 100 && model2 > 0.95】，規則2要求 【IP like '192.%' && fea2 > 100 && model1 > 0.65】。多個規則都會執行判定邏輯，判斷是否命中。

3.結果輸出：最終的PV數據會帶上反作弊命中結果。例如，在示例中，該PV數據命中了規則2，表明該行為可能存在風險。

以上就是策略配置的所有介紹，通過配置化管理字段、特徵、詞表、模型和規則，反作弊系統能夠快速響應業務需求，靈活調整檢測邏輯。同時，配置化設計大幅降低了開發部署成本，提高了策略迭代效率。

3.4 模擬過濾的實現

通過配置化的支持，可以方便地切換數據輸入和輸出，所以僅需調整測試配置文件，即可啓動模擬過濾作業，提升測試效率。同樣的模擬過濾功能也接入了風控平台，開發者可以直接一鍵調啓模擬過濾任務。

對於直接接入實時消息隊列進行模擬過濾，基本無需修改輸入配置，然而，基於實時消息隊列的模擬過濾存在一定侷限性，首先運行耗時較長，需要1:1的時間來進行測試。如過濾24小時數據需24小時，難以快速驗證策略長期效果，其次消息隊列僅保存最近幾天的數據，歷史數據回溯能力有限。一般僅適用於簡單工程測試和策略模擬過濾。

為此，我們擴展了 Flink 的 HDFS Source 組件，支持直接讀取HDFS上的 Parquet 文件進行模擬過濾。在讀取 Parquet 文件時，因為是流式計算，主要挑戰在於數據順序問題，為確保數據時序一致性，我們採取了以下優化策略：

• 文件級別排序：在讀取數據時，按照文件路徑和名稱進行排序，確保數據按時間順序加載。
• 順序讀取文件：嚴格按照排序後的順序依次讀取 Parquet 文件，避免亂序問題，保證數據的時序性。

通過這一優化方案，我們在策略模擬過濾中與線上對比測試，準確率達到 99% 左右，大幅提升了模擬過濾的可靠性和一致性。

除了Source組件適配了讀取離線數據外，其他組件跟線上完全一致，這樣就保證了模擬過濾的準確性。極端場景下（如線上作業出錯需重新回溯數據），可通過此方式對離線數據再次模擬流式過濾，實現數據修正。

3.5 便捷的數據分析

在實時反作弊系統中，數據分析不僅是風控團隊優化策略的核心工具，也是業務方監控風險、評估影響的重要支撐。為了滿足不同角色的分析需求，系統提供了離線和實時的數倉產出，幫助進行便捷的數據分析。

上圖展示了我們的數倉方案，其中 Flink 負責實時數據流的計算和處理，最終將數據分別存儲到 HDFS（Parquet 格式） 和 ClickHouse。

• 離線Hive表：Flink 將數據以 Parquet 格式 存儲到 HDFS，支持按刻鐘或小時級別分區產出數據，並掛載到圖靈表中，便於後續使用 Hive、Spark 進行批量計算和查詢。也可以作為後續回溯和測試模擬過濾的直接輸入。
• 實時ClickHouse表：支持實時數據產出，用於高性能的 OLAP 分析，可用於快速分析策略上線效果、構建實時看板以及告警監控等場景。

這種架構能夠同時滿足 實時查詢 和 離線存儲分析 需求，實現高效的數據流式處理與存儲。

高效便捷的數據分析主要滿足瞭如下需求：

• 實時監控與告警：業務方需實時瞭解反作弊策略的執行效果（如攔截量趨勢、高風險用户分佈）。
• 基於 ClickHouse 的秒級查詢能力，支持實時生成監控看板（如“近1小時攔截量TOP 10 IP”）。
• 配置告警規則（如“攔截量突增50%”），通過郵件或消息推送及時通知相關人員。
• 自助分析與可視化：業務方能夠靈活分析作弊行為特徵（如羊毛黨設備型號分佈、異常行為時間規律）。
• 接入 TDA自助分析平台，支持 SQL 查詢與拖拽式可視化分析，無需依賴數據團隊。預置常用分析儀表盤，降低使用門檻。
• 離線挖掘與模型優化：數據同學能夠於歷史數據挖掘作弊模式，優化策略規則與機器學習模型。
• 將全量數據存儲至 Hive，支持 Spark、Flink 等分佈式計算引擎進行進一步的複雜分析。

通過便捷的數據分析能力，系統不僅提升了風控策略的迭代效率，還賦能業務方自主探索數據價值，實現從“被動響應”到“主動洞察”的轉變。

04 總結

本文介紹了基於 Flink 的實時反作弊流式過濾系統，圍繞架構設計、挑戰應對及優化方案展開。通過特徵計算和配置化管理，提升了系統的檢測效率和穩定性。實踐表明，該方案在提升數據處理時效性與反作弊效果方面均取得顯著成效。未來，將進一步優化策略檢測機制，提升檢測精準度，並探索更智能的風險識別手段。

------END-----

推薦閲讀

百度智能雲xDeepSeek，最具性價比的DeepSeek一體機合集來了！

圖引擎在智能體開發場景的應用實踐

直播間互動框架性能優化與穩定性實踐

百度網盤防雪崩架構實踐

如何在百度百舸部署滿血版DeepSeek-V3、DeepSeek-R1模型