-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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
spark/ingestion/src/test/scala/feast/ingestion/StreamingPipelineIT.scala
Outdated
Show resolved
Hide resolved
} | ||
|
||
override def newExpiryTimestamp( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not really persistence related method. Maybe move it to RedisSinkRelation
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Needs 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?: