CN111538713B - 面向Hive的多模式数据处理方法、装置及电子设备 - Google Patents

Abstract

本发明实施例公开了一种面向Hive的多模式数据处理方法、装置及电子设备，方法包括：将Hive表中的数据按照每列对应存储一个字段的数据的方式存储；将每列的数据划分为属于不同分区的分区数据；将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；表模式用于表征Hive表的表结构属性，且每当Hive表的表结构发生变化时产生新的表模式。本发明可以自由应对数据仓库中数据结构的变更，通过配置不同的表模式使系统具有不同结构的数据，避免表结构发生变化时导致的数据迁移，降低了系统维护开销，此外，由于可以通过配置不同的表模式使系统具有不同结构的数据，因此使得表结构变更更具灵活性。

Description

面向Hive的多模式数据处理方法、装置及电子设备

技术领域

本发明涉及计算机技术领域，具体涉及一种面向Hive的多模式数据处理方法、装置及电子设备。

背景技术

为了有效地处理大数据，越来越多的企业都选择Hive来构建自己的数据仓库。Hive使程序员可以像操作关系型数据库一样用SQL来处理数据，这样既简化了开发又保证了大数据的处理性能。

通常情况下企业的数据仓库中所存放的数据时间跨度都会非常大，在这期间历史数据和新数据在存储结构和处理方式上会产生差异，例如甲公司的结算系统伴随子公司业务的调整多次出现了数据存储结构(表结构)与处理方式的修改，这将耗费企业大量的精力去处理这些差异来保证数据仓库的正常运行。针对这个问题，已有的解决方案如下：

第一种解决方案是：设置宽表。

这种方法是在设计Hive数据仓库的表的结构时，在设计表时除了应有字段外，还设置若干个保留字段，这些保留字段在数据仓库最初的应用中并不被使用，如果后续表需要添加字段的时候，则会选择一个保留字段作为这个新增的字段存储数据。

第二种解决方案是：设置历史表。

这种方法是在设计Hive数据仓库时，把每张表都拆分成历史表。可以按照时间等条件来拆分。最初的历史表的结构和原始设计一样，但是随着数据存储结构的变动，后续的历史表就可根据新的存储结构来设计。甲公司统一话费计费系统中按月为单位划分历史表，每个月的历史表只存储当月的数据，新建的历史表的结构可能会和老的历史表不同。

第三种解决方案是：进行数据迁移。

这种方法就是根据企业业务的调整定期更新数据仓库里数据的存储结构。一旦数据的存储结构发生变更则依据最新的存储规则建立新表，再将旧表中的数据按照新表的格式迁移过来，同时迭代数据的处理逻辑，保证数据仓库的处理能正常进行。

上面三种解决方案存在如下问题：

一方面是：性能与效率的问题，企业往往收集了海量的数据，迁移历史数据将会耗费巨大，并且效率低下，某些情况下会严重拖慢需求的开发进度。

另一方面是：现有的方法缺失数据结构变更的灵活性，无论是设置宽表还是设置历史表都有其局限。设置宽表可以适应一定情况下的字段添加，但是开发者总是无法预知后期的数据字段变化，因此很难确定保留字段的数量，一旦要新增的字段数超过了保留字段的数量则无法进行处理。如果历史表是按月建立的，但是数据在月中改变，即一个月内有两种结构的数据，则这种按月历史表将无法创建，存在条件的限制。

发明内容

由于现有方法存在上述问题，本发明实施例提出一种面向Hive的多模式数据处理方法、装置及电子设备。

具体地，本发明实施例提供了以下技术方案：

第一方面，本发明实施例提供了一种面向Hive的多模式数据处理方法，包括：

将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储；

根据预设分区定义，将每列的数据划分为属于不同分区的分区数据；

将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；其中，每个Block对应一个表标识、列标识、分区标识和表模式标识；其中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式。

进一步地，所述的面向Hive的多模式数据处理方法，还包括：

根据每个Block对应的表标识、列标识、分区标识和表模式标识确定每个Block所属的表、Block所属的列、Block所属的分区和Block所属的表模式；

根据每个Block所属的表、Block所属的列、Block所属的分区和Block所属的表模式为每个Block分别建立表维度、列维度、分区维度和表模式维度共四个维度下的键值对索引；其中，每个Block在四个维度下的键值对索引的Key值分别为相应Block对应的表标识、列标识、分区标识和表模式标识，每个Block在四个维度下的键值对索引的Value值均为相应Block的Block地址；

根据每个Block在四个维度下的键值对索引，建立四个维度下的键值对索引数据库；其中，每个维度下的键值对索引数据库中存储有相应维度下的键值对索引。

进一步地，所述的面向Hive的多模式数据处理方法，还包括：

获取待查数据的查询条件；其中，所述查询条件中包括表标识、列标识、分区标识和表模式标识；

根据查询条件中的表标识、列标识、分区标识和表模式标识，分别查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址；

对四个维度下的Block地址求取交集，获取与待查数据对应的Block地址；

根据与待查数据对应的Block地址获取待查数据。

进一步地，所述根据查询条件中的表标识、列标识、分区标识和表模式标识，分别查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址，具体包括：

启动第一线程、第二线程、第三线程和第四线程；

分别为第一线程、第二线程、第三线程和第四线程分配表维度、列维度、分区维度和表模式维度下的Block地址查询任务，使得第一线程、第二线程、第三线程和第四线程根据查询条件中的表标识、列标识、分区标识和表模式标识，并行地查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址。

进一步地，所述的面向Hive的多模式数据处理方法，还包括：

为每个表模式对应生成一个表模式配置文件，所述表模式配置文件用于描述所述表模式下的表字段信息；

在Hadoop中的NameNode节点，将所有的表模式配置文件加载入内存进行统一管理；

在Hadoop中的每个DataNode均部署一个数据读取接口，所述数据读取接口用于读取待查数据的查询条件中的表模式标识，并根据所述表模式标识从NameNode节点获取相应的表模式配置文件，通过解析相应的表模式配置文件，获取相应表模式下的表字段信息，并根据获取到的表字段信息读取相应的字段。

进一步地，所述表模式配置文件包括：表模式标识、表模式适用的Hive表、表模式包含的字段的名称、字段的数据类型和字段的位置编号。

进一步地，所述表模式配置文件为基于yaml文件格式的表模式配置文件。

第二方面，本发明实施例还提供了一种面向Hive的多模式数据处理装置，包括：

第一处理模块，用于将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储；

第二处理模块，用于根据预设分区定义，将每列的数据划分为属于不同分区的分区数据；

第三处理模块，用于将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；其中，每个Block对应一个表标识、列标识、分区标识和表模式标识；其中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式。

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

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

由上述技术方案可知，本发明实施例提供的面向Hive的多模式数据处理方法、装置及电子设备，由于利用表模式表征Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式，因此，将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储，并将每列的数据划分为属于不同分区的分区数据，且将属于不同表模式的分区数据分别存储至Hadoop的不同Block中，因此使得本实施例提供的这种面向Hive的多模式数据处理方法，可以自由应对数据仓库中数据结构的变更，通过配置不同的表模式使系统具有不同结构的数据，避免表结构发生变化时导致的数据迁移，降低了系统维护开销，此外，由于可以通过配置不同的表模式使系统具有不同结构的数据，因此使得表结构变更更具灵活性。

附图说明

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

图1是本发明一实施例提供的面向Hive的多模式数据处理方法的流程图；

图2是本发明一实施例提供的Hive表的层级存储结构示意图；

图3是本发明一实施例提供的表模式配置文件与Block之间逻辑关系示意图；

图4是本发明一实施例提供的多维度索引结构示意图；

图5是本发明一实施例提供的基于多维度索引结构的数据查询流程示意图；

图6是本发明一实施例提供的数据存储结构示意图；

图7是本发明一实施例提供的数据读取接口的结构示意图；

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

图9是本发明一实施例提供的多模式数据读取方法流程示意图；

图10是本发明一实施例提供的面向Hive的多模式数据处理装置的结构示意图；

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

具体实施方式

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

图1示出了本发明一实施例提供的面向Hive的多模式数据处理方法的流程图，如图1所示，本发明实施例提供的面向Hive的多模式数据处理方法，具体包括如下内容：

步骤101：将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储；

步骤102：根据预设分区定义，将每列的数据划分为属于不同分区的分区数据；

步骤103：将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；其中，每个Block对应一个表标识、列标识、分区标识和表模式标识；其中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式。

在本实施例中，将Hive表的存储结构修改为如图2所示的层级结构。首先，表的数据按照列来进行存储，每个列只包含该列的数据，例如图2中列1、列2、列3、列4分别存储各自列的数据；接下来将每个列里的数据按分区进行存储，分区由用户在定义表时指定，图2中只显示了一级的分区，像分区1、分区2、分区3，实际可支持多层级的分区，例如按账期、省份、月份来分区。每一个分区都对应一组Hadoop的Block数据块，这些Block数据块用于存储该分区在不同表模式下的数据。在本实施例设计的存储结构的基础上每个Block都将只会存储一个列的一个分区的数据。此外，本实施例还设计每个Block将只存储一个表模式的数据，本实施例定义数据的表模式即数据的结构(表字段)，这样可以将不同模式的数据区分出来，在进行数据处理时可以通过索引直接找到相应模式的数据进行处理。

在本实施例中，所述预设分区定义表示分区依据，例如，根据月份对列数据进行分区，根据区域对列数据进行分区等。

在本实施例中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式。举例来说，一张表可能一开始只有10个字段，这是一种表模式，后来可能新增了几个字段变成15个字段，这又是一种表模式，这样做可以在读取数据的时候根据表模式来读取数据，避免了读取数据的SQL语句因表结构前后不一致而产生的问题。在本实施例中，一个字段下的数据可以按时间分成好几个分区，比如按月份，2月份是一个分区，3月份是一个分区，2月份的表模式是10个字段，3月份是8个字段，那么在读取2月份所有数据时(所有字段)就按照2月份的表模式去读。

在本实施例中，可以为每个表模式对应生成一个表模式配置文件，所述表模式配置文件用于描述所述表模式下的表字段信息。

如图2和图3所示，假设Hive表在1月份对应一个表模式1，其对应的表模式配置文件为表模式配置文件1，Hive表在2月份对应一个表模式2，其对应的表模式配置文件为表模式配置文件2，Hive表在3月份对应一个表模式2，其对应的表模式配置文件为表模式配置文件2，Hive表在4月份对应一个表模式3，其对应的表模式配置文件为表模式配置文件3。如图2和图3所示，按照本实施例的方式，将属于表模式1的2月份这一分区数据存储至Block1中，将属于表模式2的2月份这一分区数据存储至Block2中，将属于表模式2的3月份这一分区数据存储至Block3中，将属于表模式3的4月份这一分区数据存储至Block4中。

本发明实施例由于利用表模式表征Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式，因此，将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储，并将每列的数据划分为属于不同分区的分区数据，且将属于不同表模式的分区数据分别存储至Hadoop的不同Block中，因此使得本实施例提供的这种面向Hive的多模式数据处理方法，可以自由应对数据仓库中数据结构的变更，通过配置不同的表模式使系统具有不同结构的数据，避免表结构发生变化时导致的数据迁移，降低了系统维护开销，此外，由于可以通过配置不同的表模式使系统具有不同结构的数据，因此使得表结构变更更具灵活性。

本实施例中的表模式表征所述Hive表的表结构属性，也即可以理解成：所述表模式是指Hive表的表字段信息，即包含的字段的名称、字段的数据类型、字段的位置编号等。在本实施例中，为每个表模式对应生成一个表模式配置文件，所述表模式配置文件用于描述所述表模式下的表字段信息。例如，本实施例设计了一种基于yaml文件格式的表模式配置文件，yaml格式文件的结构简单清晰且被程序解析与读取的效率较高，下面将某一结算系统的部分模式定义为例来说明表模式配置文件的结构与定义：

如上面所示，SchemaId表示该模式的ID，是该模式的唯一标识，其值由“MIGUJS”加模式创建日期(到年月日)再加4位序列号组成。模式ID只是用于系统区分不同的模式定义。

ForTable表示该定义的模式是为哪张表定义的，由上面显示可知，该模式是为SRC_DEVICE_LOG表定义的，即SRC_DEVICE_LOG的表字段结构由该模式定义确定。在本实施例中一张表可以有多个模式，但一个模式只能定义一张表；之所以这样设计是因为表的结构随着业务的改变也会跟着改变，从而形成不同的表模式定义，这些表模式定义就用表模式配置文件来表示。通过该字段可以获得一个表的所有表模式定义。

SchemaName表示该模式的名称，可以由用户自己定义。

SchemaVersion表示该模式的版本号，版本号由“V_MIGUJS_”加上定义模式的表的名称再加上模式生成的日期再加上4位序列号组成。版本号实际上包含了模式的ID，这使版本号可以唯一标识表模式配置文件。从版本号中可以清楚地获取该版本模式所定义的表名称，而且通过时间可以将表模式配置文件进行时间排序，形成一个模式演化序列。

SchemaDescription表示模式的相关描述信息，用户可写入一些对本模式定义的说明。

SchemaColumns表示模式定义的字段的集合，该元素是一个复合元素，它包含若干个Column元素。在上面所示例子中就定义了两个表字段。

Column表示表定义的字段，一个Column表示一个表字段的定义。如上面例子所示Column里包含了许多子元素：ColumnName表示字段的名称；ColumnType表示字段的数据类型，上面所示例子中设置为Hive的string类型；ColumnOrderNum表示字段在表中的位置，本实施例设计位置从1开始；ColumnDescription表示字段定义的一些描述信息。

如上面例子所示，对于SRC_DEVICE_LOG表可以定义不同的表模式，这样做是因为随着业务的发展SRC_DEVICE_LOG表的字段可能会发生改变，可能出现原始定义了20个字段，后来增加到22个字段，再后来又缩减为19个字段的情形。因此可以针对每个情形都新建一个表模式配置文件。在本实施例中，一个Block只存储与一个分区对应的一种表模式的分区数据。由于本实施例所设计的存储模式中存放数据的Block只存放同一个版本的数据，所以在表模式配置文件与Block之间可以形成如图3所示的逻辑结构。如图3所示，本实施例为方便说清楚Block和表模式配置文件的关系，在图3中略去了列式存储和分区的相关信息，只关注存储某个字段的Block和表模式配置文件的关系。在图3中可以看到表SRC_DEVICE_LOG中的4个Block分别对应多个表模式配置文件，如Block1对应表模式配置文件1，则说明Block1里的数据是属于表模式1；而Block2、Block3对应表模式配置文件2，就说明Block2和Block3里存储的数据是属于表模式2的。以此类推，每个列的不同Block都将属于不同的版本，而相同的Block将会关联相同的表模式配置文件。

由上述技术方案可知，本发明实施例公开的面向Hive的多模式数据处理方法，提供了一种基于表模式进行不同表结构管理的思想。本实施例首先将Hive表中的数据按列存储，即将每张Hive表对应的列的数据分别进行存储；接着对于每个列的数据将按分区和表模式存储进Hadoop的Block中，其中，表模式表示表的结构信息，即数据表的字段，一种表结构就是一个表模式。同时，本实施例明确了一个Block只会属于一个数据分区，且一个Block也只存储一个表模式的数据；此外，本实施例设计了一种简易的表模式配置文件，用于定义和描述表的模式，以支撑不同表模式数据的读取，由此可见，本实施例提供的面向Hive的多模式数据处理方法，可以自由应对数据仓库中数据结构的变更，通过配置不同的表模式使系统具有不同结构的数据，避免表结构发生变化时导致的数据迁移，降低了系统维护的开销；其次，本实施例提供的数据处理方法由于是基于表模式进行表结构的扩展和变更，因此具备较高的灵活性，一旦表结构变动，用户只需上传新的表配置文件并通过索引关联到数据，即可在有效地读取新结构的数据同时也可读取旧结构的数据。

进一步地，基于上述实施例的内容，为了使系统可以很方便地获取不同表模式的数据，本实施例设计了一种面向表的多维度索引结构。因此，在本实施例中，所述面向Hive的多模式数据处理方法，还包括：

根据每个Block对应的表标识、列标识、分区标识和表模式标识确定每个Block所属的表、Block所属的列、Block所属的分区和Block所属的表模式；

根据每个Block所属的表、Block所属的列、Block所属的分区和Block所属的表模式，为每个Block分别建立表维度、列维度、分区维度和表模式维度共四个维度下的键值对索引；其中，每个Block在四个维度下的键值对索引的Key值分别为相应Block对应的表标识、列标识、分区标识和表模式标识，每个Block在四个维度下的键值对索引的Value值均为相应Block的Block地址；

根据每个Block在四个维度下的键值对索引，建立四个维度下的键值对索引数据库；其中，每个维度下的键值对索引数据库中存储有相应维度下的键值对索引。

在本实施例中，需要说明的是，根据图2所示的本实施例的Hive表层级结构可知，存储数据的Block具有4个维度的属性，即Block所属的表、Block所属的列(字段)、Block所属的分区和Block所属的表模式。针对这四个维度分别去索引Block，形成了图4所示的索引结构。从图4中可以看出，本实施例针对不同的维度建立了不同的索引。如图4所示的表维度，即按照不同的表来索引Block，本实施例设计一种Key-Value键值对来存储表名与存储该表数据的Block的地址之间的关联。其中Key是表名称，而Value则是关联Block在Hadoop集群中的存储地址。图4中“表1-Block1”就是表1的第一个Block，“表1-Block2”就是表2的地2个Block。与表维度相似，列维度、分区维度和表模式维度则分别索引了不同列、分区和表模式的数据。此外，需要说明的是，本实施例中在对表索引进行管理时可以引入Redis，将索引放在Redis里进行管理，不过由于该部分内容属于现有技术，因此，本实施例对于将索引放在Redis里进行管理的过程不再详述。

本实施例之所以设计多维度索引结构主要是为了做到以下两点：一是为了支撑不同的数据获取需求，通过本实施例设计的针对多维度的索引，用户可以灵活地指定查询条件，例如，用户可以指定要查询哪张表的哪个字段的哪个分区的哪个模式的数据。举例来说，在进行数据查询时，可以先查各个维度的索引，再将各个维度的查询结果按Block的地址取交集，即得到了用户想要的数据。二是为了方便存储与扩展，本实施例设计的索引结构以Key-Value键值对进行存储，可以便于存放在NameNode的内存里，以提升查询效率。

进一步地，基于上述实施例所述的多维度索引结构内容，在本实施例中，基于该多维度索引结构，给出了基于多维度索引的数据查询流程，具体地，所述数据查询流程包括：

获取待查数据的查询条件；其中，所述查询条件中包括表标识、列标识、分区标识和表模式标识；

根据查询条件中的表标识、列标识、分区标识和表模式标识，分别查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址；

对四个维度下的Block地址求取交集，获取与待查数据对应的Block地址；

根据与待查数据对应的Block地址获取待查数据。

在本实施例中，需要说明的是，如图5所示数据查询流程示意图，系统会先读取用户的查询条件，包括查询的表名称、列名称、分区信息和表模式信息，然后根据表名称、列名称、分区信息和表模式信息分别查询各个维度的数据，最后待各个维度的数据查询完毕后，对各个维度查询结果中的Block地址求交集，只保留Block地址相同的，即得到用户查询数据的Block存储位置，再到相应位置进行数据的读取。

进一步地，基于上述实施例的内容，为提高数据查询效率，在查询时可以用多线程的方式并行地去查各个维度的索引，因此，在本实施例中，所述根据查询条件中的表标识、列标识、分区标识和表模式标识，分别查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址，具体包括：

启动第一线程、第二线程、第三线程和第四线程；

分别为第一线程、第二线程、第三线程和第四线程分配表维度、列维度、分区维度和表模式维度下的Block地址查询任务，使得第一线程、第二线程、第三线程和第四线程根据查询条件中的表标识、列标识、分区标识和表模式标识，并行地查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址。

在本实施例中，为提高数据查询效率，在查询时可以用多线程的方式并行地去查各个维度的索引，再将各个维度的查询结果按Block的地址取交集，即得到了用户想要的数据。具体查询流程如下：系统读取用户的查询条件，包括查询的表名称、列名称、分区信息和表模式信息；系统启动多个线程，线程个数由表索引的维度数来确定；同时每个线程会被分配自己要查询的维度；启动的线程会并行地查询各个维度的数据；待各个线程查询完毕后，根据各个线程查询结果中的Block地址求交集，只保留Block地址相同的，即得到用户查询数据的Block存储位置，再到相应位置进行数据的读取。

进一步地，基于上述实施例的内容，为了应对不同数据模式的读取，结合上述设计的表模式配置文件本实施例设计一种多模式数据读取接口，因此，在本实施例中，所述面向Hive的多模式数据处理方法，还包括：

为每个表模式对应生成一个表模式配置文件，所述表模式配置文件用于描述所述表模式下的表字段信息；

在Hadoop中的NameNode节点，将所有的表模式配置文件加载入内存进行统一管理；

在Hadoop中的每个DataNode均部署一个数据读取接口，所述数据读取接口用于读取待查数据的查询条件中的表模式标识，并根据所述表模式标识从NameNode节点获取相应的表模式配置文件，通过解析相应的表模式配置文件，获取相应表模式下的表字段信息，并根据获取到的表字段信息读取相应的字段。

在本实施例中，如图3所示，表SRC_DEVICE_LOG中的4个Block分别对应多个表模式配置文件，如Block1对应表模式配置文件1，则说明Block1里的数据是属于模式1；而Block2、Block3对应表模式配置文件2，就说明Block2和Block3里存储的数据是属于模式2的。以此类推，每个列的不同Block都将属于不同的版本，而相同的Block将会关联相同的表模式配置文件，基于这一点本实施例设计一种数据读取接口，可以根据Block关联的表模式配置文件来读取数据，将根据不同的表模式来决定不同的读取方式。综上，本实施例所设计的数据存储结构如图6所示。从图6中可以看出，可以从两个维度来看本实施例设计的存储方式，第一个是按列存储(按表字段)的维度，图中同一张Hive表的不同字段各自对应了不同版本的Block，这些Block分散存储在Hadoop集群里，根据表的定义可以获取这些数据的分区信息；第二个维度是按表模式，在图6中可以看出不同字段的Block可以拥有相同的表模式，这使可以很方便地获取同一模式下的数据。当数据仓库要使用的数据模式发生变化时，本实施例的设计可以保证所有的被使用的数据都来自同一个表模式的版本，即具有相同的数据结构，从而消除了表模式变更所带来的额外开销。在本实施例中，为了应对不同数据模式的读取，结合上述设计的表模式配置文件本实施例设计一种多模式数据读取接口。该数据读取接口由表模式存储、表模式解析和数据读取这三个功能模块组成，其结构如图7所示。从图7中可以看出，在Hadoop中的NameNode节点，将表模式配置文件加载入内存进行统一管理。而在Hadoop集群中每个DataNode都会部署一个数据读取接口，它包括模式解析模块和数据读取模块。在读取数据的时候模式解析模块会根据数据读取请求中的表模式信息从NameNode节点获取表模式配置文件，接着解析表模式配置文件，得到该模式下数据的字段信息。数据读取模块将会根据解析得到的表模式读取数据，不同的模式将会读取不同的表字段。这样无论是表的字段个数发生改变还是表字段名称发生改变，系统只需解析不同的表模式配置文件就可以读取不同结构的数据，具有较高地灵活性。数据读取接口的读取流程如图8所示：系统获取用户查询条件中的表模式信息；根据用户提供的表模式信息去NameNode节点中获取相应的表模式配置文件；数据读取接口解析表模式配置文件，得到数据的具体的模式信息，即读取那些字段的数据；数据读取模块进行数据读取，读取时将会根据解析得到的表模式进行读取。

下面结合图9所示的多模式数据读取方法流程图对本实施例提供的数据处理方法进行详细解释说明。如图9所示，本实施例提供的多模式数据读取方法可按照如下过程实施：

S1、系统读取用户的数据获取请求，除了Hive的SQL语句外，用户还需指定需要获取数据的表模式信息，可以用本实施例中设计的表模式ID作为表模式信息的标识传给系统；

S2、系统对用户的数据获取请求进行解析，解析出用户所需数据的表的名称、列的名称、分区信息和表模式ID；

S3、根据本实施例设计的索引来获取用户所要数据的存储地址，在这一步已经完成了表、列、分区和模式的过滤；

S4、根据系统获得的模式信息读取相应的数据返回给用户请求。

根据上面描述可知，本实施例设计了一种面向Hive的多模式数据处理方法。首先，本实施例设计了一种面向列与表模式的存储方法，使存储数据的Block属于特定的表、列、分区和表模式；接着，本实施例设计了一种简易的表模式配置文件，用于定义表的模式，以支撑不同表模式数据的读取；之后，本实施例设计了面向表的多维度索引，将不同分区不同模式的数据有效组织起来，并提供了一种高效地索引查询方法；最后，本实施例设计了基于表模式的数据读取接口，用于支撑不同模式数据的读取，适应了表模式的变化，降低了不同结构数据管理的开销。需要说明的是，本实施例提供的数据处理方法相对于现有技术具有如下优点：首先，本实施例设计的多模式数据处理方法可以有效应对数据仓库中数据结构的变更，通过配置不同的表模式使系统具有不同结构的数据，避免表结构发生变化时导致的数据迁移，降低了系统维护的开销；其次，本实施例的设计的多模式数据处理方法为基于表模式的数据处理方法，具备较高的灵活性，一旦表结构变动，用户只需上传新的表配置文件并通过索引关联到数据，即可在有效地读取新结构的数据同时也可读取旧结构的数据；最后，在保证灵活性的同时，本实施例的设计保证了系统处理数据的高效性，本实施例设计的索引和数据读取接口都是基于内存的，具有较高的访问效率。

本实施例提供的多模式数据处理方法被实际应用证明是可行且有效的。在某公司统一结算业务的开发过程中，伴随着子公司业务的调整，Hive库里表结构也需要调整，而每次Hive表结构的调整都会进行数据迁移等耗费巨大的操作，而采用本实施例提供的方法后，消除了这种数据结构变更所带来的额外开销，因此，本实施例提供的方法被证明是可行且有效的。

图10示出了本发明实施例提供的面向Hive的多模式数据处理装置的结构示意图。如图10所示，本发明实施例提供的面向Hive的多模式数据处理装置包括：第一处理模块21、第二处理模块22和第三处理模块23，其中：

第一处理模块21，用于将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储；

第二处理模块22，用于根据预设分区定义，将每列的数据划分为属于不同分区的分区数据；

第三处理模块23，用于将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；其中，每个Block对应一个表标识、列标识、分区标识和表模式标识；其中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式。

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

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

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

所述处理器301用于调用所述存储器302中的计算机程序，所述处理器执行所述计算机程序时实现上述面向Hive的多模式数据处理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储；根据预设分区定义，将每列的数据划分为属于不同分区的分区数据；将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；其中，每个Block对应一个表标识、列标识、分区标识和表模式标识；其中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式。

基于相同的发明构思，本发明又一实施例提供了一种非暂态计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述面向Hive的多模式数据处理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储；根据预设分区定义，将每列的数据划分为属于不同分区的分区数据；将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；其中，每个Block对应一个表标识、列标识、分区标识和表模式标识；其中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式。

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

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

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

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

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

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

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

Claims (9)

1.一种面向Hive的多模式数据处理方法，其特征在于，包括：

将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储；

根据预设分区定义，将每列的数据划分为属于不同分区的分区数据；

将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；其中，每个Block对应一个表标识、列标识、分区标识和表模式标识；其中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式；

根据每个Block对应的表标识、列标识、分区标识和表模式标识确定每个Block所属的表、Block所属的列、Block所属的分区和Block所属的表模式；

根据每个Block所属的表、Block所属的列、Block所属的分区和Block所属的表模式，为每个Block分别建立表维度、列维度、分区维度和表模式维度共四个维度下的键值对索引；其中，每个Block在四个维度下的键值对索引的Key值分别为相应Block对应的表标识、列标识、分区标识和表模式标识，每个Block在四个维度下的键值对索引的Value值均为相应Block的Block地址；

根据每个Block在四个维度下的键值对索引，建立四个维度下的键值对索引数据库；其中，每个维度下的键值对索引数据库中存储有相应维度下的键值对索引。

2.根据权利要求1所述的面向Hive的多模式数据处理方法，其特征在于，还包括：

获取待查数据的查询条件；其中，所述查询条件中包括表标识、列标识、分区标识和表模式标识；

根据查询条件中的表标识、列标识、分区标识和表模式标识，分别查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址；

对四个维度下的Block地址求取交集，获取与待查数据对应的Block地址；

根据与待查数据对应的Block地址获取待查数据。

3.根据权利要求2所述的面向Hive的多模式数据处理方法，其特征在于，所述根据查询条件中的表标识、列标识、分区标识和表模式标识，分别查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址，具体包括：

启动第一线程、第二线程、第三线程和第四线程；

分别为第一线程、第二线程、第三线程和第四线程分配表维度、列维度、分区维度和表模式维度下的Block地址查询任务，使得第一线程、第二线程、第三线程和第四线程根据查询条件中的表标识、列标识、分区标识和表模式标识，并行地查询所述四个维度下的键值对索引数据库，获取四个维度下的Block地址。

4.根据权利要求1所述的面向Hive的多模式数据处理方法，其特征在于，还包括：

为每个表模式对应生成一个表模式配置文件，所述表模式配置文件用于描述所述表模式下的表字段信息；

在Hadoop中的NameNode节点，将所有的表模式配置文件加载入内存进行统一管理；

在Hadoop中的每个DataNode均部署一个数据读取接口，所述数据读取接口用于读取待查数据的查询条件中的表模式标识，并根据所述表模式标识从NameNode节点获取相应的表模式配置文件，通过解析相应的表模式配置文件，获取相应表模式下的表字段信息，并根据获取到的表字段信息读取相应的字段。

5.根据权利要求4所述的面向Hive的多模式数据处理方法，其特征在于，所述表模式配置文件包括：表模式标识、表模式适用的Hive表、表模式包含的字段的名称、字段的数据类型和字段的位置编号。

6.根据权利要求5所述的面向Hive的多模式数据处理方法，其特征在于，所述表模式配置文件为基于yaml文件格式的表模式配置文件。

7.一种面向Hive的多模式数据处理装置，其特征在于，包括：

第一处理模块，用于将Hive表中的数据，按照每列对应存储一个字段的数据的方式存储；

第二处理模块，用于根据预设分区定义，将每列的数据划分为属于不同分区的分区数据；

第三处理模块，用于将属于不同表模式的分区数据分别存储至Hadoop的不同Block中；其中，每个Block对应一个表标识、列标识、分区标识和表模式标识；其中，所述表模式用于表征所述Hive表的表结构属性，且每当所述Hive表的表结构发生变化时产生新的表模式；

根据每个Block对应的表标识、列标识、分区标识和表模式标识确定每个Block所属的表、Block所属的列、Block所属的分区和Block所属的表模式；

根据每个Block所属的表、Block所属的列、Block所属的分区和Block所属的表模式，为每个Block分别建立表维度、列维度、分区维度和表模式维度共四个维度下的键值对索引；其中，每个Block在四个维度下的键值对索引的Key值分别为相应Block对应的表标识、列标识、分区标识和表模式标识，每个Block在四个维度下的键值对索引的Value值均为相应Block的Block地址；

根据每个Block在四个维度下的键值对索引，建立四个维度下的键值对索引数据库；其中，每个维度下的键值对索引数据库中存储有相应维度下的键值对索引。

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

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