CN112667411B - 一种数据处理的方法、装置、电子设备和计算机存储介质 - Google Patents

Abstract

本申请实施例公开了一种数据处理的方法、装置、电子设备和计算机存储介质，该方法包括：将MapReduce任务中的源数据写入第一消息队列中；所述源数据包括多个文件；从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。如此，基于第一消息队列，使得每个源数据的文件可以随机分配至不同的Map任务进行处理，且每个文件在被处理之前，不需要确定所属的分片，即，实现了对于所述源数据的动态分片，进一步地，每个Map任务每次只处理一个文件，进而缩小了各个Map任务之间处理数据的时间的差距，提高了整个MapReduce任务的执行效率。

Description

一种数据处理的方法、装置、电子设备和计算机存储介质

技术领域

本申请涉及大数据领域，尤其涉及一种数据处理方法、装置、电子设备和计算机存储介质。

背景技术

MapReduce是一种编程模型，用于大规模数据集的并行运算，MapReduce 编程模型的出现使得不会分布式编程的人员，可以将自己的程序运行在大规模分布式***上，其中，InputFormat模块是MapReduce编程模型中的一个重要的模块，该模块主要负责对MapReduce任务中的源数据进行遍历、分片以及利用RecordReader对分片后的数据进行解析，供Map任务进行处理，其中，通过 InputFormat模块，对MapReduce任务中经过遍历后的源数据进行分片的过程，是影响MapReduce任务执行效率的一个重要因素。

现有技术中，对于MapReduce任务中经过遍历后的源数据进行分片的方案主要有两种，第一种方案是通过UniformSizeInputFormat模块，对遍历后的数据进行均匀分片，同时，在Map任务处理分片数据之前，提前给每个Map任务指定需要处理的对应的分片数据，即，MapReduce任务中的所有Map任务都处理相同数据量的文件，然而，MapReduce任务中的某些Map任务，由于网络、服务器等原因，比其他Map任务的处理速度慢，进而影响整个MapReduce任务的执行效率。

第二种方案是通过DynamicInputFormat模块，首先，将遍历后的数据分成若干个Chunk，每个Chunk中包含相同数据量的文件，当Map任务开始处理数据时，每个Map任务随机获取一个Chunk进行处理，处理完成后再随机获取下一个Chunk进行处理，然而，由于每个Chunk中包含多个文件，且Map以单个文件为基本处理单位，因而，当Chunk中包含的文件数量不合理时，处理速度慢的Map任务与处理速度快的Map任务，处理数据的时间差距较大，进而影响整个MapReduce任务的执行效率。

发明内容

本申请实施例期望提供一种数据处理的方法、装置、电子设备和计算机存储介质。

本申请实施例提供了一种数据处理的方法，所述方法包括：

将MapReduce任务中的源数据写入第一消息队列中；所述源数据包括多个文件；

从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。

可选地，所述将MapReduce任务中的源数据写入第一消息队列中，包括：

通过多线程的方式遍历所述MapReduce任务中的源数据，并取出遍历后的数据，当取出的数据满足第一预设条件时，将所述取出的数据写入所述第一消息队列中。

可选地，所述通过多线程的方式遍历所述MapReduce任务中的源数据，并取出遍历后的数据，包括：

确定处理所述源数据的线程个数，将所述源数据写入非阻塞队列，利用每个线程，至少一次从所述非阻塞队列中取出数据。

可选地，所述第一预设条件，包括：所述取出的数据为源数据的文件。

可选地，所述第一预设条件，还包括：所述取出的数据的文件名正则匹配成功。

可选地，所述MapReduce任务中的Map任务的数量为指定数量。

可选地，所述第一消息队列为Redis消息队列。

本申请实施例还提出了一种数据处理的装置，所述装置包括：第一处理模块和第二处理模块，其中：

第一处理模块：用于将MapReduce任务中的源数据写入第一消息队列中；所述源数据包括多个文件；

第二处理模块：用于从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。

可选地，所述第一处理模块，用于通过多线程的方式遍历所述MapReduce 任务中的源数据，并取出遍历后的数据，当取出的数据满足第一预设条件时，将所述取出的数据写入所述第一消息队列中。

可选地，所述第一处理模块，用于确定处理所述源数据的线程个数，将所述源数据写入非阻塞队列，利用每个线程，至少一次从所述非阻塞队列中取出数据。

可选地，所述第一预设条件，包括：所述取出的数据为源数据的文件。

可选地，所述第一预设条件，还包括：所述取出的数据的文件名正则匹配成功。

可选地，所述MapReduce任务中的Map任务的数量为指定数量。

可选地，所述第一消息队列为Redis消息队列。

本申请实施例还提出了一种电子设备，包括处理器和用于存储能够在处理器上运行的计算机程序的存储器；其中，

所述处理器用于运行所述计算机程序时，执行上述任意一种数据处理的方法。

本申请实施例还提出了一种计算机存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任意一种数据处理的方法。

本申请实施例提出的数据处理的方法、装置、电子设备和计算机存储介质中，将MapReduce任务中的源数据写入第一消息队列中；所述源数据包括多个文件；从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。如此，基于第一消息队列，使得每个源数据的文件可以随机分配至不同的Map任务进行处理，且每个文件在被处理之前，不需要确定所属的分片，即，实现了对于所述源数据的动态分片，进一步地，每个Map任务每次只处理一个文件，进而缩小了各个Map任务之间处理数据的时间的差距，提高了整个MapReduce任务的执行效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本申请的实施例，并与说明书一起用于说明本申请的技术方案。

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

图2为本申请实施例提供的一种数据处理的***原理图；

图3为本申请实施例提供的线程执行流程图；

图4为本申请实施例提供的一种数据处理的装置的结构示意图；

图5为本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本申请，并不用于限定本申请。另外，以下所提供的实施例是用于实施本申请的部分实施例，而非提供实施本申请的全部实施例，在不冲突的情况下，本申请实施例记载的技术方案可以任意组合的方式实施。

需要说明的是，在本申请实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的方法或者装置不仅包括所明确记载的要素，而且还包括没有明确列出的其他要素，或者是还包括为实施方法或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括该要素的方法或者装置中还存在另外的相关要素(例如方法中的步骤或者装置中的单元，例如的单元可以是部分电路、部分处理器、部分程序或软件等等)。

例如，本申请实施例提供的数据处理的方法包含了一系列的步骤，但是本申请实施例提供的数据处理的方法不限于所记载的步骤，同样地，本申请实施例提供的数据处理的装置包括了一系列模块，但是本申请实施例提供的装置不限于包括所明确记载的模块，还可以包括为获取相关信息、或基于信息进行处理时所需要设置的模块。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

本申请实施例可以应用于终端和服务器组成的计算机***中，并可以与众多其它通用或专用计算***环境或配置一起操作。这里，终端可以是瘦客户机、厚客户机、手持或膝上设备、基于微处理器的***、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机***，等等，服务器可以是服务器计算机***小型计算机***﹑大型计算机***和包括上述任何***的分布式云计算技术环境，等等。

终端、服务器等电子设备可以在由计算机***执行的计算机***可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机***/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算***存储介质上。

在本申请的一些实施例中，提出了一种数据处理的方法，实现了对于所述源数据的动态分片，且每个Map任务每次只处理一个文件，缩小了各个Map 任务之间处理数据的时间的差距，提高了整个MapReduce任务的执行效率。

实施例一

图1是本申请实施例中的一种数据处理的方法的流程示意图，如图1所示，所述方法包括如下步骤：

S101：将MapReduce任务中的源数据写入第一消息队列中；所述源数据包括多个文件。

对于本步骤的实现方式，示例性地，可以通过多线程的方式遍历MaReduce 任务中的源数据，并取出遍历后的数据，当取出的数据满足第一预设条件时，将取出的数据写入第一消息队列中，当取出的数据不满足第一预设条件时，不写入第一消息队列中。

本申请实施例中，MapReduce任务中的源数据，可以是包含单个目录的数据，其目录下可以包含多个文件，还可以是包含多层嵌套目录的数据，其每一级目录下可以包含文件和/或下一级目录。

在相关技术中，采用单线程的方式对MapReduce任务中的源数据进行遍历，当MapReduce任务中的源数据的文件数较多，或者目录嵌套复杂度较高时，采用单线程的方式遍历源数据的效率较低，而在本申请实施例中，通过多线程的方式对MapReduce任务中的源数据进行遍历，并获取遍历后的源数据，如此，通过并发处理的方式，能够更快的遍历具有高数据量、多层嵌套目录特点的 MapReduce任务的源数据，提高了对于MapReduce任务的执行效率。

可选地，可以确定处理MapReduce任务的源数据的线程个数，将源数据写入非阻塞队列，利用每个线程，至少一次从非阻塞队列中取出数据。

这里，非阻塞队列为用于实现生产者能够往其队列中添加数据，或者消费者能够从其队列中取出数据的队列，其中，生产者即为往队列里添加数据的线程，消费者即为从队列取出数据的线程，同时，无论生产者往队列中添加数据，还是消费者从队列中取出数据，非阻塞队列的执行并不会被阻塞，即，非阻塞队列用于实现多线程能够并发处理其队列中的数据；线程个数可以是根据实际需求设定的数量，还可以是根据客户端服务器上的处理器核心数确定的数量，进一步地，可以根据确定的线程个数创建线程池，用于实现对于多线程的协调和调度。

可以看出，基于线程池以及非阻塞队列，可以合理协调多线程并发处理非阻塞队列中的数据，提高了对于MapReduce任务的执行效率。

可选地，第一预设条件包括：取出的遍历后的数据为源数据中的文件。

可以看出，当取出的遍历后的数据为源数据中的文件时，可以满足后续数据处理的基本要求。

可选地，第一预设条件还包括：取出的遍历后的数据的文件名正则匹配成功。

这里，文件名正则匹配即以文件名为预设条件，通过正则匹配的方式选出与预设文件名一致的数据，示例性地，可以通过正则表达式实现对于文件名的正则匹配，首先，可以预设期望得到的数据的文件名，然后，利用正则表达式将预设的文件名与取出的遍历后的数据的文件名进行对比，当预设的文件名与取出的遍历后的数据的文件名一致时，即，取出的遍历后的数据的文件名正则匹配成功。

可以看出，通过文件名正则匹配可以对遍历后的数据进行筛选，进而可以获取期望得到的数据，且通过过滤掉无效数据，进一步提高了任务的执行效率。

在一个具体的示例中，通过InputFormat模块获取客户端服务器上的处理器的核心数，这里，处理器为中央处理器(Central Processing Unit，CPU)，根据CPU的核心数确定处理MapReduce任务中的源数据的线程个数，根据确定的线程个数创建线程池，这里，线程池为FixedThreadPool，其中，线程池用于实现对于多线程的协调和调度，同时，创建一个非阻塞队列，这里，非阻塞队列为 ConcurrentLinkedQueue，以及创建一个信号量(Semaphore)，其中，信号量的个数与线程池中的线程个数相等，且信号量用于表征非阻塞队列中的数据状态；解析MapReduce任务中的源数据，确定源数据为包含单个目录的数据，此时，将MapReduce任务中的源数据写入非阻塞队列中，同时，启动线程池中的所有线程，并发对非阻塞队列中的数据进行处理，其中，利用每个线程，至少一次从非阻塞队列中取出数据，同时，当取出的数据为文件，且取出的数据的文件名正则匹配成功时，将取出的数据写入第一消息队列中。

S102：从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce 任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。

可选地，第一消息队列可以是具有高并发特点的消息队列，示例性地，第一消息队列可以是Redis消息队列。

可以看出，利用第一消息队列高并发的特点，所有Map任务可以同时处理第一消息队列中的数据，进一步提高了MapReduce任务的执行效率。

可选地，MaReduce任务中的Map任务的数量可以是指定的数量，示例性地，用户可以通过MaReduce模型中的mapreduce.job.maps参数设定期望的Map 任务数。

在相关技术中，UniformSizeInputFormat模块确定分片数，即Map任务数的方式，是预先确定一个分片数，同时需要保证在该分片数的前提下，每个分片处理同样数据量的文件，但由于实际每个分片文件的大小不一，在将每个分片大小调整一致的过程中，需要对分片的数量进行调整，导致最终确定的分片数，即Map任务数和预期的数量差距较大，DynamicInputFormat模块确定分片数的方式是Min(用户预期数，生成的Chunk数)，由于生成Chunk的逻辑比较复杂，最终预估的数量不准确，因此最终确定的Map任务的数量同样与预期的Map任务数差距较大，而在本申请实施例中，可以由用户直接指定Map任务的数量，且在执行MapReduce任务的过程中保证Map任务的数量保持不变，如此，最终确定的Map任务数与用户预期的Map数保持一致，实现了集群资源的合理利用，同时，基于准确的Map任务数，保证用户能够更有效的对 MapReduce任务进行调优。

在一个实际的应用场景中，参见图2，本申请实施例提供的一种数据处理的***原理图，InputFormat模块以生产者的身份，通过多线程的方式对 MapReduce任务中的源数据遍历，并取出遍历后的数据，当取出的数据是文件，且取出的数据文件名正则匹配成功时，将取出的数据写入Redis消息队列中，同时，通过MaReduce模型中的mapreduce.job.maps参数设定期望的Map任务数，在MapReduce任务运行的过程中，所有Map任务都以消费者的身份，并发处理从Redis消息队列中取出的数据，且每个Map任务每次处理一个文件，当Redis消息队列中的所有数据都被消耗完时，MapReduce任务执行完成。

可以看出，基于Redis消息队列，使得每个源数据的文件可以随机分配至不同的Map任务进行处理，且每个文件在被处理之前，不需要确定所属的分片，即，实现了对于所述源数据的动态分片，进一步地，每个Map任务每次只处理一个文件，缩小了各个Map任务之间处理数据的时间的差距，提高了整个 MapReduce任务的执行效率。

在实际应用中，步骤S101至步骤S102均可以基于电子设备中的处理器等实现，上述处理器可以为特定用途集成电路(Application Specific Integrated Circuit，ASIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(Digital SignalProcessing Device，DSPD)、可编程逻辑装置 (Programmable Logic Device，PLD)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、中央处理器(Central ProcessingUnit，CPU)、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的电子设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

本申请实施例提供了一种数据处理的方法，将MapReduce任务中的源数据写入第一消息队列中；所述源数据包括多个文件；从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。如此，基于第一消息队列，使得每个源数据的文件可以随机分配至不同的 Map任务进行处理，且每个文件在被处理之前，不需要确定所属的分片，即，实现了对于所述源数据的动态分片，进一步地，每个Map任务每次只处理一个文件，缩小了各个Map任务之间处理数据的时间的差距，提高了整个MapReduce 任务的执行效率。

实施例二

为了能够更加体现本申请的目的，在本申请实施例一的基础上，进行进一步的举例说明。

本申请实施例二提供了一种通过多线程的方式对MapReduce任务中的源数据进行遍历，同时，将遍历后的、符合第一预设条件的数据写入第一消息队列的具体实现方式，这里，第一消息队列为Redis消息队列。

首先，根据InputFormat模块获取的客户端服务器上的CPU的核心数，确定线程的个数为20，并创建包含有20个线程的线程池，同时，创建一个非阻塞队列，这里，非阻塞队列为ConcurrentLinkedQueue，以及创建一个信号量，其中，信号量的个数与线程池中的线程个数相等，在将包含有多层嵌套目录的 MapReduce任务中的源数据写入非阻塞队列之后，启动线程中的20个线程，并发处理非阻塞队列中的数据。

参见图3，为本申请实施例提供的线程执行流程图，其中，每个线程首先执行Semaphore.acquire操作，即获取一个信号量，然后，执行非阻塞队列ConcurrentLinkedQueue的pop操作，即，从非阻塞队列中取出一个数据；判断非阻塞队列是否为空，当非阻塞队列为空时，即，非阻塞队列中没有数据时，执行Semaphore.realse操作，即，将该信号量标记为realse状态，这里，realse 状态表示数据处理完毕，同时，判断其他信号量的状态，当所有信号量的状态都为realse状态时，则结束对于非阻塞队列中的数据的处理，该线程退出；当还有不处于realse状态的信号量时，则重新开始执行Semaphore.acquire操作；当非阻塞队列不为空时，判断取出的数据是文件还是目录，当确定取出的数据是文件时，对取到的文件进行文件名正则匹配，此时，判断文件名正则匹配是否成功，当匹配成功时，包装文件信息为一个JavaBean对象FilePair，然后通过Gson方式序列化后，写入Redis消息队列中，同时，重新执行非阻塞队列的 pop操作，当匹配失败时，丢弃该文件，同时，重新执行非阻塞队列的pop操作；当确定取出的数据是目录时，对取到的目录执行list操作，并获取list操作的结果；判断list操作的结果是否为目录，当list操作的结果是目录时，将该目录写入非阻塞队列中，然后重新执行非阻塞队列的pop操作，当list操作的结果是文件时，对读取到的文件进行文件名正则匹配，判断文件名正则匹配是否成功，当匹配失败时，丢弃该文件，并重新执行非阻塞队列的pop操作，当匹配成功时，将该文件写入Redis消息队列中，并重新执行非阻塞队列的pop操作。

当所有线程都退出时，即实现了通过多线程的方式，对MapReduce任务中的源数据进行遍历，以及将遍历后的、符合预设条件的数据写入Redis消息队列的过程。

可以看出，通过多线程的方式对MapReduce任务中的源数据进行遍历，并获取遍历后的源数据，如此，通过并发处理的方式，能够更快的遍历具有高数据量、多层嵌套目录特点的MapReduce任务的源数据，提高了对于MapReduce 任务的处理效率。

实施例三

为了能够更加体现本申请的目的，在本申请实施例一和二的基础上，进行进一步的举例说明。

本申请实施例三提供了一种利用第一消息队列实现动态分片，同时，分片粒度精确到文件级别的方法具体实现方式，这里，第一消息队列为Redis消息队列。

在一个具体的应用场景中，通过实施例二的方法，首先，通过InputFormat 模块获取包含遍历后的、符合预设条件的数据的Redis消息队列，然后，通过 MapReduce模型中的mapreduce.job.maps参数设定期望的Map任务数，即分片数，然后根据确定的分片数对Redis消息队列中的数据进行分片，其中，每一个分片对应一个分片对象，本应用场景中，分片对象即为RedisSplit对象，在分片的过程中，首先，通过getLength()方法确定每个分片的大小，本应用场景中，规定每个分片的大小一致，通过总文件数/分片数的方式确定每个分片的具体数值，然后，通过getLocations()方法和getLocationInfo()方法分别返回每个分片存储的节点名以及分片在每个节点的存储方式，本应用场景中，为了实现动态分片，需要忽略数据本地化因素，所以两个方法均返回空值。

进一步地，需要初始化所有RedisSplit对象，即，将Redis消息队列的相关配置信息初始化到所有RedisSplit对象中，其中，Redis消息队列的相关配置信息包括：RedisHost(Redis机器IP)、RedisPort(Redis端口号)、RedisDatabase (Redis数据库)、RedisPassword(Redis数据库密码)、RedisQueue(Redis 消息队列名)以及RedisTimeout(Redis连接超时时间)，当初始化完所有 RedisSplit对象之后，将生成的包含有所有RedisSplit对象的列表返回至 MapReduce框架，即，分片过程结束。

进一步地，需要将Redis消息队列中的每个分片解析成键(Key)、值(Value) 对，供Map任务进行处理，本应用场景中，通过RedisRecordReader实现对于 Redis消息队列中每个分片的解析，其中，RedisRecordReader继承父类 RecordReader，即，与RecordReader的功能一致，在解析的过程中，具体地，首先，在initialize()方法中，根据RedisSplit对象中带有的Redis消息列的相关配置信息，初始化一个Jedis对象，其中，Jedis对象能够操作Redis消息队列，即通过initialize()方法能够对Redis消息队列进行操作，其次，通过nextKeyValue() 方法，从Redis消息队列中，通过lpop操作的方式，非阻塞式地取出消息队列尾部的最后一个队列元素，然后，分别通过getCurrentKey()方法和getCurrentValue()方法，将通过nextKeyValue()方法取出的队列元素分别解析为 Key值以及Value值，具体实现方法是，将队列元素通过Gson方式反序列化后，得到一个JavaBean对象FilePair，从该JavaBean对象中，即可得到Key值和 Value值，进而可以获取Key、Value对供Map任务进行处理，进一步地，在 RedisRecordReader解析的过程中，还可以通过getProgress()方法确定数据处理的百分比，其中数据处理百分比可以通过式(1)确定：

其中，numRecordsProcessedByThisMap表示已处理的Key、Value对数，且 Reids消息队列的剩余容量可以通过llen方法获得。

当Redis消息队列中的所有数据都被取出时，向RedisRecordReader返回false值，即表明Redis消息队列中的所有数据已经被Map任务处理完成。

可以看出，基于Redis消息队列，使得每个源数据的文件可以随机分配至不同的Map任务进行处理，且每个文件在被处理之前，不需要确定所属的分片，即，实现了对于所述源数据的动态分片，进一步地，每个Map任务每次只处理一个文件，缩小了各个Map任务之间处理数据的时间的差距，提高了整个 MapReduce任务的执行效率。

实施例四

针对本申请实施例一的一种数据处理的方法，本申请实施例四还提供了一种数据处理的装置。

图4为本申请实施例提供的一种行为识别的装置的结构示意图，如图4所述，该装置包括：第一处理模块400和第二处理模块401，其中：

第一处理模块400：用于将MapReduce任务中的源数据写入第一消息队列中；所述源数据包括多个文件；

第二处理模块401：用于从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。

在一实施方式中，所述第一处理模块400用于通过多线程的方式遍历所述MapReduce任务中的源数据，并取出遍历后的数据，当取出的数据满足第一预设条件时，将所述取出的数据写入所述第一消息队列中。

在一实施方式中，所述第一处理模块400用于确定处理所述源数据的线程个数，将所述源数据写入非阻塞队列，利用每个线程，至少一次从所述非阻塞队列中取出数据。

在一实施方式中，所述第一预设条件，包括：所述取出的数据为源数据的文件。

在一实施方式中，所述第一预设条件，还包括：所述取出的数据的文件名正则匹配成功。

在一实施方式中，所述MapReduce任务中的Map任务的数量为指定数量。

在一实施方式中，所述第一消息队列为Redis消息队列。

在实际应用中，所述第一处理模块400、第二处理模块401均可由位于电子设备中的处理器实现，该处理器可以为ASIC、DSP、DSPD、PLD、FPGA、 CPU、控制器、微控制器、微处理器中的至少一种。

另外，在本实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

具体来讲，本实施例中的一种数据处理的方法对应的计算机程序指令可以被存储在光盘，硬盘，U盘等存储介质上，当存储介质中的与一种行为识别的方法对应的计算机程序指令被一电子设备读取或被执行时，实现前述实施例的任意一种数据处理的方法。

基于前述实施例相同的技术构思，参见图5，其示出了本申请实施例提供的一种电子设备50，可以包括：存储器51和处理器52；其中，

所述存储器51，用于存储计算机程序和数据；

所述处理器52，用于执行所述存储器中存储的计算机程序，以实现前述实施例的任意一种数据处理的方法。

在实际应用中，上述存储器51可以是易失性存储器(volatile memory)，例如RAM；或者非易失性存储器(non-volatile memory)，例如ROM，快闪存储器(flash memory)，硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive， SSD)；或者上述种类的存储器的组合，并向处理器52提供指令和数据。

上述处理器52可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

在一些实施例中，本申请实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。

上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考，为了简洁，本文不再赘述。

本申请所提供的各方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的各产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的各方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

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

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本申请的保护之内。

Claims (7)

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

确定处理MapReduce任务中的源数据的线程个数，将所述源数据写入非阻塞队列，利用每个线程，至少一次从所述非阻塞队列中取出数据，当取出的数据满足第一预设条件时，将所述取出的数据写入第一消息队列中；所述源数据包括多个文件；所述第一消息队列为Redis消息队列；

从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。

2.根据权利要求1所述的方法，其特征在于，所述第一预设条件，包括：

所述取出的数据为源数据的文件。

3.根据权利要求2所述的方法，其特征在于，所述第一预设条件，还包括：

所述取出的数据的文件名正则匹配成功。

4.根据权利要求1所述的方法，其特征在于，所述MapReduce任务中的Map任务的数量为指定数量。

5.一种数据处理的装置，其特征在于，所述装置包括：第一处理模块和第二处理模块，其中：

第一处理模块：用于确定处理MapReduce任务中的源数据的线程个数，将所述源数据写入非阻塞队列，利用每个线程，至少一次从所述非阻塞队列中取出数据，当取出的数据满足第一预设条件时，将所述取出的数据写入第一消息队列中；所述源数据包括多个文件；所述第一消息队列为Redis消息队列；

第二处理模块：用于从所述第一消息队列中取出所述源数据的文件，利用所述MapReduce任务中的每个Map任务，至少一次对取出的文件进行处理；每个Map任务每次处理的文件为所述源数据的一个文件。

6.一种电子设备，其特征在于，包括处理器和用于存储能够在处理器上运行的计算机程序的存储器；其中，

所述处理器用于运行所述计算机程序时，执行权利要求1至4任一项所述的方法。

7.一种计算机存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至4任一项所述的方法。

Images