挖財基于大數據的信貸審批系統實踐 http://mp.weixin.qq.com/s?__biz=MzA5NzkxMzg1Nw==&idx=1&mid=2653160720&sn=ff68736133fc4d19c24dcae62879286e
基于大數據的信貸審批系統 http://www.infoq.com/cn/presentations/credit-approval-system-based-on-big-data/
挖財基于大數據的信貸審批系統實踐-大數據雜談-大不六文章網(wtoutiao.com) http://www.wtoutiao.com/p/35fHgsZ.html
審批決策的規則相對比較簡單，這里選用了Groovy和QLExpression規則表達式，它們不能作為規則引擎，跟Drools比Drools比較重而且比較商業化，我們用Groovy和QLExpression主要考慮的因素第一個是性能，大概有10倍到50倍的提升，第二個因素是Groovy和QLExpression對程序員和稍微會excel的editor這些人非常友好，其實我們也不需要Drools那么多比如說rule dependency或者是一些復雜rule等東西。
本文整理自ArchSummit深圳2016的演講，公眾號后臺回復“信貸”，下載完整版幻燈片。關注我們，獲取更多干貨~
大家好，今天給大家帶來的分享是基于大數據的信貸審批系統。首先先自我介紹，我真名是曹靜靜，花名是叫曹寶，早期在淘寶的數據平臺做海量數據的中間件，然后在Morgan Stanley的全球清算中心任職，之后去Ebay搭建了一個億萬級的廣告的大數據處理平臺，聯合翻譯了Scala函數編程，這本書的話大家有興趣可以去看一下，本人也是Scala和Spark的愛好者和推廣者，現在就職于挖財信貸部門作為研發負責人和資深架構師，負責整個挖財信貸的基礎架構和挖財大數據風控平臺。
我首先會先解釋線上信貸和傳統信貸有什么區別，接下來的分享內容會分四點：
我們做線上信貸會面臨怎樣的挑戰，面對這個挑戰如何設計信貸的系統架構；
整個信貸分為貸前、貸中和貸后，我今天的分享主要會側重于貸中和貸后的系統設計，最后會聚焦在貸中的審批系統設計；
其次如何做好線上信貸，我們會用到大量的數據，這些數據如何加工處理使之服務于我們信貸的整體系統；
既然有了系統和平臺，我們怎么樣把他們結合起來讓它們發揮更大的作用。
線上信貸業務
這張圖介紹了現在線上信貸業務和傳統銀行業務（或者最早的小貸公司業務）之間的區別。線上信貸業務有一個比較非官方的定義：進件、電銷、電照、審批核、放款、回款、催收等行為均發生在線上，意味著我們都是用我們的系統來去處理這些事情；傳統銀行大家可能知道大部分行為都是人工操作，比如去進件然后地推，接著審批核有專門的人去收集資料，大家貸過房貸就知道這件事情了；目前一些小的P2P公司處于混合的狀態，即部分流程會放到線上。
各維度的特點：
用戶特點：線上貸款的用戶特點是什么？我們有海量的用戶也有非常豐富的接入場景，例如現在的線上貸款可能有2C或2B，甚至有對小貸公司的貸款。我們會有H5即簡單的web的頁面這種獲客方式，也會有SDK、nativeApp和API的接入方式，對于整個系統設計而言接入方式是非常多的。
數據特點：線上信貸業務的數據特點比較復雜。我們有多樣的數據獲取方式，比如我們有數據爬取、第三方的合作、自己的抓取收集等等；數據格式有結構化的、非結構化的、文本類的都有；數據種類比如電商類、網銀類和市政類的數據都有。
貸中貸后的特點：我會分為三大塊進行描述：多樣的貸款種類、高強度的審批核和高度的自動化和智能化。
決策特點：整個線上信貸業務要做到實時的反欺詐，快速迭代信用評級和高效的專家系統。
信貸業務如果要把它互聯網化，那下圖應該能夠更好地反映它，即我們要往哪邊走，往這邊走我們會遇到的困難是什么？如果是階段1，我每個月要放款1億，我的核心人員如果是100個人，這100個人包括研發、催收和審批核人員等，這樣也許很容易做到，只要借助于一些系統的開發應該就能完成，但如果你要做到階段2一個月放款10億，如何保證核心人員也能維持在100人？階段3的100億呢？在這前提下做出來的東西我才認為是互聯網帶給我們的紅利，在核心人員不變的情況下我們的業務可以實現線性的增長。
怎么樣做到這一點，我總結下來有兩條：
進行深度的數據挖據，這里會涉及到方方面面，我們會怎樣借助搭建一個數據平臺來做深度的數據挖掘；
在深度挖掘的基礎上怎樣build一套高效的信貸系統，這里會側重一個高效的審批系統，當然智能催收、精準營銷也同樣重要。
信貸系統結構
首先線上信貸的系統架構，這里總結了非常關鍵的三個階段：
一開始如果我們要開展一個業務，我們可能選擇最快的方式——外包，我們會把一些審批系統、核心系統外包給別的公司或者去買一個能夠迅速上手的系統，這樣帶來的問題其實也是我們血淋淋的教訓，雖然能夠快速上線業務但其背后會帶來復雜的維護成本，而且我們數據服務的集成基本上是不可持續的；
隨后我們自然而然進入第二階段——自主研發。大家可能會問研發一套系統的周期要多長，我們最早采購的那些系統其實都是專業做了很多年的系統外包，是有相應的一個銀行同業經驗開發出來的系統，但是以我們的經驗來看，只要滿足你的最小需求，其實一開始設計這個系統可以盡量地按照你的需求定制化，這樣的開發周期不會太長，自行研發的系統的高擴展以及和你的數據服務的集成也是最好的；
第三階段其實也是最核心的階段，剛才我說到如果每個月放款100億，你怎樣能保持你的核心人員能保證在100人左右，這時候你們就要進入輸出階段，所謂的輸出階段就是將你的能力和你的系統外包到外面去做，即選擇更低廉的人力成本去完成你的業績（例如每個月放款100億），這就要求你在自行研發階段時對整個系統架構以及對它的權限體系在自己心里都有統一規劃，有這樣的規劃到輸出階段你才不會顯得那么突兀和忽然對整體架構有那么大的沖擊。
我們設計的貸中貸后系統可能日處理量在上萬筆或者上十萬筆，這里大部分都由機器來做決策，少部分還會涉及到人工處理，怎么樣能夠更好地做到分單，其實在催收、審批只要涉及到有人工處理的地方都會用到分單，審計也是必不可少的。
在下圖第二層（即藍色的部分）有權限管理、審核和深藍等等，深藍會重點說，因為它是提高我們審批核人員人工審批的一個關鍵要點，它是怎么樣做到讓人工能夠更好地利用數據做審批。在這一層大部分都是web服務，它們大部分都是作為一個單獨的web IP暴露出來的；最上面這一層我們把所有的服務集成一個工作臺，在這個工作臺所有的業務人員（涉及到貸款方方面面的人員）都可以在上面做操作；中間有一個非常關鍵的一層稱為Desicison Node，主要負責一個貸款在貸前、貸中、貸后所有流程的管理。
接下來下圖談到如何讓機器來代替人去做決策，我們做的線上貸款怎么樣能夠提高我們的審批、審核人的效率，怎么樣提高我們催收的效率。審批審核如果一天一個人能審100單其實蠻不錯了，這效率已經很高了，但如果讓一個人一天審500單那基本不可能，我們就提出了這樣系統的構建過程：
深藍系統大家可以認為它是一個Data Hub，是審核人員所需要的所有數據的集市，在這邊以非常友好和高效的方式呈現給審核人員；
規則和模型是我們包裝的自動化審批過程的process或者service，當人和機器他們混合做決定以后他們的結果會到我們的審批決策這個Desicison Node里；
電照和審核是一些輔助系統，一般情況我們是需要和對方溝通驗證一些資料的；
審批決策的規則相對比較簡單，這里選用了Groovy和QLExpression規則表達式，它們不能作為規則引擎，跟Drools比Drools比較重而且比較商業化，我們用Groovy和QLExpression主要考慮的因素第一個是性能，大概有10倍到50倍的提升，第二個因素是Groovy和QLExpression對程序員和稍微會excel的editor這些人非常友好，其實我們也不需要Drools那么多比如說rule dependency或者是一些復雜rule等東西。
重點要突出的是：不是人最后去做決定而是機器規則去做，為什么要這樣設計？其實考慮到人的比重會越來越小，大部分的decision都會慢慢的transfer到規則和模型這一塊，在業務架構上就需要預先體現這點。
接下來講深藍系統，下圖是我們深藍系統的截圖，可以看出這其實是相當簡單的一個界面，為了提高效率我們做了一些設計，這個系統目的是讓審批核人員用這個系統能夠快速地做出決定。比如有人過來申請貸款，那我依據什么來給他批這個貸款？其實就是數據，數據通過這個系統呈現給審批核人員，系統會將不同的數據進行分類，同時我們還會有匯總的信息，比如我們有兩份風控報表和反欺詐報表，我們還有灰名單、黑名單，一些敏感詞等數據，這個web page上的detail部分會有很多的信息，我們會將關鍵的信息高亮來提示審批核人員。這個系統上之前我們的審批核大概一人是50單，上了之后有double的效率。
下圖是我們審批系統的prototype，審批系統現在正在開發過程中，它的主要目的是把各個信息匯總，不光是審批人員的信息，還有我們規則模型跑出來的結果，還有這個人審批的歷史記錄，在這系統都會以一個非常詳盡的報表形式展現給我們的審批核人員，讓他們因此做出一個decision。
先大致介紹我們信貸審批系統，后面的重頭戲是大數據，我們是怎么基于大數據去玩這件事情，我們是怎么樣去基于大數據做數據挖掘來讓我們的審批系統變得更智能。
數據平臺架構
說到數據平臺架構，其實信貸領域數據平臺的架構和電商數據平臺的架構不太一樣，但技術上可能有共通，這里不一樣的點是從一個數據平臺要解決的需求和我們要用的場景是什么。對一個成熟線上信貸業務而言，它的數據種類有很多種，大概總結為以下：
社交類：比如你的通訊人，通話記錄，QQ好友、微信好友等；
網銀類：比如今天消費的銀行流水，credit card欠款情況等；
電商類：比如在淘寶、京東、一號店上的買賣信息；
市政類：比如公積金繳納、社保情況等。
數據格式千奇百怪，剛才我已經提到的文本類的數據，結構類的還有半結構化的數據等等。服務場景重點說一下，對一個信貸的大數據平臺他的服務場景有四類：
申請，這個數據平臺在申請階段時就要起作用，所謂申請就是當你在一個App或者界面進行申請的時候我們的實時反欺詐就先起到作用，然后擋住一部分人；
審批，基于規則和模型的自動化審批。之前也提到部分審批系統是一個人機混合的過程，雖然是人審批，但是人也是基于大數據平臺給他計算出來的數據去進行快速抉擇；
催收，大家可能知道整體的經濟形勢，投資會慢慢地向保守的狀況走去，其實從這個角度來看催收可能是后面大家非常看重的點，也就是說怎么樣能夠讓用我們的數據讓催收變得更高效，其實也是這個數據平臺的需求；
分析建模：最后一點要highlight一下，當大家都在說Machine Learning或者基于規則的去建模，這些東西都要我們數據科學家或我們的數據分析人員去分析建模，這也是數據平臺的需求，如果你沒有好的平臺怎么完成你的模型訓練和最后的上線迭代。
基于這幾個需求其實已經對整套系統的設計提出了相應的技術要求：
數據管理，
多源導入導出：因為數據種類和數據格式多，所以我們需要多源的導入導出，稍后會舉例說明如何導入導出；
統一的Schema和類型系統，這點很重要，因為你的數據存在于MySQL、MongoDB、HBase和HDFS等以各種形式存在。大家都希望一份data可以滿足所有需求，比如說Ad-Hoc Query 、real-time compute、batch compute, 但按照現在的技術這是不現實的，所以同一份data有可能有不同的存儲形式存在，這要求我們統一Schema和類型mapping的系統，這點很關鍵，這樣可以解決每個人在開發對同一張表的不同存儲和開發自己的data mapping的問題，而且這種data mapping是日常中最容易出錯的地方；
數據質量實時監控：這點也很關鍵，不管你的模型和你的規則有多好，但如果你基于一個比較糟糕的數據，用最經典的一句話解釋就是Garbage in Garbage out（垃圾進，垃圾出），比如大家成功爬取一個人的網銀流水，你怎么知道這個人的網銀流水成功了而沒有在中途丟掉一條網銀流水？或者在中途沒有爬到網銀流水是因為System Failure獲取出錯了還有因為這個人真的沒有消費記錄？想這些東西的話你必須要有一個數據質量的完整監控，而且要做到實時；
按需的存儲結構，申請服務場景大家需要一個實時服務，而對審批和催收可能需要準實時，基于內存和多索引的存儲可以滿足實時服務，但成本也較高。同樣，準實時可以采用內存和磁盤 share的存儲系統，而成本最低的就是 HDFS文件存儲系統了，這時你面對的是離線計算任務。
服務分級，大家可以看到我們對不同的服務場景分了三種服務等級，這個是根據計算服務的最少可用時間（SLA）定義的：
實時：我們規定是小于1秒，基本上是200毫秒到500毫秒之內完成；
準實時：小于5分鐘；
離線：大于5分鐘
計算框架
SQL Based，選型也很重要，這么多年大家也知道各種編程語言例如Python、Scala、Java、C++的數據處理，以我看下來效率最高的其實是SQL Based，它的受眾不光是研發人員還有我們的數據分析人員他們都會很容易地去提高效率；
Lambda架構，Lambda這個結構來源于函數式編程思想，類似函數式編程里閉包的概念，當然在大數據里應用的話最早提出來的是Twitter的一個project叫Summingbird，用簡單的話去描述就是把你的計算邏輯看成一個function，而你計算邏輯可以apply不同的場景，它可以是實時的也可以是離線的，你不需要去修改代碼就完成同一套計算邏輯在不同場景下的計算。
ML Pipeline，在進行機器學習訓練過程中，調用指定的算法比如Decision Tree、Random Forest（隨機森林）、SVM，這只是完成了全部工作的10%，其它大部分時間是在做數據準備、特征工程等這些操作，Pipeline的概念就是要把這些操作全部打在一個管道里，然后訓練完模型后將這些操作和參數都序列化到磁盤上，當需要進行 prediction時，這個pipeline是可以直接被使用的（反序列化），我會解釋為什么要去考慮這個問題；
Storm：我們采用這個Storm（有JStorm，然后最近的Twitter的Heron），Storm這個東西在實時場景還是非常推崇的，因為在過去的一年多中大概有6-7次的機房故障，Storm這個集群基本不用太多人干預，它相當的穩定。
接下來給大家一個引子——黑名單，大家做信貸的話都會知道黑名單這個概念，提到黑名單大家背后都有很多的事情：
黑名單的來源，大概有三類：
人工的錄入，打標，比如你們的催收專員、審批核專員他們今天打來電話說有一個人實在催不回來了，那么就把他mark成黑名單；
聚類或圖計算生成，這類用到的算法有K-Means、Graph Shortest Path（最短路徑），還有Graph Centrality ；
第三方的合作，批量導入，大家如果從事信貸這個領域就知道很多征信公司和提供征信服務的公司以及小貸公司大家對黑名單這一塊會做到一個market市場，大家會互相交易一些黑名單。
黑名單的使用場景，其實上述來源三點也正好也貼切了這三個場景：
貸前申貸過濾，我們對于欺詐類行為的人就直接在前面就擋掉了，其實就跟支付安全是一樣的道理；
貸中審批關聯性標記，這里用了一個關聯性標記，其背后隱含了很多東西，用黑名單舉例，我有個key-value store ，你過來一個人我命中了他的身份證，或者命中了電話號碼，但這往往對團伙欺詐或者是比如在圖里面有二度了（過來一度又過了一度）這種Case，其實這種的match不是很容易被發現，那這時候就需要做一個關聯線索。拿最簡單的例子：你是一個黑中介，你的手機通訊錄里存了很多人，然后我又是通過你來去申貸的，我的電話薄里面也存了很多人，這時候咱倆用電話號碼去match肯定是不一樣的，但如果我用我的電話薄和你的電話薄去做match，這個match可以以一個比重進行衡量，比如兩個set的交集比上并集大于60%就可以作為一個指標來標記你們是關聯的，這個關聯性相當有用；
離線的模型訓練，這里需要大量的黑名單或者是白名單去作為我們的規則（比如決策樹）的輸入。
對應上面三種使用場景，我們也提出了三種計算要求：貸前必須做到實時計算，貸中我們要做到近實時計算，離線黑名單生產其實做到daily就可以了；
算法涉及到K-Means、word2vec、Graph Centrality等這些都是圖計算和聚類算法，他們主要用來生成我們的黑名單，這里值得一提的是K-Means和圖的最短路徑現在已經有online版本了，可以不用做24小時的等待時間去訓練去找到這個黑名單，你可以online用一些算法，這個Spark也有個很好的支持；
規模，我們現在規模是1000萬的用戶，1000萬其實只是一個起步，1000萬大家可以算算，單機已經不能滿足我們的要求了；
擴展，例如從黑名單你得出的灰名單是什么，我的敏感詞是什么等等，其實都是一樣的Case。
基于這個引子我們來看我們的數據平臺設計，下圖是我們數據平臺的架構，大家會看到我們做了服務的分級，基于redis上面有codis，它是redis分布式管理的框架，最早由豌豆莢提供的，現在已經開源了，這個框架用起來也是相當簡單，對ops很友好，在它上面我們做了一個Storm的集群，主要用來服務于貸前的需要在500毫秒之內有響應的計算框架。
第二類的計算框架就是我們的近實時，這里主要是模型prediction——也就是我們貸中的審批核，然后一些模型規則在這里面跑，主要是小于5分鐘，我們主要采用Spark Streaming加上Spark SQL，這里涉及到的計算有規則的預測、模型的預測還有準實時的報表，這里我們使用了HBase和Phoenix作為storage，HBase這邊給大家的建議是如果用HBase作為solution，最好有一到兩個人對HBase相對比較了解和有比較深的建樹，日常 HBase的運維還是有很多的，例如region compact、split等。
Phoenix是什么樣的東西呢？他在HBase的key-value storage提供了SQL wrapper，即你在上面就可以像寫SQL一樣去操作HBase,然后performance大概有1%到5%的下降。Phoenix上可以使用buildin的方法去建二級索引，你可以建更多的索引（性能下降較多），里面用的是HBase的Coprocessor概念去實現的。
但是大家使用Phoenix的時候也要特別謹慎，因為它的類型系統和HBase的類型系統其實不是統一的，也就是有一個mapping在里面，一旦你用到它了你的所有數據需要盡量從Phoenix入Phoenix出，而不是一邊使用HBase，當然Phoenix也是支持HBase的物理表，Phoenix有view的概念，但這樣操作并不是很友好的，所以大家使用Phoenix還是需要謹慎，它的侵入性比較強，一旦用上了他對你的整個ecosystem就必須要用Phoenix去做，可以替代的方案大家可以考慮用ElasticSearch來做相應的事，如果你的索引特別多的話。
第三層是我們的離線計算，它主要服務于我們數據的清洗、聚合、feature提取、預計算、模型訓練和報表，這里我們用HDFS+Hive，著重提一下我們并沒有用原生的MapReduce+Hive，它的計算框架已經替成了Spark，因為在一張大表（大概是5t到10t的規模），我們跑過benchmark，大概Spark SQL離線要比Hive SQL要快十倍，如果你再用上Parquet列存儲storage的話你的性能會更好。
大家可以看到我們大部分用的是開源的東西，對創業公司或2000人以內的公司來說這些開源的項目是最容易上手，但是用這些開源的東西我們自己也要開發相應的東西，有哪些東西呢？
Schema管理（mapping），剛才提到我們已經有太多的system，例如Spark DataFrame、HBase的storage、HDFS的storage、redis的storage，如果一張表從Storm或者HBase都有，那我必須要有一個consistent view ，前期如果有Schema管理，然后到不同的storage system來做mapping，會對你后面的開發以及對整體容錯率會大大提升；
Exporter，這個很重要，大家可以看到我們的數據源有MySQL、API Gateway、FTP Gateway、HTTP Gateway，如果有統一的exporter那么可以從這些源分別導入到這幾個地方；
Scheduler，即任務的管理，包括定時的日任務和 Streaming的服務。
Monitor****，監控包括系統錯誤和數據質量。
以上東西都要自己去開發。甚至有些需要你做plug-in的東西。
再說一下兩個應用場景數據平臺：
我們使用Apache開源的Zeppelin，大家如果不做一些數據分析可能不是很熟悉，打個比方更像數據庫的DMS系統，不過它更powerful可以做到數據的分析、報表的展示，然后還有個交互式的一個input output；
我們有EP的實驗平臺，主要面向我們的數據科學家。
下圖是Zeppelin的官方介紹，它服務于四塊：數據消費；數據發現；數據分析；數據展示，還有collaboration，這塊很有意思，因為他是一個sandbox，你有一個想法或idea想要嘗試，你可以配不同的interepter，你可以配Java、Scala，或者配SQL、Phoenix等等，也就是說你可以嘗試不同的計算方式，然后生成Markdown文件，這個Markdown你可以在中間添加詳細的描述：你這一步要做什么事情，代碼是什么，輸出的結果是什么，然后下一步又要做什么事情。做到了以后你和你的team member可以用它去做交互：我這邊有個idea或者我這邊做了個東西，你看我的Markdown然后就可以直接play。如果大家去上Spark Campus的訓練營，那邊會有Spark NoteBook，圖上只是開源版本。這個東西還是非常好用的。
這套系統對權限的隔離現在做得相當不好，而且有些小的 bug，所以我們后面也是做了一個CMS的單點登錄的認證并 fix了些 bug。此外開發了下載，上傳并建表的一些功能。
下圖是一個例子，MySQL的Importer in Zeppelin，我們做了一件事：我把我的最主要數據源MySQL里面一張表或者多張表導入到HDFS，形成我的parquet文件，parquet文件大概描述一下就是列存儲，大家可以認為它是把schema和data存儲在一起。
這里的代碼基本上是所有的代碼，大概34行到40行就完成了一個非常通用的MySQL的表到HDFS的導入過程，大家看到下面會有些輸入框，這也是我剛才說的它的交互非常好的地方，你在這邊只要申明幾個變量然后用這個函數（嵌入函數z.input()），下面這些交互框就會有給到你，你要run它的時候只要在下面填入你的參數，比如表名是什么，然后并發度是多少，然后基于哪個key去做partition在這邊都可以填，其中的性能我們測過是相當快的，很快地就可以把這張表load到你的HDFS上面。
下圖展示了我們二次開發的系統，主要是統一schema，統一schema其實有兩種方式：我有MySQL的schema，也有HBase的schema等等，那我們采用 jdbc sql type來作為一個central來讓它們之間mapping。
我們多次編程后總結下來這些系統其實都是SQL-Based，意味著我們可以用JDBC里面的type system來定義，上圖的表有很多列，它的schema type我們叫做Spec，即central的類型系統，這個類型系統里定義的都是我們的JDBC的type system，然后你會看到我們有Phoenix的JSON、MySQL的JSON等等，比如這張表定義完了以后你想match成Phoenix的，只要點相應的schema，那么這段schema就是可用的。當然這也有API的接口，可以直接編程拿到它的schema。
下圖是我們系統里的實時的數據監控，MySQL的數據都會通過Kafka被我們消費到HBase system，這個消費是實時的，在這個實時的過程中任何一批數據里面出現失敗都會在這個界面顯示，而且會和我們的報檢系統去聯動，我們想看到的在這個消費流的過程中，我們的一條數據都不能出問題，我們不能因為數據的質量導致我們后面的規則和模型不可用。
上圖中的row key 、raw JSON就是Kafka的message，我們存到HBase里面大家會看到有很多條，然后fail了15條，大家可能會問為什么要這么詳細，因為整個系統build的過程中一定要有工程化的思想，即我們要第一時間上來發現問題，要知道哪些key出了問題，然后我們才能夠繞過整條流程，從我的sources直接拿到我的數據去做訂正。仔細想想這個過程：我從MySQL到我的HBase的過程中，中間其實是復雜流的處理過程，如果出錯了，你的訂正其實是要拿著這個出錯的最關鍵的信息找到你的源數據，然后繞過這套復雜計算邏輯直接訂正到你的目標的一個HBase的存儲里面。
下圖是Job配置，這是online的Spark的streaming process，大家可以看到我用了Mesos Job配置。重點說一下，Spark是可以跑到YARN或Mesos上面，為什么我們把它的實時的計算放在Mesos上？因為Mesos對于異構的Job兼容更好，即我可以不跑Spark，我在這個Mesos的集群上可以跑我自己的微服務比如Spring Boot的實時服務，我也可以跑Storm服務，我甚至可以跑其他的一些實時計算。如果你用YARN的話對整個開發的友好程度可能就會大打折扣了。
下面重點說下整個信貸中貸后最大的一塊數據挖掘，它是由有一定的銀行背景的數據科學家或是有一定數據挖掘經驗的人來從事的，下圖展示的是他們現在的工作方式，這工作方式也是typical的現狀，也不一定只是挖財的一個現狀，即數據科學家在對一個規則的產生和一個模型的訓練往往會經過多少步。
可以看到當一個需求提出來時我們會定一個指標，然后數據科學家首先要去了解數據，即需要哪些數據和變量，了解了這些數據以后他會有excel給到我們的數據工程師，由他們去開發這些變量，這個過程大家可以理解為開發feature然后導出feature，然后給到數據科學家，他會load feature，然后做本地的訓練，這里面本地的訓練可能用到Weka、Scikit-Learrn或者是SAS，然后在本地速度調優，最后這一步數據科學家的產出會是什么？訓練完的一個模型你可以認為是具有規則的比如decision tree、if-else這些東西，然后給到算法工程師，算法工程師拿到的這些模型以后再去開發相應的算法，再去開發一套實時的feature，注意這和剛才的離線feature是不同的，這是兩套邏輯，最后這個模型才上線。
整個過程中大家會看到有涉及到三類人，當然這三類人不光有分工的問題而且還有數據的copy問題，最讓人可能會容易出錯的或讓人會覺得比較摸不到頭腦的地方可能是開發feature的這個計算邏輯，為什么到你算法上線的時候你還要去開發一套實時的feature計算邏輯？這套東西非常容易出錯也就導致數據科學家在train一個model，train完result然后提交上線時，他往往不會很trust，他會覺得你們的input是不是我當時訓練的那部分數據集。這里引入了別人的一句話：數據科學家80%的時間在準備數據，20%的時間其實在埋怨這個數據其實不是我想要的。
我們在想怎么樣能夠讓我們的模型迭代更快，因為整個征貸市場的風險變化非常快，我們怎么樣讓我們的模型規則能夠最快的上線，因此我們提出了假如我們只有數據科學家沒有數據工程師和算法工程師，我們應該怎么玩轉這件事情？
下圖是我們開發的一套系統，大體架構是這樣的：我們基于Spark的ecosystem搭建了一個上層的系統。之前提到的Zeppelin主要承載了數據科學家前期的數據調研，即data discovery、data exploring、data analysis，另一邊是data experimental platform（實驗平臺），承載的是feature engineering，包括feature的變換、一些簡單的feature的處理即feature的工程化，還有model training、model selection和model testing，最后數據科學家把這件事情完成一個model串完了以后要做的是發布，發布時他會做一個A/B testing setup做一定的灰度，然后會在線上的結果result收回來后不斷地去調優反饋這個系統。
發布是在我們的Rule Service里面去做，我們的Rule Service會有model deploy online prediction，我們在實驗平臺上不會做模型的預測，只會做離線訓練和我們的實時prediction的result的返回。
能做到這個一定是基于下面這幾個關鍵的點：
Lamada的架構，一個feature開發在離線訓練階段可能由數據工程師基于一套邏輯開發，實時的prediction由我們的算法工程師去開發，怎么樣能夠用一套代碼把這兩個東西做完，其實就是用的是Spark Batch Streaming即Lamada的架構；
模型訓練，有ML Pipeline，其實它在模型的上線也會用到，你可以認為你訓練出來的結果就是pipeline，整個pipeline都可以save到磁盤上面，在另外的Rule Service做prediction時，你可以把整一個pipeline從磁盤上解序列化出來，然后load到你的內存然后就可以預測了。
基于這套系統的幫助我們是想讓我們的數據科學家或者是數據分析人員變得全棧化，所謂全棧化大家都知道帶來的好處就是我們可能減少更多的錯誤，減少我們的數據copy，節省更多資源，提高我們的迭代速度。
下面簡單介紹一下Spark Pipeline，舉一個最簡單的一個例子比如一個text文檔過來，你要去做成一個Logistic Regression Model，那么第一步做分詞，然后做TF，然后做Logistic Regression，這部分是train，train完了以后這套東西的東西可以save到硬盤上，當你需要使用時，只要從硬盤里把這個load出來叫做pipeline model result，然后feed它raw text時你就能得你的prediction，即你的result。整套過程其實Spark已經做得相當好了。
下圖是Zeppelin做的一個小的example，這是Spark上面的一個代碼，Spark ML是2.0以后才來的，那2.0之前1.6這個版本相對比較穩定，用的MLlib這個package，最大的變化是把一些接口做了調整，把一些pipeline更加加強。這邊主要想展示的是用Spark去做一個model的train以后，如果大家有ML background的話，可以看到Scikit即python最經典的單機版的分析ML library，它代碼行數層次是在同一個層次上，這里面使用Scala去寫，也可以Python去寫，這其實已經非常精簡了。
最后說下有了我們的數據平臺，有了我們信貸的一個中后臺系統后，我們還缺少哪環可以讓這兩個事情能夠更好地結合在一起？
數據+系統融合
我們有很多系統融合的地方，其中我選了四點：
狀態流，我們數據來源大部分是數據的爬取、第三方獲取，這些數據最早都承接在MySQL的一個業務庫，然后到我們后臺是一個離線的大數據分析或者實時大數據分析，這是異步的數據同步過程。這本身就是一個矛盾點：我要服務于線上，那需要一個同步調用的過程，我要知道所有的數據ready了才能去跑我的模型，才能去做prediction，但是我的數據又是不同的存儲系統，數據傳輸又是異步的，所以這邊狀態流很重要。也就是說你build的一套狀態機制去管理你的數據告訴人家：這個數據是不是ready了，你期望這個數據值是不是已經在你要計算的這個平臺已經OK了；
行為收集，之前給大家展示的那個深藍系統里其實是有隱式和顯式的行為收集，所謂隱式的行為收集就是當審批核人員在做任何操作的時候我們對他的行為做check，這個check有兩個目的：
我們要規范審批核的標準，也就是當你一套政策布置下去了以后其實每個人的手的寬緊度是不一樣的，每個人對每個資料的感知也是不一樣的。但這種情況下其實你通過一次次的培訓，你可能會達到效果，但更多的我們是想通過一個隱式的feedback，然后再回過頭來去看大家在某個點上是不是是有疑惑；
隱式的行為的特征會被我們轉換成自動化流程，也就是說我們可以繞掉一些人工的步驟。
機器到人，人再到機器，這點蠻有意思，這個過程中當我們需要去做數據，需要用數據去預測一個模型的時候。這個時候我們會計算出來不同的指標，但是這些指標和規則可能我們還沒有驗證過，可能就像Machine Learning里面一個冷啟動，那這時候我們怎么辦？我們有一堆的審批核專家，這時候我們其實要利用到人給數據打標，根據這些專家的一些反饋然后這些打標最后反饋到機器，才會變成我們的規則和模型，這就是所謂的機器到人，人再到機器；
最后一點是規則可讀，我們不需要非常復雜的Drools，我們只要最簡單的Groovy和QLExpressin，第一個性能比較好，第二個就是說我相信大部分的業務人員現在對excel的表達式也很熟悉了，在這邊已經可以滿足大家edit。
下圖是我們之前提到的狀態管理，上面是我們數據的收集，我們有爬蟲，有native data，有三方數據，然后這些數據都會異步的到HBase，HBase會承載了我們模型的prediction，圖中藍色的框我們會收集我們Data State from Kafka，最后模型的調用過程中會有個State Checker不斷去pull這些data，然后決定什么時候可以調模型，或者我們有個timeout，這個數據就沒有ready你就不需要去調模型，因為你一旦調了模型這個prediction result是一個非常不靠譜的結果，而且大家不知道問題出在了哪。
下圖是機器到人，人到機器的圖，你會看到我們大部分的機器都是由Rule Service去提供機器審批，這里有feature有model prediction，深藍是給人使用的一個data hub，就是審批人員在這邊做的所有的操作都會通過我們的顯式的專家意見收集和隱式的行為搜集不斷地沉淀，最后到達Rule Service里。
下圖展示的是我們的可視化規則，就是Groovy和QLExpressin，寫這個語言非常大家很容易懂。
最后是我們的prototype，我們正在開發的專家打標系統，大家可以看到最下面這塊比較多的是我們的raw data ，上面這塊是我們給它計算出來的一些我們認為比較靠譜的值，當然這些值我們還是會讓它再去confirm一次，我們要把計算出來的結果、它的raw data、它需要打標的結果統一地收集下來也就是完成一個顯式的專家打標過程。我的演講結束了，謝謝大家！
講師介紹
曹靜靜，資深架構師，現任職于挖財信貸部研發部。先后就職于淘寶數據平臺，摩根斯坦利 OTC 清算中心，ebay 廣告數據平臺。Spark&Scala 布道者，聯合翻譯《Scala 函數式編程》，參與組織杭州Spark Meetup。
Financial Technology（金融科技）并不是只在國內火熱的概念，在國外面向Fin-Tech而生的金融科技公司隱隱有挑戰傳統金融代表——華爾街的意味，披著互聯網外衣的Fin-Tech公司如何利用一系列創新手段使得金融服務變得更有效率，如何引領瓦解傳統且不夠科技化大型金融企業和體系的趨勢，ArchSummit北京站已邀請財貓金融 CTO巨建華擔任“Fin-Tech”專題出品人，點擊原文閱讀來現場和一線技術大咖交流討論金融科技的未來發展。
