民生銀行場景化數據中臺是如何煉成的？

時間 2021-02-16

原文原文鏈接

引言

銀行是傳統行業中很是重視信息化的，並且起步早，信息化程度高，可是因爲技術的高速發展，互聯網思惟的衝擊使得銀行紛紛面臨數字化轉型的挑戰，這裏的轉型不只是業務轉型，也有技術轉型。前端

現在，許多業務不用跑去網點、櫃檯，人們經過銀行的手機客戶端，動動指尖就能完成轉帳匯款、購買理財產品等，這些便捷的操做方式正是得益於銀行的數字化轉型。固然，數字化轉型轉並不僅是表面上看到的業務轉型，還有其背後的技術、組織架構和人的思想的轉型。算法

銀行一直是新技術的實驗場，因其具備資金優點和豐富的客戶類型，對於技術應用而言，有良好的用戶基礎，並能支撐住研發的資金投入。可是銀行業面臨的痛點也很明顯，國內銀行業同質競爭很是嚴重，業務類型、監管標準、客戶羣體都高度重疊，可是流程卻各不相同，由於流程的背後是組織結構和部門利益，各個銀行之間部門設置和職責邊界都是有差異的，這種差異會直接體如今系統結構上。銀行都在談轉型，但真能大刀闊斧改革，並不容易。緩存

民生銀行場景化數據服務中臺就是在數字化轉型的大背景下誕生的，正由於這次中臺實踐的成功，民生銀行場景化數據服務中臺也被雲計算開源產業聯盟選爲「2020雲原生應用十大優秀案例」。架構

銀行爲何要建數據中臺？

通常來講，數據中臺是指經過數據技術對海量數據進行採集、計算、存儲和處理，同時統一標準和口徑，造成全域級、可複用的數據資產中心和數據存儲能力中心，造成大數據資產層，進而爲客戶提供高效的服務。併發

數據中臺構建的服務具有「可複用性」，每項服務都像一個積木，能夠隨意組合，靈活高效地解決前臺的個性化需求。其核心理念是「讓一切業務數據化，一切數據業務化」。與傳統數據平臺相比，數據中臺着眼於業務的積累和沉澱，構建了從數據生產到消費、消費後數據返回到生產的閉環過程。框架

銀行爲何要建數據中臺？

近年來銀行經營壓力持續增大，爲了尋求新的增加點，各條業務線提出了諸多個性化數據分析和服務的訴求，在沒有數據中臺時，要知足諸如個金、私銀、小微、公司、供應鏈、資管等諸多業務線的數據需求，數據分析師和工程師須要在後臺數據倉庫上完成T+1的數據加工，而後將數據文件推送給各個業務前端系統，每一個業務前端系統都維持一個小規模的數據團隊，專門負責將數據文件轉化爲本身領域內的數據服務，實現業務需求。這種模式下有幾個明顯的痛點：運維

痛點1：存儲浪費大。數據以文件方式分發到各個下游系統，均須要佔用大量寶貴的存儲空間，特別是通用數據（例如用戶屬性標籤等）的存儲和服務，亟需集中化的存儲和服務支撐，而且須要「雲化的異構存儲能力」支撐。分佈式

痛點2：傳遞效率低。文件式數據應用鏈路以T+1批量爲主，全量數據「一股腦」加載進本地應用庫，數據獲取的效率遠低於經過服務「按需」調用獲取指定內容，數據中臺爲了支持前端各具業務特點的數據應用場景，須要「微服務」支撐。微服務

痛點3：人力投入大。雖然每一個業務前端系統只維持一個小規模的數據團隊，但銀行前端業務系統衆多，總體投入不容忽視，而且不少方向並無對應的數據團隊，所以不少業務數據上的一些思路和訴求，迭代較慢，在技術上須要「雲化的部署運營能力」支撐。高併發

痛點4：管控力度弱。目前的文件式數據應用方式，文件傳送出去後，缺乏有效的管控手段，沒法準確回答數據如何使用、使用頻次等問題，數據的價值很難評估，這就須要考慮「雲化的協做管理能力」建設。

「微服務」、「雲化的異構存儲能力」、「雲化的部署運營能力」、「雲化的協做管理能力」是數據中臺解決目前金融業數據應用痛點的思路，將數據服務集中進行開發和處理，盤活數據，讓數據在線。

數據中臺體系技術方案

民生銀行數據中臺體系採用「微服務+雲化技術」做爲基礎技術架構選型，核心運轉模式由 Engine 引擎體系、 Service 服務體系、 Open 路由體系、 Plus 管理體系各種專項組件協同運轉完成：

結合民生銀行現階段業務經營的迫切訴求，阿里雲從技術平臺和數據交付兩個層面爲民生銀行制定了架構設計路線。

在技術平臺層面，經過微服務架構完成數據及模型的服務化，便於直接在系統上高效對接，結合技術組件特色和場景特色完成服務的標準化，造成標準的交付模式，進一步在技術上造成可配置化的服務框架，快速生產場景數據服務。在底層技術上，因爲中颱數據服務的集中化建設，底層採用分佈式以及雲化的相關技術完成基礎層建設，讓服務更高效可靠地發佈、運行並可管控。

在交付的內容層面，將團隊組織架構配合場景數據標準分區，造成小隊敏捷的交付模式，提升業務交付效率。在統一的平臺工做標準和模式下，沉澱共性數據內容，領域內造成工具、數據的複用，作到在靈活高效交付的同時，實現降本增效。

民生銀行數據中臺核心運轉模式以下圖所示。

首先，由Engine引擎體系完成對數據能力、模型能力的抽象封裝，以應對不一樣場景的智能數據需求。

其次，Service 服務體系完成引擎抽象能力與實際業務數據的結合應用，經過微服務模式靈活搭配，打造具有業務屬性的數據服務產品。

第三，經過 Open 體系（OpenAPI、OpenFILE、OpenMSG、OpenCFG）完成對業務系統與業務人員的快速賦能。最後，Plus 管理體系完成微服務雲化管理、數據資產目錄、數據可視化等統一管理功能，並經過DevOps、容器、高性能數據訪問緩存等前沿技術組件完成數據服務高併發、高可用、彈性部署等技術能力的提高。

引擎、服務、路由協同運轉，統籌管理，共同打造了場景化金融數據服務能力。從數據指標、數據決策、智能推薦、智能模型等多個層面提供了立體化的快速支持，爲金融業務數字化、智能化轉型升級的重要支撐。

異構分級存儲方案

數據中臺支撐的金融業務場景多樣，民生銀行結合數據應用特色、數據存儲組件能力、運維服務級別等因素，構建了一套異構大數據存儲組件的分級應用體系，在大數據存儲組件服務能力和業務場景訴求間取得平衡，取長補短，根據場景選擇合適的存儲組件，靈活組合、插拔式使用。

以常規的數據分級存儲方案爲例，以下圖所示，引入 Redis 做爲統一緩存，屏蔽下級組件服務性能波動，經過數據業務日期進行分割，近期數據存儲在 MySQL，提供 7*24 小時的運維服務保證支撐，歷史數據存儲在 HBase&SDB 等大數據存儲組件，提供強大的服務能力和水平擴展能力。

數據中臺雲原生應用實現兩個「易」

金融領域裏，數據中臺雲原生應用服務的特色相對明確：

一是讓業務需求方真正可以感覺到數據「易用」，數據可以直接輸出到系統、可以在線閉環、可以快速敏捷迭代開發。

二是在技術平臺層面，集中的平臺要面對不一樣業務條線、業務系統以知足他們的數據服務訴求，平臺自身也具有支撐多樣化需求的能力。
一、技術平臺上「易」
數據中臺改變過去數據以文件輸出的模式，將數據、模型等服務化，可以直連場景，便於造成在線的數據閉環。針對不一樣的數據服務場景，結合技術分級，按分級造成標準交付模式。經過標準化後，在開發上也抽象數據服務框架，結合「微服務+雲化」支撐，以及配套DevOps體系完善，最後達到經過配置便可產生新的數據服務，提升效率，同時也便於質量管控。
二、交付內容上「易」
數據中臺能夠實現交付敏捷化，快速知足業務需求，數據運營和經營本質就是一個不停迭代往前的過程，經過標準化、配置化的技術平臺，按照條線領域配置矩陣式的人員交付工做模式。經過數據服務的集中開發和服務管控，經過集中監控去量化數據價值，準確瞭解數據使用的情況，並最終實現成果共享化。

場景化數據中臺的效果

數據中臺是鏈接前臺和後臺的核心資源。經過爲前臺提供強大的「能力炮火」支持，能夠將後臺系統中須要頻繁變化或前臺須要直接使用的業務能力「提取」到中臺層，賦予這些業務能力更高的靈活度和更低的變動成本。

民生銀行建設場景化數據中臺的效果很是明顯：首先是數據能力的提高，圍繞數據指標在線化、實時化，算法模型服務化，開放更多大數據能力，將數據應用方式由後臺向中臺化、服務化演進，直接爲業務賦能；

其次是交付效率的提高，結合業務場景，將分佈在不一樣模塊和組件中的數據服務統一管理、規劃服務方式和標準，統一服務調用方式，統一開發框架，統一緩存機制和輔助開發工具，縮短新產品開發週期，提高了交付效率；

三是運維效能的提高，採用阿里雲微服務+基於Docker容器的雲化技術，應用的部署、啓動、升級、中止、藍綠髮布、彈伸縮等運維操做一鍵化，實現功能及服務的靈活打包部署，構建位置透明的集羣服務體系，下降領域繁雜的數據應用運維成本。

最後是管理效能的提高，在統一的平臺工做標準和模式下，沉澱共性數據內容，領域內造成工具、數據的複用，作到在靈活高效交付的同時，豐富了管理抓手，實現提效降本。

總結

數據中臺的建設是一項系統性工程，從組織架構、支撐技術到流程規範，既要有宏觀的頂層設計，又要有強有力的落地執行，數據中臺的建設沒有一勞永逸的辦法，企業須要從戰略層面進行更多思考，再配合選擇合適的數據中臺服務商，方能在數據中臺建設之路上走得穩妥。

※更多文章和資料|點擊後方文字直達 ↓↓↓
100GPython自學資料包
 阿里雲K8s實戰手冊
[阿里雲CDN排坑指南] CDN
ECS運維指南
 DevOps實踐手冊
 Hadoop大數據實戰手冊
 Knative雲原生應用開發指南
 OSS 運維實戰手冊
 雲原生架構白皮書
 Zabbix企業級分佈式監控系統源碼文檔