forked from feast-dev/feast
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'feast-dev:master' into release
- Loading branch information
Showing
163 changed files
with
7,348 additions
and
644 deletions.
There are no files selected for viewing
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
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
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
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| # Adopters of Feast | ||
|
|
||
| Below are the adopters of Feast. If you are using Feast please add | ||
| yourself into the following list by a pull request. Please keep the list in | ||
| alphabetical order. | ||
|
|
||
| | Organization | Contact | GitHub Username | | ||
| | ------------ | ------- | ------- | | ||
| | Affirm | Francisco Javier Arceo | franciscojavierarceo | | ||
| | Bank of Georgia | Tornike Gurgenidze | tokoko | | ||
| | Get Ground | Zhiling Chen | zhilingc | | ||
| | Gojek | Pradithya Aria Pura | pradithya | | ||
| | Twitter | David Liu | mavysavydav| | ||
| | Shopify | Matt Delacour | MattDelac | | ||
| | Snowflake | Miles Adkins | sfc-gh-madkins | |
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
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
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
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,97 @@ | ||
| # Feature Serving and Model Inference | ||
|
|
||
| Production machine learning systems can choose from four approaches to serving machine learning predictions (the output | ||
| of model inference): | ||
| 1. Online model inference with online features | ||
| 2. Offline mode inference without online features | ||
| 3. Online model inference with online features and cached predictions | ||
| 4. Online model inference without features | ||
|
|
||
| *Note: online features can be sourced from batch, streaming, or request data sources.* | ||
|
|
||
| These three approaches have different tradeoffs but, in general, have significant implementation differences. | ||
|
|
||
| ## 1. Online Model Inference with Online Features | ||
| Online model inference with online features is a powerful approach to serving data-driven machine learning applications. | ||
| This requires a feature store to serve online features and a model server to serve model predictions (e.g., KServe). | ||
| This approach is particularly useful for applications where request-time data is required to run inference. | ||
| ```python | ||
| features = store.get_online_features( | ||
| feature_refs=[ | ||
| "user_data:click_through_rate", | ||
| "user_data:number_of_clicks", | ||
| "user_data:average_page_duration", | ||
| ], | ||
| entity_rows=[{"user_id": 1}], | ||
| ) | ||
| model_predictions = model_server.predict(features) | ||
| ``` | ||
|
|
||
| ## 2. Offline Model Inference without Online Features | ||
| Typically, Machine Learning teams find serving precomputed model predictions to be the most straightforward to implement. | ||
| This approach simply treats the model predictions as a feature and serves them from the feature store using the standard | ||
| Feast sdk. These model predictions are typically generated through some batch process where the model scores are precomputed. | ||
| As a concrete example, the batch process can be as simple as a script that runs model inference locally for a set of users that | ||
| can output a CSV. This output file could be used for materialization so that the model could be served online as shown in the | ||
| code below. | ||
| ```python | ||
| model_predictions = store.get_online_features( | ||
| feature_refs=[ | ||
| "user_data:model_predictions", | ||
| ], | ||
| entity_rows=[{"user_id": 1}], | ||
| ) | ||
| ``` | ||
| Notice that the model server is not involved in this approach. Instead, the model predictions are precomputed and | ||
| materialized to the online store. | ||
|
|
||
| While this approach can lead to quick impact for different business use cases, it suffers from stale data as well | ||
| as only serving users/entities that were available at the time of the batch computation. In some cases, this tradeoff | ||
| may be tolerable. | ||
|
|
||
| ## 3. Online Model Inference with Online Features and Cached Predictions | ||
| This approach is the most sophisticated where inference is optimized for low-latency by caching predictions and running | ||
| model inference when data producers write features to the online store. This approach is particularly useful for | ||
| applications where features are coming from multiple data sources, the model is computationally expensive to run, or | ||
| latency is a significant constraint. | ||
|
|
||
| ```python | ||
| # Client Reads | ||
| features = store.get_online_features( | ||
| feature_refs=[ | ||
| "user_data:click_through_rate", | ||
| "user_data:number_of_clicks", | ||
| "user_data:average_page_duration", | ||
| "user_data:model_predictions", | ||
| ], | ||
| entity_rows=[{"user_id": 1}], | ||
| ) | ||
| if features.to_dict().get('user_data:model_predictions') is None: | ||
| model_predictions = model_server.predict(features) | ||
| store.write_to_online_store(feature_view_name="user_data", df=pd.DataFrame(model_predictions)) | ||
| ``` | ||
| Note that in this case a seperate call to `write_to_online_store` is required when the underlying data changes and | ||
| predictions change along with it. | ||
|
|
||
| ```python | ||
| # Client Writes from the Data Producer | ||
| user_data = request.POST.get('user_data') | ||
| model_predictions = model_server.predict(user_data) # assume this includes `user_data` in the Data Frame | ||
| store.write_to_online_store(feature_view_name="user_data", df=pd.DataFrame(model_predictions)) | ||
| ``` | ||
| While this requires additional writes for every data producer, this approach will result in the lowest latency for | ||
| model inference. | ||
|
|
||
| ## 4. Online Model Inference without Features | ||
| This approach does not require Feast. The model server can directly serve predictions without any features. This | ||
| approach is common in Large Language Models (LLMs) and other models that do not require features to make predictions. | ||
|
|
||
| Note that generative models using Retrieval Augmented Generation (RAG) do require features where the | ||
| [document embeddings](../../reference/alpha-vector-database.md) are treated as features, which Feast supports | ||
| (this would fall under "Online Model Inference with Online Features"). | ||
|
|
||
| ### Client Orchestration | ||
| Implicit in the code examples above is a design choice about how clients orchestrate calls to get features and run model inference. | ||
| The examples had a Feast-centric pattern because they are inputs to the model, so the sequencing is fairly obvious. | ||
| An alternative approach can be Inference-centric where a client would call an inference endpoint and the inference | ||
| service would be responsible for orchestration. |
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
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,56 @@ | ||
| # Role-Based Access Control (RBAC) in Feast | ||
|
|
||
| ## Introduction | ||
|
|
||
| Role-Based Access Control (RBAC) is a security mechanism that restricts access to resources based on the roles of individual users within an organization. In the context of the Feast, RBAC ensures that only authorized users or groups can access or modify specific resources, thereby maintaining data security and operational integrity. | ||
|
|
||
| ## Functional Requirements | ||
|
|
||
| The RBAC implementation in Feast is designed to: | ||
|
|
||
| - **Assign Permissions**: Allow administrators to assign permissions for various operations and resources to users or groups based on their roles. | ||
| - **Seamless Integration**: Integrate smoothly with existing business code without requiring significant modifications. | ||
| - **Backward Compatibility**: Maintain support for non-authorized models as the default to ensure backward compatibility. | ||
|
|
||
| ## Business Goals | ||
|
|
||
| The primary business goals of implementing RBAC in the Feast are: | ||
|
|
||
| 1. **Feature Sharing**: Enable multiple teams to share the feature store while ensuring controlled access. This allows for collaborative work without compromising data security. | ||
| 2. **Access Control Management**: Prevent unauthorized access to team-specific resources and spaces, governing the operations that each user or group can perform. | ||
|
|
||
| ## Reference Architecture | ||
|
|
||
| Feast operates as a collection of connected services, each enforcing authorization permissions. The architecture is designed as a distributed microservices system with the following key components: | ||
|
|
||
| - **Service Endpoints**: These enforce authorization permissions, ensuring that only authorized requests are processed. | ||
| - **Client Integration**: Clients authenticate with feature servers by attaching authorization token to each request. | ||
| - **Service-to-Service Communication**: This is always granted. | ||
|
|
||
|  | ||
|
|
||
| ## Permission Model | ||
|
|
||
| The RBAC system in Feast uses a permission model that defines the following concepts: | ||
|
|
||
| - **Resource**: An object within Feast that needs to be secured against unauthorized access. | ||
| - **Action**: A logical operation performed on a resource, such as Create, Describe, Update, Delete, Read, or write operations. | ||
| - **Policy**: A set of rules that enforce authorization decisions on resources. The default implementation uses role-based policies. | ||
|
|
||
|
|
||
|
|
||
| ## Authorization Architecture | ||
|
|
||
| The authorization architecture in Feast is built with the following components: | ||
|
|
||
| - **Token Extractor**: Extracts the authorization token from the request header. | ||
| - **Token Parser**: Parses the token to retrieve user details. | ||
| - **Policy Enforcer**: Validates the secured endpoint against the retrieved user details. | ||
| - **Token Injector**: Adds the authorization token to each secured request header. | ||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
Oops, something went wrong.