基于大数据的Flume接收端数据处理方法和装置技术领域
本发明涉及到大数据Flume接收端数据处理领域，特别是涉及到一种基于大数据
的Flume接收端数据处理方法和装置。
背景技术
在互联网快速发展的时代，网络系统日志、网络应用运行日志、网络用户行为日志
及流量等各类日志被大量产生。同时由于云等新兴技术的兴起和发展，迫切需要将各类日
志信息实时的统一的收集汇总到指定位置，以供技术及相关人员读取分析，从而可以提供
更好的服务。在这种背景下Apache Flume NG作为一款轻量级，稳定的实时日志收集系统被
开发并广泛应用在大数据行业。
参照图1，现有Flume的框架图，其主要由三部分组成：Source(源数据端)、Channel
(通道)、Sink(输出端)。Source负责链接源数据，Channel负责传输数据，Sink负责接受数
据，整个框架称为Flume的一个Agent(代理)。
数据形式在Source中以Event(事件)的形式传输。Event由Headers(报头)，Body
(数据)组成。Header中包含描述数据的多项键值-数值对，Body为序列化后的数据。
整个数据流程即可被描述为，数据通过对应的数据格式的Source组件，例如通过
AvroSource或者ThriftSource抓取数据，并传送到相应channel中，再由channel传入到设
置的Sink中。其中Avro和Thrift为数据传输中的中间件。在这种架构下，对数据源的格式需
要匹配，即需要匹配avro或thrift参数来设置Source中的相关参数，灵活性较低。
发明内容
本发明的主要目的为提供一种灵活性高的基于大数据的Flume接收端数据处理方
法和装置。
为了实现上述发明目的，本发明提出一种基于大数据的Flume接收端数据处理方
法，包括：
获取Event，并根据Event header中的信息对Event进行排序；
通过指定的函数查找对应的Source-body；如果有对应的Source-body，则直接标
记，如果没有，则使用默认的Source-body，并动态加载Source-body，形成一个新的Source-
body；
选择对应的Source-body后，对应生成一个队列，当新近的Event header与其对应
的Source-body队列中的指定信息相同后，新的Event数据会添加到其队列中；
当对应的Source-body类被选中后，Source-body以其数据类型选择对应的
channel，并与之建立联系。
进一步地，所述获取Event，并根据Event header中的信息对Event进行排序的步
骤之前，包括：
将Source拆分Source-header和Source-body，并在每个时间Event中定义Header
信息。
进一步地，所述将Source拆分Source-header和Source-body，并在每个时间Event
中定义Header信息的步骤，包括：
在Source-header中设置指定参数，通过所述指定参数在Source-header中进行解
析。
进一步地，所述指定参数包括：
指明Event数据所使用的数据传输所用类型的DATATYPE；
数据源的IP地址或域名的ONFIG_BIND；
数据源所使用的通讯端口的ONFIG_PORT；以及，
时间戳函数生成时间戳的TIMESTAMP。
进一步地，在Source-header中设置指定参数，通过所述指定参数在Source-
header中进行解析的步骤，包括：
所述TIMESTAMP还生成16位数位作为字典数位；其中所述字典位的生成规则为12
位IP地址加4位线程PID，若PID小于4位时左边补零，大于四位时取后四位；当大于两个的具
有相同系统时间戳的数据由不同线程传入Source header时，Source-header根据字典位中
的线程数位进行排序，较小的数据会被先传入相应Source-body中。
本发明还提供一种基于大数据的Flume接收端数据处理装置，包括：
获取单元，用于获取Event，并根据Event header中的信息对Event进行排序；
查找判断单元，用于通过指定的函数查找对应的Source-body；如果有对应的
Source-body，则直接标记，如果没有，则使用默认的Source-body，并动态加载Source-
body，形成一个新的Source-body；
选择生成单元，用于选择对应的Source-body后，对应生成一个队列，当新近的
Event header与其对应的Source-body队列中的指定信息相同后，新的Event数据会添加到
其队列中；
选择建立单元，用于当对应的Source-body类被选中后，Source-body以其数据类
型选择对应的channel，并与之建立联系。
进一步地，所述基于大数据的Flume接收端数据处理装置，还包括：
拆分定义单元，用于将Source拆分Source-header和Source-body，并在每个时间
Event中定义Header信息。
进一步地，所述拆分定义单元包括：
解析模块，用于在Source-header中设置指定参数，通过所述指定参数在Source-
header中进行解析。
进一步地，所述指定参数包括：
指明Event数据所使用的数据传输所用类型的DATATYPE；
数据源的IP地址或域名的ONFIG_BIND；
数据源所使用的通讯端口的ONFIG_PORT；以及，
时间戳函数生成时间戳的TIMESTAMP。
进一步地，所述解析模块包括：
生成子模块，用于所述TIMESTAMP还生成16位数位作为字典数位；其中所述字典位
的生成规则为12位IP地址加4位线程PID，若PID小于4位时左边补零，大于四位时取后四位；
当大于两个的具有相同系统时间戳的数据由不同线程传入Source header时，Source-
header根据字典位中的线程数位进行排序，较小的数据会被先传入相应Source-body中。
本发明的基于大数据的Flume接收端数据处理方法和装置，因为是针对数据类型
查找数据类型，所以允许动态加载Source-body，即当原来没有的数据类型被开发出来后，
可以通过加载其对应的Source-body来处理其数据传输，而不使用默认Source-body，提高
效率、灵活性和通用性。
附图说明
图1为现有Flume的框架图；
图2为本发明一实施例的的基于大数据的Flume接收端数据处理方法的流程示意
图；
图3为本发明一实施例的的基于大数据的Flume接收端数据处理方法的流程示意
图；
图4为本发明一实施例的重构后的Flume接收端的框架图；
图5为本发明一实施例的基于大数据的Flume接收端数据处理装置的结构示意框
图；
图6为本发明一实施例的基于大数据的Flume接收端数据处理装置的结构示意框
图；
图7为本发明一实施例的拆分定义单元的结构示意框图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
参照图2，本发明实施例提出一种基于大数据的Flume接收端数据处理方法，包括
步骤：
S1、获取Event，并根据Event header中的信息对Event进行排序；
S2、通过指定的函数查找对应的Source-body；如果有对应的Source-body，则直接
标记，如果没有，则使用默认的Source-body，并动态加载Source-body，形成一个新的
Source-body；
S3、选择对应的Source-body后，对应生成一个队列，当新近的Event header与其
对应的Source-body队列中的指定信息相同后，新的Event数据会添加到其队列中；
S4、当对应的Source-body类被选中后，Source-body以其数据类型选择对应的
channel，并与之建立联系。
如上述步骤S1所述，上述Event由数据源产生，包括Headers和Body；上述Event
header中包含描述数据的多项键值-数值对，Body为序列化后的数据。本实施例中，对Event
进行排序，防止数据源产生的Event有多种数据类型。
如上述步骤S2所述，当排序完成后Source-header会通过如switch()函数读取的
DATATYPE的值来寻找对应的Source-body。例如，如果Event header中DATATYPE为REST-
JSON时，则查看是否有Source-rest-json这个类，如果有，则标记，并在后续中调用这个类；
如果没有这个类，则使用默认的Source-body类。因为是针对数据类型查找数据类型，所以
允许动态加载Source-body，即当原来没有的数据类型例如A被开发出来后，可以通过加载
其Source-A来处理其数据传输，而不使用默认Source-body，来提高效率和灵活性。
如上述步骤S3所述，当选择了一个Source-body后，会对应生成一个队列，当新近
的Event header与其对应的Source-body队列中的Event header的指定信息相同后，新的
Event数据会添加到其队列中，比如，当处理时间戳信息不同，而其他信息均相同的时候，新
的Event数据会添加到其队列中。
如上述步骤S4所述，建立新的数据通道，数据通道建立联系后，数据的传输等与原
有Flume的工作原理相同。
参照图3和图4，本实施例中，上述获取Event，并根据Event header中的信息对
Event进行排序的步骤S1之前，包括：
S10、将Source拆分Source-header和Source-body，并在每个时间Event中定义
Header信息。
如上述步骤S10所述，将Source端进行了拆分重构。将Source拆分为两大部分，
Source-header和Source-body，并在每个时间Event中定义Header信息；Event是一个事件，
由一个重新定义的header及数据组成；Src-header为Source-header缩写，负责处理Event
中重新定义的header信息；Source-body可以由多个组成，针对avro、thrift数据源的为
Source-avro、Source-thrift，在图4中简写为Src-avro、Src-thrift，当数据源类型不指定
时即流向默认的Source-body简写为Src-body。其他架构组件与原Flume一致，在此不做赘
述。
本实施例中，上述将Source拆分Source-header和Source-body，并在每个时间
Event中定义Header信息的步骤S10，包括：
S11、在Source-header中设置指定参数，通过所述指定参数在Source-header中进
行解析。
如上述步骤S11所述，Event由数据源产生，由两部分组成，header和数据。其中在
Source-headerr中定义一系列必填参数，用于Source-header中进行解析并进行后续操作。
本实施例中，上述指定参数包括：
指明Event数据所使用的数据传输所用类型的DATATYPE，其包括含但不限于如
TCompactProtocol、TBinaryProtocol、Protocol Buffers、REST-XML和REST-JSON等；
数据源的IP地址或域名的ONFIG_BIND，其中内部网络时建议使用IP地址，跨域调
用时推荐使用域名；
数据源所使用的通讯端口的ONFIG_PORT，例如9999等；以及，
时间戳函数生成时间戳的TIMESTAMP，其中，为了使数据源所发送的数据可以根据
Source的重要性并按照时间顺序进行传输，使用Lamport面包房算法(简称Lamport算法)来
定义TIMESTAMP函数。
本实施例中，上述在Source-header中设置指定参数，通过所述指定参数在
Source-header中进行解析的步骤S11，包括：
S110、所述TIMESTAMP还生成16位数位作为字典数位；其中所述字典位的生成规则
为12位IP地址加4位线程PID，若PID小于4位时左边补零，大于四位时取后四位；当大于两个
的具有相同系统时间戳的数据由不同线程传入Source header时，Source-header根据字典
位中的线程数位进行排序，较小的数据会被先传入相应Source-body中。
如上述步骤S110所述，本步骤可以保证多线程的情况下，数据是以Source的重要
性来进行传输的。
本实施例中，上述步骤S110之前一般还设置有同一进程中，事件的表达方式，比如
事件E1和E2发生的时间分别为T1和T2，表达式T1＜T2表示为“事件E1在事件E2之前发生”。那么
对于在同一进程中，我们还定义如下规则：
1.若事件E1在事件E2之前发生，则TIMESTAMP(E1)＜TIMESTAMP(E2)；
2.若事件E1和E2分别代表发送一个消息和接收该消息，则TIMESTAMP(E1)＜
TIMESTAMP(E2)；
3.对所有不同的事件E1≠E2，则TIMESTAMP(E1)≠TIMESTAMP(E2)；
定义上述三条规则后，我们保证在同一线程内，数据的传输是以时间一致性进行
传输的。
在一具体实施例中，首先，Source-header读取TIMESTAMP，对Event进行排序。排序
中先以时间戳数位进行排序，本实施例中使用quicksort排序方法进行排序，在其它实施例
中，也可以使用其其它的排序方法。当时间排序之后，如有时间戳相同数据，再以其中字典
位按照IP先排序，线程PID后排序的方式进行再排序，防止数据源产生的Event有多种数据
类型。其次，当排序完成后Source-header会通过switch()函数读取的DATATYPE的值来寻
找对应的Source-body。例如，如果Event header中DATATYPE为REST-JSON时，则查看是否有
Source-rest-json这个类，如果有，则标记，并在后续中调用这个类；如果没有这个类，则使
用默认的Source-body类。因为是针对数据类型查找数据类型，所以允许动态加载Source-
body，即当原来没有的数据类型例如A被开发出来后，可以通过加载其Source-A来处理其数
据传输，而不使用默认Source-body，来提高效率。然后，当选择了一个Source-body后，会对
应生成一个队列，当新近的Event header与其对应的Source-body队列中的Event header
除时间戳外相同后，新的Event数据会添加到其队列中。最后，当对应的Source-body类被选
中后，Source-body以其数据类型选择对应的channel，并与之建立联系，此处之后即与原有
Flume的工作原理相同。
在另一具体实施例中，进行实验数据比较分析，如下：
1)测试方法：
a.设立一台服务器，底层收集服务器系统日志。
b.分别以Thrift、Avro、JSON等传输方式实现通信。
c.分别使用Flume和重构后的Flume与日志收集服务器集成。
d.每次测试时，只使用单一传输方式，并使用同一端口进行测试。
2)测试结果，如下表：
![]()
本发明的基于大数据的Flume接收端数据处理方法，因为是针对数据类型查找数
据类型，所以允许动态加载Source-body，即当原来没有的数据类型被开发出来后，可以通
过加载其对应的Source-body来处理其数据传输，而不使用默认Source-body，提高效率、灵
活性和通用性。
参照图5，本发明实施例还提供一种基于大数据的Flume接收端数据处理装置，包
括：
获取单元10，用于获取Event，并根据Event header中的信息对Event进行排序；
查找判断单元20，用于通过指定的函数查找对应的Source-body；如果有对应的
Source-body，则直接标记，如果没有，则使用默认的Source-body，并动态加载Source-
body，形成一个新的Source-body；
选择生成单元30，用于选择对应的Source-body后，对应生成一个队列，当新近的
Event header与其对应的Source-body队列中的指定信息相同后，新的Event数据会添加到
其队列中；
选择建立单元40，用于当对应的Source-body类被选中后，Source-body以其数据
类型选择对应的channel，并与之建立联系。
如上述获取单元10，上述Event由数据源产生，包括Headers和Body；上述Event
header中包含描述数据的多项键值-数值对，Body为序列化后的数据。本实施例中，对Event
进行排序，防止数据源产生的Event有多种数据类型。
如上述查找判断单元20，当排序完成后Source-header会通过如switch()函数读
取的DATATYPE的值来寻找对应的Source-body。例如，如果Event header中DATATYPE为
REST-JSON时，则查看是否有Source-rest-json这个类，如果有，则标记，并在后续中调用这
个类；如果没有这个类，则使用默认的Source-body类。因为是针对数据类型查找数据类型，
所以允许动态加载Source-body，即当原来没有的数据类型例如A被开发出来后，可以通过
加载其Source-A来处理其数据传输，而不使用默认Source-body，来提高效率和灵活性。
如上述选择生成单元30，当选择了一个Source-body后，会对应生成一个队列，当
新近的Event header与其对应的Source-body队列中的Event header的指定信息相同后，
新的Event数据会添加到其队列中，比如，当处理时间戳信息不同，而其他信息均相同的时
候，新的Event数据会添加到其队列中。
如上述选择建立单元40，建立新的数据通道，数据通道建立联系后，数据的传输等
与原有Flume的工作原理相同。
参照图6和图4，本实施例中，上述基于大数据的Flume接收端数据处理装置，还包
括：
拆分定义单元100，用于将Source拆分Source-header和Source-body，并在每个时
间Event中定义Header信息。
如上述拆分定义单元100，将Source端进行了拆分重构。将Source拆分为两大部
分，Source-header和Source-body，并在每个时间Event中定义Header信息；Event是一个事
件，由一个重新定义的header及数据组成；Src-header为Source-header缩写，负责处理
Event中重新定义的header信息；Source-body可以由多个组成，针对avro、thrift数据源的
为Source-avro、Source-thrift，在图4中简写为Src-avro、Src-thrift，当数据源类型不指
定时即流向默认的Source-body简写为Src-body。其他架构组件与原Flume一致，在此不做
赘述。
参照图7，本实施例中，上述拆分定义单元100包括：
解析模块110，用于在Source-header中设置指定参数，通过所述指定参数在
Source-header中进行解析。
如上述解析模块110，Event由数据源产生，由两部分组成，header和数据。其中在
Source-headerr中定义一系列必填参数，用于Source-header中进行解析并进行后续操作。
本实施例中，上述指定参数包括：
指明Event数据所使用的数据传输所用类型的DATATYPE，其包括含但不限于下列
几种传输类型，如TCompactProtocol、TBinaryProtocol、Protocol Buffers、REST-XML和
REST-JSON等；
数据源的IP地址或域名的ONFIG_BIND，其中内部网络时建议使用IP地址，跨域调
用时推荐使用域名；
数据源所使用的通讯端口的ONFIG_PORT，例如9999等；以及，
时间戳函数生成时间戳的TIMESTAMP，其中，为了使数据源所发送的数据可以根据
Source的重要性并按照时间顺序进行传输，使用Lamport面包房算法(简称Lamport算法)来
定义TIMESTAMP函数。
本实施例中，上述解析模块110包括：
生成子模块1101，用于所述TIMESTAMP还生成16位数位作为字典数位；其中所述字
典位的生成规则为12位IP地址加4位线程PID，若PID小于4位时左边补零，大于四位时取后
四位；当大于两个的具有相同系统时间戳的数据由不同线程传入Source header时，
Source-header根据字典位中的线程数位进行排序，较小的数据会被先传入相应Source-
body中。
如上述生成子模块1101，可以保证多线程的情况下，数据是以Source的重要性来
进行传输的。
本实施例中，同一进程中，事件的表达方式一般为，事件E1和E2发生的时间分别为
T1和T2，表达式T1＜T2表示为“事件E1在事件E2之前发生”。那么对于在同一进程中，我们还定
义如下规则：
1.若事件E1在事件E2之前发生，则TIMESTAMP(E1)＜TIMESTAMP(E2)；
2.若事件E1和E2分别代表发送一个消息和接收该消息，则TIMESTAMP(E1)＜
TIMESTAMP(E2)；
3.对所有不同的事件E1≠E2，则TIMESTAMP(E1)≠TIMESTAMP(E2)；
定义上述三条规则后，我们保证在同一线程内，数据的传输是以时间一致性进行
传输的。
在一具体实施例中，首先，Source-header读取TIMESTAMP，对Event进行排序。排序
中先以时间戳数位进行排序，本实施例中使用quicksort排序方法进行排序，在其它实施例
中，也可以使用其其它的排序方法。当时间排序之后，如有时间戳相同数据，再以其中字典
位按照IP先排序，线程PID后排序的方式进行再排序，防止数据源产生的Event有多种数据
类型。其次，当排序完成后Source-header会通过switch()函数读取的DATATYPE的值来寻
找对应的Source-body。例如，如果Event header中DATATYPE为REST-JSON时，则查看是否有
Source-rest-json这个类，如果有，则标记，并在后续中调用这个类；如果没有这个类，则使
用默认的Source-body类。因为是针对数据类型查找数据类型，所以允许动态加载Source-
body，即当原来没有的数据类型例如A被开发出来后，可以通过加载其Source-A来处理其数
据传输，而不使用默认Source-body，来提高效率。然后，当选择了一个Source-body后，会对
应生成一个队列，当新近的Event header与其对应的Source-body队列中的Event header
除时间戳外相同后，新的Event数据会添加到其队列中。最后，当对应的Source-body类被选
中后，Source-body以其数据类型选择对应的channel，并与之建立联系，此处之后即与原有
Flume的工作原理相同。
在另一具体实施例中，进行实验数据比较分析，如下：
1)测试方法：
a.设立一台服务器，底层收集服务器系统日志。
b.分别以Thrift、Avro、JSON等传输方式实现通信。
c.分别使用Flume和重构后的Flume与日志收集服务器集成。
d.每次测试时，只使用单一传输方式，并使用同一端口进行测试。
2)测试结果，如下表：
![]()
本发明的基于大数据的Flume接收端数据处理装置，因为是针对数据类型查找数
据类型，所以允许动态加载Source-body，即当原来没有的数据类型被开发出来后，可以通
过加载其对应的Source-body来处理其数据传输，而不使用默认Source-body，提高效率、灵
活性和通用性。
以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用
本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关
的技术领域，均同理包括在本发明的专利保护范围内。