風(fēng)險(xiǎn)一體化項(xiàng)目實(shí)施案例

 

項(xiàng)目背景

隨著大數(shù)據(jù)和互聯(lián)網(wǎng)+時代來臨，大數(shù)據(jù)成為商業(yè)銀行在市場競爭重要手段之一。新的市場和業(yè)務(wù)變化推動商業(yè)銀行向智能化轉(zhuǎn)型。銀行信用卡中心數(shù)據(jù)外延大，與個人的結(jié)合點(diǎn)多，單筆消費(fèi)信貸金額小，總體消費(fèi)信貸金額高，對風(fēng)險(xiǎn)控制與管理的要求較高。因此，信用卡風(fēng)險(xiǎn)管理對信用卡業(yè)務(wù)具有重要的意義，促進(jìn)信用卡中心業(yè)務(wù)增長，努力建設(shè)數(shù)據(jù)驅(qū)動的新一代信用卡業(yè)務(wù)體系成為目前國內(nèi)銀行的理想選擇。

 

應(yīng)用場景

當(dāng)前信用卡風(fēng)險(xiǎn)管理涉及貸前、貸中、貸后等各業(yè)務(wù)環(huán)節(jié)，已建設(shè)完成信用卡審批、催收、調(diào)額等系統(tǒng)，目前這些系統(tǒng)獨(dú)立運(yùn)作，而且各業(yè)務(wù)系統(tǒng)與V+核心系統(tǒng)進(jìn)行不間斷的數(shù)據(jù)交互。

由于缺乏統(tǒng)一的數(shù)據(jù)管控平臺，無法實(shí)現(xiàn)風(fēng)險(xiǎn)數(shù)據(jù)統(tǒng)一存儲管控，同時缺乏集中調(diào)度管理各風(fēng)險(xiǎn)模塊的機(jī)制，各個風(fēng)險(xiǎn)子系統(tǒng)獨(dú)立運(yùn)行，不利于實(shí)現(xiàn)對業(yè)務(wù)風(fēng)險(xiǎn)全面整體把控。風(fēng)險(xiǎn)業(yè)務(wù)分析數(shù)據(jù)來源多樣化，針對不同的業(yè)務(wù)場景很多數(shù)據(jù)都是重復(fù)的，數(shù)據(jù)未被重復(fù)利用造成很大程度的資源浪費(fèi)。

信用卡中心擬基于現(xiàn)有各風(fēng)險(xiǎn)管理子系統(tǒng)功能，通過風(fēng)險(xiǎn)事件實(shí)現(xiàn)各子系統(tǒng)業(yè)務(wù)處理流程調(diào)度，搭建客戶全生命周期內(nèi)的風(fēng)險(xiǎn)統(tǒng)一管理平臺。該平臺不僅能夠最大限度地拓展各個子系統(tǒng)的風(fēng)險(xiǎn)管控功能，并基于事件和信息在各子系統(tǒng)中的流轉(zhuǎn)實(shí)現(xiàn)系統(tǒng)間的風(fēng)險(xiǎn)事件交叉反饋評價及檢測機(jī)制，從而形成整個客戶生命周期內(nèi)的信息統(tǒng)一管理、事件信息聯(lián)動，為銀行信用卡風(fēng)險(xiǎn)政策的制定與落地提供統(tǒng)一的平臺支撐。

 

面臨的挑戰(zhàn)

風(fēng)險(xiǎn)業(yè)務(wù)分析數(shù)據(jù)來源多樣化，數(shù)據(jù)源多，非結(jié)構(gòu)化數(shù)據(jù)的清洗、轉(zhuǎn)化等規(guī)則復(fù)雜，硬件載體不同，開發(fā)平臺不同，系統(tǒng)環(huán)境不同。

 

數(shù)據(jù)支持

采集多源數(shù)據(jù)，整合光大信用卡中心各業(yè)務(wù)系統(tǒng)所涉及的數(shù)據(jù)資產(chǎn)；建立統(tǒng)一的數(shù)據(jù)存儲規(guī)范，實(shí)現(xiàn)多源數(shù)據(jù)融合存儲；為上層業(yè)務(wù)系統(tǒng)提供統(tǒng)一數(shù)據(jù)出口，對外提供數(shù)據(jù)查詢服務(wù)；做到一次寫入多次利用，提高數(shù)據(jù)利用率；多源數(shù)據(jù)融合存儲，多源數(shù)據(jù)橫向?qū)Ρ龋岣邤?shù)據(jù)質(zhì)量。

目前風(fēng)險(xiǎn)一體化平臺已上線運(yùn)行，接入的數(shù)據(jù)來源主要為光大信用卡各業(yè)務(wù)系統(tǒng)。

數(shù)據(jù)格式主要為：JSON格式，文本格式等。

數(shù)據(jù)分類（類型）主要有：申請信息、人行信息（包括信用卡明細(xì)、貸款信息、擔(dān)保信息、養(yǎng)老信息等）、第三方數(shù)據(jù)（百分點(diǎn)數(shù)據(jù)、國稅數(shù)據(jù)、公積金、學(xué)歷、公安等信息）、調(diào)額信息、貸中數(shù)據(jù)、催收數(shù)據(jù)、賬單數(shù)據(jù)等。

支持的數(shù)據(jù)量情況：日接收及存儲的數(shù)據(jù)量為：200-300萬左右；數(shù)據(jù)總量：6億左右；對外提供數(shù)據(jù)查詢服務(wù)，日請求量200萬次左右。

 

應(yīng)用技術(shù)

1、風(fēng)險(xiǎn)一體化基礎(chǔ)架構(gòu)

1.1 分布式存儲技術(shù)

風(fēng)險(xiǎn)一體化平臺底層具有開放的架構(gòu)，所有組件之間的交互利用標(biāo)準(zhǔn)的接口，具備很強(qiáng)的開放性。Hadoop的生態(tài)系統(tǒng)的組件有很多，它們之間有各自的分工也會有部分的重合，利用這些組件匹配出適合業(yè)務(wù)場景的組件，并要把適合的組件有機(jī)的組合在一起才能實(shí)現(xiàn)對業(yè)務(wù)有限的支持。開放性架構(gòu)保證系統(tǒng)能夠針對業(yè)務(wù)需求靈活整合底層Hadoop組件，實(shí)現(xiàn)面向業(yè)務(wù)的最佳技術(shù)組合。

下圖中包含了最常用的組件，主要包括：

應(yīng)用程序協(xié)調(diào)服務(wù)zookeeper、Hdfs分布式文件系統(tǒng)、資源管理器Yarn、分布式列存儲數(shù)據(jù)庫Hbase等；

計(jì)算框架：Spark：分布式大數(shù)據(jù)內(nèi)存計(jì)算框架

 

1.2 多集群管理

系統(tǒng)底層集群的規(guī)模越來越大，在集群上線前期，部署通常要占用大量的時間和精力。Hadoop作為分布式計(jì)算平臺，雖然可以很容易的處理海量數(shù)據(jù)，但是部署步驟較為繁瑣。官方上的部署文檔一般是配置免密鑰登錄、配置jdk、修改相關(guān)配置文件，再分發(fā)幾臺到節(jié)點(diǎn)服務(wù)器上。

幾個節(jié)點(diǎn)的集群從系統(tǒng)安裝好到集群部署完成需要幾個小時，相關(guān)服務(wù)無法啟動的話還需要慢慢排錯，意味著集群投入使用需要更長的時間。每次部署如果都手動部署環(huán)境的話會非常麻煩，手工部署顯得效率低，容易出錯。因此，自動化部署集群顯得更適合大規(guī)模集群上線的情景，而且只需配置一次，測試成功后以后都可以使用。

平臺的自動化部署不只支持部署Hadoop，包括集群、主機(jī)、服務(wù)等在內(nèi)均可自動化部署完成。天云大數(shù)據(jù)BDP企業(yè)級平臺的自動化部署，保障了版本的一致性，可以幫助用戶快速搭建Hadoop集群，2小時內(nèi)即可完成一套10節(jié)點(diǎn)集群的部署，大大提高了部署效率。

為方便開發(fā)者更靈活方便的使用風(fēng)險(xiǎn)一體化平臺資源進(jìn)行開發(fā)，系統(tǒng)提供REST風(fēng)格的服務(wù)端接口。REST具有結(jié)構(gòu)清晰、符合標(biāo)準(zhǔn)、易于理解、擴(kuò)展方便等特性，開發(fā)者使用REST接口可以實(shí)現(xiàn)對底層多個Hadoop集群的統(tǒng)一監(jiān)管。

平臺的集群管理功能，提供向?qū)降陌惭b步驟，協(xié)助使用者管理物理資源分配，可根據(jù)服務(wù)模型、集群角色等多種方式進(jìn)行分配，做到最大限度的使用集群，并有效的降低集群管理的復(fù)雜度。

根據(jù)不同的服務(wù)模型、集群角色等方式,可添加多個主機(jī)，并將主機(jī)按集群分組。按不同的主機(jī)配置分配到不同用途的集群中，得到物理資源合理利用、資源利用最大化的效果。

用戶需要完全理解工作負(fù)載，這樣才能選擇最優(yōu)的大數(shù)據(jù)硬件，下邊是一個BDP企業(yè)級平臺定義集群，主機(jī)分組的例子：

如圖所示，根據(jù)不用的硬件資源和使用目的，將集群和主機(jī)分組，用于歸檔數(shù)據(jù)查詢的集群由千兆網(wǎng)絡(luò)、雙核高頻CPU、32GB內(nèi)存、低速磁盤的主機(jī)組成；用于高并發(fā)的集群由千兆網(wǎng)絡(luò)、多核低頻CPU、64GB內(nèi)存、高速磁盤的主機(jī)組成；用于復(fù)雜分析類的集群由萬兆網(wǎng)絡(luò)、多核高頻CPU、128GB內(nèi)存、掛載固態(tài)硬盤的主機(jī)組成。

平臺的主機(jī)管理功能可以創(chuàng)建、配置主機(jī)，與集群管理配合使用，完成集群和主機(jī)的對應(yīng)，根據(jù)不同的服務(wù)模型、集群角色等方式，進(jìn)行主機(jī)分配。使用平臺的主機(jī)管理功能使用戶不必專門學(xué)習(xí)Linux與Hadoop相關(guān)配置知識，只需要通過簡單的界面操作即可實(shí)現(xiàn)對主機(jī)的管理與監(jiān)控，有效的簡化了Hadoop集群的部署過程。

大數(shù)據(jù)平臺系統(tǒng)出現(xiàn)問題，可能的原因很多，具體原因有網(wǎng)絡(luò)、硬件故障、操作系統(tǒng)故障、服務(wù)配置與運(yùn)行、病毒、異常進(jìn)程、負(fù)載等。往往對具體原因不便追查。在實(shí)際工作中，日志中經(jīng)常有各種嚴(yán)重錯誤信息，但也不影響信息系統(tǒng)正常運(yùn)行。這時就會出現(xiàn)積累性或累加性的錯誤，系統(tǒng)運(yùn)行初時沒有影響，一旦累計(jì)到一定程度，會發(fā)生系統(tǒng)崩潰。為防止出現(xiàn)這種情況，需要進(jìn)行相關(guān)性分析。在故障處理時，相關(guān)性分析尤其重要，可以迅速定位故障、減少判定時間。

 

1.3 開源服務(wù)框架管理

系統(tǒng)采用當(dāng)前業(yè)內(nèi)主流Hadoop平臺進(jìn)行底層支撐，將Hadoop平臺下相關(guān)技術(shù)組件均進(jìn)行封裝，使應(yīng)用開發(fā)平臺用戶不必關(guān)心Hadoop底層實(shí)現(xiàn)方式，只需要調(diào)用應(yīng)用開發(fā)平臺API即可進(jìn)行相應(yīng)的操作，可以做到平臺無關(guān)性，并簡化相關(guān)操作。這些組件的封裝包括但不限于HDFS、HBase、MapReduce、YARN、Hive、Impala、Storm、Spark、Sqoop、Kerberos、Flume、Solr、Kafka、zookeeper。

 

1.4 多源數(shù)據(jù)融合

數(shù)據(jù)融合模塊針對多個數(shù)據(jù)源實(shí)現(xiàn)全量數(shù)據(jù)的統(tǒng)一存儲，定制相應(yīng)的數(shù)據(jù)模板及校驗(yàn)規(guī)則對各系統(tǒng)接入的數(shù)據(jù)源進(jìn)行一致性校驗(yàn)，并根據(jù)規(guī)則對臟數(shù)據(jù)、重復(fù)數(shù)據(jù)、缺失數(shù)據(jù)進(jìn)行處理。

數(shù)據(jù)融合模塊區(qū)別于傳統(tǒng)技術(shù)，利用大數(shù)據(jù)技術(shù)手段，以Key/Value鍵值對的形式存儲全量業(yè)務(wù)數(shù)據(jù)，通過分析業(yè)務(wù)需求預(yù)定義合適的主鍵，并將增量數(shù)據(jù)逐條插入到數(shù)據(jù)庫中，形成統(tǒng)一的數(shù)據(jù)寬表，方便后續(xù)數(shù)據(jù)分析處理。

歷史數(shù)據(jù)的一次性入庫
將已經(jīng)有數(shù)據(jù)格式的歷史業(yè)務(wù)數(shù)據(jù)，直接調(diào)用數(shù)據(jù)融合模塊，進(jìn)行數(shù)據(jù)錄入存儲。

新增數(shù)據(jù)的批量入庫
負(fù)責(zé)定期定時從業(yè)務(wù)系統(tǒng)中采集業(yè)務(wù)增量數(shù)據(jù)，并對數(shù)據(jù)進(jìn)行一致性校驗(yàn)，校驗(yàn)成功后，直接調(diào)用數(shù)據(jù)融合模塊，進(jìn)行數(shù)據(jù)錄入存儲。

 

2 SQL查詢技術(shù)

Hadoop大數(shù)據(jù)技術(shù)通過Hive和Spark等組件提供標(biāo)準(zhǔn)SQL支持，尤其是Spark2.0發(fā)布以后，Hadoop生態(tài)隊(duì)已經(jīng)能夠支持TPC－DS 99標(biāo)準(zhǔn)，可以實(shí)現(xiàn)標(biāo)準(zhǔn)的SQL查詢語法。

同時在開源Hadoop SQL支持之上，天云采用自主研發(fā)的數(shù)據(jù)探查工具，能夠?qū)崿F(xiàn)基于不同數(shù)據(jù)源的靈活SQL查詢。

1)能夠?qū)崿F(xiàn)底層基于不同的數(shù)據(jù)源大數(shù)據(jù)平臺、數(shù)據(jù)倉庫、傳統(tǒng)關(guān)系型數(shù)據(jù)庫的跨數(shù)據(jù)庫靈活查詢。

2)支持標(biāo)準(zhǔn)SQL查詢語句，實(shí)現(xiàn)靈活SQL查詢。

通過Hadoop生態(tài)體系的SQL支持能力和天云的數(shù)據(jù)探查工具，完全能夠滿足對于結(jié)構(gòu)化數(shù)據(jù)的查詢需求。

實(shí)時OLTP引擎靈活查詢技術(shù)

針對業(yè)務(wù)對查詢性能要求高的問題，系統(tǒng)采用HBase分布式列存數(shù)據(jù)庫支撐數(shù)據(jù)查詢業(yè)務(wù)，HBase通過主鍵Row key進(jìn)行數(shù)據(jù)查詢，可以達(dá)到實(shí)時查詢響應(yīng)，但這種方式也導(dǎo)致了HBase自身靈活性較差；

針對查詢條件靈活的問題，系統(tǒng)采用SolrCloud做為HBase的二級索引，通過索引手段來保證查詢的靈活性。靈活性體現(xiàn)了可以實(shí)現(xiàn)根據(jù)任意字段、關(guān)鍵字進(jìn)行查詢，或者是字段的任意組合。例如指定查詢包含某個或某幾個字段，同時要求不包含某個字段任意組合條件查詢等。

Hbase和Solr自身無法保證數(shù)據(jù)的一致性且兩者結(jié)合開發(fā)人員使用難度高，需要同時熟練使用Hbase與Solr。針對以上問題我方提供一款中間件產(chǎn)品BDTQ，它從底層支持事務(wù)，很好的保證了數(shù)據(jù)的一致性，同時對開發(fā)者提供友好的接口，開發(fā)者不需要關(guān)心Hbase與solr之間如何關(guān)聯(lián)如何使用，只需要寫簡單的代碼就可以實(shí)現(xiàn)數(shù)據(jù)的入口與檢索，降低了開發(fā)成本提高了開發(fā)效率，使代碼維護(hù)工作更加方便。

1)BDP-RT特性：

與Hadoop生態(tài)圈緊密結(jié)合。

Hbase與solr的有效整合。

通過solr實(shí)現(xiàn)Hbase二級索引。

強(qiáng)大的一致性支持。

線性擴(kuò)展能力。

讀寫嚴(yán)格一致。

基類支持HBase表的MapReduce作業(yè)。

數(shù)據(jù)查詢的秒級、毫秒級響應(yīng)。

2)BDP-RT用途

針對OLTP工作負(fù)載，能夠快速低延遲的訪問數(shù)據(jù)。

針對ACID，能夠保證數(shù)據(jù)的強(qiáng)一致性。

針對開發(fā)人員，簡化使用的復(fù)雜度，降低開發(fā)成本。

針對OLAP工作負(fù)載，能夠?qū)?shù)據(jù)對象中的大部分?jǐn)?shù)據(jù)進(jìn)行批處理的處理引擎。

 

2.1 客戶信息真實(shí)性判斷

 

作為信用卡業(yè)務(wù)的生命線，風(fēng)險(xiǎn)管理被視為信用卡工作的重中之重。隨著近年信用卡業(yè)務(wù)發(fā)展，信用卡申請數(shù)據(jù)激增，部分用戶為了提高信用卡申請成功率和授信額度，在申請信息中提供虛假信息，成為信用卡風(fēng)險(xiǎn)的重要來源之一。風(fēng)險(xiǎn)一體化平臺一個重要功能就是實(shí)現(xiàn)用戶信息真實(shí)性判斷，發(fā)現(xiàn)其中的風(fēng)險(xiǎn)信息，具體如下：

風(fēng)險(xiǎn)一體化平臺通過數(shù)據(jù)融合整合多方數(shù)據(jù)來源，包括光大業(yè)務(wù)系統(tǒng)數(shù)據(jù)和第三方數(shù)據(jù)，尤其是人行征信數(shù)據(jù)、公安數(shù)據(jù)、公積金數(shù)據(jù)等，從用戶、賬戶等多個層面進(jìn)行數(shù)據(jù)打通。在基于客戶數(shù)據(jù)統(tǒng)一管理的基礎(chǔ)上，實(shí)現(xiàn)用戶信息在多方數(shù)據(jù)之間的交叉驗(yàn)證，對用戶信息進(jìn)行真實(shí)性判斷，篩選屏蔽其中的虛假客戶信息，以便準(zhǔn)確授信，降低風(fēng)險(xiǎn)。

2.1.1地址信息模糊匹配功能技術(shù)實(shí)現(xiàn)

針對地址匹配功能，天云所采用專業(yè)的文本分詞技術(shù)，實(shí)現(xiàn)地址信息的分詞，根據(jù)分詞信息進(jìn)行地址模糊匹配。

天云分詞系統(tǒng)提供高精度的切詞功能。同時，利用新詞識別模塊，自動化擴(kuò)充領(lǐng)域詞典。

 

2.2 事件管理模塊

 

事件管理模塊基于系統(tǒng)日志功能，實(shí)現(xiàn)對事件數(shù)據(jù)的記錄和采集，并通過對日志數(shù)據(jù)的查詢和分析，實(shí)現(xiàn)事件的全程可追溯，從而到實(shí)時預(yù)警，實(shí)現(xiàn)降低信用卡使用風(fēng)險(xiǎn)的業(yè)務(wù)目標(biāo)。

Flume是Hadoop生態(tài)體系中提供的日志收集系統(tǒng)，F(xiàn)lume支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，F(xiàn)lume提供對數(shù)據(jù)進(jìn)行簡單處理，并寫到各種數(shù)據(jù)接受方（可定制）的能力。

Flume是一個分布式、可靠、和高可用的海量日志采集、聚合和傳輸?shù)南到y(tǒng)。

本系統(tǒng)創(chuàng)新的將Flume和Kafka整合在一起，形成基于消息總線的分布式數(shù)據(jù)聚合系統(tǒng)，實(shí)現(xiàn)日志數(shù)據(jù)的實(shí)時采集。

數(shù)據(jù)采集負(fù)責(zé)從各節(jié)點(diǎn)上實(shí)時采集數(shù)據(jù)，選用cloudera的flume來實(shí)現(xiàn),flume是一個分布式、可靠、和高可用的海量日志聚合的系統(tǒng)，支持在系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，F(xiàn)lume提供對數(shù)據(jù)進(jìn)行簡單處理，并寫到各種數(shù)據(jù)接受方的能力。

flume的邏輯架構(gòu)：

Flume架構(gòu)

Flume采用了分層架構(gòu)：分別為agent，collector和storage。其中，agent和collector均由兩部分組成：source和sink，source是數(shù)據(jù)來源，sink是數(shù)據(jù)去向。Flume使用兩個組件：Master和Node，Node根據(jù)在Master shell或web中動態(tài)配置，決定其是作為Agent還是Collector。

數(shù)據(jù)接入

由于采集數(shù)據(jù)的速度和數(shù)據(jù)處理的速度不一定同步，因此添加一個消息中間件來作為緩沖，選用apache的kafka, Kafka是Linkedin所支持的一款開源的、分布式的、高吞吐量的發(fā)布訂閱消息系統(tǒng),可以有效地處理流式數(shù)據(jù)。

 

 

商業(yè)變化

辦理信用卡中存在的風(fēng)險(xiǎn)問題，使得銀行每年因金融欺詐損失數(shù)十億元，傳統(tǒng)的離散式反欺詐分析方法的漏洞暴露的越來越多，已無法有效的阻止這些欺詐行為，經(jīng)驗(yàn)豐富的欺詐者利用這些漏洞創(chuàng)造出更多的欺詐手段，而不被金融機(jī)構(gòu)發(fā)現(xiàn)。如何迅速有效識別欺詐，為業(yè)務(wù)風(fēng)險(xiǎn)分析提供高效的數(shù)據(jù)服務(wù)成為題中之義。

致力于解決銀行內(nèi)部數(shù)據(jù)的分析和已有數(shù)據(jù)孤島問題，光大風(fēng)險(xiǎn)一體化平臺成功整合了信用卡中心各業(yè)務(wù)所涉及數(shù)據(jù)資產(chǎn)，建立統(tǒng)一的數(shù)據(jù)資源池，建立統(tǒng)一的數(shù)據(jù)存儲規(guī)范，實(shí)現(xiàn)多源數(shù)據(jù)的融合存儲。通過多源數(shù)據(jù)融合存儲，實(shí)現(xiàn)多源數(shù)據(jù)的橫向比對，提高數(shù)據(jù)質(zhì)量，為上層業(yè)務(wù)提高更好的數(shù)據(jù)支撐。

風(fēng)險(xiǎn)一體化平臺的建設(shè)，為業(yè)務(wù)風(fēng)險(xiǎn)分析提供高效的數(shù)據(jù)服務(wù)，實(shí)現(xiàn)面向風(fēng)險(xiǎn)業(yè)務(wù)的實(shí)時數(shù)據(jù)反饋，最大程度上提升工作效率，降低幾百萬運(yùn)營及人力成本投入。同時為信用卡審批提供交叉驗(yàn)證，有效識別欺詐虛假信息，結(jié)合數(shù)據(jù)分析技術(shù)有效識別信用卡欺詐事件，降低欺詐業(yè)務(wù)風(fēng)險(xiǎn)，每年降低了近千萬的欺詐損失。