Feature-store design is about keeping model inputs consistent across training and serving. In Google Cloud\u2019s current architecture, BigQuery feature tables act as the data source, while Vertex AI Feature Store can synchronize selected feature views into an online store for low-latency serving. Offline workflows continue to use BigQuery directly.<\/p>\n
Within AI on Google Cloud<\/a>, Feature Store sits between data engineering and model serving. Its job is not merely to make lookup fast; it is to make the feature definition, entity key, freshness, and point-in-time meaning stable enough that training and production inference refer to the same concept.<\/p>\n The hardest failures are usually not outages. They are silent mismatches between what the model learned during training and what the online application provides later.<\/p>\n Google Cloud\u2019s feature-serving guidance starts with feature data stored in BigQuery tables. This gives offline training and analysis a durable SQL-accessible source and avoids maintaining an unrelated offline feature store.<\/p>\n BigQuery also makes it practical to derive features with scheduled queries, Dataform, pipelines, or existing analytical transformations before those features are synchronized for online serving.<\/p>\n The feature table should have a clear owner and data contract because every downstream model that depends on it inherits its semantics.<\/p>\n Time-sensitive features must represent what would have been known at the historical prediction time. BigQuery provides functions such as Without temporal correctness, a training query can accidentally use a future account status, later purchase, or post-event label information that would not have existed when the prediction should have been made.<\/p>\n This type of leakage can produce excellent offline metrics and disappointing production performance, so time semantics belong in the feature contract.<\/p>\n Vertex AI Feature Store serves feature values from feature views. A view identifies the BigQuery-backed feature data and the entity identifier used for online retrieval.<\/p>\n The online store does not need every feature in the warehouse. It should synchronize only the features required by latency-sensitive production models.<\/p>\n A small, purpose-built online feature surface is easier to govern and cheaper to keep fresh than replicating every analytical column.<\/p>\n A feature view must be synchronized into the online store before it can serve values. That creates an operational dependency between BigQuery data freshness and the online store\u2019s sync state.<\/p>\n Monitoring should track last successful sync, sync duration, failed rows, and source freshness so the application can distinguish \u201cfeature value is old\u201d from \u201cfeature is legitimately unchanged.\u201d<\/p>\n If stale features create unacceptable model risk, the serving application needs a fallback or fail-closed strategy rather than using old values silently.<\/p>\n Online serving retrieves feature values for entity identifiers such as customer, account, device, or product IDs. The application should obtain those IDs from trusted business context rather than accepting arbitrary client-supplied identifiers.<\/p>\n A feature store can return the correct value for the wrong entity if the caller is allowed to query it. Authorization and tenancy must therefore be enforced around the online lookup.<\/p>\n Entity definitions should also remain stable across training, serving, and evaluation so one model does not silently reinterpret the same key.<\/p>\n For time-sensitive features, the timestamp should reflect when the feature value became true or valid in the business process. Using only warehouse-load time can distort point-in-time training when pipelines are delayed or backfilled.<\/p>\n Separating event time from ingestion time also makes freshness monitoring clearer. A row loaded today may represent an event that occurred yesterday.<\/p>\n The feature contract should document which timestamp is used for historical correctness and which timestamp is used for pipeline operations.<\/p>\n Even when one BigQuery source is used, skew can appear because online synchronization cadence, preprocessing, missing-value behavior, or model version differs from the training workflow.<\/p>\nBigQuery should remain the authoritative feature source<\/h3>\n
Point-in-time correctness prevents training leakage<\/h3>\n
ML.FEATURES_AT_TIME<\/code> and ML.ENTITY_FEATURES_AT_TIME<\/code> to support point-in-time lookups.<\/p>\nFeature views define what is synchronized for online use<\/h3>\n
Online serving requires successful synchronization first<\/h3>\n
Entity IDs are a security and correctness boundary<\/h3>\n
Feature timestamps should represent the business event, not only ingestion time<\/h3>\n
Training-serving skew needs explicit monitoring<\/h3>\n