核心業務“瘦身”進行時！手把手帶你搭建海量數據實時處理架構

01 背景

在線交易服務平臺目的是減輕核心系統計算壓力和核心性能負荷壓力，通過該平臺可以將核心系統的交易數據實時捕獲、實時計算加工、計算結果保存于SequoiaDB中。并能實時的為用戶提供在線交易查詢服務。在線交易服務平臺基于實時處理架構設計，通過將核心系統的數據變更，實時的同步到在平臺數據庫，從而達到數據實時復制，及向外提供服務的目的。

本文旨在分析實時處理系統的各技術原理及整體架構。首先介紹該架構所用到的技術原理，然后再介紹整體架構實現，并從數據采集層，實時處理層，數據存儲層等方面進行詳細分析與說明。
 
02 技術需求
2.1 如何構建數據庫日志文件實時采集系統

該平臺需要從銀行多個交易系統中，實時獲取客戶余額變動和交易明細數據。該過程要求數據采集組件能夠提供高性能、高可用性、高安全可靠性的實時采集、傳輸功能，因此我們采用了具備這些特性的 OGG 和 CDC 采集框架。

CDC（Change Data Capture）：基于數據庫日志實現對數據源變化的實時捕獲，并且實時傳輸到目標端。CDC組件通過讀取各個業務生產系統數據庫的日志文件捕獲得到更新（插入、刪除、更新）的交易記錄信息數據，經過行列過濾，字符編碼轉換后由 TCP/IP 發送給目標端，目標端接收到源端數據后，經過數值轉換，字符編碼轉換，沖突檢測后將變更數據通過 Confluent Rest API 把數據傳送到 Kafka，將數據直接進行持久化之前進行消息隊列的數據緩存。

OGG（Oracle GoldenGate）是一種基于日志的挖掘的技術，它通過解析源數據庫在線日志或歸檔日志獲得數據的增量變化后，再將這些變化的數據傳輸到 Kafka 中，Kafka將數據直接進行持久化之前進行消息隊列的數據緩存。
 
2.2 如何保證對海量數據的實時處理

相比其他實時處理框架如 Spark 來說，Storm 的實時性較高，延時低，而在線交易服務平臺實時性要求比較高，要求毫秒級的數據處理。Storm 作為純實時的計算框架，其實時計算能力能達到毫秒級。

Storm 是基于數據流的實時處理系統，提供了大吞吐量的實時計算能力。在一條數據到達系統的時候，系統會立即在內存中進行相應的計算，因此 Storm 適合要求實時性較高的數據分析場景。此外，Storm 支持分布式并行計算，即使海量數據大量涌入，也能得到實時處理。Storm 還具備以下幾個優點：低延遲、高可用、分布式、可擴展、數據不丟失，并且提供簡單容易理解的接口，便于開發。
 
2.3 如何實現采集層與實時處理層的對接

在采集層和實時處理層之間，往往需要加一個消息隊列機制，用于實現采集層與實時處理層的解耦，并緩存需要實時處理的數據，保證所有數據都能被有序的正確的處理。

此外，從源端采集的數據流并不是均勻的，而是時而多時而少的數據流。特別是在高并發的條件下，數據庫日志的數據會出現井噴式增長，如果 Storm 的消費速度(即使 Storm  的實時計算能力已經很快了)慢于日志的產生速度，必然會導致大量數據滯后和丟失，因此我們加上 Kafka 消息系統作為數據緩沖區，Kafka 可以將不均勻的數據轉換成均勻的消息流，從而與 Storm 結合起來，實現穩定的流式計算。

Kafka 是一個分布式的、分區化、可復制提交的日志服務。作為一個可擴展、高可靠的消息系統，在流處理中，經常用來保存收集流數據，提供給之后對接的 Storm 流數據框架進行處理。作為一個消息隊列系統，與大多數消息系統比較，Kafka 具有更好的吞吐量、內置分區、副本和故障轉移等功能，這有利于及時處理大規模的消息。
 
03 SequoiaDB 作為存儲層的優勢

在線交易服務平臺需要滿足實時處理之后海量數據的高速存儲和高效檢索，并且需要保證數據的可用性與可靠性。SequoiaDB 是一款優秀的分布式數據庫，可以被用來存儲海量的數據，其底層主要基于分布式、高可用、高性能與動態數據類型設計，同時兼顧了關系型數據庫中眾多的優秀設計如事務、多索引、動態查詢和更新、SQL等。利用巨杉數據庫自身的分布式存儲機制與多索引功能，能夠很好地為應用提供高并發、低延時的查詢、更新、寫入和刪除操作服務。



SequoiaDB 使用 MPP（海量并行處理）架構，整個集群主要由三個角色構成，分別是協調節點，編目節點和數據節點。其中，編目節點存儲元數據，協調節點負責分布式系統的任務分發，數據節點負責數據存儲和操作。當有應用程序向協調節點發送訪問請求時，協調節點首先通過與編目節點通信，了解底層數據存儲的結構與規則，再將查詢任務分發給不同的數據節點，然后聚合所有數據節點上的結果，并將結果排序作為合適的查詢結果。

SequoiaDB 具備以下幾點優勢：

1) 具備豐富的查詢模型：SequoiaDB 適合于各種各樣的應用程序。它提供了豐富的索引和查詢支持，包括二級索引，聚合框架等。

2) 具有常用驅動：開發者整合了系統環境和代碼庫的原生驅動庫，通過原生驅動庫與數據庫交互，使得 SequoiaDB 的使用變得簡單和自然。

3) 支持水平可擴展：開發人員能夠利用通過服務器和云基礎架構來增加 SequoiaDB 系統的容量，以應對數據量和吞吐量的增長。

4) 高可用性：數據的多份副本通過遠程復制來維護。遇到故障系統會自動轉移到輔助節點、機架和數據中心上，使得企業不需要自定義和優化代碼，就能讓系統正常運行。

5) 內存級的性能：數據在內存中直接讀取和寫入。并且為了系統的持久性，系統會在后臺持續把數據寫入磁盤。這些都為系統提供了快速的性能，使得系統無需使用單獨的緩存層。
 
04 技術架構

實時處理架構主要分為數據實時采集，實時處理，實時存儲三個模塊。其中 CDC，OGG用來獲取數據，Kafka 用來臨時保存數據，Strom 用來進行數據實時計算，SequoiaDB是分布式數據庫，用來保存數據。



整個實時分析系統的架構先由 OGG/CDC 實時捕獲數據庫日志文件，提取其中數據的變化，如增、刪、改等操作，并存進 Kafka 消息系統中。然后由 Storm 系統消費 Kafka 中的消息，消費記錄由 Zookeeper 集群管理，這樣即使 Kafka 宕機重啟后也能找到上次的消費記錄。接著從上次宕機點繼續從 Kafka 的 Broker 中進行消費，并使用定義好的 Storm Topology 去進行日志信息的分析，輸出到 SequoiaDB 分布式數據庫中進行持久化，最后提供在線實時查詢接口供用戶進行查詢。
 
4.1 數據采集

在日志收集流程方面，針對不同的系統環境，我們設計了不同的采集流程。外圍系統采用實時數據同步工具 OGG 進行數據實時采集。OGG 通過捕捉進程在源系統端讀取數據庫日志文件進行解析，提取其中數據的變化如增、刪、改等操作，并將相關信息轉換為自定義的中間格式存放在隊列文件中，再利用傳送進程將隊列文件通過 TCP/IP 傳送到 Kafka 隊列中。



而對于核心系統，通過在核心系統源端部署 InfoSphere CDC 實時采集數據庫日志及其文件以捕獲源端數據庫產生的更新（插入、刪除、更新）交易記錄信息，通過連續鏡像運行模式，不間斷地把最新交易數據傳送到目標端。在目標系統上同樣運行  InfoSphere  CDC，接收來自于不同源系統傳過來的數據，再通過 Confluent Rest API把數據傳送到 Kafka，在對數據進行計算或者直接進行持久化之前進行消息隊列的數據緩存。
 
4.2 實時處理

這里采用 Storm 進行實時處理，Storm 作為實時處理框架具備低延遲、高可用、分布式、可擴展、數據不丟失等特點。這些特點促使 Storm 在保證數據不丟失的前提下，依然具備快速的處理速度。

在 Storm 集群中 Master 節點上運行的一個守護進程叫“Nimbus”，負責集群中計算程序的分發、任務的分發、監控任務和工作節點的運行情況等；Worker 節點上運行的守護進程叫“Supervisor”，負責接收 Nimbus 分發的任務并運行，每一個 Worker 上都會運行著 Topology 程序的一部分，而一個 Topology 程序的運行就是由集群上多個 Worker 一起協同工作的。Nimubs 和 Supervisor 之間的協調工作通過 Zookeeper 來管理，Nimbus 和 Supervisor 自己本身在集群上是無狀態的，它們的狀態都保存在 Zookeeper 上，所以任何節點的宕機和動態擴容都不會影響整個集群的工作運行，并且支持 fast-fail 機制。

在 Storm 上做實時計算，需要自定義一個計算程序“Topology”，一個 Topology 程序由 Spout 和 Bolt 共同組成，Storm 就是通過 Topology 程序將數據流 Stream 通過可靠(ACK機制)的分布式計算生成我們的目標數據流 Stream。我們使用 Kafkaspout從 Kafka 的 queue 中不間斷地獲得對應的 topic 數據，然后通過自定義 bolt 來做數據處理，分別區分出增、刪、改記錄，再通過自定義 bolt 來調用 SequoiaDB API 對SequoiaDB 數據庫進行對應的增，刪，改操作，從而達到對源數據實時復制的目的。

 
4.3 數據存儲

數據源獲取數據經過 Kafka 和 Storm實時處理之后，通過調用 SequoiaDB API 接口將實時解析后的數據存儲到 SequoiaDB 中。通過 SQL 查詢 SequoiaDB 為 OLAP 場景提供支持，也可通過 JDBC 為在線應用提供 OLTP 服務。

將海量數據保存在 SequoiaDB 分布式數據庫中，利用其數據庫自身的分布式存儲機制與多索引功能，能夠很好地為應用提供高并發、低延時的查詢，以及更新、寫入和刪除操作等服務。



SequoiaDB 數據庫底層采用多維分區的方式將海量數據分散到多個數據分區組上進行存儲。該方式通過結合了 Hash 分布方式和 Partition 分布方式的優點，讓集合中的數據以更小的顆粒度分布到數據庫多個數據分區組上，從而提升數據庫的性能。


采用分區的目的主要是為了解決單臺服務器硬件資源受限問題，如內存或者磁盤 I/O 瓶頸問題，使得機器能夠得到橫向擴展；此外還能將系統壓力分散到多臺機器上，從而提高系統性能，并且不會增加應用程序復雜性。同時結合 SequoiaDB 的副本模式，保證系統的高可用性。

 
05 實現價值
5.1 商業價值

越來越多的企業不再滿足于通過夜間運行批量任務作業的方式來處理信息，更傾向于實時地獲取數據的價值。他們認為數據的價值只有在剛產生時才是最大的，認為在數據剛產生時就移動、處理和使用才是最有意義的。在線交易服務平臺作為實時處理架構的最佳實踐，將各個系統的數據進行實時處理，整合得到有價值的數據，并將其保存到 SequoiaDB 數據庫中供用戶實時查詢使用。數據實時處理系統不僅提高了用戶的滿意度，還將實時處理技術與實際業務應用有效地結合了起來。在未來，將會有更多的業務場景需要該技術的支持。

 
5.2 技術價值

一個穩定可靠且高效的實時處理架構是將實時數據轉化為價值的基礎。在線交易服務平臺作為由數據實時處理架構搭建起來的平臺，能夠穩定的在生成環境中運行，提供高效的服務，在技術上具有很高的參考價值。該數據實時處理架構實現了 SequoiaDB 與其他數據庫的實時對接，能夠方便從其他數據庫中遷移和備份數據，可以作為 SequoiaDB  與其他數據庫實時對接的中間件。