Every record in Hudi is uniquely identified by a HoodieKey, which is a pair of record key and partition path where the
record belongs to. Hudi has imposed this constraint so that updates and deletes can be applied to the record of interest.
Hudi relies on the partition path field to partition your dataset and records within a partition have unique record keys.
Since uniqueness is guaranteed only within the partition, there could be records with same record keys across different
partitions. One should choose the partition field wisely as it could be a determining factor for your ingestion and
Hudi exposes a number of out of the box key generators that customers can use based on their need. Or can have their
own implementation for the KeyGenerator. This blog goes over all different types of key generators that are readily
available to use.
is the interface for KeyGenerator in Hudi for your reference.
Before diving into different types of key generators, let’s go over some of the common configs required to be set for
Refers to record key field. This is a mandatory field.
Refers to partition path field. This is a mandatory field.
Refers to Key generator class(including full path). Could refer to any of the available ones or user defined one. This is a mandatory field.
When set to true, partition path will be url encoded. Default value is false.
When set to true, uses hive style partitioning. Partition field name will be prefixed to the value. Format: “=”. Default value is false.
There are few more configs involved if you are looking for TimestampBasedKeyGenerator. Will cover those in the respective section.
Lets go over different key generators available to be used with Hudi.
Record key refers to one field(column in dataframe) by name and partition path refers to one field (single column in dataframe)
by name. This is one of the most commonly used one. Values are interpreted as is from dataframe and converted to string.
Both record key and partition paths comprise one or more than one field by name(combination of multiple fields). Fields
are expected to be comma separated in the config value. For example "Hoodie.datasource.write.recordkey.field" : “col1,col4”
This key generator relies on timestamps for the partition field. The field values are interpreted as timestamps
and not just converted to string while generating partition path value for records. Record key is same as before where it is chosen by
field name. Users are expected to set few more configs to use this KeyGenerator.
This is a generic implementation of KeyGenerator where users are able to leverage the benefits of SimpleKeyGenerator,
ComplexKeyGenerator and TimestampBasedKeyGenerator all at the same time. One can configure record key and partition
paths as a single field or a combination of fields. This keyGenerator is particularly useful if you want to define
complex partition paths involving regular fields and timestamp based fields. It expects value for prop "hoodie.datasource.write.partitionpath.field"
in a specific format. The format should be “field1:PartitionKeyType1,field2:PartitionKeyType2…”
The complete partition path is created as
<value for field1 basis PartitionKeyType1>/<value for field2 basis PartitionKeyType2>
and so on. Each partition key type could either be SIMPLE or TIMESTAMP.
Example config value: “field_3:simple,field_5:timestamp”
RecordKey config value is either single field incase of SimpleKeyGenerator or a comma separate field names if referring to ComplexKeyGenerator.
Eg: “col1” or “col3,col4”.
If your hudi dataset is not partitioned, you could use this “NonPartitionedKeyGenerator” which will return an empty
partition for all records. In other words, all records go to the same partition (which is empty “”)
Hope this blog gave you a good understanding of different types of Key Generators available in Apache Hudi. Thanks for your continued support for Hudi’s community.