CN114077518A - 数据快照方法、装置、设备及存储介质 - Google Patents
数据快照方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN114077518A CN114077518A CN202010850323.5A CN202010850323A CN114077518A CN 114077518 A CN114077518 A CN 114077518A CN 202010850323 A CN202010850323 A CN 202010850323A CN 114077518 A CN114077518 A CN 114077518A
- Authority
- CN
- China
- Prior art keywords
- snapshot
- component
- data
- log file
- message
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种数据快照方法、装置、设备及存储介质,该方法包括:Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka;kafka对所述日志文件写入对应的消息分区,生成订阅消息并发送至快照组件;当达到快照触发条件时,所述快照组件基于所述订阅消息对所述日志文件进行快照处理得到数据快照。该方案中快照组件能够直接基于kafka发送的订阅消息进行快照处理,使得生成数据快照的过程中不影响业务的正常进行,并且具备强大的容灾性,能够通过快照组件进行快照处理时的备份数据快速恢复得到任意时间点的数据切面数据。
Description
技术领域
本发明一般涉及数据处理技术领域,具体涉及一种数据快照方法、装置、设备及存储介质。
背景技术
随着信息技术的不断发展,产生的数据量越来越多,更新也越来越快,这同时对数据处理及存储技术提出了很高的要求,需要进行数据快照处理,以实现某个时间节点的数据备份。数据快照是一种保留某一时刻数据映像的技术,其保留的映像称为快照。
目前,数据快照可以通过执行sql语句将指定表里面的所有数据备份到另一张表中,使得在新的表中形成执行sql命令时的数据备份,也可以通过MySQL数据库自带的备份文件系统dump工具,实现单库单表/单库多表/多库多表的数据快照备份。
然而,相关的快照处理方案在生成数据快照的时候,其他的业务操作无法正常进行,会对全时段不停机业务产生业务影响,并且生成的快照如果损坏会导致无法恢复,使得快照处理的容灾性较差。
发明内容
鉴于现有技术中的上述缺陷或不足,期望提供一种数据快照方法、装置、设备及存储介质。
第一方面,本申请提供了一种数据快照方法,该方法包括:
Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka;
kafka将日志文件写入对应的消息分区,生成订阅消息并发送至快照组件;
当达到快照触发条件时,快照组件基于订阅消息对日志文件进行快照处理得到数据快照。
在其中一个实施例中,kafka将日志文件写入对应的消息分区,生成订阅消息并发送至快照组件,包括:
kafka根据预先配置的分片规则对日志文件进行哈希处理,得到哈希值;
kafka按照哈希值将日志文件进行分区处理,存储至对应的消息分区;
kafka读取消息分区对应的日志文件,生成订阅消息;
kafka将订阅消息发送至快照组件。
在其中一个实施例中,快照组件基于订阅消息对日志文件进行快照处理得到数据快照,包括:
快照组件对订阅消息进行解析处理,得到与订阅消息对应的日志文件;
快照组件基于预设的配置文件,对日志文件进行快照处理得到数据快照。
在其中一个实施例中,快照组件包括至少一个业务处理组件和至少一个业务存储组件,快照组件基于预设的配置文件,对日志文件进行快照处理得到数据快照,包括:
快照组件基于预设的配置文件判断日志文件是否需要处理,配置文件包括针对相同的日志文件进行不同业务处理条件下设置的配置参数;
当对日志文件需要处理时,获取至少一个业务处理组件中每个业务处理组件对应的业务类型;
基于业务类型对日志文件进行数据处理,得到每个业务处理组件对应的数据快照。
在其中一个实施例中,在快照组件基于预设的配置文件判断日志文件是否需要处理之后,该方法还包括:
当对日志文件不需要处理时,获取至少一个业务存储组件中每个业务存储组件对应的存储格式;
将所述日志文件按照所述存储格式进行处理,得到每个业务存储组件对应的数据快照。
在其中一个实施例中,快照组件还包括主节点组件,在kafka向快照组件发送订阅消息之后,该方法还包括:
基于订阅消息,将与订阅消息对应的日志文件存储至主节点组件中,以对日志文件进行数据备份。
在其中一个实施例中,在对日志文件进行数据备份之后,该方法还包括:
业务组件接收数据恢复请求,数据恢复请求包括数据恢复时间点和快照数据标识,业务组件为业务处理组件或业务存储组件;
业务组件基于快照数据标识从主节点组件中获取快照数据,快照数据包括数据集和每个消息分区对应的位置偏移量;
业务组件将数据集加载至工作表中,并重置每个消息分区对应的位置偏移量;
业务组件设置快照触发时间为数据恢复时间点,并从kafka中消费消息数据;
当达到快照触发时间时,业务组件停止消费kafka消息数据得到数据恢复时间点对应的数据快照。
第二方面,本申请提供了一种数据快照装置,该装置包括:
发送模块,用于Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka;
分区模块,用于所述kafka将所述日志文件写入对应的partition消息分区,生成订阅消息并发送至快照组件;
快照生成模块,用于当达到快照触发时间时,所述快照组件基于所述订阅消息对所述日志文件进行快照处理得到数据快照。
第三方面,本申请实施例提供一种计算机设备,包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序,该处理器执行该程序时实现如第一方面的数据快照方法。
第四方面,本申请实施例提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序用于实现如第一方面的数据快照方法。
本申请实施例提供的数据快照方法、装置、设备及存储介质,通过Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka,kafka将日志文件写入对应的消息分区,生成订阅消息并发送至快照组件,当达到快照触发条件时,快照组件基于订阅消息对日志文件进行快照处理生成数据快照。该技术方案中快照组件能够直接基于kafka发送的订阅消息进行快照处理,使得生成数据快照的过程中不影响业务的正常进行,并且具备强大的容灾性,能够通过快照组件进行快照处理时的备份数据快速恢复得到任意时间点的数据切面数据。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1为本申请实施例提供的数据快照的系统架构示意图;
图2为本申请实施例提供的数据快照方法的流程示意图;
图3为本申请另一实施例提供的数据快照方法的流程示意图;
图4为本申请实施例提供的数据快照的结构示意图;
图5为本申请实施例提供的数据恢复方法的流程示意图;
图6为本申请实施例提供的数据恢复方法的结构示意图;
图7为本申请实施例提供的数据快照装置的结构示意图;
图8为本申请实施例提供的数据快照装置的结构示意图;
图9为本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释相关发明,而非对该发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与发明相关的部分。
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
可以理解,数据快照是数据存储的某一时刻的状态记录,根据业务场景的不同,对数据快照的需求也不同,比如需要一份最新的生产数据来做新系统的测试或者提供决策支持和数据分析所用。对于一些场景下,某项业务会有固定的业务“休整期”,例如超市的关门、股票的收盘等,这样有足够的空档期来进行数据快照处理,但是对于一些全时段不停机的业务,如电商业务,业务随时在发生,数据随时在变化,需要在不影响正常业务的情况下实现精确切面数据快照,如每日的账务结算。
目前,相关技术中可以通过执行sql语句将指定表里面的所有数据备份到另一张表中,使得在新的表中形成执行sql命令时的数据备份,也可以通过MySQL数据库自带的备份文件系统dump工具,实现单库单表/单库多表/多库多表的数据快照备份。但是,相关技术在生成快照的过程中,业务对数据的修改将会被阻塞,对于全时段不停机的业务会产生业务影响,生成的快照如果损坏会导致无法恢复,且只能做简单的数据备份,对于不同的业务无法进行定制化的数据处理,可扩展性较差。
基于上述缺陷,本申请提供了一种数据快照方法,与相关技术相比,该快照组件能够直接基于kafka发送的订阅消息进行快照处理,使得生成数据快照的过程中不影响业务的正常进行,并且具备强大的容灾性,能够通过快照组件进行快照处理时的备份数据快速恢复得到任意时间点的数据切面数据,且在数据快照处理时能够根据业务方需求进行数据处理得到对应的数据快照,很大程度上提高了可扩展性。
图1为本申请实施例提供的数据快照方法的实施环境架构图。如图1所示,该实施环境架构包括:终端100和服务器200。
终端100可以为智能手机、笔记本电脑或平板电脑等,本申请对操作系统的类型不做限定,例如可以是包括安卓(Android)操作系统,也可以是苹果(ios)操作系统,还可以是窗口(Windows)操作系统等。终端100上运行有客户端,用户可在终端100的客户端上执行任意业务操作,从而产生业务数据,并将业务数据存储在数据库中。
服务器200可以是一台服务器,也可以是多台服务器组成的服务器集群,或者是一个云计算服务中心。服务器200具有数据处理功能,用于通过Canal组件从数据库中读取日志文件发送至kafka,并通过kafka将日志文件写入对应的消息分区,生成订阅消息发送至快照组件,当达到快照触发条件时,通过快照组件基于订阅消息对日志文件进行快照处理得到数据快照。
终端100与服务器200之间通过有线或无线网络建立通信连接。
为了便于理解和说明,下面通过图2至图9详细阐述本申请实施例提供的数据快照方法、装置、设备及存储介质。
图2所示为本申请实施例提供的数据快照处理方法的流程示意图,该方法应用于数据快照装置,该装置可以是服务器或终端,如图2所示,该方法包括:
S101、Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka。
具体的,上述日志文件可以是一个二进制格式的日志文件,用于记录用户对数据操作的sql语句信息,例如更改数据库表和更改内容的sql语句将会记录到日志文件中,可以使用mysqlbin命令查看二进制日志的内容,该日志文件可以为binlog。
在进行业务处理时,可以将业务数据存储在数据库mysql中。通过Canal组件从数据库中读取日志文件binlog,在读取到日志文件binlog之后,通过Canal组件对日志文件binlog进行解析处理,例如可以是进行协议转换,从而将日志文件binlog解析处理为符合预设格式的日志文件binlog,例如可以解析处理为json格式。然后将符合预设格式的日志文件binlog发送至分布式发布订阅消息系统kafka。
其中,Canal组件在读取日志文件时,可以模拟mysql slave的交互协议,把自己伪装成数据库mysql的slave,从而读取binlog日志文件。可选的,可以给Canal组件配置对应的读取权限,从而读取到配置的读取权限对应的日志文件,一般对所有文件均配置有读取权限,即能够读取所有日志文件。
S102、kafka将日志文件写入对应的消息分区,生成订阅消息并发送至快照组件。
上述kafka是一种高吞吐量的分布式发布订阅消息系统,支持通过kafka服务器或消费机集群来分区消息,可以处理消费者在网站中的所有动作流数据,这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决,kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,为了通过集群来提供实时消息。可以利用kafka开源组件进行多线程并发,实现高性能处理。Canal组件发送至kafka的日志文件可以包括多条消息数据,每条消息数据都有一个类别,这个类别称为topic,用户可以根据自己的业务形态将不同业务类别的消息分别存储到不同topic,物理上不同topic的消息分开存储。Kafka以topic来进行消息管理,每个topic包含一个或多个消息分区,该分区可以为partition消息分区。kafka可以根据性能需求预先配置消息分区partition数量,其中,partition数量越高,则并发程度越高。
Canal组件发送至kafka中的日志文件会通过消息分发至某个topic对应的多个partition消息分区。其中,每个partition消息分区是一个有序的、不可变的队列,按生产顺序存储着每条消息,分区中的每条消息都会分配一个64bit的位置偏移量,即为自增长的有序offset,该offset相当于消息id,用于唯一确定每条消息在partition消息分区内的位置。
在Canal组件将日志文件解析处理为符合预设格式的binlog日志文件并传输至kafka后,kafka根据Canal组件预先配置的分片规则对日志文件进行哈希处理,得到对应的哈希值,其中,分片规则例如可以是按照用户分片,同一分片是可以保证消息处理顺序的,不同分区之间无法严格保序,即要求分片规则根据业务选择互不影响的维度。然后按照哈希值对日志文件进行分区处理,将日志文件存储至对应的partition消息分区,并读取partition消息分区对应的日志文件,可以通过预设的协议将一个partition消息分区或多个partition消息分区对应的日志文件进行处理,生成订阅消息,并将订阅消息发送给快照组件。可选的,可以通过检测按照性能需求配置的消息分区数量,并基于哈希值和消息分区数量,采用预设算法将日志文件进行分区处理,使其存储在对应的partition消息分区。其中,可以根据哈希值对partition数量取模,确定消息分发至哪个分区。例如,提交到哪个partition消息分区是以算法:partition=hash(group_id)%50来计算的,其中,group_id为订阅消息标识,比如:group_id=test_group_1,则partition=hash(test_group_1)%50=28,即将该订阅消息对应的日志文件存储至标识为28的partation消息分区。
本实施例中通过Canal组件从数据库中读取的日志文件发送至kafka,并且通过kafka对日志文件进行消息分发,由于使用了binlog同步模式获取日志文件,进行快照处理生成数据快照的行为对mysql数据存储来说是完全无感知、无影响的,使得数据快照生成的过程中不影响业务的正常运行。
S103、当达到快照触发条件时,快照组件基于订阅消息对日志文件进行快照处理得到数据快照。
具体的,在进行数据快照处理时,可以根据需求进配置快照触发条件,当在某个预设时间点有快照需求时,可以配置快照触发条件为某个预设时间点,当达到某个预设时间点时通过快照组件基于订阅消息自动触发进行快照处理得到对应的数据快照;快照触发条件也可以是通过外部接口主动触发,通过外部接口进行消费数据并产生数据快照,可以将生成的数据快照进行存储。
其中,可以将生成的数据快照存储在数据库中,如可以存储在MongoDB数据库中。
需要说明的是,MongoDB是非关系型数据库,也叫文档数据库,是一种NoSQL的数据库,其可以存放xml、json、bson类型系的数据,以类json文档的格式存储,使用MongoDB查询语句,是同时支持社区和企业版本的数据库。
可选的,作为另一种可实施方式,图3为本实施例提供的基于订阅消息对日志文件进行快照处理得到数据快照方法的流程示意图。如图3所示,上述步骤S103可以包括以下步骤:
S201、快照组件对订阅消息进行解析处理,得到与订阅消息对应的日志文件。
S202、快照组件基于预设的配置文件,对日志文件进行快照处理得到数据快照。
具体的,一般在进行快照服务时,快照组件可以根据kafka中的partition消息分区数量注册对应数量的消息消费者consumer,该消息消费者可以是快照组件中从kafka读取消息的多个业务组件,多个业务组件包括至少一个业务处理组件和至少一个业务存储组件,每个业务处理组件中对应配置有不同的业务类型,每个业务存储组件中对应配置有不同的存储格式。消息消费者从kafka中消费订阅消息,并对订阅消息进行解析,得到与订阅消息对应的日志文件,并根据预先的配置文件判断出该日志文件是否需要处理,其中,该预设的配置文件可以包括针对相同的日志文件进行不同业务处理条件下设置的配置参数。
当需要对日志文件进行处理时,从每个业务处理组件预设的配置子文件中获取至少一个业务处理组件中每个业务处理组件对应的业务类型,并基于业务类型对日志文件进行数据处理,得到每个业务处理组件对应的数据快照,其中,业务处理组件预设的配置子文件可以包括业务类型、业务规则等配置参数;当不需要对日志文件进行处理时,可以从每个业务存储组件预设的配置子文件中获取至少一个业务存储组件中每个业务存储组件对应的存储格式,然后将日志文件按照存储格式进行处理,得到每个业务存储组件对应的数据快照,其中,业务存储组件预设的配置子文件可以包括数据的存储格式、存储规则等配置参数。
其中,根据业务类型和业务规则对日志文件进行处理操作可以是对日志文件进行数据过滤和处理,得到数据快照。例如业务类型为获取数据,业务规则为获取12点的订单数据,则快照组件中的业务处理组件从kafka中消费订阅消息,对订阅消息进行解析,得到的例如是每天的订单数据,对该每天的订单数据进行数据过滤,获取得到12点的订单数据。
进一步地,快照组件在进行数据快照服务时,快照组件可以包括上述业务组件和主节点组件,该主节点组件可以称为Checkpoint branch,业务组件也可称为业务branch,快照组件默认拥有主节点组件Checkpoint branch实时监听并保存所有数据,即会消费从kafka过来的每个partition消息分区的数据,将每个partition消息分区的日志文件存储至主节点组件中,从而实现日志文件等全量数据的基础备份。业务branch用于对kafka中某个partition消息分区的日志文件进行快照处理后得到数据快照。业务branch还可以自定义设置快照触发时间,如快照触发时间为五点,即在五点时触发快照操作。
另外,快照组件还可以根据业务需要增加业务组件,即业务branch,其中,主节点组件Checkpoint branch的数据是各业务branch的父集,各业务branch之间是配置独立、定制独立、处理单元独立的。
其中,主节点组件Checkpoint branch和业务branch中均存储有数据快照表,该数据快照表中包括快照标识、存储地址、快照生成时间、数据集、kafka中各partition分区对应的offset等数据切面的信息。
需要说明的是,主节点组件Checkpoint branch与业务组件Biz branch具有如下区别:Biz branch的数据是Checkpoint branch的子集,包括数据量维度或/和属性量维度;业务组件Biz branch的快照触发的时间参照分两级,第一级是kafka时间戳Kfktimestamp,第二级是现实时间;CheckPoint branch并不关心kafka时间戳Kfk timestamp,只在某些时候(并不需要准确的时间点)生成快照,用于容灾和replay;主节点组件CheckPoint branch的镜像理论上长时间保留,业务组件Biz branch的镜像只保留上一个时间点。
本实施例中通过设置多业务组件,使得各业务组件能够独立定制需要的数据,且各业务间数据隔离,互不影响,进一步提高了业务数据处理的可扩展性。
示例性地,如图4所示,在进行业务操作时产生业务数据,该业务数据以binlog日志文件的形式存储在mysql数据库中,Canal组件从存储业务数据的mysql中读取binlog日志文件,并将binlog日志文件解析处理为符合预设格式的binlog日志文件,将符合预设格式的binlog日志文件传输至kafka中,kafka根据预先配置的分片规则对日志文件进行哈希处理,得到对应的哈希值,然后按照哈希值将日志文件进行分区处理,存储至kafka中对应的多个partition消息分区,kafka读取partition消息分区中对应的日志文件,基于预设协议将一个或多个partition消息分区中的日志文件进行处理生成订阅消息,并将订阅消息发送至快照组件Polaroid。
Polaroid快照组件从kafka中消费订阅消息,当达到快照触发条件时,停止从kafka中消费订阅消息,并对订阅消息进行解析,得到对应的日志文件,然后根据预设的配置文件判断该日志文件是否需要进行同步存储,当判断出日志文件同步存储时,从业务存储组件预设的配置子文件中获取对应的存储格式,并将日志文件按照业务存储组件对应的存储格式进行处理,得到对应的数据快照;当不需要对该日志文件进行同步存储时,从业务处理组件预设的配置子文件中获取业务类型,并基于业务类型对日志文件进行数据处理,得到数据快照,将生成的数据快照存储在MongoDB数据库中。
本实施例中快照组件能够直接基于kafka发送的订阅消息进行快照处理,使得生成数据快照的过程中不影响业务的正常进行,并通过对快照组件中设置有多个业务组件,能够使得各业务组件能够独立定制需要的数据,且各业务间数据隔离,互不影响,从而得到符合业务需求的数据快照。
进一步地,快照组件具有很强的容灾能力。只要存在一个未被破坏的镜像,且kafka消息存储完好,就可以重做该镜像后的所有镜像并恢复数据,称这种重做/恢复的过程为Replay。
图5为本实施例提供的进行数据恢复方法的流程示意图。如图5所示,该方法包括:
S301、业务组件接收数据恢复请求,数据恢复请求包括数据恢复时间点和快照数据标识,该业务组件为业务处理组件或业务存储组件。
具体的,当需要对恢复某个时间点的数据时,通过业务组件接收数据恢复请求,该数据恢复请求中包括数据恢复时间和快照数据标识。其中,数据恢复时间可以是任意时间点,如0点。快照数据标识为主节点组件Checkpoint branch备份的快照数据工作表中对应的标识,用于唯一标识某个快照切面的数据。
S302、业务组件基于快照数据标识从主节点组件中获取快照数据,快照数据包括数据集和每个消息分区对应的位置偏移量。
业务组件响应于该数据恢复请求,基于快照数据标识从主节点组件中获取快照数据,其中,该快照数据可以包括数据集以及kafka中每个消息分区对应的位置偏移量offset。数据集中保存的是从kafka中消费的日志文件。
S303、业务组件将数据集加载至工作表中,并重置每个消息分区对应的位置偏移量。
S304、业务组件设置快照触发时间为数据恢复时间点,并从kafka中消费消息数据。
S305、当达到快照触发时间时,业务组件停止从kafka中消费消息数据得到数据恢复时间点对应的数据快照。
业务组件将数据集加载至自身的工作表中,并重置每个消息分区对应的位置偏移量offset,然后设置快照触发时间为数据恢复时间点,并从kafka中消费消息数据,当达到快照触发时间时,停止从kafka中消费消息数据得到数据恢复时间点对应的数据快照。
示例性地,如图6所示,例如业务组件Branch A接收数据恢复请求,该数据恢复请求为需要恢复3月3日的0点对应的数据快照,而当前可用的数据快照为主节点组件Checkpoint branch备份的3月1日的checkpoint镜像数据,该checkpoint镜像数据包括数据集image collection以及每个patition消息分区对应的offset,例如包括P1:offset,P2:offset,P3:offset。
假设BranchA的数据快照触发时间在每日0点触发,在进行数据恢复的过程是将3月1日的checkpoint镜像数据中的数据集加载至该业务组件BranchA中的工作表中,并根据kafka的自有能力调整每个patition消息分区对应的位置偏移量offset,即重置位置偏移量offset。将快照下一触发快照的时间点设置为3月2日0点,业务组件branchA在从kafka中消费数据时,将快照触发时间与kafka中每个消息自有的时间戳timestamp进行比较。
当kafka中每个消息自有的kafka时间戳timestamp到达3月2号之后(过零点之后),即消费kafka消息的时间戳在3月2日0点以后,且所有的patition消息分区均到达该时间节点时,业务组件branchA停止消费消息会打出3月2日0点的数据快照。同理,继续设置下一快照触发时间为3月3日的零点,消费kafka消息到kafka时间戳为3月3日0点,到达3月3日0点之后打出3月3日0点的数据快照,从而完成对3月3日0点的数据恢复,进一步地,还可以设置下一快照触发时间为3月4日0点,进而恢复得到3月4日0点的数据快照,在数据恢复完成后,可以继续正常的业务数据同步。
本实施例中由于使用主节点组件Checkpoint branch进行了基础备份,能够通过该完整的基础备份数据迅速恢复数据,具有极强的数据容灾性,能够恢复任意时间点的数据。
应当注意,尽管在附图中以特定顺序描述了本发明方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。相反,流程图中描绘的步骤可以改变执行顺序。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。
另一方面,图7为本申请实施例提供的一种数据快照装置的结构示意图。该装置可以为终端设备内的装置,如图7所示,该装置700包括:
发送模块710,用于Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka;
分区模块720,用于kafka将日志文件写入对应的消息分区,生成订阅消息并发送至快照组件;
快照生成模块730,用于当达到快照触发时间时,快照组件基于订阅消息对日志文件进行快照处理得到数据快照。
可选的,可以参见图8,上述分区模块720,包括:
处理单元721,用于kafka根据预先配置的分片规则对日志文件进行哈希处理,得到哈希值;
存储单元722,用于kafka按照哈希值将日志文件进行分区处理,存储至对应的消息分区;
生成单元723,用于kafka读取所述消息分区对应的日志文件,生成订阅消息;
发送单元724,用于kafka将订阅消息发送至快照组件。
可选的,上述快照生成模块730,包括:
解析单元731,用于快照组件对订阅消息进行解析处理,得到订阅消息对应的日志文件;
快照单元732,用于快照组件基于预设的配置文件,对日志文件进行快照处理得到数据快照。
可选的,上述快照单元732,具体用于:
快照组件基于预设的配置文件判断日志文件是否需要处理,配置文件包括针对相同的日志文件进行不同业务处理条件下设置的配置参数;
当对日志文件需要处理时,获取至少一个业务处理组件中每个业务处理组件对应的业务类型;
基于业务类型对日志文件进行数据处理,得到每个所述业务处理组件对应的数据快照。
可选的,上述快照单元732,具体用于:
当对日志文件不需要处理时,获取至少一个业务存储组件中每个业务存储组件对应的存储格式;
将日志文件按照存储格式进行处理,得到每个业务存储组件对应的数据快照。
可选的,上述装置还用于:
基于订阅消息,将与订阅消息对应的日志文件存储至主节点组件中,以对日志文件进行数据备份。
可选的,上述装置还用于:
业务组件接收数据恢复请求,数据恢复请求包括数据恢复时间点和快照数据标识,业务组件为业务处理组件或业务存储组件;
业务组件基于快照数据标识从主节点组件中获取快照数据,快照数据包括数据集和每个消息分区对应的位置偏移量;
业务组件将数据集加载至工作表中,并重置每个消息分区对应的位置偏移量;
业务组件设置快照触发时间为数据恢复时间点,并从kafka中消费消息数据;
当达到快照触发时间时,业务组件停止从kafka中消费消息数据得到数据恢复时间点对应的数据快照。
本申请实施例提供的数据快照装置,通过Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka,kafka将日志文件写入对应的消息分区,生成订阅消息并发送至快照组件,当达到快照触发条件时,快照组件基于订阅消息对日志文件进行快照处理生成数据快照。该技术方案中快照组件能够直接基于kafka发送的订阅消息进行快照处理,使得生成数据快照的过程中不影响业务的正常进行,并且具备强大的容灾性,能够通过快照组件进行快照处理时的备份数据快速恢复得到任意时间点的数据切面数据。
下面参考图9,图9为本申请实施例的终端设备或服务器的计算机系统的结构示意图。
如图9所示,计算机系统1000包括中央处理单元(CPU)1001,其可以根据存储在只读存储器(ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(RAM)1003中的程序而执行各种适当的动作和处理。在RAM1003中,还存储有系统1000操作所需的各种程序和数据。CPU1001、ROM1002以及RAM1003通过总线1004彼此相连。输入/输出(I/O)接口1006也连接至总线1004。
以下部件连接至I/O接口1005:包括键盘、鼠标等的输入部分1006;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1007;包括硬盘等的存储部分1008;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1006。可拆卸介质1011,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器1010上,以便于从其上读出的计算机程序根据需要被安装入存储部分1008。
特别地,根据本申请的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本申请的实施例包括一种计算机程序产品,其包括承载在机器可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分1003从网络上被下载和安装,和/或从可拆卸介质1011被安装。在该计算机程序被中央处理单元(CPU)1001执行时,执行本申请的系统中限定的上述功能。
需要说明的是,本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。
附图中的流程图和框图,图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中,例如,可以描述为:一种处理器,包括:发送模块、分区模块及快照生成模块。其中,这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定,例如,发送模块还可以被描述为“用于Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka”。
作为另一方面,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中的。上述计算机可读存储介质存储有一个或者多个程序,当上述前述程序被一个或者一个以上的处理器用来执行描述于本申请的数据快照方法:
Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka;
所述kafka将所述日志文件写入对应的消息分区,生成订阅消息并发送至快照组件;
当达到快照触发条件时,所述快照组件基于所述订阅消息对所述日志文件进行快照处理得到数据快照。
综上所述,本申请实施例提供的数据快照方法、装置、设备及存储介质,通过Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka,kafka将日志文件写入对应的消息分区,生成订阅消息并发送至快照组件,当达到快照触发条件时,快照组件基于订阅消息对日志文件进行快照处理生成数据快照。该技术方案中快照组件能够直接基于kafka发送的订阅消息进行快照处理,使得生成数据快照的过程中不影响业务的正常进行,并且具备强大的容灾性,能够通过快照组件进行快照处理时的备份数据快速恢复得到任意时间点的数据切面数据。
以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本申请中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离所述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
Claims (10)
1.一种数据快照方法,其特征在于,包括:
Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka;
所述kafka将所述日志文件写入对应的消息分区,生成订阅消息并发送至快照组件;
当达到快照触发条件时,所述快照组件基于所述订阅消息对所述日志文件进行快照处理得到数据快照。
2.根据权利要求1所述的方法,其特征在于,所述kafka将所述日志文件写入对应的消息分区,生成订阅消息并发送至快照组件,包括:
所述kafka根据预先配置的分片规则对日志文件进行哈希处理,得到哈希值;
所述kafka按照哈希值将所述日志文件进行分区处理,存储至对应的消息分区;
所述kafka读取所述消息分区对应的日志文件,生成订阅消息;
所述kafka将所述订阅消息发送至所述快照组件。
3.根据权利要求1所述的方法,其特征在于,所述快照组件基于所述订阅消息对所述日志文件进行快照处理得到数据快照,包括:
所述快照组件对所述订阅消息进行解析处理,得到与所述订阅消息对应的日志文件;
所述快照组件基于预设的配置文件,对所述日志文件进行快照处理得到数据快照。
4.根据权利要求3所述的方法,其特征在于,所述快照组件包括至少一个业务处理组件和至少一个业务存储组件,所述快照组件基于预设的配置文件,对所述日志文件进行快照处理得到数据快照,包括:
所述快照组件基于预设的配置文件判断所述日志文件是否需要处理,所述配置文件包括针对相同的日志文件进行不同业务处理条件下设置的配置参数;
当对所述日志文件需要处理时,获取所述至少一个业务处理组件中每个业务处理组件对应的业务类型;
基于所述业务类型对所述日志文件进行数据处理,得到所述每个所述业务处理组件对应的数据快照。
5.根据权利要求4所述的方法,其特征在于,在所述快照组件基于预设的配置文件判断所述日志文件是否需要处理之后,所述方法还包括:
当对所述日志文件不需要处理时,获取所述至少一个业务存储组件中每个业务存储组件对应的存储格式;
将所述日志文件按照所述存储格式进行处理,得到所述每个业务存储组件对应的数据快照。
6.根据权利要求4所述的方法,其特征在于,所述快照组件还包括主节点组件,在所述kafka向所述快照组件发送订阅消息之后,所述方法还包括:
基于所述订阅消息,将与所述订阅消息对应的日志文件存储至所述主节点组件中,以对所述日志文件进行数据备份。
7.根据权利要求6所述的方法,其特征在于,在对所述日志文件进行数据备份之后,所述方法还包括:
业务组件接收数据恢复请求,所述数据恢复请求包括数据恢复时间点和快照数据标识,所述业务组件为业务处理组件或业务存储组件;
业务组件基于所述快照数据标识从所述主节点组件中获取快照数据,所述快照数据包括数据集和每个消息分区对应的位置偏移量;
业务组件将所述数据集加载至工作表中,并重置所述每个消息分区对应的位置偏移量;
业务组件设置快照触发时间为数据恢复时间点,并从所述kafka中消费消息数据;
当达到所述快照触发时间时,所述业务组件停止从所述kafka中消费消息数据得到所述数据恢复时间点对应的数据快照。
8.一种数据快照装置,其特征在于,所述装置包括:
发送模块,用于Canal组件将从数据库中读取的日志文件发送至分布式发布订阅消息系统kafka;
分区模块,用于所述kafka将所述日志文件写入对应的消息分区,生成订阅消息并发送至快照组件;
快照生成模块,用于当达到快照触发时间时,所述快照组件基于所述订阅消息对所述日志文件进行快照处理得到数据快照。
9.一种计算机设备,其特征在于,所述计算机设备包括存储器、处理器以及存储在存储器并可在处理器上运行的计算机程序,所述处理器用于执行所述程序时实现如权利要求1-7任一项所述的方法。
10.一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序用于实现如权利要求1-7任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010850323.5A CN114077518A (zh) | 2020-08-21 | 2020-08-21 | 数据快照方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010850323.5A CN114077518A (zh) | 2020-08-21 | 2020-08-21 | 数据快照方法、装置、设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114077518A true CN114077518A (zh) | 2022-02-22 |
Family
ID=80282544
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010850323.5A Pending CN114077518A (zh) | 2020-08-21 | 2020-08-21 | 数据快照方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114077518A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114816845A (zh) * | 2022-04-06 | 2022-07-29 | 在线途游(北京)科技有限公司 | 一种基于MongoDB的快速数据回滚方法及装置 |
CN115604290A (zh) * | 2022-12-13 | 2023-01-13 | 云账户技术(天津)有限公司(Cn) | Kafka消息执行方法、装置、设备及存储介质 |
CN114816845B (zh) * | 2022-04-06 | 2024-05-10 | 在线途游(北京)科技有限公司 | 一种基于MongoDB的快速数据回滚方法及装置 |
-
2020
- 2020-08-21 CN CN202010850323.5A patent/CN114077518A/zh active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114816845A (zh) * | 2022-04-06 | 2022-07-29 | 在线途游(北京)科技有限公司 | 一种基于MongoDB的快速数据回滚方法及装置 |
CN114816845B (zh) * | 2022-04-06 | 2024-05-10 | 在线途游(北京)科技有限公司 | 一种基于MongoDB的快速数据回滚方法及装置 |
CN115604290A (zh) * | 2022-12-13 | 2023-01-13 | 云账户技术(天津)有限公司(Cn) | Kafka消息执行方法、装置、设备及存储介质 |
CN115604290B (zh) * | 2022-12-13 | 2023-03-24 | 云账户技术(天津)有限公司 | Kafka消息执行方法、装置、设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8645323B2 (en) | Large volume data replication using job replication | |
US8364636B2 (en) | Real time data replication | |
US10726042B2 (en) | Replication control using eventually consistent meta-data | |
US20150261766A1 (en) | Method and apparatus for determining a range of files to be migrated | |
US20180239617A1 (en) | Big data pipeline management within spreadsheet applications | |
CN111338834B (zh) | 数据存储方法和装置 | |
CN114722119A (zh) | 数据同步方法及系统 | |
CN104750755A (zh) | 一种数据库主备切换后的数据回补方法及系统 | |
CN111178849A (zh) | 线性流程引擎实现方法、装置、设备及存储介质 | |
CN111144926A (zh) | 业务请求处理方法、装置、系统、电子设备及可读介质 | |
CN111435367A (zh) | 知识图谱的构建方法、系统、设备及存储介质 | |
US9146816B2 (en) | Managing system image backup | |
CN115858488A (zh) | 基于数据治理的平行迁移方法、装置及可读介质 | |
CN115408391A (zh) | 一种数据库表变更方法、装置、设备和存储介质 | |
CN114077518A (zh) | 数据快照方法、装置、设备及存储介质 | |
US10552419B2 (en) | Method and system for performing an operation using map reduce | |
US8856070B2 (en) | Consistent replication of transactional updates | |
US20180239749A1 (en) | Techniques for asynchronous execution of computationally expensive local spreadsheet tasks | |
CN113760846A (zh) | 一种数据处理方法和装置 | |
CN111581227A (zh) | 事件推送方法、装置、计算机设备及存储介质 | |
CN107277108B (zh) | 一种区块链的节点处的消息处理方法、装置及系统 | |
CN110941658A (zh) | 一种数据导出方法、装置、服务器及存储介质 | |
US20220019465A1 (en) | Systems and methods for batch job execution in clustered environments | |
US11675931B2 (en) | Creating vendor-neutral data protection operations for vendors' application resources | |
CN112463887A (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 | ||
TA01 | Transfer of patent application right |
Effective date of registration: 20220329 Address after: 410000 Room 301, floor 3, building 6, Xiangjiang fund Town, No. 188 Binjiang Road, guanshaling street, Yuelu District, Changsha City, Hunan Province Applicant after: Hunan Weibu Information Technology Co.,Ltd. Address before: 410000 Room 501, building 3, Xincheng Science Park, No. 588, Yuelu West Avenue, high tech Development Zone, Changsha, Hunan Applicant before: HUNAN FUMI INFORMATION TECHNOLOGY CO.,LTD. |
|
TA01 | Transfer of patent application right |