用户案例 | 巨杉数据库在银行实时数据处理的规模实践

巨杉数据库 2020-06-02

1793

背景

在过去，银行等机构的IT应用系统之间大数据量的交换方式主要是次日（T+1）定时抽取数据文件。这种传统方式具备很多优点，例如技术简单，消耗资源少，系统间耦合度低，对源系统影响小，可以分发数据给多个目标系统。但是，随着互联网金融的高速发展，对多元化业务的需求日益增长。在互联网带来便捷的同时，也带来了高风险。而分时T+1的数据处理或分析，已经不能满足客户的需求、银行的风险控制等。而搭建实时数据服务平台能够很好的解决以上问题，为客户及业务人员提供更好、时效性更高的数据支持与服务。

实时数据服务平台的目标定位是建设企业级的数据服务平台，为大部分生产系统（例如核心系统、信贷系统、报表系统等）提供服务的数据中心，并提供统一的标准化的数据采集和分发接口，同时需要实现海量的多模式数据的存储、查询及管理，使用分布式的系统布署方式。

实时数据服务平台需求要点：

支持常见数据数据库的数据实时采集，快速发现数据变化，能够保持数据一致，即正确同步源系统数据并且不改变数据逻辑；
支持大规模高并发数据流的缓存队列，易于扩容；
支持高并发实时数据加工计算；
低成本的分布式存储管理海量数据，支持大规模高并发处理能力，支持同城双活、异地灾备；
提供对外查询服务，服务支持权限管理、元数据管理、监控管理等，服务支持集群化部署，具备高可用机制，无单点故障。

本文也将从巨杉数据库在某大型股份制银行的应用案例出发，向大家详细介绍分布式数据库在处理实时数据服务场景中的架构设计和技术实践思路。

逻辑架构

实时数据服务的主要逻辑架构应该包括数据采集、数据处理、数据存储和接口服务等层次。实时数据流从采集层次进入，经过数据处理和存储层次之后，通过数据接口服务层流出系统。

总体的逻辑架构如下图所示：

数据源

数据源是数据的产生者。数据源产生的数据作为实时数据交换系统的输入数据，供数据消费者使用。

实时数据交换系统需要支持如下类型的数据源的接入，即可以采集如下类型的数据源：

1. 常见关系型数据库，例如Oracle、DB2等数据库；

2. 数据文件，例如应用日志文件、系统日志等；

数据采集服务模块需要在数据源端部署数据采集组件，方能实现实时探知数据变化，并将变化数据采集发送到实时数据交换系统服务端。

实时服务层

实时服务层作为实时数据系统的主要处理逻辑实现层，主要功能模块为：

实时数据采集服务

实时数据采集服务中的主要功能是接收、加工、计算、入库、分发、监控、管理等功能。

- 接收：接收部署于数据源端负责实时采集的客户端程序发送来的数据；

- 缓存：为了增加系统的吞吐能力及稳定性，大规模并发缓存队列就是必须的组件。接收到的大量数据需要实时存入缓存；

- 加工：数据解析、过滤、分区、提取、转码均为数据加工范畴；

- 计算：数据计数、累加、均值、派生、关联、聚合、预测等功能均为数据计算范畴；

- 入库：将数据持久化存储进入海量大规模数据库，便于数据计算、查询和归档；

- 分发：数据经过加工、计算之后，需要分发给数据订阅者。分发的形式可以是主动推送，也可以是被动等待订阅者来读取；

数据缓存队列

实时数据交换系统的数据吞吐量巨大，缓存非常必要。而且，数据流需要保持先进先出的次序关系。所以，大规模并发分布式缓存队列是重要的功能组件。

数据缓存队列需根据数据源、数据对象两个维度划分队列分区，以保障最大程度的并发能力，从而保证高吞吐量的需求。

监控和管理

- 监控：服务状态、性能、资源使用率均需监控，展示和告警功能也同样具备；

- 管理：任务、规则、参数均可配置，并且有方便快捷的管理界面；

数据存储层

数据存储层同样是高并发分布式数据库集群，用于统一存储来源多样的海量多模式数据。

此处使用的就是巨杉数据库，因此技术特性和巨杉数据库保持一致。

接口层

接口层是指系统对外提供服务的接口。对外服务的接口主要分为三类：

- 数据查询：系统对外提供数据查询功能，接口的形式可以是Rest、JDBC、Java SDK等；

- 管理指令：管理指令接口主要用于管理元数据，管理各级服务，监控服务状态等功能。管理指令的接口形式是Rest。

技术方案

整体架构方案通过数据实时抽取+复制的机制，将业务系统源库中的数据或日志数据实时抽取并发送至缓存队列。流处理引擎则从缓存队列中分批拉取数据，对每一条数据进行解析和加工，并复制到实时数据服务平台的对应模型中。该平台同时需要满足实时查询的需求，可满足数据查询下移、实时统计、预测等业务需求。

数据采集

在数据采集方面，采用Oracle Golden Gate（简称OGG）。OGG可以实时监控数据库日志变化，如增、删、改操作，并将相关信息转换为自定义的中间格式存放在队列文件中，再利用传送进程将队列文件通过TCP/IP发送到目标端。

Extract：Extract 进程运行在数据库源端上，它是OGG的捕获机制，可以配置Extract 进程完成“初始化数据”和“ 同步数据变化”。
Data Pump：是一个配置在源端的辅助的 Extract 机制，是一个可选组件，如果不配置 Data Pump，那么由 Extract 主进程将数据发送到目标端的 Remote Trail 文件中，如果配置了 Data Pump，会由 Data Pump将Extract 主进程写好的本地 Trail 文件通过网络发送到目标端的 Remote Trail 文件中。
Trail：为了持续地提取与复制数据库变化，OGG将捕获到的数据变化临时存放在磁盘上的一系列队列文件中，这些文件叫做 Trail 文件。
Collector：Collector 是运行在目标端的一个后台进程，接收从 TCP/IP 网络传输过来的数据库变化，并写到 Trail 文件里。
Replicat：Replicat 进程是运行在目标端系统的一个进程，负责读取 Extract 进程提取到的数据并应用到目标数据库，可以配置 Replicat 进程完成“初始化数据”和“数据复制”。

数据缓存

在采集层和实时处理层之间，我们往往需要加上一个消息队列机制，用于实现采集层与实时处理层的解耦，并缓存需要实时处理的数据，保证所有数据都能被有序的正确的处理。

此外，由于从源端采集的数据流并不是均匀的，而是时而多时而少的数据流。特别是在高并发的条件下, 数据库的数据会出现井喷式增长，如果数据实时处理的速度慢于源端数据的产生速度，必然会导致大量数据滞后并丢失，因此我们加上Kafka消息系统作为数据缓冲区，作为一个可扩展、高可靠的消息系统，在流处理中，经常用来对接流数据框架进行处理。作为一个消息队列系统，与大多数消息系统比较，kafka据有更好的吞吐量，内置分区，副本和故障转移，这有利于处理大规模的消息。

OGG发送到Kafka队列的消息指定为JSON格式，需包含以下字段：

{
“table”:      表名，以schema.tablename作为表名
“op_type”:     操作类型（I、U、D）（I:insert、U:update、D:delete）
“op_ts”:      本条消息在OGG源端抽取的时间戳
“current_ts”:     本条消息同步到Kafka的时间戳
“pos”:      消息在OGG源端trail文件中的位置（sequence number+offset）
“primary_keys”:     表的主键字段
“before”:      // 操作执行前的数据
“after”:      // 操作执行后的数据
}

数据加工

数据加工层采用Spark Streaming实时流处理框架。在该层中，使用可靠读取的方式从Kafka队列中获得相应的数据，然后在JSON数据中解析表名，操作符以及时间戳，再根据操作符解析需要的插入、删除、更新的相应字段。

数据处理流程：

1. SparkStreaning 引擎根据配置的批处理间隔，Driver 进程周期性的查询Kafka对应topic的偏移量，如果有新的数据到达，Driver 将消息的分区和偏移量信息传递给各Excutor进程，Excutor 进程拉取对应的数据。

2. 流程序根据 JSON 格式消息中的表名称，获取该表对应目标库（SequoiaDB）表名称和字段类型。

3. 获取到集合空间和集合后，将消息中的字段值进行相应的类型转换，并生成对应的 BSONObject 对象，最后执行对应的更改。

4. Driver 进程向 kafka 提交处理完成的消息偏移量。

数据存储

数据的存储采用分布式数据库 SequoiaDB。将海量数据保存在 SequoiaDB 分布式数据库中，利用数据库自身的分布式存储机制与多索引功能，能够很好地为应用提供高并发、低延时的查询服务。

SparkStreaming 实时处理数据时，通过调用 SequoiaDB 原生 API 接口将解析后的数据存储到SequoiaDB中，数据库底层采用多维分区的方式将数据分散到多个数据分区组上进行存储。该方式通过结合了 Hash 分布方式和 Range 分布方式的优点，让集合中的数据以更小的颗粒度分布到数据库多个数据分区组上，从而提升数据库的性能。

采用分区的目的主要是为了解决单台服务器硬件资源受限问题，如内存或者磁盘 I/O 瓶颈，使得机器能够得到横向扩展；此外还能将系统压力分散到多台机器上，从而提高系统性能，并且不会增加应用程序复杂性。再结合 SequoiaDB 的副本模式，保证系统的高可用性。

数据查询

查询服务采用微服务架构，基于 SpringCloud 框架进行开发，通过Rest进行远程服务调用，并且封装了驱动包，便于业务系统与查询服务对接。

为了在不同的查询场景能够提供最优的查询效率，提供了两种查询引擎：PostgreSQL、SparkSQL，这两种引擎通过与 SequoiaDB 对接实现 SQL 的解析与计算，只存储表的元数据信息，实际数据内容存储于 SequoiaDB。

引擎适用场景：

PostgreSQL：适用于查询条件相对固定的精准类查询，单表查询或多表关联且根据关联条件筛选后结果集较小的查询。

Note：为了避免单点故障以及承受高并发下的查询要求，PG部署为集群模式，并使用pg-pool II软件管理PG集群，实现负载均衡以及故障转移功能。

SparkSQL：适用于多表关联且语句较为复杂的统计分析类查询，能够提供优于传统关系型数据库的查询效率。

Note：服务内部使用JDBC的方式来连接查询引擎，所以启用了Spark提供的thrift-server服务来使用SparkSQL。

项目成果

实时数据交换平台目前已经在超过20家银行用户上线生产。其中在一家大型股份制银行，基于巨杉数据库构建的实时数据服务平台，已经服务包括ECIF，借记卡核心，用户CRM等在内的超过30个业务系统，总部署超过50台物理服务器。

银行用户的实时数据交换平台未来还将进一步拓展为全行范围内的统一数据交换平台，为不同业务系统提供历史数据和准实时数据的大规模并发、大规模数据吞吐量的查询服务。各业务系统的数据集中存放于数据交换平台，可以提升数据关联价值，也可以起到数据归档作用。在当前实时数据处理基础上，还将持续增加包括元数据管理、数据生命周期管理在内的多种解决方案。

小结

本文主要介绍了实时数据服务平台的整体架构，以及架构中各个组成模块的作用和技术实现细节，从数据采集层，数据处理层，数据存储层、数据查询等方面进行了详细分析与说明。帮助读者对基于 SequoiaDB 搭建的实时数据服务平台有个清晰且全面的了解。

越来越多的企业倾向于实时的获取数据的价值，而不满足于通过夜间运行批量任务作业的方式来处理信息的方式了。他们认为数据的价值只有在刚刚产生时才是最大的，而且在数据刚一产生就对它进行移动、处理和使用才是最有意义的。实时数据服务平台将银行各个系统的数据实时的处理，整合得到有价值的数据保存到 SequoiaDB 巨杉数据库中供用户实时查询使用。不仅提高了用户的满意度，还将实时处理技术与实际业务应用有效地结合起来，促进实时处理技术的落地。未来将会有更多的业务场景需要该技术的支持。

一个稳定可靠且高效的实时处理架构是体现实时数据价值的基础，实时数据服务平台的搭建，能够稳定的在生产环境中运行，提供高效的服务，在技术上，具有很高的参考价值。该实时数据处理架构实现了 SequoiaDB 与其他数据库实时对接，能够方便从其他数据库中实时的迁移和备份数据。