数据中台实时数据抽取关键技术研究

吴海涛 廖 兵 王 丹 李张泰 周文进

（1.四川明星电力股份有限公司，四川 遂宁 629000 2.北京国网信通埃森哲信息技术有限公司，北京 100031）

一、实时数据抽取现状与问题

目前数据中心的数据抽取方式大致为全量数据接入方式或基于全量对比的数据抽取技术。该方式处理效率低下，经常会造成数据积压严重，通常无法达到数据的实时性抽取任务要求。针对该问题，本系统对现今的增量抽取技术进行了研究，提出一种Change Data Capture （CDC）结合GPkafka的实时数据接入抽取技术，极大地提升了目前明星电力公司中台数据抽取实时性，达到了零数据积压的数据入库要求。

二、CDC结合GPkafka的实时数据抽取技术

1.CDC技术

CDC又称变更数据捕获（Change Data Capture）。CDC有两个模式：同步和异步。同步CDC主要是采用触发器记录新增数据，基本能够做到实时增量抽取。而异步CDC则是通过分析已经commit的日志记录来得到增量数据信息，有一定的时间延迟，并且提供了到Oracle Streams的接口。同步相对比较简单，通过触发器捕获增量数据。而异步CDC根据实现的内部机制区别，又可以分为异步HotLog模式，异步分布式HotLog模式和异步AutoLog模式[1]。

2.GPKafak

2.1 Kafka。Kafka是一个分布式消息队列。Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer。Producer即生产者，向Kafka集群发送消息，在发送消息之前，会对消息进行分类。Topic即主题，通过对消息指定主题可以将消息分类，消费者可以只关注自己需要的Topic中的消息。Consumer即消费者，消费者通过与kafka集群建立长连接的方式，不断地从集群中拉取消息，然后可以对这些消息进行处理。

2.2 GPSS。Greenplum Stream Server（GPSS）是 一 个ETL（提取、转换、加载）工具。GPSS服务器的一个实例从一个或多个客户机接收流数据，使用Greenplum数据库可读的外部表将数据转换并插入到目标Greenplum表中。数据源和数据格式是特定于客户机的。数据源和数据格式由客户端指定[2]。

3.基于异步联机日志与流处理的实时数据抽取实现

整体技术流程图如图1所示

图1 基于异步联机日志结合流处理的实时数据抽取实现

系统采用可视化数据抽取流程建模技术实现了以上的数据抽取过程。可视化数据抽取技术通过组件连接的方式形成数据处理管道。

整体数据实时抽取流程由两个管道组成，分别是数据生产者和数据消费者。

3.1 数据生产者管道。通过解析异步联机日志，CDC感知数据源库Oracle中表的数据更新、增加和删除操作，并将操作流转换成数据流发送到Kafka中。通过CDC读取到的日志进行SQL解析与转换，将数据解析为对应数据的JSON对象，并标记该数据是增加、修改还是删除数据，然后将数据存入到Kafka中。需要注意的是，存储到Kafka中的数据，不同来源表的数据需要存储到不同的Topic中，相当于每个Topic中仅存储固定的一张源表的增量数据信息，一般情况下，使用Oracle的schema名和table名联合起来作为Topic的名称[3]。

3.2 数据消费者管道。GPKafka通过Job方式将导数的配置提交到GPSS，GPSS读取Kafka对应的Topic数据，并写入对应的Grennplum数据库，然后将Job的调度的信息存入到本地文件中。GPKafka消费者根据配置的目标仓库的schema和table信息，自动生成对应的Job配置文件，然后提交Job至GPSS中进行执行。GPSS接收到Job信息后，开始根据Job配置读取Kafka中对应Topic中的数据，然后写入到GreenPlum数据库中。当同时运行的Job数量过多时，GPKafka消费者会根据实际情况，暂停和调度不同的Job运行情况，以满足当前数据抽取业务的需要。最后将流程运行阶段性情况和调度情况写入到本地文件系统中[4]。

三、技术性能对比

数据来源：明星电力公司中台数据，大小为从100M-5G单表。

测试环境：1台Oracle数据库服务器，1台大数据中台服务器，1个GreenPlum实例（6台服务器，1个Master，24个Segment），Kafka集群（3台服务器节点），服务器物理内存64G，内网带宽1Gbps。测试所用源库表以完全入库完毕。

测试方法：对比方法：

第一，CDC读取数据库数据变化日志，然后通过传统JDBC直接写入Grennplum数据库，后面称为（CDC+JDBC）；第二，我们系统采用的方法：通过CDC读取数据库数据变化日志，然后通过GPKafka直接写入Grennplum数据库，后面称为（CDC+GPKAFKA）；第三，通过JDBC实现全量抽取，并通过Greenplum存储组件将数据写入Grennplum数据库，后面称为（JDBC全量抽取）[5]。

实现对比结果如表3、表4所示。

表3 各个方法测试对比结果（累计读取源Oracle数据库效率）

表4 各个方法测试对比结果（累计写入目标Greenplum数据库效率）

通过观察计算可以发现JDBC全量抽取和CDC+JDBC这两种方式再读取和写入效率上都是一致的，因为他们都在同一个任务中做处理。而CDC+GPKAFKA这种方式，由于读取出数据后，暂存在Kafka中，有个消费的过程，它的读取和写入的效率是有区别的，写入效率远高于读取的效率。从事实数据抽取的效率上面来看，CDC+GPKAFKA这种方式是最优选。CDC+GPKAFKA由于同时采用了CDC异步日志分析技术和kafak流式并行写入技术，不经过JDBC接口因此在小表和大表，小数据改变量到大数据改变量情况下都保持了非常好的数据抽取写入性能[6]。

结语

我们对多个业务数据源系统进行数据实时抽取，包含的数据源表总共约5000余张，历史存量数据约150GB，月增量约10GB。同时，以上所述业务系统内的原始数据源表，包含部分未做分区、分表等设计的超大表，无唯一键和主键等现象，其中最大的表记录数量达到2亿条，约5GB，为数据中心对于该类表的数据实时性抽取增加了较大的困难和障碍。原始的数据抽取方式为全量数据接入方式和基于全量对比的数据抽取技术。该方式处理效率低下，通常造成数据积压严重，无法达到数据的实时性抽取任务要求[7]。

针对该问题，提出的一种CDC结合GPKafka的实时数据接入抽取技术，提升了中台数据抽取实时性。通过与CDC+JDBC方式、JDBC全量抽取方式对比，CDC+GPKAFKA有明显的优势，在对1亿条数据量的读写测试中，CDC+GPKafka的方式读写数据效率分别261000条/分钟和509000条/分钟。达到了零数据积压的数据入库要求。