-
Notifications
You must be signed in to change notification settings - Fork 996
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Field Status metadata to Online Serving #658
Add Field Status metadata to Online Serving #658
Conversation
/test test-serving |
/test test-python-sdk |
/test test-golang-sdk |
/test test-end-to-end |
/test test-end-to-end-redis-cluster |
Just a very, um, meta thing—if I saw this changelog and #536 in the same release notes I would think they're related. Should we find some disambiguating terminology? Maybe "registry metadata" and "serving metadata"? |
I guess "feature (set) labels" could already suffice unambiguously for what I called "registry metadata". The feature in this PR being called "feature metadata" is problematic though, I think. |
Yea I agree :) Actually the Feast project has a long history of abusing the term metadata. It's just such a convenient word. It's everything How about
|
I might steal that. I think "feature value statuses" is apt. |
Can we introduce this change/functionality in an evolutionary-friendly way? Like introduce it as a new RPC and new messages, with the old ones remaining supported, possibly going through a deprecation period before Feast 1.0? Breaking the contract is extremely disruptive here. Upgrading the Serving API will break existing online clients in production, they will all have to upgrade their SDK, and it's not possible to roll out a forward-compatible SDK upgrade to fleets in advance. This breaks all the rules of API evolution. |
@mrzzy any objections to
We can. Some ideas on gRPC versioning from Microsoft. We could add a new RPC with |
I renaming "Feature Metadata" to "Field Status" in the PR name instead of "Feature Status" as it also returns entity statuses in addition to feature statuses. |
The golang code has to be versioned too, since version pinning is a non-goal of go modules :/ |
This is a good example I think in favor of SDKs providing higher-level API wrapping protobuf types and request/response objects—this Java API was seamlessly upgraded in the PR, and the same could apply to using a new RPC underneath and phasing out the old one: public List<Row> getOnlineFeatures(List<String> features, List<Row> rows, String defaultProject) while this is very susceptible to source-incompatible breakage, at least if user code touches the (public) underlying func (fc *GrpcClient) GetOnlineFeatures(ctx context.Context, req *OnlineFeaturesRequest) (
*OnlineFeaturesResponse, error) { |
The golang SDK follows a similar pattern, but unfortunately for golang the proto-generated code is persisted (and versioned) together with the sdk code :(
|
… consolidate constants
… in OnlineServingService
… "stale" is a overloaded term.
…Row> instead of returning null. This allows the code to more semenatic and readable compared to dealing with nullable FeatureRow values
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mrzzy, woop 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 |
/test test-end-to-end-batch |
What this PR does / why we need it:
Adds field status metadata to Online Serving so that users can debug Serving returning missing values.
Field status metadata returned (
FieldStatus
) classifies the missing values into 3 possible cases:NULL_VALUE
- the value is missing because the user did not specify a value on ingestion.NOT_FOUND
- the value is missing because it could not be retrieved from the online store (ie feature data key not found Redis store.)OUTSIDE_MAX_AGE
- the value is missing because it was purposely discarded as the time since the value was ingested and retrieval has exceeded the FeatureSet's max age.Updates SDKs (Go, Java, Python) to support field status metadata.
Which issue(s) this PR fixes:
Fixes #278
Does this PR introduce a user-facing change?: