融合大數據技術架構在大型商業銀行海量數據分析的應用①

金磐石, 朱 志, 沈麗忠

1(中國建設銀行股份有限公司, 北京 100025)

2(中國建設銀行股份有限公司 廈門開發中心, 廈門 361008)

1 現狀與挑戰

隨著以社交媒體的興起、智能設備的普及, 現代社會已經步入“大數據”時代, 它將對社會、商業和個人都產生巨大而深遠的影響. 根據維基百科的定義[1],“大數據”是指無法在一定時間內用傳統數據庫軟件工具對其內容進行抓取、管理和處理的數據集合;而大數據技術指的是新一代的技術與架構, 在成本可控的前提下, 它可以通過快速的采集、發現和分析, 從海量的、多樣的數據中提取價值. 這個定義描述了大數據的三個特征:Volume(海量)、Velocity(高速)、Variety(多樣), 即俗稱的“3V”. 第一個是 Volume(海量), 數據量越來越大, 已經超出傳統技術和功能的存儲和處理能力;第二個是Velocity(速度), 數據量增長越來越快,需要處理的速度和響應的時間要求也越來越高;第三個是Variety(多樣性), 指各種各樣類型的數據出現, 過去的數據更多的是結構化的, 現在越來越多的數據是半結構, 甚至是完全沒有結構的數據, 如文本、郵件甚至于語音、視頻等. “3V”是對大數據最基本特征的歸納, 得到業界的共識, 同時也是我行面臨的主要挑戰.

一方面, 在“大數據”時代背景下, 我行數據線架構面臨“大數據”三個基本特征帶來的沖擊. 首先, 數據量持續增長, 我行擁有6億客戶和20億賬戶, 由此產生的每日數據增量達2～3TB,并以每年10%以上的速度增長, 然而傳統軟硬件一體的數據倉庫解決方案成本高昂, 動則上億元的升級成本, 令其無法滿足我行在成本可控的前提下高效地存儲、處理不斷增長業務數據的需求;其次, 原有的數據分析處理基本以T+1的批處理為主, 無法滿足像反欺詐、運營指標實時分析/探索等需要實時響應的交互式數據分析、探索的業務需求;最后, 傳統的方案只能處理結構化的數據, 然而, 除了傳統結構化的數據外, 越來越多的業務需求需要結合半結構化、非結構化的數據進行分析、決策, 如記錄客戶使用行為的網上銀行系統日志、記錄電話客服的語音和文本數據和第三方社交媒體數據等.

另一方面, 在新一代實施前, 我行數據線已具備相當規模, 包括數據倉庫、操作數據存儲、分行操作數據存儲、歷史數據存儲和管理分析類應用在內的數據線為全行提供經營、管理、決策所需的信息, 在客戶關系管理、資產負債管理、風險管理等方面的應用在國內同業處于領先水平. 但在數據管理上, 缺乏統籌考慮, 部門級應用各自重復存儲數據;在數據應用上, 應用模式單一(報表), 報表使用效率不高, 開發周期長.這些問題, 導致數據在完整性、一致性、準確性和時效性上存在諸多質量隱患, 影響了數據線價值的實現.

2 方案架構

2.1 “新一代”整體架構

面對這些挑戰, 我行“新一代”從業務架構及 IT 架構兩大方向入手, 建立起統一、規范的企業級架構規劃. 采用基于 SOA 的組件化設計方法[2], 將 IT 架構整合為 7 層(細化為12 個技術平臺), 如圖1所示, 各個區的具體定位和功能為[3]:

圖1 “新一代”整體架構

(1) 渠道整合層(包含P1和P2)的作用是整合渠道接入, 統一渠道接口處理. 通過標準的方式接入、處理并封裝請求數據和調用后臺服務返回結果, 渠道整合層響應來自不同渠道的業務請求.

(2) 客戶服務整合層(包含P3)從客戶視角出發,通過整合端到端的客戶服務流程, 為內外部客戶提供具備良好體驗的銀行產品和集成服務.

(3) 應用集成層(包含P4)通過標準化方式接受來自客戶服務整合層及渠道整合層的服務請求, 屏蔽后臺服務的技術特性, 以一致的形式返回結果. 主要功能包括服務目錄管理、報文轉換、交易路由、服務調用、資源分配等;

(4) 外聯集成層(包含P5)負責我行“新一代”與外部金融和非金融機構的系統交互, 包含如第三方支付系統、保險公司、人行征信系統等. 主要完成協議轉換、報文轉發和等功能, 為內部系統屏蔽各類網絡接口的技術特性.

(5) 產品服務層(包含P6, P7, P8)提供企業視角的產品服務, 支持銀行集團核心業務, 涉及產品、客戶、合約、核算等服務, 提供與渠道無關的產品、服務處理組件. 產品服務層以應用組件作為服務的載體, 將服務發布在應用集成層.

(6) 數據集成層(包含P9)整合企業范圍內的各類數據, 為產品服務層和管理分析層提供統一的數據服務. 數據集成層可提供面向企業級數據的集成服務, 是企業級信息視圖的必要條件, 實現了企業級統一的數據接入、數據存儲、數據批處理、數據分析、數據歸檔、文件交換、數據訪問、元數據管理和任務調度等能力.

(7) 管理分析層(包含P10, P12)為銀行內部管理和決策提供支持. P10主要的功能是搭建企業級數據應用平臺基礎設施, 為各類管理分析類應用提供報表、自助維度分析、即席查詢和數據挖掘等服務;P12主要為在線交易運營決策服務和信息訪問服務提供開發和運行支持, 具備靈活的規則定制和高效的數據訪問能力.

2.2 數據線邏輯分區

在“新一代”整體架構內, 數據線主要包括數據集成層(P9)和管理分析層(P10和P12), 其細化的邏輯分析如圖2所示, 包含如下幾個數據區:

(1) 數據緩存區, 它支持數據集散存放, 作為源系統數據的暫存區. 數據模型與組件數據格式相近, 以文本文件方式存儲. 支持做一部分簡單的數據處理:如基本的數據的轉碼、標準化、技術清洗;完成基于增量數據的快速/簡單加工等. 數據保留的周期較短, 一般為15天.

(2) 數據倉庫區, 主要完成企業級數據整合, 支持全行公共計算和應用計算, 提供數據給全行使用. 數據倉庫區又細分為五個區:貼源區, 基礎主題區, 公共計算區, 應用計算區, 公共訪問區, 他們的功能和定位分別為:

① 貼源區. 顧名思義, 它的數據模型主要為貼源結構(貼近源系統/組件), 同時采用拉鏈表技術降低數據冗余量. 提供前日快照數據, 供日常加工計算使用;提供30天以內的截面全量;支持快速、跨業務領域的應用計算;設有存放半結構化數據的子分區, 提供半結構化數據轉換為結構化數據、半結構化數據預處理等功能. 數據保存周期一般為30天.

② 基礎主題數據區. 主要完成企業級的基礎數據整合計算, 包括按基礎主題模型重新組織數據、合并不同組件數據到同一實體中. 數據以3NF方式完成數據合并, 形成企業級全口徑, 確保模型穩定.

③ 公共計算區. 主要做公共指標和衍生數據的計算加工, 具體還包含完成賬戶、客戶和流水粒度的衍生加工;完成通用的交叉維度衍生計算;完成分行共用指標的加工.

④ 應用計算區. 主要做與特定應用相關的指標和衍生數據加工.

⑤ 公共訪問區. 涵蓋基礎數據、衍生數據等全部數據;支持非固定、高并發的用戶對全部數據的訪問;支持SAS, 支持少數用戶對全部數據的分析和挖掘.

(3) 實驗數據區. 主要用于數據深度探索、模型研發、和需求驗證等目的. 模型訓練結果是模型及參數,由應用計算區負責對應用模型訓練結果進行加工;支持管理分析應用需求分析人員確認口徑;一般按月更新樣本數據, 同時也支持按需同步數據;支持分行以實驗項目方式使用實驗數據區進行模型訓練.

(4) 歷史數據歸檔區. 主要用于源系統數據的歸檔和數據倉庫歷史數據歸檔, 同時也支持對歸檔數據的聯機訪問.

(5) 非結構化數據區. 顧名思義, 主要提供非結構化數據存儲、訪問和分析.

圖2 數據線邏輯分區

3 關鍵技術方案和策略

3.1 海量數據的存儲和處理

新一代前我行的數據倉庫主要采用軟硬件一體的數據庫和SAN存儲存放和處理數據, 存在成本居高不下、擴展能力有限、支持的數據類型有限(不支持半結構化和非結構化)等問題. 隨著業務數據的快速增加和業務需求的涌現, 這些問題日漸突出.

基于X86開放平臺的新技術在大數據時代以其相對合理的成本和高可擴展性逐漸受到業界的關注和應用, 新一代實施需要適時對新技術進行探索和使用.

3.1.1 MPP數據庫技術

MPP (Massive Parallel Processing)數據庫, 即大規模并行處理數據庫系統, 由多個獨立的節點組成, 每個節點只訪問自己的本地資源(如內存和存儲等), 節點之間通過網絡連接通訊, 是一種完全無共享架構.MPP架構數據庫具備如下特點:

① 擁有較強的海量計算能力:所有數據分布到所有節點, 每個節點都計算自己的部分數據, 并行處理無需人工干預, 系統自動通過增加通用硬件來擴充新的計算結點;② 具有較強的容錯能力:對于普通的計算節點, 一份數據分布在多個節點上,避免出現由于單個節點出現故障而導致的數據丟失和系統不可用. 對于管理節點, 一般也采用高可用設計, 避免了單點故障;③移動計算比移動數據更方便:由于數據分布的特性,可利用普通計算節點的處理能力, 處理本機器上的數據,從而盡量避免數據在不同節點之間的大量數據移動;④ 較好的擴展性:可線性擴展到上百個節點, 每增加一個節點, 查詢、加載性能都成線性增長;⑤ 數據管理相對簡單:無需復雜的調優需求, 只需要加載數據和查詢,DBA工作量較少, 無需復雜的調優工作和維護工作;⑥ BI工具支持比較成熟, 一般能夠廣泛地支持各個BI和ETL軟件工具. 除此之外, 不同產品在事務支持、數據存儲格式、存儲分布優化等方面都有不同程度的增強.

3.1.2 Hadoop/Spark技術

Apache Hadoop[4]是GOOGLE大數據技術存儲、計算框架的開源實現, 具備良好的可擴展性、低廉的硬件成本、高度容錯、較強的靈活性等特點. 它包含以下幾個核心組件:

(1) HDFS(Hadoop Distribute File System)基于Google發布的GFS論文[5]設計開發, 其除具備其他分布式文件系統相同特性外, 還有自己特有的特性:高容錯, 能很好地應對通用硬件的單點故障;高吞吐量, 為有大量數據訪問的應用提供高吞吐量支持;大文件存儲, 支持存儲TB-PB級別的數據. HDFS特別適合大文件一次寫入, 多次讀取的情景, 而不適合存儲大量小文件、隨機寫入和低延遲讀取的情景

(2) MapReduce 是基于Google發布的MapReduce論文[6]開源實現一個并行計算框架, 該框架把復雜的并行計算抽象為Map和Reduce兩個階段, 用戶開發應用時無需關注一系列復雜的分布式計算問題, 如任務調度、資源分配、容錯和數據分片等, 只需重點關注如何把要解決的問題轉換為一系列Map和Reduce操作.

(3) YARN (Yet Another Resource Negotiator)[7]是一個通用資源管理系統(主要包含集群的CPU、內存和IO計算資源), 可為上層應用提供統一的資源管理和調度服務, 能為集群的利用率、資源統一管理和數據共享等方面帶來了大幅提升. 在它之上, 可以運行不同的并行計算框架, 如MapReduce, Spark, Tez等.

在Hadoop核心組件的基礎之上, 又陸續發展出多種適用于不用使用場景的技術產品, 如圖3所示, 適用于海量數據批處理的Hive, Pig等;適用于交互式分析的Impala、Kylin等;適用于數據挖掘的Mahout等;適用于實時計算的Storm和適用于高并發在線訪問的HBase等NoSQL產品. 此外還包含用于集群部署安裝的Ambari;用于元數據管理的HCatalog;用于底層分布式協同的Zookeeper;用于作業編排的Oozie;用于提供友好可視化訪問、分析界面的Hue和Zepplin等產品.

圖3 Hadoop/Spark 生態體系

Apache Spark[8]是為大規模數據運算而設計的一個開源通用計算框架, 最初是由加州大學柏克萊分校AMP Lab所開發. 相對于Hadoop的MapReduce重度依賴磁盤緩存中間計算結果不同, Spark盡可能地基于緩存在內存中的數據進行運算, 大幅度提高并行計算速度, 特別適合需要多次迭代的復雜運算場景, 如數據挖掘. 和 Hadoop MapReduce 相比, 根據不同的場景, 運算速度能提升10～100倍. 除了性能上的提升, Spark具備另外一個獨特的優勢:依賴基于Spark Core之上的Spark SQL, Spark MLib和Spark Streaming等庫,Spark可以支持批處理、即席分析、數據挖掘和實時計算多種使用場景,大幅減低了系統部署和運維的復雜度.

3.1.3 MPP數據庫技術與Hadoop/Spark技術對比

MPP數據庫技術與Hadoop/Spark技術各有特點,其主要的區別如表1所示, 整體而言, Hadoop/Spark技術具備更好的擴展能力、更低的軟硬件成本和多樣化數據處理能力, 而MPP數據庫技術在對SQL支持、事務支持、BI工具支持等方面較Hadoop/Spark技術成熟, 而且對人員技能要求相對較低, 后期運維投入成本也會比較低. 簡而言之, MPP數據庫技術和Hadoop/Spark技術各有優劣, 各有各適用的場景, 需要綜合多種因素進行選擇.

表1 MPP技術與Hadoop/Spark技術對比

3.1.4 我行的技術引入策略

我行數據線各個邏輯分區的應用特點如表2所示.

表2 數據線各個邏輯分區的應用特點

根據MPP數據庫、Hadoop/Spark技術各自的特點和數據線各個邏輯分區的應用特點, 在綜合考慮到快速見成效、人員技能、開發模式等因素, 我行引入基于X86開放式硬件平臺的MPP數據庫技術產品, 應用于貼源數據區、應用計算區和實驗數據區, 降低Teradata平臺的處理壓力, 為Teradata平臺減負, 另一方面, 綜合考慮到產品的成熟度、特性、業界最佳實踐和應用遷移成本等因素, Teradata依然承擔基礎主題數據區和公共計算區的負載. 考慮到Hadoop/Spark技術良好的可擴展性、較低的軟硬件成本和多樣化數據處理能力, 將其運用于歷史數據歸檔區存儲源系統和倉庫海量備份數據;運用于歷史數據在線訪問區提供高并發且訪問模式相對固定的歷史數據在線訪問;運用于非結構化數據區對非結構化數據的存儲、加工和分析.

此外, 對于公共訪問區, 單一的產品無法很好地滿足其相對比較有挑戰的功能和非功能需求, 為此我們為其提出如下解決方案.

3.2 聯機在線分析處理的快速響應

聯機分析處理(OnLine Analytical Processing, 簡稱OLAP)的概念最早由關系數據庫之父Codd EF于1993年提出[9]. 不同于面向基本、日常事務處理的聯機事務處理(OnLine Transaction Processing, 簡稱OLTP), 例如銀行交易, 它支持復雜的分析操作(如多維度分析), 讓用戶能夠根據自身需求, 多維度、多角度地快速洞悉原始數據隱含的價值, 并為其商業決策提供強有力的支持. 它是商業智能和數據庫倉庫的基礎. 隨著數據平民化趨勢的不斷發展, 聯機分析類應用逐漸對更多的管理人員和業務人員開放, 這對公共訪問區的聯機分析處理的訪問性能和并發度提出更高的要求. 然而, 現有的產品, 無論是MPP數據庫還是單一的Hadoop/Spark技術產品都無法很好地同時滿足應用在功能和非功能方面的要求.

目前可用于OLAP(聯機分析)的產品主要分為兩大類:多維聯機分析處理(Multidimensional OnLine Analytical Processing, 簡稱MOLAP)和關系型聯機分析處理(Relational OnLine Analytical Processing, 簡稱ROLAP). MOLAP以多維數據組織方式為核心, 使用多維數組存儲數據, 把數據組織成"立方塊(Cube)"的結構, 然后對"立方塊"進行"旋轉"、"切塊"、"切片"等操作來形成多維數據報表需要的數據. 它的特點是將聚合后的數據保存在Cube中, 以空間換效率, 查詢時效率高, 但生成Cube時需要大量的時間和空間.

在大數據領域, Apache Kylin[10]是MOLAP技術路線的典型代表. 單從公開的測試數據來看[11], 它的查詢性能相比ROLAP要好很多. 當然, Kylin的亞秒級響應也是要付出一定的代價, 即預計算的代價, 包含兩部分:其一是預計算所需計算資源和時間, 其二是保存預計算結果(即Cube)所需的存儲空間. 如果不對預計算的維度組合進行合理的選擇, 很容易引起Cube作業失敗或維度爆炸等問題. 對此, Kylin提供了部分Cube優化的功能, 幫助用戶控制數據膨脹問題. 總體而言, 要在查詢性能和預計算代價之間做出合理的權衡, 需要用戶對其工作原理和業務查詢模式都有較深的理解. 除此之外, Apache Kylin也不是能夠很好地滿足所有的場景, 比如:明細數據的查詢;高基維的指標查詢和即席查詢等.

ROLAP以關系數據庫為核心, 以關系型結構進行多維數據的表示和存儲, 星型模型為其數據模型的典型代表:包含一張事實表和零個或多個維度表, 其中事實表存儲指標明細數據(如銷售額等), 維度表存儲維度信息(如銷售的商品、地區等), 事實表和維度表之間通過主鍵外鍵關聯, 維表之間沒有關聯. ROLAP的特點是數據組織相對比較靈活, 不需要進行預計算, 但是它的查詢性能相對MOLAP來說比較差.

在大數據領域, Hive, SparkSQL, Presto, Impala等SQL on Hadoop產品本質上是采用大數據技術來構建SQL引擎實現或部分實現數據庫的能力, 所以他們不僅可以用來支撐ROLAP應用, 即對以維度模型方式組織的數據進行查詢分析, 也支持對以貼源方式組織的數據進行查詢分析. 相對MOLAP產品來說, 他們具備更高的靈活度和適應性.

MOLAP和ROLAP各有優缺點, 由此在傳統的OLAP技術領域還出現了HOLAP (Hybrid OnLine Analytical Processing, 簡稱HOLAP)技術, 試圖吸取MOLAP和ROLAP各自的長處來滿足OLAP分析. 但是在大數據領域, 根據我們的調研了解, 目前還沒有一個成熟的開源HOLAP產品能滿足我行聯機分析應用的需求.

為此, 基于以上對不同SQL on Hadoop引擎的調研和比較, 并結合我行的實際業務場景需求, 在此提出一套HOLAP技術方案, 如圖4所示:其核心思想是利用MOLAP的預計算技術預先聚合、統計出常用的OLAP分析結果, 滿足相當大一部分OLAP查詢分析請求, 對于其他不適合用預計算來滿足的請求(比如明細查詢或基數太大的維度), 下推到底層的 ROLAP引擎, 利用其高效的SQL引擎查詢出結果返回給客戶端,對于計算代價較高的查詢請求, 可以進一步緩存在分布式緩存中, 減少后端OLAP引擎的壓力.

圖4 混合技術架構圖

此方案的先決條件就是要選擇合適的MOLAP引擎和ROLAP引擎. Apache Kylin和Apache Druid都屬于大數據領域的MOLAP開源產品. 但是Apache Druid的查詢接口不是SQL, 且有不支持join等缺陷,最后我們根據對SQL支持程度、適用場景、業界參考案例等方面的對比, 選擇Apache Kylin作為我們方案中的MOLAP引擎. 圖 5 為在Apache Kylin 上對SSB測試數據集進行測試的結果[11], 其中Kylin SF 10,Kylin SF 20和Kylin SF 40分別代表在SSB基準測試數據上翻10倍, 20倍和40倍的測試結果. 從測試結果可以看出, 經過預計算, Apache的查詢結果基本都在600毫秒以內, 而且查詢時間不隨著數據量的增長而增加. 不過預計算的時間和計算結果所占用的空間會隨著數據量的增長而線性增加的.

圖5 MOLAP (Apache Kylin) 運行SSB大數據測試的結果[11]

另一方面, Hive, SparkSQL, Presto, Impala等都具備ROLAP引擎的能力, 根據公開的測試結果(圖6),這些引擎各有所長, 綜合考慮ROLAP引擎性能、Hadoop發行版兼容性、運維成本和團隊技能等因素,我們選擇SparkSQL作為此方案的ROLAP引擎. 由測試結果可以知道, ROLAP引擎的響應時間一般是在秒到分鐘之間, 具體取決于數據量、查詢語句復和計算資源等因素.

圖6 ROLAP 運行SSB大數據測試的結果[12]

此方案既吸取MOLAP引擎查詢速度快的優勢,又汲取ROLAP引擎靈活和適應性強的優點, 實現了在有效控制成本的前提下, 大大提高整體的OLAP 查詢處理性能的目標.

4 結論

依托新一代構建的7層12P中的數據集成層(P9)和管理分析層(P10, P12)的能力, 我行在企業運營管理、風控管理和產品與服務等方面的應用都取得較大的進步和提升.

以運營管理為例, 為我行數據管理和日常運營打造的移動端數據可視化項目--“慧視”, 擁有“慧決策”、“慧管理”、“慧算賬”、“鷹眼”等系列產品, 著眼于移動優先、數據可視化、便捷高效、體驗第一的項目目標,滿足總行領導、分行行長、支行行長、網點負責人、各管理條線負責人等全行各級管理者的數據需求. 依托企業級統一數據視圖, 自2017年上線以來, 已經涵蓋16個崗位角色、實現600+指標數據的移動端可視化. 目前, “慧視”已在全行范圍內推廣, 得到各級管理者的廣泛好評.

在產品服務方面, 基于企業級數據分析平臺,對客戶定活期資產、貸款、代發工資、公積金、征信等數據進行深度挖掘, 對客戶進行差額化授信, 靈活設置多種服務模式, 在有效控制風險的前提下提升客戶體驗和服務水平,使快貸業務規范化、規模化發展. 截至2017年9月底, 個人快貸累計服務客戶達500萬戶, 額度授信金額3000億元, 貸款余額1377億元. 另一方面,建設銀行以小微企業金融服務為履行社會責任的重點,不斷拓寬小微企業金融服務覆蓋面. 從2016年6月投產至2017年8月底, 已成功授信113 451筆, 授信金額709.9億元, 客戶累計支用450.2億元 , 授信客戶數從1.02萬戶增長到8萬多戶, 增長幅度高達684%.

在風險管控方面, 隨著企業級反欺詐聯合防控方案落地, 業務功能全部釋放, 實現“五個首次”——首次建立信用卡、借記卡的首筆實時偵測能力, 首次將借記卡、善融商務、電話支付業務納入反欺詐監測范圍,首次將監測對象擴大到所有對私客戶和收單商戶, 首次建立統一的欺詐告警和案件管理機制, 首次建立全面的客戶行為檔案.

實踐證明, 商業銀行通過引入基于開放硬件平臺的技術和產品, 結合自身的業務和應用特點自主研發融合多種大數據技術的企業級分析處理平臺是可行的,而且比單一的、傳統的軟硬件一體方案具有明顯的優勢.