CN112286941B - 一种基于Binlog+HBase+Hive的大数据同步方法和装置 - Google Patents
一种基于Binlog+HBase+Hive的大数据同步方法和装置 Download PDFInfo
- Publication number
- CN112286941B CN112286941B CN202011545416.3A CN202011545416A CN112286941B CN 112286941 B CN112286941 B CN 112286941B CN 202011545416 A CN202011545416 A CN 202011545416A CN 112286941 B CN112286941 B CN 112286941B
- Authority
- CN
- China
- Prior art keywords
- data
- hbase
- binlog
- hive
- database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2471—Distributed queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Software Systems (AREA)
- Fuzzy Systems (AREA)
- Mathematical Physics (AREA)
- Probability & Statistics with Applications (AREA)
- Computational Linguistics (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及数据库技术领域,提供了一种基于Binlog+HBase+Hive的大数据同步方法和装置。方法包括监听关系型数据库中Binlog日志文件,获取实时变化的数据;数据同步装置获取Binlog日志文件数据后,解析并获取数据库名,表名,操作类型,主键,所有字段值;在HBase中存储Binlog日志文件数据时,对应以数据库名称作为HBase表的命名空间,建表;使用主键作为HBase数据记录的rowkey,以便于数据库记录的所有变化,都通过rowkey找到HBase的对应记录进行数据覆盖更新。本发明实时表中不保留历史全量数据,数据量小,查询实时数据速度快。
Description
技术领域
本发明涉及数据库技术领域,特别是涉及一种基于Binlog+HBase+Hive的大数据同步方法和装置。
背景技术
随着数据的增长,传统的单机数据库已无法满足亿级的存储和分析需求。目前业界的做法是单机数据库用作生产环境的实时热点数据存储,历史数据做归档,同时将数据同步到大数据仓库,从而进行复杂分析。但当前的方案,各自存在一些缺点:
1、数据查询导出方案
全量导出方案
通过oozie等任务调度工具定时利用sqoop等ETL工具通过JDBC协议连接数据库,将数据库的表数据查询后全量导出,然后完整覆盖大数据仓库对应的表数据。该方案可以保证数据的完整性,但是每天全量导出,数据量大的情况下,资源开销大,效率低。另外其时效性低,没有实时数据。
增量导出方案
通过oozie等任务调度工具定时利用sqoop等ETL工具通过JDBC协议连接数据库,将数据库的表数据查询后增量导出,然后将增量数据与大数据仓库对应的表数据做合并。该方案只获取变更的数据,数据量大大减小。但其依赖数据库表设计数据的更新时间字段。且数据做了物理删除的情况下,增量数据不包含物理删除的数据,导致大数据仓库对应的数据没有对应删除。另外其时效性低,没有实时数据。
2、Binlog监听方案
使用canal等Binlog监听工具实时获取数据库的表数据变更信息。
通过消费程序将Binlog数据写入Hive。由于Hive的存储特征,数据顺序写入,很难进行数据的修改和删除,只能将Binlog原始数据顺序记录下来,然后定时的合并处理,数据量大,资源开销大,效率低,时效性低。
通过消费程序将Binlog数据写入HBase。由于HBase的存储特征,可以存储全部的海量数据,但不适合做复杂的统计分析。即使使用Apache Phoenix、Hive等查询工具,也会对HBase产生极大的性能影响。再就是存在数据并发消费写入顺序性问题。
鉴于此,克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。
发明内容
本发明要解决的技术问题是涉及数据同步性能消耗、数据同步时效性、数据物理删除同步、binlog数据并发消费写入顺序的综合解决方案性能提升问题。
本发明采用如下技术方案:
第一方面,本发明提供了一种基于Binlog+HBase+Hive的大数据同步方法,包括:
监听关系型数据库中Binlog日志文件,获取实时变化的数据;
数据同步装置获取Binlog日志文件数据后,解析并获取数据库名db,表名t,操作类型o,主键k,所有字段值;在HBase中存储Binlog日志文件数据时,对应以数据库名称作为HBase表的命名空间,建表db:t;
使用主键k作为HBase数据记录的rowkey,以便于数据库记录的所有变化,都通过rowkey找到HBase的对应记录进行数据覆盖更新;
对每个表都新增2个字段,分别为数据的更新日期etl_dt,物理删除标识etl_deleted,所述物理删除标识用于标识数据是否已经在相应关系型数据库中物理删除;当操作类型o为insert或者update时,设置物理删除标识etl_deleted为0,当操作类型o为delete时,设置物理删除标识etl_deleted为1;以便同步合并到数据仓库Hive表时,丢弃Hive里对应删除标识etl_deleted为1的数据记录。
优选的,数据同步装置为分布式多线程并发处理,具体的:
获取Binlog日志中数据产生的时间戳,用所述时间戳作为HBase数据的timestamp写入;
若发生同一表项中Binlog日志中数据产生的时间戳相同,则数据同步装置会利用redis缓存,使用记录的表名t+主键k+timestamp作为rediskey,并使用Binlog的全局事务ID作为value;
每条数据先去redis缓存中查找rediskey,若查找成功,则说明有相同表、相同主键、相同时间产生了更新数据;比较当前Binlog的全局事务ID和key对应存储的全局事务ID大小来判断当前数据是否更小,如果当前数据的全局事务ID小,则为旧数据,直接丢弃。
优选的,HBase的表设置数据过期时间,保留过期时间内的增量变化数据,然后创建对应的Hive表,进行SQL统计分析。
优选的,通过oozie定时调度工具,定时将HBase映射的Hive实时数据表A的数据合并到对应的Hive全量历史表B中;其中,所述Hive全量历史表B为物理表;所述实时数据表A为映射表。
优选的,合并方式为,表主键相同的记录用A的增量数据覆盖B的数据,当A的etl_deleted=1时,则实时数据表A中的相应数据进行删除,以便于在Hive进行数据同步时,在对比生成新文件时,过滤掉相应数据。
优选的,所述关系型数据库包括:Oracle、DB2、Microsoft SQL Server、MicrosoftAccess和MySQL中的一种或者多种。
第二方面,本发明还提供了一种基于Binlog+HBase+Hive的大数据同步方法和装置,用于实现第一方面所述的基于Binlog+HBase+Hive的大数据同步方法,所述装置包括:
至少一个处理器;以及,与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述处理器执行,用于执行第一方面所述的基于Binlog+HBase+Hive的大数据同步方法。
第三方面,本发明还提供了一种非易失性计算机存储介质,所述计算机存储介质存储有计算机可执行指令,该计算机可执行指令被一个或多个处理器执行,用于完成第一方面所述的基于Binlog+HBase+Hive的大数据同步方法。
本发明对比Binlog数据写入Hbase,然后编码进行API查询的方式,本发明无需进行API接口的复杂编码对接,用简单的SQL即可完成分析查询。本方案通过将HBase的数据映射到Hive中,然后编写SQL语句来查询。其优势在于可以给懂sql语言的数据分析人员使用,提供强大的数据查询支持,满足数据的交互需求。
本发明对比Binlog数据写入Hbase然后映射Hive表进行查询分析的方式,本发明实时表中不保留历史全量数据,数据量小,查询实时数据速度快。通过Hive直接映射HBase的全量数据,查询时会占用HBase的计算资源,影响业务系统的对其的读写能力。且经对比实践,同样数据量同样计算资源的情况下,HBase映射表与Hive物理表对比,查询效率低一倍以上。本方案将全量数据做成Hive物理表查询,不影响业务系统,且查询效率更高。另外,本方案实现了分布式并发数据处理系统,通过横向添加机器的方式即可提升数据处理能力。
本发明对比Binlog数据写入Hive,然后进行定时数据合并后查询的方式,本发明对于实时数据的查询无需定时合并,实时表的数据实时性高,节约计算资源。本方案通过将Binlog数据写入HBase,再映射成Hive表进行查询,可以支持实时变化数据的查询。另外,本方案提供了物理删除的数据的同步处理方法,保障了数据仓库数据和业务系统数据库的记录一致。
【附图说明】
为了更清楚地说明本发明实施例的技术方案,下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地,下面所描述的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种基于Binlog+HBase+Hive的大数据同步方法流程示意图;
图2是本发明实施例提供的一种基于Binlog+HBase+Hive的大数据同步方法流程示意图;
图3是本发明实施例提供的一种基于Binlog+HBase+Hive的大数据同步方法流程示意图;
图4是本发明实施例提供的一种基于Binlog+HBase+Hive的大数据同步装置结构示意图。
【具体实施方式】
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
在本发明的描述中,术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作,因此不应当理解为对本发明的限制。
Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供SQL查询功能,可以将SQL语句转换为MapReduce任务进行运行。其优点是学习成本低,可以通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。
HBase是一个分布式的、面向列的开源数据库。数据模型为Row Key、Timestamp、Column Family。
Mysql Binlog是二进制格式的日志文件,记录Mysql内部对数据库的改动。
canal是阿里巴巴旗下的一款开源项目,基于数据库增量日志解析,提供增量数据订阅&消费。
Kafka是一种高吞吐量的分布式发布订阅消息系统。
hbase:数据结构为:Row Key行键+Timestamp时间戳+Column Family列簇。所以其特性为:适合通过行键(比如数据库的表主键)来更新数据,通过时间戳来保障数据的先后顺序正确。但是其问题是,列簇中的字段没有索引,查询得全表扫描,或者通过别的工具建二级索引。
hive:它提供了丰富的SQL查询方式来分析存储在Hadoop分布式文件系统中的数据。可以将结构化的数据文件映射为一张数据库表,并提供完整的SQL查询功能,将SQL语句转换为MapReduce任务运行;但是由于它底层的文件系统是hadoop的hdfs,不支持行级的数据更新操作。
在本发明各实施例中,时间戳是关系数据库的更新时间;用来更新HBase里的Timestamp;而Timestamp是HBase里面描述数据的一个版本用的维度,即时间信息;这两者与本发明的etl_dt的关系,都是用来表征时间,但是各自用的场景不同。
此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
实施例1:
本发明实施例1提供了一种基于Binlog+HBase+Hive的大数据同步方法,如图1所示,包括:
在步骤201中,监听关系型数据库中Binlog日志文件,获取实时变化的数据。
其中,所述关系型数据库包括:Oracle、DB2、Microsoft SQL Server、MicrosoftAccess和MySQL中的一种或者多种。
在步骤202中,数据同步装置获取Binlog日志文件数据后,解析并获取数据库名db,表名t,操作类型o,主键k,所有字段值;在HBase中存储Binlog日志文件数据时,对应以数据库名称作为HBase表的命名空间,建表db:t。
其中,在Hbase数据库中,其建表的命名规则为“空间名称”:“表名”,即上述的db:t。
在步骤203中,使用主键k作为HBase数据记录的rowkey,以便于数据库记录的所有变化,都通过rowkey找到HBase的对应记录进行数据覆盖更新。
在步骤204中,对每个表都新增2个字段,分别为数据的更新日期etl_dt,物理删除标识etl_deleted,所述物理删除标识用于标识数据是否已经在相应关系型数据库中物理删除;当操作类型o为insert或者update时,设置物理删除标识etl_deleted为0,当操作类型o为delete时,设置物理删除标识etl_deleted为1;以便同步合并到数据仓库Hive表时,丢弃Hive里对应删除标识etl_deleted为1的数据记录。其中,etl采纳自Extract-Transform-Load的缩写,而相应的dt为数据data的缩写。
结合本发明实施例,还存在一种应用场景,其中,数据同步装置为分布式多线程并发处理,如图2所示,具体的:
在步骤301中,获取Binlog日志中数据产生的时间戳,用所述时间戳作为HBase数据的timestamp写入;其中,timestamp是Hbase中的固有属性之一。
在步骤302中,Binlog若发生同一表项中Binlog日志中数据产生的时间戳相同,则数据同步装置会利用redis缓存,使用记录的表名t+主键k+timestamp作为rediskey,并使用Binlog的全局事务ID作为value;其中,全局事务ID(缩写为GTID)内容表现为:字母加数字的字符串,在具体使用过程中,通过逐一的比对各个字节的大小来实现。GTID功能是mysql5.6版本开始新加入的特性,GTID是一种很好的分布式ID实践方式。
在步骤303中,每条数据先去redis缓存中查找rediskey,若查找成功,则说明有相同表、相同主键、相同时间产生了更新数据;比较当前Binlog的全局事务ID和key对应存储的全局事务ID大小来判断当前数据是否更小,如果当前数据的全局事务ID小,则为旧数据,直接丢弃。其中,比较当前Binlog的全局事务ID和key对应存储的全局事务ID大小来判断当前数据是否更小,如果当前数据的全局事务ID小,则为旧数据,直接丢弃为现有的一种基于全局事务ID的机制,并非本发明独自提出的技术动作,在此不多赘述。
例如:k=1的一条记录,在09:00:01产生一条更新日志L1,在09:00:02产生一条更新日志L2,线程T1接受到L1,线程T2接受到L2,可能因为资源波动或者网络波动等不可控因素,导致线程T2在09:00:03先写入L2的数据,线程T1在09:00:04后写入L1的数据,通常情况下,会导致L1的数据覆盖L2的数据,造成数据错误。而数据同步装置通过获取Binlog日志产生的时间戳,来设置HBase记录的timestamp,具体为线程T2在09:00:03先写入L2的数据,数据的timestamp=09:00:02,线程T1在09:00:04后写入L1的数据,数据的timestamp=09:00:01。由于L1的timestamp小于L2的timestamp,故不会覆盖K=1记录的HBase数据。
结合本发明实施例,还存在一种优选的扩展方案,HBase的表设置数据过期时间,HBase保留过期时间内的增量变化数据,然后创建对应的Hive表,进行SQL统计分析。其中,Hive相比较HBase的优势在于,提供结构化查询的功能(即SQL查询方式),这是Hive数据库相比较HBase数据库的优势所在。
在本发明实施例实现过程中,对于将HBase数据导入Hive表中的方式,也提供了一种具体优选实现方案,通过oozie定时调度工具,定时将HBase映射的Hive实时数据表A的数据合并到对应的Hive全量历史表B中;其中,所述Hive全量历史表B为物理表;所述实时数据表A为映射表。其中,HIVE不适合做实时动态更新,HIVE是一条一条顺序的往文件里面写;如果有多个操作,它不会直接更新到最后的,而是像写日志一样一条一条执行;最后用合并更新后的Hive表做全量数据的复杂统计分析。解决了数据物理删除无法同步的问题。
本方案对比Binlog数据写入Hbase然后映射Hive表进行查询分析的方式,本方案Hive为物理表,相对于HBase映射的Hive表,查询速度快1倍,且不会对HBase产生计算压力,导致HBase性能下降。
在本发明实施例还提供了一种合并方式,表主键相同的记录用A的增量数据覆盖B的数据,当A的etl_deleted=1时,则实时数据表A(即上述过期时间内的Hbase数据,例如近3天的所有动态数据)中的相应数据进行删除,以便于在Hive进行数据同步时,在对比生成新文件时,过滤掉相应数据。此处,若不携带etl_deleted=1,则Hive边无法知道相应数据在生成新文件时,是否需要过滤掉。
本方案对比《CN201710084592.3 一种基于HBase的物联网大数据存取方法》:其查询hbase数据的方法为通过编码拼接HBase Scan对象,然后调用hbase的API实现。该方案存在的问题是查询数据必须要程序员编码实现,且查询条件的变化需要修改并发布程序。本方案通过将hbase的数据映射到hive中,然后编写SQL语句来查询。其优势在于可以给懂sql语言的数据分析人员使用,提供强大的数据查询支持,满足数据的交互需求。
本方案对比《CN201611237526.7 一种建立用于大数据分析的中间数据仓库的方法及系统》:其通过binlog数据写入Hbase保存全量数据的变化,然后映射hive表进行查询分析。该方案存在的问题是通过hive直接映射hbase的全量数据,查询时会占用hbase的计算资源,影响业务系统的对其的读写能力。且经对比实践,同样数据量同样计算资源的情况下,hbase映射表与hive物理表对比,查询效率低一倍以上。本方案将全量数据做成hive物理表查询,不影响业务系统,且查询效率更高。另外,本方案实现了分布式并发数据处理系统,通过横向添加机器的方式即可提升数据处理能力。
本方案对比《CN202010165156.0 一种数据同步方法、装置、服务器及存储介质》:其通过定期将binlog数据合并到hive存量数据提供数据查询。该方案存在的问题是,定期同步数据时效性差,无法查询到实时的数据。本方案通过将binlog数据写入hbase,再映射成hive表进行查询,可以支持实时变化数据的查询。另外,本方案提供了物理删除的数据的同步处理方法,保障了数据仓库数据和业务系统数据库的记录一致。
实施例2:
针对实施例1中所描述的方法内容,在本发明实施例从另一个关键节点进行切入,并结合具体工具进行内容呈现,相应的整体过程如图3所示。
第一部分:实时Binlog获取
作为优选可以用canal工具,监听MySql数据库Binlog日志,然后将Binlog日志数据对接到消息中间件kafka中,再开发应用程序进行数据消费处理。或者使用阿里的logtail工具,然后开发程序消费。
即通过监听MySql Binlog日志文件获取实时变化的数据的方式,相对于数据查询导出方案而言,不影响数据库性能,解决了数据同步性能问题、时效性问题。
第二部分:实时Binlog处理
数据同步装置,其特性在于接受消息中间件kafka中的Binlog数据,处理后写入HBase。具体处理步骤如下:
a、数据同步装置获取Binlog数据后,解析并获取库名db,表名t,操作类型o,主键k,所有字段值。在HBase中对应的建表db:t,即以数据库名称作为HBase表的命名空间,避免不同的数据库有相同的名称的表,导致HBase表名冲突。
b、使用主键k作为HBase数据记录的rowkey,即数据库记录的所有变化,都通过rowkey找到HBase的对应记录进行数据覆盖更新。同时对每个表都新增2个字段,分别为数据的更新日期etl_dt,物理删除标识etl_deleted。当操作类型o为insert或者update时,设置物理删除标识etl_deleted为0,当操作类型o为delete时,设置物理删除标识etl_deleted为1。以此标识数据是否已经物理删除,以便同步合并到数据仓库Hive表时,丢弃Hive里对应的数据记录,解决物理删除记录的同步问题。
c、为了保障处理速度,数据同步装置为分布式多线程并发处理的设计,分布式方式存在数据生产顺序和消费处理顺序不一致的问题。故数据同步装置在写入数据时,不使用数据消费程序的系统时间,也不使用写入HBase数据的默认时间,而是获取Binlog日志中数据产生的时间戳,用该时间戳作为HBase数据的timestamp写入。
例如:k=1的一条记录,在09:00:01产生一条更新日志L1,在09:00:02产生一条更新日志L2,线程T1接受到L1,线程T2接受到L2,可能因为资源波动或者网络波动等不可控因素,导致线程T2在09:00:03先写入L2的数据,线程T1在09:00:04后写入L1的数据,通常情况下,会导致L1的数据覆盖L2的数据,造成数据错误。而数据同步装置通过获取Binlog日志产生的时间戳,来设置HBase记录的timestamp,具体为线程T2在09:00:03先写入L2的数据,数据的timestamp=09:00:02,线程T1在09:00:04后写入L1的数据,数据的timestamp=09:00:01。由于L1的timestamp小于L2的timestamp,故不会覆盖K=1记录的HBase数据。
d、另外还存在一个可能是,L1和L2的Binlog日志产生的时间戳一样,无法利用timestamp解决写入顺序问题。数据同步装置会利用redis缓存,使用记录的表名t+主键k+timestamp作为key,Binlog的GTID(全局事务ID)作为value,每条数据先去redis setnx对应rediskey,若失败,则说明有相同表相同主键相同时间产生了更新数据。此时需要比较当前Binlog的GTID和key对应存储的GTID大小来判断当前数据是否更小,如果当前数据的GTID小,则为旧数据。
第三部分:HBase数据落地到Hive
a、解决实时数据复杂分析查询需求。HBase的表设置数据过期时间,比如3天,这样保障HBase每张表的数据量不会太大,仅保留近三天的增量变化数据,然后创建对应的Hive表,进行SQL统计分析。
b、解决历史全量数据复杂分析查询需求。通过oozie等定时调度工具,每天将HBase映射的Hive实时数据表A的数据合并到对应的Hive全量历史表B中。合并方式为,表主键相同的记录用A的增量数据覆盖B的数据,当A的etl_deleted=1时,则两个表都过滤掉该数据。最后用合并更新后的Hive表做全量数据的复杂统计分析。解决了数据物理删除无法同步的问题。
本发明对比Binlog数据写入Hbase然后映射Hive表进行查询分析的方式,本发明Hive为物理表,相对于HBase映射的Hive表,查询速度快1倍,且不会对HBase产生计算压力,导致HBase性能下降。
本发明对比Binlog数据写入Hbase,然后编码进行API查询的方式,本发明无需进行API接口的复杂编码对接,用简单的SQL即可完成分析查询。
本发明对比Binlog数据写入Hbase然后映射Hive表进行查询分析的方式,本发明实时表中不保留历史全量数据,数据量小,查询实时数据速度快。
本发明对比Binlog数据写入Hive,然后进行定时数据合并后查询的方式,本发明无需定时合并,实时表的数据实时性高,节约计算资源。
实施例3:
如图4所示,是本发明实施例的基于Binlog+HBase+Hive的大数据同步装置的架构示意图。本实施例的基于Binlog+HBase+Hive的大数据同步装置包括一个或多个处理器21以及存储器22。其中,图4中以一个处理器21为例。
处理器21和存储器22可以通过总线或者其他方式连接,图4中以通过总线连接为例。
存储器22作为一种非易失性计算机可读存储介质,可用于存储非易失性软件程序和非易失性计算机可执行程序,如实施例1中的基于Binlog+HBase+Hive的大数据同步方法。处理器21通过运行存储在存储器22中的非易失性软件程序和指令,从而执行基于Binlog+HBase+Hive的大数据同步方法。
存储器22可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中,存储器22可选包括相对于处理器21远程设置的存储器,这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
所述程序指令/模块存储在所述存储器22中,当被所述一个或者多个处理器21执行时,执行上述实施例1中的基于Binlog+HBase+Hive的大数据同步方法,例如,执行以上描述的图1和图2所示的各个步骤。
值得说明的是,上述装置和系统内的模块、单元之间的信息交互、执行过程等内容,由于与本发明的处理方法实施例基于同一构思,具体内容可参见本发明方法实施例中的叙述,此处不再赘述。
本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:只读存储器(ROM,Read Only Memory)、随机存取存储器(RAM,Random AccessMemory)、磁盘或光盘等。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
Claims (7)
1.一种基于Binlog+HBase+Hive的大数据同步方法,其特征在于,包括:
监听关系型数据库中Binlog日志文件,获取实时变化的数据;
数据同步装置获取Binlog日志文件数据后,解析并获取数据库名db,表名t,操作类型o,主键k,所有字段值;在HBase中存储Binlog日志文件数据时,对应以数据库名称作为HBase表的命名空间,建表db:t;
使用主键k作为HBase数据记录的rowkey,以便于数据库记录的所有变化,都通过rowkey找到HBase的对应记录进行数据覆盖更新;
对每个表都新增2个字段,分别为数据的更新日期etl_dt,物理删除标识etl_deleted,所述物理删除标识用于标识数据是否已经在相应关系型数据库中物理删除;当操作类型o为insert或者update时,设置物理删除标识etl_deleted为0,当操作类型o为delete时,设置物理删除标识etl_deleted为1;以便同步合并到数据仓库Hive表时,丢弃Hive里对应删除标识etl_deleted为1的数据记录;
数据同步装置为分布式多线程并发处理,具体的:
获取Binlog日志中数据产生的时间戳,用所述时间戳作为HBase数据的timestamp写入;
若发生同一表项中Binlog日志中数据产生的时间戳相同,则数据同步装置会利用redis缓存,使用记录的表名t+主键k+timestamp作为rediskey,并使用Binlog的全局事务ID作为value;
每条数据先去redis缓存中查找rediskey,若查找成功,则说明有相同表、相同主键、相同时间产生了更新数据;比较当前Binlog的全局事务ID和key对应存储的全局事务ID大小来判断当前数据是否更小,如果当前数据的全局事务ID小,则为旧数据,直接丢弃。
2.根据权利要求1所述的基于Binlog+HBase+Hive的大数据同步方法,其特征在于,HBase的表设置数据过期时间,保留过期时间内的增量变化数据,然后创建对应的Hive表,进行SQL统计分析。
3.根据权利要求1所述的基于Binlog+HBase+Hive的大数据同步方法,其特征在于,通过oozie定时调度工具,定时将HBase映射的Hive实时数据表A的数据合并到对应的Hive全量历史表B中;其中,所述Hive全量历史表B为物理表;所述实时数据表A为映射表。
4.根据权利要求3所述的基于Binlog+HBase+Hive的大数据同步方法,其特征在于,合并方式为,表主键相同的记录用A的增量数据覆盖B的数据,当A的etl_deleted=1时,则实时数据表A中的相应数据进行删除,以便于在Hive进行数据同步时,在对比生成新文件时,过滤掉相应数据。
5.根据权利要求1-4任一所述的基于Binlog+HBase+Hive的大数据同步方法,其特征在于,所述关系型数据库包括:Oracle、DB2、Microsoft SQL Server、Microsoft Access和MySQL中的一种或者多种。
6.一种基于Binlog+HBase+Hive的大数据同步装置,其特征在于,所述装置包括:
至少一个处理器;以及,与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述处理器执行,用于执行权利要求1-5 任一所述的基于Binlog+HBase+Hive的大数据同步方法。
7.一种非易失性计算机存储介质,其特征在于,所述计算机存储介质存储有计算机可执行指令,该计算机可执行指令被一个或多个处理器执行,用于完成权利要求1-5任一所述的基于Binlog+HBase+Hive的大数据同步方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011545416.3A CN112286941B (zh) | 2020-12-23 | 2020-12-23 | 一种基于Binlog+HBase+Hive的大数据同步方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011545416.3A CN112286941B (zh) | 2020-12-23 | 2020-12-23 | 一种基于Binlog+HBase+Hive的大数据同步方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112286941A CN112286941A (zh) | 2021-01-29 |
CN112286941B true CN112286941B (zh) | 2021-03-23 |
Family
ID=74426057
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011545416.3A Active CN112286941B (zh) | 2020-12-23 | 2020-12-23 | 一种基于Binlog+HBase+Hive的大数据同步方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112286941B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112948486B (zh) * | 2021-02-04 | 2024-08-16 | 北京淇瑀信息科技有限公司 | 批量数据同步方法、系统及电子设备 |
CN112948490B (zh) * | 2021-02-26 | 2023-10-24 | 湖北华中电力科技开发有限责任公司 | 基于kafka和redis的数据同步方法、装置、设备和存储介质 |
CN113094208B (zh) * | 2021-04-02 | 2024-04-09 | 上海中通吉网络技术有限公司 | 基于绑定接口和Binlog日志实现数据恢复的方法及系统 |
CN113449043A (zh) * | 2021-07-21 | 2021-09-28 | 中国人民解放军61932部队 | 数据同步方法、装置、计算机设备和存储介质 |
CN114048178B (zh) * | 2021-11-29 | 2022-07-26 | 众和空间(北京)科技有限责任公司 | 一种数据的双模式存储及同步方法 |
CN115718787B (zh) * | 2023-01-09 | 2023-05-05 | 百融至信(北京)科技有限公司 | 数据表数据同步方法、查询方法、电子设备及存储介质 |
CN115982285B (zh) * | 2023-03-10 | 2023-07-07 | 北京集度科技有限公司 | 数据处理方法、设备及计算机可读存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108920698A (zh) * | 2018-07-16 | 2018-11-30 | 北京京东金融科技控股有限公司 | 一种数据同步方法、装置、系统、介质及电子设备 |
CN109815219A (zh) * | 2019-02-18 | 2019-05-28 | 国家计算机网络与信息安全管理中心 | 支持多数据库引擎的数据生命周期管理的实现方法 |
CN110489247A (zh) * | 2019-08-22 | 2019-11-22 | 深圳前海环融联易信息科技服务有限公司 | 一种数据实时集成方法及装置 |
CN110879812A (zh) * | 2019-11-20 | 2020-03-13 | 浪潮软件股份有限公司 | 一种电商平台中基于spark的数据同步方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110287251B (zh) * | 2019-06-26 | 2022-09-16 | 上海德拓信息技术股份有限公司 | MongoDB到HBase的分布式高容错数据实时同步方法 |
-
2020
- 2020-12-23 CN CN202011545416.3A patent/CN112286941B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108920698A (zh) * | 2018-07-16 | 2018-11-30 | 北京京东金融科技控股有限公司 | 一种数据同步方法、装置、系统、介质及电子设备 |
CN109815219A (zh) * | 2019-02-18 | 2019-05-28 | 国家计算机网络与信息安全管理中心 | 支持多数据库引擎的数据生命周期管理的实现方法 |
CN110489247A (zh) * | 2019-08-22 | 2019-11-22 | 深圳前海环融联易信息科技服务有限公司 | 一种数据实时集成方法及装置 |
CN110879812A (zh) * | 2019-11-20 | 2020-03-13 | 浪潮软件股份有限公司 | 一种电商平台中基于spark的数据同步方法 |
Non-Patent Citations (1)
Title |
---|
基于MySQL Binlog 实现HBase数据同步实践;贾静斯;《知乎》;20200306;第1-5页 * |
Also Published As
Publication number | Publication date |
---|---|
CN112286941A (zh) | 2021-01-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112286941B (zh) | 一种基于Binlog+HBase+Hive的大数据同步方法和装置 | |
CN109460349B (zh) | 一种基于日志的测试用例生成方法和装置 | |
US10614050B2 (en) | Managing object requests via multiple indexes | |
CN107544984B (zh) | 一种数据处理的方法和装置 | |
CN107515874B (zh) | 一种分布式非关系型数据库中同步增量数据的方法与设备 | |
CN104133867A (zh) | 分布式顺序表片内二级索引方法及系统 | |
CN111694863B (zh) | 一种数据库缓存的刷新方法、系统和装置 | |
CN106874281B (zh) | 实现数据库读写分离的方法和装置 | |
US9811560B2 (en) | Version control based on a dual-range validity model | |
CN105608126A (zh) | 一种建立海量数据库二级索引的方法和装置 | |
CN112000649B (zh) | 一种基于map reduce的增量数据同步的方法和装置 | |
CN111680017A (zh) | 一种数据同步的方法及装置 | |
CN113177090A (zh) | 数据处理方法及装置 | |
CN114691704A (zh) | 一种基于MySQL binlog的元数据同步方法 | |
CN112965939A (zh) | 一种文件合并方法、装置和设备 | |
CN114741453A (zh) | 数据同步的方法、系统及计算机可读存储介质 | |
CN113704267A (zh) | 基于ElasticSearch的数据查询方法、系统、设备及存储介质 | |
CN111159020B (zh) | 一种应用于同步软件测试的方法和装置 | |
CN116049306A (zh) | 数据同步方法、装置、电子设备以及可读存储介质 | |
CN113672556A (zh) | 一种批量文件的迁移方法及装置 | |
US20240095246A1 (en) | Data query method and apparatus based on doris, storage medium and device | |
US20240070180A1 (en) | Mutation-Responsive Documentation Regeneration Based on Knowledge Base | |
US11914655B2 (en) | Mutation-responsive documentation generation based on knowledge base | |
CN112685431B (zh) | 异步缓存方法、装置、系统、电子设备和存储介质 | |
CN117390040B (zh) | 基于实时宽表的业务请求处理方法、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |