CN111538789B - 数据同步方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明实施例公开了一种数据同步方法、装置、电子设备及存储介质，所述方法包括：从待进行同步的Hive表中提取Hive表数据；将所述Hive表数据映射到分布式队列中；从所述分布式队列中读取数据至目标数据库以完成数据同步。本发明实施例由于将Hive表数据映射到分布式队列中，因此可以从分布式队列中读取Hive表数据至目标数据库以完成数据同步，因此可见，本发明实施例设计的将Hive表数据映射到分布式队列的处理方法，可以较好的应对数据量的波动，分布式队列可以较好的应对同步数据量较大的情形，有效优化数据同步的效率。

Description

数据同步方法、装置、电子设备及存储介质

技术领域

本发明涉及计算机技术领域，具体涉及一种数据同步方法、装置、电子设备及存储介质。

背景技术

目前主流的大数据仓库都是构建在Hive的基础之上。通过使用Hive可以有效地处理数以亿计的数据，在使用Hive时，Hive的处理结果的同步效率在某些场景下会影响用户的体验和系统的可用性，例如对于某一结算系统来说，统一结算出账流程结束后用户希望立即可以查询出账结果，在这种情况下如果数据同步的效率太低的话会严重影响用户体验、甚至使用户下一阶段的工作无法正常进行。

目前常用的Hive结果数据同步方法主要是基于Sqoop框架的数据同步方法，Sqoop框架是一种基于Hadoop的分布式数据同步框架，它可以实现关系型数据库到Hive的数据同步。一般情况下，Sqoop的每一个同步任务都只处理Hive中某一张表的数据，这样需要同步多少张Hive结果表就会产生多少个Sqoop同步任务。例如，如果需要同步的表很多有数百张的时候，Sqoop只能一个个启动MapReduce任务执行非常耗时，即便使用多线程来启动Sqoop同步任务，也会产生大量Sqoop数据同步装置进程消耗大量的系统资源。

发明内容

针对现有技术中存在的问题，本发明实施例提出一种数据同步方法、装置、电子设备及存储介质。

第一方面，本发明实施例提供了一种数据同步方法，包括：

从待进行同步的Hive表中提取Hive表数据；

将所述Hive表数据映射到分布式队列中；

从所述分布式队列中读取数据至目标数据库以完成数据同步。

进一步地，将所述Hive表数据映射到分布式队列中，具体包括：

将每个Hive表的表数据映射为Redis的多个队列；

将与同一Hive表对应的多个队列分散存储至Redis的不同节点上。

进一步地，将每个Hive表的表数据映射为Redis的多个队列，具体包括：

将每个Hive表数据按照预设队列大小映射为Redis的多个队列；其中，所述预设队列大小根据第一关系模型确定，所述第一关系模型为：

Q_size＝[NODE_size/THREAD_num]

其中，Q_size是预设队列大小，NODE_size是Redis节点的最大存储容量，THREAD_num是Redis节点能接受的最大并发线程数。

进一步地，将与同一Hive表对应的多个队列分散存储至Redis的不同节点上，具体包括：

确定Redis各队列的键值；

根据所述键值按照第二关系模型将与同一Hive表对应的多个队列分散存储至Redis的不同节点上；

其中，所述第二关系模型为：Loc_key＝(CRC16(Sub(key))+(16384/n*(ORDER_ID-1)))％16384；

其中，Loc_key为存储槽号，Sub(key)表示取队列Key的表名和分区名部分；CRC16(Sub(key)表示取队列Key的表名和分区名部分用CRC16算法编码成一个整数，16384为Redis中槽的总数，n为Redis节点的个数，16384/n得到Redis中每个节点维护的槽的个数，％为求模运算。

进一步地，所述确定Redis各队列的键值，具体包括：

根据第三关系模型确定Redis各队列的键值；其中，所述第三关系模型为：Key＝Table_Name+[PARTITION_NAME]+ORDER_ID；

其中，Key为队列的键值，Table_Name为Hive表名称，PARTITION_NAME为Hive表的分区名称，ORDER_ID为队列编号。

进一步地，将所述Hive表数据映射到分布式队列中，具体包括：

预先建立Hive表和Redis队列的对应关系，并将所述对应关系作为表队列元数据信息进行缓存；

相应地，根据所述表队列元数据信息，将所述Hive表数据映射到分布式队列中；

其中，所述表队列元数据的数据结构为key-Value形式：

<Hive表名+[分区名]，(Redis队列编号，Redis存储槽号，Redis节点编号)>

其中，Key由Hive表名称和分区名称组成，Value由Redis队列编号、Redis存储槽号和Redis节点编号组成。进一步地，根据所述表队列元数据信息，将所述Hive表数据映射到分布式队列中，具体包括：

根据所述表队列元数据信息，确定与所述Hive表对应的队列信息和Redis节点信息；

根据所述队列信息和Redis节点信息，确定需要启动的线程数和每个线程连接的Redis节点；

生成与各队列和各Redis节点对应的写入线程，利用所述写入线程将所述Hive表的多个队列存储至Redis的不同节点上。

第二方面，本发明实施例还提供了一种数据同步装置，包括：

提取模块，用于从待进行同步的Hive表中提取Hive表数据；

映射模块，用于将所述Hive表数据映射到分布式队列中；

读取模块，用于从所述分布式队列中读取数据至目标数据库以完成数据同步。

第三方面，本发明实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面所述的数据同步方法。

第四方面，本发明实施例还提供了一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如第一方面所述的数据同步方法。

由上述技术方案可知，本发明实施例提供的数据同步方法、装置、电子设备及存储介质，由于将Hive表数据映射到分布式队列中，因此可以从分布式队列中读取Hive表数据至目标数据库以完成数据同步，因此可见，本发明实施例设计的将Hive表数据映射到分布式队列的处理方法，可以较好的应对数据量的波动，分布式队列可以较好的应对同步数据量较大的情形，有效优化数据同步的效率。

附图说明

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

图1是本发明一实施例提供的数据同步方法的流程图；

图2是本发明一实施例提供的总体架构示意图；

图3是本发明一实施例提供的将Hive表数据映射到分布式队列的示意图；

图4是本发明一实施例提供的将队列分布到不同的Redis节点中，且保证每个节点都只有一个Hive表的一个队列的示意图；

图5是本发明一实施例提供的数据提取模块的处理过程示意图；

图6是本发明一实施例提供的数据提取流程示意图；

图7是本发明一实施例提供的数据捞取模块的处理过程示意图；

图8是本发明一实施例提供的数据捞取流程示意图；

图9是本发明一实施例提供的数据同步装置的结构示意图；

图10是本发明一实施例提供的电子设备的结构示意图。

具体实施方式

下面结合附图，对本发明的具体实施方式作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

图1示出了本发明一实施例提供的数据同步方法的流程图，如图1所示，本发明实施例提供的数据同步方法，具体包括如下内容：

步骤101：从待进行同步的Hive表中提取Hive表数据；

在本实施例中，本步骤主要负责提取所需同步的数据。举例来说，提取的方式可以分为两种，一种是全表提取，即提取一张Hive表中所有的数据，在这种情况下直接提取HDFS上相应的表文件；第二种是部分提取，即根据用户提供的条件只提取Hive表中满足条件的数据，在这种情况下则使用HiveSQL获取出相应的数据。需要说明的是，用于进行数据提取的数据提取模块可以看作是一个实时运行的进程，类似于消息队列的生产者。

步骤102：将所述Hive表数据映射到分布式队列中；

在本实施例中，如图2和图3所示，本步骤主要负责把提取的数据放入分布式队列中，以等待用于进行数据捞取的数据捞取模块从分布式队列中捞取数据。

举例来说，本实施例可以采用Redis来实现分布式队列的功能，可以理解的是，除了Redis以外，还可以使用其他方式实现分布式队列，并不局限于Redis这一种处理方式。

在本实施例中，需要说明的是，由于将Hive表数据映射到分布式队列中，因此可以从分布式队列中读取Hive表数据至目标数据库以完成数据同步，因此，本实施例设计的将Hive表数据映射到分布式队列的处理方法，可以较好的应对数据量的波动，分布式队列可以较好的应对同步数据量较大的情形，有效优化数据同步的效率。

步骤103：从所述分布式队列中读取数据至目标数据库以完成数据同步。

在本实施例中，本步骤主要负责从分布式队列中捞取结果数据并存入目标数据库中，从而完成Hive表的数据同步。

由上述技术方案可知，本发明实施例提供的数据同步方法，由于将Hive表数据映射到分布式队列中，因此可以从分布式队列中读取Hive表数据至目标数据库以完成数据同步，因此可见，本发明实施例设计的将Hive表数据映射到分布式队列的处理方法，可以较好的应对数据量的波动，分布式队列可以较好的应对同步数据量较大的情形，有效优化数据同步的效率。

在介绍下一实施例之前，先对本发明面临的技术问题进行说明。目前主流的大数据仓库像统一结算系统一样都是构建在Hive的基础之上。通过使用Hive可以有效地处理数以亿计的数据，在使用Hive时的Hive处理结果的同步效率在某些场景下会影响用户的体验和系统的可用性，例如统一结算出账流程结束后用户希望立即可以查询出账结果，在这种情况下如果数据同步的效率太低的话会严重影响用户体验、甚至使用户下一阶段的工作无法正常进行。目前常用的Hive结果数据同步方法有以下几种：①基于文件的处理方式，这种处理方式主要是将Hive处理结果直接导出为磁盘上的本地文件，再将这些导出的结果数据文件导入结果库(一般是关系型数据库，例如MySQL)。这种方式主要依赖于用户自己开发出的代码，例如数据一致性比对系统使用JDBC接口先从Hive中取出比对结果为文件，再通过JDBC接口将结果数据同步到MySQL结果表中。②基于Sqoop框架的处理方式，Sqoop框架是一种基于Hadoop的分布式数据同步框架，它可以实现关系型数据库到Hive的数据同步。Sqoop导出Hive中结果数据的时候会根据用户的指令生成相应的MapReduce任务，这些MapReduce任务会以并行的方式获取需要同步的数据并写入到结果库中。一般情况下，Sqoop的每一个同步任务都只处理Hive中某一张表的数据，这样需要同步多少张Hive结果表就会产生多少个Sqoop同步任务。在实际应用的情况下很可能会出现Hive处理的数据量非常大(达到亿级)，而Hive处理完的结果可能会比较小的情况。在这种情况下使用Sqoop框架就不是最优的方案了，因为Sqoop启动MapReduce任务将会耗费大量的时间，而且如果需要同步的表很多有数百张的时候，Sqoop只能一个个启动MapReduce任务执行非常耗时，即便使用多线程来启动Sqoop同步任务，则会产生大量Sqoop客户端进程消耗大量的系统资源。此外，在需要同步的结果数据量很大的情况下，基于文件的处理方式显然是效率低下的，写中间文件与读中间文件将会消耗大量的时间，系统的文件I/O效率成为了结果数据同步的瓶颈。针对上述问题，本实施例提出一种基于分布式队列的数据同步方案，使其可以较好地应对不同数据量的同步任务，便于扩展，并且尽量优化同步过程来去除不必要的读/写操作，以保证数据同步的实时性。具体地，本实施例设计的基于分布式队列的数据同步优化方法，可以基于Redis来实现，由于Redis可以实现简易的阻塞队列功能，因而完全可以满足数据同步的功能需求，而且Redis是基于内存的数据库读写速度相对于磁盘I/O有着巨大的优势，Redis集群易于扩展可以适应不同数据量的数据同步需求。因此，基于上述实施例的内容，在本实施例中，所述将Hive表数据映射到分布式队列中，具体包括：

将所述Hive表数据映射到Redis的分布式队列中。

进一步地，为提高数据同步效率，基于上述实施例的内容，在本实施例中，将所述Hive表数据映射到Redis的分布式队列中，具体包括：

将每个Hive表的表数据映射为Redis的多个队列；

将与同一Hive表对应的多个队列分散存储至Redis的不同节点上，优选地，保证每个节点都只有一个Hive表的一个队列。

在本实施例中，需要说明的是，将所述Hive表数据映射到Redis的分布式队列是本发明提供的数据同步方法的核心。本实施例设计使用Redis来实现简易的阻塞队列，每个Hive表都将对应多个队列，这些队列被本实施例设计的分布方法分散存储在Redis集群的各个节点

如图4所示，每个表的初始队列数可以设置为Redis集群中的节点个数(也可以配置成其他个数，这设置需要根据同步结果表的大小来确定)，通过本实施例设计的分布方法将队列分布到不同的Redis节点中，优选地，保证每个节点都只有一个Hive表的一个队列。

如图4所示，假设所需要同步的Hive表有A、B、C、三张表，在Redis集群中表A对应3个队列，表B对应2个队列，表C对应3队列，则根据本实施例设计的存储方法，A、B和C这三张表的队列则会分散存储在Redis集群中。在图4中Redis节点1存储了表A的队列1、表B的队列2和表C的队列3，而Redis节点2则存储了表A的队列2、表B的队列1和表C的队列2，将同一表的队列分散到了不同的Redis节点，这样可以在读取数据时启动多个线程从不同的节点并行的读取数据，从而提高数据同步效率。

基于上述实施例的内容，为了保证数据读取的效率，在本实施例中，还设计限制每个队列的长度，使不同表的队列都可以被很快读完。因此，所述将每个Hive表的表数据映射为Redis的多个队列，具体包括：

将每个Hive表数据按照预设队列大小映射为Redis的多个队列；其中，所述预设队列大小根据第一关系模型确定，所述第一关系模型为：

Q_size＝[NODE_size/THREAD_num]

其中，Q_size是预设队列大小，NODE_size是Redis节点的最大存储容量，THREAD_num是Redis节点能接受的最大并发线程数。

在本实施例中，设计限制每个队列的大小，即每个队列只可以容纳有限的记录。采用这种限制的主要原因是Redis的每个节点是以单线程的方式运行的，当有多个读取数据的任务在同一个节点时，Redis会将这些任务排序然后顺序执行，如果有的被读取的队列过大执行时间过长，会阻塞其他读取任务，降低Redis的数据读取效率，因此特意设计了每个队列的大小，用Redis节点的最大存储容量除以Redis节点的并发线程数得到了每个队列的大小，这样做的目的是为了保证在线程满负荷状态下，线程可以读取最大的数据量又能迅速完成切换让别的线程读取数据，保证数据的读取效率。此外，需要说明的是，也可以考虑用Docker来管理Redis集群，如果集群中的某个节点出现负载倾斜则拷贝该节点，用拷贝的节点来分摊负载。

为实现如图4所示的将与同一Hive表对应的多个队列分散存储至Redis的不同节点上，且保证每个节点都只有一个Hive表的一个队列的情况，具体可采用如下实施例介绍的技术手段实现。

基于上述实施例的内容，在本实施例中，将与同一Hive表对应的多个队列分散存储至Redis的不同节点上，具体包括：

确定Redis各队列的键值；

根据所述键值按照第二关系模型将与同一Hive表对应的多个队列分散存储至Redis的不同节点上；

其中，所述第二关系模型为：Loc_key＝(CRC16(Sub(key))+(16384/n*(ORDER_ID-1)))％16384；

其中，Loc_key为存储槽号，Sub(key)表示取队列Key的表名和分区名部分；CRC16(Sub(key)表示取队列Key的表名和分区名部分用CRC16算法编码成一个整数，16384为Redis中槽的总数，n为Redis节点的个数，16384/n得到Redis中每个节点维护的槽的个数，％为求模运算。

在本实施例中，为了达到图4所示的这种分布效果，确定Redis各队列的键值可通过下面第三关系模型实现，也即可以设计队列的key为如下结构：

Key＝Table_Name+[PARTITION_NAME]+ORDER_ID(第三关系模型)

其中，Key为队列的键值，Table_Name为Hive表名称，PARTITION_NAME为Hive表的分区名称(只在表有分区的时候才有效)，ORDER_ID为队列编号(例如：1,2,3,4……)；队列编号对应所设置的初始队列的数量。

在上述设计的Key结构的基础上，本实施例改造了Redis的Key映射方法，与Redis自身的Key映射方法不同，本方法不是取全部的key去求出存储的槽号，而是只截取Key的表名和分区名部分作为输入值，同时在计算时考虑进槽与节点的对应关系，保证不同的队列分布在不同的Redis节点上，计算方法如下：

Loc_key＝(CRC16(Sub(key))+(16384/n*(ORDER_ID-1)))％1638

在本实施例中，先取队列Key的表名和分区名部分用CRC16算法编码成一个整数，这样做可以保证对于同一个表的所有队列的key首先都会映射到同一个Redis的槽中，这个槽称之为初始槽；之后用16384(Redis中槽的总数)除以n(n是Redis节点的个数)得到Redis中每个节点维护的槽的个数，用这个值乘以队列编号减1从而得到每个队列的偏移值，可以看出偏移值会随着队列编号的增大而增大，从最初的偏移值为0会逐步增大，这样再通过对16384取模就可以将队列1存储到初始槽中，而队列2就会因为初始槽的编号增加了一个节点槽的总数从而会被存储到下一个节点的槽中，以此类推队列都会分散在不同节点的槽中，达到分布效果。

基于上述实施例的内容，在本实施例中，为方便进行将所述Hive表数据映射到分布式队列中这一处理动作，在将所述Hive表数据映射到分布式队列中之前，所述方法还包括：预先建立表和队列的对应关系，将表和队列的对应关系作为元数据信息缓存在系统中，以供使用时进行调用。

在本实施例中，将所述Hive表数据映射到分布式队列中，具体包括：

预先建立Hive表和Redis队列的对应关系，并将所述对应关系作为表队列元数据信息进行缓存；

相应地，根据所述表队列元数据信息，将所述Hive表数据映射到分布式队列中；

其中，所述表队列元数据的数据结构为key-Value形式：

<Hive表名+[分区名]，(Redis队列编号，Redis存储槽号，Redis节点编号)>

其中，Key由Hive表名称和分区名称组成，Value由Redis队列编号、Redis存储槽号和Redis节点编号组成。

具体地，在本实施例中，在建立Hive表和Redis队列的对应关系时，可以采用上述实施例介绍的第三关系模型和第二关系模型预先建立Hive表和队列的对应关系，并将所述对应关系作为表队列元数据信息进行缓存；

相应地，根据所述表队列元数据信息，将所述Hive表数据映射到分布式队列中；

其中，所述表队列元数据的数据结构为key-Value形式：

<Hive表名+[分区名]，(Redis队列编号，Redis存储槽号，Redis节点编号)>

其中，Key由表名称和分区名称组成，Value由Redis队列编号、Redis存储槽号和Redis节点编号组成。

在本实施例中，将表和队列的对应关系作为元数据信息缓存在系统中，用以提供给数据提取模块和数据捞取模块进行操作时使用。表队列元数据缓存被设计为一个Map结构，其结构如下：

<Hive表名+[分区名]，(Redis队列编号，Redis存储槽号，Redis节点编号)>

其中，Key由表名称和分区名称组成，而值则包括了队列编号以及槽编号、节点编号这些存储位置信息。

基于上述实施例的内容，在本实施例中，根据所述表队列元数据信息，将所述Hive表数据映射到分布式队列中，具体包括：

根据所述表队列元数据信息，确定与所述Hive表对应的队列信息和Redis节点信息；

根据所述队列信息和Redis节点信息，确定需要启动的线程数和每个线程连接的Redis节点；

生成与各队列和各Redis节点对应的写入线程，利用所述写入线程将所述Hive表的多个队列存储至Redis的不同节点上。

在本实施例中，如图5所示，数据提取模块的核心部分是数据提取进程和Hive元数据。数据提取进程用来提取Hive表里的数据，用户可以用配置文件的方式配置所需要提取的Hive表(也可设置表分区，用来提取某个表的某个分区)，Hive元数据以Map的方式存储了Hive表的元数据信息，这些信息包括表名称、分区信息、表的大小、每个分区的大小、表文件的存储路径和分区文件的存储路径等(如果表没有分区则分区信息、分区大小和分区文件存储路径都为空)。当数据提取进程要提取数据时则根据Hive元信息来判断提取方式：如果提取全表，则根据Hive元信息直接去HDFS提取整个表文件或分区文件，省去启动Hive执行SQL的时间来提升效率；如果是提取表中部分数据则使用Hive执行相应的SQL查询并取出数据。

当数据被从Hive里取出后就要写入Redis里的队列；本实施例设中计一个Hive表对应多个Redis队列，这些队列被分散存储在Redis的不同节点上，根据表对应的队列数来启动线程进行并行写，每一个线程都只写一个Redis节点，每个线程都将获取该表的队列在Redis集群中的存储信息。

如图6所示，数据提取模块进行数据提取时的执行流程如下：

第一步，系统获取所需要提取那些表的数据，这些数据由用户自己配置，除了配置表的信息外也可细化到配置获取哪张表哪个分区的数据；

第二步，根据所要提取的表的信息获取这些表的Hive元数据信息，得到这些表或分区的大小、存储路径等；

第三步，判断该采用哪种提取方式，主要是根据用户配置的提取，如果是提取整个Hive表或整个分区则转步骤四，如果是提取一个表或分区中的部分数据则转步骤五；

第四步，根据表的Hive元信息直接去HDFS上提取Hive表的文件或分区的文件，再转步骤六；

第五步，根据用户提供的条件生成SQL查询语句，查询出用户所要导出的语句并将结果集以List数据结构存储在内存中，再转步骤六；

第六步，根据表的信息获取表所对应的队列在Redis中的存储信息(该存储信息做为元数据信息存储在整个系统中)，根据表队列的存储信息得出这些队列存储在那几个Redis节点上，从而得到需要启动的线程数和每个线程连接的Redis节点；

第七步，生成Redis各个节点的写入线程，每个线程都有一个连接固定Redis节点的Redis客户端对象，将数据写入对应的节点；

第八步，执行完成杀死这些写入线程。

基于上述实施例的内容，在本实施例中，根据所述表队列元数据信息，还可以进行数据捞取操作。如图7所示，数据捞取进程主要负责从Redis中把数据捞出来再写入结果库中相应的结果表。在捞取某一个表或分区的数据时，数据捞取进程会根据Redis中的表队列缓存生成捞取线程，每个捞取线程都对应一个表队列，表队列的访问位置也可由表队列缓存获得。

如图8所示，数据捞取模块进行数据捞取时的执行流程如下：

第一步，数据捞取模块进程以一定的周期循环读取表队列缓存，以保证数据捞取模块使用的表队列关联数据是最新的；

第二步，数据捞取模块进程筛选出需要同步的表，并获取这些表和队列的关联以及表队列存储的位置；

第三步，根据表队列的数量生成捞取线程，本实施例修改了Redis的连接方式，使每个线程可以连接到某个节点；捞取线程连接到各个节点开始捞取各自节点中队列里的数据；

第四步，数据捞取模块进程将捞取线程捞出来的数据写入MySQL结果库，完成捞取操作。

根据上面的描述可知，本实施例设计了一种Hive表与队列的映射方法，能够将Hive表映射为Redis中的多个队列，本实施例同时设计了一种Redis队列的分布方法，可以将同一个表的队列分散存储到Redis的不同节点上，本实施例还设计了表队列信息的缓存，用以支撑数据的写入和读取；本实施例设计的数据提取方法对用户的数据提取需求进行区分，分别采取了不同的方式避免了不必要的提数开销，同时本实施例设计的数据提取方法根据表队列缓存信息来生成线程进行多线程写入；最后本实施例设计的数据捞取方法也可以根据表队列信息来生成相应的线程读取数据。

本实施例设计的基于分布式队列的数据同步方法相较于已有的方法有如下优势：首先采用Redis队列相较于文件和Sqoop都省去了不必要的磁盘I/O开销，所有的数据与操作都在内存中进行，处理速度快、实时性高；其次，通过本实施例设计的队列分布方法与数据提取方法可以较好的应对数据量的波动，分布式队列可以较好的应对同步数据量较大的情形，而数据量较小时由于单个线程执行的时间变短了速度会更快；最后，采用Redis做队列具有较好的扩展性，可以轻易扩展Redis集群。经实验验证，本实施例提供的数据同步方法，相较于之前采用的Sqoop同步方法和文件同步方法，明显提高了数据同步效率。

图9示出了本发明一实施例提供的数据同步装置的结构示意图，如图9所示，本发明实施例提供的数据同步装置，包括：提取模块21、映射模块22和读取模块23，其中：

提取模块21，用于从待进行同步的Hive表中提取Hive表数据；

映射模块22，用于将所述Hive表数据映射到分布式队列中；

读取模块23，用于从所述分布式队列中读取数据至目标数据库以完成数据同步。

由于本实施例提供的数据同步装置可以用于执行上述实施例提供的数据同步方法，其工作原理和有益效果类似，此处不再详述。

基于相同的发明构思，本发明又一实施例提供了一种电子设备，参见图10，所述电子设备具体包括如下内容：处理器301、存储器302、通信接口303和通信总线304；

其中，所述处理器301、存储器302、通信接口303通过所述通信总线304完成相互间的通信；所述通信接口303用于实现各设备之间的信息传输；

所述处理器301用于调用所述存储器302中的计算机程序，所述处理器执行所述计算机程序时实现上述数据同步方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：从待进行同步的Hive表中提取Hive表数据；将所述Hive表数据映射到分布式队列中；从所述分布式队列中读取数据至目标数据库以完成数据同步。

基于相同的发明构思，本发明又一实施例提供了一种非暂态计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述数据同步方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：从待进行同步的Hive表中提取Hive表数据；将所述Hive表数据映射到分布式队列中；从所述分布式队列中读取数据至目标数据库以完成数据同步。

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

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

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

此外，在本发明中，诸如“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

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

此外，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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

Claims (9)

1.一种数据同步方法，其特征在于，包括：

从待进行同步的Hive表中提取Hive表数据；

将所述Hive表数据映射到分布式队列中；

从所述分布式队列中读取数据至目标数据库以完成数据同步；

将所述Hive表数据映射到分布式队列中，具体包括：

将每个Hive表的表数据映射为Redis的多个队列；

将与同一Hive表对应的多个队列分散存储至Redis的不同节点上。

2.根据权利要求1所述的数据同步方法，其特征在于，将每个Hive表的表数据映射为Redis的多个队列，具体包括：

将每个Hive表数据按照预设队列大小映射为Redis的多个队列；其中，所述预设队列大小根据第一关系模型确定，所述第一关系模型为：

Q_size＝[NODE_size/THREAD_num]

其中，Q_size是预设队列大小，NODE_size是Redis节点的最大存储容量，THREAD_num是Redis节点能接受的最大并发线程数。

3.根据权利要求1所述的数据同步方法，其特征在于，将与同一Hive表对应的多个队列分散存储至Redis的不同节点上，具体包括：

确定Redis各队列的键值；

根据所述键值按照第二关系模型将与同一Hive表对应的多个队列分散存储至Redis的不同节点上；

其中，所述第二关系模型为：Loc_key＝(CRC16(Sub(key))+(16384/n*(ORDER_ID-1)))％16384；

其中，Loc_key为存储槽号，Sub(key)表示取队列Key的表名和分区名部分；CRC16(Sub(key))表示取队列Key的表名和分区名部分用CRC16算法编码成一个整数，16384为Redis中槽的总数，n为Redis节点的个数，16384/n得到Redis中每个节点维护的槽的个数，％为求模运算。

4.根据权利要求3所述的数据同步方法，其特征在于，所述确定Redis各队列的键值，具体包括：

根据第三关系模型确定Redis各队列的键值；其中，所述第三关系模型为：Key＝Table_Name+[PARTITION_NAME]+ORDER_ID；

其中，Key为队列的键值，Table_Name为Hive表名称，PARTITION_NAME为Hive表的分区名称，ORDER_ID为队列编号。

5.根据权利要求1所述的数据同步方法，其特征在于，将所述Hive表数据映射到分布式队列中，具体包括：

预先建立Hive表和Redis队列的对应关系，并将所述对应关系作为表队列元数据信息进行缓存；

相应地，根据所述表队列元数据信息，将所述Hive表数据映射到分布式队列中；

其中，所述表队列元数据的数据结构为key-Value形式：

<Hive表名+[分区名]，(Redis队列编号，Redis存储槽号，Redis节点编号)>

其中，Key由Hive表名称和分区名称组成，Value由Redis队列编号、Redis存储槽号和Redis节点编号组成。

6.根据权利要求5所述的数据同步方法，其特征在于，根据所述表队列元数据信息，将所述Hive表数据映射到分布式队列中，具体包括：

根据所述表队列元数据信息，确定与所述Hive表对应的队列信息和Redis节点信息；

根据所述队列信息和Redis节点信息，确定需要启动的线程数和每个线程连接的Redis节点；

生成与各队列和各Redis节点对应的写入线程，利用所述写入线程将所述Hive表的多个队列存储至Redis的不同节点上。

7.一种数据同步装置，其特征在于，包括：

提取模块，用于从待进行同步的Hive表中提取Hive表数据；

映射模块，用于将所述Hive表数据映射到分布式队列中，具体包括：将每个Hive表的表数据映射为Redis的多个队列；将与同一Hive表对应的多个队列分散存储至Redis的不同节点上；

读取模块，用于从所述分布式队列中读取数据至目标数据库以完成数据同步。

8.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6任一所述的数据同步方法。

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