中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

這篇文章是支付風控系統設計的第二篇，重點介紹支持支付風控的數據倉庫建設。關于支付系統在風控上的具體需求，可參見上一篇文章 《支付風控場景分析》。

支付風控系統在數據存儲設計上和其它業務不同的地方在于數據獲取與使用的流程。一般業務系統會先確定系統數據需求，再設計如何在業務流程中采集數據，以及數據的格式怎么定義。而支付風控面臨的是一個無法預知的場景，需要在實踐中根據當前運行情況不斷調整。它會先把數據采集過來，之后才能從中發現可能存在的問題，并針對該問題制訂風控規則。也就是風控是先采集數據，再使用數據。

風控分析不僅要看交易數據，還得研究所有相關聯的數據，這才能全面分析出來風險的根源，推斷出需要采取的措施。因而數據采集工作對風控系統建設和演化是非常重要的。本文分析風控所需要的數據，如何采集和存儲數據，建立支持風控的數據倉庫。

一、數據來源

一筆交易的風險等級的計算需要考慮到多個維度。未成年人購買高檔酒、促銷期間羊毛客刷單、在洗錢高發地區的商戶銷售的物品成交價格遠超實際價格。這些可疑交易的識別，僅依靠支付系統本身是無法完成的。用戶的年齡、商品特點(是否高檔酒)、是否促銷、羊毛號的識別等，需要從各業務系統，甚至公司外部收集和用戶、商品、商家、地區、手機號相關的數據，通過對這些數據進行分析，提取特征，識別潛在的風險。

1. 內部數據

風控幾乎需要收集所有相關系統的數據。 用戶系統需采集用戶的靜態信息，姓名、性別、年齡等。風控系統不僅僅關注這些靜態信息，還需要重點關注用戶的行為信息，包括注冊、密碼修改、修改個人信息等操作，需要收集這些操作的時間、地點、設備等信息。 此外，用戶之間的關系，也是風控系統需要關注的數據。

• 商戶系統：除了采集機構的基本信息，如成立時間、注冊時間、人員規模、營業額、銷售額、經營范圍、注冊地點等， 還需要考慮到該商戶關聯的用戶，包括法人代表、公司組織結構、主要員工信息等。
• 商品系統：商品的靜態信息，包括類型、價格、上架時間、庫存等信息； 商品的瀏覽、放入購物車、購買、評論、退貨等用戶操作，包括這些操作的時間、地點、設備等信息。
• 社交數據，包括評論、論壇、留言等。
• 業務系統，如視頻系統中的觀影記錄、類型偏好、時間、地點、設備等信息。

當然，支付數據是風控最重要基礎數據。用戶在支付系統中涉及到的數據都需要收集整理來支持風控分析。包括但不限于賬戶數據、訂單數據、交易數據、優惠券數據和賬務流水等。這些數據在支付數據庫中也存在，風控所需要的數據和業務數據略有不同。除了業務數據外，風控還關心如下數據：

• 用戶當前上下文環境，包括用戶所用設備的類型、操作系統、IP地址、設備ID、所在地等，而這些數據往往并不是業務所關心的。而且記錄太多的上下文數據也影響性能。
• 賬戶，訂單等操作實體的狀態。在業務數據庫中一般僅保留實體的最終狀態，比如賬戶是否已鎖定、訂單是否已支付等。 而風控需要關心這些狀態變更的時機，以及變更的時間間隔。例如，用戶頻繁更改交易密碼，超正常頻率提交訂單等，就不是一個正常的狀態。

這些數據一般可以從日志中采集。

2. 外部數據

對于大部分業務單一和用戶量不大的公司來說，其數據有限而且單一，需要使用外部數據來輔助完成風控計算。

常用的外部數據包括：

• 公安部的實名認證數據，包括用戶姓名、身份證號信息；
• 央行發布的各種名單，如洗錢區域，恐怖組織名單等。
• 央行信用報告，這個查詢可是要真金白銀的。
• 微博數據，一個人經常了解如何養卡，套現等內容并不是太好的事情。
• 工商局提供的公司信息。
• 招聘網站上的公司招聘信息。公司一直有招聘說明業務還不錯。
• 芝麻信用，這個需要申請。

二、采集方式

一般來說，風控的非實時數據采集，不能直接從線上的數據庫中讀取，這會把數據庫打死。主要的數據采集方式有從庫采集，日志采集和pingback三種方式。

1. 數據庫從庫

主流數據庫，如Hbase，Mysql都提供同步數據進從庫的功能，讀取從庫不會影響主庫操作。但如上所述，采用從庫有如下問題：

• 分析所需數據和業務數據不同，還需要從其他途徑補充數據。
• 將風控所需數據和業務數據緊耦合起來了。一旦業務有變更，風控系統也需要調整。

2.?日志

這是風控數據采集的主要方式。 業務方可以將風控所需要的數據輸出到日志中，風控系統對接日志來異步采集數據。這使得數據采集不會影響業務處理主流程。 這種方式風險在于：

• 需要規范日志的格式，否則每個系統一套日志格式，會導致對接工作量巨大。
• 保持日志的穩定性。一旦代碼被修改，打印日志的代碼被刪除了，會導致日志數據無法采集的風險。
• 需要注意日志采集系統的可靠性。目前主流的采集框架都有可能會丟失日志。雖然從我們使用的情況來還未發生這種事情，但不排除這個風險。

從技術上來說，日志采集的框架主要框架有

• ELK（Elastic + Logstash + Kibana）， Logstash 駐留在日志輸出端采集日志，并發送到Elastic 服務器上。 Kibana則是一個日志分析的工具；
• Flume + Kafka + Elastic 。 通過Flume進行采集，輸出到Kafka，匯總到Elastic進行存儲。日志分析可以在Elastic上離線非實時進行，也可以直接對接Kafka準實時分析，即流處理。 使用Storm 或者Spark都可以。

3.?pingback

Pingback指在頁面上埋入腳本來監測用戶的操作，特別是點擊操作和鍵盤操作，將檢測到的用戶行為異步發送到服務器端。這可以偵測到用戶在頁面停留時間，鼠標點擊的區域等信息，由此可以推斷用戶偏好，情緒等信息。 pingback的挑戰在于如何在服務器端應對流量洪峰。pingback數據一般不直接入庫，可以先寫入Kafka，風控系統對接Kafka來分析pingback數據。

三、數據特征

用于支持風控計算的最終數據，在靜態與動態數據為基礎計算出來的帶置信度的推算數據為主的離散數據，有點繞口，我們詳細分析下這里涉及到的幾個概念，來說明最終用來支持風控計算的數據有什么特征。

1.?靜態數據與動態數據

上述采集到的數據，大部分是靜態數據。也就是這些數據一旦產生，一般不會被修改。但在分析時，還需要一些易變的動態數據來，比如用戶的 年齡，每天的訪問量，每天消費金額等。

2.?原始數據與推算數據

不管靜態還是動態數據，他們都是從用戶輸入或者系統采集的方式產生。但我們知道，互聯網的數據可靠性是有問題的。網上千嬌百媚的姑娘，在現實中可能是一位摳腳大漢。雖然系統中設計了復雜的表格來收集用戶信息，但會提供全部信息的用戶還是很少，大家對隱私內容還是捂得很緊。

所以，在進行風險計算前，還需要對數據進行驗證和補充。這都需要借助其他數據來進行推算，這些數據被稱為推算數據。推算數據和原始數據不同之處在于它會有多個可能取值，每個值都帶有置信度。完全可信為100%，不可信為0。置信度總和為1。比如正常情況下，用戶的性別要么男，要么女。假如有個用戶注冊時選擇性別女，但經常買刮胡刀，襯衣，沒有買過女性用品，那實際性別為男的置信度就非常高。

3.?離散數據與連續數據

這是從屬性值的取值范圍來評估。比如用戶每天的訂單額，一般來說是連續分布的。而性別，職業，愛好等，是離散值。一般來說，離散值更容易做分析處理，刻畫特征，所以在分析前，需要對連續數值做離散化處理。

四、名單數據

名單數據是支付風控數據倉庫中最重要的內容。 風控系統數據倉庫建設，也一般都從名單數據開始。 名單加上簡單的攔截規則，已經可以解決絕大部分風控的問題。就算在更先進的風控系統中，名單仍然是風控中的基礎數據。在評估事件風險時，名單往往是用來執行第一道攔截時所用的數據。比如用戶交易時使用的手機是黑名單中的手機，則必須終止本次交易。

1. 黑白灰名單

大家都熟知黑名單與白名單，一個是必須阻止，一個是必須放行。 除此之外，還有灰名單?；颐麊斡糜趯σ恍└唢L險的用戶進行監控。 這些用戶的行為不是直接阻止，而是延遲交易，經人工確認無問題后再放行。

2. 更新周期

相對其它數據來說，名單數據的更新頻率不高，按天、周、月更新都有，很少有需要實時更新的內容。對于手機號，證件號等名單，一般可以采取人工更新的策略。每天評估風控數據，對確認有問題的號碼，加入到黑名單中。如果采用的是第三方名單，則需要按照第三方的要求對名單做更新。

3.?名單列表

一般來說，風控系統需要配置的名單列表有：

（1）個人名單

如下名單是必備的（后續會及時更新）：

• 央行的反洗錢恐怖分子名單
• 公安部的通緝犯名單
• 全國法院失信被執行人名單信息公布與查詢

（2）IP名單

沒有權威的IP名單。這需要在運行中積累。建立IP名單需要注意如下事項：公司內部IP，合作伙伴IP可以列入白名單列表；手機運營商的IP也要做到白名單中，封一個IP等于封掉一大批手機號；代理服務器可以列入灰名單；訪問量大的IP也可能大公司的外網IP，不能僅依賴訪問量來識別黑IP。

（3）公司名單

必備名單包括央行反洗錢制裁公司名單和工商局失信企業名單

（4）手機號名單

這也沒有權威數據，電信運營商也不會提供此類服務。支付寶正在推廣這個服務，但還沒有公開。黑名單數據需要自主收集。

（5）地域名單

央行公布的聯合國反洗錢地區名單是必須在風控時考慮的名單，其他地域名單也需要自主收集。

（6）協查名單

公檢法協查名單，接收到協查請求后，將人員全部信息拉黑。

4. 名單數據存儲

名單數據在使用上的特點：

• 使用頻率高，實時性要求高。各種名單匹配基本都需要在線上做實時計算。
• 數據粒度小，總量大小不一，但存儲空間需求都不高。大部分名單都是一些號碼表，幾個G的空間都能存儲。
• 更新頻率低。名單數據一般都比較穩定，按天更新

在使用中，名單數據一般直接存儲在內存中，或者使用內存數據庫（Redis，Couchbase）。關系型數據庫可以用來保存名單數據，但不會直接被線上應用所訪問，它無法滿足高訪問量的需求。

五、畫像數據

名單數據能夠快速發現用戶在某個維度上的異常行為。在實際使用中，存在過于簡單粗暴，一刀切的問題。比如如果限制單次購買金額為5000元，這個規則被試探出來后，攻擊者會選擇4999元來規避這個限制。畫像技術則是嘗試從多個維度來評估當前事件的風險。 比如畫像刻畫某用戶平時主要在北京地區登錄，購買習慣在10~300元之間。某一天突然發生一筆在東莞的4999元額度的消費，那這筆交易就非?？梢闪?。而這種交易通過規則比較難發現出來。 支付風控涉及的畫像包括用戶、設備、商品、地域、操作行為等。 這里重點介紹用戶、設備和商品的畫像。

1.?用戶畫像（persona）

用戶畫像是從用戶的角度來刻畫其背景和行為習慣，為判定某交易的風險等級提供支持。 用戶畫像的內容包括但不限于：

• 人口信息：一般就叫基本信息，主要包括：姓名、性別、出生日期、出生地、民族、星座等。
• 聯系方式：家庭地址、工作地址、手機、固定電話、緊急聯系人、QQ、微信號等。
• 資產特征：月工資、年收入、工資外收入、房產、車等
• 家庭特征：婚姻狀況、是否有小孩、小孩關聯、家庭成員等
• 交易偏好：交易頻率（總計、年、月、日）、交易金額（總計、年、月、日）、常用賬戶、交易時間偏好、交易地點偏好、交易所使用設備、交易物品、交易物品所屬類別等。
• 行為特征，這是和業務相關的特征。比如對于電商，關注 用戶瀏覽的物品、瀏覽的物品類別、購買的物品等。而對于視頻網站，則關注用戶查看的視頻、觀影時長、類別偏好、觀影地點偏好等信息。

對于已登錄用戶，可以使用用戶ID來識別并做畫像，但對未登錄用戶，系統需要通過設備來識別。

2.?設備畫像

一個用戶配備多臺智能設備已經是很常見的事情了。手機，PAD，筆記本，臺式機，都是常用的設備。用戶在不同的設備上的行為往往是不一樣的。有人偏好在電腦上尋找要購買的商品，卻最終使用手機來下單，因為手機支付更便捷。 對設備進行畫像，和用戶畫像類似，實際上是刻畫使用設備的用戶的特征。 此外，對于未登錄用戶，由于無法標識，也只能通過設備來代表這個用戶。設備畫像關注如下信息：

• 設備信息，包括設備類型、型號、屏幕大小、內存大小、CPU類型、購買時間、購買時價格、現在價格等。
• 交易偏好，同用戶畫像；
• 行為特征，同用戶畫像。

對設備畫像來說，生成一個能唯一識別該設備的標識，即設備指紋，是數據采集中的一個挑戰。設備指紋具有如下特點

• 唯一性，每臺機器的指紋都不同，不能重復。
• 一致性，機器指紋在一臺機器上是唯一的，不同應用，不同登錄用戶中取到的指紋都是一樣的。
• 穩定性，指紋不會隨時間變更，不會由于外圍設備變更而變更。重裝應用，重裝操作系統也應該保持不變。

我們將在專門的主題中介紹如何生成設備指紋。

3.?商品畫像

商品畫像是從商品的角度來刻畫購買或者擁有該商品的人的特性。

• 基本特征：名稱，價格，類別，是否虛擬資產，上架時間，下架時間等
• 促銷信息：價格，開始時間，截止時間
• 購買者特征：偏離這個特征越多，風險越大。購買時間分布，地點分布，價格分布，數量分布，年齡分布，性別分布等。

4.?畫像數據存儲

畫像數據有如下特點：

• 數據粒度大。一個用戶的畫像數據，成百上千個維度都正常。
• 大部分數據都是推算數據，也就是數據格式是帶置信度的，比如 {性別： 男，80%；女，20%};
• 每個維度的數據一般最終都需要離散化，比如年齡，雖然0~150的取值區間還不算稀疏，一般還會將年齡再分段。
• 數據量大。考慮到匿名用戶和設備，上千萬規模的注冊用戶，匿名用戶和設備會在數十億規模的量級。
• 數據結構不穩定。 根據業務需要會頻繁添加新的數據維度，甚至添加新實體進來。
• 數據更新頻繁。采用推算數據，每天不僅僅要計算新增數據，也需要重新計算現有數據的維度權重。
• 數據訪問頻率高。交易時計算權重，也需要使用畫像數據。

很難有一個數據庫能夠同時滿足上述的需求。畫像數據存儲需要綜合采用多種數據庫來滿足不同應用上的需求。

• 數據寫入庫， 需要支持數據批量、快速地寫入，Hbase是個不錯的選擇。
• 數據讀取庫，需要支持數據高速讀取， couchbase可以滿足這個需求。但couchbase不能存儲所有數據，這樣成本太高。 可以把couchbase作為HBase的緩存來使用。
• 寫庫和讀庫之間的數據同步?？梢愿鶕I務量選取合適的消息隊列。每天更新的數據規模在百萬及其以下，ActiveMQ可以滿足需求；而上千萬的數據，則需要使用Kafka。

六、知識圖譜

畫像是從群體和個體的統計角度評估事件的風險，而圖譜則更進一步，從關系的角度來評估風險。 知識圖譜是由Google提出來并應用到搜索引擎上，其后在多個領域都得到很好的應用。 交易是一種社會行為，所以從關系的角度來評估這個行為，能夠更精確的了解行為中存在的風險。一個簡單的例子，如果發現A是高風險的用戶，而通過社交圖譜分析，發現A經常和B有交易關系， 那B的風險等級也相應地會被調高。

圖譜在本質上是一個語義網絡， 是一種基于圖的數據結構， 它由點和邊組成的。點代表一個實體，如人、公司、電話、商品、地址等，邊代表實體之間的關系。

如上所示， 如果A和B兩人之間是夫妻關系， 則在圖中， A和B分別被用一個節點來標識， 稱為實體，他們的關系是 is_wife_of。對電話、出生日期、出生地點、公司等，也可以使用這種方式來表示。 圖譜的表達能力，不僅在于描述實體之間的關系，而且通過關系還可以推理出潛在的進一步關系。 比如A是B的母親， A是C的妻子， 則有很大的概率可以推斷出來C是B的父親。 支付風控需要像建立畫像一樣建立圖譜，需要支持包括人，機構，地區，日期，電話，手機號，設備，商品等實體，以及實體之間的關系。圖譜數據源也是和畫像一樣。此外，還有一些互聯網數據也有利于建立圖譜 百度百科，有很不錯的公司，明星，電影，音樂等信息，一般僅限于國內或者中文版本的資料。由于編審并不嚴謹，數據質量不高。 wiki，有各種語言的版本，提供各種領域的實體，參與的專業人士多，質量較高。 各專業數據庫，

知識圖譜是基于圖的數據結構，它的存儲主要是使用圖數據庫。關系型數據庫和Hbase等nosql數據庫在處理圖的關系以及關系計算上性能較差，需要專用的圖數據庫，當前主要的圖數據庫有neo4j，Titan,Jena等。neo4j是使用最多的圖數據庫，而且可以和spark graph集成，方便對圖譜數據做處理。

七、總結

總結一下，本文將風控系統所需要的數據分為名單、畫像和圖譜三個主題，這三個主題也對應了風控系統發展的不同的階段。這里列出了每個階段所需要的典型數據，以及這些數據會如何存儲。風控系統會如何使用這些數據，將下一篇博文中分享。

系列文章

支付風控系統設計：支付風控場景分析(一)

作者：鳳凰牌老熊，程序員 & 架構師

本文由@鳳凰牌老熊（微信公眾號：shamphone） 原創發布于人人都是產品經理 。未經許可，禁止轉載。