You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hudi.apache.org by "nsivabalan (via GitHub)" <gi...@apache.org> on 2023/04/10 19:35:22 UTC
[GitHub] [hudi] nsivabalan commented on a diff in pull request #7942: [HUDI-5753] Add docs for record payload
nsivabalan commented on code in PR #7942:
URL: https://github.com/apache/hudi/pull/7942#discussion_r1162020746
##########
website/docs/record_payload.md:
##########
@@ -0,0 +1,97 @@
+---
+title: Record Payload
+keywords: [hudi, merge, upsert, precombine]
+---
+
+## Record Payload
+
+One of the core features of Hudi is the ability to incrementally upsert data, deduplicate and merge records on the fly.
+Additionally, users can implement their custom logic to merge the input records with the record on storage. Record
+payload is an abstract representation of a Hudi record that allows the aforementioned capability. As we shall see below,
+Hudi provides out-of-box support for different payloads for different use cases, and a new record merger API for
+optimized payload handling. But, first let us understand how record payload is used in the Hudi upsert path.
+
+<figure>
+ <img className="docimage" src={require("/assets/images/upsert_path.png").default} alt="upsert_path.png" />
+</figure>
+
+Figure above shows the main stages that records go through while being written to the Hudi table. In the precombining
+stage, Hudi performs any deduplication based on the payload implementation and precombine key configured by the user.
+Further, on index lookup, Hudi identifies which records are being updated and the record payload implementation tells
+Hudi how to merge the incoming record with the existing record on storage.
+
+### Existing Payloads
+
+#### OverwriteWithLatestAvroPayload
+
+This is the default record payload implementation. It picks the record with the greatest value (determined by calling
+.compareTo() on the value of precombine key) to break ties and simply picks the latest record while merging. This gives
+latest-write-wins style semantics.
+
+#### EventTimeAvroPayload
+
+Some use cases require merging records by event time and thus event time plays the role of an ordering field. This
+payload is particularly useful in the case of late-arriving data. For such use cases, users need to set
+the [payload event time field](/docs/configurations#RECORD_PAYLOAD) configuration.
+
+#### ExpressionPayload
+
+This payload is very useful when you want to merge or delete records based on some conditional expression, especially
+when updating records using [`MERGE INTO`](/docs/quick-start-guide#mergeinto) statement.
+
+#### Payload to support partial update
+
+Typically, once the merge step resolves which record to pick, then the record on storage is fully replaced by the
+resolved record. But, in some cases, the requirement is to update only certain fields and not replace the whole record.
+This is called partial update.
+`PartialUpdateAvroPayload` in Hudi provides out-box-support for such use cases. To illustrate the point, let us look at
+a simple example:
+
+Let's say the order field is `ts` and schema is :
+
+```
+{
+ [
+ {"name":"id","type":"string"},
+ {"name":"ts","type":"long"},
+ {"name":"name","type":"string"},
+ {"name":"price","type":"string"}
+ ]
+}
+```
+
+Current record in storage:
+
+```
+ id ts name price
+ 1 2 name_1 null
+```
+
+Incoming record:
+
+```
+ id ts name price
+ 1 1 null price_1
+```
+
+Result data after merging using `PartialUpdateAvroPayload`:
+
+```
+ id ts name price
+ 1 2 name_1 price_1
Review Comment:
oh I see. if the two records came in proper order, the final snapshot would have been
1 2 name_1 price_1
I get it now.
##########
website/docs/record_payload.md:
##########
@@ -0,0 +1,97 @@
+---
+title: Record Payload
+keywords: [hudi, merge, upsert, precombine]
+---
+
+## Record Payload
+
+One of the core features of Hudi is the ability to incrementally upsert data, deduplicate and merge records on the fly.
+Additionally, users can implement their custom logic to merge the input records with the record on storage. Record
+payload is an abstract representation of a Hudi record that allows the aforementioned capability. As we shall see below,
+Hudi provides out-of-box support for different payloads for different use cases, and a new record merger API for
+optimized payload handling. But, first let us understand how record payload is used in the Hudi upsert path.
+
+<figure>
+ <img className="docimage" src={require("/assets/images/upsert_path.png").default} alt="upsert_path.png" />
+</figure>
+
+Figure above shows the main stages that records go through while being written to the Hudi table. In the precombining
+stage, Hudi performs any deduplication based on the payload implementation and precombine key configured by the user.
+Further, on index lookup, Hudi identifies which records are being updated and the record payload implementation tells
+Hudi how to merge the incoming record with the existing record on storage.
+
+### Existing Payloads
+
+#### OverwriteWithLatestAvroPayload
+
+This is the default record payload implementation. It picks the record with the greatest value (determined by calling
+.compareTo() on the value of precombine key) to break ties and simply picks the latest record while merging. This gives
+latest-write-wins style semantics.
+
+#### EventTimeAvroPayload
+
+Some use cases require merging records by event time and thus event time plays the role of an ordering field. This
+payload is particularly useful in the case of late-arriving data. For such use cases, users need to set
+the [payload event time field](/docs/configurations#RECORD_PAYLOAD) configuration.
+
+#### ExpressionPayload
+
+This payload is very useful when you want to merge or delete records based on some conditional expression, especially
+when updating records using [`MERGE INTO`](/docs/quick-start-guide#mergeinto) statement.
+
+#### Payload to support partial update
+
+Typically, once the merge step resolves which record to pick, then the record on storage is fully replaced by the
+resolved record. But, in some cases, the requirement is to update only certain fields and not replace the whole record.
+This is called partial update.
+`PartialUpdateAvroPayload` in Hudi provides out-box-support for such use cases. To illustrate the point, let us look at
+a simple example:
+
+Let's say the order field is `ts` and schema is :
+
+```
+{
+ [
+ {"name":"id","type":"string"},
+ {"name":"ts","type":"long"},
+ {"name":"name","type":"string"},
+ {"name":"price","type":"string"}
+ ]
+}
+```
+
+Current record in storage:
+
+```
+ id ts name price
+ 1 2 name_1 null
+```
+
+Incoming record:
+
+```
+ id ts name price
+ 1 1 null price_1
+```
+
+Result data after merging using `PartialUpdateAvroPayload`:
+
+```
+ id ts name price
+ 1 2 name_1 price_1
Review Comment:
this is bit confusing actually.
so based on ordering field, we choose the one in storage. so, shouldn't we ignore the new record totally?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org