Feature views as versioned assets: packaging and scaling feature transformations

1.Why feature logic lives outside model code

When each training script computes its own features, every model carries a private copy of the same logic, and the copies drift apart. A feature store fixes this. You define the transformation once, give it a name, and every model that needs it reads from that definition. Snowflake describes the goal as standardizing "commonly used feature transformations in a central repository, enabling reuse". That reuse is why features count as data assets and not as helper code inside a model repository.

In Snowflake these assets are ordinary database objects. A feature store is a schema. A feature view is either a dynamic table or a view, and its properties, such as name and entity, are stored as tags on that object. Because they are ordinary objects, normal role-based access control applies, and changes made through SQL appear in the Python API and the other way round. You can write the transformation in Python or SQL. The model team only has to know which feature view, and which version of it, to read.

Sources1

2.Packaging: who runs the transformation?

The FeatureView constructor takes a Snowpark DataFrame that holds the feature logic, and you can write that logic in SQL or Snowpark Python. One parameter, refresh_freq, decides who keeps the features up to date. If you set it, the feature view is Snowflake-managed: Snowflake creates a dynamic table as the feature table and refreshes it on your schedule. The value can be a time delta, with a minimum of 1 minute, or a cron expression with a time zone.

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
)

If your transformations already run in a tool such as dbt, you can still publish the output as a versioned asset. Set refresh_freq to None to create an external feature view. In that case you build and maintain the feature table yourself, and the feature DataFrame is usually a plain projection of that table. External feature views are implemented as views, so they add no storage cost.

external_fv = FeatureView(
    name="MY_EXTERNAL_FV",
    entities=[entity],
    feature_df=my_df,                   # Snowpark DataFrame referencing the feature table
    timestamp_col="ts",                 # optional timestamp column name in the dataframe
    refresh_freq= ? ,                  # None means the feature view is external
    desc="my external feature view"     # optional description
)

Sources2

3.Versioning: register once, change by adding versions

Defining a feature view does not publish it. You publish it by registering it with an explicit version, and that name plus version is what training and inference code refer to.

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
)

After registration, the pipeline definition is immutable. That is what lets a model trained on version 1 trust that version 1 will always compute features the same way. Operational settings can still change. update_feature_view can change only three things: the refresh frequency, the warehouse where the transforms run, and the description. Any change to the logic or the columns needs a new version. Teams find registered versions with get_feature_view, list_feature_views, the Snowsight Feature Store UI, or Universal Search, and per-feature descriptions make them easier to find.

Sources2

4.Scaling feature computation: warehouses, incremental refresh, compute pools

A managed feature view refreshes on a virtual warehouse. The cheapest way to scale is to keep that refresh incremental, so each run processes only new data. Incremental refresh requires change tracking on every source table. Snowflake tries to turn it on when it creates the dynamic table, but that needs OWNERSHIP of the table. If you don't own it, ask the owner to enable change tracking, or accept refresh_mode='FULL', which reads the whole source table on every refresh.

Some queries cannot be maintained incrementally. Those are fully refreshed at the specified frequency, which the docs warn "may lead to greater lag in feature refresh and higher maintenance costs." There are two remedies. You can split the query into smaller queries that do support incremental maintenance, or you can provision a larger virtual warehouse for dynamic table maintenance. Because the warehouse can be updated in place, resizing it does not need a new version.

fs.update_feature_view(
    name="<name>",
    version="<version>",
    refresh_freq="<new_fresh_freq>",    # optional
     ? ="<new_warehouse>",        # optional
    desc="<new_description>",           # optional
)

Warehouses are not the only engine. Snowflake ML's preprocessing APIs push work down to the warehouse and "distribute the processing across warehouse compute resources." For highly customizable large-scale processing, especially of unstructured data, Ray map_batches runs across nodes in a compute pool on Container Runtime. For freshness rather than throughput, stream feature views ingest events in real time and reach end-to-end freshness under two seconds. That is the near-real-time path when scheduled batch refreshes are not fresh enough.

Sources234

Exam traps

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

1. 1.You can fix a feature's logic by updating the registered feature view in place.Why is that wrong?

   update_feature_view changes only the refresh frequency, warehouse and description. Any change to the logic or columns needs a new version.

   Covered in Versioning: register once, change by adding versions

2. 2.Registering a feature view with refresh_freq=None means Snowflake will still keep it fresh on a default schedule.Why is that wrong?

   With no refresh schedule the feature view is external. Snowflake does not run the pipeline, and you must maintain the feature table yourself.

   Covered in Packaging: who runs the transformation?