一、企業名稱

光大銀行

二、所述分類

金融科技

三、案例背景

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

四、實施時間

2016.10-2017.9
 

五、應用場景

當前光大信用卡風險管理涉及貸前、貸中、貸后等各業務環節，已建設完成信用卡審批、催收、調額等系統，目前這些系統獨立運作，而且各業務系統與V+核心系統進行不間斷的數據交互。

由于缺乏統一的數據管控平臺，無法實現風險數據統一存儲管控，同時缺乏集中調度管理各風險模塊的機制，各個風險子系統獨立運行，不利于實現對業務風險全面整體把控。風險業務分析數據來源多樣化，針對不同的業務場景很多數據都是重復的，數據未被重復利用造成很大程度的資源浪費。

光大信用卡中心擬基于現有各風險管理子系統功能，通過風險事件實現各子系統業務處理流程調度，搭建客戶全生命周期內的風險統一管理平臺。該平臺不僅能夠最大限度地拓展各個子系統的風險管控功能，并基于事件和信息在各子系統中的流轉實現系統間的風險事件交叉反饋評價及檢測機制，從而形成整個客戶生命周期內的信息統一管理、事件信息聯動，為銀行信用卡風險政策的制定與落地提供統一的平臺支撐。

六、面臨挑戰

風險業務分析數據來源多樣化，數據源多，非結構化數據的清洗、轉化等規則復雜，硬件載體不同，開發平臺不同，系統環境不同。

七、數據支持

采集多源數據，整合光大信用卡中心各業務系統所涉及的數據資產；建立統一的數據存儲規范，實現多源數據融合存儲；為上層業務系統提供統一數據出口，對外提供數據查詢服務；做到一次寫入多次利用，提高數據利用率；多源數據融合存儲，多源數據橫向對比，提高數據質量。

目前風險一體化平臺已上線運行，接入的數據來源主要為光大信用卡各業務系統。

數據格式主要為：JSON格式，文本格式等。

數據分類（類型）主要有：申請信息、人行信息（包括信用卡明細、貸款信息、擔保信息、養老信息等）、第三方數據（百分點數據、國稅數據、公積金、學歷、公安等信息）、調額信息、貸中數據、催收數據、賬單數據等。

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

八、應用技術

8.1、風險一體化基礎架構

8.1.1 分布式存儲技術

風險一體化平臺底層具有開放的架構，所有組件之間的交互利用標準的接口，具備很強的開放性。Hadoop的生態系統的組件有很多，它們之間有各自的分工也會有部分的重合，利用這些組件匹配出適合業務場景的組件，并要把適合的組件有機的組合在一起才能實現對業務有限的支持。開放性架構保證系統能夠針對業務需求靈活整合底層Hadoop組件，實現面向業務的最佳技術組合。

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

應用程序協調服務zookeeper、Hdfs分布式文件系統、資源管理器Yarn、分布式列存儲數據庫Hbase等；

計算框架：Spark：分布式大數據內存計算框架

8.1.2 多集群管理

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

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

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

為方便開發者更靈活方便的使用風險一體化平臺資源進行開發，系統提供REST風格的服務端接口。REST具有結構清晰、符合標準、易于理解、擴展方便等特性，開發者使用REST接口可以實現對底層多個Hadoop集群的統一監管。

平臺的集群管理功能，提供向導式的安裝步驟，協助使用者管理物理資源分配，可根據服務模型、集群角色等多種方式進行分配，做到最大限度的使用集群，并有效的降低集群管理的復雜度。

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

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

如圖所示，根據不用的硬件資源和使用目的，將集群和主機分組，用于歸檔數據查詢的集群由千兆網絡、雙核高頻CPU、32GB內存、低速磁盤的主機組成；用于高并發的集群由千兆網絡、多核低頻CPU、64GB內存、高速磁盤的主機組成；用于復雜分析類的集群由萬兆網絡、多核高頻CPU、128GB內存、掛載固態硬盤的主機組成。

平臺的主機管理功能可以創建、配置主機，與集群管理配合使用，完成集群和主機的對應，根據不同的服務模型、集群角色等方式，進行主機分配。使用平臺的主機管理功能使用戶不必專門學習Linux與Hadoop相關配置知識，只需要通過簡單的界面操作即可實現對主機的管理與監控，有效的簡化了Hadoop集群的部署過程。

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

8.1.3 開源服務框架管理

系統采用當前業內主流Hadoop平臺進行底層支撐，將Hadoop平臺下相關技術組件均進行封裝，使應用開發平臺用戶不必關心Hadoop底層實現方式，只需要調用應用開發平臺API即可進行相應的操作，可以做到平臺無關性，并簡化相關操作。這些組件的封裝包括但不限于HDFS、HBase、MapReduce、YARN、Hive、Impala、Storm、Spark、Sqoop、Kerberos、Flume、Solr、Kafka、zookeeper。

8.1.4 多源數據融合

數據融合模塊針對多個數據源實現全量數據的統一存儲，定制相應的數據模板及校驗規則對各系統接入的數據源進行一致性校驗，并根據規則對臟數據、重復數據、缺失數據進行處理。

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

歷史數據的一次性入庫
將已經有數據格式的歷史業務數據，直接調用數據融合模塊，進行數據錄入存儲。

新增數據的批量入庫
負責定期定時從業務系統中采集業務增量數據，并對數據進行一致性校驗，校驗成功后，直接調用數據融合模塊，進行數據錄入存儲。

8.2 SQL查詢技術

Hadoop大數據技術通過Hive和Spark等組件提供標準SQL支持，尤其是Spark2.0發布以后，Hadoop生態隊已經能夠支持TPC－DS 99標準，可以實現標準的SQL查詢語法。

同時在開源Hadoop SQL支持之上，天云采用自主研發的數據探查工具，能夠實現基于不同數據源的靈活SQL查詢。

1)能夠實現底層基于不同的數據源大數據平臺、數據倉庫、傳統關系型數據庫的跨數據庫靈活查詢。

2)支持標準SQL查詢語句，實現靈活SQL查詢。

通過Hadoop生態體系的SQL支持能力和天云的數據探查工具，完全能夠滿足對于結構化數據的查詢需求。

實時OLTP引擎靈活查詢技術

針對業務對查詢性能要求高的問題，系統采用HBase分布式列存數據庫支撐數據查詢業務，HBase通過主鍵Row key進行數據查詢，可以達到實時查詢響應，但這種方式也導致了HBase自身靈活性較差；

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

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

1)BDP-RT特性：

與Hadoop生態圈緊密結合。

Hbase與solr的有效整合。

通過solr實現Hbase二級索引。

強大的一致性支持。

線性擴展能力。

讀寫嚴格一致。

基類支持HBase表的MapReduce作業。

數據查詢的秒級、毫秒級響應。

 
2)BDP-RT用途

針對OLTP工作負載，能夠快速低延遲的訪問數據。

針對ACID，能夠保證數據的強一致性。

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

針對OLAP工作負載，能夠對數據對象中的大部分數據進行批處理的處理引擎。

 
8.2.1 客戶信息真實性判斷

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

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

 
8.2.1.1地址信息模糊匹配功能技術實現

針對地址匹配功能，天云所采用專業的文本分詞技術，實現地址信息的分詞，根據分詞信息進行地址模糊匹配。

天云分詞系統提供高精度的切詞功能。同時，利用新詞識別模塊，自動化擴充領域詞典。

 
8.2.2 事件管理模塊

事件管理模塊基于系統日志功能，實現對事件數據的記錄和采集，并通過對日志數據的查詢和分析，實現事件的全程可追溯，從而到實時預警，實現降低信用卡使用風險的業務目標。

Flume是Hadoop生態體系中提供的日志收集系統，Flume支持在日志系統中定制各類數據發送方，用于收集數據；同時，Flume提供對數據進行簡單處理，并寫到各種數據接受方（可定制）的能力。

Flume是一個分布式、可靠、和高可用的海量日志采集、聚合和傳輸的系統。

本系統創新的將Flume和Kafka整合在一起，形成基于消息總線的分布式數據聚合系統，實現日志數據的實時采集。

數據采集負責從各節點上實時采集數據，選用cloudera的flume來實現,flume是一個分布式、可靠、和高可用的海量日志聚合的系統，支持在系統中定制各類數據發送方，用于收集數據；同時，Flume提供對數據進行簡單處理，并寫到各種數據接受方的能力。

flume的邏輯架構：

Flume架構

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

數據接入

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

9、商業變化

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

致力于解決銀行內部數據的分析和已有數據孤島問題，光大風險一體化平臺成功整合了信用卡中心各業務所涉及數據資產，建立統一的數據資源池，建立統一的數據存儲規范，實現多源數據的融合存儲。通過多源數據融合存儲，實現多源數據的橫向比對，提高數據質量，為上層業務提高更好的數據支撐。

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