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

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 與其餘數據庫實時對接的中間件。