Expires Redis Keys based on Feature Table Max Age - #1161
Conversation
|
/retest |
87c7ec5 to
c537690
Compare
f1a496b to
c537690
Compare
c537690 to
46d3e43
Compare
|
@khorshuheng can you please add a description? This PR has no information. |
46d3e43 to
9bf661d
Compare
Signed-off-by: Khor Shu Heng <khor.heng@gojek.com>
9bf661d to
0b787c3
Compare
| .map(value => decodeTimestamp(value)) | ||
| } | ||
|
|
||
| override def newExpiryTimestamp( |
There was a problem hiding this comment.
This is not really persistence related method. Maybe move it to RedisSinkRelation?
There was a problem hiding this comment.
you can move MAX_EXPIRED_TIMESTAMP to package level
…edisSinkRelation Signed-off-by: Khor Shu Heng <khor.heng@gojek.com>
| keyTTL should (be <= (r.getEventTimestamp.getSeconds + maxAge - ingestionTimeUnix / 1000) and be > 0L) | ||
| } | ||
|
|
||
| val increasedMaxAge = 86400 * 2 |
There was a problem hiding this comment.
Can we have test for max age = 0 instead, since this flow was already tested with Batch Pipeline?
So how does an administrator force a TTL? |
Signed-off-by: Khor Shu Heng <khor.heng@gojek.com>
Signed-off-by: Khor Shu Heng <khor.heng@gojek.com>
|
/test test-end-to-end-gcp |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: khorshuheng, pyalex The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
* Expires Redis Keys based on Feature Table Max Age Signed-off-by: Khor Shu Heng <khor.heng@gojek.com> * Remove redundant generics, move expiry eventimestamp computation to RedisSinkRelation Signed-off-by: Khor Shu Heng <khor.heng@gojek.com> * Persist the key if the expiry date is equal to max timestamp Signed-off-by: Khor Shu Heng <khor.heng@gojek.com> * Add more test cases Signed-off-by: Khor Shu Heng <khor.heng@gojek.com> Co-authored-by: Khor Shu Heng <khor.heng@gojek.com>
Signed-off-by: Khor Shu Heng khor.heng@gojek.com
What this PR does / why we need it:
Since the release of Feast 0.8, the Redis ingestion is performed via Spark ingestion module rather than the existing Redis storage module. Hence, #955 is not applicable to Feast 0.8.
For the current implementation, instead of a global value of ttl which would be applicable to all Redis key, the ttl will be computed based on the max ages of all the feature tables associated with the Redis Key. For example, if two feature table are associated with the Redis key, the ttl will be computed as follows:
In the event where any of the feature table associated with the Redis key has max age set to 0, ttl will not be set.
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?: