一种Iceberg中数据处理方法、装置、存储介质及设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种Iceberg中数据处理方法、装置、存储介质及设备。

背景技术

Iceberg是目前比较流行的数据湖技术框架之一，提供了一种独立的数据组织方式，可实现大数据场景下数据的添加、删除、修改、查询等处理操作。

目前，Iceberg是通过元数据文件(manifest)为表实现了各种数据处理功能，Iceberg表结构示意图如图1所示。目前在Iceberg中执行数据修改、删除、查询等处理操作时，处理流程通常为：元数据文件(metadata file)->元数据文件列表(mamifest list)->元文件(manifest file)->数据文件(data file)，通过这四层处理才能获取到data file的列表信息。然后再通过遍历读取所有data file，查看是否存在与待查询数据相匹配的数据，导致整体查询速率较慢，数据的处理性能较差。

发明内容

本申请实施例的主要目的在于提供一种Iceberg中数据处理方法、装置、存储介质及设备，能够在Iceberg中利用分桶(bucket)功能快速实现数据的处理(如数据的添加、删除、修改、查询等)操作，从而提高了Iceberg中数据的处理效率。

本申请实施例提供了一种Iceberg中数据处理方法，包括：

在创建Iceberg数据表时，在所述数据表的元数据文件中添加分桶信息；

在所述Iceberg中执行目标数据的处理操作时，根据所述分桶信息，对所述目标数据进行列级别的哈希计算，得到哈希值；

根据所述哈希值，结合所述分桶信息，确定目标分桶，并在所述目标分桶中进行相应的数据处理操作，得到数据处理结果。

一种可能的实现方式中，所述在所述Iceberg中执行目标数据的处理操作时，根据所述分桶信息，对所述目标数据进行列级别的哈希计算，得到哈希值，包括：

在所述Iceberg中执行目标数据的插入操作时，根据所述分桶的数量，对所述目标数据进行列级别的哈希计算，得到哈希值；

所述根据所述哈希值，结合所述分桶信息，确定目标分桶，并在所述目标分桶中进行相应的数据处理操作，得到数据处理结果，包括：

根据所述哈希值，结合所述分桶的数量，确定目标分桶，并将所述目标数据写入所述目标分桶的数据文件中。

一种可能的实现方式中，所述在所述Iceberg中执行目标数据的处理操作时，根据所述分桶信息，对所述目标数据进行列级别的哈希计算，得到哈希值，包括：

在所述Iceberg中执行目标数据的查询操作时，根据所述分桶的数量，对所述目标数据的查询语句进行列级别的哈希计算，得到哈希值；

所述根据所述哈希值，结合所述分桶信息，确定目标分桶，并在所述目标分桶中进行相应的数据处理操作，得到数据处理结果，包括：

将所述哈希值与所述分桶的值进行匹配，将匹配成功的分桶确定为目标分桶，并从所述目标分桶的数据文件中查询所述目标数据，得到查询结果。

一种可能的实现方式中，所述方法还包括：

当检测到所述Iceberg中分桶的容量不满足第一预设条件时，对所述分桶信息进行修改，并保存修改后的分桶信息；

在所述Iceberg中执行新增数据的插入操作时，按照修改后的分桶信息，计算新增数据列级别的哈希值，并根据所述哈希值，将所述新增数据写入修改后的分桶的数据文件中，实现动态分桶。

一种可能的实现方式中，所述方法还包括：

获取所述Iceberg中的历史数据及其所属的分桶信息；

当所述历史数据所属的分桶信息不满足第二预设条件时，根据所述第二预设条件对所述分桶信息进行刷新处理，得到刷新后的分桶信息。

一种可能的实现方式中，所述方法还包括：

在所述Iceberg的元数据文件中添加支持按照区间范围分桶的功能，更新所述Iceberg的分区信息和分桶信息；

在所述Iceberg中执行目标数据的插入和/或查询操作时，根据所述Iceberg中更新后的分区信息和分桶信息，确定目标数据文件，并对所述目标数据文件进行相应的数据处理操作，得到处理结果。

一种可能的实现方式中，所述方法还包括：

记录所述Iceberg中的历史数据列级别的查询信息；

根据所述历史数据列级别的查询信息，判断历史数据列级别的数据量是否超过预设阈值，若是，则对所述历史数据进行列级别的重新分桶，并在更新后的分桶中进行数据处理操作。

本申请实施例还提供了一种Iceberg中数据处理装置，所述装置包括：

添加单元，用于在创建Iceberg数据表时，在所述数据表的元数据文件中添加分桶信息；

计算单元，用于在所述Iceberg中执行目标数据的处理操作时，根据所述分桶信息，对所述目标数据进行列级别的哈希计算，得到哈希值；

处理单元，用于根据所述哈希值，结合所述分桶信息，确定目标分桶，并在所述目标分桶中进行相应的数据处理操作，得到数据处理结果。

一种可能的实现方式中，所述计算单元具体用于：

在所述Iceberg中执行目标数据的插入操作时，根据所述分桶的数量，对所述目标数据进行列级别的哈希计算，得到哈希值；

所述处理单元具体用于：

根据所述哈希值，结合所述分桶的数量，确定目标分桶，并将所述目标数据写入所述目标分桶的数据文件中。

一种可能的实现方式中，所述计算单元具体用于：

在所述Iceberg中执行目标数据的查询操作时，根据所述分桶的数量，对所述目标数据的查询语句进行列级别的哈希计算，得到哈希值；

所述处理单元具体用于：

将所述哈希值与所述分桶的值进行匹配，将匹配成功的分桶确定为目标分桶，并从所述目标分桶的数据文件中查询所述目标数据，得到查询结果。

一种可能的实现方式中，所述装置还包括：

修改单元，用于当检测到所述Iceberg中分桶的容量不满足第一预设条件时，对所述分桶信息进行修改，并保存修改后的分桶信息；

写入单元，用于在所述Iceberg中执行新增数据的插入操作时，按照修改后的分桶信息，计算新增数据列级别的哈希值，并根据所述哈希值，将所述新增数据写入修改后的分桶的数据文件中，实现动态分桶。

一种可能的实现方式中，所述装置还包括：

获取单元，用于获取所述Iceberg中的历史数据及其所属的分桶信息；

刷新单元，用于当所述历史数据所属的分桶信息不满足第二预设条件时，根据所述第二预设条件对所述分桶信息进行刷新处理，得到刷新后的分桶信息。

一种可能的实现方式中，所述装置还包括：

更新单元，用于在所述Iceberg的元数据文件中添加支持按照区间范围分桶的功能，更新所述Iceberg的分区信息和分桶信息；

确定单元，用于在所述Iceberg中执行目标数据的插入和/或查询操作时，根据所述Iceberg中更新后的分区信息和分桶信息，确定目标数据文件，并对所述目标数据文件进行相应的数据处理操作，得到处理结果。

一种可能的实现方式中，所述装置还包括：

记录单元，用于记录所述Iceberg中的历史数据列级别的查询信息；

分桶单元，用于根据所述历史数据列级别的查询信息，判断历史数据列级别的数据量是否超过预设阈值，若是，则对所述历史数据进行列级别的重新分桶，并在更新后的分桶中进行数据处理操作。

本申请实施例还提供了一种Iceberg中数据处理设备，包括：处理器、存储器、系统总线；

所述处理器以及所述存储器通过所述系统总线相连；

所述存储器用于存储一个或多个程序，所述一个或多个程序包括指令，所述指令当被所述处理器执行时使所述处理器执行上述Iceberg中数据处理方法中的任意一种实现方式。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备执行上述Iceberg中数据处理方法中的任意一种实现方式。

本申请实施例提供的一种Iceberg中数据处理方法、装置、存储介质及设备，首先在创建Iceberg数据表时，在数据表的元数据文件中添加分桶信息，然后，在Iceberg中执行目标数据的处理操作时，根据分桶信息，对目标数据进行列级别的哈希计算，得到哈希值；接着，可以根据该哈希值，结合分桶信息，确定目标分桶，并在目标分桶中进行相应的数据处理操作，得到最终的数据处理结果。可见，由于本申请是先在创建Iceberg表时，在元数据中添加了分桶信息，这样，新增数据可以按照列级别的哈希值存储到不同的分桶中，并且，在进行数据更新、删除、查询等操作时，也不再不局限于分区表，通过列级别的分桶值，可以更加快速查询出数据位置，从而能够提高Iceberg中数据的处理效率。

附图说明

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

图1为本申请实施例提供的Iceberg表结构的示意图；

图2为本申请实施例提供的现有Iceberg表结构中实现数据查询的示例图；

图3为本申请实施例提供的一种Iceberg中数据处理方法的流程示意图；

图4为本申请实施例提供的在创建Iceberg数据表时，在数据表的元数据文件中添加分桶信息的示例图；

图5为本申请实施例提供的在Iceberg中执行目标数据的插入操作的过程示例图；

图6为本申请实施例提供的在Iceberg中执行目标数据的查询操作的过程示例图；

图7为本申请实施例提供的支持动态分桶的示例图；

图8为本申请实施例提供的Iceberg表结构中实现数据查询的示例图；

图9为本申请实施例提供的一种Iceberg中数据处理装置的组成示意图。

具体实施方式

Iceberg是一种表格格式，具有与传统数据库中结构化查询语言(StructuredQuery Language，SQL)表类似的功能，但采用的是完全开放和可访问的方式，通过元数据文件(manifest)为表实现了许多功能，如：通过时间旅行查询历史数据，验证数据版本之间的变化；整体计划和过滤功能等。如图1所示，这些元数据文件是通过时间点快照跟踪，在表随时间更新时维护所有增量。每个快照都提供表的模式、分区和文件信息的完整描述，并提供完全的隔离和一致性。此外，Iceberg以层次结构智能地组织快照元数据。这样就可以在不重新定义所有数据集文件的情况下快速有效地更改表，从而确保在数据湖规模下工作时的最佳性能。

在使用Iceberg时，完整的历史记录是在Iceberg的元数据文件(metadata file)中维护的，没有存储系统依赖关系。支持开放的体系结构和随时间改变系统的灵活性，而不会对用户或现有工作负载造成干扰。由于历史状态是不可变的，并且历史来源是清晰的，用户可以在任何Iceberg快照或任何历史时间点查询以前的状态，以获得一致的结果、比较或回滚数据，以纠正问题。

数据分布方面，可以是将数据划分为子集，按一定规则，均衡地分布在不同节点上，以期最大限度地利用集群的并发性能。目前在Iceberg中，通常采用的数据分桶(bucket)方式是采用哈希(Hash)算法进行分桶，即通过对数据内容进行哈希计算后，将一致的哈希值对应的数据写入同一分桶中。

但目前Iceberg中只支持分区级别的分桶功能，即，通过对数据的列值取哈希值的方式，将不同数据写入不同分桶的数据文件(data file)中存储，以列的哈希值除以桶的个数来决定每条数据划分在哪个桶中。这种数据处理方式存在三个缺点：一是仅能实现实时将bucket信息添加到分区(partition)的元数据中，所以只能支持分区表。二是不支持动态分桶，即不支持修改bucket信息。三是只能设定固定的分桶个数，可能会造成数据的倾斜问题。

并且，由于Iceberg表结构是采用如图1所示的结构，导致在Iceberg中执行数据修改、删除、查询等处理操作时，需要经过四层处理流程，具体为：元数据文件(metadatafile)->元数据文件列表(mamifest list)->元文件(manifest file)->数据文件(datafile)，通过这四层处理之后才能获取到data file的列表信息。然后再通过遍历读取所有data file，查看是否存在与待查询数据相匹配的数据，导致整体查询速率较慢，数据的处理性能较差。

举例说明：目前对于Iceberg中的数据处理语句“update table set column_1＝1where coLumn_2＝′A′”来说，需要遍历Iceberg中所有的data file文件列表，并在读取所有data file后，查看其中的内容是否含有column_2＝′A′的数据，如图2所示，可能查询出第一个和第三个具有“√”标识的data file为含有column_2＝′A′的数据，其他具有“X”标识的data file并不是含有column_2＝′A′的数据，整体查询速率较慢。

为解决上述缺陷，本申请提供了一种Iceberg中数据处理方法，首先在创建Iceberg数据表时，在数据表的元数据文件中添加分桶信息，然后，在Iceberg中执行目标数据的处理操作时，根据分桶信息，对目标数据进行列级别的哈希计算，得到哈希值；接着，可以根据该哈希值，结合分桶信息，确定目标分桶，并在目标分桶中进行相应的数据处理操作，得到最终的数据处理结果。可见，由于本申请是先在创建Iceberg表时，在元数据中添加了分桶信息，这样，新增数据可以按照列级别的哈希值存储到不同的分桶中，并且，在进行数据更新、删除、查询等操作时，也不再不局限于分区表，通过列级别的分桶值，可以更加快速查询出数据位置，从而能够提高Iceberg中数据的处理效率。

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

第一实施例

参见图3，为本实施例提供的一种Iceberg中数据处理方法的流程示意图，该方法包括以下步骤：

S301：在创建Iceberg数据表时，在数据表的元数据文件中添加分桶信息。

需要说明的是，Iceberg是一种数据表格式，在创建iceberg数据表时，可以指定bucket的字段和分桶个数等分桶信息，并且，Iceberg可以将这些分桶信息中存入Iceberg数据表的元数据文件(metadata file)中，如图4所示，用以执行后续步骤S302。其中，分桶信息包含的内容本申请不做限制，比如可以包含分桶表字段或者分桶最大个数等。

举例说明：在创建Iceberg数据表时，可以指定分桶信息的代码如下：

create table fentong(

id int，

name string，

age int，)clustered by(age)into 4 buckets；

其中，定义了分桶的表为“fentong”和分桶最大个数为“4”。

进一步的，可以在Iceberg数据表的元数据文件(metadata file)中记录上述定义的分桶(bucket)信息，如图4所示，具体代码如下：

{″default-bucket-spec-id″：0，

″bucket-specs″：[{

″spec-id″：0，

″fields″：[{

″name″：″ts_day″，

″transform″：″day″，

″source-id″：3，

″bucket-number″：2

}，{

″name″：″category″，

″transform″：″identity″，

″source-id″：2，

″bucket-number″：6

}]

}]，

S302：在Iceberg中执行目标数据的处理操作时，根据分桶信息，对目标数据进行列级别的哈希计算，得到哈希值。

在本实施例中，通过步骤S301在Iceberg数据表的元数据文件中添加了分桶信息后，进一步可以在Iceberg中执行目标数据的处理操作(如数据的添加、删除、修改、查询等)时，根据已添加的分桶信息，对目标数据进行列(Column)级别的哈希计算，得到哈希值，用以执行后续步骤S303。

其中，目标数据指的是利用本申请提供的数据处理方法在Iceberg中实现处理任意数据。并且，本申请不限制目标数据的数量、内容以及构成格式等信息。

S303：根据哈希值，结合分桶信息，确定目标分桶，并在目标分桶中进行相应的数据处理操作，得到数据处理结果。

在本实施例中，通过步骤S302对目标数据进行列级别的哈希计算，得到哈希值后，进一步可以根据得到的哈希值，结合分桶信息(如分桶的个数等)，确定出目标分桶，并在目标分桶的数据文件(data file)中进行相应的数据处理操作，得到最终的数据处理结果。

具体来讲，一种可选的实现方式是，当在Iceberg中执行目标数据的插入(insert)操作时，首先可以根据分桶的数量，对目标数据进行列级别的哈希计算，得到哈希值，然后再根据该哈希值，结合分桶的数量，确定目标分桶，并将目标数据写入目标分桶的数据文件中。

举例说明：基于上述图4举例，假设分桶最大个数为4，且目标数据为数据1、数据2、数据3、数据4、数据5，则如图5所示，可以根据分桶数量，对数据1、数据2、数据3、数据4、数据5分别进行列级别的哈希计算，得到数据1、数据2、数据3、数据4、数据5各自对应的哈希值，其中，数据1和数据2对应的哈希值是一致的，且与分桶1的哈希值相同；数据3和数据4对应的哈希值是一致的，且与分桶2的哈希值相同；数据5对应的哈希值与其他四个数据对应的哈希值是不一致的，且与分桶3的哈希值相同。由此，可以将分桶1、分桶2、分桶3确定为目标分桶，并将数据1和数据2写入分桶1中创建的数据文件(data file)中。将数据3和数据4写入分桶2中创建的数据文件(data file)中。以及将数据5写入分桶3中创建的数据文件(data file)中。

另一种可选的实现方式是，当在Iceberg中执行目标数据的查询(select)操作时，首先可以根据分桶的数量，对目标数据的查询语句进行列级别的哈希计算，得到哈希值，然后再将该哈希值与分桶的值进行匹配，将匹配成功的分桶确定为目标分桶，并从目标分桶的数据文件中查询出目标数据，得到查询结果。

举例说明：基于上述图4举例，在Iceberg中执行数据处理语句“select*fromwhere column_2＝′A′”时，分桶最大个数为4，则如图6所示，可以根据分桶数量，对′A′进行列级别的哈希计算，得到哈希值。再将该哈希值与分桶的值进行匹配，将匹配成功(即哈希值一致)的分桶确定为目标分桶，并从目标分桶查询出where column_2＝′A′所在的数据文件中的目标数据，得到查询结果。比如可以将匹配成功(即哈希值一致)的分桶1确定为目标分桶，并将分桶1的数据文件(data file)中的数据1和数据2作为查询结果。

需要说明的是，对于在Iceberg中执行删除、修改等其他数据处理操作均可参考上述数据插入或查询的实现方式执行即可，在此不再一一赘述。

这样，通过在创建Iceberg表时，在元数据中添加了分桶信息，新增数据可以按照列级别的哈希值存储到不同的分桶中，并且，在进行数据更新、删除、查询等操作时，也不再不局限于分区表，通过列级别的分桶值，可以更加快速查询出数据位置，从而能够提高Iceberg中数据的处理效率。

此外，为了实现数据更加均匀分布，减少出现数据倾斜的问题，一种可选的实现方式是，当检测到Iceberg中分桶的容量不满足第一预设条件时，可以对分桶信息进行修改，并保存修改后的分桶信息。进而当在Iceberg中执行新增数据的插入操作时，可以按照修改后的分桶信息，计算新增数据列级别的哈希值，并根据该哈希值，将新增数据写入修改后的分桶的数据文件中，实现动态分桶。

需要说明的是，由于在创建Iceberg数据表时，已指定了bucket数目，虽然在功能实现上比较简单。但当不确定数据量和数据分布情况下，可能存在bucket数目不够合理的情况。此时，需要更改bucket信息，这样对于新增的数据，才可以按照更改后的bucket信息进行插入。并且，更改后的bucket信息也需要记录在Iceberg数据表的元数据文件中，并采用bucket-specs来维护。

具体来讲，在本实现方式中，当检测到Iceberg中分桶的容量不满足第一预设条件(可根据实际情况进行设定，本申请不进行限定，比如可以将第一预设条件设定为最大容量不大于10GB等)时，如，当检测到Iceberg中某分桶的容量超过10GB时，需要对分桶信息进行修改，如将分桶的数量由5个扩展到7个，并保存修改后的分桶信息。这样，在进行数据插入操作时，可以按照修改后的分桶信息，计算新增数据列级别的哈希值，并根据该哈希值，将新增数据写入修改后的分桶的数据文件中，实现动态分桶。比如，如图7所示，在第一次插入数据存在共5个分桶，对分桶信息进行修改后，得到了7个分桶，这样，在第二次插入数据时，可以将数据写入最多7个不同的分桶中。

需要说明的是，对于在Iceberg中执行修改、删除、查询等其他数据处理操作均可参考上述数据插入的实现方式执行，实现动态分桶，以保证数据更加均匀分布，减少出现数据倾斜的问题，在此不再一一赘述。

另一种可选的实现方式是，还可以获取Iceberg中的历史数据及其所属的分桶信息，当历史数据所属的分桶信息不满足第二预设条件(可根据实际情况进行设定，本申请不进行限定，比如可以将第二预设条件设定为data file的最大存储量不大于1GB等)时，可以根据第二预设条件对分桶信息进行部分刷新处理，以得到刷新后的分桶信息。

具体来讲，在本实现方式中，当确定出历史数据所属的分桶信息不满足第二预设条件时，如果需要对其进行修改，在尽量降低成本的情况下，不再将所有历史数据重新计算一遍，按照最新的bucket信息来计算哈希值，而是进行部分数据的刷新功能，具体代码如下：

alter table set bucket(column，number)where条件。

其中，“条件”的具体取值可根据第二预设条件的内容来设定，本申请不进行限定，比如可以将其设定为data file的最大存储量等。

此外，为了进一步实现数据更加均匀分布，并减少出现数据倾斜的问题，一种可选的实现方式是，在Iceberg的元数据文件中添加支持按照区间范围分桶的功能，更新Iceberg的分区信息和分桶信息。进而在Iceberg中执行目标数据的插入和/或查询操作时，可以根据Iceberg中更新后的分区信息和分桶信息，确定目标数据文件，并对目标数据文件进行相应的数据处理操作，得到处理结果。

具体来讲，在本实现方式中，首先可以更改Iceberg原有的架构，在数据表的元数据文件(metadata file)中增加支持less than、more than的功能，然后，对表进行插入数据时，可以根据partition和bucket的信息，对数据进行分布，写入不同的data file中，并在元数据中记录到data file的信息，包括partition和bucket的值。以及，对表进行数据查询时，可以获取到data file列表后，根据partition和bucket的值过滤掉不需要的datafile。从而在进行联合查询时，可以将相同的partition和bucket的data file放在一个shuffle task中，进而较少了全局shuffle的代价，提高了查询性能。

举例说明：可以建立3个分区，第一个分区保存1月份之前的数据，第二个分区保存3月份之前的数据，第三个分区保存5月份之前的数据，每个分区中包括4个桶，具体代码如下：

create table fentong(

time date，

name string，

age int，

p String)clustered BY(age)into 4buckets

PARTITION by RANGE(time)

(

PARTITION p1VALUES LESS THAN(′2020-01-31′)，

PARTITION p2 VALUES LESS THAN(′2020-03-31′)，

这样，采用上述区间(range)和哈希结合(此处将其定义为range-hash)方式进行数据分布，可以较少数据的密集型，避免查询时出现数据倾斜。

而在数据表的元数据文件(metadata file)中增加支持less than、more than的功能实现代码如下：

″bucket-specs″：[{

″spec-id″：0，

″name″：age，

″number″：4

}]

″partition-specs″：[{

″spec-id″：0，

″fields″：[{

″name″：″p1″，

″transform″：″LESS THAN(′2020-01-31′)″，

″source-id″：1，

″field-id″：1000

}，{

″name″：″p2″，

″transform″：″LESS THAN(′2020-03-31′)″，

″source-id″：1，

″field-id″：1001

}，{

″name″：″p3″，

″transform″：″LESS THAN(′2020-05-31′)″，

″source-id″：1，

″rield-id″：1002

}]

}]，

另外，虽然能手动指定分桶的个数，使得插入的数据可以按照指定的分桶个数进行分桶。但在不清楚数据规模时，指定的分桶个数可能也不是最好的情况。对此，可以根据历史的数据情况和查询情况，实现对新数据的自动分桶。

在创建表时不指定分桶个数的情况下，一种可选的实现方式是，可以先记录Iceberg中的历史数据列级别的查询信息，包括但不限于Column名、Column的数据统计大小、对应的查询条件(如where Column＞10等)、以及表的总个数等。然后，根据历史数据列级别的查询信息，判断历史数据列级别的数据量是否超过预设阈值(可根据实际情况进行设定，本申请不进行限定)，若是，则对历史数据进行列级别的重新分桶，并在更新后的分桶中进行数据处理操作。

在本实现方式中，在获取到历史数据列级别的查询(query)信息后，如Column名、Column的数据统计大小、对应的查询条件以及表的总个数等。可以单独建立一个进程，来定期遍历前述的元数据，以获取到经常被访问的Column和对应的条件。如果数据量超过预设阈值时，可以对该Column进行分桶(如数据量小于10GB，可分4个桶，或者，如数据量小于50GB，可分3个桶等)，以便下次再进行数据插入时，可以按照最新的分桶参数进行分桶。接下来，进行query时，如果分桶后存在桶的数据量较大，则可以判断是否需要采用上述range-hash方式进行分桶，以规定不同的数据范围内存在不同的bucket情况，实现自动动态分桶。

为便于理解本申请提供的Iceberg中数据处理方法，区别于图2所示的在Iceberg表结构中实现数据查询的示例图，本申请提供了如图8所示的Iceberg表结构中实现数据查询的示例图。如图8所示，通过在元数据中添加bucket信息，可以在数据查询时，过滤掉一些data file，从而减少数据的读取量，提高数据查询效率。比如，对于Iceberg中的数据处理语句“update table set column_1＝1where column_2＝′A′”来说，不再需要遍历Iceberg中所有的data file文件列表，以在读取所有data file后，查看其中的内容是否含有column_2＝′A′的数据，而是如图8所示，可以以column_2字段做分桶，通过bucket的值，很简单的判断出column_2＝′A′，在哪个bucket中，进而可以读取该bucket中相应的datafile中的数据即可，如可以以column_2字段做分桶，通过bucket的值，很简单的判断出column_2＝′A′，在第一个具有“√”标识的bucket中，进而只需要读取第一个bucket中相应的data file中的数据即可，大幅提高了数据查询速率。

综上，本实施例提供的一种Iceberg中数据处理方法，首先在创建Iceberg数据表时，在数据表的元数据文件中添加分桶信息，然后，在Iceberg中执行目标数据的处理操作时，根据分桶信息，对目标数据进行列级别的哈希计算，得到哈希值；接着，可以根据该哈希值，结合分桶信息，确定目标分桶，并在目标分桶中进行相应的数据处理操作，得到最终的数据处理结果。可见，由于本申请实施例是先在创建Iceberg表时，在元数据中添加了分桶信息，这样，新增数据可以按照列级别的哈希值存储到不同的分桶中，并且，在进行数据更新、删除、查询等操作时，也不再不局限于分区表，通过列级别的分桶值，可以更加快速查询出数据位置，从而能够提高Iceberg中数据的处理效率。

第二实施例

本实施例将对一种Iceberg中数据处理装置进行介绍，相关内容请参见上述方法实施例。

参见图9，为本实施例提供的一种Iceberg中数据处理装置的组成示意图，该装置900包括：

添加单元901，用于在创建Iceberg数据表时，在所述数据表的元数据文件中添加分桶信息；

计算单元902，用于在所述Iceberg中执行目标数据的处理操作时，根据所述分桶信息，对所述目标数据进行列级别的哈希计算，得到哈希值；

处理单元903，用于根据所述哈希值，结合所述分桶信息，确定目标分桶，并在所述目标分桶中进行相应的数据处理操作，得到数据处理结果。

在本实施例的一种实现方式中，所述计算单元902具体用于：

在所述Iceberg中执行目标数据的插入操作时，根据所述分桶的数量，对所述目标数据进行列级别的哈希计算，得到哈希值；

所述处理单元903具体用于：

根据所述哈希值，结合所述分桶的数量，确定目标分桶，并将所述目标数据写入所述目标分桶的数据文件中。

在本实施例的一种实现方式中，所述计算单元902具体用于：

在所述Iceberg中执行目标数据的查询操作时，根据所述分桶的数量，对所述目标数据的查询语句进行列级别的哈希计算，得到哈希值；

所述处理单元903具体用于：

将所述哈希值与所述分桶的值进行匹配，将匹配成功的分桶确定为目标分桶，并从所述目标分桶的数据文件中查询所述目标数据，得到查询结果。

在本实施例的一种实现方式中，所述装置还包括：

修改单元，用于当检测到所述Iceberg中分桶的容量不满足第一预设条件时，对所述分桶信息进行修改，并保存修改后的分桶信息；

写入单元，用于在所述Iceberg中执行新增数据的插入操作时，按照修改后的分桶信息，计算新增数据列级别的哈希值，并根据所述哈希值，将所述新增数据写入修改后的分桶的数据文件中，实现动态分桶。

在本实施例的一种实现方式中，所述装置还包括：

获取单元，用于获取所述Iceberg中的历史数据及其所属的分桶信息；

刷新单元，用于当所述历史数据所属的分桶信息不满足第二预设条件时，根据所述第二预设条件对所述分桶信息进行刷新处理，得到刷新后的分桶信息。

在本实施例的一种实现方式中，所述装置还包括：

更新单元，用于在所述Iceberg的元数据文件中添加支持按照区间范围分桶的功能，更新所述Iceberg的分区信息和分桶信息；

确定单元，用于在所述Iceberg中执行目标数据的插入和/或查询操作时，根据所述Iceberg中更新后的分区信息和分桶信息，确定目标数据文件，并对所述目标数据文件进行相应的数据处理操作，得到处理结果。

在本实施例的一种实现方式中，所述装置还包括：

记录单元，用于记录所述Iceberg中的历史数据列级别的查询信息；

分桶单元，用于根据所述历史数据列级别的查询信息，判断历史数据列级别的数据量是否超过预设阈值，若是，则对所述历史数据进行列级别的重新分桶，并在更新后的分桶中进行数据处理操作。

进一步地，本申请实施例还提供了一种Iceberg中数据处理设备，包括：处理器、存储器、系统总线；

所述处理器以及所述存储器通过所述系统总线相连；

所述存储器用于存储一个或多个程序，所述一个或多个程序包括指令，所述指令当被所述处理器执行时使所述处理器执行上述Iceberg中数据处理方法的任一种实现方法。

进一步地，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备执行上述Iceberg中数据处理方法的任一种实现方法。

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

需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

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

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。