CN112035534A - 一种实时大数据处理方法、装置及电子设备 - Google Patents

Abstract

本申请提供一种实时大数据处理方法、装置及电子设备，方法包括：当数据源的数据有更新，将更新数据发送到第一消息队列；通过预设规则或模型解析，从第一消息队列里的更新数据中提取标签，并将更新数据及对应的标签发送到第二消息队列；将预设时间范围内的第二消息队列里的数据及对应的标签存储到第一数据库；基于标签对第二消息队列里的数据过滤，将与标签一致的对应数据存放到第二数据库；将第二消息队列里的数据按照主题分类，筛选主题与预设主题一致的数据存储到第三数据库。根据本申请实施例的实时大数据处理方法、装置及电子设备，能够实现自动实时大数据处理，无需手动触发，新增数据可以实时得到处理结果。

Description

一种实时大数据处理方法、装置及电子设备

技术领域

本申请涉及大数据领域，尤其涉及一种实时大数据处理方法、装置及电子设备。

背景技术

现在常规的批处理大数据需要每天手动启动一次程序，对10GB数量级的文件数据进行处理，将处理结果存储到某个数据库或数据库集群中。每次手动触发程序运行，两次触发时间点之间的数据，不会立即处理，常规的批处理存在严重的滞后性，当读取超大文件，需要消耗大量内存，机器运行成本非常高，运行速度慢，日积月累，当数据库中的数据过多时，批处理查询性能会大幅下降。

发明内容

有鉴于此，本申请提供一种实时大数据处理方法、装置及***，能够实现自动实时大数据处理，无需手动触发，新增数据可以实时得到处理结果，控制内存占用，在小内存机器上也能高效运行，既能存储大规模数据，又能保证高效的查询性能，使得实时大数据处理过程更高效。

为解决上述技术问题，本申请采用以下技术方案：

第一方面，本申请提供一种实时大数据处理方法，方法包括：

监听数据源，实时监听所述数据源，当所述数据源的数据有更新，将更新数据发送到第一消息队列；

提取数据标签，通过预设规则或模型解析，从所述第一消息队列里的更新数据中提取标签，并将所述更新数据及对应的所述标签发送到第二消息队列，其中，所述标签用于标识数据关键信息；

数据分类存储，包括：

将预设时间范围内的所述第二消息队列里的数据及对应的标签存储到第一数据库；

基于所述标签对所述第二消息队列里的数据过滤，将与所述标签一致的对应数据存放到第二数据库；

将所述第二消息队列里的数据按照主题分类，筛选所述主题与预设主题一致的数据存储到第三数据库，其中，所述主题用于总结数据含义。

作为本申请的第一方面的一个实施例，所述监听数据源包括：

定时启动或关闭对所述数据源的监听。

作为本申请的第一方面的一个实施例，当用户更改生成所述标签的规则或模型时，实时生成新的标签时，并且开启定时任务，对所述第一数据库里的数据重新提取数据标签，并进行数据分类存储，更新所述第一数据库、第二数据库、第三数据库。

作为本申请的第一方面的一个实施例，所述数据源的数据可以是文本数据、音频数据、视频数据中任一种。

作为本申请的第一方面的一个实施例，所述提取数据标签和所述数据分类存储是实时流任务，在流处理框架下执行该任务。

作为本申请的第一方面的一个实施例，所述流处理框架可以选择Flink、Storm、Map Reduce、Spark中任一种。

作为本申请的第一方面的一个实施例，所述第一数据库是全量数据库，所述全量数据库用于存储在预设时间范围内的全部数据及该数据对应的所述标签；所述全量数据库对其内部存储的数据设有数据生命周期，基于所述数据生命周期定期清除超出所述数据生命周期的数据；

所述第二数据库是现行数据库，所述现行数据库用于存储基于标签过滤所述第二消息队列内后的数据，且所述现行数据库对应的上层应用可显示或查询所述现行数据库；

所述第三数据库是存档数据库，所述存档数据库用于存储与人工筛选的数据，且所述存档数据库中的数据是永久保存。

第二方面，本申请实施例提供了一种实时大数据处理装置，所述装置包括：

监听数据源模块，实时监听所述数据源，当所述数据源的数据有更新，将更新数据发送到第一消息队列；

提取数据模块，通过预设规则或模型解析，从所述第一消息队列里的更新数据中提取标签，并将所述更新数据及对应的所述标签发送到第二消息队列，其中，所述标签用于标识数据关键信息；

数据分类存储模块，包括：

将预设时间范围内的所述第二消息队列里的数据及对应的标签存储到第一数据库；

基于所述标签对所述第二消息队列里的数据过滤，将与所述标签一致的对应数据存放到第二数据库；

将所述第二消息队列里的数据按照主题分类，筛选所述主题与预设主题一致的数据存储到第三数据库，其中，所述主题用于总结数据含义，能够归纳总结数据的含义。例如，一篇文章的主题，该主题可以概括总结文章表达的思想。

作为本申请的第二方面的一个实施例，所述监听数据源模块包括：定时启动或关闭对所述数据源的监听。

作为本申请的第二方面的一个实施例，当用户更改生成所述标签的规则或模型时，实时生成新的标签时，并且开启定时任务，对所述第一数据库里的数据重新提取数据标签，并进行数据分类存储，更新所述第一数据库、第二数据库、第三数据库。

作为本申请的第二方面的一个实施例，所述数据源的数据可以是文本数据、音频数据、视频数据中任一种。

作为本申请的第二方面的一个实施例，所述提取数据标签模块和所述数据分类存储模块执行实时流任务，在流处理框架下执行该任务。

作为本申请的第二方面的一个实施例，所述流处理框架可以选择Flink、Storm、Map Reduce、Spark中任一种。

作为本申请的第二方面的一个实施例，所述第一数据库是全量数据库，所述全量数据库用于存储在预设时间范围内的全部数据及该数据对应的所述标签；所述全量数据库对其内部存储的数据设有数据生命周期，基于所述数据生命周期定期清除超出所述数据生命周期的数据；

所述第二数据库是现行数据库，所述现行数据库用于存储基于标签过滤所述第二消息队列内后的数据，且所述现行数据库对应的上层应用可显示或查询所述现行数据库；

所述第三数据库是存档数据库，所述存档数据库用于存储与人工筛选的数据，且所述存档数据库中的数据是永久保存。

第三方面，本申请实施例提供了一种电子设备，包括处理器和存储器，

所述存储器中存储有指令，

所述处理器，用于读取所述存储器中存储的所述指令，以执行上述实时大数据处理方法任一项所述的方法。

本申请的上述技术方案至少具有如下有益效果之一：

根据本申请实施例的实时大数据处理方法、装置及电子设备，能够自动对数据源进项监控，无需手动触发，流式读取数据，降低了对内存的占用，加快了数据处理速度，新增数据可以实时得到处理结果，并且本申请实施例提供了三种数据库，分别存储全量数据、现行处理的数据和永久存档的数据，既能保证大规模数据存储，又能保证高效的查询数据性能，使得实时大数据处理的实时性更强、更高效。

附图说明

图1为本申请实施例的实时大数据处理方法的场景图；

图2为本申请实施例的实时大数据处理方法流程图；

图3为本申请实施例的实时大数据处理装置的示意图；

图4为本申请实施例的实时大数据处理装置的架构示意图。

具体实施方式

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

下面结合具体的场景对本申请实施例进行说明。

图1是根据本申请一个实施例的实时大数据处理方法的应用场景图。大数据处理的场合多种多样，这里以社交网站作为本申请实施例的一种应用场景举例说明。如图1所示，社交网站是现代社会很热门的软件，每个人都可以在上面认识朋友，发表自己的想法，记录生活中的事情，这也就意味着微博上每天要处理PB级别(Petabyte千万亿字节)的数据，且社交网站上的数据实时更新。一些公司单位，如科研机构、公司运营部门，需要每天从PB级别的数据中找到自己关注的信息，进行分析。例如，统计社交网站中特定的关键词出现的频率，分析用户群体的喜好，挖掘用户感兴趣的主题或带有某些关键字的文章，并能进一步匹配得到对应的用户信息。又例如，公关部门对社交网站上的数据进行舆情分析，实时采集社交网站上的媒体新闻、粉丝动向，能够及时发现问题，并尽早处理解决问题。

根据本申请的实施例，通过监听数据源，自动获取社交网站每天更新的数据，当监听到有新的数据，立即提取数据的标签，通过流处理框架对更新的数据做处理，其中，流处理框架可以选择Flink流处理框架，能够在较短时间内取得数据的标签，帮助用户分析数据的关键信息，在流式处理框架中，采用流式读取数据内容，而不是一次性加载全部数据，由此，本申请实施例运行时内存占用始终维持较低水平，由于单次读取的数据量小，数据计算速度会加快。最后，将数据存储到三个数据库，一个全量数据库，用于存储获得的所有数据，方便后期数据溯源，并且设定了数据生命周期，防止全量数据库存储空间过大。一个现行数据库，用于存储正在处理的数据，可以供上层应用快速查询。一个存档数据库，用于永久存储的重要数据，使得重要数据得到了保护。由此，本申请实施例实时大数据处理方法能够自动对数据源进项监控，无需手动触发，流式读取数据，降低了对内存的占用，加快了数据处理速度，新增数据可以实时得到处理结果，并且本申请实施例提供了三种数据库，分别存储全量数据、现行处理的数据和永久存档的数据，既能保证大规模数据存储，又能保证高效的查询数据性能，使得实时大数据处理更实时、更高效。

下面，首先对本发明实施例所提供的一种实时大数据处理方法进行介绍。

如图2所示，本发明实施例所提供的一种实时大数据处理方法的流程图，方法可以包括如下步骤：

步骤S201，监听数据源，实时监听数据源，当数据源的数据有更新，将更新数据发送到第一消息队列。具体地，设置一条进程，实时监听数据源，获取实时产生的数据，例如，对于社交网站上的数据，可以通过爬虫技术，获取社交网站每天产生的数据，并保存在文件中，其中，文件格式可以选择json格式，json数据格式格式简单，易于读写，且支持多种编程语言。每当有数据更新时，监听数据源的进程监听到数据源有变化，就会分段读入数据，导入到第一消息队列，在本申请的一个可选实施例中，第一消息队列选择kafka消息队列，kafka消息队列具有高吞吐量、低延迟的优点。由此，可以实现自动化监听数据源，实时获取更新数据。

步骤S202，提取数据标签，通过预设规则或模型解析，从第一消息队列里的更新数据中提取标签，并将更新数据及对应的标签发送到第二消息队列，其中，标签用于标识数据关键信息。提取数据标签这个过程在流处理框架下执行，流处理框架可以选择Flink、Storm、Map Reduce、Spark中任一种，在本申请的一个可选实施例中，选择Flink流处理框架，Flink流处理框架具有很少配置就能实现高吞吐、低延迟的优点。在Flink流处理框架下，流式读取kafka消息队列的数据，数据经过设置规则，或训练模型，映射取得标签。使用Flink流处理框架处理数据，可以占用内存较低，由此，单次处理数据量较小，提高了数据处理速度，能到达到一个实时大数据处理的效果。对数据提取了标签以后，将该数据和对应的标签发送到第二消息队列，第二消息队列也可以选择kafka消息队列，kafka消息队列具有高吞吐量、低延迟的优点。

步骤S203，数据分类存储，包括：

将预设时间范围内的第二消息队列里的数据及对应的标签存储到第一数据库。基于标签对第二消息队列里的数据过滤，将与标签一致的对应数据存放到第二数据库。将第二消息队列里的数据按照主题分类，筛选主题与预设主题一致的数据存储到第三数据库，其中，主题用于总结数据含义，能够归纳总结数据的含义。例如，一篇文章的主题，该主题可以概括总结文章表达的思想。

根据本申请的一个可选实施例，第一数据库是全量数据库，全量数据库用于存储在预设时间范围内的全部数据及该数据对应的标签；全量数据库对其内部存储的数据设有数据生命周期，基于数据生命周期定期清除超出数据生命周期的数据，避免全量数据库的数据量过大。设置全量数据库存储数据，有助于重新处理全量数据，也就是说，当标签发生变动的时候，Flink流处理框架下可以直接读取全量数据库，重新提取全量数据标签，获得新的标签过滤命中的数据。

第二数据库是现行数据库，现行数据库用于存储基于标签过滤第二消息队列内后的数据，且现行数据库对应的上层应用可显示或查询现行数据库。这里以社交网站举例，例如设置标签为“喜爱”，基于该标签过滤第二消息队列里的数据，当匹配到数据，该数据和对应的标签都会保存到现行数据库，用户可以在上层应用的前端界面查询现行数据库，例如，在前端界面看到提示，该数据提取的标签是“喜爱”，由此，用户读取数据，判断该数据是否需要进一步关注。

第三数据库是存档数据库，存档数据库用于存储与人工筛选的数据，且存档数据库中的数据是永久保存。在上一步骤，用户可以在上层应用的前端界面看到提示，当用户判断该数据比较重要，需要进一步关注该数据时，该条数据会被保存到存档数据库，做永久保存。

需要说明的是，本申请实施例中的数据库可以选择ES(ElasticSearch)数据库，ES数据库是一个分布式文档数据库，具有可拓展、高可用的优点，ES的数据分布式存储在多个服务器，可以处理PB级的数据，分布式存储的优点是利用多台存储服务器分担存储负荷，提高数据处理速度。

根据本申请的一个实施例，监听数据源包括：

定时启动或关闭对数据源的监听。例如，可以设定每天24点，开启对数据源的监听，进行对数据源更新数据的处理。

根据本申请的一个可选实施例，当用户更改生成标签的规则或模型时，实时生成新的标签时，并且开启定时任务，对第一数据库里的数据重新提取数据标签，并进行数据分类存储，更新第一数据库、第二数据库、第三数据库。也就是说，当用户感兴趣的标签变化了，本申请实施例可以设置定时任务，重新处理第一数据库中的数据，也就是全量数据库中的数据。重新获得命中标签的数据，并更新到现行数据库和存档数据库，并在现行数据库对应的上层应用的前端界面进行显示。

根据本申请的一个可选实施例，数据源的数据可以是文本数据、音频数据、视频数据中任一种。本申请实施例可以处理文本数据、音频数据、视频数据中任一种，在此，以文本数据的处理举例说明。

根据本申请的一个实施例，数据包括数据的事件时间属性和数据的处理时间属性。由此，能够避免因网络或***等外部因素影响，数据不能及时传输至流处理框架中，导致数据乱序到达或延迟到达等问题。

本发明实施例还提供了一种实时大数据处理装置，如图3所示，装置包括监听数据源模块3100、提取数据模块3200和数据分类存储模块3300。

其中，监听数据源模块3100，实时监听数据源，当数据源的数据有更新，将更新数据发送到第一消息队列。

提取数据模块3200，通过预设规则或模型解析，从第一消息队列里的更新数据中提取标签，并将更新数据及对应的标签发送到第二消息队列，其中，标签用于标识数据关键信息。其中，提取数据模块3200可以采用流处理框架执行，流处理框架可以选择Flink、Storm、Map Reduce、Spark中任一种，在本申请的一个可选实施例中，选择Flink流处理框架，Flink流处理框架具有很少配置就能实现高吞吐、低延迟的优点。

数据分类存储模块3300，包括：

将预设时间范围内的第二消息队列里的数据及对应的标签存储到第一数据库。基于标签对第二消息队列里的数据过滤，将与标签一致的对应数据存放到第二数据库。将第二消息队列里的数据按照主题分类，筛选主题与预设主题一致的数据存储到第三数据库，其中，主题用于总结数据含义。

根据本申请的一个可选实施例，监听数据源模块3100包括：定时启动或关闭对数据源的监听。

根据本申请的一个可选实施例，当用户更改生成标签的规则或模型时，实时生成新的标签时，并且开启定时任务，对第一数据库里的数据重新提取数据标签，并进行数据分类存储，更新第一数据库、第二数据库、第三数据库。

根据本申请的一个可选实施例，数据源的数据可以是文本数据、音频数据、视频数据中任一种。

根据本申请的一个可选实施例，提取数据标签模块3200和数据分类存储模块3300执行实时流任务，在流处理框架下执行该任务。

根据本申请的一个可选实施例，流处理框架可以选择Flink、Storm、Map Reduce、Spark中任一种。在本申请实施例实际应用中，选择Flink流处理框架，Flink流处理框架具有很少配置就能实现高吞吐、低延迟的优点。

根据本申请的一个可选实施例，第一数据库是全量数据库，全量数据库用于存储在预设时间范围内的全部数据及该数据对应的标签；全量数据库对其内部存储的数据设有数据生命周期，基于数据生命周期定期清除超出数据生命周期的数据。

第二数据库是现行数据库，现行数据库用于存储基于标签过滤第二消息队列内后的数据，且现行数据库对应的上层应用可显示或查询现行数据库。

第三数据库是存档数据库，存档数据库用于存储与人工筛选的数据，且存档数据库中的数据是永久保存。

在本申请的一个可选实施例中，数据库选择ES(ElasticSearch)数据库，ES数据库是一个分布式文档数据库，具有可拓展、高可用的优点，ES的数据分布式存储在多个服务器，可以处理PB级的数据。

本申请还提供一种电子设备，包括处理器和存储器，

存储器中存储有指令，处理器用于读取存储器中存储的指令，以执行上述实时大数据处理方法中如下步骤：

如图4所示，监听数据源，实时监听所述数据源，当所述数据源的数据有更新，将更新数据发送到第一消息队列，其中，图中以json格式的文本数据源举例，数据采集进入第一消息队列。

提取数据标签，读取第一消息队列的数据，通过预设规则或模型解析，从所述第一消息队列里的更新数据中提取标签，并将所述更新数据及对应的所述标签发送到第二消息队列。

数据分类存储，包括：将预设时间范围内的所述第二消息队列里的数据及对应的标签存储到第一数据库；基于所述标签对所述第二消息队列里的数据过滤，将与所述标签一致的对应数据存放到第二数据库；将所述第二消息队列里的数据按照主题分类，筛选所述主题与预设主题一致的数据存储到第三数据库，其中，所述主题用于总结数据含义。

由此，本申请实施例的实时大数据处理方法、装置及电子设备，能够自动对数据源进项监控，无需手动触发，流式读取数据，降低了对内存的占用，加快了数据处理速度，新增数据可以实时得到处理结果，并且本申请实施例提供了三种数据库，分别存储全量数据、现行处理的数据和永久存档的数据，既能保证大规模数据存储，又能保证高效的查询数据性能，使得实时大数据处理更实时、更高效。

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

以上所述是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请所述原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种实时大数据处理方法，其特征在于，所述方法包括：

监听数据源，实时监听所述数据源，当所述数据源的数据有更新，将更新数据发送到第一消息队列；

提取数据标签，通过预设规则或模型解析，从所述第一消息队列里的更新数据中提取标签，并将所述更新数据及对应的所述标签发送到第二消息队列，其中，所述标签用于标识数据关键信息；

数据分类存储，包括：

将预设时间范围内的所述第二消息队列里的数据及对应的标签存储到第一数据库；

基于所述标签对所述第二消息队列里的数据过滤，将与所述标签一致的对应数据存放到第二数据库；

将所述第二消息队列里的数据按照主题分类，筛选所述主题与预设主题一致的数据存储到第三数据库，其中，所述主题用于总结数据含义。

2.根据权利要求1所述的方法，其特征在于，所述监听数据源包括：

定时启动或关闭对所述数据源的监听。

3.根据权利要求1所述的方法，其特征在于，当用户更改生成所述标签的规则或模型时，实时生成新的标签时，并且开启定时任务，对所述第一数据库里的数据重新提取数据标签，并进行数据分类存储，更新所述第一数据库、第二数据库、第三数据库。

4.根据权利要求1所述的方法，其特征在于，所述数据源的数据可以是文本数据、音频数据、视频数据中任一种。

5.根据权利要求1所述的方法，其特征在于，所述提取数据标签和所述数据分类存储是实时流任务，在流处理框架下执行该任务。

6.根据权利要求5所述的方法，其特征在于，所述流处理框架可以选择Flink、Storm、Map Reduce、Spark中任一种。

7.根据权利要求1所述的方法，其特征在于，所述第一数据库是全量数据库，所述全量数据库用于存储在预设时间范围内的全部数据及该数据对应的所述标签；所述全量数据库对其内部存储的数据设有数据生命周期，基于所述数据生命周期定期清除超出所述数据生命周期的数据；

所述第二数据库是现行数据库，所述现行数据库用于存储基于标签过滤所述第二消息队列内后的数据，且所述现行数据库对应的上层应用可显示或查询所述现行数据库；

所述第三数据库是存档数据库，所述存档数据库用于存储与人工筛选的数据，且所述存档数据库中的数据是永久保存。

8.根据权利要求1所述的方法，其特征在于，所述数据包括数据的事件时间属性和数据的处理时间属性。

9.一种实时大数据处理装置，其特征在于，所述装置包括：

监听数据源模块，实时监听所述数据源，当所述数据源的数据有更新，将更新数据发送到第一消息队列；

提取数据模块，通过预设规则或模型解析，从所述第一消息队列里的更新数据中提取标签，并将所述更新数据及对应的所述标签发送到第二消息队列，其中，所述标签用于标识数据关键信息；

数据分类存储模块，包括：

将预设时间范围内的所述第二消息队列里的数据及对应的标签存储到第一数据库；

基于所述标签对所述第二消息队列里的数据过滤，将与所述标签一致的对应数据存放到第二数据库；

将所述第二消息队列里的数据按照主题分类，筛选所述主题与预设主题一致的数据存储到第三数据库，其中，所述主题用于总结数据含义。

10.一种电子设备，其特征在于，包括处理器和存储器，

所述存储器中存储有指令，

所述处理器，用于读取所述存储器中存储的所述指令，以执行权利要求1-8任一项所述的方法。

Images