Skip to content
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 support for Redis to new Feast #1497

Closed
woop opened this issue Apr 23, 2021 · 4 comments · Fixed by #1511
Closed

Add support for Redis to new Feast #1497

woop opened this issue Apr 23, 2021 · 4 comments · Fixed by #1511
Assignees

Comments

@woop
Copy link
Member

woop commented Apr 23, 2021

Currently Feast only supports Redis as part of a Kubernetes deployment (Feast 0.9). We'd like to make it possible to use Redis as part of the new Feast 0.10 architecture, which would allow teams to migrate from Feast 0.9 to Feast 0.10. We also want to ensure that Feast Serving is fully decoupled from Feast Core, making it easier to operate Feast on K8s.

image

Proposal

  1. Decouple Feast Serving from Feast Core. Instead, make it possible to read Feature Views, Feature Tables, and Entities directly from the Protobuf feature registry that the Feast SDK uses.
  2. Add support for feature ingestion from the Feast SDK directly to Redis.
  3. Update our Helm charts to provide a Spark-free and Core-free Helm installation. Basically only Feast Serving and Redis. This should be behind a flag to not disrupt existing users.
  4. Add a Feast k8s provider for reading/writing to Redis from the Feast Python SDK. Reads will happen through Feast Serving. Reads will happen directly from Redis if using the Python SDK. From Go or Java it will go through Feast Serving for the time being.

Further Extension

Push Based Ingestion

As an extension to the above proposal we could also add support for push based ingestion to Redis through Feast Serving (Java), following an approach outlined feast-dev/feast-java-old#6 and #1461

We'd then let the Feast SDK write to Redis through Feast Serving using gRPC. The benefit to this approach is that teams can also use the push API for streaming ingestion.

Spark

We'd be able to move our existing Spark users over to this new architecture by moving a launcher (like the Spark on K8s Feast launcher) into the Feast SDK under a new provider.

@tedhtchang
Copy link
Contributor

tedhtchang commented Apr 30, 2021

@woop How will the Feast Serving read the local registry ?Or I guess for k8s deployment, the Feast Serving will only read Protobuf directly from gcs backed registry.

@woop
Copy link
Member Author

woop commented May 12, 2021

@woop How will the Feast Serving read the local registry? Or I guess for k8s deployment, the Feast Serving will only read Protobuf directly from gcs backed registry.

For K8s you will have to use the object store registry. I mean in theory you could use a volume mount, but we won't test for or support that.

@woop woop reopened this Jun 25, 2021
@achals achals self-assigned this Sep 23, 2021
@adchia
Copy link
Collaborator

adchia commented Oct 26, 2021

@achals Think we can likely close this?

@achals
Copy link
Member

achals commented Oct 26, 2021

@adchia I think it's best to wait until we cut a release of feast-serving

@adchia adchia closed this as completed Jan 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants