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

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  與其他資料庫實時對接的中介軟體。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31534344/viewspace-2659540/，如需轉載，請註明出處，否則將追究法律責任。