Feast is inconsistent in how it uses entity names (as defined in Feast) vs entity join keys (i.e. the original column name in the offline store). It leads to several issues:
get_online_features doesn't work properly when the user uses entity aliases (see below for example in historical retrieval)
get_online_features callers need to find what the entity name is since it doesn't naturally reflect the join key they have on hand.
Expected behavior
get_online_features should take join keys instead of entity names (and understand with_join_key_map)
Background
See also a similar discussion in Entity name/joinkey dichotomy
Historical feature retrieval
In get_historical_features: entity join keys (aka the column in the original table) are expected.
When there are multiple possible join keys that refer to the same entity, we require the use of with_join_key_map (code) on the feature view. Then get_historical_features takes in the join keys directly.
Example: for a given shopping transaction, get user features for both buyers + sellers
transaction_service = FeatureService(
name="transactions",
features=[
user_feature_view
.with_name("buyer_features")
.with_join_key_map(
{"user_id": "buyer_id"}
),
user_feature_view
.with_name("seller_features")
.with_join_key_map(
{"user_id": "seller_id"}
),
])
feature_store.get_historical_features(
features=transaction_service,
entity_df=pd.DataFrame.from_dict(
{
"buyer_id": [1001, 1002],
"seller_id": [1003, 1003],
"event_timestamp": [
datetime(2021, 4, 12, 10, 59, 42),
datetime(2021, 4, 12, 8, 12, 10),
],
}
)
)
Online feature retrieval
In get_online_features, entity names are expected.
Feature / entity definitions in the feature repo
In defining Feast objects, Feast FeatureView objects use entity names.
Feast is inconsistent in how it uses entity names (as defined in Feast) vs entity join keys (i.e. the original column name in the offline store). It leads to several issues:
get_online_featuresdoesn't work properly when the user uses entity aliases (see below for example in historical retrieval)get_online_featurescallers need to find what the entity name is since it doesn't naturally reflect the join key they have on hand.Expected behavior
get_online_featuresshould take join keys instead of entity names (and understandwith_join_key_map)Background
See also a similar discussion in Entity name/joinkey dichotomy
Historical feature retrieval
In
get_historical_features: entity join keys (aka the column in the original table) are expected.When there are multiple possible join keys that refer to the same entity, we require the use of
with_join_key_map(code) on the feature view. Thenget_historical_featurestakes in the join keys directly.Example: for a given shopping transaction, get user features for both buyers + sellers
Online feature retrieval
In
get_online_features, entity names are expected.Feature / entity definitions in the feature repo
In defining Feast objects, Feast
FeatureViewobjects use entity names.