文章整理：加米谷大數據
近年來，隨著大數據與人工智能相關技術的迅速發展，新技術逐步在全社會各行各業得到應用。銀行業作為一個高度信息化的行業，首當其沖面臨著互聯網新技術應用的挑戰。民生銀行在 2013 年開始布局分布式、大數據及人工智能技術等領域，在全行鳳凰計劃的牽頭下，逐步的將新技術與我行發展戰略業務實施策略進行了深度融合，為金融科技銀行的發展奠定了扎實的基礎。
一、大數據簡介
大數據起源于互聯網，在 2003 年左右由 google 發布 GFS 和 MapReduce 論文為節點拉開了新技術應用的序幕，介紹了一種利用普通 PC 服務器構建大規模分布式系統，來解決海量數據的存儲和計算問題。在此論文基礎上發展出來的 Hadoop 開源體系逐步成為海量數據處理的一種通用技術框架。2008 年左右 Hadoop 技術被廣泛的使用在各個互聯網企業中，極大的推進 Hadoop 技術體系的成熟，隨著早期 Single Point of Failure 問題被解決，在 MAP-REDUCE 兩階段的計算模式上，誕生了更豐富的 Spark、Flink 等計算框架。2013 年左右批量數據的計算模式逐步成熟，在需求的推動下互聯網開始進一步的攻堅實時數據計算領域。同年部分銀行開始嘗試引入 Hadoop 大數據技術。民生銀行作為銀行業第一批，在 2013 年從互聯網引入了大數據專業才人，啟動了 Hadoop 大數據體系化的建設。
新技術的應用首要是解決問題，提高數據使用的效率，降低數據使用成本，最終推動業務數字化、智能化轉型。在大數據體系化規劃下，以服務用戶為目標，以解決問題為抓手逐步推動大數據技術落地。民生銀行大數據整體規劃如下圖：
圖 1、大數據平臺體系規劃
在整個規劃的指導下，按照不同階段的主力需求，民生銀行大數據建設可以簡單分為三個階段：
第一個階段是面向客戶的在線存儲查詢階段：
銀行有很多面向客戶的數據，數據積累非常快也非常多，以流水數據為例，為了保證系統服務質量，通常是縮短可查詢的周期，依托大數據的海量數據存儲能力，基于分布式體系構建了歷史數據管理平臺來滿足業務場景中海量數據的存儲和查詢服務需求。
第二個階段是離線的批量數據計算及智能數據分析階段：
在 2015 年全面啟動鳳凰計劃建設后，各領域系統性的梳理了業務戰略和實施策略，配合鳳凰計劃中數字化戰略的落地，業務流程和模式中涌現出大量的批量數據加工計算和結果數據服務的應用場景。在這個階段根據數據流轉周期和服務場景，結合整體的數據管控需求，建立了企業級數據開發模型，逐步推動和完善了全行統一的數據服務中臺，先后為數十個業務場景提供數據支持。同時隨著數據中臺的成熟，原始數據的積累，基于數據的機器學習人工智能分析等場景逐步涌現，為了降低新技術的使用門檻，快速迭代場景下的機器學習算法模型，在這個階段同步建設了可視化的機器學習平臺，對接數據中臺，為個性化推薦、風險預警及運營多個領域內的細分場景提供服務能力輸出。
第三個階段是全面推動在線實時數據計算及分析階段：
隨著批量數據體系的成熟，業務場景對實時數據的需求迅速涌現，我行科技啟動了全面的實時數據體系建設，對實時風控和實時事件驅動的營銷和運營形成了全面的支撐。
通過三個階段，在支撐業務應用場景發展的同時，目前平臺層面已初步完成如下幾大平臺建設：
- 數據采集分析平臺
- Hadoop 數據加工整合平臺
- 可視化機器學習平臺
- 實時推薦引擎
- 數據開放平臺
圖 2、大數據主要平臺視圖
在數據采集層通過行為數據平臺和外部數據平臺，豐富了整個數據體系。通過數據整合平臺（DC），打通以用戶為中心的全維度的數據視圖，為后續的機器學習和人工智能應用提供了可行的數據基礎，通過可視化的機器學習平臺完成數據與算法的結合，由數據服務層統一管控輸出。
目前隨著大數據多個平臺的建設，為我行多個戰略級項目提供了全面的底層數據和模型能力輸出，包括支持了鳳凰計劃項目指南針預警項目、數據化平臺型授信決策變革項目、運營風險監控體系項目、新一代零售信貸體系、村鎮銀行等多個項目的建設。
二、數據采集平臺
背景及目標
銀行在過去的信息化建設中，更多的注重是交易數據的積累，對用戶的使用偏好、瀏覽點擊行為、停留時間等行為層面的數據較少涉及。隨著大數據的發展，通過對用戶數據的收集，整合，分析，挖掘，能夠很好的對用戶是誰，用戶從哪來，要到哪里去等問題進行定義和解析。在交易數據的基礎上，對用戶行為數據和外部數據進行補充建設，有了這些數據，首先可以在我行的 App、網站以及 ATM 等與用戶密切相關的場景里，提供更貼心，更優質的服務；其次對公司內部各個金融業務產品用戶體驗優化等方向上提供用戶數據反饋支撐。
行為數據采集及分析
圖 3、行為數據平臺
從行為數據的采集、數據分析整合及數據應用三個方面統籌進行規劃和設計，完成了行為數據平臺（GD）的建設。數據采集部分作為整個項目的數據來源層，完成對用戶產生的原始行為數據的收集和存儲。數據分析部分作為 GD 的中間層，對收集來的用戶行為數據進行統計分析，大致可以得到三類數據，一類是反應應用整體運營情況的指標數據，第二類是反應用戶行為軌跡、地理位置軌跡等的用戶生命周期數據，還有一類是標識每一個微觀用戶的標簽數據。數據應用部分作為 GD 對外展示和服務層，一方面為實時推薦、精準營銷等應用提供數據支持，一方面通過后臺管理系統，供應用運營方進行查看。
在數據采集層通過構建采集客戶端 SDK，嵌入我行統一的移動開發框架 Firefly 以及前端開發框架 Apollo 中，結合無碼采集的技術能力運用，使得我行所有基于同一框架開發的移動端 APP 和 Web 網站天然具備用戶行為數據采集和分析的能力。
行為數據平臺自 2015 年上線到現在為止，已經接入了手機銀行、直銷銀行、樂收銀及客戶化運營等民生銀行大部分 APP 應用，對這些應用中的用戶的行為數據進行采集，2017 年又增加了對網頁端行為數據采集的功能。目前每天采集的數據超過千萬條，累積的行為數據已經達到數十億條，通過大數據分析技術，對采集到的數據進行了報表統計和分析，已得到五類的統計報表數據，包括應用中用戶的新增數目、活躍數目、累計數目及用戶的設備分布、地域分布、操作系統、留存情況、用戶瀏覽時長統計、點擊事件統計及應用的錯誤統計等，目前進一步的在推動行為數據對營銷和風控的實時數據補充。
外部數據采集及分析
圖 4、外部數據平臺
在啟動外部數據平臺建設之前，我行外部數據由各業務條線獨立規劃實施，各個技術團隊建設了自己業務領域內的外部數據鏈路及服務，形成了“煙囪”式的數據加工服務模式。隨著 Hadoop 大數據平臺的推進，2016 年在統一外部數據管理及使用的思想下，啟動了外部數據平臺的建設，核心定位在于：負責所有外部數據的統一存儲、統一加工以及統一的查詢服務，要求支持海量的結構化、非結構化外部數據的引入分析能力。
外部數據平臺 OMDS 于 2016 年 9 月完成上線，目前已經整合接入包括征信、工商、法院、公安、千里眼、百度、銀聯、世聯評估、行業分析、萬德財報等約二十種外部數據的統一管控和服務。
三、配置化的數據加工整合平臺
背景及目標
Hadoop 數據整合平（DC）在行內大數據體系中承擔著承上啟下的角色，匯集各渠道的數據到大數據平臺，經過統一清洗、加工、治理，進而向上游應用提供服務，從后臺走到中臺，直接、快速地向應用系統提供數據服務和大數據能力，發揮數據內在的威力。數據的獲取并不是目的，如何利用大數據平臺技術，實現數據的管理和信息的加工提煉，并對上游系統提供各類數據支支持。針對這些問題和挑戰，DC 從數據和技術兩個方面著手對平臺進行構建。
數據層次
圖 5、DC 數據層次
為方便數據的管理、加工和使用，DC 將數據進行了分層：近源層和共性加工層，其中近源層為來自于 MDS、OMDS、GD 和 EDW 的原始數據，包含行內數據、外部數據、行為數據、分行數據和數倉數據。
近源層數據經過關聯、匯總和分析之后，針對上游應用的需求，進行數據共性加工，包括流水加工、應用統計、指標加工、標簽計算、風險領域和運營領域。
通過 OpenFile（批量文件服務）實現數據的訂閱管理，提供了近源層、共性加工層等數據的查看、訂閱功能。
技術架構
基于上述數據架構及應用需求，DC 從數據處理、任務調度、數據管理和開發輔助四塊進行平臺的建設，技術架構如下圖：
圖 6、DC 技術架構圖
1、 數據處理體系
數據的存儲、計算和分析為基于 Hadoop 生態體系，包括 Hadoop、Spark、Inceptor、HBase 等分布式計算及存儲框架，來完成數據的存儲、計算、分析整個生命周期。
數據處理自下到上包含數據獲取 RouterIn、數據清洗 (DataClean)、共性加工 (SparkSql/Inceptor Sql) 和批量數據訪問服務 OpenFile。
通過 Router 實現不同數據平臺間的數據交互，屏蔽平臺間的差異，配置化開發，提升了開發效率，降低了人為失誤導致的問題，實現了數據的快速接入和分發。
基于 Inceptor 和 SparkSql 設計開發了數據共性加工模塊 DcCore 和 Dispose，實現了數據的快速加工，并支持模板式的配置開發，有效提升了共性加工的開發效率。
2、 任務調度體系
為實現調度批次輕量化，精細化數據依賴，避免批次等待，通過任務組織模塊化，來實現作業調度的導出與上線。
系統間的調度通過 CPS，實現批量作業執行，系統內部調度通過 moia 聯動，可支持更小粒度的作業調度，實現了作業調試的效率和靈活。
3、 開發輔助體系
開發人員需要對數據處理及任務調度單獨開發一系列的代碼和配置文件，人為操作不僅效率低，而且易出錯。通過輔助開發工具，可根據每個模塊的規范，自動生成代碼及配置文件，并提供可視化界面，提升開發效率，降低成本和風險。
支持的功能分為自動化創建、自動化校驗、調度管理、模型管理和元數據管理。
4、 數據管理體系
數據管理體系建設目的是為了降低運維成本，對源數據、加工數據、數據質量、作業運行進行統計分析，分析結果通過 Web 頁面展示以方便對系統及數據的查看管理，并對于重要信息進行監控告警，其核心模塊包括信息采集模塊、數據質量管理、系統運行分析和監控告警。
DC 的構建在民生銀行中起到承上啟下的作用，匯集了各渠道的數據，經過統一清洗、關聯整合，并對數據進行深層的分析挖掘，進而向上游應用提供服務，從后臺走到中臺，直接、快速地向應用系統提供數據服務和大數據能力，發揮數據內在的威力。目前 DC 系統管理了近源數據 5000 余項、共性加工數據 800 余項，為包括風險領域、運營領域、移動互聯領域等 8 個領域，20 余個系統，50 余個場景提供數據或計算支持。
四、在線機器學習平臺
背景及目標
目前的機器學習技術，尤其是智能算法，具有很高的技術門檻，需要頂級專業團隊的持續投入，每個項目單獨去關注技術的變化并落地代價太高。模型研發實踐亟需一個統一的機器學習平臺，用以規范模型開發流程，封裝和簡化各類算法的使用，支持多種多樣的數據預加工，提供和管理模型預測服務。最終滿足數據分析師、業務專家、軟件開發等不同角色的不同層次的模型研發實踐訴求。
機器學習平臺建設旨在：
- 基于 Hadoop 技術棧的平臺型環境，提供業內最新的模型算法；
- 基于 Hadoop 技術棧的分布式環境，支持超大規模的模型場景；
- 為一般模型研究人員提供便捷的基于算子和工作流的圖形環境；
- 為高階模型研究人員提供全面的基于編程的模型開發管理環境。
機器學習平臺要能夠適配各種已有的數據源，如傳統關系型數據庫，TeraData 數據倉庫等，提供數據的各種可視化探索及建模挖掘；并能對數據和模型基于角色進行完善的權限管理；對于研究人員精心挑選調試而來的模型，平臺能夠將其一鍵部署為在線服務，將經驗數據及時轉化為對未來的精準預測能力。
圖 7、機器學習平臺功能架構圖
建設現狀
項目一期中建設了機器學習平臺系統核心模塊，覆蓋了模型研發的主要流程，主要分為調研平臺和預估服務兩大子模塊。海量樣本學習、高維特征分析處理和自動特征組合能力是其最大亮點，示意圖如下：
圖 8、機器學習平臺系統基本示意圖
整個平臺主要通過網站交互式功能為用戶提供服務。模型生命周期內的幾個大的階段都已經封裝成算子的功能模塊，模型的研發過程就是在一塊“畫布”上，通過拖拽算子，串聯模型研發的各個階段，繪制創意藍圖。如下圖所示：
圖 9、拖拽算子進行模型研發
對于訓練好的模型，平臺支持一鍵發布為在線預測服務。從研發到服務，不再需要龐雜的代碼與流程。只要對學習模型有概念，對于領域問題有好的創意。就能在拖拽之間，點選之后獲得一個高性能的，高可用的預測服務。就能實現業務決策的更加精確化、智能化。
典型案例
平臺目前對接了以下幾方面的應用：
運營風險監控之可疑境外取現
運營風險監控之可疑境外取現場景，通過機器學習方法分析已掌握的可疑取現行為特征，自動發現其中模式，從而更全面、更及時地發掘可疑取現賬號。經過頭腦風暴，我們抽取了銷卡 / 重開 / 換卡次數、開戶機構、交易地域 / 時段 / 頻率 / 金額、資金流入流出渠道 / 時間差、客戶基本信息等特征，精確率從~65% 提升到了~90%，緩解了人工復核階段的開銷。
零售風險申請反欺詐評分實驗
零售風險管理之申請 / 反欺詐評分實驗探索 -- 結合信用風險和反欺詐兩方面，建立統一的小微反欺詐評分模型。期望通過機器學習平臺系統的新機器學習算法和高維特征處理能力使我行小微申請反欺詐評分模型的效果有比較明顯的提升和優化，提高對信用風險和欺詐風險的識別能力。通過對數 TB 的征信、工商、設備和客戶基本信息加以聚合分析，抽取了近千個特征字段，特征自動組合階段又發現了數十個高效特征，再結合平臺內置算法模型的 AUC 達到了 0.9，KS 值提升 20%。
五、智能化實時推薦引擎平臺
背景及目標
實時推薦引擎是我行大數據體系中面向應用場景建立的應用層面的通用智能引擎，該引擎將大數據基礎平臺的多種底層數據產出系統，包括標簽系統、機器學習平臺、大數據平臺及實時數據平臺，通過應用場景鏈接起來，構建了具備實時推薦能力的數據服務層。實時推薦引擎的核心是實時數據處理體系以及機器學習推薦模型。實時推薦引擎的建設，為精細化的客群經營、個性化客戶服務提供了千人千面的支持，成為大數據能力落地、轉化為效益的重要環節。實時推薦建設的目標包括：
- 構建在線推薦系統，建設提供各場景的實時推薦服務的基礎能力；
- 打通用戶實時點擊行為鏈路，將實時數據結合到在線推薦服務中；
- 打通機器學習平臺模型推薦結果，將模型結果數據融合到在線推薦服務中；
- 抽象用戶、產品數據模式，建設推薦層面規則引擎，支持業務策略靈活配置，并支持融合在線實時行為推薦結果以及機器學習批量模型結果等數據。
系統架構
從技術上實時推薦引擎分為數據加工體系和數據服務體系兩部分，通過 redis 層來將兩部分鏈接起來。
數據加工上涉及到后端多平臺上的數據加工，在通用類數據加工上，包括了通過數倉平臺建立的集市層數據加工以及 DC 平臺完成的行為和外部數據標簽加工。這部分加工的數據作為客戶的屬性數據，灌入到 Redis 中供引擎層快速查詢和過濾使用。同樣在后端數據加工上，還涉及到算法層面的數據加工，通過機器學習平臺完成客戶購買預測，將基于批量持有信息的計算結果，通過 T-1 每日批量的模式推入 Reids 作為推薦結果集的數據來源之一。對于用戶實時點擊的數據，通過 GD 的行為數據采集，推送到實時數據處理平臺上，通過流式作業計算在線實時的相關性矩陣，將用戶的實時行為通過協同過濾算法體現到推薦結果中去。對于服務層，著重建設了核心的引擎（包括算法引擎和規則引擎），用戶訪問將觸發引擎訪問 Redis 對應模塊的數據，通過業務策略以及在線的算法對各推薦結果備選集進行篩選和排序，最終給出最適合的結果。
圖 10、實時推薦引擎
典型案例
手機銀行理財產品推薦
當前手機銀行上推薦的理財是基于客戶資產、持倉以及在售理財產品信息，按照相應推薦規則計算得到，使用的數據維度少，靈活性較差。因此為了進一步為了提升客戶體驗，在手機銀行上實現個性化的理財推薦服務。
財富圈資訊推薦
以萬德的新聞資訊數據為基礎，依據客戶在我行的產品購買，交易行為以及上線之后的瀏覽行為等信息，推薦符合客戶投資、閱讀偏好的新聞資訊，并且在推薦過程中對新聞的價值作出簡要判斷，以對客戶形成簡要的投資支持。
六、數據開放平臺
背景及目標
如何實現大數據價值轉化是其中非常重要的課題，從當前數據應用的趨勢來看，一是越來越看重數據的時效性，從數據分析到數據提供，都要求從離線走向在線；二是注重場景化，要求數據能夠靈活和快速地適配各類應用場景。為適應這樣的趨勢，大數據的服務層就必須設計相應的機制。場景化數據開放平臺從大數據服務的頂層設計出發，為統一服務出口，增強數據輸出規范，對外使用上提供統一的 API 服務網關，提供服務流量的匯聚點，為數據服務模型服務的共享和迭代提供可能。
在數據開放平臺中，API 是數據基礎。在各類數據規范的指引下，對數據進行分門別類，維度切分后，以在線 API 的方式提供包括數據接入、數據供給等各類服務，供各應用場景實時、組合式調用。通過統一的開放網關實現服務接入、發布、鑒權、訪問、統計和監控，實現數據安全與管控。
功能架構
數據開放平臺整體上包含管理網站和網關系統兩部分。管理網站負責 API 的接入、發布、維護、監控，訪問統計數據的展示和 API 的訪問申請審批。網關系統是訪問 API 請求的統一出入口，負責請求的鑒權、訪問控制、流量控制、統計監控等功能。
圖 11、功能架構圖
技術架構
管理網站將 API 數據、鑒權數據和訪問控制配置信息等持久化到 MySQL 數據庫，同時將這些數據和配置信息通過 Zookeeper 服務同步到網關系統。為了實現對請求的靈活管控，網關系統針對黑名單、身份驗證、權限校驗、流量控制等功能采用插件化開發，且每個插件均能動態開關。每個請求的處理日志信息通過異步方式發送到事件隊列，并由單獨的日志收集進程進行收集，大數據實時計算平臺對收集的日志進行分析處理將訪問統計數據存儲到數據庫供用戶查看。
圖 12、技術架構圖
建設現狀
數據開放平臺上的 API 服務分為客戶行為類、客戶資產類、行外數據類、基礎服務類等，其中基礎服務類中已經接入了實時數據接收 API，該 API 用于接收各個系統實時數據供后續實時計算任務消費。已經開發完成客戶行為類 API 共 16 個、客戶資產類 API 共 6 個、行外數據類 API 共 13 個，OpenAPI 平臺屬于初步完成建設，后續會有更豐富的數據服務 API 通過數據開放平臺對外服務。
總結
民生銀行大數據建設之路是一個配合業務場景需求反復迭代前進的一個線路，發展到今天，從多個不同的平臺、模塊逐步的形成了幾大體系：數據采集體系、數據服務體系、批量數據分析體系、實時數據分析體系以及智能數據分析體系。對于數據服務體系，主體是整體規劃中提到的數據中臺演化而來，是數據業務化輸出的重要承載體。數據服務體系形成統一的數據服務目錄，由開放平臺層面的網關統一進行把控，通過場景化數據服務中臺對數據和模型應用進行服務化，為對數字化、場景化的業務轉型提供了堅實的底層支撐能力。
