?　最近看了一本書叫《風控要略—互聯網業務反欺詐之路》，這本書主要是講互聯網產品安全防范的，我之前做過一年情報數據分析的工作，當時覺得這方面工作很機密，網絡上幾乎沒什么相關的資料，這本書讓我與之前的工作產生了共鳴，因此還是推薦一下這本書。
?　對于海量數據庫以及實時指標計算，我以前了解過一些大數據技術相關的知識，由于現在工作中涉及較少，因此寫了一篇筆記了解實時指標計算方面的知識。

目錄

• 一、實時指標計算概述
• 二、實時指標計算方案
  • 2.1 基于數據庫SQL的計算方案
  • 2.2 基于事件驅動的計算方案
  • 2.3.基于實時計算框架的計算方案
    • 2.3.1 Storm介紹
    • 2.3.2 Spark Straming介紹
    • 2.3.3 Flink介紹
• 三、實時指標計算實踐
  • 數據拆分
  • 分片計算
  • 引入Flink
  • Lambda架構
• 四、參考文章

一、實時指標計算概述

?　在風控反欺詐業務中，為了實時進行業務事件的風險判斷，要求指標計算延遲非常低，一般在毫秒或幾十毫秒級別。常見的指標類型有下：

?　在反欺詐業務中，為了能及時發現新的黑產行為，以上業務指標計算需要隨時上線，而且時間窗口和計算維度組合均不確定。因此為了滿足反欺詐系統快速響應的需求，就要構建實時的反欺詐指標計算系統，用于支持策略運營人員靈活配置和使用。

二、實時指標計算方案

?　實時指標計算方案常見的實現方法有基于數據庫SQL的計算方案、基于事件驅動的計算方案和基于實時計算框架的計算方案三種。

2.1 基于數據庫SQL的計算方案

?　關系數據庫支持基于SQL語句進行統計計算，這種方式實現簡單，但不夠靈活，響應時間得不到保障。比如計算最近1小時內某ip注冊賬號個數的代碼可以如下：

select count(1) from xxx where ip=‘x.x.x.x’ and gmt_create>now()-1 hour

2.2 基于事件驅動的計算方案

?　注冊、登錄、交易等都是獨立的事件，事件可以轉化成消息進入kafka等消息系統中。比如以最近1小時內某IP注冊賬號個數為例，當注冊事件到達時，可以在數據庫或緩存中構造KV，代碼如下：

112.3.10.6 :[{
“deviceId”:“acefhahefbibv”,
“account”:“jack”
“timestamp”:,1560745934747,
“eventType”:“register”
},{
“deviceId”:“acefhahefbibv”,
“account”:“jim”
“timestamp”:,1560745934747,
“eventType”:“login” },
{
“deviceId”:“acefhahefbibv”,
“account”:“lily”
“timestamp”:,1560745934747,
“eventType”:“register”}]

?　當指標查詢請求來到時，只需要進行一次KV查詢，即可以獲得全部相關數據，然后在內存中進行數據篩選，得出結算結果。
?　當時間跨度較大，數據量較大的情況下，可以采用差分計算的方法。比如，計算最近一小時內注冊的手機號數量，可以預先10分鐘做一次聚合，最后的查詢優化統計為(最近幾分鐘明細+5個10分鐘聚合數據+10分鐘明細數據)。
?　這種計算方式的優點在于可以進行預計算，查詢性能較好。缺點是每一個指標的計算都需要處理消息系統、中間結果存儲系統、業務邏輯，需要針對不同的事件場景進行邏輯開發，且需要每次進行發布，而且需要進行大量的預計算。

2.3.基于實時計算框架的計算方案

?　實時計算框架解決了方法二的痛點，將數據流、中間結果存儲、性能和可靠性交給框架本身解決，它提供易用的不同層次抽象的API，甚至可以通過SQL完成一個計算指標的上線。業界流行的三大實時計算框架：Storm、Spark Streaming和Flink。
先了解兩組基礎概念：

1.實時計算和離線計算
實時計算對延遲要求較高，要求在秒級甚至毫秒級就給出結果。離線計算一般指天級別(T+1)或小時級別(T+H)給出計算結果。
2.批計算和流計算
批計算是按照數據塊進行計算，一般需要累積一定時間或一定的數據量再進行計算，有一定延遲。流計算是針對數據流進行計算，1條數據處理完成后立刻發給后續計算節點，延遲較低。批計算如果時間間隔很短，處理速度很快，也可以稱為某種意義上的準實時計算。

2.3.1 Storm介紹

?　Storm是比較早出現的實時計算框架。主要概念有Spout(產生數據源)、Bolt(消息處理者)、Topology(網絡拓撲)、Tuple(元祖)。
?　Storm提交運行的程序稱為Topology，Topology處理的最小消息單位是一個Tuple，也就是一個任意對象的數組。在Storm中，數據像流水一樣，源源不斷地從一個處理模型完成處理后，快讀流向下一處理模塊。

2.3.2 Spark Straming介紹

?　Spark Streaming是Spark核心API的一個擴展，可以實現高吞吐量、具備容錯機制的實施流數據的處理。它支持從Kafka、Flume、ZeroMQ等多種數據源獲取數據，然后使用map、reduce和join函數進行復雜算法的處理，最后將處理結果存儲到文件系統、數據庫等。
?　Spark Streaming本質上是基于核心Spark Core的，它接受實時流的數據，并根據一定的時間間隔拆分成一批批的數據，通過Spark Engine處理這批數據，整體框架如下：

2.3.3 Flink介紹

?　Flink在數據處理方式上和Storm類似，并沒有采用小批量處理的方式，把所有的任務當成流來處理，是真正的流式系統。此外它也是一個流批一體的計算框架。

?　從本質上說，Storm和Flink是真正意義的流式計算，延遲在毫秒級。Spark Streaming采用微小批的方式進行計算，延遲在秒級，對延遲要求不高的業務場景適用。

三、實時指標計算實踐

?　在某個風控反欺詐業務場景中，需要計算基于設備號主屬性的多個指標如下“

設備在最近5分鐘登錄次數。
設備在最近1小時登錄過的賬戶個數。
設備在最近1天登錄過的賬戶個數。
設備在最近1天使用過的IP個數。
設備在最近1天的GPS位置移動距離。

?　實時指標計算引擎的數據結構如下：

?　當新的業務事件到來時，實時指標計算引擎不斷更新Value數據。然后根據事件驅動的計算方案進行KV查詢，在內存中對篩選過后的數據進行計算。實際操作中，還可以結合數據壓縮、應用緩存、數據截斷等方式提升效率。比如用戶設備最近1天登錄1000次和10000次的風險是沒有區別的，因此可以只存儲最近1000次的數據。

數據拆分

?　為了對實時指標計算引擎進行優化，可以對數據進行拆分計算。比如將設備ID的數據拆分gps、ip、賬戶等維度，實際計算時只需查詢設備ID賬戶維度的數據，不需要返回無用多余的數據。但是這種方式使得數據的復用性較差，導致NoSQL數據庫占用較大的內存和存儲，是一種空間換時間的優化方式。

分片計算

?　對于"頻度-關聯個數統計"類指標，由于需要去重，因此需要業務事件的明細數據。但是對于頻度-出現次數統計類指標，本質上只是個數的計算，因此不需要去重，可以進一步優化，這種方法上面也提及到。

?　當業務事件觸發風控規則時，只需要查詢多個時間分片的數據，進行聚合累加即可。

引入Flink

?　通過代碼配置指定計算任務，將各種復雜業務邏輯都交給Flink框架處理，計算過程完全交給框架實現。以"IP最近1小時登錄次數"為例，對應的Flink示例代碼如下：

Lambda架構

?　在實踐場景中，有些指標需要回溯的時間較長，因此如果全部使用實時指標計算引擎的話，時間窗口很長，對系統的壓力很大。Lmabda架構可以將一個時間跨度較長的實時指標計算轉化為一個"較短時間窗口的實時指標"+"歷史數據的離線指標"的聚合結果。實時指標用Flink做實時流處理，歷史數據用Spark做批處理，Lambda架構分為實時層、批量層以及服務聚合層3層。

四、參考文章

《風控要略 互聯網業務反欺詐之路》

【作者】：Labryant
【原創公眾號】：風控獵人
【簡介】：某創業公司策略分析師，積極上進，努力提升。乾坤未定，你我都是黑馬。
【轉載說明】：轉載請說明出處，謝謝合作！~

總結

以上是生活随笔為你收集整理的海量数据的实时指标计算的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。