金磐石, 朱 志, 沈麗忠

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

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

1 現(xiàn)狀與挑戰(zhàn)

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

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

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

2 方案架構(gòu)

2.1 “新一代”整體架構(gòu)

面對(duì)這些挑戰(zhàn), 我行“新一代”從業(yè)務(wù)架構(gòu)及 IT 架構(gòu)兩大方向入手, 建立起統(tǒng)一、規(guī)范的企業(yè)級(jí)架構(gòu)規(guī)劃. 采用基于 SOA 的組件化設(shè)計(jì)方法[2], 將 IT 架構(gòu)整合為 7 層(細(xì)化為12 個(gè)技術(shù)平臺(tái)), 如圖1所示, 各個(gè)區(qū)的具體定位和功能為[3]:

圖1 “新一代”整體架構(gòu)

(1) 渠道整合層(包含P1和P2)的作用是整合渠道接入, 統(tǒng)一渠道接口處理. 通過標(biāo)準(zhǔn)的方式接入、處理并封裝請(qǐng)求數(shù)據(jù)和調(diào)用后臺(tái)服務(wù)返回結(jié)果, 渠道整合層響應(yīng)來自不同渠道的業(yè)務(wù)請(qǐng)求.

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

(3) 應(yīng)用集成層(包含P4)通過標(biāo)準(zhǔn)化方式接受來自客戶服務(wù)整合層及渠道整合層的服務(wù)請(qǐng)求, 屏蔽后臺(tái)服務(wù)的技術(shù)特性, 以一致的形式返回結(jié)果. 主要功能包括服務(wù)目錄管理、報(bào)文轉(zhuǎn)換、交易路由、服務(wù)調(diào)用、資源分配等;

(4) 外聯(lián)集成層(包含P5)負(fù)責(zé)我行“新一代”與外部金融和非金融機(jī)構(gòu)的系統(tǒng)交互, 包含如第三方支付系統(tǒng)、保險(xiǎn)公司、人行征信系統(tǒng)等. 主要完成協(xié)議轉(zhuǎn)換、報(bào)文轉(zhuǎn)發(fā)和等功能, 為內(nèi)部系統(tǒng)屏蔽各類網(wǎng)絡(luò)接口的技術(shù)特性.

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

(6) 數(shù)據(jù)集成層(包含P9)整合企業(yè)范圍內(nèi)的各類數(shù)據(jù), 為產(chǎn)品服務(wù)層和管理分析層提供統(tǒng)一的數(shù)據(jù)服務(wù). 數(shù)據(jù)集成層可提供面向企業(yè)級(jí)數(shù)據(jù)的集成服務(wù), 是企業(yè)級(jí)信息視圖的必要條件, 實(shí)現(xiàn)了企業(yè)級(jí)統(tǒng)一的數(shù)據(jù)接入、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)批處理、數(shù)據(jù)分析、數(shù)據(jù)歸檔、文件交換、數(shù)據(jù)訪問、元數(shù)據(jù)管理和任務(wù)調(diào)度等能力.

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

2.2 數(shù)據(jù)線邏輯分區(qū)

在“新一代”整體架構(gòu)內(nèi), 數(shù)據(jù)線主要包括數(shù)據(jù)集成層(P9)和管理分析層(P10和P12), 其細(xì)化的邏輯分析如圖2所示, 包含如下幾個(gè)數(shù)據(jù)區(qū):

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

(2) 數(shù)據(jù)倉庫區(qū), 主要完成企業(yè)級(jí)數(shù)據(jù)整合, 支持全行公共計(jì)算和應(yīng)用計(jì)算, 提供數(shù)據(jù)給全行使用. 數(shù)據(jù)倉庫區(qū)又細(xì)分為五個(gè)區(qū):貼源區(qū), 基礎(chǔ)主題區(qū), 公共計(jì)算區(qū), 應(yīng)用計(jì)算區(qū), 公共訪問區(qū), 他們的功能和定位分別為:

① 貼源區(qū). 顧名思義, 它的數(shù)據(jù)模型主要為貼源結(jié)構(gòu)(貼近源系統(tǒng)/組件), 同時(shí)采用拉鏈表技術(shù)降低數(shù)據(jù)冗余量. 提供前日快照數(shù)據(jù), 供日常加工計(jì)算使用;提供30天以內(nèi)的截面全量;支持快速、跨業(yè)務(wù)領(lǐng)域的應(yīng)用計(jì)算;設(shè)有存放半結(jié)構(gòu)化數(shù)據(jù)的子分區(qū), 提供半結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)換為結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)預(yù)處理等功能. 數(shù)據(jù)保存周期一般為30天.

② 基礎(chǔ)主題數(shù)據(jù)區(qū). 主要完成企業(yè)級(jí)的基礎(chǔ)數(shù)據(jù)整合計(jì)算, 包括按基礎(chǔ)主題模型重新組織數(shù)據(jù)、合并不同組件數(shù)據(jù)到同一實(shí)體中. 數(shù)據(jù)以3NF方式完成數(shù)據(jù)合并, 形成企業(yè)級(jí)全口徑, 確保模型穩(wěn)定.

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

④ 應(yīng)用計(jì)算區(qū). 主要做與特定應(yīng)用相關(guān)的指標(biāo)和衍生數(shù)據(jù)加工.

⑤ 公共訪問區(qū). 涵蓋基礎(chǔ)數(shù)據(jù)、衍生數(shù)據(jù)等全部數(shù)據(jù);支持非固定、高并發(fā)的用戶對(duì)全部數(shù)據(jù)的訪問;支持SAS, 支持少數(shù)用戶對(duì)全部數(shù)據(jù)的分析和挖掘.

(3) 實(shí)驗(yàn)數(shù)據(jù)區(qū). 主要用于數(shù)據(jù)深度探索、模型研發(fā)、和需求驗(yàn)證等目的. 模型訓(xùn)練結(jié)果是模型及參數(shù),由應(yīng)用計(jì)算區(qū)負(fù)責(zé)對(duì)應(yīng)用模型訓(xùn)練結(jié)果進(jìn)行加工;支持管理分析應(yīng)用需求分析人員確認(rèn)口徑;一般按月更新樣本數(shù)據(jù), 同時(shí)也支持按需同步數(shù)據(jù);支持分行以實(shí)驗(yàn)項(xiàng)目方式使用實(shí)驗(yàn)數(shù)據(jù)區(qū)進(jìn)行模型訓(xùn)練.

(4) 歷史數(shù)據(jù)歸檔區(qū). 主要用于源系統(tǒng)數(shù)據(jù)的歸檔和數(shù)據(jù)倉庫歷史數(shù)據(jù)歸檔, 同時(shí)也支持對(duì)歸檔數(shù)據(jù)的聯(lián)機(jī)訪問.

(5) 非結(jié)構(gòu)化數(shù)據(jù)區(qū). 顧名思義, 主要提供非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)、訪問和分析.

圖2 數(shù)據(jù)線邏輯分區(qū)

3 關(guān)鍵技術(shù)方案和策略

3.1 海量數(shù)據(jù)的存儲(chǔ)和處理

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

基于X86開放平臺(tái)的新技術(shù)在大數(shù)據(jù)時(shí)代以其相對(duì)合理的成本和高可擴(kuò)展性逐漸受到業(yè)界的關(guān)注和應(yīng)用, 新一代實(shí)施需要適時(shí)對(duì)新技術(shù)進(jìn)行探索和使用.

3.1.1 MPP數(shù)據(jù)庫技術(shù)

MPP (Massive Parallel Processing)數(shù)據(jù)庫, 即大規(guī)模并行處理數(shù)據(jù)庫系統(tǒng), 由多個(gè)獨(dú)立的節(jié)點(diǎn)組成, 每個(gè)節(jié)點(diǎn)只訪問自己的本地資源(如內(nèi)存和存儲(chǔ)等), 節(jié)點(diǎn)之間通過網(wǎng)絡(luò)連接通訊, 是一種完全無共享架構(gòu).MPP架構(gòu)數(shù)據(jù)庫具備如下特點(diǎn):

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

3.1.2 Hadoop/Spark技術(shù)

Apache Hadoop[4]是GOOGLE大數(shù)據(jù)技術(shù)存儲(chǔ)、計(jì)算框架的開源實(shí)現(xiàn), 具備良好的可擴(kuò)展性、低廉的硬件成本、高度容錯(cuò)、較強(qiáng)的靈活性等特點(diǎn). 它包含以下幾個(gè)核心組件:

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

(2) MapReduce 是基于Google發(fā)布的MapReduce論文[6]開源實(shí)現(xiàn)一個(gè)并行計(jì)算框架, 該框架把復(fù)雜的并行計(jì)算抽象為Map和Reduce兩個(gè)階段, 用戶開發(fā)應(yīng)用時(shí)無需關(guān)注一系列復(fù)雜的分布式計(jì)算問題, 如任務(wù)調(diào)度、資源分配、容錯(cuò)和數(shù)據(jù)分片等, 只需重點(diǎn)關(guān)注如何把要解決的問題轉(zhuǎn)換為一系列Map和Reduce操作.

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

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

圖3 Hadoop/Spark 生態(tài)體系

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

3.1.3 MPP數(shù)據(jù)庫技術(shù)與Hadoop/Spark技術(shù)對(duì)比

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

表1 MPP技術(shù)與Hadoop/Spark技術(shù)對(duì)比

3.1.4 我行的技術(shù)引入策略

我行數(shù)據(jù)線各個(gè)邏輯分區(qū)的應(yīng)用特點(diǎn)如表2所示.

表2 數(shù)據(jù)線各個(gè)邏輯分區(qū)的應(yīng)用特點(diǎn)

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

此外, 對(duì)于公共訪問區(qū), 單一的產(chǎn)品無法很好地滿足其相對(duì)比較有挑戰(zhàn)的功能和非功能需求, 為此我們?yōu)槠涮岢鋈缦陆鉀Q方案.

3.2 聯(lián)機(jī)在線分析處理的快速響應(yīng)

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

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

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

ROLAP以關(guān)系數(shù)據(jù)庫為核心, 以關(guān)系型結(jié)構(gòu)進(jìn)行多維數(shù)據(jù)的表示和存儲(chǔ), 星型模型為其數(shù)據(jù)模型的典型代表:包含一張事實(shí)表和零個(gè)或多個(gè)維度表, 其中事實(shí)表存儲(chǔ)指標(biāo)明細(xì)數(shù)據(jù)(如銷售額等), 維度表存儲(chǔ)維度信息(如銷售的商品、地區(qū)等), 事實(shí)表和維度表之間通過主鍵外鍵關(guān)聯(lián), 維表之間沒有關(guān)聯(lián). ROLAP的特點(diǎn)是數(shù)據(jù)組織相對(duì)比較靈活, 不需要進(jìn)行預(yù)計(jì)算, 但是它的查詢性能相對(duì)MOLAP來說比較差.

在大數(shù)據(jù)領(lǐng)域, Hive, SparkSQL, Presto, Impala等SQL on Hadoop產(chǎn)品本質(zhì)上是采用大數(shù)據(jù)技術(shù)來構(gòu)建SQL引擎實(shí)現(xiàn)或部分實(shí)現(xiàn)數(shù)據(jù)庫的能力, 所以他們不僅可以用來支撐ROLAP應(yīng)用, 即對(duì)以維度模型方式組織的數(shù)據(jù)進(jìn)行查詢分析, 也支持對(duì)以貼源方式組織的數(shù)據(jù)進(jìn)行查詢分析. 相對(duì)MOLAP產(chǎn)品來說, 他們具備更高的靈活度和適應(yīng)性.

MOLAP和ROLAP各有優(yōu)缺點(diǎn), 由此在傳統(tǒng)的OLAP技術(shù)領(lǐng)域還出現(xiàn)了HOLAP (Hybrid OnLine Analytical Processing, 簡稱HOLAP)技術(shù), 試圖吸取MOLAP和ROLAP各自的長處來滿足OLAP分析. 但是在大數(shù)據(jù)領(lǐng)域, 根據(jù)我們的調(diào)研了解, 目前還沒有一個(gè)成熟的開源HOLAP產(chǎn)品能滿足我行聯(lián)機(jī)分析應(yīng)用的需求.

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

圖4 混合技術(shù)架構(gòu)圖

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

圖5 MOLAP (Apache Kylin) 運(yùn)行SSB大數(shù)據(jù)測試的結(jié)果[11]

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

圖6 ROLAP 運(yùn)行SSB大數(shù)據(jù)測試的結(jié)果[12]

此方案既吸取MOLAP引擎查詢速度快的優(yōu)勢,又汲取ROLAP引擎靈活和適應(yīng)性強(qiáng)的優(yōu)點(diǎn), 實(shí)現(xiàn)了在有效控制成本的前提下, 大大提高整體的OLAP 查詢處理性能的目標(biāo).

4 結(jié)論

依托新一代構(gòu)建的7層12P中的數(shù)據(jù)集成層(P9)和管理分析層(P10, P12)的能力, 我行在企業(yè)運(yùn)營管理、風(fēng)控管理和產(chǎn)品與服務(wù)等方面的應(yīng)用都取得較大的進(jìn)步和提升.

以運(yùn)營管理為例, 為我行數(shù)據(jù)管理和日常運(yùn)營打造的移動(dòng)端數(shù)據(jù)可視化項(xiàng)目--“慧視”, 擁有“慧決策”、“慧管理”、“慧算賬”、“鷹眼”等系列產(chǎn)品, 著眼于移動(dòng)優(yōu)先、數(shù)據(jù)可視化、便捷高效、體驗(yàn)第一的項(xiàng)目目標(biāo),滿足總行領(lǐng)導(dǎo)、分行行長、支行行長、網(wǎng)點(diǎn)負(fù)責(zé)人、各管理?xiàng)l線負(fù)責(zé)人等全行各級(jí)管理者的數(shù)據(jù)需求. 依托企業(yè)級(jí)統(tǒng)一數(shù)據(jù)視圖, 自2017年上線以來, 已經(jīng)涵蓋16個(gè)崗位角色、實(shí)現(xiàn)600+指標(biāo)數(shù)據(jù)的移動(dòng)端可視化. 目前, “慧視”已在全行范圍內(nèi)推廣, 得到各級(jí)管理者的廣泛好評(píng).

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

在風(fēng)險(xiǎn)管控方面, 隨著企業(yè)級(jí)反欺詐聯(lián)合防控方案落地, 業(yè)務(wù)功能全部釋放, 實(shí)現(xiàn)“五個(gè)首次”——首次建立信用卡、借記卡的首筆實(shí)時(shí)偵測能力, 首次將借記卡、善融商務(wù)、電話支付業(yè)務(wù)納入反欺詐監(jiān)測范圍,首次將監(jiān)測對(duì)象擴(kuò)大到所有對(duì)私客戶和收單商戶, 首次建立統(tǒng)一的欺詐告警和案件管理機(jī)制, 首次建立全面的客戶行為檔案.

實(shí)踐證明, 商業(yè)銀行通過引入基于開放硬件平臺(tái)的技術(shù)和產(chǎn)品, 結(jié)合自身的業(yè)務(wù)和應(yīng)用特點(diǎn)自主研發(fā)融合多種大數(shù)據(jù)技術(shù)的企業(yè)級(jí)分析處理平臺(tái)是可行的,而且比單一的、傳統(tǒng)的軟硬件一體方案具有明顯的優(yōu)勢.