CN115237986A - 数据转储方法、装置以及存储介质 - Google Patents

Abstract

本申请公开了一种数据转储方法、数据转储装置以及存储介质，该数据转储方法包括：获取待处理数据；在所述待处理数据为非结构化数据的情况下，获取所述待处理数据的样例数据和元数据；根据所述元数据和所述样例数据，得到所述元数据和所述样例数据的映射关系；根据所述映射关系，获取目标数据表；基于所述映射关系和所述目标数据表，对所述待处理数据进行数据转储。通过上述方式，本申请能够使得非结构化的数据在进行数据转储时，可以识别该非结构化的数据的数据属性。

Description

数据转储方法、装置以及存储介质

技术领域

本申请涉及数据处理技术领域，特别是涉及一种数据转储方法、装置以及存储介质。

背景技术

随着计算机应用技术的不断发展，智能数据存储及处理技术在人们日常工作和生活中的应用场景不断增加，数据库技术给人们的工作以及各种复杂的管理事务提供了方便，而在实际的工作及生产使用过程中，数据存在很多种格式，按照数据结构特征，数据可以分为结构化数据和非结构化数据两种类型。每种类型的数据都与客户体验有着不一样的交互方式，所以对那些影响客户感知甚至影响客户决策的数据进行有效管理和存储是一个不可或缺的步骤。

目前，由于结构化数据的结构规则且完整，系统可以通过查询结构化数据表结构直接生成元数据，完成数据转出工作。而对于非结构化数据在进行数据转储时，则无法识别该非结构化数据对应的数据属性，需要人工手动输入，导致转储效率不高。

发明内容

本申请主要解决的技术问题是提供一种数据转储方法、数据转储装置以及存储介质，使得非结构化数据在进行数据转储时，可以识别非结构化数据的数据属性，完成数据映射。

为解决上述技术问题，本申请采用的一个技术方案是：提供一种数据转储方法，所述方法包括：

获取待处理数据；

在所述待处理数据为非结构化数据的情况下，获取所述待处理数据的样例数据和元数据；

根据所述元数据和所述样例数据，得到所述元数据和所述样例数据的映射关系；

根据所述映射关系，获取目标数据表；

基于所述映射关系和所述目标数据表，对所述待处理数据进行数据转储。

所述结构化数据对应的目标数据表，对所述待处理数据进行数据转储。

为解决上述技术问题，本申请采用的另一个技术方案是：提供一种数据转储装置，该数据转储装置包括存储器和处理器，存储器用于存储程序数据，处理器用于执行程序数据以实现如上述的数据转储方法。

为解决上述技术问题，本申请采用的另一个技术方案是：提供一种计算机可读存储介质，该计算机可读存储介质存储有程序数据，程序数据在被处理器执行时，用于实现如上述的数据转储方法。

本申请的有益效果是：区别于现有技术的情况，本申请是先通过获取待处理数据，当所述待处理数据为非结构化数据时，获取所述待处理数据的样例数据和元数据，然后基于获取到的所述元数据和所述样例数据，生成所述元数据和所述样例数据的映射关系，再根据所述映射关系，获取目标数据表，最后基于所述映射关系和所述目标数据表，对所述待处理数据进行数据转储。

也就是说，本申请通过获取非结构化数据的样例数据和元数据，进而生成元数据和样例数据的映射关系，解决了现有技术因系统无法识别该非结构化数据中元数据的数据属性，导致所有非结构化数据的数据属性都需要手动输入的问题，极大地提高了工作效率。

附图说明

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

图1是本申请提供的数据转储方法一实施例的流程示意图；

图2是本申请提供的数据转储方法一可选实施例中图1步骤S12的流程示意图；

图3是本申请提供的数据转储方法一可选实施例中图1中步骤S13的流程示意图；

图4是本申请提供的数据转储方法一可选实施例中图1中步骤S14的流程示意图；

图5是本申请提供的数据转储方法一可选实施例中图1中步骤S15的流程示意图；

图6为本申请提供的数据转储方法的完整流程示意图；

图7是本申请提供的数据转储装置的结构简图；

图8是本申请提供的数据转储装置一实施例的结构示意图；

图9是本申请提供的计算机可读存储介质一实施例的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面针对本发明涉及的专业术语和技术缩略语进行解释。

Kafka:是一种分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

FTP：文件传输协议。

DorisDB：一款经过业界检验、现代化，面向多种数据分析场景的、兼容MySQL协议的、高性能分布式关系型列式数据库。

一般来说，DorisDB包括前端节点(FrontEnd DorisDB，FE)、后端节点(BackEndDorisDB,BE)、Tablet和Broker。其中，FE负责管理元数据、管理客户端的连接、进行查询规划和调度等工作；BE负责数据存储、计算执行、副本管理等；Tablet是一张表实际的物理存储单元，一张表按照分区和分桶后在BE构成分布式存储层中以Tablet为单位进行存储，每个Tablet包括元数据；Broker是DorisDB中和外部数据对接的中转服务，辅助提供导入导出功能。

非Hive数据：非结构化数据，例如文本结构的数据。

Hive数据：结构化数据。

这里对结构化数据(Hive数据)和非结构化数据(非Hive数据)之间的异同点说明一下：

结构化数据是关系数据库中的定量数据，通常是由预定义格式的文本和数字组成，常见的结构化数据有：日期、电话号码、邮政编码、客户姓名、产品库存、销售点交易信息等等。结构化数据在数据库中以一种高度规则的形式存在，非常便于理解和解读。

而非结构化数据是指无法通过现有工具和方法处理的数据集。由于不能在关系数据库中进行组织，它通常被归类为定性数据。非结构化数据由非关系数据库或NoSQL数据库管理和存储。

具体地，非结构化数据是由数据结构不规则或不完整的数据组成，包括所有格式的办公文档、文本、图片、XML、HTML、各类报表、图像和音频/视频信息等等。

结构化和非结构化数据之间最明显的区别在于管理的数据类型。结构化数据包含可以量化和分析的确定数据。每条信息都按行和列放置，以映射到预定类别。相反，非结构化数据是以原始格式收集和分析的。

由于结构化数据相对更容易处理，这使得机器学习算法的集成更易于管理。相反，分析非结构化数据更加复杂。数据管理人员在分析收集到的数据之前需要大量的人工处理工作，再加之缺乏预定义的数据模型，这类信息即使是人工配置，难度也很大。并且大多数数据专家更熟练应用专业工具和软件进行结构化数据的挖掘与分析。使得企业在处理非结构化数据(如博客，社交媒体数据、客户交流数据等)的过程中会面临更多挑战。

因此，本申请提供一种数据转储方法，主要用于识别非结构化数据的数据属性，提高非结构化数据的转储效率。

下面，先解释一下数据转储的含义。

数据转储是数据库恢复中采用的基本技术。所谓转储就是服务器定期地将数据库中的数据复制到另外一个数据库的数据上进行保存起来的过程。当数据库遭到破坏后可以将后备副本重新装入,将数据库恢复到转储时的状态。

本申请中的数据转储可以将不同源的数据通过转储汇总到DorisDB数据库中。

请参阅图1，图1是本申请提供的数据转储方法第一实施例的流程示意图，该方法的执行主体为数据转储装置，该数据转储装置可以是计算机，该数据转储装置连接数据库，可以通过该数据转储装置将数据库复制到另外一个数据库的数据上进行保存起来，该方法包括：

步骤S11：获取待处理数据。

其中，待处理数据可以是结构化数据或者非结构化数据。在本实施例中的待处理数据可以是各种数据源接入的数据，比如说是来源于Hive、Kafka或FTP的数据，待处理数据若来源于Hive则可以称为Hive数据源数据，Hive数据源数据包括Hive数据(结构化数据)和非Hive数据(非结构化数据)。

当获取到需要进行数据转储的待处理数据后，需对待处理数据的一些数据信息进行管理。比如说，需要配置数据信息的访问地址和访问账号密码，并同时提供测试验证的连接端，保证数据配置的正确性。

步骤S12：在所述待处理数据为非结构化数据的情况下，获取所述待处理数据的样例数据和元数据。

需要说明的是由于从Kafka数据源接入的数据基本都是json格式的数据，通过ftp数据源接入的数据大多是csv、excel、txt这种文件格式的数据，所以会用不同的Demo结构来识别待处理数据，识别后的数据即为Demo数据，也就是本实施例中的样例数据。

以json格式为例，下面的json结构数据就可以视为一个Demo数据，具体如下：

{

"user_id":123,

"user_name":"张三",

"age":123,

"birth":"2000-02-22",

"mobile":"13333333333"

}

而元数据是指待处理数据经识别解析转化后的数据属性字段，元数据包括三要素：元数据字段名称、元数据字段描述和元数据字段类型。

具体地，以上述列举的Demo数据即json结构数据为例，该Demo数据中冒号前面的内容将来会被识别为元数据的字段名称和字段描述。比如说Demo数据中的：user_id、user_name、age、birth、mobile，就是元数据的字段名称和字段描述。

而元数据的字段类型是根据该Demo数据中冒号后面的内容自动识别的。目前通过技术可以识别出的字段类型有数字类型、日期类型和字符串类型。

比如说该Demo数据中的：123、张三、2000-02-22等就是元数据的字段类型。

需要注意的是，用户也可以结合实际情况对元数据的属性字段名称、属性字段描述等进行调整，也可以筛选掉一些不需要转储的属性字段。比如说用户觉得日期类型不是很重要，不需要进行转储，可以直接筛选掉，虽然说根据该Demo数据中冒号后面的内容会自动识别作为元数据的字段类型，但并不是所有识别后的数据都需要进行转储，而且当有相同的元数据导入目标数据表时，目标数据表可能会将其认为是两行不同的数据，这时也可以对元数据的属性字段进行适当的删减。

步骤S13：根据所述元数据和所述样例数据，得到所述元数据和所述样例数据的映射关系。

这里的映射关系(也可以称为Mapping关系)可以是通过元数据的字段类型、字段名称和字段描述，找到Demo数据中对应的内容。比如说通过元数据中的数字类型，可以找到Demo数据中对应的取值123。

步骤S14：根据所述映射关系，获取目标数据表。

其中，目标数据表在本申请可以指DorisDB数据库中的基表(table)，简称DorisDB表。

一般来说，DorisDB表由行和列构成，每行数据对应用户的一条记录，每列数据有相同的数据类型(也就是元数据中的字段类型)，所有数据行的列数相同，具体可以参考如下：

用户user

步骤S15：基于所述映射关系和所述目标数据表，对所述待处理数据进行数据转储。

示例性地，将映射关系和目标数据表按照DorisDB的转储脚本规则进行数据转储。

也即，将第一数据库中的数据转储到第二数据中。示例性地，当第一数据库中的数据为kafka的数据时，则可以使用routine load的方式将kafka中的数据实时的导入到DorisDB中以实现数据转储。示例性地，通过以下方式实现数据转储，具体如下：

在步骤S15中，通过在DorisDB上执行转储脚本，实现数据转储。数据转储后，数据保存在转储后的第二数据库中。由于DorisDB对于大数据量的数据Load性能支持极好，因此，可以有效的利用DorisDB的能力提高数据的转储能力，同时，对于大量数据的查询分析也非常好，能够为后续的数据应用提供足够的支撑。在本实施例中，上述步骤的执行主体可以是管理数据库的服务器，示例性地，可以是DorisDB数据库的处理器。

本实施例的有益效果是：区别于现有技术的情况，本申请是先通过获取待处理数据，当所述待处理数据为非结构化数据时，获取所述待处理数据的样例数据和元数据，然后基于获取到的所述元数据和所述样例数据，生成所述元数据和所述样例数据的映射关系，再根据所述映射关系，获取目标数据表，最后基于所述映射关系和所述目标数据表，对所述待处理数据进行数据转储。

也就是说，本申请通过获取所述待处理数据的样例数据和元数据，生成所述元数据和所述样例数据的映射关系，解决了现有技术因系统无法自动识别该非结构化数据的数据属性，导致所有的数据属性都需要手动输入的问题，极大地提高了工作效率；并且使用DorisDB数据库，进一步提高了数据转储的效率。

参阅图2，图2是一可选实施例中图1步骤S12的流程示意图，该方法包括：

步骤S121:获取所述待处理数据的样例数据。

步骤S122:根据多种预设数据结构解析所述待处理数据的样例数据。

步骤S123:根据解析后的所述样例数据，得到对应所述待处理数据的元数据。

具体地，对于步骤S122和S123，由于非结构化数据(例如Kafka、FTP的数据)的数据结构比较开放，需要通过不同预设数据结构解析识别Demo数据。

通常地，对于非结构化数据有个内置逻辑是这样的：

若非结构化数据是Kafka数据，则基本接入的都是json格式的数据；若非结构化数据是ftp数据，则接入的数据大都是csv格式、excel格式和txt格式的数据，所以对于每种不同的格式Demo数据，需要采用不同预设数据结构去解析识别。

在本实施例中，所述多种预设数据结构，包括但不局限于JSON数据结构、Txt数据结构、CSV数据结构和Excel数据结构。

示例性地，这几种不同的预设数据结构的识别方式如下：

1)JSON数据结构识别：解析JSON数据样例识别完整的JSON数据结构，自动生成对应的元数据。

2)CSV数据结构识别：解析CSV数据样例识别完整的JSON数据结构，自动生成对应的元数据。

3)Excel数据结构识别：解析Excel数据样例识别完整的JSON数据结构，自动生成对应的元数据。

4)Txt数据结构识别：解析Txt数据样例识别完整的JSON数据结构，自动生成对应的元数据。

其中，在Txt数据结构识别中，每一行作为一条数据，必须有明确的分隔符。

根据以上的介绍，可以得知通过不同预设数据结构的Demo数据解析，可以自动识别非结构化数据即Hive的样例数据，生成对应的元数据，避免了传统的手动输入非Hive数据的数据属性导致的工作量巨大，人力成本高，且容易出错的缺点，另外，通过不同的预设结构去解析识别样例数据，最后做一个归一汇总，像CSV、Excel、Txt这种格式的数据识别后都转化成JSON数据结构，然后采用同样的方法转换为元数据，在一定程度上提高了转储的效率。

在另一实施例中，根据多种预设数据结构解析所述待处理数据的样例数据，具体可以包括解析所述样例数据的数据属性字段；

根据解析后的所述样例数据，得到对应所述待处理数据的元数据，具体可以包括：根据所述数据属性字段，生成所述元数据；

其中，所述元数据包括：属性字段描述、属性字段名称和属性字段类型。

其中，元数据为转储后的属性字段，是系统根据内置规则逻辑自动生成的，元数据主要包括三个属性，分别是：属性字段描述、属性字段名称、属性字段类型。

具体地，属性字段描述即数据字段的中文描述，用于描述字段的含义；

属性字段名称即数据字段的字段名称，也就是表字段名称，字段名称需要回避关键词的出现(例如：select group system等)，需要注意的是，若出现关键词则会自动重命名添加后缀。

属性字段类型即数据字段的数据类型，例如int、varchar等，需要说明的是，元数据中属性字段类型的具体识别是根据Demo数据中的数据样例的属性字段类型自动识别的。

需要注意的是，内置规则逻辑如下：

1)关键字判断：判断非Hive数据的字段名称是否是保留关键字(例如：system、create、table等)，如果是则增加固定后缀“_key”。

2)是否存在判断：根据“关键字判断”该步骤的处理结果查找元数据是否存在该属性字段，存在则直接匹配，否则直接匹配后同时进入步骤3)。

3)自动生成元数据：根据非Hive数据对应的数据属性字段自动生成元数据。

其中，元数据主要有三个管理入口，具体如下：

1)Hive数据接入，自动生成元数据；

2)Kafka数据及其他Hive数据接入，根据Demo数据生成元数据；

3)用户手动配置增加新的数据。

需要说明的是，生成元数据之后可选择性地对该元数据进行管理，示例性地，将待处理数据的结构识别中识别的属性字段统一管理，管理属性名称、属性描述、属性数据类型为后续数据转储提供基础支撑，也就是说当配置数据接入时系统会自动识别数据属性，结合现有元数据完成自动匹配，如果元数据中不存在该属性，则匹配后自动生成该元数据的数据，如果存在则自动匹配。

由于DorisDB中的所有属性字段都来自于元数据，所以元数据是用于统一管理和规范目标数据表的数据字段的。

参阅图3，图3是一可选实施例中图1中步骤S13的流程示意图，具体可以包括以下步骤：

步骤S131：根据所述样例数据中的属性字段编码，匹配所述元数据对应的数据属性字段，得到匹配结果。

步骤S132：对所述匹配结果进行确认，输出所述元数据和Demo数据的映射关系。

具体地，根据Demo数据和元数据生成Mapping关系性字段编码，自动匹配元数据对应的属性字段，自动匹配后通过人工判断调整，最终生成完整的Mapping关系。

示例性，对匹配结果进行确认即步骤S132，具体可以包括以下步骤：

步骤S1321：判断所述元数据的属性字段是否重复。

步骤S1322：确认所述目标数据表的属性主键字段和分区字段。

具体地，在步骤S1321和步骤S1322中，确认的内容如下：

1)确认字段映射关系：例如元数据和Demo数据的映射关系是否正确，并且，保证元数据的数据属性字段不重复；

2)key：确定目标数据表的主键字段；

3)分区：确定目标数据表的分区字段。

该实施例可以根据Demo数据和元数据自动生成Mapping关系，并且通过确认这一环节，使得用户可以根据具体需要进行调整，方便用户进行配置。需要说明的是，本实施例中的确认可以是人工确认，也可以是通过机器执行对应的代码程序进行确认，在此不做限定。

参阅图4，图4是一可选实施例中图1中步骤S14的流程示意图，具体可以包括以下步骤：

步骤S141:将映射关系中所述元数据的字段编码、字段数据类型和数据字段描述，根据预设建表规则生成建表脚本。

步骤S142:根据该建表脚本执行建表语句，生成所述目标数据表。

其中，预设建表规则可以是DorisDB的建表规则，建表脚本可以为DorisDB的脚本。需要注意的是，目标数据表中的所有属性字段都来源于元数据。

具体地,在步骤S141中，关于DorisDB的建表脚本的生成，可参考以下示例：

在该实施例中，通过将映射关系中所述元数据的字段编码、字段数据类型和数据字段描述，按照DorisDB的建表规范自动生成Dori sDB的建表脚本，再按照该建表脚本执行建表语句。

由于DorisDB建表脚本和标准SQL的脚本略有不同，不需要设置分桶数量，所以需要遵从DorisDB的建表规范生成建表脚本，以使生成的目标数据表更加规范和方便，便于管理。

参阅图5，图5是一可选实施例中图1中步骤S15的流程示意图，具体可以包括以下步骤：

步骤S151:将所述映射关系和所述目标数据表，按照预设数据转储规则生成数据转储脚本。

步骤S152:执行所述数据转储脚本，进行数据转储工作。

其中，预设数据转储规则可以是DorisDB的转储规则，可选地，生成数据转储脚本后，可以根据数据所在的位置选择导入方式，也可以根据数据对应的数据源选择导入方式，例如可以选择broker load、routine load、stream load、spark load等方式导入，将不同源的数据转储汇总到DorisDB中。

示例性地，当数据为kafka，则可以使用routine load的方式将kafka中的数据实时的导入到DorisDB中。具体可以通过以下方式进行导入：

在另一实施例中，对所述待处理数据进行数据转储即步骤S15之后，所述方法还包括：

步骤S153:对所述待处理数据进行数据转储管理和/或数据转储监控。

可选地，数据转储管理包括但不局限于暂停转储、启动转储和重新转储。

其中，数据转储监控主要用到两个监控查询命令，即show load和show routineload。

步骤S153中，通过对数据进行转储管理和通过查询数据转储任务的状态动态监控数据转储的情况，不仅实现了对于转出任务的全面管理，而且提供了全面的数据转出监控。在本实施例中，对数据转储的管理以及监控都是在管理数据库的服务器上执行的，示例性地，可以是上述说明的DorisDB数据库的处理器。

在另一实施例中，获取待处理数据之后，所述方法还包括：

当所述待处理数据为Hive数据时，查询Hive数据表，获取所述Hive数据的数据结构；

基于所述Hive数据的数据结构，自动生成所述Hive数据对应的元数据；

获取所述Hive数据和所述Hive数据对应的元数据之间的映射关系；

根据所述Hive数据对应的映射关系，获取所述Hive数据对应的DorisDB目标数据表；

基于所述Hive数据对应的映射关系和所述Hive数据对应的DorisDB目标数据表，对所述待处理数据进行数据转储。

具体地，由于Hive数据的数据结构相对稳定，可以通过直接查询Hive表的结构直接获取Hive数据的数据结构，自动生成元数据，并自动生成对应的Mapping关系，而不需要通过待处理的数据提供Demo数据，再根据数据的Demo数据解析数据的数据属性字段，生成元数据。

需要注意的是，由于本实施例的待处理数据为Hive数据，因此，本实施例的Mapping关系指的是Hive数据的属性字段和转储后的属性字段即Hive数据对应的元数据之间的映射关系。

另外，在本实施例中，系统根据内置规则自动生成Hive数据对应的元数据中，内置规则逻辑如下：

1)关键字判断：判断Hive字段名称是否是保留关键字(例如：system、create、table等)，如果是则增加固定后缀“_key”。

2)是否存在判断：根据“关键字判断”该步骤的处理结果查找元数据是否存在该属性字段，存在则直接匹配，否则匹配后进入步骤3)。

3)自动生成元数据：根据Hive对应的数据属性字段自动生成元数据。

在这个过程中，不同的用户可以根据具体需要进行调整，方便用户配置。

需要说明的是，Hive数据中涉及的元数据与非Hive数据中的元数据类似，都主要包括三个属性，分别是：属性字段描述、属性字段名称、属性字段类型。

具体地，属性字段描述即数据字段的中文描述，用于描述字段的含义。

属性字段名称即数据字段的字段名称，也就是表字段名称，字段名称需要回避关键词的出现(例如：select group system等)，需要注意的是，若出现关键词则会自动重命名添加后缀。

属性字段类型即数据字段的数据类型，例如int、varchar等，不过，需要注意的是，这里元数据中属性字段类型的具体识别是根据Hive数据的属性字段自动识别的。

在本实施例中，由于待处理数据为Hive数据，则使用Broker load导入。

示例性地，可以如以下实施方式将Hive数据导入：

同样地，在本实施例中，也会对所述待处理数据进行数据转储管理和/或数据转储监控。

可选地，数据转储管理包括但不局限于暂停转储、启动转储和重新转储。

其中，数据转储监控主要用到两个监控查询命令，即show load和show routineload。

通过对数据进行转储管理和通过查询数据转储任务的状态动态监控数据转储的情况，不仅实现了对于转出任务的全面管理，而且提供了全面的数据转出监控。

在这里，结合上述所提到的实施例，对本申请完整的实施方案进行一个梳理解释，请参阅图6，图6为本申请提供的数据转储方法的完整流程示意图。

本申请是先获取待处理数据的Demo数据和元数据，其中待处理数据可以是本地数据、Hive数据和非Hive数据，元数据可以根据Demo数据进行解析生成，根据获取到的Demo数据和元数据生成映射关系，并按照预设数据转储规则生成转储脚本，在生成转储脚本的同时，根据元数据，生成建表脚本创建目标数据表，执行转储脚本，将不同的数据转储到建好的目标数据表即DorisDB表中，由DorisDB表中的Broker负责和外部数据对接的中转服务，辅助提供导入导出功能，完成数据转储，而DorisDB表中的FE负责对转储后的元数据和客户端的连接进行管理、并进行查询规划和调度等工作；BE负责数据存储、计算执行、副本管理等。

简单来说，本申请提供的数据转储方法对应的装置主要可以分为三大模块，具体可参阅图7，图7是本申请提供的数据转储装置的结构简图。

示例性地，本申请的数据转储装置可以主要分为三大操作模块，第一是数据管理模块即对接入的数据进行管理，比如说管理数据的来源即数据源，对数据进行结构识别，生成元数据，进而生成映射关系；第二是生成模块，即依赖生成的脚本和数据表来将数据进行转储，比如说建表脚本、创建目标数据表和转储脚本，第三是转储管理模块，即对转储后的数据做进一步的管理，包括数据转储、数据转储管理和数据转储监控。

在另一实施例中，可以针对数据的数据结构定义一条完整的模板，每个数据按照该模板提供数据结构数据，再由系统解析数据对应的数据结构数据，自动生成元数据、Mapping关系映射。

其中，在该实施例中，模板可以是xml、json等任何结构化的数据文件，但是需要注意的是，这里所述的模板需要能够表达原始数据结构的规范定义，包括但不局限于表达原始数据结构的每个数据字段的名称、数据类型。

根据上述的介绍，可以理解的是，通过先定义模板，然后数据按照该模板提供数据结构数据，再由系统解析数据对应的数据结构数据，自动生成元数据和Mapping关系映射，这样不仅可以保证高质量的匹配，而且可以减少人为的调整优化。

参阅图6，图6是本申请提供的数据转储装置一实施例的结构示意图，该数据转储装置60包括存储器61和处理器62，存储器61用于存储程序数据，处理器62用于执行程序数据以实现如下的方法：

获取待处理数据；在所述待处理数据为非Hive数据的情况下，获取所述待处理数据的Demo数据和元数据；基于获取到的所述元数据和所述Demo数据，生成所述元数据和所述Demo数据的映射关系；根据所述映射关系，获取目标数据表；基于所述映射关系和所述目标数据表，对所述待处理数据进行数据转储。

可选地，处理器62还用于执行程序数据以实现如下的方法：

在所述待处理数据为Hive数据的情况下，查询Hive数据表，获取所述Hive数据的数据结构；基于所述Hive数据的数据结构，自动生成所述Hive数据对应的元数据；获取所述Hive数据和所述Hive数据对应的元数据之间的映射关系；根据所述Hive数据对应的映射关系，获取所述Hive数据对应的目标数据表；基于所述Hive数据对应的映射关系和所述Hive数据对应的目标数据表，对所述待处理数据进行数据转储。

可选地，在一实施例中，该数据转储装置60可以是芯片、可编程逻辑门阵列(FieldProgrammable Gate Array，FPGA)、单片机等，其中的芯片可以是处理芯片，如CPU、GPU、MCU等，也可以是存储芯片，如DRAM、SRAM等。

参阅图7，图7是本申请提供的计算机可读存储介质一实施例的结构示意图，该计算机可读存储介质70存储有程序数据71，程序数据71在被处理器执行时，用于实现如下的方法：

获取待处理数据；当所述待处理数据为非Hive数据时，获取所述待处理数据的Demo数据和元数据；基于获取到的所述元数据和所述Demo数据，生成所述元数据和所述Demo数据的映射关系；根据所述映射关系，获取目标数据表；基于所述映射关系和所述目标数据表，对所述待处理数据进行数据转储。

可选地，程序数据71在被处理器执行时，还用于实现如下的方法：

当所述待处理数据为Hive数据时，查询Hive数据表，获取所述Hive数据的数据结构；基于所述Hive数据的数据结构，自动生成所述Hive数据对应的元数据；获取所述Hive数据和所述Hive数据对应的元数据之间的映射关系；根据所述Hive数据对应的映射关系，获取所述Hive数据对应的目标数据表；基于所述Hive数据对应的映射关系和所述Hive数据对应的目标数据表，对所述待处理数据进行数据转储。

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

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (11)

1.一种数据转储方法，其特征在于，所述方法包括：

获取待处理数据；

在所述待处理数据为非结构化数据的情况下，获取所述待处理数据的样例数据和元数据；

根据所述元数据和所述样例数据，得到所述元数据和所述样例数据的映射关系；

根据所述映射关系，获取目标数据表；

基于所述映射关系和所述目标数据表，对所述待处理数据进行数据转储。

2.根据权利要求1所述的数据转储方法，其特征在于，

所述获取所述待处理数据的样例数据和元数据，包括：

获取所述待处理数据的样例数据；

根据预设数据结构解析所述待处理数据的样例数据；

根据解析后的样例数据，得到对应所述待处理数据的元数据。

3.根据权利要求2所述的数据转储方法，其特征在于，

所述根据预设数据结构解析所述待处理数据的样例数据，具体包括：

根据所述预设数据结构解析所述样例数据的数据属性字段；

所述根据解析后的所述样例数据，得到对应所述待处理数据的元数据，包括：

基于所述数据属性字段，生成所述元数据；

其中，所述元数据包括：属性字段描述、属性字段名称和属性字段类型。

4.根据权利要求3所述的数据转储方法，其特征在于，

所述根据所述元数据和所述样例数据，得到所述元数据和所述样例数据的映射关系，具体包括：

根据所述样例数据中的数据属性字段，匹配所述元数据对应的属性字段，得到匹配结果；

对所述匹配结果进行确认，输出所述元数据和样例数据的映射关系。

5.根据权利要求4所述的数据转储方法，其特征在于，

所述对所述匹配结果进行确认，具体包括：

判断所述元数据的属性字段是否重复；

确认所述目标数据表的属性主键字段和分区字段。

6.根据权利要求3-5任一项所述的数据转储方法，其特征在于，

所述根据所述映射关系，获取目标数据表，具体包括：

根据预设建表规则将所述映射关系中所述元数据的属性字段描述、属性字段名称和属性字段类型生成建表脚本；

根据所述建表脚本执行建表语句，生成所述目标数据表。

7.根据权利要求1-3任一项所述的数据转储方法，其特征在于，

所述进行数据转储之前，所述方法还包括：

根据所述映射关系和所述目标数据表，

按照预设数据转储规则生成数据转储脚本；

执行所述数据转储脚本，完成数据转储。

8.根据权利要求1-3任一项所述的数据转储方法，其特征在于，

所述对所述待处理数据进行数据转储之后，所述方法还包括：

对所述待处理数据进行数据转储管理和/或数据转储监控。

9.根据权利要求1所述的数据转储方法，其特征在于，

所述获取待处理数据之后，所述方法还包括：

在所述待处理数据为结构化数据的情况下，

查询结构化数据表，获取所述结构化数据的数据结构；

基于所述结构化数据的数据结构，生成所述结构化数据对应的元数据；

获取所述结构化数据和所述结构化数据对应的元数据之间的映射关系；

根据所述结构化数据对应的映射关系，获取所述结构化数据对应的目标数据表；

基于所述结构化数据对应的映射关系和所述结构化数据对应的目标数据表，对所述待处理数据进行数据转储。

10.一种数据转储装置，其特征在于，所述数据转储装置包括存储器和处理器，所述存储器用于存储程序数据，所述处理器用于执行所述程序数据以实现如权利要求1-9任一项所述的数据转储方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有程序数据，所述程序数据在被处理器执行时，用于实现如权利要求1-9任一项所述的数据转储方法。

Images