Snowflake Feature Store: Architecture, Entities and Feature Views

1.A feature store is a schema

A feature store gives teams one central place to define common feature transformations. They can then reuse those transformations instead of copying them. It also keeps features current as new source data arrives, so everyone reads from a single source of truth. In Snowflake there is no separate service behind this. The documentation states it directly: "A feature store in Snowflake is simply a schema." You can create a new schema for it or use an existing one.

Everything else in the feature store sits on ordinary Snowflake objects. A feature view is backed by either a dynamic table or a view. An entity is a tag, and each feature is a column. Properties of a feature view, such as its name and entity, are also stored as tags on the underlying dynamic table or view. Because these are real objects, you can query or change them with SQL, and those changes show up in the Python API (and the other way round). To delete a feature store completely, first make sure the schema holds nothing else, then drop the schema.

You create a feature store, or connect to one, with the FeatureStore class. It is part of the snowflake-ml-python package. The constructor takes a Snowpark session, a database name, a feature store name and a default warehouse. The creation_mode parameter decides what happens if the schema does not exist yet. The default, CreationMode.FAIL_IF_NOT_EXIST, raises an exception. CreationMode.CREATE_IF_NOT_EXIST creates the schema. Normally an administrator role creates the feature store schema and its roles. Everyone else then connects using the default mode. The documentation also suggests keeping feature stores in a dedicated database because that makes them easier to replicate. A user with access to several feature stores can combine feature views from all of them when building training and inference datasets.

from snowflake.ml.feature_store import FeatureStore, CreationMode

fs = FeatureStore(
        session=session,
        database="MY_DB",
        name="MY_FEATURE_STORE",
        default_warehouse="MY_WH",
        creation_mode=CreationMode. ? ,
     )

The architecture exists to give you centralized feature management and reuse. The central repository standardizes commonly used feature transformations, so teams reuse one definition instead of rebuilding it. That reduces duplicated data and effort and improves productivity. Features are updated on new source data, so the store is a single source of truth that is correct, consistent and fresh. Extracting features from raw data in one consistent way also makes production ML pipelines more robust.

The central store is hosted natively inside Snowflake. Your data stays under your control and governance and never leaves Snowflake. Access is managed with fine-grained role-based access control, because every feature store object is a Snowflake object. The Snowsight Feature Store UI lets people search for and discover features. In practice, one administrator-created schema holds the shared entities and feature views, and many teams and models read from it. A user with access to more than one store can still combine feature views from several of them.

Sources12

2.Entities: the data model and its join keys

Feature views are grouped by entity. An entity is the subject a feature describes. For example, a streaming service might have users and movies. Entities do two jobs. They organise feature views so people can find them, and they hold the names of the key columns used to join features back to other data. As the docs put it, entities store the names of the key columns you can use to join the extracted features back to the original data. A feature view can be tagged with more than one entity. For example, a feature about a user's activity on a particular movie relates to both.

You define an entity with a name, a list of join_keys and an optional description, then register it in the store:

from snowflake.ml.feature_store import Entity

entity = Entity(
    name="MY_ENTITY",
    join_keys=["UNIQUE_ID"],
    desc="my entity"
)
fs.register_entity(entity)

Several other methods manage entities. list_entities() returns the registered entities as a Snowpark DataFrame. get_entity(name=...) returns one entity, for example so you can read its join_keys. delete_entity removes one. The rules after registration are strict. update_entity can change only the description. Join keys and the other properties cannot be changed, so you create a new entity if you need different keys. You also cannot delete an entity while any feature view references it. Because entities are tags, they count toward the limit of 10,000 tags per account and 50 unique tags per object.

Sources3

3.Feature views: managed (dynamic tables) or external

A feature view wraps the transformation of raw data into one or more related features. All features in one view refresh on the same schedule. In Python you build one with snowflake.ml.feature_store.FeatureView, and its constructor accepts a Snowpark DataFrame that contains the feature generation logic. That DataFrame is how you build a feature store with Snowpark. It must include the join_keys columns of the associated entities. It also needs a timestamp column name if the view contains time-series features. You can write the transformations in SQL or in Snowpark Python.

Setting refresh_freq makes the view Snowflake-managed. The value can be a time delta (minimum 1 minute) or a cron expression with a time zone. This is where dynamic tables come in: a Snowflake-managed feature view uses a dynamic table as the feature table. Snowflake refreshes it on your schedule and handles new data incrementally where it can.

managed_fv = FeatureView(
    name="MY_MANAGED_FV",
    entities=[entity],
    feature_df=my_df,                   # Snowpark DataFrame containing feature transformations
    timestamp_col="ts",                 # optional timestamp column name in the dataframe
    refresh_freq="5 minutes",           # how often feature data refreshes
    desc="my managed feature view"      # optional description
)

Incremental refresh has two conditions. First, each source table must have change tracking enabled. If it is not enabled, Snowflake tries to turn it on when it creates the dynamic table, and that requires OWNERSHIP of the table. If you don't own the table, you can ask the owner to enable change tracking, or you can create the view with refresh_mode='FULL', which fully reads the source table for each refresh. Second, the query itself must support incremental maintenance. If it doesn't, the table will be fully refreshed from the query at the specified frequency. That can mean more refresh lag and higher maintenance costs. The documented fixes are to split the query into smaller queries that do support incremental maintenance, or to use a larger warehouse.

An external feature view is one where refresh_freq=None. It is meant for features that are already computed outside the Feature Store, for example by dbt. You create and maintain the feature table yourself. The feature DataFrame reads from that feature table, not from raw data, and is usually a simple projection with no transformations. External feature views are implemented as views on your feature table, so they add no storage cost. They still get the same entities, versioning and discovery as managed views, which keeps outside pipelines consistent with the rest of the store.

Sources4

4.Registering, versioning and discovering features

Defining a FeatureView object does not share it with anyone. You do that by registering it with register_feature_view and giving it a version. Both managed and external views are registered this way. After registration, managed views start their incremental maintenance and automatic refresh. block=True makes the call wait until the initial data is available. overwrite=False stops you from replacing an existing view with the same name and version.

registered_fv: FeatureView = fs.register_feature_view(
    feature_view=managed_fv,    # feature view created above, could also use external_fv
    version="1",
    block=True,         # whether function call blocks until initial data is available
    overwrite=False,    # whether to replace existing feature view with same name/version
)

Versioning works because a registered pipeline definition is immutable, so features are computed the same way for as long as that version exists. update_feature_view can change only three properties: the refresh frequency, the warehouse where the transforms run, and the description. Feature definitions and columns can't be changed. To change features, you register a new version of the feature view. Consumers keep using version 1 until they choose to move.

Registration also makes features searchable shared metadata. attach_feature_desc adds a short description to each feature, which helps people find features in Snowsight Universal Search. get_feature_view(name, version) fetches a specific version. list_feature_views filters by entity or name and returns the results as a Snowpark DataFrame. People can also browse the Snowsight Feature Store UI. For teams that keep definitions in source control, a declarative snow feature plan/apply CLI describes entities and feature views as YAML files that can go through CI/CD. It is in preview and distributed as a private wheel.

Registering turns a feature definition into a centralized metadata object, which is what lets different use cases and teams discover and reuse it. A registered feature view is a Snowflake object in the feature store schema. Its properties, such as name and entity, are implemented as tags on the dynamic table or view. Because the feature view is tagged with its entity, any team can call list_feature_views with an entity name to find the existing views for, say, users, before building a new one. Per-feature descriptions, the Snowsight Feature Store UI and Universal Search help people locate features without asking the team that built them.

Reuse works across models and teams because each consumer refers to a view by name and version. Different models can read the same registered view, and every one of them gets the same computation. Since the registered objects are ordinary Snowflake objects, access control decides who can see and use them. A team that wants a changed feature registers a new version rather than altering the shared one.

Sources415

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.An entity's join keys can be corrected later with update_entity.Why is that wrong?

   update_entity changes only the description. Join keys are immutable, so a different key needs a new entity.

   Covered in Entities: the data model and its join keys

2. 2.Every feature view is backed by a dynamic table.Why is that wrong?

   Only Snowflake-managed views use a dynamic table. External views (refresh_freq=None) are views on a feature table you maintain, and they add no storage cost.

   Covered in Feature views: managed (dynamic tables) or external

3. 3.update_feature_view can change a registered view's feature logic.Why is that wrong?

   Only refresh frequency, warehouse and description can be updated. The pipeline definition is immutable after registration, so feature changes need a new version.

   Covered in Registering, versioning and discovering features