本发明涉及通信技术领域，具体涉及一种基于流处理的网络流量数据分析的方法和装置。
背景技术：
随着网络技术的不断发展，网络提供的应用和业务种类得到了极大的丰富。与此同时，多样化的业务和不断增加的用户数也使运营商网络变得愈加复杂，这无疑加大了通信设备的运维难度，也给网络服务提供商带来了新的机遇与挑战。
对通信设备发出的大规模数据进行分析能够帮助运营商精准掌控网络应用的信息，并基于掌控的信息完成高效的网络运维管理，从而支撑信息安全、用户管理，故障监控等多方面业务需求。传统网络流量数据分析方法主要包括对传输协议端口、信息特征内容、流量特征的分析，上述分析方法尚不能满足流量分类和深度分析的多样化功能需求。而dpi(deeppacketinspection，深度包检测)技术基于二层到七层网络协议，能够深入读取数据包载荷，提供更为细致和具体的信息。基于dpi技术的分析设备能够采集原始的数据流量信息，生成xdr(externaldatarepresentation，外部数据表示)格式的数据。运营商能够通过dpi设备生成的xdr数据精确感知网络状况，从而实现精细化、差异化运维的目的。
然而，由于网络中的业务、用户及数据的多样性，网络中的数据包特征也会不断的改变，深度包检测的技术实现也变得更加困难。网络中数据包的二层到四层的信息相对固定，处理起来比较方便。但四层以上的信息既无标准的定义，也经常变化，需要设计一套合理而有效的方案对这部分信息进行筛选、归类和分析。但是，现有的dpi设备灵活性较差，软件可扩展能力差，导致输出的xdr数据当中丢失了很多信息。传统采用解码、单接口合成、回填、多接口合成的步骤在需要增加新的业务逻辑时比较麻烦，因此需要设计更为灵活的方案以生成个性化xdr信息。此外，dpi设备需要对大量的数据包进行解析，而伴随着网络流量的爆炸式增涨，处理速度已成为基于dpi流量深度分析的瓶颈，因此需要引入大数据处理技术来解决这一问题。大数据时代的到来对于数据的实时性需求更为迫切，对于数据可靠性要求更高。
技术实现要素：
鉴于此，本发明提供一种基于流处理的网络流量数据解析方法及装置，采用分布式流处理模式提高数据的处理速度，满足通信设备监测场景中实时处理流数据的需求。
为实现上述目的，本发明实施例提供如下技术方案：
一种基于流处理的网络流量数据解析方法，应用于数据处理系统中，所述数据处理系统中预架构有多个流量数据采集节点和多个处理节点，方法包括：
从各采集节点获取信令中转设备转接的原始网络流量数据；
依据协议匹配规则对原始网络流量数据中的原始报文进行协议匹配；
对协议匹配后的原始报文标注分类标识；
依据所述分类标识和负载均衡原则为加分类标识后的原始报文确定对应的目标处理节点，将协议匹配后的原始报文发送至所述目标处理节点；
所述所有处理节点采用分布式流数据处理方式，对收到的报文依据业务匹配规则进行业务匹配，将匹配出的数据重组为业务xdr数据输出。
优选的，上述网络流量数据解析方法中，所述从各采集节点获取信令中转设备转接的原始网络流量数据之前，还包括：获取协议匹配规则、业务匹配规则；将所述协议匹配规则分发给各采集节点，将所述业务匹配规则分发给各处理节点。
优选的，上述网络流量数据解析方法中，所述将所述协议匹配规则分发给各采集节点之前，还包括：对所述匹配规则进行整合，去除所述匹配规则中的冗余规则，并分别形成协议匹配判断树、业务匹配判断树，形成简化的匹配规则。
优选的，上述网络流量数据解析方法中，所述的协议匹配规则、业务匹配规则用正则表达式表述并存储于配置文件中，或者通过人机交互界面获取用户输入的协议特征、业务需求，然后动态生成用正则表达式表述的协议匹配规则、业务匹配规则。
优选的，上述网络流量数据解析方法中，所述协议特征至少包括：ip地址、端口号和协议类型。所述业务需求至少包括：ip地址、端口号和业务类型。
优选的，上述网络流量数据解析方法中，对协议匹配后的原始报文标注分类标识；依据所述标识和负载均衡原则为所述加标识后的原始报文确定对应的目标处理节点，将匹配后的原始报文发送至对应的目标处理节点。进一步包括：依据原始报文内容之间的关联性，对相互关联的原始报文配置相同的id标识，将相同id标识的报文发送至相同的目标处理节点。
优选的，上述网络流量数据解析方法中，所述存在关联性的原始报文指的是：具有相同信源和信宿的数据报文、同一时间段内发出的数据报文、具有相同端口号的数据报文。
优选的，上述网络流量数据解析方法中，还包括将所述输出的业务xdr数据进行分布式文件存储。
一种基于流处理的网络流量数据解析系统，包括：采集分发子系统和业务匹配子系统。
所述采集分发子系统包括架构多个流量数据采集节点，每个采集节点包括如下模块：
采集模块，用于获取信令中转设备转接的原始网络流量数据；
协议匹配模块，依据协议匹配规则对采集模块获取到的原始网络流量数据中的原始报文进行协议匹配；
标识模块，对协议匹配后的原始报文标注分类标识；
分发模块，用于依据所述分类标识和负载均衡原则为加分类标识后的原始报文确定对应的目标处理节点，将协议匹配后的原始报文发送至所述目标处理节点。
所述业务匹配子系统包括多个处理节点，共同采用分布式流数据处理方式工作，每个处理节点包括一个匹配引擎，所述匹配引擎依据业务匹配规则对收到的报文进行业务匹配，将匹配出的数据重组为业务xdr数据输出。
优选的，上述基于流处理的网络流量数据解析系统，还包括规则管理子系统，包括：
规则获取模块，用于获取协议匹配规则、业务匹配规则；
规则处理模块，用于对所述获取的匹配规则进行整合，去除所述匹配规则中的冗余规则，并分别形成判断树，保存到规则数据库；
规则数据库，用于存贮协议匹配规则、业务匹配规则；
规则分发模块，用于从规则数据库取出协议匹配规则、业务匹配规则，将所述协议匹配规则分发给各采集节点，将所述业务匹配规则分发给各处理节点。
优选的，上述基于流处理的网络流量数据解析系统中，规则获取模块包括：
规则配置模块和/或规则配置与生成模块；
所述规则配置模块，用于通过正则表达式描述协议匹配规则、业务匹配规则，形成规则配置文件；
所述规则配置与生成模块，用于通过人机交互界面获取用户输入的协议特征、业务需求，然后动态生成用正则表达式描述的协议匹配规则、业务匹配规则。
优选的，上述基于流处理的网络流量数据解析系统中，所述协议特征至少包括：ip地址、端口号和协议类型；所述业务需求至少包括：ip地址、端口号和业务类型。
优选的，上述基于流处理的网络流量数据解析系统中，所述标识模块具体被配置为，依据原始报文内容之间的关联性，对相互关联的原始报文配置相同的id标识。
所述分发模块被配置为：将相同id标识的原始报文发送至业务匹配单元中相同的目标处理节点。
优选的，上述基于流处理的网络流量数据解析系统中，所述存在关联性的原始报文指的是：具有相同信源和信宿的数据报文，同一时间段内发出的数据报文，具有相同端口号的数据报文。
优选的，上述基于流处理的网络流量数据解析系统中，还包括文件存储子系统，用于将业务匹配子系统输出的业务xdr数据进行分布式文件存储。
优选的，上述基于流处理的网络流量数据解析系统中，所述业务匹配子系统中的匹配引擎还用于，在进行业务匹配之前，将收到的报文缓存到消息队列，从而形成连续的数据码流。
基于上述技术方案，通过本申请上述实施例公开的技术方案可见，本申请将分布式流处理模式与深度包解析思想结合起来，先将数据报文协议规则匹配，再做业务相关的细致匹配，将业务规则匹配任务分配到多个处理节点中，使处理节点中的计算资源能够得到充分利用。同时，基于分布式流处理模式的计算方案能够在短时间内将连续的数据报文匹配、整合为便于业务人员理解的xdr数据，既满足了实际业务分析中高吞吐量、低时延的要求，又保证了输出xdr数据的体量和质量，满足了运营商通信设备网络中实时分析大规模流量数据的需求，极大地提升了分析效率和速度，规避了大数据处理对系统容量的需求压力。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请实施例公开的一种基于流处理的网络流量数据解析系统的结构示意图；
图2为本申请另一实施例公开的一种基于流处理的网络流量数据解析系统的结构示意图；
图3为本申请实施例公开的基于流处理的网络流量数据解析系统的工作流程示意图；
图4为本申请实施例公开的一种基于流处理的网络流量数据解析方法的流程示意图；
图5为本申请实施例公开的一种基于流处理的网络流量数据解析方法的数据流图；
图6为基于分布式流处理的业务匹配设计思路。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
针对于传统的基于dpi分析方式需要经过复杂的处理逻辑，不能应对实际业务中高吞吐量，低时延的要求的问题，本申请公开了一种基于流处理的网络流量数据解析装置。图1为该系统的结构示意图，参见图1，该系统可以包括：
采集分发子系统100和业务匹配子系统200。
所述采集分发子系统100包括预架构的多个流量数据采集节点，每个采集节点包括采集模块110、协议匹配模块120、标识模块130和分发模块140。
其中，所述采集模块110，用于获取信令中转设备转接的原始网络流量数据，所述原始网络流量数据中包含有原始报文；
所述采集模块110还用于完成接口适配和协议规定匹配工作，形成报文json消息。
所述协议匹配模块120，用于依据协议匹配规则对采集模块获取到的原始网络流量数据中的原始报文进行协议匹配，例如http协议。
所述标识模块130，用于对协议匹配后的原始报文标注分类标识。其中，对原始报文标注分类标识的具体原则可以为：依据原始报文之间的关联性，对相互关联的原始报文配置相同的id标识。
所述分发模块140在分发原始报文时，将具有相同id标识的原始报文发送至同一处理节点。其中关联的判别方式可以依据用户需求设置不同的判断原则，例如可以是指的是：具有相同信源、信宿的数据报文、同一时间段内发出的数据报文和/或具有相同端口号的数据报文。
所述分发模块140，用于依据所述分类标识和负载均衡原则为加分类标识后的原始报文确定对应的目标处理节点，将协议匹配后的原始报文发送至所述目标处理节点。具体的，当所述分发模块140进行原始报文分发时，获取要分发的原始报文的分类标识，判断所述处理节点中是否存在与所述分类标识相同的原始报文，如果存在，将要分发的所述原始报文分发至该处理节点，如果不存在，依据负载均衡原则由各个处理节点中选择一个处理节点作为目标处理节点，将所述原始报文下发至所述目标处理节点。
所述业务匹配子系统200内配置有多个处理节点，各个处理节点共同采用分布式流数据处理方式工作，每个处理节点包括一个匹配引擎210，所述匹配引擎210用于依据所述业务匹配规则对收到的报文进行业务匹配，将匹配出的数据重组为业务xdr数据输出。
所述业务匹配子系统200执行业务匹配规则，完成对网络流量数据的业务规则匹配，并产生xdr数据，具体的，可以采用基于storm框架的结构形式，以满足实时处理流式数据的需求。基于storm框架的匹配引擎210不断地对连续原始报文进行业务规则匹配，并不间断地将匹配成功的报文重组为业务xdr数据。当然，所述业务匹配子系统200除了采用storm框架之外，还可以配置sparkstreaming等框架。
在实际使用过程中，为了使得所述协议匹配模块120和业务匹配引擎210具备良好的扩展能力，所述协议匹配规则和业务匹配规则采用通过正则表达式描述形成的规则配置文件；在保障匹配正确性的同时兼具了灵活性。
在本申请上述实施例公开的技术方案中，参见图2，还包括用于对协议匹配规则和业务匹配规则进行管理的规则管理子系统300。
所述规则管理子系统300可以包括：规则获取模块310、规则处理模块320、规则数据库330和规则分发模块340。
所述规则获取模块310，用于获取协议匹配规则、业务匹配规则，并将所述协议匹配规则和业务匹配规则映射为方便数据库存储的结构化数据；为了使得所述协议匹配模块120和业务匹配引擎210具备良好的扩展能力，所述协议匹配规则和业务匹配规则采用通过正则表达式描述形成的规则配置文件，对此，所述规则获取模块310内可以配置有规则配置模块和/或规则配置与生成模块，所述规则配置模块用于通过正则表达式描述协议匹配规则、业务匹配规则，形成规则配置文件；所述规则配置与生成模块用于通过人机交互界面获取用户输入的协议特征、业务需求，然后动态生成用正则表达式描述的协议匹配规则、业务匹配规则，其中，所述协议特征和业务需求的具体类型可以依据用户需求自行设定，例如，在本申请实施例公开的技术方案中，所述协议特征可以包括ip地址、端口号和协议类型等，所述业务需求可以包括：ip地址、端口号和业务类型等。
所述规则处理模块320可以采用单服务器来实现，其用于对所述获取的协议匹配规则进行整合、对获取到的业务匹配规则进行整合，去除所述协议匹配规则和业务匹配规则中的冗余规则，并分别形成与所述协议匹配规则和业务匹配规则相对应的判断树，将所述判断树保存到规则数据库330。
所述规则数据库330可以采用关系型数据库管理系统来实现，其用于存贮以判断树形式保存的协议匹配规则和业务匹配规则。
所述规则分发模块340，用于从所述规则数据库330提取判断树形式的协议匹配规则和业务匹配规则，将提取到的所述协议匹配规则分发给各采集节点，将所述业务匹配规则分发给各处理节点，以便于所述采集节点和处理节点进行协议规则匹配和业务规则匹配。
本申请上述实施例公开的技术方案可以应用于网络设备中，在数据采集阶段，所述网络设备的采集模块110中加载有用于获取网络数据包的应用，例如libpcap等，以实现网络中的数据包的获取，并以原始码流的形式发送给所述协议匹配模块120进行协议规则匹配。协议规则匹配后的原始报文由标识模块130进行分类标识，再由分发模块140分发至业务匹配子系统200进行业务匹配和xdr数据生成。
在本申请另一实施例公开的技术方案中，基于流处理的网络流量数据解析系统还可以包括一文件存储子系统，所述文件存储子系统用于将所述业务匹配子系统200输出的业务xdr数据进行分布式文件存储。为了方便用户对数据进行查询和调取，分布式文件存储器300还可以支持hive、impala等查询引擎的访问。
在数据处理阶段，所述业务匹配子系统中的匹配引擎在进行业务匹配之前，可以将收到的原始报文缓存到消息队列中，从而形成连续的数据码流。具体的，所述匹配引擎210可以采用消息队列将进行分类标注后的原始报文转换为storm框架的输入码流，采用storm框架对输入码流进行处理，匹配引擎210中每个数据单元的格式为(键，值)对(键对应编号，值对应json格式dpi数据)，将各个数据单元连续发送，形成storm的输入码流。在storm内部的bolt模块中设置规则化的过滤器，建立分布式的匹配执行器。最后将符合匹配规则的结果整合为xdr数据，存储到分布式文件系统中，或者接入其他统计分析及可视化系统，便于数据的呈现。
参见图3，对本申请实施例公开的基于流处理的网络流量数据解析装置的详细工作过程进行说明：
规则获取模块310用于进行规则输入，通过人机接口定义确定协议匹配规则和业务匹配规则，将这些规则存储于规则数据库中，其中，所述协议匹配规则和业务匹配规则中需要定义如下规则内容：
{“if”:[<报文位置字符串>:<值字符串>,…],“action”:[“printtemplate”:<输出xdr模板字符串>]}
其中，“报文位置字符串”支持类似c语言的数组写法，如“http[4,$]”表示http协议开始的报文第四个字节开始到报文结束。“值字符串”可以使用字符串完全匹配或者pcre语法的正则表达式匹配。“输出xdr模板字符串”包含固定字符、变量引用和“if”节中正则表达式子匹配的引用。
所述规则处理模块320用于进行规则合并形成规则判断树，具体被配置为：对所述规则数据库中的协议匹配规则和业务匹配规则进行分析，合并各条规则中的“if”节中的“<报文位置字符串>:<值字符串>”的相同报文位置引用或值判断并形成一个判断树，树的各个非叶子节点为各个判断条件，越常用的判断距离根节点越近。叶子节点为一个规则的代表节点。并将此判断树形成内部表达传递给规则分发模块340。通过规则合并可以很大程度上减少在进行协议规则匹配和业务规则匹配时的判断次数。判断树中每个叶子节点对应一条具体规则，该叶子节点对应路径上的节点对应各条子规则，如果两个叶子节点的路径上有重复部分则说明这两个节点的部分子规则相同，可合并。
规则分发模块340用于进行规则分发，具体被配置为：合并后的协议规则对应的判断树分发协议匹配模块，将合并后的业务规则对应的判断树分发给处理节点；本发明中主要通过内存数据库redis作为规则数据的分发地点。同时，还可通过系统基于kafka的消息系统传递更新规则的通知消息，各个处理节点和协议匹配模块收到通知消息后从redis中读取更新后的规则配置。
采集模块110，用于进行数据采集和接口适配，具体被配置为：用于完成对原始网络流量数据接口的接口适配，并采集原始网络流量数据进入本系统。本发明实施例的接口适配中的硬件部分采用通用pc服务器和通用网卡，如intel82599等。适配的软件部分可以适配基于libpcap的采集器，pc服务器与采集源一般为一一对应方式部署。pc服务器输出的信息的格式可以为json格式，其具体如下格式：
{“time”:<日期字符串>,“interface”:<采集接口编码字符串>,“body”:<报文内容的base64编码字符串>}
当采用基于libpcap的采集模块作为前端时，在此步骤把libpcap格式码流转换为上文数据格式(json)。
协议匹配模块120用于进行协议规则匹配，具体被配置为：对原始报文进行粗粒度的过滤，所述粗粒度的过滤指的是对报文消息的“body”字段进行粗略快速的协议识别，只辨别如ip地址、端口号、协议类型(仅ip、tcp、udp、http等关键协议类型)等信息，并根据协议匹配规则的定义内容对原始报文进行过滤。同时对报文消息进行增补，具备如下格式：(同样满足标准json格式)
{“time”:<日期字符串>,“interface”:<采集接口编码字符串>,“proto”:<协议类型字符串>,“srcip”:<源ip地址字符串>,“dstip”:<目的ip地址字符串>,“srcport”:<源端口号整数>,“dstport”:<目的端口号整数>,“body”:<报文内容的base64编码字符串>}
标识模块130用于对原始报文进行分类标注，具体被配置为：完成对原始报文数据的标注过程，为解决关联性规则的匹配要求，需要在报文信息中增加用于进行报文分发的分类标识，以保证原始报文按照规则匹配的正确性。分类标识的生成按照规则管理模块形成的字段定义规则采用md5哈希算法来进行。标注步骤完成后，数据具备如下格式：
{“time”:<日期字符串>,“interface”:<采集接口编码字符串>,“id”:<标识字符串>,“proto”:<协议类型字符串>,“srcip”:<源ip地址字符串>,“dstip”:<目的ip地址字符串>,“srcport”:<源端口号整数>,“dstport”:<目的端口号整数>,“body”:<报文内容的base64编码字符串>}
分发模块140用于进行原始报文的分发，具体被配置为：根据每条报文消息中的“id”字段对报文进行分发，对相同的“id”发送到相同的目标服务器。如果不存在相同的id，则按照负荷平衡原则或者roundrobin方式进行分发。分发步骤对数据内容没有改动；
业务匹配子系统200用于进行业务规则匹配，具体被配置为：基于规则管理模块下发的业务匹配规则树对原始报文进行业务规则匹配，对匹配的规则完成action部分的动作要求，丢弃不能匹配任何规则的数据。本发明支持的业务规则action部分为按照模板产生业务xdr记录并入库。其中，业务匹配步骤对数据内容没有改动。
文件存储子系统，用于将业务xdr数据记录入库，具体被配置为：接受业务规则匹配产生的结果xdr记录数据，所述xdr记录数据具备如下格式：
{“time”:<日期字符串>,“proto”:<协议类型字符串>,“srcip”:<源ip地址字符串>,“dstip”:<目的ip地址字符串>,“srcport”:<源端口号整数>,“dstport”:<目的端口号整数>,“ruleid”:<匹配规则编号>,“xdr”:<按照模板输出的xdr内容字符串>}
记录数据按照配置写入对应数据存储中。在海量数据处理架构中，相比上述各个步骤，入库步骤也是较耗时的步骤，需要独立运行在不同的存储集群上，并需要多机分担负荷。为方便后继处理，本发明支持的入库形式主要基于分布式文件系统，亦可采用oracle、mysql等关系型数据库。
总体上来说，所述采集分发子系统的初始的数据流由packetemiter(packetemiter与信令中转设备连接，获取原始数据，生成基于流处理的网络流量数据解析系统的输入数据流)产生，使用libpcap等网络数据包捕获技术对原始网络流量数据进行解析，在数据源端编写程序sniffer(sniffer程序实现的是协议规则匹配，完成方案中粗粒度匹配功能)，实现原始报文的初级过滤，最后将过滤后的原始报文转型成标准格式以二进制数据流的形式输入到网络中进行传输，发送给业务匹配子系统200进行分布式流处理。
所述业务匹配子系统200主要采用分布式流处理思想，实现业务匹配功能。图6为基于分布式流处理的业务匹配设计思路，其主要过程包括，获取外部数据源，采用分布式流处理平台对数据源进行管理，由分布式流处理平台获取数据并对数据进行解析，对解析后的数据进行业务规则匹配，依据匹配结果生成并存储日志并进行统计分析。本实施例采用基于storm框架的结构形式实现分布式流处理思想，并且采用redis完成数据的接收、暂存，实现数据流缓冲。其中，所述redis可以作为消息容器，便于storm框架从redis中提取数据，生成输入数据流。
所述基于storm框架的业务规则匹配装置具体可以包括redisspout、splitbolt、filterbolt、loggerbolt和counterbolt五大模块。分别完成数据流的生成、数据解析、业务匹配、日志存储和运算统计五大功能。
所述storm框架的具体工作流程可包括：
步骤a1：由redisspout连续读取redis中的数据，作为分布式流处理框架消息的生产者，生成storm输入流。
步骤a2：由splitbolt完成数据的解析工作，将数据单元中的信息拆分为源端地址、目的端地址、端口号、请求正文等元信息，所述splitbolt将处理过的数据发送到filterbolt进行进一步加工。
步骤a3：filterbolt封装具体的业务逻辑，对数据单元进行细分过滤，生成有效数据集，在filterbolt中封装的业务逻辑与程序处理逻辑低耦合，用户可以灵活配置多样化的业务逻辑，程序以正则表达式的形式实现每一项具体规则，并将规则注入到filterbolt的处理过程中，实现业务配置的灵活性；该模块实现业务匹配功能，在完成细分过滤后，将匹配的数据单元重组为xdr数据。
步骤a4：counterbolt模块实现对数据集合的统计分析工作，根据业务的具体需要，可以配置统计规则和分析算法，对数据集进行聚合、连接，转换等多样化分析，便于后续的可视化呈现。
步骤sa5：loggerbolt模块中的程序根据结果数据集的规模选择相应的处理函数，实现结果集的持久化工作，当需要的数据规模较小时，为了便于导出，loggerbolt将数据结果输出到本地文件系统中，当数据规模较大时，loggerbolt将结果输出到关系型数据库中，方便运维人员的查询调取。
当然，如果系统的硬件环境支持分布式存储时，程序亦可将数据结果存储在分布式文件系统中，充分利用集群的存储资源，实现大规模数据的持久化。在服务器端结合hadoop分布式文件系统hdfs，将counterbolt统计的相关数据以及xdr信息存储起来。因为hdfs具有存储容量大、可扩展性强等特点，所以可以将大规模数据持久化到集群，便于日后的分析和使用。
基于上述技术方案，通过本申请上述实施例公开的技术方案可见，本申请将分布式流处理模式与深度包解析思想结合起来，先将数据报文协议规则匹配，再做业务相关的细致匹配，将业务规则匹配任务分配到多个处理节点中，使处理节点中的计算资源能够得到充分利用。同时，基于分布式流处理模式的计算方案能够在短时间内将连续的数据报文匹配、整合为便于业务人员理解的xdr数据，既满足了实际业务分析中高吞吐量、低时延的要求，又保证了输出xdr数据的体量和质量，满足了运营商通信设备网络中实时分析大规模流量数据的需求，极大地提升了分析效率和速度，规避了大数据处理对系统容量的需求压力。而进一步的技术方案中通过软件定义的思想灵活配置匹配规则进行协议匹配和业务匹配，有助于系统运维人员快速获取到所需的业务xdr数据。
对应于上述系统，本申请还公开了一种网络流量数据解析方法，应用于数据处理系统中，所述数据处理系统中预架构有多个流量数据采集节点和多个处理节点，参见图4，该方法可以包括：
步骤s101：从各采集节点获取信令中转设备转接的原始网络流量数据，所述原始网络流量数据中包含有原始报文。
步骤s102：依据协议匹配规则对原始网络流量数据中的原始报文进行协议匹配。
步骤s103：对协议匹配后的原始报文标注分类标识。
具体的，与上述系统相对应，对原始报文标注分类标识的具体原则可以为：依据原始报文之间的关联性，对相互关联的原始报文配置相同的id标识；其中关联的判别方式可以依据用户需求设置不同的判断原则，例如可以是指的是：具有相同信源、信宿的数据报文、同一时间段内发出的数据报文和/或具有相同端口号的数据报文。
步骤s104：依据所述分类标识和负载均衡原则为加分类标识后的原始报文确定对应的目标处理节点，将协议匹配后的原始报文发送至所述目标处理节点。
具体的，本步骤可以包括：具体的，获取要分发的原始报文的分类标识，判断所述处理节点中是否存在与所述分类标识相同的原始报文，如果存在，将要分发的所述原始报文分发至该处理节点，如果不存在，依据负载均衡原则由各个处理节点中选择一个处理节点作为目标处理节点，将所述原始报文下发至所述目标处理节点。
步骤s105：所述所有处理节点采用分布式流数据处理方式，对收到的报文依据业务匹配规则进行业务匹配，将匹配出的数据重组为业务xdr数据输出。
与上述方法相对应，所述步骤s105具体为：基于storm框架的匹配引擎对获取到的原始报文进行业务规则匹配，并不间断地将匹配成功的报文重组为业务xdr数据。
在本申请上述实施例公开的技术方案中，进行协议规则匹配和业务规则匹配之前还可以包括：
获取协议匹配规则和业务匹配规则；
将所述协议匹配规则分发给各采集节点，将所述业务匹配规则分发给各处理节点。
当然，在获取到所述协议匹配规则和业务匹配规则之后，下发协议匹配规则和业务匹配规则之前，还需对所述协议匹配规则和业务匹配规则进行预处理，其中，所述预处理可以为：对所述匹配规则进行整合，去除所述匹配规则中的冗余规则，并分别形成协议匹配判断树、业务匹配判断树，形成简化的匹配规则。
与上述系统相对应，在本方法中，所述协议匹配规则和业务匹配规则可以采用正则表达式描述，具体的，在获取到协议匹配规则、业务匹配规则后，采用正则表达式描述所述协议匹配规则和业务匹配规则并存储至配置文件中，当还可以通过人机交互界面获取用户输入的协议特征、业务需求，然后给予所述协议特征、业务需求采用正则表达式表述所述协议匹配规则、业务匹配规则，并存储至所述配置文件中。
与上述方法相对应，输出业务xdr数据之后，还可以包括：将所述输出的业务xdr数据进行分布式文件存储。
参见图5，对本申请实施例公开的网络流量数据解析方法的整体工作流程进行说明：
规则管理模块将所述规则数据库中的协议匹配规则分发给各采集节点用于进行协议规则匹配，将所述业务匹配规则分发给各处理节点用于业务规则匹配；
首先进行网络采集，获取原始网络流量数据，依据获取到的协议匹配规则进行协议规则匹配；
对协议规则匹配后的原始报文进行数据标注，以对协议匹配后的原始报文标注分类标识；
对标注后的报文进行数据分发，将标注后的原始报文发送至所述目标处理节点；
目标处理节点获取到报文后，将缓存报文消息；
提取缓存的报文消息，并依据业务匹配规则进行业务规则匹配；
将匹配出的数据重组为业务xdr数据输出；
导入分类数据库，分类数据库对业务xdr数据进行分布式文件存储。
为了描述的方便，描述以上系统时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。