CN109254982A - 一种流数据处理方法、系统、装置及计算机可读存储介质 - Google Patents

Abstract

本申请公开了一种流数据处理方法，从消息型队列中获取流数据，即此时消息型队列的输出数据为Flink的输入数据，借助消息型队列对初始流数据进行了一次处理，接着利用预设的数据解析规则将接收到的流数据一一解析成键值对事件，以充分结合现今被广泛使用的关系型数据库实现对数据和其对应关系的保存，便于后续基于SQL实现对数据的处理，同时还利用数据分析引擎从多方面、多角度进行数据分析，提升分析结果的准确程度，在应用了本申请提供的数据流处理方法的Flink框架上，可实现对传统流数据业务的快速展开，与现有工具结合更加紧密，效率更高。本申请还同时公开了一种流数据处理系统、装置及计算机可读存储介质，具有上述有益效果。

Description

一种流数据处理方法、系统、装置及计算机可读存储介质

技术领域

本申请涉及数据处理技术领域，特别涉及一种流数据处理方法、系统、装置及计算机可读存储介质。

背景技术

在数据处理领域，数据在某种划分方式下可被划分内批数据和流数据两类，相较于静态的存储于固定地点的、有界的批数据，流数据因其源源不断的特性在处理的过程中明显区别于批数据，且处理难度较大。

现存在多种可用于处理流数据的框架，例如仅用处理流数据的Storm和Samza流处理框架，以及不仅能够处理流数据还能够实现对小规模批数据进行处理的Flink框架，这是因为Flink能够大规模执行，具有非常高的吞吐量，即使在无序或者数据延迟的情况下也能提供正确的结果，并且它是拥有状态和容错能力，可以从故障中恢复。

单纯的Flink的功能较为单一，Flink SQL在实际应用中功能有限，Flink CEP使用较为复杂功能也不够完备，不便于快速的对基于诸如系统日志、文件调动、设备状态监控等流数据展开相关业务。

因此，如何克服现有仅单一的使用Flink来实现对流数据的处理和业务展开过程存在的缺陷，提供一种功能更丰富、业务展开速度更快、分析效率更高、与实际应用场景结合更紧密的流处理处理机制是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种流数据处理方法，从消息型队列中获取流数据，即此时消息型队列的输出数据为Flink的输入数据，借助消息型队列对初始流数据进行了一次处理，接着利用预设的数据解析规则将接收到的流数据一一解析成键值对事件，以充分结合现今被广泛使用的关系型数据库实现对数据和其对应关系的保存，便于后续基于SQL实现对数据的处理，同时还利用数据分析引擎从多方面、多角度进行数据分析，提升分析结果的准确程度，在应用了本申请提供的数据流处理方法的Flink框架上，可实现对传统流数据业务的快速展开，与现有工具结合更加紧密，效率更高。

本申请的另一目的在于提供了一种流数据处理系统、装置及计算机可读存储介质。

为实现上述目的，本申请提供一种流数据处理方法，应用于Flink框架，该流数据处理方法包括：

从消息型队列中获取流数据；

利用预设的数据解析规则解析所述流数据，得到各键值对事件，并为各所述键值对事件增加类型信息，得到各Schema信息；

接收输入的SQL流指令，并利用数据分析引擎按所述SQL流指令对各所述Schema信息进行分析，得到分析结果；

通过第一预设路径输出所述分析结果；

其中，所述SQL流指令中的各指令基于类SQL语法编写得到，所述类SQL语法为遵循ANSI SQL标准的SQL语法。

可选的，在从消息型队列中获取流数据之前，还包括：

利用Kafka以主题的方式处理初始流数据，得到所述流数据；

对应的，从消息型队列中获取流数据，具体为：

从所述Kafka中获取所述流数据。

可选的，接收输入的SQL流指令，包括：

利用QueryService通过Restful API接收用户输入的SQL流指令。

可选的，通过第一预设路径输出所述分析结果，包括：

将所述分析结果输出至ElasticSearch，以利用所述ElasticSearch解析所述分析结果中包含的数据文档，并通过第二预设路径发送携带有所述数据文档的分析报告或告警信息。

可选的，所述数据分析引擎包括：

统计分析引擎、正则匹配引擎、机器学习引擎、数据预处理引擎中的至少一项。

为实现上述目的，本申请还提供了一种流数据处理系统，应用于Flink框架，该流数据处理系统包括：

流数据获取单元，用于从消息型队列中获取流数据；

事件解析单元，用于利用预设的数据解析规则解析所述流数据，得到各键值对事件，并为各所述键值对事件增加类型信息，得到各Schema信息；

指令接收及分析单元，用于接收输入的SQL流指令，并利用数据分析引擎按所述SQL流指令对各所述Schema信息进行分析，得到分析结果；

分析结果输出单元，用于通过第一预设路径输出所述分析结果；

其中，所述SQL流指令中的各指令基于类SQL语法编写得到，所述类SQL语法为遵循ANSI SQL标准的SQL语法。

可选的，该流数据处理系统还包括：

Kafka处理单元，用于利用Kafka以主题的方式处理初始流数据，得到所述流数据；

对应的，所述流数据获取单元具体为：从所述Kafka中获取所述流数据。

可选的，所述指令接收及分析单元包括：

QueryService子单元，用于利用QueryService通过Restful API接收用户输入的SQL流指令。

可选的，所述分析结果输出单元包括：

ElasticSearch子单元，用于将将所述分析结果输出至ElasticSearch，以利用所述ElasticSearch解析所述分析结果中包含的数据文档，并通过第二预设路径发送携带有所述数据文档的分析报告或告警信息。

为实现上述目的，本申请还提供了一种流数据处理装置，该装置包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述内容所描述的流数据处理方法的步骤。

为实现上述目的，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述内容所描述的流数据处理方法的步骤。

显然，本申请所提供的一种流数据处理方法，从消息型队列中获取流数据，即此时消息型队列的输出数据为Flink的输入数据，借助消息型队列对初始流数据进行了一次处理，接着利用预设的数据解析规则将接收到的流数据一一解析成键值对事件，以充分结合现今被广泛使用的关系型数据库实现对数据和其对应关系的保存，便于后续基于SQL实现对数据的处理，同时还利用数据分析引擎从多方面、多角度进行数据分析，提升分析结果的准确程度，在应用了本申请提供的数据流处理方法的Flink框架上，可实现对传统流数据业务的快速展开，与现有工具结合更加紧密，效率更高。本申请同时还提供了一种流数据处理系统、装置及计算机可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的一种流数据处理方法的流程图；

图2为本申请实施例提供的又一种流数据处理方法的流程图；

图3为本申请实施例提供的一种基于Flink框架的日志处理方法的逻辑示意图；

图4为本申请实施例提供的一种流数据处理系统的结构框图。

具体实施方式

本申请的核心是提供一种流数据处理方法、系统、装置及计算机可读存储介质，从消息型队列中获取流数据，即此时消息型队列的输出数据为Flink的输入数据，借助消息型队列对初始流数据进行了一次处理，接着利用预设的数据解析规则将接收到的流数据一一解析成键值对事件，以充分结合现今被广泛使用的关系型数据库实现对数据和其对应关系的保存，便于后续基于SQL实现对数据的处理，同时还利用数据分析引擎从多方面、多角度进行数据分析，提升分析结果的准确程度，在应用了本申请提供的数据流处理方法的Flink框架上，可实现对传统流数据业务的快速展开，与现有工具结合更加紧密，效率更高。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

实施例一

以下结合图1，图1为本申请实施例提供的一种流数据处理方法的流程图，其具体包括以下步骤：

S101：从消息型队列中获取流数据；

本步骤旨在将消息型队列输出的流数据作为Flink框架的输入数据，目的在于借助消息型队列具有的数据处理能力先对初始的流数据进行一些处理，以分担一部分Flink框架的处理压力和降低一些数据处理难度。

消息被发送到队列中，消息队列(Message Queue，MQ)是在消息的传输过程中保存消息的容器，消息队列管理器在将消息从它的源中继到它的目标时充当中间人，而队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

通过消息队列，应用程序可以在不知道彼此位置的情况下独立处理消息，或者在处理消息前不需要等待接收此消息，所以消息队列可以解决应用解耦、异步消息、流量削锋等问题，是实现高性能、高可用、可伸缩和最终一致性架构中不可以或缺的一环。根据具体应用场景的不同和功能特化的方向，现今应用广泛的消息型队列包括ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。

此处对上述提及的几种消息型队列的特点进行说明：ZeroMQ仅是一个简单好用的传输层，可在与其它框架结合后作为消息队列使用，不过二次开发难度较大，且ZeroMQ不支持消息持久化；RabbitMQ在数据一致性、稳定性和可靠性方面比较优秀，且直接或间接的支持多种协议，对多种语言支持良好，但是其性能和吞吐量差强人意，同时二次开发成本受Erlang语言的限制；ActiveMQ则介于ZeroMQ和RabbitMQ之间，各拥有两者的一部分优点，但其缺点是不够轻巧，且对于队列较多的情况支持不好，还存在丢消息的情况；Kafka是一个高性能跨语言分布式Publish/Subscribe(公开的或私有的)消息队列系统，以Pull的形式消费消息，具有快速持久化、高吞吐以及完全的分布式系统的特性，且专为日志流平台和运营消息管道平台设计，还实现了消息顺序排列、海量堆积以及支持按主题进行分类的功能；RocketMQ是阿里开源的消息中间件，使用纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点，RocketMQ基于Kafka开发，但还对消息的可靠传输及事务性做了优化，被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。以上提及的各类消息型队列可根据实际需要构建的业务的类型，灵活选用，此处并不做具体限定。

进一步的，加入上述消息型队列中的流数据可来自Logstash以及拥有相同或类似功能的流数据搜集引擎，Logstash就是一个专用于日志的日志搜集引擎，当流数据种类为其它类型时，可以采用相应种类的搜集引擎实现，此处并不做具体限定。

还需要说明的是，Flink可以同时接收来自多个消息型队列的输出数据，即可以将每个消息型队列作为一个数据源添加至自身框架，但为了数据类型和格式的一致性，在采用多个数据源的情况下会尽量使得各数据源输出的数据类型和格式一致。

S102：利用预设的数据解析规则解析流数据，得到各键值对事件，并为各键值对事件增加类型信息，得到各Schema信息；

在S101的基础上，本步骤旨在利用预设的数据解析规则解析从消息型队列输出的流数据，并将其解析为一个个键值对事件，并进一步为仅包含键值信息的事件增加类型信息，以便后续根据类型信息来进行分析。其中，键值对是指以Key-Value形式存在的一对数据，其中，Key被称为键，Value被称为值，每个Key唯一对应一个Value，其两者之间一个明显的对应关系，基于键值对形式构建的数据库也被称为关系型数据，其通常采用SQL(Structured Query Language，结构化查询语言)实现在数据库中的数据查询。Schmea信息中包含字段与类型的关系，在解析为键值对事件后，还需要形成其对应的映射，以便被后面的数据直接引用，假设一个键值对事件的类型为数值型，可以使用诸如sum(bytesln),(a+b)等命令，但字符串型却无法使用，也就是说为后续数据调用提供了一些必要信息。

因此，使用预设数据解析规则的目的在于，将原先为其它格式的流数据转换成可基于SQL指令完成查询和分析操作的键值对事件，以便与现有应用环境中广泛使用的关系型数据库相结合。

当然，在实际情况允许的情况下，还可以进一步的外界非关系型数据库的，并通过相关组件和服务实现关系型数据库和非关系数据库的互相转换。

S103：接收输入的SQL流指令，并利用数据分析引擎按SQL流指令对各Schema信息进行分析，得到分析结果；

在S102完成键值对事件的解析和类型信息添加的基础上，本步骤旨在接收输入的SQL流指令，并利用数据分析引擎按SQL流指令对各Schema信息进行分析，得到分析结果。其中，SQL流指令的英文为：Stream SQL，也可以理解为SQL指令流，用于实现相关功能，且需要说明的是，该SQL流指令中的各指令基于类SQL语法编写得到，该类SQL语法为遵循ANSI SQL标准的SQL语法，是为了降低分析人员业务实现复杂性，基于ANSI SQL标准编写得到，但降低了标准SQL编写难度的一种SQL语法。

另外，该数据分析引擎可根据实际情况包括多种数据处理算法，例如统计分析算法、正则匹配算法、机器学习算法、数据预处理算法，其中，机器学习算法又可包含多类数据挖掘算法，例如聚类算法、人工申请网络算法等，此处旨在使用这些数据分析算法去更好的实现基于SQL流指令的数据分析。

根据实际需求，还可以预先使用选取的数据分析引擎对已由数据进行分析，以便于在接收到SQL流指令时减少分析时间。

S104：通过第一预设路径输出分析结果。

在S103的基础上，本步骤旨在通过预设的路径输出分析结果，一种包括但不限于的方式为：

将分析结果输出至ElasticSearch，ElasticSearch是一个搜索服务器，它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口，且ElasticSearch设计用于云计算中，能够达到实时搜索，稳定，可靠，快速。ElasticSearch将数据分片以便后续索引和获取，实际应用广泛。

ElasticSearch一种可行的输出分析结果的方式，利用它强大的聚合功能可以快速的构建可视化效果。

基于上述技术方案，本申请实施例提供的一种流数据处理方法，从消息型队列中获取流数据，即此时消息型队列的输出数据为Flink的输入数据，借助消息型队列对初始流数据进行了一次处理，接着利用预设的数据解析规则将接收到的流数据一一解析成键值对事件，以充分结合现今被广泛使用的关系型数据库实现对数据和其对应关系的保存，便于后续基于SQL实现对数据的处理，同时还利用数据分析引擎从多方面、多角度进行数据分析，提升分析结果的准确程度，在应用了本申请提供的数据流处理方法的Flink框架上，可实现对传统流数据业务的快速展开，与现有工具结合更加紧密，效率更高。

实施例二

以下结合图2，图2为本申请实施例提供的又一种流数据处理方法的流程图，本实施例在实施例一的基础上，以日志这种流数据为例，通过S201和S202给出了一种以Kafka作为消息型队列时如何获取流数据的方法，通过S204给出了一种如何接收SQL指令的方法，通过S205提供了一种将分析结果输出至ElasticSearch并借助ElasticSearch实现报告和信息反馈的方法，需要说明的是，这三部分均可以单独基于实施例一形成相应的实施例，本实施例仅作为其中一种同时存在三个优选方式的实施例，具体实施例步骤如下：

S201：利用Kafka以主题的方式处理初始流数据，得到流数据；

借助专为日志这种流数据设计的Kafka处理初始日志数据，并以主题的方式初始日志数据中的信息按主题分类。

S202：从Kafka中获取流数据；

Flink添加kafka数据源，以将kafka中的数据在流程序中消费，特别指出，Flink通过StreamExecutionEnvironment.addSource将Kafka主题中的数据源添加流程序中。

S203：利用预设的数据解析规则解析流数据，得到各键值对事件；

Flink通过加载解析模块对接收到的日志数据进行解析，将日志源逐条解析为键值对事件：

S204：利用QueryService通过Restful API接收用户输入的SQL流指令，并利用数据分析引擎按SQL流指令对各键值对事件进行分析，得到分析结果；

其中，QueryService是一个服务组件，可通过Restful API(基于REST风格的接口)接收用户编写的StreamSQL，QueryService会根据类SQL语法解析接收到的StreamSQL，并生成Query Job及配置文件，路由到Flink相关数据分析引擎来处理该Query Job。

S205：将分析结果输出至ElasticSearch，以利用ElasticSearch解析分析结果中包含的数据文档，并通过第二预设路径发送携带有数据文档的分析报告或告警信息。

Flink还可将指定Kafka主题输出到Elasticsearch，自动生成Dashbord(仪表板)和Report(报告)，告警数据可直接通过Email或者短信发送给订阅者。

Elasticsearch还可以根据业务要求，解析出业务需要的数据文档。

进一步的，在得到该分析结果时，还可以将该分析结果再次返回Kafka，以新的主题进行再处理，新的Kafaka主题是指根据用户进行的处理所定义的主题，每个主题的数据可以在流程序中进行再消费。

形象的，还可以参见图3，图3为本申请实施例提供的一种基于Flink框架的日志处理方法的逻辑示意图，图中的yarn是指Apache Hadoop YARN，Yet Another ResourceNegotiator，另一种资源协调者，是一种新的Hadoop(一种分布式系统基础架构)资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处，其中，ML模块指的是RedisModules，是一种在Redis(一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库)以Modules(组件)方式进行拓展的功能模块。

因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到根据本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。

下面请参见图4，图4为本申请实施例提供的一种流数据处理系统的结构框图，该流数据处理系统可以包括：

流数据获取单元100，用于从消息型队列中获取流数据；

事件解析单元200，用于利用预设的数据解析规则解析流数据，得到各键值对事件，并为各键值对事件增加类型信息，得到各Schema信息；

指令接收及分析单元300，用于接收输入的SQL流指令，并利用数据分析引擎按SQL流指令对各Schema信息进行分析，得到分析结果；

分析结果输出单元400，用于通过第一预设路径输出分析结果；

其中，SQL流指令中的各指令基于类SQL语法编写得到，类SQL语法为遵循ANSI SQL标准的SQL语法。

进一步的，该流数据处理系统还可以包括：

Kafka处理单元，用于利用Kafka以主题的方式处理初始流数据，得到流数据；

对应的，流数据获取单元100具体为：从Kafka中获取流数据。

其中，指令接收及分析单元300可以包括：

QueryService子单元，用于利用QueryService通过Restful API接收用户输入的SQL流指令。

其中，分析结果输出单元400可以包括：

ElasticSearch子单元，用于将分析结果输出至ElasticSearch，以利用ElasticSearch解析分析结果中包含的数据文档，并通过第二预设路径发送携带有数据文档的分析报告或告警信息。

基于上述实施例，本申请还提供了一种流数据处理装置，该装置可以包括存储器和处理器，其中，该存储器中存有计算机程序，该处理器调用该存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然，该装置还可以包括各种必要的网络接口、电源以及其它零部件等。

本申请还提供了一种计算机可读存储介质，其上存有计算机程序，该计算机程序被执行终端或处理器执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random AccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，且各个实施例间为递进关系，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，可参见对应的方法部分说明。以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种流数据处理方法，其特征在于，应用于Flink框架，包括：

从消息型队列中获取流数据；

利用预设的数据解析规则解析所述流数据，得到各键值对事件，并为各所述键值对事件增加类型信息，得到各Schema信息；

接收输入的SQL流指令，并利用数据分析引擎按所述SQL流指令对各所述Schema信息进行分析，得到分析结果；

通过第一预设路径输出所述分析结果；

其中，所述SQL流指令中的各指令基于类SQL语法编写得到，所述类SQL语法为遵循ANSISQL标准的SQL语法。

2.根据权利要求1所述的流数据处理方法，其特征在于，在从消息型队列中获取流数据之前，还包括：

利用Kafka以主题的方式处理初始流数据，得到所述流数据；

对应的，从消息型队列中获取流数据，具体为：

从所述Kafka中获取所述流数据。

3.根据权利要求1所述的流数据处理方法，其特征在于，接收输入的SQL流指令，包括：

利用QueryService通过Restful API接收用户输入的SQL流指令。

4.根据权利要求1所述的流数据处理方法，其特征在于，通过第一预设路径输出所述分析结果，包括：

将所述分析结果输出至ElasticSearch，以利用所述ElasticSearch解析所述分析结果中包含的数据文档，并通过第二预设路径发送携带有所述数据文档的分析报告或告警信息。

5.根据权利要求1至4任一项所述的流数据处理方法，其特征在于，所述数据分析引擎包括：

统计分析引擎、正则匹配引擎、机器学习引擎、数据预处理引擎中的至少一项。

6.一种流数据处理系统，其特征在于，应用于Flink框架，包括：

流数据获取单元，用于从消息型队列中获取流数据；

事件解析单元，用于利用预设的数据解析规则解析所述流数据，得到各键值对事件，并为各所述键值对事件增加类型信息，得到各Schema信息；

指令接收及分析单元，用于接收输入的SQL流指令，并利用数据分析引擎按所述SQL流指令对各所述Schema信息进行分析，得到分析结果；

分析结果输出单元，用于通过第一预设路径输出所述分析结果；

其中，所述SQL流指令中的各指令基于类SQL语法编写得到，所述类SQL语法为遵循ANSISQL标准的SQL语法。

7.根据权利要求6所述的流数据处理系统，其特征在于，还包括：

Kafka处理单元，用于利用Kafka以主题的方式处理初始流数据，得到所述流数据；

对应的，所述流数据获取单元具体为：从所述Kafka中获取所述流数据。

8.根据权利要求7所述的流数据处理系统，其特征在于，所述分析结果输出单元包括：

ElasticSearch子单元，用于将所述分析结果输出至ElasticSearch，以利用所述ElasticSearch解析所述分析结果中包含的数据文档，并通过第二预设路径发送携带有所述数据文档的分析报告或告警信息。

9.一种流数据处理装置，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至5任一项所述的流数据处理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述的流数据处理方法的步骤。