189 8069 5689
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 与其他数据库实时对接的中间件。
