-
|
Reading through the following documentation: https://docs.feast.dev/concepts/sources, it looks like event_timestamp_column is required. How would you integrate a set of features that are not event based? For example, you might have a set of features that describe aspects of some object. While the object may have a 'transaction' time (thus an event_timestamp_column), the features that additional describe the details of the object do not change. More concretely, retail stores might have a set of features for the location of stores and layout of stores, with several transactions. Can each transaction be a set of features while the location and store layout be another set of features? Or would they all be entered in as one set of features, one FeatureStore |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Typically our users still have a timestamp associated even if the data is "static" by itself. For non-event-based data, it would usually be based on CDC stream timestamp. The idea is that even if the data doesn't change by its nature, it is still possible that it gets updated in the lookup/dimension table, and ideally you want to take that into account. For example, if you're social network, user birth date is "static" but it may turn out that an average user only fills that field in a week after sign up. To encourage users to think about scenarios like this it is required by feast; but of course you could always just use a dummy timestamp if that's not the case. |
Beta Was this translation helpful? Give feedback.
Typically our users still have a timestamp associated even if the data is "static" by itself. For non-event-based data, it would usually be based on CDC stream timestamp.
The idea is that even if the data doesn't change by its nature, it is still possible that it gets updated in the lookup/dimension table, and ideally you want to take that into account. For example, if you're social network, user birth date is "static" but it may turn out that an average user only fills that field in a week after sign up. To encourage users to think about scenarios like this it is required by feast; but of course you could always just use a dummy timestamp if that's not the case.