干貨 | 攜程新風控數據平臺建設

---

作者：劉丹青

前言

 近幾年，隨著電商和互聯網金融的發展，各大互聯網企業也在逐步加強風控體系的建設，為公司的運營保駕護航。在攜程，各BU經常受到惡意注冊、登錄、惡意刷單、掃號等行為，所以建設了一套數據平臺，希望能夠從數據中挖掘出有用的信息，不僅可以為風控系統提供數據支持，還可以為其他服務提供支撐。

 本文主要從架構和業務的角度介紹下攜程信息安全團隊的數據平臺建設之路，以及如何為業務和風控提供支持的。

一、數據平臺1.0的特點

1.0數據平臺架構圖

 為了快速支持風控平臺，在早期建設數據平臺的時候，我們直接通過RabbitMQ收集業務數據，再使用數據引擎對數據做清洗、計算，再存儲在MySQL中，把數據處理以sql的形式寫入到代碼中，通過高頻的定時任務對數據做聚合統計。

 在剛開始運行時，數據量和業務量都比較小，惡意攻擊的手段也比較簡單，所以數據統計還是比較快速及時的，滿足我們大多數的需求。

隨著業務量的爆炸式增長，數據處理的復雜度提升，我們不得不面對幾個問題：

• 數據來源單一，并強依賴RabbitMQ；數據量過大時，data engine無法快速的處理完數據，導致MQ中堆積的數據越來越多，最終導致服務器內存崩潰
• 做數據處理的sql語句都是寫在代碼里，通過quartz去調度定時任務，這樣每當需要更新數據處理邏輯時，不得不重新發布代碼

二、數據平臺2.0的改進

 基于這兩個痛點，無法提供穩定的數據服務，甚至影響了賬戶風控平臺的業務，所以為了解決這些問題，提供穩定可靠的服務，我們重新設計了數據平臺2.0，解決以上痛點，并從下面三個方面考慮，解決以上痛點：

• 數據采集與整合
• 數據的實時計算與離線計算
• 任務調度與熱更新

數據平臺架構圖

那么接下來就談談我們具體是怎么去解決這些問題的。

1、數據來源

 原來我們只能被動的接收風控平臺傳過來的數據，數據樣本過于單一；在新版本中，需要收集更多的數據，比如業務日志、行為日志、http日志等；這些數據源位于各BU的存儲上，通過Kafka或者MQ流式的將這些數據拉取過來后，又由于數據格式各異，通過數據平臺創建數據模型，并保存到HDFS存儲上。

 在風控的場景中，我們需要判斷每一個請求是否是惡意攻擊，與此同時，又不能影響普通用戶的正常體驗，那么我們需要對所以的請求數據進行計算，并實時的給出響應，這個時間一般都是秒級范圍。

2、流式計算與實時計算

實時統計流程圖

 所以在這塊我們做了兩塊計算，首先是用流式計算對數據做實時統計，通過Storm去消費Kafka/MQ的數據，并分發各種數據統計規則到bolt里，對數據做個初步計算，再使用count server對數據進行分片，同時進行數據流的繼續處理。

 通過count server得到的分片數據和最終的數據都會緩存起來，可以為接下來的實時計算提供部分的數據支持。在這里，由于數據是通過Kafka或者MQ傳過來，有時候可能出現數據堆積的情況，導致無法進行實時統計，所以在這還做了一個請求-統計的超時監控，這可以幫助我們及時處理數據流問題。

 接下來是實時計算，由于實時計算的性能要求很高，所以當用戶的請求過來時，在流式計算結果的基礎上做增量運算，最終達到一個實時的效果；這個結果也會存到redis中并定期做持久化，可以作為下一次請求的參數，也方便后續的離線計算。

這里大概介紹下count server，這個服務可以滿足我們對于數據預熱、分片存儲的需求。

 先舉個例子：我們需要計算一個IP在10分鐘內的訪問次數，原來的做法就是通過索引日志或者直接去DB中查詢10分鐘內的數據，但是這樣的效率還是比較低下的；我們通過count server把每個請求分別存儲在一個時間槽里，當我們需要按照時間去統計的時候，直接獲取所有槽里的數據，并直接相加就能得到結果。所以這就可以看出來，count server其實就是按照各種維度，對數據進行分片存儲。

3、離線計算

 在離線計算這塊，我們使用了十分流行的解決方案，Hadoop+Spark。隨著數據的增長，MapReduce和Spark任務的數量也逐漸的增加，并將計算結果按照不同的應用類型分別保存到MySQL、Redis、Hbase、ES上。

4、任務調度與熱更新

 為了方便任務的調度與熱更新，我們把任務拆解成任務單元和動態規則；在數據平臺中，分別創建任務單元和規則，通過zookeeper將規則打包成規則集推送到不同的任務單元上，實現自動調度與熱更新；這樣即使規則出現問題，也不需要重新部署整個任務，只需要修改規則并重新推送規則集即可。

 同時為了更好的檢查任務的正確性，還新增了測試單元，在測試單元中創建測試用例、設置入參與預期結果，然后注入到任務單元中即可完成測試，這樣可以極大的提高任務的上線與更新效率。

5、效果

 伴隨著新平臺的上線，每天處理的數據達到近30億，相較于原來的1.0版本，實現了近30倍的提升；而且攔截了大量的惡意攻擊請求；并且整個平臺的服務化之后，很大程度上減少了開發人員的參與。

三、尾聲

 在建設數據平臺的過程中，首先是考慮對業務的支持，脫離了業務空談數據是沒有意義的，在對老業務提供支持的同時，積累經驗，收集需求，為新業務提供快速的支撐；其次是平臺的擴展，隨著業務的發展，數據量和數據分析也會要求的越來越多，數據平臺不僅要可以快速的橫向擴展，還能在原有的數據鏈路上方便快捷的插入新的操作與功能。

 畢竟數據平臺的建設與運營并非一朝一夕的工作，也不是一個通過堆砌各種框架組件而成的應用，而是根據自身的需求，合理的制定計劃、設計架構，最終達到一個成本和收益的平衡。

本文轉載自：36大數據