大數據反欺詐技術架構

一年多之前，有朋友讓我聊一下大家的大數據反欺詐架構是怎麼實現的，以及咱們途中踩了哪些坑，怎麼作到從30min延遲優化到1s內完成實時反欺詐。當時呢第一是以爲不合適，第二也是以爲場景比較侷限沒什麼分享的必要性。

時間也過了好久了，最近看到圈裏一些東西，發現當時的這套架構並未落伍，依然具備很大的參考價值，因此今天跟大夥聊聊關於大數據反欺詐體系怎麼搭建，主要來源是來自於我工做的時候的實踐，以及跟行業裏的不少大佬交流的實踐，算是集小成的一個比較好的實踐。

這套架構我作的時候主要領域是信貸行業的大數據反欺詐，後來也看過電商的架構，也看過金融大數據的架構，發現其實你們使用的其實也差很少是這個套路，只是在各個環節都有不一樣的細節。

大佬說的，能用圖的，儘可能不要打字，那我就打少點字，多作點圖。其實大數據不外乎這麼幾個步驟。數據源開拓、數據抽取、數據存儲、數據清洗和處理、數據應用，且聽我一個一個說。

數據源

數據源是一個比較重要的點，畢竟若是連數據源都是垃圾，那麼毫無疑問能夠預見，最終產出的必定是垃圾，因此挑選數據源和對接數據源的時候都要關注，該機構產出的數據是否是都是質量比較高的數據。

好比人行徵信數據就是一個質量很是很是高的數據，主要涉及信用卡、銀行流水、老賴、失信、強制執行信息等，都很是核心，任何一個點均可能是一筆壞帳的苗頭。以及各類行政機構提供的付費機密數據。

好比運營商通信數據、好比大型電商的行爲數據、好比各類保險數據，以及各個機構貸款記錄的互相溝通，這些數據源，都很是核心也都很是值錢，是如今反欺詐很是核心的數據。

固然也有更加粗暴更加高效的作法，就是直接購買外部的黑名單數據，這讓反欺詐變得更加簡單，遇到就直接拒，能夠減小很是的人力物力成本去作其餘的核查。

數據抽取

有了高質量的數據源後，固然就是怎麼抽取的問題了，各個機構所提供的數據格式是多種多樣的，其中包括 http 接口的json、xml，內部其餘數據源的 etl、定時人工上報的 Excel，以及 sqoop+ozzie 這兩個直接數據抽取通道，這個過程只須要保證通道穩定，數據服務冪等便可，沒什麼特殊的地方。

數據存儲

數據存儲其實就是創建一個數據倉庫和一個實時倉庫，數據倉庫用於存儲來自各大數據源的原始數據，實時倉庫用於業務系統的核心做業，數據倉庫的數據量通常都以 T 爲單位，實時倉庫以 M 和 G 爲單位。

離線計算&實時計算

數據保證了，那麼計算就是這套架構的核心之處，從大的角度來看能夠分紅離線計算和實時計算。

離線計算主要會作兩件事情。Hive 、Spark 數據整合與清洗和離線數據建模。Hive 數據整合主要作的事情就是把各個數據庫裏面的東西，進行清洗和過濾，最終寫到咱們定義的標準表裏邊，提供給下游的計算使用。若是是很是複雜的數據清洗，咱們會使用 Spark 寫程序來作，畢竟有一些操做不是 Hive 這種標準 SQL 能解決的。離線數據建模，就是對於這批數據進行建模，以便後續用於實時計算和應用中，算法嘛，精通兩個基本就穩了，LogisticRegression & 決策樹，不要問我爲何。

實時計算又會作些什麼事情？SparkStreaming和Flink用於實時流計算，主要是用於一些統計類的事情，以及多個數據流的 join 操做。在這裏咱們但願作到什麼事情呢？就是但願服務能夠準實時，什麼叫準實時呢？就是在一個能夠接受的範圍內，我容許你有必定的延遲，這塊咱們一開始的任務延遲是 30 min。

咱們踩過哪些坑呢？

一開始咱們但願使用流批次計算來實現實時計算，實踐下來準實時跟實時仍是區別很大的，一個業務一般是容許不了分鐘級別的延遲的，然而 Spark 的 GraphX 必然有分鐘級別的延遲，只適合離線計算。

Hive + Ozzie 處理離線批量處理是一個很是大的利器，不少人都覺得Hive數據清洗不就寫寫幾行 SQL？幾百張乃至幾千張表背後的複雜的數據清洗規則，任務依賴，任務重跑，數據質量，數據血緣關係維護。相信我，要是沒有細心和工具，這些能把你搞崩潰。

ElasticSearch 集羣多個機器的負載吞吐量，比單臺機器高性能的要高，畢竟網絡卡在那。

咱們趟了不少的坑，摸了不少的時候，最終決定把全部的實時操做都架構在 ElasticSearch 和 Neo4j 上，由於咱們不只僅須要實時的全文本全字段社交關係生成，更是須要實時搜索多維度多層社交關係並反欺詐分析，而這個關係多是百萬級別的，根據六度理論，決定了咱們選取的層次不能太多，因此最終咱們只抽取其中三層社交關係。最終肯定這個架構，這很核心地肯定了咱們的響應時間，並最終決定了咱們服務的可用性。

不少地方產生的結果數據只是整個決策鏈上的一個細節，因此咱們還須要 Drools 這類規則引擎幫助作一個最終決策。

業務應用

最終業務系統應該怎麼使用，怎麼對外提供服務？這也是一個很是核心的問題，由於這部分要求很是很是穩定，以及很是很是高效，通常來講不容許有過高的延遲，同時還要求很是高的併發量。這就要求了咱們第一要儘可能提升計算效率，第二要求咱們對於系統的架構要有很是高的保障。

計算效率要高效，有什麼技巧呢，保證各個系統之間的交互都是聚合、加工、計算後的結果，而不是原始數據，畢竟網絡傳輸是須要很高成本的在目標數據量很是大的場景下。好比一次性要加載幾十萬條數據，那所有拉回來再從新計算是否是就顯得很蠢了？爲何不在目標系統裏以數據服務的形式提供呢？

技術架構保障，其實大部分都是基礎架構的事情了，好比動態負載均衡、一主多從、異地多機房容災、斷網演練、上游服務故障預案等等。

建模之社交網絡

好久之前就已經介紹了各類社區發現算法，這裏就再也不贅述，有興趣的本身點進去細緻瞭解一下。

這裏聊聊一個知識圖譜的標準創建過程。

一、主體確認

二、關係創建。

三、邏輯推理創建。

四、圖譜檢索

主體確認，從圖的角度來看就是確認各個頂點，這些頂點有本身的屬性，表明着網絡裏的一個個個體。

關係創建，從其餘資料關係得來，也能夠根據第三步的邏輯推理得來，從圖的角度來看就是確認各個邊，這些邊有起點有終點也有本身的屬性，表明着網絡裏各個個體的關聯。

邏輯推理創建，這是很是重要的一個部分，好比姚明的老婆的母親，就是姚明的岳母，這種先驗知識的推理能夠在圖譜的幫助下，爲咱們解決不少的實際問題。

圖譜檢索，有了圖譜咱們就開始使用，咱們有四件套，主體屬性搜索，關係屬性搜索，廣度優先搜索，寬度優先搜索。咱們通常的使用策略都是，優先肯定一個頂點好比目標人物，而後向外擴散，直到找到全部符合條件的個體。

這裏咱們踩了什麼坑作了什麼優化呢？咱們一開始是把整個搜索結果拉到本地再進行計算，而圖譜搜索後的結果老是很大，畢竟咱們找了不少維的關係，因此老是卡在網絡這塊。通過探索和諮詢，最終確認了 Neo4j 這種圖數據庫不只僅提供數據查詢服務，還作了基於定製化的社交網絡分析的插件化開發，把咱們的反欺詐服務以插件化的形式部署到服務器中，這就減小了很是多的網絡開銷，保障了咱們服務的秒級響應。

完整架構圖

從數據來源、獲取、存儲、加工、應用，一步到位，萬一有點幫助那就更好了，若是還心存疑慮，這篇文章從下往上，再看一遍。

歡迎學Java和大數據的朋友們加入java架構交流： 855835163

羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！