CN109684279A - 一种数据处理方法及系统 - Google Patents

Abstract

本发明实施例提供一种数据处理方法及系统，用以解决现有技术中的在对大并发下海量日志数据进行存储时，存储资源的消耗较大的技术问题。其中，方法包括获取多个业务日志文件；其中，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息；对多个业务日志文件进行分析，建立映射文件，映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系；基于映射文件对每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，待存储文件数据集合中的每条文件数据的词项个数小于等于每个业务日志数据的词项个数。

Description

一种数据处理方法及系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种数据处理方法及系统。

背景技术

在现今的业务支撑领域，众多运营中的业务支撑系统，如客户关系管理(CustomerRelationship Management，CRM)、业务运营支撑系统(Business Operation SupportSystem，BOSS)、经营分析支撑系统(Business Analysis Support System，BASS)等系统，随着业务支撑系统在线上的持续运营，以及业务量的不断增加，业务日志数据慢慢的累积起来，这些海量的数据包含着丰富的信息，对这些信息的提取与分析是运营人员实现对该系统的高效运营与管控的重要保证。传统使用关系型数据库存储业务日志，在系统的业务量或者并发量不大的情况下可以较好的完成对数据的存储与检索；而在面对海量数据或者高并发情况时，不少的系统集成商在积极的探索海量日志数据集中化存储与高可用搜索方案。

目前，主流的日志集中化存储架构模式，通常使用日志集中存储与搜索(Elasticsearch Logstash Kibana stack，ELK)协议栈组件来搭建日志存储系统。围绕着ELK stack协议栈，常用的海量日志存储与搜索方案包括基于ELK日志存储与搜索方案、基于ELK+文件搜集Filebeat存储与搜索方案，以及引入消息队列的ELK+Filebeat日志存储与搜索方案。

上述三种目前常见的海量日志存储与搜索方案，经过分析与实践，在大并发下，存储海量日志时会体现出如下的弊端：

1、在基于ELK日志存储与搜索方案中，日志数据收集需要在服务器端，安装文件监控与传输Logstash-forwarder。然而，经过实践发现，该组件对服务器端存储资源的消耗较大，在系统高并发的情况下，会导致系统资源利用率过高，对应用服务器的存储性能造成较大的影响。

2、基于ELK+Filebeat存储与搜索方案，虽然是对服务器日志收集端高性能消耗做了较大的优化，但由于日志存储Logstash在接受这些海量数据时候，由于需要遍历每条数据，对其进行过滤与格式化，需要一定的计算与存储资源的消耗，因此会导致在高并发下大量的日志数据堆积在Logstash服务器，使得系统性能消耗较大且造成系统吞吐量不高。

3、引入消息队列的ELK+Filebeat日志存储与搜索方案，虽然克服了方案2关于Logstash端不能高效处理并分析大并发下的海量数据而导致的数据堆积的缺陷，但是，由于Logstash端需要对每条日志数据进行过滤与格式化分析，Logstash的filter插件对这些数据进行解析会消耗计算资源，虽然可以通过增加机器性能以及处理的线程数来缓解系统压力，但是随着系统并发量的增加，存储资源消耗较大的缺陷很快就显现出来。

综上可知，现有技术中大都采用增加硬件资源，或者对组件参数进行调优来实现大并发下海量日志数据的存储，均不能从根源上解决在对大并发下海量日志数据进行存储时，存储资源的消耗较大的技术问题。

发明内容

本发明实施例提供一种数据处理方法及系统，用以解决现有技术在对大并发下海量日志数据进行存储时，存储资源的消耗较大的技术问题。

第一方面，本发明实施例提供一种数据处理方法，包括：获取多个业务日志文件；其中，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息；对所述多个业务日志文件进行分析，建立映射文件，所述映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系；基于所述映射文件对所述每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，所述待存储文件数据集合中的每条文件数据的词项个数小于等于所述每个业务日志数据的词项个数。

在一种可能的实现方式中，所述对所述多个业务日志文件进行分析，建立映射文件，包括：基于所述词项及所述词项特征信息，对每个业务日志数据进行词项分割，获得索引文件与文档文件；其中，所述索引文件包括词项集合和所述词项集合中每个词项对应的索引ID子集合，所述文档文件包括所述每个词项对应的词项特征信息，所述词项特征信息包括索引自增ID，所述索引ID子集合中的任一索引ID与所述索引自增ID对应；基于所述索引文件和所述文档文件，建立映射文件。

在一种可能的实现方式中，所述基于所述映射文件对所述每个业务日志数据进行数据重组，获得待存储文件数据集合，包括：基于所述索引文件与所述文档文件之间的关联关系对所述每个业务日志数据进行重组，获得待存储文件数据集合。

在一种可能的实现方式中，所述存储待存储文件数据集合，包括：将所述待存储文件数据集合分别存储在弹性搜索集群的至少两个节点中。

在一种可能的实现方式中，在对所述待存储文件数据集合进行存储之后，所述方法还包括：接收用户终端发送的搜索指令，并获取所述搜索指令中包括的至少一个查询词项；确定所述待存储文件数据集合中与所述至少一个查询词项对应的目标文件数据；向所述用户终端发送所述目标文件数据。

在一种可能的实现方式中，所述确定所述待存储文件数据集合中与所述至少一个查询词项对应的目标文件数据，包括：获取所述搜索指令中的至少一个查询词项，建立主节点与所述用户终端之间的通信连接；判断所述主节点中是否存在与所述至少一个查询词项对应的目标文件数据；若存在，则确定所述目标文件数据；否则，从至少一个从节点上确定所述目标文件数据；其中，所述至少一个从节点为所述至少两个节点中的节点。

在一种可能的实现方式中，所述建立主节点与所述用户终端之间的通信连接，包括：判断预设时间段内所述主节点与所述用户终端之间的通信连接是否建立成功；若确定所述预设时间段内，所述主节点与所述用户终端之间的通信连接未建立成功，则按照预设规则确定所述至少一个从节点中一个从节点为主节点；将新确定的所述主节点与所述用户终端建立通信连接。

第二方面，本发明实施例提供一种数据处理系统，包括：

数据源模块，用于获取多个业务日志文件；其中，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息；

文件数据压缩模块，用于对所述多个业务日志文件进行分析，建立映射文件，所述映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系；

文件数据恢复模块，用于基于所述映射文件对所述每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，所述待存储文件数据集合中的每条文件数据的词项个数小于等于所述每个业务日志数据的词项个数。

在一种可能的实现方式中，所述文件数据压缩模块具体用于：基于所述词项及所述词项特征信息，对每个业务日志数据进行词项分割，获得索引文件与文档文件；其中，所述索引文件包括词项集合和所述词项集合中每个词项对应的索引ID子集合，所述文档文件包括所述每个词项对应的词项特征信息，所述词项特征信息包括索引自增ID，所述索引ID子集合中的任一索引ID与所述索引自增ID对应；基于所述索引文件和所述文档文件，建立映射文件。

在一种可能的实现方式中，所述文件数据恢复模块具体用于：基于所述索引文件与所述文档文件之间的关联关系对所述每个业务日志数据进行重组，获得待存储文件数据集合。

在一种可能的实现方式中，所述文件数据恢复模块具体用于：将所述待存储文件数据集合分别存储在弹性搜索集群的至少两个节点中。

在一种可能的实现方式中，所述数据处理系统还包括：弹性搜索模块，用于在对所述待存储文件数据集合进行存储之后，接收用户终端发送的搜索指令，并获取所述搜索指令中包括的至少一个查询词项；确定所述待存储文件数据集合中与所述至少一个查询词项对应的目标文件数据；向所述用户终端发送所述目标文件数据。

在一种可能的实现方式中，所述弹性搜索模块具体用于：获取所述搜索指令中的至少一个查询词项，建立主节点与所述用户终端之间的通信连接；判断所述主节点中是否存在与所述至少一个查询词项对应的目标文件数据；若存在，则确定所述目标文件数据；否则，从至少一个从节点上确定所述目标文件数据；其中，所述至少一个从节点为所述至少两个节点中的节点。

在一种可能的实现方式中，所述弹性搜索模块还用于：判断预设时间段内所述主节点与所述用户终端之间的通信连接是否建立成功；若确定所述预设时间段内，所述主节点与所述用户终端之间的通信连接未建立成功，则按照预设规则确定所述至少一个从节点中一个从节点为主节点；将新确定的所述主节点与所述用户终端建立通信连接。

第三方面，本发明实施例提供另一种数据处理系统，包括：

至少一个处理器，以及

与所述至少一个处理器通信连接的存储器、通信接口；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令，利用所述通信接口执行如第一方面所述的方法。

第四方面，本发明实施例提供一种计算机可读存储介质，包括：

所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如第一方面所述的方法。

本发明实施例的数据处理方法中，通过对获取的多个业务日志文件进行分析，建立映射文件，其中，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息，映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系，然后根据映射文件对每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，待存储文件数据集合中的每条文件数据的词项个数小于等于每个业务日志数据的词项个数，解决了对大并发下海量日志数据进行存储时，存储资源的消耗仍旧较大的技术问题，降低了存储资源的消耗。

附图说明

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

图1为本发明实施例中数据处理系统的系统架构图；

图2为本发明实施例中数据处理方法的流程示意图；

图3为本发明实施例中文件压缩与恢复的框架图；

图4为本发明实施例中日志弹性搜索模型；

图5为本发明实施例中数据处理系统的模块示意图；

图6为本发明实施例中另一种数据处理系统的结构示意图。

具体实施方式

为了使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

首先，对本发明实施例所应用的系统架构进行介绍，以便本领域技术人员理解。

请参见图1，为应用本发明实施例总体设计方案的数据处理系统的系统架构图，数据处理系统可以包括数据源、文件数据压缩、日志采集与数据缓冲、数据过滤、文件数据恢复、数据集中化存储和弹性搜索等模块。

下面自上而下简要介绍图1中各个模块的作用。

数据源模块：包括应用服务器App Server，通常用于采集业务日志文件Log File，文件中的数据以行为单位，每一行是一个完整的业务操作记录。

文件数据压缩模块，对目标日志文件按照倒排索引的思想，分析其中的词项、词频，建立词项与字段之间的映射文件file，以此达到文件压缩的目标。

日志采集与数据缓冲模块：包括文件搜集Filebeat组件、分布式发布订阅消息系统Kafka等，可以由文件收集Filebeat组件进行日志的监控与采集，将采集到的数据发送到消息队列中，实现数据的缓冲。

数据过滤模块：采集后的数据经过消息队列到达日志存储Logstash，由Logstash的过滤filter插件完成对数据的分析与过滤。

文件数据恢复模块：对Logstash处理后的数据进行数据重组，依据在文件压缩阶段建立的规则，进行数据记录的恢复。

数据集中化存储模块：将恢复后的文件数据传输到弹性搜索Elasticsearch集群，实现日志数据的集中化存储。

弹性搜索模块：包括聚合aggregation单元、模糊搜索fuzzy单元、通配符搜索wildcard单元、全字匹配term单元、前缀搜索prefix单元和范围搜索range单元等，提供了一个高可用的Elasticsearch模块，该模块可以根据业务场景实现对日志数据的定制化搜索。

下面结合附图对本发明优选的实施方式进行详细说明。

实施例一

请参见图2，本发明实施例提供一种数据处理方法，该方法可以用于如图1所示的数据处理系统中，该方法的执行过程可以描述如下：

S101：获取多个业务日志文件；其中，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息；

S102：对多个业务日志文件进行分析，建立映射文件，映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系；

S103：基于映射文件对每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，待存储文件数据集合中的每条文件数据的词项个数小于等于每个业务日志数据的词项个数。

在S101中，业务日志文件可以是数据处理系统中的数据源模块采集的数据源，每个业务日志文件可以为同一用户操作所产生，或者也可以由不同用户操作产生，每个业务日志文件可以包括多个业务日志数据。

本发明实施例中，假设，每个业务日志文件中的业务日志数据以行为单位，即每个业务日志文件中的一行数据可以为一个业务日志数据，而每个业务日志数据可以由多个词项，及每个词项对应的词项特征信息构成，可以表征一个完整的业务操作记录。

在实际应用中，词项可以为姓名、电话号码、年龄、密码、生日、家庭住址等。相应地，词项特征信息可以包括词项值、词项在业务日志文件中出现的位置、出现次数等。

举例来说，若词项为姓名，则词项特征信息可以为张三、李四、张良等，还可以包括这些人的具体姓名在业务日志文件中出现的位置，重复出现的次数等等。而由上述每个业务日志数据包括的词项和词项特征信息可以构成表征业务操作的一个完整的业务操作记录。

在S102中，在获取多个业务日志文件之后，可以对这多个业务日志文件进行分析，而由于每个业务日志文件包括多个业务日志数据，每个业务日志数据可以包括用于表征业务操作的词项及词项特征信息，因此，通过对业务日志文件的分析，可以得到但不仅限于以下几个关于业务日志数据的特点：

(1)一个业务日志数据包括的词项较多；

(2)某些词项对应的词项值所包含的字节数较多；

(3)业务日志文件中不同的业务日志数据之间存在大量的重复词项值。

为了解决在高并发下海量业务日志数据的高效存储，本发明实施例中可以结合以上对业务日志文件的分析结果，同时可以借鉴倒排索引的思想，建立映射文件，其中，该映射文件可以用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系，可以避免业务日志数据的重复存储，保证了业务日志数据可以高效传输且提高了系统分析处理业务日志数据的能力。

在一种可能的实现方式中，对多个业务日志文件进行分析，建立映射文件可以通过以下方式进行。

可以根据词项和词项特征信息，对每个业务日志数据进行词项分割，获得索引文件IndexFile和文档文件DocFile。

请参见图3，多个业务日志文件在经过文件压缩后可以得到多个索引文件和多个文档文件。以索引文件1为例，可以参见表1，索引文件1中可以包括词项集合，包括用户名、电话号码、年龄、密码、生日、地址等词项，而每个词项还对应有索引ID子集合。相应地，索引文件中的任一词项，均可以在文档文件中找到与其对应的相关列表。

表1

词项集合	索引ID子集合
		用户名	1，3，8，21
电话号码	2，6，16，29
		年龄	44，53，66，86
密码	1，13，16，214
		生日	10，31，32、92
地址	25，37，64，121
		…	…

表2

索引自增ID集合	词项值	词项重复次数	词项地址
				1	zhangsan	10000	<1><2><3>…
2	lisi	8000	<1><2><4>…
				3	mawu	5000	<1><2><5>…
4	zhangliang	4800	<1><2><6>…
				5	lihang	600	<1><2><7>…
6	liming	500	<1><2><8>…
				…	…	106	<1><2><9>…

举例来说，假设文档文件1与索引文件1对应，词项“用户名”可以在索引文件1中找到与其对应的相关列表，如表2所示，该列表中可以包括索引自增ID、词项值、词项重复次数和词项值地址等，其中，索引自增ID可以表示为递增的索引ID，词项值地址可以表示为词项值在业务日志文件中出现的行位置。索引ID子集合中的任一索引ID与索引自增ID对应，即索引文件可以通过每个词项对应的索引ID子集合中的任意一个索引ID与文档文件关联起来。

由于索引文件所占存储空间减小，使得数据处理系统对其传输与分析的效率较高，而文档文件中，针对重复出现的词项值只存储了一份及与其对应的词项出现次数、地址等，消除了源文件中的冗余数据，降低了数据处理系统传输于存储数据的压力。

然后可以根据上述得到的索引文件和文档文件，建立映射文件。在实际应用中，映射文件可以为包括索引文件和文档文件的文件，也可以是存储索引文件和文档文件之间的映射关系的文件，映射文件可以用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系。

进而可以进入S103，即可以根据映射文件对每个业务日志数据进行存储，获得并存储待存储文件数据集合；其中，待存储文件数据集合中的每条文件数据的词项个数小于等于每个业务日志数据的词项个数。

本发明实施例中，业务日志数据及映射文件可以由数据处理系统中的日志采集与数据缓冲模块中的Filebeat组件进行监控，然后将其发送在消息队列中进行数据的缓存，以到达Logstash，由Logstash的filter插件完成对数据的分析与过滤，消除了源文件中的冗余数据，降低了数据处理系统传输于存储数据的压力。

而由于业务日志数据经过logstash解析后，可能是非完整的数据记录，因此，在输入到Elasticsearch集群前，需要经过文件数据恢复模块，根据映射文件对每个业务日志数据进行数据重组，请仍参见图3。

在一种可能的实现方式中，可以根据索引文件与文档文件之间的关联关系对每个业务日志数据进行重组，获得待存储文件数据集合。

在实际应用中，业务日志数据的重组可以描述为：业务日志数据经过logstash解析后，可以输出到redis，对存储的键值对key-value设置相应的失效时间，以保证内存空间的合理释放；然后，从redis中读取的文件数据，通过索引文件与文档文件之间的关联关系，进行计算重组数据形成完整的文件日志记录，最终输出到Elasticsearch集群中的至少两个节点中进行保存。而redis作为一个缓存中间件，能实现快速的数据交互，避免大量的输入/输出端口(Input/Output，I/O)消耗。同时，通过设置相应的失效时间使得redis中无效的数据及时的得到释放，从而保证在高并发下数据处理。

基于倒排索引的建立映射文件与数据重组模型的优势，一方面压缩了文件的大小，使得在文件的传输过程中占用系统更少的带宽；另一方面压缩后的文件由于包含较少的字段，使得在Logstash中分析处理效率得到较大的提高，解决了Logstash的filter插件处理数据的性能瓶颈问题。

在一种可能的实现方式中，在对待存储文件数据集合进行存储之后，还可以包括：接收用户终端发送的搜索指令，并获取搜索指令中包括的至少一个查询词项；确定待存储文件数据集合中与至少一个查询词项对应的目标文件数据；向用户终端发送目标文件数据。

即若用户需要搜索文件数据，可以通过用户终端向数据处理系统发送搜索指令，该搜索指令中可以包括至少一个查询词项，当然，在实际应用中，搜索指令中也可以包括具体的词项值等信息。

然后数据处理系统在获取到搜索指令后，可以根据搜索指令中的至少一个查询词项，在待存储文件数据集合中确认与其对应的目标文件数据，进而向用户终端反馈该目标文件数据，实现搜索。当然，该搜索可以为可定制化的搜索，即用户可以根据实际需求进行目标文件数据的搜索。

在实际应用中，可以参见图4所示的与图1中弹性搜索模块对应的日志弹性搜索模型，可以基于搜索指令中的至少一个查询词项，在待存储文件数据集合中确认与其对应的目标文件数据，并向用户终端反馈该目标文件数据。其中，该模块至少包括以下两个部分：

(1)配置信息管理集群(ZooKeeper Cluster)：包括弹性搜索配置(ElasticsearchConfig)，其中，弹性搜索配置可以包括多个配置信息管理节点ZooKeeper node，图4中以弹性搜索配置包括配置信息管理节点1、配置信息管理节点2和配置信息管理节点3为例。配置信息管理集群是无中心化的，且基于主从master-slave模式的。其中，主master节点是通过选举产生的，当master节点出点故障，集群会立即推选出新的master节点，保障集群的高可用。配置信息管理ZooKeeper中主要保存了Elasticsearch配置，这些配置是建立Elasticsearch client搜索时必要的配置信息。通过集群化的配置，能避免节点的单点故障，实现配置的高可用。同时，利用ZooKeeper提供的用户界面，即UI界面，可以可视化的管理所有的配置信息，并且动态实现增删改查。

(2)弹性搜索应用程序编程接口(Elasticsearch Search API)：包括配置信息管理Java客户端(ZooKeeper Java Client)，与其相连的弹性搜索Java应用程序编程接口客户端(Elasticsearch Java API Client)及弹性搜索模块。首先，将Elasticsearch集群节点以一定的规则动态的配置到ZooKeeper集群中，然后在配置信息管理Java客户端Elasticsearch Java Client读取ZooKeeper配置，解析规则，从而实现该Client的高可用，避免Elasticsearch集群中单节点的故障导致搜索失败。其次，该Client提供了丰富的搜索应用程序编程接口(Application Programming Interface，API)，这些API使用HTTP+JSON的交互方式，易于阅读与理解，能保证第三方能快速使用API进行定制化的搜索。

在一种可能的实现方式中，由于本发明实施例中待存储文件数据可以存储在弹性搜索集群的至少两个节点中，其中，至少两个节点中可以包括主节点，或者也可以不包括主节点，如此可以对待存储文件数据进行备份，一来可以避免存储待存储文件数据的节点出现故障时，无法读取与搜索指令中的至少一个查询词项对应的目标文件数据的情况发生，提高了目标文件数据搜索的效率；再者，可以确保各个节点存储数据的均衡性。

在获取搜索指令中的至少一个查询词项后，可以先建立主节点与用户终端之间的通信连接，然后判断主节点中是否存在与至少一个查询词项对应的目标文件数据；若存在，即待存储文件数据存储于主节点中时，则确定目标文件数据；否则，即待存储文件数据并未存储于主节点上时，可以从至少一个从节点上确定目标文件数据；其中，至少一个从节点为至少两个节点中的节点。

在一种可能的实现方式中，在建立主节点与用户终端之间的通信连接时，可以首先判断在预设时间段内，比如30秒内，主节点与用户终端的通信连接是否建立成功，如用户终端在30秒内是否接收到数据处理系统的反馈信息，若确定预设时间段内，主节点与用户终端之间的通信连接未建立成功，则按照预设规则确定至少一个从节点中一个从节点为主节点；将新确定的主节点与用户终端建立通信连接。

其中，预设规则可以是由用户预设的关于主从节点的存储空间大小的排序列表，或者也可以由数据处理系统根据各个节点的历史存储值自动推选出新的主节点，或者也可以由数据处理系统选择与故障主节点直接连接的任一从节点作为新的主节点与用户终端进行通信连接等等，具体采用何种预设规则可以根据实际情况而定，本发明实施例不作限制。

综上所述，本发明实施例的一个或者多个技术方案，具有如下技术效果或者优点：

第一、本发明实施例的数据处理方法中，通过对获取的多个业务日志文件进行分析，建立映射文件，其中，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息，映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系，然后根据映射文件对每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，待存储文件数据集合中的每条文件数据的词项个数小于等于每个业务日志数据的词项个数，解决了对大并发下海量日志数据进行存储时，存储资源的消耗较大的技术问题，降低了存储资源的消耗。

第二、为了解决在高并发下海量业务日志数据的高效存储，本发明实施例中可以结合以上对业务日志文件的分析结果，同时可以借鉴倒排索引的思想，建立映射文件，其中，该映射文件可以用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系，可以避免业务日志数据的重复存储，保证了业务日志数据可以高效传输且提高了系统分析处理业务日志数据的能力。

第三、由于索引文件所占存储空间减小，使得数据处理系统对其传输与分析的效率较高，而文档文件中，针对重复出现的词项值只存储了一份及与其对应的词项出现次数、地址等，消除了源文件中的冗余数据，降低了数据处理系统传输于存储数据的压力。

第四、基于倒排索引的建立映射文件与数据重组模型的优势，一方面压缩了文件的大小，使得在文件的传输过程中占用系统更少的带宽；另一方面压缩后的文件由于包含较少的字段，使得在Logstash中分析处理效率得到较大的提高，解决了Logstash的filter插件处理数据的性能瓶颈问题。

第五、由于本发明实施例中待存储文件数据可以存储在弹性搜索集群的至少两个节点中，其中，至少两个节点中可以包括主节点，或者也可以不包括主节点，如此可以对待存储文件数据进行备份，一来可以避免存储待存储文件数据的节点出现故障时，无法读取与搜索指令中的至少一个查询词项对应的目标文件数据的情况发生，提高了目标文件数据搜索的效率；再者，可以确保各个节点存储数据的均衡性。

实施例二

请参见图5，基于同一发明构思，本发明实施例提供一种数据处理系统，包括数据源模块51、文件数据压缩模块52和文件数据恢复模块53。

其中，数据源模块51可以用于获取多个业务日志文件，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息；

文件数据压缩模块52，用于对所述多个业务日志文件进行分析，建立映射文件，所述映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系；

文件数据恢复模块53，用于基于所述映射文件对所述每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，所述待存储文件数据集合中的每条文件数据的词项个数小于等于所述每个业务日志数据的词项个数。

在一种可能的实现方式中，所述文件数据压缩模块52具体用于：基于所述词项及所述词项特征信息，对每个业务日志数据进行词项分割，获得索引文件与文档文件；其中，所述索引文件包括词项集合和所述词项集合中每个词项对应的索引ID子集合，所述文档文件包括所述每个词项对应的词项特征信息，所述词项特征信息包括索引自增ID，所述索引ID子集合中的任一索引ID与所述索引自增ID对应；基于所述索引文件和所述文档文件，建立映射文件。

在一种可能的实现方式中，所述文件数据恢复模块53具体用于：基于所述索引文件与所述文档文件之间的关联关系对所述每个业务日志数据进行重组，获得待存储文件数据集合。

在一种可能的实现方式中，所述文件数据恢复模块53具体用于：将所述待存储文件数据集合分别存储在弹性搜索集群的至少两个节点中。

在一种可能的实现方式中，所述数据处理系统还包括：弹性搜索模块，用于在对所述待存储文件数据集合进行存储之后，接收用户终端发送的搜索指令，并获取所述搜索指令中包括的至少一个查询词项；确定所述待存储文件数据集合中与所述至少一个查询词项对应的目标文件数据；向所述用户终端发送所述目标文件数据。

在一种可能的实现方式中，所述弹性搜索模块具体用于：获取所述搜索指令中的至少一个查询词项，建立主节点与所述用户终端之间的通信连接；判断所述主节点中是否存在与所述至少一个查询词项对应的目标文件数据；若存在，则确定所述目标文件数据；否则，从至少一个从节点上确定所述目标文件数据；其中，所述至少一个从节点为所述至少两个节点中的节点。

在一种可能的实现方式中，所述弹性搜索模块还用于：判断预设时间段内所述主节点与所述用户终端之间的通信连接是否建立成功；若确定所述预设时间段内，所述主节点与所述用户终端之间的通信连接未建立成功，则按照预设规则确定所述至少一个从节点中一个从节点为主节点；将新确定的所述主节点与所述用户终端建立通信连接。

实施例三

请参见图6，基于同一发明构思，本发明实施例中提供一种数据处理系统，包括至少一个处理器61，以及与所述至少一个处理器61通信连接的存储器62和通信接口63，图6中以示出一个处理器61为例。

其中，所述存储器62存储有可被所述至少一个处理器61执行的指令，所述至少一个处理器61通过执行所述存储器62存储的指令，利用所述通信接口63执行如实施例一中所述的方法。

实施例四

基于同一发明构思，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如实施例一所述的方法。

在具体的实施过程中，计算机可读存储介质包括：通用串行总线闪存盘(Universal Serial Bus flash drive，USB)、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的存储介质。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元/模块可以是或者也可以不是物理上分开的，作为单元/模块显示的部件可以是或者也可以不是物理单元/模块，即可以位于一个地方，或者也可以分布到多个网络单元/模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

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

获取多个业务日志文件；其中，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息；

对所述多个业务日志文件进行分析，建立映射文件，所述映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系；

基于所述映射文件对所述每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，所述待存储文件数据集合中的每条文件数据的词项个数小于等于所述每个业务日志数据的词项个数。

2.如权利要求1所述的方法，其特征在于，所述对所述多个业务日志文件进行分析，建立映射文件，包括：

基于所述词项及所述词项特征信息，对每个业务日志数据进行词项分割，获得索引文件与文档文件；其中，所述索引文件包括词项集合和所述词项集合中每个词项对应的索引ID子集合，所述文档文件包括所述每个词项对应的词项特征信息，所述词项特征信息包括索引自增ID，所述索引ID子集合中的任一索引ID与所述索引自增ID对应；

基于所述索引文件和所述文档文件，建立映射文件。

3.如权利要求1或2所述的方法，其特征在于，所述基于所述映射文件对所述每个业务日志数据进行数据重组，获得待存储文件数据集合，包括：

基于所述索引文件与所述文档文件之间的关联关系对所述每个业务日志数据进行重组，获得待存储文件数据集合。

4.如权利要求3所述的方法，其特征在于，所述存储待存储文件数据集合，包括：

将所述待存储文件数据集合分别存储在弹性搜索集群的至少两个节点中。

5.如权利要求4所述的方法，其特征在于，在对所述待存储文件数据集合进行存储之后，所述方法还包括：

接收用户终端发送的搜索指令，并获取所述搜索指令中包括的至少一个查询词项；

确定所述待存储文件数据集合中与所述至少一个查询词项对应的目标文件数据；

向所述用户终端发送所述目标文件数据。

6.如权利要求5所述的方法，其特征在于，所述确定所述待存储文件数据集合中与所述至少一个查询词项对应的目标文件数据，包括：

获取所述搜索指令中的至少一个查询词项，建立主节点与所述用户终端之间的通信连接；

判断所述主节点中是否存在与所述至少一个查询词项对应的目标文件数据；

若存在，则确定所述目标文件数据；否则，从至少一个从节点上确定所述目标文件数据；其中，所述至少一个从节点为所述至少两个节点中的节点。

7.如权利要求6所述的方法，其特征在于，所述建立主节点与所述用户终端之间的通信连接，包括：

判断预设时间段内所述主节点与所述用户终端之间的通信连接是否建立成功；

若确定所述预设时间段内，所述主节点与所述用户终端之间的通信连接未建立成功，则按照预设规则确定所述至少一个从节点中一个从节点为主节点；

将新确定的所述主节点与所述用户终端建立通信连接。

8.一种数据处理系统，其特征在于，所述系统包括：

数据源模块，用于获取多个业务日志文件；其中，每个业务日志文件包括多个业务日志数据，每个业务日志数据包括用于表征业务操作的词项及词项特征信息；

文件数据压缩模块，用于对所述多个业务日志文件进行分析，建立映射文件，所述映射文件用于指示每个业务日志文件所包括的多个业务日志数据中每个业务日志数据的词项与词项特征信息之间的映射关系；

文件数据恢复模块，用于基于所述映射文件对所述每个业务日志数据进行数据重组，获得并存储待存储文件数据集合；其中，所述待存储文件数据集合中的每条文件数据的词项个数小于等于所述每个业务日志数据的词项个数。

9.一种数据处理系统，其特征在于，所述系统包括：

至少一个处理器，以及

与所述至少一个处理器通信连接的存储器、通信接口；

其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令，利用所述通信接口执行如权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于：

所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如权利要求1-7中任一项所述的方法。