Unify Feature Transformations and Feature Views #4584
Description
Problem
In Feast, the current On Demand Feature View executes feature transformations at read time. However, this behavior is not immediately obvious from the name "On Demand Feature View."
The terms "On Demand" don't explicitly convey when the transformation occurs, leading to potential confusion for users trying to understand the timing and execution flow of feature transformations. Additionally, there's inconsistency in how different types of feature views (batch, streaming, on-demand) are declared and used, which can make the codebase less intuitive and harder to maintain.
Proposed Solution
I propose we refactor and rename the way transformations are defined in Feast to make the execution timing explicit. Introducing a @transform decorator with a type parameter that accepts a FeastTransformation enum can achieve this clarity. The enum would define the transformation types:
from enum import Enum
class FeastTransformation(Enum):
NONE = 0 # No transformations happening using Feast
ON_READ = 1 # Equivalent to the current On Demand Feature View
ON_WRITE = 2 # New: Transformations executed at write time
BATCH = 3 # New: Batch processing transformations
STREAMING = 4 # Migrates the existing stream_feature_view decorator
@transform(
type=FeastTransformation.ON_WRITE,
schema=[...],
entity=[...],
sources=[...],
mode='python',
)
def my_feature_view(inputs: List[Dict[str, float]]) -> List[Dict[str, float]]:
# Transformation logic here
return outputsBy explicitly declaring when the transformation should occur {'ON_READ', 'ON_WRITE', 'BATCH', 'STREAMING'}, the code becomes more readable, maintainable, and, more importantly, we will be able to remove a lot of duplicate, confusing code that obfuscates what is actually happening (particularly during the execution of FeatureStore.apply()).
*This approach unifies the declaration of feature views and transformations, making it easier for users to understand and for developers to extend functionality in the future.
Alternatives
-
Enhancing Documentation: Improving the existing documentation to better explain the behavior of On Demand Feature View without changing the code structure.
- This doesn't solve the inherent ambiguity in the naming.
-
Renaming Existing Decorators: Simply renaming on_demand_feature_view to something like on_read_feature_view to make the execution timing clearer.
- While this improves clarity, it doesn't address the inconsistency in how different feature views are declared.
-
Using Configuration Parameters: Adding parameters to existing decorators to specify execution timing.
- This could make the decorators more complex and doesn't provide a unified approach.
Additional Context
Consistency and Extensibility: This change promotes a consistent method of declaring feature transformations, regardless of when they execute. It also sets a foundation for adding more transformation types in the future.
Clarity for New Users: Making the execution timing explicit in the code helps new users understand the flow of data and transformations in Feast, reducing the learning curve.
Impact on Existing Codebase: Careful consideration and planning would be needed to migrate existing code to the new structure without breaking functionality. Deprecation warnings and migration guides could facilitate this transition.
Community Feedback: Engaging with the community to gather feedback on this proposed change could provide additional insights and help refine the solution.
Migration: We can make the code backwards compatible and even provide some helper scripts to migrate to the new syntax but I think this is the right long term proposal that settles the several discussions we've had.