金融行業(yè)批量系統(tǒng)存儲架構(gòu)技術(shù)選型分析

一、金融行業(yè)批量系統(tǒng)業(yè)務(wù)特征提起批量業(yè)務(wù)，從事銀行業(yè)科技的人員都會非常熟悉。白天的柜臺、終端以及其他渠道的交易業(yè)務(wù)需要實時修改賬戶信息，晚上需要跑批來完成例如賬務(wù)清算、利息計算、報表生成等系列業(yè)務(wù)。這就是銀行典型批量業(yè)務(wù)需要完成的事情。而對于其他的保險及證券等金融行業(yè)，同樣會有類似的批量業(yè)務(wù)。通常金融行業(yè)業(yè)務(wù)系統(tǒng)產(chǎn)生的明細(xì)數(shù)據(jù)要經(jīng)過加工處理，按照一定邏輯計算成需要的結(jié)果，用以支持企業(yè)的經(jīng)營活動。這類數(shù)據(jù)的加工任務(wù)一般會有很多個，需要批量完成計算。大部分業(yè)務(wù)統(tǒng)計都會要求以某日作為截止點，而且為了不影響生產(chǎn)系統(tǒng)的運行，跑批任務(wù)一般會在夜間進(jìn)行，這時候才能將生產(chǎn)系統(tǒng)當(dāng)天產(chǎn)生的新明細(xì)數(shù)據(jù)導(dǎo)出來，送到專門的數(shù)據(jù)庫或數(shù)據(jù)倉庫完成跑批計算。第二天早上，跑批結(jié)果就可以提供給業(yè)務(wù)人員使用了。和在線查詢不同，跑批計算是定時自動執(zhí)行的離線任務(wù)，不會出現(xiàn)多人同時訪問一個任務(wù)的情況，所以沒有并發(fā)問題，也不必實時返回結(jié)果。但是，跑批必須在規(guī)定的窗口時間內(nèi)完成。比如某銀行的跑批窗口時間是晚上到第二天早上，如果到了早上跑批任務(wù)還沒有完成，就會造成業(yè)務(wù)人員無法正常工作的嚴(yán)重后果。而且跑批任務(wù)涉及的數(shù)據(jù)量非常大，通常是需要很多系統(tǒng)的數(shù)據(jù)，同時包含歷史數(shù)據(jù)；計算邏輯通常非常復(fù)雜，不僅處理較長、步驟較多、而且計算頻繁，是需要在某些業(yè)務(wù)模型基礎(chǔ)之上去完成的；跑批時間經(jīng)常是以小時甚至更長時間粒度來計算的。隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量還在不斷增加，跑批數(shù)據(jù)庫的負(fù)擔(dān)快速增長，就會發(fā)生整晚都跑不完的情況，嚴(yán)重影響用戶的業(yè)務(wù)，這是無法接受的。二、金融行業(yè)批量業(yè)務(wù)的數(shù)據(jù)管理要求2.1數(shù)據(jù)處理量級提升的要求近些年來，對金融行業(yè)批量業(yè)務(wù)挑戰(zhàn)最大的可能就是數(shù)據(jù)量的劇增了。以某消費金融公司為例，該消費金融公司于2015年營業(yè)，截止到2020年，歷經(jīng)4年多風(fēng)雨，總注冊用戶數(shù)8000萬，活躍用戶數(shù)2500萬，賬務(wù)系統(tǒng)的核心表累計數(shù)據(jù)量已達(dá)到單表15億行以上，而且還在高速增長中。這是大多數(shù)金融企業(yè)面對互聯(lián)網(wǎng)業(yè)務(wù)時都會遇到的巨大挑戰(zhàn)。很多金融行業(yè)批量業(yè)務(wù)系統(tǒng)在面對海量數(shù)據(jù)的不斷挑戰(zhàn)，數(shù)據(jù)庫從傳統(tǒng)的Oracle單庫模式走向集群模式，從單表單庫走向分庫分表切片模式，甚至開始選擇NoSQL、NewSQL解決方案；基礎(chǔ)架構(gòu)從從前的小型機(jī)走向一體機(jī)，從一體機(jī)走向分布式模式?？偠灾?，金融行業(yè)批量業(yè)務(wù)在當(dāng)前以及未來一段時間內(nèi)面臨的最大挑戰(zhàn)還是數(shù)據(jù)量的升級，這必然要求數(shù)據(jù)處理層面具備更強(qiáng)的數(shù)據(jù)容納以及過程處理能力。2.2數(shù)據(jù)批量讀寫效率提升的要求對于金融行業(yè)的批量業(yè)務(wù)，從業(yè)務(wù)層面來講，它是賬務(wù)清算、利息核算、報表分析之類的分析業(yè)務(wù)。從數(shù)據(jù)處理層面來講，它是對多系統(tǒng)多維度數(shù)據(jù)進(jìn)行讀取、歸類、統(tǒng)計、分析、寫入的整體過程，里面伴隨著大量的順序讀寫全表操作，數(shù)據(jù)量會非常大。而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫最忌諱的卻是數(shù)據(jù)庫當(dāng)中的全表掃描操作，當(dāng)單表數(shù)據(jù)量達(dá)到一定程度之后，必然會影響數(shù)據(jù)庫的整體檢索效率，這二者之間似乎是有不可調(diào)和的矛盾。于是行業(yè)內(nèi)企業(yè)開始尋求相應(yīng)的解決方法，一方面通過各種方法來提升數(shù)據(jù)處理平臺本身對數(shù)據(jù)讀寫的處理效率，例如利用全閃存儲架構(gòu)從物理層提升數(shù)據(jù)的處理效率，利用分布式存儲架構(gòu)來提升存儲引擎的吞吐效率；另外一方面通過對業(yè)務(wù)邏輯及模型的革新創(chuàng)新來尋求新的整體解決方案。2.3數(shù)據(jù)處理邏輯多樣化融合的要求以銀行的批量業(yè)務(wù)為例，傳統(tǒng)的批量業(yè)務(wù)系統(tǒng)，無論是賬務(wù)類的總賬跑批，還是監(jiān)管報送類的報表跑批，它們都是基于傳統(tǒng)的二維關(guān)系數(shù)據(jù)模型，跑批的邏輯都是基于銀行特有的業(yè)務(wù)模型。這種模式下的批量業(yè)務(wù)都會涉及到數(shù)據(jù)一致性的問題，典型的場景就是外鍵關(guān)聯(lián)的場景。當(dāng)我們對其中一張表的數(shù)據(jù)進(jìn)行更改的時候，如果它有相關(guān)的外鍵約束或者關(guān)聯(lián)約束，那么必然會涉及數(shù)據(jù)庫對數(shù)據(jù)一致性的檢查及處理。對于傳統(tǒng)的賬務(wù)類批量來講，這是必然的選擇，但是對于其他統(tǒng)計分析類的報表類批量業(yè)務(wù)，尤其是基于互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)數(shù)據(jù)設(shè)計的批量報表業(yè)務(wù)，對數(shù)據(jù)間的相互約束并不敏感，而是聚焦數(shù)據(jù)在其他維度的總體特征分析，因此某些列式數(shù)據(jù)存儲解決方案反而更契合。因此，金融行業(yè)在堅持批量業(yè)務(wù)系統(tǒng)既有載體架構(gòu)方案升級改善的同時，探討新型的數(shù)據(jù)處理解決方案，并且能將這集中元素應(yīng)用到數(shù)據(jù)后臺批量業(yè)務(wù)當(dāng)中，是一種必然的趨勢。三、金融行業(yè)批量業(yè)務(wù)存儲架構(gòu)選型技術(shù)分析3.1列式存儲的存儲方式與批量查詢之間的契合點對于某些需要根據(jù)字段特點進(jìn)行統(tǒng)計、排序、篩選的批量分析類業(yè)務(wù)，列式存儲的效率要比行式存儲的效率高很多。數(shù)據(jù)量越大，這個優(yōu)勢越明顯，到了單機(jī)資源無法處理的規(guī)模，這個優(yōu)勢就更加突出了。但是如果遇到需要精準(zhǔn)定位到某一條數(shù)據(jù)，并且進(jìn)行多字段處理的場景，列式存儲就顯得笨重很多。以傳統(tǒng)關(guān)系數(shù)據(jù)庫為載體的批量業(yè)務(wù)系統(tǒng)，必然會涉及到相關(guān)的外鍵約束或者關(guān)聯(lián)約束，這會帶來兩個問題：一是數(shù)據(jù)處理效率的問題，關(guān)聯(lián)約束的檢查及關(guān)聯(lián)操作必然帶來多余的操作代價。二是數(shù)據(jù)處理過度依賴單節(jié)點資源，無法實現(xiàn)分布式處理。既然我們要顧及數(shù)據(jù)之間的橫向聯(lián)系，那么必然導(dǎo)致數(shù)據(jù)無法切分，分布式處理也無法保障關(guān)聯(lián)約束。而列式數(shù)據(jù)庫的原則是要拋棄數(shù)據(jù)之間的外鍵關(guān)聯(lián)約束，希望將數(shù)據(jù)切分為相互之間獨立的數(shù)據(jù)表。這樣的優(yōu)勢有很多，首先我們可以對數(shù)據(jù)進(jìn)行切片，無論是通過哈希算法還是通過其他算法，數(shù)據(jù)更容易切片交由不同節(jié)點分布式處理。其次，當(dāng)我們對數(shù)據(jù)進(jìn)行批量的插入、刪除、更新的時候，我們無需付出不可估量的關(guān)聯(lián)性代價?；蛟S在數(shù)據(jù)量可觀的情況下，這個優(yōu)勢不會被人過于關(guān)注。但是一旦當(dāng)數(shù)據(jù)量的處理超過單節(jié)點資源能夠完成的邊界，我們唯一可以選擇的就是列式存儲，甚至我們不惜花費大量的開發(fā)代價去改變業(yè)務(wù)邏輯，使之前下沉到數(shù)據(jù)庫的關(guān)聯(lián)性約束上浮到業(yè)務(wù)控制層面。3.2列式存儲與數(shù)據(jù)存取效率的契合性首先，列式存儲最大特點在于其數(shù)據(jù)壓縮消重的優(yōu)勢，因為按照現(xiàn)實世界的特點來看，大部分重復(fù)數(shù)據(jù)在某一個維（列）上，那么這就給了列式存儲消重最大的優(yōu)勢。在一片連續(xù)的物理存儲空間上處理一些重復(fù)數(shù)據(jù)，總比在雜亂無序的物理存儲空間上處理一些隨機(jī)的重復(fù)數(shù)據(jù)要提高很多效率。這個效率的提高帶來的是CPU、內(nèi)存、磁盤等各個資源的代價減少。其次，當(dāng)我們要對數(shù)據(jù)的維和度進(jìn)行具體的OLAP分析的時候，我們需要把大量的數(shù)據(jù)讀入到內(nèi)存進(jìn)行深度的處理，比如排序、分類、分組、篩選、統(tǒng)計等等。從物理存儲讀入數(shù)據(jù)到內(nèi)存本身的效率是非?？捎^的，在內(nèi)存當(dāng)中處理少量的數(shù)據(jù)要比處理帶有重復(fù)數(shù)據(jù)的大量數(shù)據(jù)要效率得多。很多事情就是因為這不同環(huán)節(jié)上的少量提高而發(fā)生了整體上的指數(shù)級別的改變，將不可能變成可能?；蛟S我們可以通過微觀和宏觀的理論來解釋其中的細(xì)節(jié)。再有，忽略數(shù)據(jù)字段之間的關(guān)聯(lián)性的列式存儲解決方案，使得數(shù)據(jù)具備了切片分庫的基本條件，也具備了分布式架構(gòu)的應(yīng)用前提，而且分布式的擴(kuò)展性會更好，無疑這又提高了批量系統(tǒng)對數(shù)據(jù)處理的整體吞吐量和引擎的整體處理效率。或許我們可以說這個是通過犧牲了數(shù)據(jù)的完整性約束來換取的，如果業(yè)務(wù)本身沒有這種需求，我們丟掉這個特性換取“分布式”的特性，又有何妨呢？很多人可能會抬出CAP理論來講，沒錯，我們承認(rèn)CAP理論的正確性，但是在OLAP業(yè)務(wù)場景當(dāng)中，我們看到的更多的是數(shù)據(jù)宏觀維度的抽象屬性，是基于大量數(shù)據(jù)的同緯同度分析之后的價值，而不在于單個數(shù)據(jù)之間的嚴(yán)格約束，所