CN114116908A - 一种数据管理方法、装置及电子设备 - Google Patents
一种数据管理方法、装置及电子设备 Download PDFInfo
- Publication number
- CN114116908A CN114116908A CN202111451322.4A CN202111451322A CN114116908A CN 114116908 A CN114116908 A CN 114116908A CN 202111451322 A CN202111451322 A CN 202111451322A CN 114116908 A CN114116908 A CN 114116908A
- Authority
- CN
- China
- Prior art keywords
- data
- historical data
- historical
- query
- warehouse
- 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
- 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/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- 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)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请涉及数据分析领域,尤其涉及一种数据管理方法、装置及电子设备,应用于金融系统。该方法包括:基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据;其中,所述历史数据指示数据库中更新前以及更新后的数据信息;利用流数据处理框架分批提取所述流处理平台中的历史数据,并保存在对应的数据仓储中;基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,并在所述目标数据仓储中进行所述第二历史数据的查询。通过上述方法可以解决现有技术中,金融系统历史数据查询效率低的问题。
Description
技术领域
本申请涉及数据分析领域,尤其涉及一种数据管理方法、装置及电子设备。
背景技术
由于用户及服务种类的增加,目前金融行业的交易数据量大且增长速度快。基于此,产生的历史数据也同时具备了数据量大且增长速度快的特点。例如,手机号码、居住地址、经营地址、办公地址、兴趣爱好、客户标签、客户分类、基金持仓、基金收益等数据,可能每天都在发生变化。针对历史数据的存储目前有以下两种方法:
(一)针对数据库中的数据,将删除,更改,增加等更新方式的更新的数据单独记录一张表,该表以及数据库中的数据统称为历史数据。该方法形成的历史数据与应用的耦合度高,即当需要提取或者分析任一更新的数据内容时,都需要开发相应的应用以实现数据的提取或者分析。
(二)针对数据库中的数据,直接记录删除,更改,增加等更新方式的更新的数据,不再单独生成一张表,数据库中的所有数据统称为历史数据。该方法形成的历史数据依赖数据库触发器实现。
为了保证系统提供的服务质量,保证交易的响应时间,根据上述两种方法存储的历史数据均需要定期清理,随着银行金融服务种类增加,以及用户的增加,历史数据的数量以及增长越来越多,这导致金融系统历史数据的查询效率越来越低。因此,现有技术中存在金融系统历史数据查询效率低的问题。
发明内容
本申请提供一种数据管理方法、装置及电子设备,用以解决现有技术中,金融系统历史数据查询效率低的问题。
第一方面,本申请提供一种数据管理方法,所述方法包括:
基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据;其中,所述历史数据指示数据库中更新前以及更新后的数据信息;
分批提取所述第一历史数据,并保存在对应的数据仓储中;
基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,并在所述目标数据仓储中进行所述第二历史数据的查询。
上述本申请实施例所提供的方法,通过将历史数据实时同步、提取到对应的数据仓储,进而根据指定使用场景确定目标数据仓储,并查询第二历史数据;达到了提高历史数据查询效率的目的。
一种可能的实施方式,所述历史数据包括更新数据对应的元数据、更新的数据类型、更新的数据的数据库信息;其中,所述更新数据包括删除的数据、增加的数据、以及修改前和修改后的数据;所述元数据为所述删除的数据、增加的数据、以及修改前和修改后的数据中的至少一项,以及更新数据对应的更新时间。
一种可能的实施方式,所述基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据,包括:
采集所述历史数据到Kafka中;
使用kafka针对所述历史数据进行实时更新、保存,得到第一历史数据。
一种可能的实施方式,所述分批提取所述第一历史数据,并保存在对应的数据仓储中,包括:
利用Spark Streaming分批提取所述第一历史数据,并保存在对应的数据仓储。
一种可能的实施方式,所述数据仓储包括Hive,Hbase,ElasticSearch,则所述利用Spark Streaming分批提取Kafka中的历史数据,并保存在对应的数据仓储中,包括:
分别使用独立且与所述数据仓储对应的Spark Streaming提取Kafka中历史数据,并分别对应保存在Hive,Hbase,ElasticSearch中。
上述分别使用独立且与所述数据仓储对应的Spark Streaming提取Kafka中历史数据,达到了提高提取效率的目的。
一种可能的实施方式,所述基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,包括:
当所述指定使用场景为聚合查询或者模糊查询时,确定所述目标数据仓储为ElasticSearch;
当所述指定使用场景为实时查询时,确定所述目标数据仓储为Hbase;
当所述指定使用场景为批量查询时,确定所述目标数据仓储为Hive。
将历史数据存储在上述数据仓储中,提升了历史数据的存储量;并且避免了在提取、使用历史数据时单独开发程序应用,从而达到了应用解耦的目的。
第二方面,本申请还提供一种数据管理的装置,所述装置包括:
采集单元:用于基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据;其中,所述历史数据指示数据库中更新前以及更新后的数据信息;
提取单元:用于分批提取所述第一历史数据,并保存在对应的数据仓储中;
查询单元:用于基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,并在所述目标数据仓储中进行所述第二历史数据的查询。
一种可能的实施方式,所述历史数据包括更新数据对应的元数据、更新的数据类型、更新的数据的数据库信息;其中,所述更新数据包括删除的数据、增加的数据、以及修改前和修改后的数据;所述元数据为所述删除的数据、增加的数据、以及修改前和修改后的数据中的至少一项,以及更新数据对应的更新时间。
一种可能的实施方式,所述采集单元具体用于采集所述历史数据到Kafka中;使用kafka针对所述历史数据进行实时更新、保存,得到第一历史数据。
一种可能的实施方式,所述提取单元具体用于利用Spark Streaming分批提取Kafka中的历史数据,并保存在对应的数据仓储。
一种可能的实施方式,所述数据仓储包括Hive,Hbase,ElasticSearch,则提取单元还用于,分别使用独立且与所述数据仓储对应的Spark Streaming提取Kafka中历史数据,并分别对应保存在Hive,Hbase,ElasticSearch中。
一种可能的实施方式,所述查询单元具体用于当所述指定使用场景为聚合查询或者模糊查询时,确定所述目标数据仓储为ElasticSearch;当所述指定使用场景为实时查询时,确定所述目标数据仓储为Hbase;当所述指定使用场景为批量查询时,确定所述目标数据仓储为Hive。
第三方面,本申请还提供一种电子设备,包括:
存储器,用于存放计算机程序;
处理器,用于执行所述存储器上所存放的计算机程序时,如第一方面及任一种可能的实施方式所述的方法。
第四方面,本申请还提供一种计算机可读存储介质,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现如第一方面及任一种可能的实施方式所述的方法。
第五方面,本申请提供了一种计算机程序产品,当所述计算机程序产品在计算机上运行时,使得所述计算机执行如第一方面及任一种可能的实施方式所述的方法。
附图说明
图1为本申请提供的一种数据管理方法的流程图;
图2为本申请提供的一种数据管理装置的结构示意图;
图3为本申请提供的一种数据管理电子设备的结构示意图。
具体实施方式
针对现有技术中,金融系统历史数据查询效率低的问题,本申请实施例提出一种数据管理方法,将历史数据实时更新、保存;并分批提取到不同的数据仓储中保存,用以在不同的使用场景中查询历史数据,提供不同种类的服务,从而提高了历史数据的查询效率。
需要说明的是,本申请技术方案中对数据的获取、存储、使用、处理等均符合国家法律法规的相关规定。
以下针对本申请实施例中所使用的技术术语进行解释:
Hbase:一个分布式的开历史数据库。
Hive:是基于Hadoop的数据仓库工具,用于数据提取、转化、加载。是一种可以存储、查询、分析存在Hadoop中数据的大规模数据组件。
Kafka:一种高吞吐量的分布式发布订阅消息系统。
SparkStreaming:在Spark Core API的基础上,实现的可扩展、高吞吐、可容错的实时数据流处理引擎。
数据迁移服务组件(OMS):是一个分布式数据库自带的采集数据库维护记录日志的工具,记录了数据新增、修改前后、删除前的数据明细,以及修改时间、数据主键、数据库、修改序号等信息。
分布式数据库:由位于不同地点的多台计算器服务器通过网络连接所组成的,一个完整的、全局的逻辑上集中、物理上分布的大型数据库。
为了更好的理解上述技术方案,下面通过附图以及具体实施例对本申请技术方案做详细的说明,应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明,而不是对本申请的技术方案的限定,在不冲突的情况下,本申请实施例以及实施例中的技术特征可以相互组合。
请参考图1,本申请实施例提供一种数据管理方法,用以解决金融系统历史数据查询效率低的问题。该方法具体包括以下实现步骤:
步骤101:基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据。
其中,历史数据指示数据库中更新前以及更新后的数据信息。本申请实施例中数据库包括OceanBase、Oracle、Mysql等。
具体地,历史数据包括更新数据对应的元数据,更新的数据类型,更新的数据的数据库信息。其中,元数据为所述删除的数据、增加的数据、以及修改前和修改后的数据中的至少一项,以及更新数据对应的更新时间。所述删除的数据、增加的数据、以及修改前和修改后的数据统称为更新数据。由于数据迁移服务组件(OMS)输出格式为json格式,则历史数据的格式为json。
数据库中的历史数据主要包括以下几种类型:
(1)客户证件基本信息(证件名称、号码、类型、到期日期、办理机构渠道、有效标记);
(2)客户基本信息(客户出生日期、职业、学历、毕业学校、AUM等);
(3)客户电话基本信息(客户电话号码、用途、办理渠道等);
(4)客户合约基本信息(合约类型、开户渠道、合约状态等);
(5)客户地址信息(户籍地址、办公地址、居住地址、营业地址、海外地址等);
(6)客户机构信息(开户机构、维护机构等);
(7)客户关系基本信息(关系信息、关系人信息等);
(8)客户其他信息(标签信息、产品信息、合约地址信息、营销信息、纪念日等)。
本申请实施例中设置,采集所述历史数据到Kafka中;使用kafka针对所述历史数据进行实时更新、保存,得到第一历史数据。基于Kafka组件可以实现高吞吐量数据的订阅以及发布,在得到历史数据的同时可以将历史数据以更新时间顺序转存在Kafka组件。其中,修改前和修改后的数据保存为一组数据,新增保存为一组数据。
具体地,在Kafka中将更新频率超过第一阈值或者提取频率超过第二阈值的历史数据分别设置一个独立的表;将更新频率不超过第一阈值,或者提取频率不超过第二阈值的历史数据设置为一个表,以便于合理分配系统资源(CPU内存等)。例如,客户电话基本信息,客户地址信息是更新频率比较高的,则分别设置,各自作为一个独立的数据表;而对于客户基本信息(客户出生日期、职业、学历、毕业学校、AUM等),客户证件基本信息(证件名称、号码、类型、到期日期、办理机构渠道、有效标记)等不经常发生更新的数据,统一设置在同一个数据表中。每个表中设置Topic,包括更新,提取,偏移量。其中,更新指历史数据的生产;提取指历史数据的消费,用于历史数据的加工和利用;偏移量指发生变化的历史数据的编号。接着,以客户为维度在Topic设置分区,避免同一个客户的数据多次修改记录在同一个分区,或者多个客户的数据在一个分区中导致的数据混乱,即保证同一个客户的数据有序。
当在设定时间范围内,数据库更新的历史数据量超过第三阈值,或者更新频率超过第四阈值时,一个数据迁移服务组件不能完成历史数据的采集,则可以设置至少两个数据迁移服务组件采集历史数据在一个Kafka组件中,从而实现了数据采集和接入资源部署的相互隔离。
同时,因为Kafka储量大,且转存的数据周期默认为7天,当历史数据的每秒传输历史数据个数(TPS)达到峰值时,即数据生产达到峰值时,仍然可以确保不影响数据的提取,从而起到了数据销峰的作用。
步骤102:分批提取所述第一历史数据,并保存在对应的数据仓储中。
具体地,本申请实施例中利用Spark Streaming分批提取所述第一历史数据,并保存在对应的数据仓储。其中,数据仓储包括Hive,Hbase,Elastic Search,则每个仓储对应1个Spark Streaming进行历史数据的提取,即分别使用独立且与所述数据仓储对应的SparkStreaming提取Kafka中历史数据,并分别对应保存在Hive,Hbase,ElasticSearch中。
分批提取Kafka组件中的历史数据的方式可以采用以下2种可实施方式:
(1)根据历史数据量与系统配置,或者设定时间范围内的每秒传输历史数据个数(TPS)的峰值与系统配置,设置每批次的并发提取数,以及提取批数。
(2)根据数据更新的时间间隔以及系统配置,设置每批次的并发提取数,以及提取批数。
当处于背压模式时,则一次性将历史数据提取。背压模式指,历史数据在Kafka中存储量超过设定阈值。
对于提取成功的历史数据,记录对应的偏移量,从而避免了数据丢失和重复提取。即当断电等特殊情况发生时,Kafka可以基于偏移量记录数据上次数据提取结束位置,所以在重新进行数据提取时,Kafka可以避免重复提取的情况发生。基于Hbase低延迟的特点,本申请实施例中使用Hbase管理提取数据的偏移量。对于提取不成功的信息,标记为异常数据。
需要说明的是,为避免消息丢失,至少为Kafka设置两个副本。当Kafka中某个Topic的服务器发生损坏,则会从副本中再选举一个作为服务器提供服务。
完成上述提取后,利用Spark Streaming存储到数据仓储。
步骤103:基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,并在所述目标数据仓储中进行所述第二历史数据的查询。
本申请实施例中根据使用场景提供以下3种数据仓储,分别为Hive,Hbase,ElasticSearch,避免了涉及不同使用场景的数据提取时,单独进行应用的开发,从而实现了数据与应用的解耦合。
(1)指定使用场景为聚合查询或者模糊查询时,确定所述目标数据仓储为ElasticSearch;
ElasticSearch的查询特点包括:扩展性能好,查询时效快,写入速度快,但一致性、联(join)查询较差的特点,该数据仓储使用在聚合查询或者模糊查询场景中。即确定ElasticSearch与聚合查询或者模糊查询使用场景相对应。
(2)当所述指定使用场景为实时查询时,确定所述目标数据仓储为Hbase;
Hbase的查询特点包括:存储量大,查询快,写入速度快的特点,该数据仓储用于发布交易实时查询历史数据明细使用,包括维护的时间、渠道、更改机构、柜员等在线业务场景。即确定Hbase与实时查询的使用场景相对应。
(3)当所述指定使用场景为批量查询时,确定所述目标数据仓储为Hive。
Hive的查询特点包括:存储量大,但查询以及写入效率低下的特点,该数据仓储用于用户客户历史数据、报表、客户历史流水查询、关键信息变动记录等批量场景使用。
因此,当需要查询历史数据提供服务时,可以根据具体使用场景确定相应的数据仓储完成查询,从而提高了历史数据的查询效率。
在将历史数据根据上述操作分别存储在Hive,Hbase,ElasticSearch中,还可以通过客户确认起到保障信息安全的作用。具体地,每当历史数据更新,可以使用Kafka以及Spark Streaming在数据仓储中对应更新,即可以通过上述数据仓储完成模糊查询和精准查询,将更新的结果发函给客户(海内外)确认提醒,从而起到保障客户信息安全的作用。
基于同一发明构思,本申请实施例中提供一种数据管理的装置,该装置与前述图1所示数据管理的方法对应,该装置的具体实施方式可参见前述方法实施例部分的描述,重复之处不再赘述,参见图2,该装置包括:
采集单元201:用于基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据。其中,所述历史数据指示数据库中更新前以及更新后的数据信息。
具体地,采集所述历史数据到Kafka中;使用kafka针对所述历史数据进行实时更新、保存,得到第一历史数据。所述历史数据包括更新数据对应的元数据、更新的数据类型、更新的数据的数据库信息;其中,所述更新数据包括删除的数据、增加的数据、以及修改前和修改后的数据;所述元数据为所述删除的数据、增加的数据、以及修改前和修改后的数据中的至少一项,以及更新数据对应的更新时间。
提取单元202:用于分批提取所述第一历史数据,并保存在对应的数据仓储中。
具体地,利用Spark Streaming分批提取Kafka中的历史数据,并保存在对应的数据仓储。
所述数据仓储包括Hive,Hbase,ElasticSearch,则提取单元202还用于,分别使用独立且与所述数据仓储对应的Spark Streaming提取Kafka中历史数据,并分别对应保存在Hive,Hbase,ElasticSearch中。
查询单元203:用于基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,并在所述目标数据仓储中进行所述第二历史数据的查询。
具体地,当所述指定使用场景为聚合查询或者模糊查询时,确定所述目标数据仓储为ElasticSearch;当所述指定使用场景为实时查询时,确定所述目标数据仓储为Hbase;当所述指定使用场景为批量查询时,确定所述目标数据仓储为Hive。
基于与上述数据管理方法相同的发明构思,本申请实施例中还提供了一种电子设备,所述电子设备可以实现前述一种数据管理方法的功能,参考图3,所述电子设备包括:
至少一个处理器301,以及与至少一个处理器301连接的存储器302,本申请实施例中不限定处理器301与存储器302之间的具体连接介质,图3中是以处理器301和存储器302之间通过总线300连接为例。总线300在图3中以粗线表示,其它部件之间的连接方式,仅是进行示意性说明,并不引以为限。总线300可以分为地址总线、数据总线、控制总线等,为便于表示,图3中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。或者,处理器301也可以称为控制器,对于名称不做限制。
在本申请实施例中,存储器302存储有可被至少一个处理器301执行的指令,至少一个处理器301通过执行存储器302存储的指令,可以执行前文论述数据管理方法。处理器301可以实现图2所示的装置中各个模块的功能。
其中,处理器301是该装置的控制中心,可以利用各种接口和线路连接整个该控制设备的各个部分,通过运行或执行存储在存储器302内的指令以及调用存储在存储器302内的数据,该装置的各种功能和处理数据,从而对该装置进行整体监控。
在一种可能的设计中,处理器301可包括一个或多个处理单元,处理器301可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理器301中。在一些实施例中,处理器301和存储器302可以在同一芯片上实现,在一些实施例中,它们也可以在独立的芯片上分别实现。
处理器301可以是通用处理器,例如中央处理器(CPU)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件,可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的数据管理方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。
存储器302作为一种非易失性计算机可读存储介质,可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器302可以包括至少一种类型的存储介质,例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory,RAM)、静态随机访问存储器(Static Random Access Memory,SRAM)、可编程只读存储器(Programmable Read Only Memory,PROM)、只读存储器(Read Only Memory,ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory,EEPROM)、磁性存储器、磁盘、光盘等。存储器302是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。本申请实施例中的存储器302还可以是电路或者其它任意能够实现存储功能的装置,用于存储程序指令和/或数据。
通过对处理器301进行设计编程,可以将前述实施例中介绍的数据管理方法所对应的代码固化到芯片内,从而使芯片在运行时能够执行图1所示的实施例的数据管理方法的步骤。如何对处理器301进行设计编程为本领域技术人员所公知的技术,这里不再赘述。
基于同一发明构思,本申请实施例还提供一种存储介质,该存储介质存储有计算机指令,当该计算机指令在计算机上运行时,使得计算机执行前文论述数据管理方法。
在一些可能的实施方式中,本申请提供的数据管理方法的各个方面还可以实现为一种程序产品的形式,其包括程序代码,当程序产品在装置上运行时,程序代码用于使该控制设备执行本说明书上述描述的根据本申请各种示例性实施方式的数据管理方法中的步骤。
程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
本发明的实施方式中提供的数据管理方法的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码,并可以在计算设备上运行。然而,本发明的程序产品不限于此,在本文件中,可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。这种传播的数据信号可以采用多种形式,包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质,该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
可读介质上包含的程序代码可以用任何适当的介质传输,包括——但不限于——无线、有线、光缆、RF等,或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码,所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备,或者,可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
应当注意,尽管在上文详细描述中提及了装置的若干单元或子单元,但是这种划分仅仅是示例性的并非强制性的。实际上,根据本发明的实施方式,上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之,上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。
此外,尽管在附图中以特定顺序描述了本发明方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (15)
1.一种数据管理方法,其特征在于,所述方法包括:
基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据;其中,所述历史数据指示数据库中更新前以及更新后的数据信息;
分批提取所述第一历史数据,并保存在对应的数据仓储中;
基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,并在所述目标数据仓储中进行所述第二历史数据的查询。
2.如权利要求1所述的方法,其特征在于,所述历史数据包括更新数据对应的元数据、更新的数据类型、更新的数据的数据库信息;其中,所述更新数据包括删除的数据、增加的数据、以及修改前和修改后的数据;所述元数据为所述删除的数据、增加的数据、以及修改前和修改后的数据中的至少一项,以及更新数据对应的更新时间。
3.如权利要求1或2所述的方法,其特征在于,所述基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据,包括:
采集所述历史数据到Kafka中;
使用kafka针对所述历史数据进行实时更新、保存,得到第一历史数据。
4.如权利要求3所述的方法,其特征在于,所述分批提取所述第一历史数据,并保存在对应的数据仓储中,包括:
利用Spark Streaming分批提取所述第一历史数据,并保存在对应的数据仓储。
5.如权利要求4所述的方法,其特征在于,所述数据仓储包括Hive,Hbase,ElasticSearch,则所述利用Spark Streaming分批提取Kafka中的历史数据,并保存在对应的数据仓储中,包括:
分别使用独立且与所述数据仓储对应的Spark Streaming提取Kafka中历史数据,并分别对应保存在Hive,Hbase,ElasticSearch中。
6.如权利要求5所述的方法,其特征在于,所述基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,包括:
当所述指定使用场景为聚合查询或者模糊查询时,确定所述目标数据仓储为ElasticSearch;
当所述指定使用场景为实时查询时,确定所述目标数据仓储为Hbase;
当所述指定使用场景为批量查询时,确定所述目标数据仓储为Hive。
7.一种数据管理的装置,其特征在于,所述装置包括:
采集单元:用于基于数据迁移服务组件采集历史数据并实时更新、保存,得到第一历史数据;其中,所述历史数据指示数据库中更新前以及更新后的数据信息;
提取单元:用于分批提取所述第一历史数据,并保存在对应的数据仓储中;
查询单元:用于基于不同的使用场景与所述数据仓储的查询特点,确定指定使用场景待使用的第二历史数据对应的目标数据仓储,并在所述目标数据仓储中进行所述第二历史数据的查询。
8.如权利要求7所述的装置,其特征在于,所述历史数据包括更新数据对应的元数据、更新的数据类型、更新的数据的数据库信息;其中,所述更新数据包括删除的数据、增加的数据、以及修改前和修改后的数据;所述元数据为所述删除的数据、增加的数据、以及修改前和修改后的数据中的至少一项,以及更新数据对应的更新时间。
9.如权利要求7或8所述的装置,其特征在于,所述采集单元具体用于采集所述历史数据到Kafka中;使用kafka针对所述历史数据进行实时更新、保存,得到第一历史数据。
10.如权利要求9所述的装置,其特征在于,所述提取单元具体用于利用SparkStreaming分批提取Kafka中的历史数据,并保存在对应的数据仓储。
11.如权利要求10所述的装置,其特征在于,所述数据仓储包括Hive,Hbase,ElasticSearch,则提取单元还用于,分别使用独立且与所述数据仓储对应的SparkStreaming提取Kafka中历史数据,并分别对应保存在Hive,Hbase,ElasticSearch中。
12.如权利要求11所述的装置,其特征在于,所述查询单元具体用于当所述指定使用场景为聚合查询或者模糊查询时,确定所述目标数据仓储为ElasticSearch;当所述指定使用场景为实时查询时,确定所述目标数据仓储为Hbase;当所述指定使用场景为批量查询时,确定所述目标数据仓储为Hive。
13.一种电子设备,其特征在于,包括:
存储器,用于存放计算机程序;
处理器,用于执行所述存储器上所存放的计算机程序时,以实现权利要求1~4中任一项所述的方法步骤。
14.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现权利要求1~6中任一项所述的方法。
15.一种计算机程序产品,其特征在于,当所述计算机程序产品在计算机上运行时,使得所述计算机执行如权利要求1~6中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111451322.4A CN114116908A (zh) | 2021-12-01 | 2021-12-01 | 一种数据管理方法、装置及电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111451322.4A CN114116908A (zh) | 2021-12-01 | 2021-12-01 | 一种数据管理方法、装置及电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114116908A true CN114116908A (zh) | 2022-03-01 |
Family
ID=80369049
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111451322.4A Pending CN114116908A (zh) | 2021-12-01 | 2021-12-01 | 一种数据管理方法、装置及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114116908A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116661705A (zh) * | 2023-07-24 | 2023-08-29 | 江西云眼视界科技股份有限公司 | 基于kafka的数据管理方法、系统、电子设备及存储介质 |
-
2021
- 2021-12-01 CN CN202111451322.4A patent/CN114116908A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116661705A (zh) * | 2023-07-24 | 2023-08-29 | 江西云眼视界科技股份有限公司 | 基于kafka的数据管理方法、系统、电子设备及存储介质 |
CN116661705B (zh) * | 2023-07-24 | 2023-10-20 | 江西云眼视界科技股份有限公司 | 基于kafka的数据管理方法、系统、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10831562B2 (en) | Method and system for operating a data center by reducing an amount of data to be processed | |
CN111258978B (zh) | 一种数据存储的方法 | |
CN104090889A (zh) | 数据处理方法及系统 | |
CN113282611B (zh) | 一种流数据同步的方法、装置、计算机设备及存储介质 | |
CN109842621A (zh) | 一种减少token存储数量的方法及终端 | |
CN108268468A (zh) | 一种大数据的分析方法及系统 | |
CN112860412B (zh) | 业务数据处理方法、装置、电子设备及存储介质 | |
CN114116908A (zh) | 一种数据管理方法、装置及电子设备 | |
CN114138877A (zh) | 基于微服务架构的主题数据服务实现方法、装置及设备 | |
CN112000703A (zh) | 数据入库处理方法、装置、计算机设备和存储介质 | |
CN108696559A (zh) | 流处理方法及装置 | |
CN115576973B (zh) | 一种业务部署方法、装置、计算机设备和可读存储介质 | |
CN116204540A (zh) | 操作日志记录方法、装置、设备及存储介质 | |
CN113902415A (zh) | 财务数据核对方法、装置、计算机设备和存储介质 | |
CN108664503A (zh) | 一种数据归档方法及装置 | |
CN111782588A (zh) | 一种文件读取方法、装置、设备和介质 | |
CN110705736A (zh) | 宏观经济预测方法、装置、计算机设备及存储介质 | |
CN113055476B (zh) | 一种集群式服务系统、方法、介质和计算设备 | |
CN115470225A (zh) | 数据处理方法、数据查询方法、装置和电子设备 | |
Sultan et al. | Dynamic cloud resources allocation | |
CN115576935A (zh) | 针对Hadoop的存储清理方法、装置、计算机设备及存储介质 | |
CN116719553A (zh) | 一种数据变更历史管理方法、装置、系统和介质 | |
CN117151862A (zh) | 数据处理方法、装置、系统、设备和存储介质 | |
CN117667914A (zh) | 一种数据处理方法和云服务系统 | |
CN117472451A (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 |