華文網

案例:光大銀行——風險一體化專案實施

本篇案例為資料猿推出的“金融科技價值—資料驅動金融商業裂變”大型主題策劃活動第一部分的文章/案例/產品徵集部分;感謝 天雲大資料 的投遞

1、企業名稱

光大銀行

2、所述分類

金融科技

3、案例背景

隨著大資料和互聯網+時代來臨,大資料成為商業銀行在市場競爭重要手段之一。新的市場和業務變化推動商業銀行向智慧化轉型。銀行信用卡中心資料外延大,與個人的結合點多,單筆消費信貸金額小,總體消費信貸金額高,

對風險控制與管理的要求較高。因此,信用卡風險管理對信用卡業務具有重要的意義,促進信用卡中心業務增長,努力建設資料驅動的新一代信用卡業務體系成為目前國內銀行的理想選擇。

4、實施時間:2016.10-2017.9

5、應用場景

當前光大信用卡風險管理涉及貸前、貸中、貸後等各業務環節,

已建設完成信用卡審批、催收、調額等系統,目前這些系統獨立運作,而且各業務系統與V+核心系統進行不間斷的資料交互。

由於缺乏統一的資料管控平臺,無法實現風險資料統一存儲管控,同時缺乏集中調度管理各風險模組的機制,各個風險子系統獨立運行,不利於實現對業務風險全面整體把控。風險業務分析資料來源多樣化,針對不同的業務場景很多資料都是重複的,

資料未被重複利用造成很大程度的資源浪費。

光大信用卡中心擬基於現有各風險管理子系統功能,通過風險事件實現各子系統業務處理流程調度,搭建客戶全生命週期內的風險統一管理平臺。該平臺不僅能夠最大限度地拓展各個子系統的風險管控功能,並基於事件和資訊在各子系統中的流轉實現系統間的風險事件交叉回饋評價及檢測機制,

從而形成整個客戶生命週期內的資訊統一管理、事件資訊聯動,為銀行信用卡風險政策的制定與落地提供統一的平臺支撐。

6、面臨挑戰

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

7、資料支援

採集多來源資料,整合光大信用卡中心各業務系統所涉及的資料資產;建立統一的資料存儲規範,

實現多來源資料融合存儲;為上層業務系統提供統一資料出口,對外提供資料查詢服務;做到一次寫入多次利用,提高資料利用率;多來源資料融合存儲,多來源資料橫向對比,提高資料品質。

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

資料格式主要為:JSON格式,文本格式等。

資料分類(類型)主要有:申請資訊、人行資訊(包括信用卡明細、貸款資訊、擔保資訊、養老資訊等)、協力廠商資料(百分點資料、國稅資料、公積金、學歷、公安等資訊)、調額資訊、貸中資料、催收資料、帳單資料等。

支援的資料量情況:日接收及存儲的資料量為:200-300萬左右;數據總量:6億左右;對外提供資料查詢服務,日請求量200萬次左右。

8、應用技術

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、商業變化

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

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

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

10、關於企業

天雲大資料,國內唯一能夠同時提供分散式運算平臺產品和AI平臺基礎設施的科技廠商,擁有博士後工作站和國家級高新企業稱號,並於2016首批進入中關村前沿科技企業重點計畫。

公司在分散式運算領域有自主產品,填補了連線事務等領域空白,並在多個大型銀行核心交易系統部署驗證。在人工智慧方向領先於BAT發佈了分散式AI平臺,於2016年在大型股份制銀行落地,該平臺與科大訊飛一起獲得了北美ZDnet評選的十大AI賦能平臺獎項。

憑藉分散式AI能力,天雲自2016開始為金融機構提供資料模型深入信用風險欺詐等金融業務領域,為人行、光大銀行、興業銀行、銀聯等提供信用業務相關計算與資料科學模型分析服務,由此獲得國際一線機構KPMG評定的中國Fintech50強,亞太Asset財經評選的TrippleA金融科技領先獎,財視的Fintech30強金融科技介甫獎,與螞蟻金服、京東金融等同列先進金融科技企業。

作為整體活動的第二部分,2017年10月25日,資料猿還將在北京舉辦千人規模的“2017金融科技價值——資料驅動金融商業裂變”峰會並將在現場舉行文章、案例、產品的頒獎典禮。

支援的資料量情況:日接收及存儲的資料量為:200-300萬左右;數據總量:6億左右;對外提供資料查詢服務,日請求量200萬次左右。

8、應用技術

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、商業變化

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

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

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

10、關於企業

天雲大資料,國內唯一能夠同時提供分散式運算平臺產品和AI平臺基礎設施的科技廠商,擁有博士後工作站和國家級高新企業稱號,並於2016首批進入中關村前沿科技企業重點計畫。

公司在分散式運算領域有自主產品,填補了連線事務等領域空白,並在多個大型銀行核心交易系統部署驗證。在人工智慧方向領先於BAT發佈了分散式AI平臺,於2016年在大型股份制銀行落地,該平臺與科大訊飛一起獲得了北美ZDnet評選的十大AI賦能平臺獎項。

憑藉分散式AI能力,天雲自2016開始為金融機構提供資料模型深入信用風險欺詐等金融業務領域,為人行、光大銀行、興業銀行、銀聯等提供信用業務相關計算與資料科學模型分析服務,由此獲得國際一線機構KPMG評定的中國Fintech50強,亞太Asset財經評選的TrippleA金融科技領先獎,財視的Fintech30強金融科技介甫獎,與螞蟻金服、京東金融等同列先進金融科技企業。

作為整體活動的第二部分,2017年10月25日,資料猿還將在北京舉辦千人規模的“2017金融科技價值——資料驅動金融商業裂變”峰會並將在現場舉行文章、案例、產品的頒獎典禮。