金融行業批次系統儲存架構技術選型分析

金融行業的批次業務在網際網路模式影響下，在資料量和業務型別上都面臨巨大壓力，這必將在資料處理方面帶來對容量、效率、邏輯等方面的巨大挑戰。本文從業務特徵、資料管理要求入手，進行了金融行業批次系統儲存架構選型技術分析，供同行參考。

一、金融行業批次系統業務特徵

提起批次業務，從事銀行業科技的人員都會非常熟悉。白天的櫃檯、終端以及其他渠道的交易業務需要實時修改賬戶資訊，晚上需要跑批來完成例如賬務清算、利息計算、報表生成等系列業務。這就是銀行典型批次業務需要完成的事情。而對於其他的保險及證券等金融行業，同樣會有類似的批次業務。

通常金融行業業務系統產生的明細資料要經過加工處理，按照一定邏輯計算成需要的結果，用以支援企業的經營活動。這類資料的加工任務一般會有很多個，需要批次完成計算。大部分業務統計都會要求以某日作為截止點，而且為了不影響生產系統的執行，跑批任務一般會在夜間進行，這時候才能將生產系統當天產生的新明細資料匯出來，送到專門的資料庫或資料倉儲完成跑批計算。第二天早上，跑批結果就可以提供給業務人員使用了。和線上查詢不同，跑批計算是定時自動執行的離線任務，不會出現多人同時訪問一個任務的情況，所以沒有併發問題，也不必實時返回結果。但是，跑批必須在規定的視窗時間內完成。比如某銀行的跑批視窗時間是晚上到第二天早上，如果到了早上跑批任務還沒有完成，就會造成業務人員無法正常工作的嚴重後果。而且跑批任務涉及的資料量非常大，通常是需要很多系統的資料，同時包含歷史資料;計算邏輯通常非常複雜，不僅處理較長、步驟較多、而且計算頻繁，是需要在某些業務模型基礎之上去完成的;跑批時間經常是以小時甚至更長時間粒度來計算的。隨著業務的發展，資料量還在不斷增加，跑批資料庫的負擔快速增長，就會發生整晚都跑不完的情況，嚴重影響使用者的業務，這是無法接受的。

二、金融行業批次業務的資料管理要求

2.1 資料處理量級提升的要求

近些年來，對金融行業批次業務挑戰最大的可能就是資料量的劇增了。以某消費金融公司為例，該消費金融公司於2015年營業，截止到2020年，歷經4年多風雨，總註冊使用者數8000萬，活躍使用者數2500萬，賬務系統的核心表累計資料量已達到單表15億行以上，而且還在高速增長中。這是大多數金融企業面對網際網路業務時都會遇到的巨大挑戰。很多金融行業批次業務系統在面對海量資料的不斷挑戰，資料庫從傳統的Oracle單庫模式走向叢集模式，從單表單庫走向分庫分表切片模式，甚至開始選擇NoSQL、NewSQL解決方案;基礎架構從從前的小型機走向一體機，從一體機走向分散式模式。

總而言之，金融行業批次業務在當前以及未來一段時間內面臨的最大挑戰還是資料量的升級，這必然要求資料處理層面具備更強的資料容納以及過程處理能力。

2.2 資料批次讀寫效率提升的要求

對於金融行業的批次業務，從業務層面來講，它是賬務清算、利息核算、報表分析之類的分析業務。從資料處理層面來講，它是對多系統多維度資料進行讀取、歸類、統計、分析、寫入的整體過程，裡面伴隨著大量的順序讀寫全表操作，資料量會非常大。而傳統的關係型資料庫最忌諱的卻是資料庫當中的全表掃描操作，當單表資料量達到一定程度之後，必然會影響資料庫的整體檢索效率，這二者之間似乎是有不可調和的矛盾。於是行業內企業開始尋求相應的解決方法，一方面透過各種方法來提升資料處理平臺本身對資料讀寫的處理效率，例如利用全快閃記憶體儲架構從物理層提升資料的處理效率，利用分散式儲存架構來提升儲存引擎的吞吐效率;另外一方面透過對業務邏輯及模型的革新創新來尋求新的整體解決方案。

2.3 資料處理邏輯多樣化融合的要求

以銀行的批次業務為例，傳統的批次業務系統，無論是賬務類的總賬跑批，還是監管報送類的報表跑批，它們都是基於傳統的二維關係資料模型，跑批的邏輯都是基於銀行特有的業務模型。這種模式下的批次業務都會涉及到資料一致性的問題，典型的場景就是外來鍵關聯的場景。當我們對其中一張表的資料進行更改的時候，如果它有相關的外來鍵約束或者關聯約束，那麼必然會涉及資料庫對資料一致性的檢查及處理。對於傳統的賬務類批次來講，這是必然的選擇，但是對於其他統計分析類的報表類批次業務，尤其是基於網際網路業務系統資料設計的批次報表業務，對資料間的相互約束並不敏感，而是聚焦資料在其他維度的總體特徵分析，因此某些列式資料儲存解決方案反而更契合。

因此，金融行業在堅持批次業務系統既有載體架構方案升級改善的同時，探討新型的資料處理解決方案，並且能將這集中元素應用到資料後臺批次業務當中，是一種必然的趨勢。

三、金融行業批次業務儲存架構選型技術分析

3.1 列式儲存的儲存方式與批次查詢之間的契合點

對於某些需要根據欄位特點進行統計、排序、篩選的批次分析類業務，列式儲存的效率要比行式儲存的效率高很多。資料量越大，這個優勢越明顯，到了單機資源無法處理的規模，這個優勢就更加突出了。但是如果遇到需要精準定位到某一條資料，並且進行多欄位處理的場景，列式儲存就顯得笨重很多。以傳統關聯式資料庫為載體的批次業務系統，必然會涉及到相關的外來鍵約束或者關聯約束，這會帶來兩個問題：

一是資料處理效率的問題，關聯約束的檢查及關聯操作必然帶來多餘的操作代價。

二是資料處理過度依賴單節點資源，無法實現分散式處理。既然我們要顧及資料之間的橫向聯絡，那麼必然導致資料無法切分，分散式處理也無法保障關聯約束。

而列式資料庫的原則是要拋棄資料之間的外來鍵關聯約束，希望將資料切分為相互之間獨立的資料表。這樣的優勢有很多，首先我們可以對資料進行切片，無論是透過雜湊演演算法還是透過其他演演算法，資料更容易切片交由不同節點分散式處理。其次，當我們對資料進行批次的插入、刪除、更新的時候，我們無需付出不可估量的關聯性代價。或許在資料量可觀的情況下，這個優勢不會被人過於關注。但是一旦當資料量的處理超過單節點資源能夠完成的邊界，我們唯一可以選擇的就是列式儲存，甚至我們不惜花費大量的開發代價去改變業務邏輯，使之前下沉到資料庫的關聯性約束上浮到業務控制層面。

3.2 列式儲存與資料存取效率的契合性

首先，列式儲存最大特點在於其資料壓縮消重的優勢，因為按照現實世界的特點來看，大部分重複資料在某一個維(列)上，那麼這就給了列式儲存消重最大的優勢。在一片連續的物理儲存空間上處理一些重複資料，總比在雜亂無序的物理儲存空間上處理一些隨機的重複資料要提高很多效率。這個效率的提高帶來的是CPU、記憶體、磁碟等各個資源的代價減少。

其次，當我們要對資料的維和度進行具體的OLAP分析的時候，我們需要把大量的資料讀入到記憶體進行深度的處理，比如排序、分類、分組、篩選、統計等等。從物理儲存讀入資料到記憶體本身的效率是非常可觀的，在記憶體當中處理少量的資料要比處理帶有重複資料的大量資料要效率得多。很多事情就是因為這不同環節上的少量提高而發生了整體上的指數級別的改變，將不可能變成可能。或許我們可以透過微觀和宏觀的理論來解釋其中的細節。

再有，忽略資料欄位之間的關聯性的列式儲存解決方案，使得資料具備了切片分庫的基本條件，也具備了分散式架構的應用前提，而且分散式的擴充套件性會更好，無疑這又提高了批次系統對資料處理的整體吞吐量和引擎的整體處理效率。或許我們可以說這個是透過犧牲了資料的完整性約束來換取的，如果業務本身沒有這種需求，我們丟掉這個特性換取 “分散式”的特性，又有何妨呢?很多人可能會抬出CAP理論來講，沒錯，我們承認CAP理論的正確性，但是在OLAP業務場景當中，我們看到的更多的是資料宏觀維度的抽象屬性，是基於大量資料的同緯同度分析之後的價值，而不在於單個資料之間的嚴格約束，所以這一點可以放棄，因為我們換來的是可以解決海量資料場景下的架構變革。

四、結論及展望

金融行業的批次業務在網際網路模式影響下，在資料量和業務型別上都面臨了巨大的挑戰。這必將在資料處理方面帶來對容量、效率、邏輯等方面的巨大挑戰，這也必然導致金融企業選擇在堅持傳統資料架構為基礎的前提下尋求更先進、更契合的資料儲存解決方案。