互联网金融消费信贷批量业务分布式流计算处理引擎的制作方法

本发明涉及流计算处理领域，具体是指互联网金融消费信贷批量业务分布式流计算处理引擎。

背景技术：

互联网消费金融从本质上讲其实就是网络贷款，是指具有相关资质的互联网金融企业在大数据征信的基础上，通过互联网向消费者提供某个具体消费产品(房产或汽车除外)或服务贷款的金融运作模式。用户只要登陆相关网站，然后进行申请就可享受互联网消费金融所带来的便捷性。

当前互联网金融消费信贷批量是使用单机单进程模式，随着数据量不断增加，单机批量系统的压力很大，批量处理时间越来越长，已经影响了正常的交易和下游系统的数据处理。

因此我们迫切需要一种能够提高批量处理效率，缩短处理时间的互联网金融消费信贷批量业务分布式流计算处理引擎。

技术实现要素：

基于以上问题，本发明提供了互联网金融消费信贷批量业务分布式流计算处理引擎。本发明通过分布式并行技术来提高批量处理效率，缩短处理时间，把kafka高速的流传输能力和greenplum强大的流运算执行能力联合起来，形成一个分布式流计算处理引擎，大大降低了数据处理的延时。

为解决以上技术问题，本发明采用的技术方案如下：

互联网金融消费信贷批量业务分布式流计算处理引擎，包括以下步骤，

步骤s1001：从源数据库中读取数据，通过kafkaproducer把源数据流发送到kafkatopicpartition上；

步骤s1002：读取kafka中的源数据消息，为kafka的topic中每一个partition创建一个reader作为consumer；

步骤s1003：reader通过流运算把来自于同一个topic的消息汇集起来上，再通过httpconnector转发到gp的各个segment上；

步骤s1004：通过调度器dispatcher来调度、加载、启动使用流数据处理模式和流运算的gp-sqlforjava实现流数据处理的job来完成具体的业务功能；

步骤s1005：把处理完成的结果数据写入到结果数据库中。

作为优选的，在步骤s1002中，reader是流计算处理引擎的kafkaconsumer，负责读取kafka中的源数据流，同时对数据流进行前置变换和处理，然后再通过connector发送数据到gp的segment上。

作为优选的，connector基于http协议，负责kafka、gp连接功能，以及数据收发功能。

作为优选的，dispatcher是调度组件，负责调度、加载、启动与gpsegment关联的用gp-sqlforjava实现的job。

作为优选的，数据流在job处理前还需进行prehandler操作，从而得到job处理需要的数据格式。

作为优选的，数据流在job处理后还需进行posthandler操作，使其满足保存到mysql数据库需要的格式，实现把处理完成的结果数据写入到结果数据库中。

本发明的有益效果：

(1)本发明使用kafka流数据平台，具备高速数据流传输能力。

(2)本发明使用greenplum，具备强大的流运算执行能力。

(3)本发明支持完整的流计算处理模式，支持事件时间和处理时间，支持固定窗口及滑动窗口，可以通过时间窗口模拟会话窗口，并可以在这些窗口上执行各种greenplum强大的数据处理功能。

(4)本发明充分利用kafka、greenplum的分布式并行技术，极大的提高了批量处理效率，大大缩短处理时间。

(5)本发明还支持处理节点的横向扩展，大大提高了系统的扩展性、伸缩性、容错性。

附图说明

参考以下详细描述可以获得对本发明的特征和优点的更好理解，其中阐述了利用了本发明的原理的说明性实施例以及附图，其中：

图1是根据本说明书一些实施例所示的框架示意图。

具体实施方式

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。

参见图1，互联网金融消费信贷批量业务分布式流计算处理引擎，包括以下步骤，

步骤s1001：从源数据库中读取数据，通过kafkaproducer把源数据流发送到kafkatopicpartition上；

步骤s1002：读取kafka中的源数据消息，为kafka的topic中每一个partition创建一个reader作为consumer；

步骤s1003：reader通过流运算把来自于同一个topic的消息汇集起来上，再通过httpconnector转发到gp的各个segment上；

步骤s1004：通过调度器dispatcher来调度、加载、启动使用流数据处理模式和流运算的gp-sqlforjava实现流数据处理的job来完成具体的业务功能；

步骤s1005：把处理完成的结果数据写入到结果数据库中。

为了便于实施例理解，我们做出如下说明。

1、greenplum：

greenplum是基于postgres的mpp版本构建的功能丰富，性能优越的开源数据处理平台，数据可分布在不同的节点上进行高速并行处理，在本申请文件中也简称gp。

greenplum主要由master节点、segment节点、interconnect三大部分组成。greenplummaster是greenplum数据库系统的入口，接受客户端连接及提交的sql语句，将工作负载分发给其它数据库实例(segment实例)，由它们存储和处理数据。greenpluminterconnect负责不同postgresql实例之间的通信。greenplumsegment是独立的postgresql数据库，每个segment存储一部分数据。大部分查询处理都由segment完成。master节点不存放任何用户数据，只是对客户端进行访问控制和存储表分布逻辑的元数据,segment节点负责数据的存储，可以对分布键进行优化以充分利用segment节点的io性能来扩展整集群的io性能存储方式可以根据数据热度或者访问模式的不同而使用不同的存储方式。一张表的不同数据可以使用不同的物理存储方式：行存储、列存储、外部表。

greenplum架构大致有以下几个特点：

1.1大规模数据存储

(1)greenplum数据库通过将数据分布到多个节点上来实现规模数据的存储。

(2)greenplum采用分而治之的办法，将数据规律的分布到节点上，充分利用segment主机的io能力，以此让系统达到最大的io能力。

(3)在greenplum中每个表都是分布在所有节点上的。master节点首先通过对表的某个或多个列进行hash运算，然后根据hash结果将表的数据分布到segment节点中。整个过程中master节点不存放任何用户数据，只是对客户端进行访问控制和存储表分布逻辑的元数据。

(4)greenplum提供称为“多态存储”的灵活存储方式。多态存储可以根据数据热度或者访问模式的不同而使用不同的存储方式。一张表的不同数据可以使用不同的物理存储方式。

支持的存储方式包含：

行存储：行存储是传统数据库常用的存储方式，特点是访问比较快，多列更新比较容易。

列存储：列存储按列保存，不同列的数据存储在不同的地方(通常是不同文件中)。适合一次只访问宽表中某几个字段的情况。列存储的另外一个优势是压缩比高。

外部表：数据保存在其他系统中例如hdfs，数据库只保留元数据信息。

1.2并行查询计划和执行

(1)greenplum主节点(master)上的调度器(qd)会下发查询任务到每个数据节点。

(2)数据节点收到任务后(查询计划树)，创建工作进程(qe)执行任务。

(3)如果需要跨节点数据交换(如hashjoin)，则数据节点上会创建多个工作进程协调执行任务。不同节点上执行同一任务(查询计划中的切片)的进程组成一个进程组。数据从下往上流动，最终master返回给客户端。

1.3并行数据加载

(1)并行加载技术充分利用分布式计算和分布式存储的优势，保证发挥出每一块disk的i/o资源。

(2)并行加载比串行加载，速度提高40-50倍以上。

(3)增加segment，并行加载速度呈线性增长。

2、kafka：

kafka是一个开源的高吞吐量的分布式发布订阅消息系统和流数据传输平台。kafka最初是设计为一个分布式的日志系统，并广泛用于流数据的消息中间件场景。随着kafka扩展组件越来越多，它也慢慢演变成为一个完整的流数据计算平台。kafka的核心组件确保了最重要的三个功能：高速，可靠，可扩展。

kafka结构中的topic是存放消息的队列，每个topic包含一个或多个partition，partition的数量决定了消费时的并行程度。producer生成消息，消息发送给某个topic，或者直接发给topic中特定的partition。consumer消费消息，consumer以组(consumergroup)为单位消费同一个topic的消息。同一个topic可以有多组消费者同时消费，每个组一般对应不同的应用逻辑。在同一个组内部，每个partition的消息，同时只能由一个消费者进行消费。不存在同一组内的多个消费者消费同一个partition的情况。因此，增加producer的数量一定会提高发送端的并行度，但增加consumer的数量，则不一定会增加接受端的并行度，因为实际消费端的并行度的上限是由partition的数据决定的。kafka是分布式集群，kafka集群由broker组成，每一个broker都是可以独立提供服务的进程实例。消息以分区为组织单元，保存在broker上。数据会有备份，称为replica，备份保存在另一个broker上，因此备份的数目不会超过broker的数目，而分区数没有这个限制，同一broker上可以有同一topic的多个分区。

在所有的备份中，有一个leader对外提供读写服务，其它称为replica。只有在leader挂掉的情况下，才会从剩下的replica中选出新的leader提供服务。为最大化kafka的吞吐，在流处理管道架构设计上必须考虑如何与kafka本身的设计相匹配。

3、流数据：

流数据是没有边界的数据，有2个重要的特点。

第一个是流数据从产生到处理，存在延迟。因此流数据有两个时间属性：事件时间和处理时间。

第二个特点是应用可以根据实际需求来决定数据的一致性目标，比如强一致，最终一致，或者最多一次，最少一次等等。

4、流数据处理模式：

流数据处理模式主要有三种属性。

4.1时间：时间属性一共分三类，事件时间，处理时间及时间无关，通常事件时间和处理时间之间是有延时的，且延迟是不固定的

4.2窗口：窗口属性是对流数据添加虚拟的边界，从而将无边界的流数据转变成一个个有边界的数据集；它是处理无边界数据的最常用方法。添加的边界通常有两类，时间边界和事件边界，分别叫做时间窗口和会话窗口；时间窗口有两种类型，固定窗口和滑动窗口，会话窗口的含义是，需要处理的事件，有明确的开始和结束的标志。开始和结束标志之间的一系列事件称为一个会话，而对数据的处理则是以会话为单位

4.3运算：运算是我们需要对流数据执行什么样的处理。从简单到复杂，依次是，流数据的内连接，也就是在两个流数据中找到共同的事件或类似的事件；第二个是数据的变换和过滤，比如简单去重，单位转换，到复杂的加密，脱敏等；第三种是最复杂的流数据聚合，即需要执行某种聚合函数从而识别出数据流的某些特征。gp的sqlforjava是执行流运算很好的工具。

综合来说，流数据处理模式就是这三个属性的排列组合。绝大部分流计算问题都可以划分到这里面的某一个类别。例如在基于事件时间的会话窗口上，或者以固定窗口，对时间无关的数据进行加工变换等等。

5、流计算引擎：

流计算引擎是专门处理无边界数据的计算引擎。它有两个特点，首先是流计算引擎必须能够满足强一致性要求。第二个特点是流计算引擎需要支持以上描述的流数据处理模式。

需要说明的是，在一些实施例中，在步骤s1002中，reader是流计算处理引擎的kafkaconsumer，负责读取kafka中的源数据流，同时对数据流进行前置变换和处理，然后再通过connector发送数据到gp的segment上。

需要说明的是，在一些实施例中，connector基于http协议，负责kafka、gp连接功能，以及数据收发功能。

需要说明的是，在一些实施例中，dispatcher是调度组件，负责调度、加载、启动与gpsegment关联的用gp-sqlforjava实现的job。

需要说明的是，在一些实施例中，数据流在job处理前还需进行prehandler操作，从而得到job处理需要的数据格式。

需要说明的是，在一些实施例中，数据流在job处理后还需进行posthandler操作，使其满足保存到mysql数据库需要的格式，实现把处理完成的结果数据写入到结果数据库中。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。

同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。