干貨 | 攜程新風(fēng)控?cái)?shù)據(jù)平臺(tái)建設(shè)

---

作者：劉丹青

前言

 近幾年，隨著電商和互聯(lián)網(wǎng)金融的發(fā)展，各大互聯(lián)網(wǎng)企業(yè)也在逐步加強(qiáng)風(fēng)控體系的建設(shè)，為公司的運(yùn)營(yíng)保駕護(hù)航。在攜程，各BU經(jīng)常受到惡意注冊(cè)、登錄、惡意刷單、掃號(hào)等行為，所以建設(shè)了一套數(shù)據(jù)平臺(tái)，希望能夠從數(shù)據(jù)中挖掘出有用的信息，不僅可以為風(fēng)控系統(tǒng)提供數(shù)據(jù)支持，還可以為其他服務(wù)提供支撐。

 本文主要從架構(gòu)和業(yè)務(wù)的角度介紹下攜程信息安全團(tuán)隊(duì)的數(shù)據(jù)平臺(tái)建設(shè)之路，以及如何為業(yè)務(wù)和風(fēng)控提供支持的。

一、數(shù)據(jù)平臺(tái)1.0的特點(diǎn)

1.0數(shù)據(jù)平臺(tái)架構(gòu)圖

 為了快速支持風(fēng)控平臺(tái)，在早期建設(shè)數(shù)據(jù)平臺(tái)的時(shí)候，我們直接通過RabbitMQ收集業(yè)務(wù)數(shù)據(jù)，再使用數(shù)據(jù)引擎對(duì)數(shù)據(jù)做清洗、計(jì)算，再存儲(chǔ)在MySQL中，把數(shù)據(jù)處理以sql的形式寫入到代碼中，通過高頻的定時(shí)任務(wù)對(duì)數(shù)據(jù)做聚合統(tǒng)計(jì)。

 在剛開始運(yùn)行時(shí)，數(shù)據(jù)量和業(yè)務(wù)量都比較小，惡意攻擊的手段也比較簡(jiǎn)單，所以數(shù)據(jù)統(tǒng)計(jì)還是比較快速及時(shí)的，滿足我們大多數(shù)的需求。

隨著業(yè)務(wù)量的爆炸式增長(zhǎng)，數(shù)據(jù)處理的復(fù)雜度提升，我們不得不面對(duì)幾個(gè)問題：

• 數(shù)據(jù)來(lái)源單一，并強(qiáng)依賴RabbitMQ；數(shù)據(jù)量過大時(shí)，data engine無(wú)法快速的處理完數(shù)據(jù)，導(dǎo)致MQ中堆積的數(shù)據(jù)越來(lái)越多，最終導(dǎo)致服務(wù)器內(nèi)存崩潰
• 做數(shù)據(jù)處理的sql語(yǔ)句都是寫在代碼里，通過quartz去調(diào)度定時(shí)任務(wù)，這樣每當(dāng)需要更新數(shù)據(jù)處理邏輯時(shí)，不得不重新發(fā)布代碼

二、數(shù)據(jù)平臺(tái)2.0的改進(jìn)

 基于這兩個(gè)痛點(diǎn)，無(wú)法提供穩(wěn)定的數(shù)據(jù)服務(wù)，甚至影響了賬戶風(fēng)控平臺(tái)的業(yè)務(wù)，所以為了解決這些問題，提供穩(wěn)定可靠的服務(wù)，我們重新設(shè)計(jì)了數(shù)據(jù)平臺(tái)2.0，解決以上痛點(diǎn)，并從下面三個(gè)方面考慮，解決以上痛點(diǎn)：

• 數(shù)據(jù)采集與整合
• 數(shù)據(jù)的實(shí)時(shí)計(jì)算與離線計(jì)算
• 任務(wù)調(diào)度與熱更新

數(shù)據(jù)平臺(tái)架構(gòu)圖

那么接下來(lái)就談?wù)勎覀兙唧w是怎么去解決這些問題的。

1、數(shù)據(jù)來(lái)源

 原來(lái)我們只能被動(dòng)的接收風(fēng)控平臺(tái)傳過來(lái)的數(shù)據(jù)，數(shù)據(jù)樣本過于單一；在新版本中，需要收集更多的數(shù)據(jù)，比如業(yè)務(wù)日志、行為日志、http日志等；這些數(shù)據(jù)源位于各BU的存儲(chǔ)上，通過Kafka或者M(jìn)Q流式的將這些數(shù)據(jù)拉取過來(lái)后，又由于數(shù)據(jù)格式各異，通過數(shù)據(jù)平臺(tái)創(chuàng)建數(shù)據(jù)模型，并保存到HDFS存儲(chǔ)上。

 在風(fēng)控的場(chǎng)景中，我們需要判斷每一個(gè)請(qǐng)求是否是惡意攻擊，與此同時(shí)，又不能影響普通用戶的正常體驗(yàn)，那么我們需要對(duì)所以的請(qǐng)求數(shù)據(jù)進(jìn)行計(jì)算，并實(shí)時(shí)的給出響應(yīng)，這個(gè)時(shí)間一般都是秒級(jí)范圍。

2、流式計(jì)算與實(shí)時(shí)計(jì)算

實(shí)時(shí)統(tǒng)計(jì)流程圖

 所以在這塊我們做了兩塊計(jì)算，首先是用流式計(jì)算對(duì)數(shù)據(jù)做實(shí)時(shí)統(tǒng)計(jì)，通過Storm去消費(fèi)Kafka/MQ的數(shù)據(jù)，并分發(fā)各種數(shù)據(jù)統(tǒng)計(jì)規(guī)則到bolt里，對(duì)數(shù)據(jù)做個(gè)初步計(jì)算，再使用count server對(duì)數(shù)據(jù)進(jìn)行分片，同時(shí)進(jìn)行數(shù)據(jù)流的繼續(xù)處理。

 通過count server得到的分片數(shù)據(jù)和最終的數(shù)據(jù)都會(huì)緩存起來(lái)，可以為接下來(lái)的實(shí)時(shí)計(jì)算提供部分的數(shù)據(jù)支持。在這里，由于數(shù)據(jù)是通過Kafka或者M(jìn)Q傳過來(lái)，有時(shí)候可能出現(xiàn)數(shù)據(jù)堆積的情況，導(dǎo)致無(wú)法進(jìn)行實(shí)時(shí)統(tǒng)計(jì)，所以在這還做了一個(gè)請(qǐng)求-統(tǒng)計(jì)的超時(shí)監(jiān)控，這可以幫助我們及時(shí)處理數(shù)據(jù)流問題。

 接下來(lái)是實(shí)時(shí)計(jì)算，由于實(shí)時(shí)計(jì)算的性能要求很高，所以當(dāng)用戶的請(qǐng)求過來(lái)時(shí)，在流式計(jì)算結(jié)果的基礎(chǔ)上做增量運(yùn)算，最終達(dá)到一個(gè)實(shí)時(shí)的效果；這個(gè)結(jié)果也會(huì)存到redis中并定期做持久化，可以作為下一次請(qǐng)求的參數(shù)，也方便后續(xù)的離線計(jì)算。

這里大概介紹下count server，這個(gè)服務(wù)可以滿足我們對(duì)于數(shù)據(jù)預(yù)熱、分片存儲(chǔ)的需求。

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

3、離線計(jì)算

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

4、任務(wù)調(diào)度與熱更新

 為了方便任務(wù)的調(diào)度與熱更新，我們把任務(wù)拆解成任務(wù)單元和動(dòng)態(tài)規(guī)則；在數(shù)據(jù)平臺(tái)中，分別創(chuàng)建任務(wù)單元和規(guī)則，通過zookeeper將規(guī)則打包成規(guī)則集推送到不同的任務(wù)單元上，實(shí)現(xiàn)自動(dòng)調(diào)度與熱更新；這樣即使規(guī)則出現(xiàn)問題，也不需要重新部署整個(gè)任務(wù)，只需要修改規(guī)則并重新推送規(guī)則集即可。

 同時(shí)為了更好的檢查任務(wù)的正確性，還新增了測(cè)試單元，在測(cè)試單元中創(chuàng)建測(cè)試用例、設(shè)置入?yún)⑴c預(yù)期結(jié)果，然后注入到任務(wù)單元中即可完成測(cè)試，這樣可以極大的提高任務(wù)的上線與更新效率。

5、效果

 伴隨著新平臺(tái)的上線，每天處理的數(shù)據(jù)達(dá)到近30億，相較于原來(lái)的1.0版本，實(shí)現(xiàn)了近30倍的提升；而且攔截了大量的惡意攻擊請(qǐng)求；并且整個(gè)平臺(tái)的服務(wù)化之后，很大程度上減少了開發(fā)人員的參與。

三、尾聲

 在建設(shè)數(shù)據(jù)平臺(tái)的過程中，首先是考慮對(duì)業(yè)務(wù)的支持，脫離了業(yè)務(wù)空談數(shù)據(jù)是沒有意義的，在對(duì)老業(yè)務(wù)提供支持的同時(shí)，積累經(jīng)驗(yàn)，收集需求，為新業(yè)務(wù)提供快速的支撐；其次是平臺(tái)的擴(kuò)展，隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量和數(shù)據(jù)分析也會(huì)要求的越來(lái)越多，數(shù)據(jù)平臺(tái)不僅要可以快速的橫向擴(kuò)展，還能在原有的數(shù)據(jù)鏈路上方便快捷的插入新的操作與功能。

 畢竟數(shù)據(jù)平臺(tái)的建設(shè)與運(yùn)營(yíng)并非一朝一夕的工作，也不是一個(gè)通過堆砌各種框架組件而成的應(yīng)用，而是根據(jù)自身的需求，合理的制定計(jì)劃、設(shè)計(jì)架構(gòu)，最終達(dá)到一個(gè)成本和收益的平衡。

本文轉(zhuǎn)載自：36大數(shù)據(jù)