feat: add ibis-based duckdb offline store #3822
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
This PR adds two offline store implementations:
This is a draft PR to garner feedback from the community regarding the idea to converge offline store implementations to a single abstract base implementation that will then be extended by concrete offline stores. Right now each feast offline store has to more or less reimplement the same data transformation logic (mainly point-in-time join) in their respective technologies. The goal of this PR is to suggest a possible alternative approach where feast would only implement abstract transformations and offload technology translation details to another library, namely ibis.
Ibis is a lightweight python library that offers a universal dataframe API with pluggable query engine backends. As of now it can interface with 15+ engines with varying level of API coverage, including BigQuery, Snowflake, Pyspark, PosgreSQL, Trino and others. I think adopting ibis as a common backend for at least some offline store implementations (contrib stores for starters) would simplify development effort and ensure feature parity.
The implementation in this PR is very rough and far from merge-ready. The main goal is to find out it the community thinks this is a good long-term approach for feast offline stores in general.