大數(shù)據(jù)反欺詐技術(shù)架構(gòu)

一年多以前，有朋友讓我聊一下你們的大數(shù)據(jù)反欺詐架構(gòu)是怎么實現(xiàn)的，以及我們途中踩了哪些坑，怎么做到從30min延遲優(yōu)化到1s內(nèi)完成實時反欺詐。當時呢第一是覺得不合適，第二也是覺得場景比較局限沒什么分享的必要性。

時間也過了很久了，最近看到圈里一些東西，發(fā)現(xiàn)當時的這套架構(gòu)并未落伍，依然具有很大的參考價值，所以今天跟大伙聊聊關(guān)于大數(shù)據(jù)反欺詐體系怎么搭建，主要來源是來自于我工作的時候的實踐，以及跟行業(yè)里的很多大佬交流的實踐，算是集小成的一個比較好的實踐。

這套架構(gòu)我做的時候主要領(lǐng)域是信貸行業(yè)的大數(shù)據(jù)反欺詐，后來也看過電商的架構(gòu)，也看過金融大數(shù)據(jù)的架構(gòu)，發(fā)現(xiàn)其實大家使用的其實也差不多是這個套路，只是在各個環(huán)節(jié)都有不同的細節(jié)。

大佬說的，能用圖的，盡量不要打字，那我就打少點字，多做點圖。其實大數(shù)據(jù)不外乎這么幾個步驟。數(shù)據(jù)源開拓、數(shù)據(jù)抽取、數(shù)據(jù)存儲、數(shù)據(jù)清洗和處理、數(shù)據(jù)應用，且聽我一個一個說。

數(shù)據(jù)源

數(shù)據(jù)源是一個比較重要的點，畢竟如果連數(shù)據(jù)源都是垃圾，那么毫無疑問可以預見，最終產(chǎn)出的一定是垃圾，所以挑選數(shù)據(jù)源和對接數(shù)據(jù)源的時候都要關(guān)注，該機構(gòu)產(chǎn)出的數(shù)據(jù)是不是都是質(zhì)量比較高的數(shù)據(jù)。

比如人行征信數(shù)據(jù)就是一個質(zhì)量非常非常高的數(shù)據(jù)，主要涉及信用卡、銀行流水、老賴、失信、強制執(zhí)行信息等，都非常核心，任何一個點都可能是一筆壞賬的苗頭。以及各種行政機構(gòu)提供的付費機密數(shù)據(jù)。

比如運營商通訊數(shù)據(jù)、比如大型電商的行為數(shù)據(jù)、比如各種保險數(shù)據(jù)，以及各個機構(gòu)貸款記錄的互相溝通，這些數(shù)據(jù)源，都非常核心也都非常值錢，是現(xiàn)在反欺詐非常核心的數(shù)據(jù)。

當然也有更加粗暴更加高效的做法，就是直接購買外部的黑名單數(shù)據(jù)，這讓反欺詐變得更加簡單，遇到就直接拒，可以減少非常的人力物力成本去做其他的核查。

數(shù)據(jù)抽取

有了高質(zhì)量的數(shù)據(jù)源后，當然就是怎么抽取的問題了，各個機構(gòu)所提供的數(shù)據(jù)格式是多種多樣的，其中包括 http 接口的json、xml，內(nèi)部其他數(shù)據(jù)源的 etl、定時人工上報的 Excel，以及 sqoop+ozzie 這兩個直接數(shù)據(jù)抽取通道，這個過程只需要保證通道穩(wěn)定，數(shù)據(jù)服務冪等即可，沒什么特殊的地方。

數(shù)據(jù)存儲

數(shù)據(jù)存儲其實就是建立一個數(shù)據(jù)倉庫和一個實時倉庫，數(shù)據(jù)倉庫用于存儲來自各大數(shù)據(jù)源的原始數(shù)據(jù)，實時倉庫用于業(yè)務系統(tǒng)的核心作業(yè)，數(shù)據(jù)倉庫的數(shù)據(jù)量一般都以 T 為單位，實時倉庫以 M 和 G 為單位。

離線計算&實時計算

數(shù)據(jù)保證了，那么計算就是這套架構(gòu)的核心之處，從大的角度來看可以分成離線計算和實時計算。

離線計算主要會做兩件事情。Hive 、Spark 數(shù)據(jù)整合與清洗和離線數(shù)據(jù)建模。Hive 數(shù)據(jù)整合主要做的事情就是把各個數(shù)據(jù)庫里面的東西，進行清洗和過濾，最終寫到我們定義的標準表里邊，提供給下游的計算使用。如果是非常復雜的數(shù)據(jù)清洗，我們會使用 Spark 寫程序來做，畢竟有一些操作不是 Hive 這種標準 SQL 能解決的。離線數(shù)據(jù)建模，就是對于這批數(shù)據(jù)進行建模，以便后續(xù)用于實時計算和應用中，算法嘛，精通兩個基本就穩(wěn)了，LogisticRegression & 決策樹，不要問我為什么。

實時計算又會做些什么事情？SparkStreaming和Flink用于實時流計算，主要是用于一些統(tǒng)計類的事情，以及多個數(shù)據(jù)流的 join 操作。在這里我們希望做到什么事情呢？就是希望服務可以準實時，什么叫準實時呢？就是在一個可以接受的范圍內(nèi)，我允許你有一定的延遲，這塊我們一開始的任務延遲是 30 min。

我們踩過哪些坑呢？

一開始我們希望使用流批次計算來實現(xiàn)實時計算，實踐下來準實時跟實時還是區(qū)別很大的，一個業(yè)務通常是允許不了分鐘級別的延遲的，然而 Spark 的 GraphX 必然有分鐘級別的延遲，只適合離線計算。

Hive + Ozzie 處理離線批量處理是一個非常大的利器，很多人都以為Hive數(shù)據(jù)清洗不就寫寫幾行 SQL？幾百張乃至幾千張表背后的復雜的數(shù)據(jù)清洗規(guī)則，任務依賴，任務重跑，數(shù)據(jù)質(zhì)量，數(shù)據(jù)血緣關(guān)系維護。相信我，要是沒有細心和工具，這些能把你搞崩潰。

ElasticSearch 集群多個機器的負載吞吐量，比單臺機器高性能的要高，畢竟網(wǎng)絡(luò)卡在那。

我們趟了很多的坑，摸了很多的時候，最終決定把所有的實時操作都架構(gòu)在 ElasticSearch 和 Neo4j 上，因為我們不僅僅需要實時的全文本全字段社交關(guān)系生成，更是需要實時搜索多維度多層社交關(guān)系并反欺詐分析，而這個關(guān)系可能是百萬級別的，根據(jù)六度理論，決定了我們選取的層次不能太多，所以最終我們只抽取其中三層社交關(guān)系。最終確定這個架構(gòu)，這很核心地確定了我們的響應時間，并最終決定了我們服務的可用性。

很多地方產(chǎn)生的結(jié)果數(shù)據(jù)只是整個決策鏈上的一個細節(jié)，所以我們還需要 Drools 這類規(guī)則引擎幫助做一個最終決策。

業(yè)務應用

最終業(yè)務系統(tǒng)應該怎么使用，怎么對外提供服務？這也是一個非常核心的問題，因為這部分要求非常非常穩(wěn)定，以及非常非常高效，一般來說不允許有太高的延遲，同時還要求非常高的并發(fā)量。這就要求了我們第一要盡量提高計算效率，第二要求我們對于系統(tǒng)的架構(gòu)要有非常高的保障。

計算效率要高效，有什么技巧呢，保證各個系統(tǒng)之間的交互都是聚合、加工、計算后的結(jié)果，而不是原始數(shù)據(jù)，畢竟網(wǎng)絡(luò)傳輸是需要很高成本的在目標數(shù)據(jù)量非常大的場景下。比如一次性要加載幾十萬條數(shù)據(jù)，那全部拉回來再重新計算是不是就顯得很蠢了？為什么不在目標系統(tǒng)里以數(shù)據(jù)服務的形式提供呢？

技術(shù)架構(gòu)保障，其實大部分都是基礎(chǔ)架構(gòu)的事情了，比如動態(tài)負載均衡、一主多從、異地多機房容災、斷網(wǎng)演練、上游服務故障預案等等。

建模之社交網(wǎng)絡(luò)

很久以前就已經(jīng)介紹了各種社區(qū)發(fā)現(xiàn)算法，這里就不再贅述，有興趣的自己點進去細致了解一下。

這里聊聊一個知識圖譜的標準建立過程。

1、主體確認

2、關(guān)系建立。

3、邏輯推理建立。

4、圖譜檢索

主體確認，從圖的角度來看就是確認各個頂點，這些頂點有自己的屬性，代表著網(wǎng)絡(luò)里的一個個個體。

關(guān)系建立，從其他資料關(guān)系得來，也可以根據(jù)第三步的邏輯推理得來，從圖的角度來看就是確認各個邊，這些邊有起點有終點也有自己的屬性，代表著網(wǎng)絡(luò)里各個個體的關(guān)聯(lián)。

邏輯推理建立，這是非常重要的一個部分，比如姚明的老婆的母親，就是姚明的岳母，這種先驗知識的推理可以在圖譜的幫助下，為我們解決很多的實際問題。

圖譜檢索，有了圖譜我們就開始使用，我們有四件套，主體屬性搜索，關(guān)系屬性搜索，廣度優(yōu)先搜索，寬度優(yōu)先搜索。我們一般的使用策略都是，優(yōu)先確定一個頂點比如目標人物，然后向外擴散，直到找到所有符合條件的個體。

這里我們踩了什么坑做了什么優(yōu)化呢？我們一開始是把整個搜索結(jié)果拉到本地再進行計算，而圖譜搜索后的結(jié)果總是很大，畢竟我們找了很多維的關(guān)系，所以總是卡在網(wǎng)絡(luò)這塊。經(jīng)過探索和咨詢，最終確認了 Neo4j 這種圖數(shù)據(jù)庫不僅僅提供數(shù)據(jù)查詢服務，還做了基于定制化的社交網(wǎng)絡(luò)分析的插件化開發(fā)，把我們的反欺詐服務以插件化的形式部署到服務器中，這就減少了非常多的網(wǎng)絡(luò)開銷，保障了我們服務的秒級響應。

完整架構(gòu)圖

從數(shù)據(jù)來源、獲取、存儲、加工、應用，一步到位，萬一有點幫助那就更好了，如果還心存疑慮，這篇文章從下往上，再看一遍。
歡迎學Java和大數(shù)據(jù)的朋友們加入java架構(gòu)交流： 855835163
群內(nèi)提供免費的架構(gòu)資料還有：Java工程化、高性能及分布式、高性能、深入淺出。高架構(gòu)。性能調(diào)優(yōu)、Spring，MyBatis，Netty源碼分析和大數(shù)據(jù)等多個知識點高級進階干貨的免費直播講解 可以進來一起學習交流哦