You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Users can deploy http and grpc feature servers that wrap get_online_features calls, but currently there is no way to interact with feature servers from python sdk.
Describe the solution you'd like
Add online store types remote-http and remote-grpc (or maybe just call it a remote and differentiate with a url?) that wrap network calls to the respective feature servers. This follows the same pattern as remote registry implementation that wraps calls to the registry server.
We'll have to serialize the data on the server to match what's in the feature registry from the FeatureView itself and fail loudly when it doesn't match, probably return a 400.
Is this something we support? The signature for get_online_features is only feature service or a list of features -> features: Union[List[str], FeatureService]
@tokoko I'm confused about why we would do this? I think adding a client that makes the behavior intuitive makes sense but that's basically in the Python feature server.
Well, it's more of convenience thing, i think. They can still use the feature server directly of course, but what this additional layer would enable is writing a piece of code using store.get_online_features and then configuring how you want to resolve features with feature_store.yaml. You could change the backend from the actual online store to http feature server or a grpc one without changing anything in the code itself.
There is no grpc implementation of APIs in python feature server. So this issue is going to only focus on remote with http implementation. We can enhance the online store to include grpc implementation when the grpc apis available on the python feature server.
Planning to implement the online store api methods of online_write_batch and online_read. Rest all life cycle methods of online_store are not having associated APIs in the feature server.
Activity
[-]Add `remote-http` and `remote-grpc` online stores[/-][+]Add `remote-http` online store[/+]lokeshrangineni commentedon May 2, 2024
I am currently working on this and will get back in case if i find any difficulty.
lokeshrangineni commentedon May 3, 2024
@franciscojavierarceo FYI
franciscojavierarceo commentedon May 3, 2024
Some things we'll have to do:
1. Handle purelyfeature_viewsi.e.,features="feature_view"2. Handle feature references; i.e.,
["feature_view:feature_1","feature_view:feature_2",...]etc.3. Handle feature services
We'll have to serialize the data on the server to match what's in the feature registry from the
FeatureViewitself and fail loudly when it doesn't match, probably return a400.tokoko commentedon May 3, 2024
@franciscojavierarceo I think you closed this by accident.
Is this something we support? The signature for
get_online_featuresis only feature service or a list of features ->features: Union[List[str], FeatureService]franciscojavierarceo commentedon May 3, 2024
Whoops, nevermind that was based on outdated documentation I think.
franciscojavierarceo commentedon May 3, 2024
@tokoko I'm confused about why we would do this? I think adding a client that makes the behavior intuitive makes sense but that's basically in the Python feature server.
tokoko commentedon May 3, 2024
Well, it's more of convenience thing, i think. They can still use the feature server directly of course, but what this additional layer would enable is writing a piece of code using
store.get_online_featuresand then configuring how you want to resolve features withfeature_store.yaml. You could change the backend from the actual online store to http feature server or a grpc one without changing anything in the code itself.lokeshrangineni commentedon May 15, 2024
Few updates after started working on the issue:
online_write_batchandonline_read. Rest all life cycle methods of online_store are not having associated APIs in the feature server.dmartinol commentedon May 15, 2024
@tokoko can you confirm the above assumptions, in order to guide @lokeshrangineni 's implementation?
tokoko commentedon May 15, 2024
sure, sounds like a good starting point.
lokeshrangineni commentedon May 24, 2024
Created a draft PR just for initial feedback. Please note that code may change significantly depending on the feedback.
#4226