Every record in Hudi is uniquely identified by a primary key, which is a pair of record key and partition path where
the record belongs to. Using primary keys, Hudi can impose a) partition level uniqueness integrity constraint
b) enable fast updates and deletes on records. One should choose the partitioning scheme wisely as it could be a
determining factor for your ingestion and query latency.
In general, Hudi supports both partitioned and global indexes. For a dataset with partitioned index(which is most
commonly used), each record is uniquely identified by a pair of record key and partition path. But for a dataset with
global index, each record is uniquely identified by just the record key. There won’t be any duplicate record keys across
Hudi provides several key generators out of the box that users can use based on their need, while having a pluggable
implementation for users to implement and use their own 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.