Matérialiser les affichages de fonctionnalités

Une fois que vous avez créé vos définitions d’affichage des fonctionnalités, qui sont stockées dans le catalogue Unity, vous pouvez produire des données de fonctionnalités à partir de votre table source à l’aide des définitions de fonctionnalités. Ce processus est appelé matérialisation de vos fonctionnalités. Azure Databricks crée et gère des pipelines Lakeflow pour remplir des tables dans Unity Catalog pour l’apprentissage des modèles et le scoring par batch ou le traitement en ligne.

Pour en savoir plus sur la diffusion des Feature Views, consultez Diffuser des Feature Views.

Pour recalculer les valeurs matérialisées après avoir corrigé ou ajouté des données sources historiques, consultez Vues de fonctionnalités de remplissage.

Pour supprimer les valeurs matérialisées pour les entités sélectionnées, consultez Purger les valeurs des caractéristiques pour les entités.

Spécifications

• Les fonctionnalités doivent être créées en tant que vues de fonctionnalités et stockées dans le catalogue Unity.
• Pour les exigences de version, voir Exigences.

Prise en charge de la matérialisation par type de caractéristique

La possibilité et l’endroit où une caractéristique peut être matérialisée dépend de son type :

• ColumnSelection les fonctionnalités peuvent être matérialisées dans des magasins en ligne. Consultez matérialisation de la sélection de colonnes.
• Les fonctionnalités Last batch avec un RollingWindow peuvent être matérialisées dans les magasins en ligne. Voir Materialize les valeurs les plus récentes sous contrainte de fraîcheur.
• Les fonctionnalités RequestSource, FeatureViewSource et CustomUDF ne peuvent pas être matérialisées. Voir Fonctionnalités à la demande et matérialisation.

Les fonctionnalités qui ne se matérialisent que dans les boutiques en ligne restent utilisables hors ligne : create_training_set et compute_features calculent leurs valeurs à un moment donné directement depuis la source, donc aucune matérialisation hors ligne n’est nécessaire.

Matérialisation de la sélection de colonnes

ColumnSelection les fonctionnalités sélectionnent la dernière valeur d’une seule colonne par clé d’entité sans agrégation. Ils ne peuvent être matérialisés que dans des magasins en ligne. Pour les cas d’usage hors connexion (apprentissage et inférence par lots), ColumnSelection les fonctionnalités sont extraites directement des données sources au moment de la requête, de sorte que la matérialisation hors connexion n’est pas nécessaire.

Comportement de matérialisation

• Le pipeline écrit la ligne la plus récente pour chaque clé d’entité dans le tableau en ligne, sans fenêtre d’agrégation.
• La matérialisation en ligne actualise la table en ligne avec la dernière valeur par clé d’entité.

Exemple

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    DeltaTableSource, Feature, ColumnSelection, TableTrigger, OnlineStoreConfig,
)

fe = FeatureEngineeringClient()

delta_source = DeltaTableSource(
    catalog_name="catalog",
    schema_name="schema",
    table_name="transactions",
)

amount_feature = Feature(
    source=delta_source,
    function=ColumnSelection("amount"),
    entity=["user_id"],
    timeseries_column="transaction_time",
    name="latest_transaction_amount",
)

# Register before materializing
amount_feature = fe.register_feature(
    feature=amount_feature,
    catalog_name="catalog",
    schema_name="schema",
)

mfs = fe.materialize_features(
    features=[amount_feature],
    online_config=OnlineStoreConfig(
        catalog_name="catalog",
        schema_name="feats_online",
        table_name_prefix="txn_",
        online_store_name="lb_usw2"
    ),
    trigger=TableTrigger(),
)

ColumnSelection utilise les fonctionnalités de TableTrigger, qui exécute le pipeline chaque fois que la table Delta source reçoit un nouveau commit. Aucun offline_config n'est nécessaire, car les caractéristiques de ColumnSelection sont lues directement à partir de la source pour les cas d’usage hors connexion (formation et inférence par lots).

Note

RequestSource les fonctionnalités ne peuvent pas être matérialisées, car elles représentent les données fournies par l’appelant au moment de l’inférence (ou extraites du DataFrame étiqueté au moment de l’entraînement). Il n’existe aucune table source à lire. Les valeurs existent uniquement dans la charge utile de la requête ou dans le DataFrame d’entraînement.

Matérialisez les valeurs les plus récentes limitées par un seuil de fraîcheur

Une agrégation par lots Last avec un RollingWindow donne à une feature en ligne une durée de vie (TTL) : sa valeur expire et est supprimée du magasin en ligne lorsqu’aucune valeur source ne se situe dans cette fenêtre. Cela est utile lorsque l’âge d’une valeur détermine si elle est sûre à servir. Par exemple, un état de l’appareil de la dernière heure peut être servi, tandis qu’un état plus ancien se résout en nul au lieu de rester disponible indéfiniment.

A RollingWindow définit une durée explicite qui confère à la fonctionnalité un comportement de type TTL. Par exemple, si la source publie des valeurs quotidiennement et que vous souhaitez ne conserver que les valeurs des sept derniers jours, utilisez a RollingWindow avec une durée de sept jours. À chaque déclencheur, la matérialisation remplace complètement la table en ligne, de sorte que les valeurs qui dépassent la fenêtre sont supprimées selon un calendrier prévisible. Cela produit le même résultat qu’un streaming Last avec un RollingWindow, mais coûte moins cher car il ne s’exécute pas en continu.

Ce modèle de publication est similaire à une table de caractéristiques avec un TTL publiée en mode instantané. Si vous maintenez un ensemble de tables de caractéristiques et souhaitez les utiliser aux côtés d’autres Feature Views, vous pouvez les adapter au cadre de création des Feature Views. Utilisez un lot Last avec un RollingWindow et un TableTrigger.

Cette combinaison propose un mode spécial de matérialisation uniquement en ligne avec les exigences suivantes :

• La source doit être un DeltaTableSource.
• La fonction d’agrégation doit être Last et sa fenêtre doit être RollingWindow.
• La matérialisation doit fournir un OnlineStoreConfig, omettre OfflineStoreConfig, et utiliser TableTrigger.

Dans l’exemple suivant, latest_device_state_1h se trouve une fonctionnalité enregistrée qui répond à ces exigences :

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import OnlineStoreConfig, TableTrigger

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=[latest_device_state_1h],
    online_config=OnlineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="latest_device_state_serving",
        online_store_name="device_state_store",
    ),
    trigger=TableTrigger(),
)

Pour la formation hors ligne et le score par lots, le client d’ingénierie des fonctionnalités calcule la valeur à un moment donné directement depuis la source. Il ne détecte pas de matérialisation hors ligne pour cette fonctionnalité.

Considérations

• L’expiration ne progresse qu’au déclenchement. La valeur en ligne et son délai d’expiration avancent lorsqu’un commit de table source déclenche une actualisation de matérialisation. Le temps qui passe à lui seul ne déclenche pas un rafraîchissement. Si le code source cesse de publier, la dernière valeur matérialisée reste dans la boutique en ligne jusqu’à ce qu’un commit ultérieur déclenche un rafraîchissement.
• Alignez la colonne de la série temporelle avec l’heure de publication de la source. La colonne de la série temporelle doit indiquer quand la source a publié les données. Sinon, les valeurs en ligne et hors ligne divergent, car le magasin en ligne rejoint au moment du déclenchement tandis que les lectures hors ligne se rejoignent au moment de la série temporelle.
• Fixez la durée de la fenêtre à un multiple de la cadence de publication. Si la RollingWindow durée n’est pas un multiple de la cadence de publication de la source, certaines valeurs sont considérées comme expirées lors de l’entraînement hors ligne alors qu’elles sont encore visibles en ligne.

Fonctionnalités à la demande et matérialisation

RequestSource les valeurs proviennent du DataFrame d’entraînement ou de la requête d’inférence, il n’y a donc pas de table source à matérialiser. Les caractéristiques FeatureViewSource appliquent un CustomUDF aux valeurs des caractéristiques en amont pendant la formation ou le service. Ils ne stockent pas de résultat précalculé. La matérialisation n’est pas non plus prise en charge pour les fonctionnalités CustomUDF basées sur une table Delta.

Pour un graphe de dépendance tel que revenue_sum_7d et cost_sum_7d alimentant une margin caractéristique :

• Pour la formation hors ligne, appelez create_training_set avec margin. Il résout les fonctionnalités en amont et calcule les valeurs en un moment donné, en utilisant des matérialisations hors ligne compatibles lorsque disponibles.
• Pour la mise en service en ligne, matérialisez les variables de revenus et de coûts prises en charge dans un magasin en ligne. Le point de terminaison les recherche et calcule margin pour chaque requête.
• Ne transférez que les fonctionnalités en amont supportées à materialize_features, non margin ou aucune fonctionnalité soutenue par requête. La matérialisation ne matérialise pas récursivement les dépendances d’une caractéristique dérivée.

Un graphe qui utilise uniquement des fonctionnalités soutenues par requête n’a pas besoin d’une boutique en ligne. Voir S’entraîner avec les variables FeatureViewSource et servir des variables dérivées.

Permissions

La matérialisation nécessite des privilèges sur la fonctionnalité ainsi que sur les ressources source et destination. Pour les descriptions complètes des privilèges du Catalogue Unity, voir la référence des privilèges du Catalogue Unity.

• La matérialisation d’une fonctionnalité nécessite MANAGE. Appeler materialize_features crée et gère les pipelines Lakeflow et les tables de catalogue Unity qui le soutiennent, donc c’est une opération de gestion. Vous devez avoir MANAGE pour la fonctionnalité, ainsi que READ FEATURE pour lire la définition de la fonctionnalité en cours de matérialisation.

• La suppression d’une fonctionnalité matérialisée est réservée à son créateur. Seul l’utilisateur ayant créé une fonctionnalité matérialisée peut la supprimer avec delete_materialized_feature. Cette restriction est indépendante des privilèges du catalogue Unity : MANAGE sur la fonctionnalité ou son schéma parent ne permet pas à un autre utilisateur de la supprimer.

• La lecture des données sources nécessite SELECT. Pour une fonctionnalité qui utilise une source de table Delta, vous devez avoir SELECT sur la table source. Pour une fonctionnalité qui utilise une source Stream, vous devez disposer de SELECT sur la table d’ingestion du Stream.

  Pour les autres permissions requises par la configuration d’authentification d’un Stream, voir authentification Kafka.

• Créer des tables de destination nécessite CREATE TABLE. Vous devez avoir CREATE TABLE sur chaque schéma spécifié par OfflineStoreConfig ou OnlineStoreConfig. Les destinations hors ligne et en ligne peuvent être dans différents schémas ou catalogues, et la matérialisation nécessite des privilèges sur chaque destination.

• Pour créer une boutique en ligne, il faut CAN USE. Vous devez avoir CAN USE sur l’instance ou le projet Lakebase utilisé par la boutique en ligne. Pour des informations sur les autorisations de Lakebase, voir Accorder les autorisations de projet.

• Le listage des fonctionnalités matérialisées nécessite READ FEATURE sur la fonctionnalité parente. Pour utiliser list_materialized_features, vous devez disposer de READ FEATURE pour la fonctionnalité qui a été activée.

• La lecture des données matérialisées nécessite SELECT. Vous devez disposer de SELECT pour chaque table de sortie, hors ligne ou en ligne, à laquelle vous accédez. READ FEATURE la fonction parent n’accorde pas l’accès à ces tableaux.

Pour chaque ressource Unity Catalog impliquée dans la matérialisation, vous devez également disposer de USE CATALOG sur son catalogue parent et de USE SCHEMA sur son schéma parent. Cette exigence s’applique à la fonctionnalité, à chaque table d’ingestion source ou de flux, et à chaque destination configurée. READ FEATURE et MANAGE accordés sur un schéma ou un catalogue s’appliquent à toutes les fonctionnalités actuelles et futures qu’il contient.

Structures de données d’API

OfflineStoreConfig

Configuration du magasin hors connexion où les fonctionnalités matérialisées seront enregistrées. Lorsqu’materialize_features est appelé, le back-end du Feature Store crée des tables à l’aide de ce préfixe. Chaque exécution de pipeline matérialise les valeurs de fonctionnalités les plus récentes dans la table en fonction de la planification de matérialisation.

OfflineStoreConfig(
    catalog_name: str,        # Catalog name for the offline table where materialized features will be stored
    schema_name: str,         # Schema name for the offline table
    table_name_prefix: str    # Table name prefix for the offline table. The pipeline may create multiple tables with this prefix, each updated at different cadences
)

from databricks.feature_engineering.entities import OfflineStoreConfig

offline_store = OfflineStoreConfig(
    catalog_name="main",
    schema_name="feature_store",
    table_name_prefix="customer_features"
)

OnlineStoreConfig

Configuration du magasin en ligne, qui stocke les fonctionnalités utilisées par la mise en service de modèles. La matérialisation crée des tables Delta avec le catalog.schema.table_name_prefix et diffuse les tables vers le magasin de caractéristiques en ligne portant le même nom.

from databricks.feature_engineering.entities import OnlineStoreConfig

online_store = OnlineStoreConfig(
    catalog_name="main",
    schema_name="feature_store",
    table_name_prefix="customer_features_serving",
    online_store_name="customer_features_store"
)

MaterializedFeature

Représente une Feature View qui a été matérialisée, autrement dit, qui dispose d’une représentation pré-calculée dans Unity Catalog. Il existe des fonctionnalités matérialisées distinctes pour la table hors connexion et la table en ligne. En général, on n’instanciait pas directement un MaterializedFeature personnage.

Le latest_backfill_operation champ porte le nom du remblai le plus récent de la structure matérialisée. Voir les vues des fonctionnalités de remplissage.

Appels de fonction API

materialize_features()

Matérialise une liste de vues de fonctionnalités soit dans une table Delta hors ligne, soit dans un magasin de fonctionnalités en ligne. Les fonctionnalités doivent être inscrites dans le catalogue Unity avant d’appeler cette fonction (par exemple, à l’aide create_feature ou register_feature). Les fonctionnalités construites localement qui n’ont pas été inscrites ne fonctionnent pas.

FeatureEngineeringClient.materialize_features(
    *,                                                                     # Arguments are keyword-only
    features: List[Feature],                                               # List of Feature Views to materialize
    offline_config: Optional[OfflineStoreConfig] = None,                   # Offline store config (aggregation features only)
    online_config: Optional[OnlineStoreConfig] = None,                     # Online store config
    trigger: Union[CronSchedule, TableTrigger, StreamingMode],             # Materialization trigger
    tags: Optional[Dict[str, str]] = None,                                 # Custom tags for cost attribution
    budget_policy_id: Optional[str] = None,                                # Serverless usage policy for cost attribution
) -> List[MaterializedFeature]:

La méthode retourne une liste de fonctionnalités matérialisées, qui contiennent des métadonnées sur le moment où les valeurs des fonctionnalités sont mises à jour et les tables du catalogue Unity où les fonctionnalités sont matérialisées.

Si un OnlineStoreConfig et un OfflineStoreConfig sont fournis, deux fonctionnalités matérialisées sont retournées par fonctionnalité fournie, une pour chaque type de magasin.

Le paramètre trigger contrôle quand le pipeline de matérialisation s’exécute :

• CronSchedule : s’exécute selon une planification dérivée des paramètres de synchronisation de la fonctionnalité ou selon une planification cron de Quartz fournie par l’appelant. Pris en charge pour les fonctions d’agrégation par lots (AggregationFunction à partir de DeltaTableSource).
• TableTrigger: s’exécute lorsque la table Delta en amont reçoit une validation. Compatible avec les fonctionnalités ColumnSelection et les fonctionnalités d’agrégation (AggregationFunction) prises en charge par un fichier DeltaTableSource. Pour les fonctionnalités d’agrégation, la fréquence d’exécution du pipeline est limitée à au plus une fois par moitié de la granularité de la fonctionnalité (la durée de glissement pour une fenêtre coulissante, ou la longueur de la fenêtre pour une fenêtre basculante), avec un plafond d’une heure et sans jamais dépasser une exécution toutes les 5 minutes. Par exemple, au maximum une fois toutes les 30 minutes pour une granularité d’une heure, ou au plus une fois par heure pour une granularité de 2 heures ou plus. L’intervalle est mesuré depuis l’exécution précédente, donc un commit qui arrive après son expiration déclenche néanmoins rapidement une exécution.
• StreamingMode: fonctionne comme pipeline de diffusion en continu. Obligatoire pour les fonctionnalités prises en charge par un StreamSource.

Vous ne pouvez pas combiner des fonctionnalités qui nécessitent différents types de déclencheurs dans un seul materialize_features appel. Émettre des appels distincts à la place.

Pour attribuer le coût d’une matérialisation, passe tags, budget_policy_id, ou les deux. Azure Databricks les applique au travail ou au pipeline qu’il crée, donc ses dépenses correspondent à votre attribution dans la table du système d’utilisation facturable. Les deux sont appliqués lors de la création, donc attribuer une matérialisation existante différemment signifie en créer une nouvelle. budget_policy_id accepte l’identifiant d’une stratégie d’utilisation serverless. Pour en créer un et obtenir son ID, voir Créer une politique d’utilisation serverless. Pour les limites de tags, les ressources que chaque valeur atteint, et comment interroger la dépense attribuée, voir Gestion des coûts du Feature Store.

Matérialiser le magasin hors connexion

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    CronSchedule, OfflineStoreConfig,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=features,
    offline_config=OfflineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features"
    ),
    trigger=CronSchedule(
        quartz_cron_expression="0 0 * * * ?",  # Hourly
        timezone_id="UTC",
    ),
)

Matérialiser une boutique en ligne

Note

Pour intégrer la plupart des fonctionnalités d’agrégation dans une boutique en ligne, vous devez également vous rendre sur une boutique hors ligne. Les deux offline_config et online_config sont obligatoires. Il online_store_name doit faire référence à un magasin de fonctionnalités en ligne existant. Pour obtenir des instructions sur la création d’une fonctionnalité, consultez Databricks Online Feature Stores.

Les fonctionnalités de ColumnSelection ne nécessitent pas de OfflineStoreConfig. Consultez matérialisation de la sélection de colonnes.

Le batch Last avec le cas spécial RollingWindow est également uniquement en ligne. Voir Materialize les valeurs les plus récentes sous contrainte de fraîcheur.

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    CronSchedule, OfflineStoreConfig, OnlineStoreConfig,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=features,
    offline_config=OfflineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features"
    ),
    online_config=OnlineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features_serving",
        online_store_name="customer_features_store"
    ),
    trigger=CronSchedule(
        quartz_cron_expression="0 0 * * * ?",  # Hourly
        timezone_id="UTC",
    ),
)

Créer des fonctionnalités de streaming

Les fonctionnalités de diffusion en continu ne peuvent être matérialisées que dans des magasins en ligne ; le offline_config paramètre n’est pas pris en charge. La matérialisation hors ligne n’est pas prise en charge, car les fonctionnalités de streaming nécessitent un pipeline en temps réel pour garantir une fraîcheur inférieure à la seconde. Pour l’entraînement ou l’évaluation hors connexion, le client d’ingénierie des fonctionnalités récompose les valeurs des fonctionnalités en fonction de chaque point de données évalué.

Les fonctionnalités de streaming ne peuvent pas être mélangées à des fonctionnalités de traitement par lots dans le même materialize_features appel.

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    OnlineStoreConfig, StreamingMode,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=[streaming_feature],
    online_config=OnlineStoreConfig(
        catalog_name="my_catalog",
        schema_name="my_schema",
        table_name_prefix="streaming_features_serving",
        online_store_name="feature_store_online"
    ),
    trigger=StreamingMode(),
)

list_materialized_features()

Retourne les matérialisations d’une seule fonctionnalité, identifiées par son nom complet. feature_name est obligatoire et uniquement par mot-clé. Pour examiner les matérialisations sur plusieurs attributs, commencez par lister les attributs dans un catalogue ou un schéma, puis appelez list_materialized_features pour chaque attribut renvoyé.

Par défaut, un maximum de 100 matérialisations sont retournées. Vous pouvez modifier cette limite à l’aide du max_results paramètre.

FeatureEngineeringClient.list_materialized_features(
    *,                                      # Arguments are keyword-only
    feature_name: str,                      # Required: full name of the feature whose materializations to list
    max_results: int = 100,                 # Maximum number of materializations to return
) -> List[MaterializedFeature]:

delete_materialized_feature()

Avant de supprimer une fonctionnalité matérialisée, supprimez ou mettez à jour des modèles ou des spécifications de fonctionnalités qui référencent la fonctionnalité.

Supprime une fonctionnalité matérialisée. La fonctionnalité à transmettre dépend du type de fonctionnalité :

• Fonctionnalités d’agrégation : passez la fonctionnalité matérialisée hors connexion. S’il existe une fonctionnalité matérialisée en ligne pour la même fonctionnalité, les deux sont supprimées. Pour une fonctionnalité Last batch uniquement en ligne avec un RollingWindow, passez la fonctionnalité matérialisée en ligne.
• ColumnSelection fonctionnalités : passez la fonctionnalité matérialisée en ligne. ColumnSelection les fonctionnalités sont matérialisées uniquement dans le magasin en ligne (voir Matérialisation de la sélection de colonnes), par conséquent il n’existe aucune fonctionnalité hors connexion appairée.

Dans le cadre de la matérialisation, les fonctionnalités sont regroupées par source de données et par fenêtre d’agrégation pour plus d’efficacité. ColumnSelection les fonctionnalités n’ont aucune fenêtre d’agrégation. Elles sont donc regroupées uniquement par source de données. Le pipeline de matérialisation, la table hors connexion et la table en ligne ne sont pas supprimés tant que toutes les fonctionnalités groupées n’ont pas été supprimées. Lorsque la dernière fonctionnalité matérialisée d’un groupe est supprimée, le magasin de fonctionnalités planifie les ressources associées pour le nettoyage automatique par un processus en arrière-plan. Consultez le nettoyage des ressources en arrière-plan.

Pour nettoyer les fonctionnalités matérialisées, examinez la table associée à une fonctionnalité matérialisée. Chaque fonctionnalité de la table (une par colonne) doit être supprimée avant que les ressources de calcul et de table Delta soient nettoyées.

Utilisez list_materialized_features() pour obtenir l’argument materialized_feature.

FeatureEngineeringClient.delete_materialized_feature(
    materialized_feature: MaterializedFeature,  # Required: The materialized feature to delete
) -> None

from databricks.feature_engineering import FeatureEngineeringClient

fe = FeatureEngineeringClient()

feature_names = [
    "main.feature_store.amount_sum_sliding_7d_1d",
    "main.feature_store.amount_sum_sliding_30d_1d",
    "main.feature_store.transaction_count_sliding_7d_1d",
    "main.feature_store.latest_transaction_amount",
    "main.feature_store.latest_user_tier",
]

for name in feature_names:
    mfs = fe.list_materialized_features(feature_name=name)   # required, keyword-only
    offline = [mf for mf in mfs if not mf.is_online]
    for mf in (offline or mfs):
        fe.delete_materialized_feature(materialized_feature=mf)
    fe.delete_feature(full_name=name)

Nettoyage des ressources en arrière-plan

Lorsque vous supprimez une fonctionnalité matérialisée, Databricks supprime immédiatement les métadonnées de fonctionnalité. L’infrastructure associée (tables, pipelines et tâches) est nettoyée de manière asynchrone par un processus en arrière-plan.

Étant donné que plusieurs fonctionnalités matérialisées peuvent partager les mêmes tables et pipelines, ces ressources partagées ne sont pas supprimées tant que chaque fonctionnalité matérialisée qui les référence a été supprimée. Lorsque la dernière fonctionnalité matérialisée partageant un ensemble de tables est supprimée, le processus en arrière-plan supprime automatiquement les ressources suivantes :

• Tables Delta hors connexion contenant les données de caractéristique matérialisées
• Les tables en ligne, si les fonctionnalités ont été matérialisées dans un magasin en ligne
• La chaîne de matérialisation
• Travail d’orchestration

Ce processus en arrière-plan utilise un principal de service système géré par Databricks pour effectuer ces actions de nettoyage en votre nom, notamment la suppression de tables, de pipelines et de travaux dans votre espace de travail. Aucune action de votre part n’est nécessaire. Le nettoyage est entièrement géré par le feature store.

Note

Il peut y avoir un court délai entre la suppression de la dernière fonctionnalité matérialisée dans un groupe et la suppression des tables associées et d’autres ressources.

Afficher l’état de matérialisation

Pour voir l’état de matérialisation de vos vues de fonctionnalités dans l’interface Databricks et déboguer les erreurs de matérialisation, consultez Explorer les vues de fonctionnalités dans Unity Catalog.

Valider la fraîcheur de bout en bout de RollingWindow

Note

La validation de la fraîcheur utilise le flux de données de changement de Lakebase (CDF), qui est disponible en Aperçu Public. Un administrateur d’espace de travail doit activer l’aperçu de Lakebase Change Data Feed avant de pouvoir activer CDF.

Cette section s’applique uniquement aux RollingWindow agrégations. Les fonctionnalités batch ne révèlent pas les métadonnées de fraîcheur du streaming décrites ici.

Les fonctionnalités de streaming RollingWindow matérialisées dans un magasin en ligne Lakebase comportent des métadonnées de fraîcheur pour chaque ligne. Avec CDF, vous capturez chaque mise à jour de la table en ligne dans une table historique Delta dans Unity Catalog et mesurez la fraîcheur de bout en bout sans exécuter un pipeline supplémentaire. La fraîcheur de bout en bout correspond au décalage entre le moment où un événement s’est produit et celui où sa valeur agrégée est devenue disponible pour être servie.

Comment les fonctionnalités de RollingWindow émettent des lignes

Pour une RollingWindow fonctionnalité, la valeur de chaque entité résume les événements dans une fenêtre de temps fixe (par exemple, le nombre de transactions dans la dernière heure). La fenêtre glissante avance continuellement, donc une ligne est écrite sur la boutique en ligne dans deux situations :

• Mise à jour basée sur les données (is_timer = false) : un nouvel événement arrive et met à jour l’agrégat. La ligne reflète l’événement le plus récent dans la fenêtre.
• Expiration de la fenêtre (is_timer = true) : aucun nouvel événement n’arrive, mais le temps avance et les événements les plus anciens sortent de la fenêtre, ou expirent. Comme ces événements ne comptent plus dans l’agrégat, la valeur change (par exemple, un compte diminue), donc la fonctionnalité émet une ligne mise à jour sur un minuteur. La ligne reflète le moment où l’événement le plus ancien est sorti de la fenêtre, c’est-à-dire la fin de la fenêtre de cet événement.

Dans les deux cas, event_time c’est à ce moment que le changement qui a produit la ligne s’est produit : un nouvel événement arrive, ou l’événement le plus ancien qui expire. commit_time - event_time correspond à la fraîcheur de la ligne, peu importe la manière dont elle a été émise.

Métadonnées de fraîcheur

Chaque ligne de streaming en ligne comporte les colonnes suivantes :

Column	Description
event_time	Quand le changement qui a produit la ligne s’est produit. Lors d’une mise à jour pilotée par les données (is_timer = false), heure de l’événement la plus récente (maximale) dans la fenêtre. Lors d’une mise à jour d’expiration de fenêtre (is_timer = true), le moment où l’événement le plus ancien a expiré : le temps de cet événement plus la durée de la fenêtre. Si le tableau en ligne contient des attributs avec des durées de fenêtres différentes, la fenêtre expirée est utilisée.
output_time	La limite de la fenêtre de streaming (watermark) à l’émission.
is_timer	Comment la ligne a été émise : false = un événement nouvellement arrivé a avancé l’agrégat (piloté par les données) ; true = la fenêtre a avancé sur un minuteur et les données les plus anciennes ont expiré (expiration de la fenêtre).
commit_time	Quand la ligne a été écrite sur la boutique en ligne de Lakebase.

Lorsque le CDF est activé, chaque changement est ajouté à une lb_<online_table>_history table Delta avec des colonnes de métadonnées CDF. La _pg_change_type colonne (insert, update_preimage, update_postimage, ou delete) identifie chaque type de changement.

Activez le CDF sur le tableau en ligne

Warning

Utilisez CDF pour valider la fraîcheur de bout en bout, par exemple pendant que vous testez un pipeline ou ajustez sa configuration, plutôt que pour surveiller en continu la fraîcheur sur une boutique en ligne de production. CDF et REPLICA IDENTITY FULL ajoutent de la charge à l’instance Lakebase, principalement le CPU pour décoder les modifications et un volume supplémentaire de journal d’écriture anticipée. La surcharge augmente avec le nombre de tables synchronisées et avec les valeurs de colonne volumineuses telles que des tableaux ou des mappages. Si vous activez le CDF sur une boutique en ligne qui sert le trafic de production, augmentez le maximum d’unités de calcul (CU) pour que l’auto-scaling ait de la marge de manœuvre, et surveillez l’utilisation du processeur et la latence de diffusion en ligne.

1. Lakebase CDF exige que l’identité de réplique soit définie sur FULL sur chaque table source afin que les mises à jour soient capturées avec des images complètes des lignes avant et après modification. Pose-le sur le tableau en ligne :

   ALTER TABLE <schema>.<online_table> REPLICA IDENTITY FULL;
   

2. Lancez Lakebase CDF pour la boutique en ligne, choisissez le schéma source et un catalogue et schéma Unity Catalog de destination. Pour les détails de la configuration, voir Lakebase Change Data Feed.

CDF crée lb_<online_table>_history dans le schéma de destination.

Pour arrêter de capturer les changements, voir Désactiver le CDF de Lakebase. Désactiver CDF arrête le flux pour tous les schémas du projet. Après avoir désactivé le CDF, vous pouvez réinitialiser l’identité de réplique de la table en ligne pour supprimer le volume supplémentaire de journal d’écriture anticipée :

ALTER TABLE <schema>.<online_table> REPLICA IDENTITY DEFAULT;

Actualité du calcul

La fraîcheur est commit_time - event_time pour les lignes basées sur les données ainsi que pour celles avec expiration de fenêtres. Incluez is_timer pour pouvoir comparer les deux types d’émissions, et limitez la requête à la période que vous souhaitez analyser.

SELECT
  event_time,
  commit_time,
  is_timer,
  (unix_micros(commit_time) - unix_micros(event_time)) / 1000 AS feature_freshness_ms
FROM <dest_catalog>.<dest_schema>.lb_<online_table>_history
WHERE _pg_change_type IN ('insert', 'update_postimage')
  AND commit_time >= (
    SELECT max(commit_time) - INTERVAL 1 DAY
    FROM <dest_catalog>.<dest_schema>.lb_<online_table>_history
  );

feature_freshness_ms est le décalage, en millisecondes, entre le moment de l’événement et l’écriture dans la boutique en ligne. Il s’agit de la fraîcheur de la valeur disponible pour la diffusion.

Note

Lorsque vous activez CDF sur une table en ligne qui contient déjà des lignes, l’instantané initial copie chaque ligne existante dans la table d’historique sous la forme d’un insert. Chaque ligne copiée conserve le event_time et commit_time de la dernière écriture de cette entité, donc sa valeur de fraîcheur est exacte, mais l’instantané fournit exactement un échantillon par entité. Pour ne mesurer que les écritures capturées par le feed, attendez que le statut de la table dans l’onglet CDF de Lakebase change de Snapshotting à Streaming, notez l’heure, et utilisez-la comme borne inférieure au lieu de max(commit_time) - INTERVAL 1 DAY. Un changement de schéma sur la table en ligne déclenche un autre instantané complet, qui duplique les écritures déjà capturées par le flux. Ne filtrez pas toutes les lignes insert, car la première écriture pour chaque nouvelle entité est aussi un insert.

Interpréter les résultats

• Suivez à la fois p50 et p99 de feature_freshness_ms, et comparez les lignes pilotées par les données (is_timer = false) avec les lignes d’expiration de fenêtre (is_timer = true).
• Attendez-vous à un petit pic périodique à la limite du lot du mode temps réel (5 minutes par défaut), lorsque le pipeline fait une courte pause pour checkpoint et commit. Cela est généralement négligeable à l’intervalle par défaut.
• Regardez la rare longue traîne (le maximum, au-delà de p99). Il reflète le rattrapage du pipeline plutôt qu’un état stable, notamment après un redémarrage, comme un redémarrage de maintenance, lorsque le pipeline traite des événements en mémoire tampon. Mesurez la fraîcheur de l’état stationnaire sur une fenêtre excluant les redémarrages, et évaluez séparément les pics de redémarrage.

Limites

Fonctionnalités par lot

• Les pipelines de matérialisation par lots s’exécutent comme des pipelines Lakeflow sans serveur.
• Les fonctionnalités de fenêtre glissante batch ne peuvent pas être matérialisées, à l’exception du cas particulier Last uniquement en ligne décrit dans Matérialiser les dernières valeurs limitées par l'actualisation. Pour l’entraînement hors ligne ou l’inférence par lots, les fonctionnalités de fenêtres roulantes sont calculées à partir des données sources pour chaque recherche en un instant donné.
• ColumnSelection les fonctionnalités peuvent uniquement être matérialisées dans des magasins en ligne.
• Les fonctionnalités RequestSource, FeatureViewSource et CustomUDF ne peuvent pas être matérialisées. Voir Fonctionnalités à la demande et matérialisation.
• Les fonctionnalités matérialisées ne peuvent être supprimées que dans l’espace de travail dans lequel elles ont été créées.
• Seul l’utilisateur ayant créé une fonctionnalité matérialisée peut la supprimer, indépendamment des privilèges du catalogue Unity sur la fonctionnalité ou son schéma parent.
• Pour les fonctionnalités d’agrégation matérialisées, la fonctionnalité matérialisée en ligne ne peut pas être supprimée directement. Supprimez la fonctionnalité matérialisée et hors ligne associée, et la modification se répercute sur les deux fonctionnalités.
• Pour les fonctionnalités d’agrégation matérialisées créées avant le 20 avril 2026, le pipeline de matérialisation continue de produire de nouvelles valeurs de fonctionnalités jusqu’à ce que toutes les fonctionnalités matérialisées du pipeline aient été supprimées, ce qui déclenche le nettoyage des ressources. Pour créer un pipeline mis à jour qui prend en charge la suppression par fonctionnalité, supprimez et matérialisez à nouveau la fonctionnalité.
• Pour les fonctionnalités matérialisées ColumnSelection, le pipeline de matérialisation continue de produire de nouvelles valeurs de fonctionnalités jusqu’à ce que toutes les fonctionnalités matérialisées du pipeline aient été supprimées, ce qui déclenche le nettoyage des ressources.

Fonctionnalités de diffusion en continu

• Les fonctionnalités de diffusion en continu ne peuvent être matérialisées que dans des magasins en ligne. La matérialisation hors connexion n’est pas nécessaire, car les fonctionnalités de streaming au moment de l’entraînement sont conçues pour être recomputées à partir d’événements historiques par point de données pour fournir une précision au niveau de la milliseconde.
• Les fonctionnalités de streaming ne peuvent pas être mélangées à des fonctionnalités de traitement par lots dans un seul materialize_features appel.
• compute_features ne prend pas en charge les fonctionnalités de diffusion en continu.
• L’espace de travail doit se trouver dans une région qui prend en charge les instances Lakebase.
• Les messages Kafka peuvent utiliser JSON, Avro ou Protobuf. Pour les exigences du schéma et les limites du registre de schémas, voir Registre de schémas.
• Uniquement RollingWindow et SawtoothWindow sont pris en charge pour les fonctionnalités d’agrégation de streaming. TumblingWindow et SlidingWindow doit être utilisé avec les fonctionnalités de traitement par lots. Voir les fenêtres temporelles pour les fonctionnalités de streaming.
• Seules les fonctions d’agrégation Count, Avg, Sum, StddevPop, First, FirstN, Max, Last, LastN, Min, FirstDistinct et LastDistinct sont prises en charge pour les fonctionnalités de streaming.
• Les fonctionnalités de sélection de colonnes des sources de diffusion en continu ne gèrent pas les messages hors ordre. L’événement le plus récent sur le flux Kafka est affiché, même si la valeur de colonne timeseries est antérieure à un événement précédemment reçu.
• Les pipelines de streaming sont redémarrés deux fois par semaine. Chaque redémarrage peut entraîner des retards de traitement et des temps de démarrage allant jusqu’à 1 minute. En excluant les redémarrages, l'actualisation au p99 est de 200 ms.
• Les fonctionnalités de streaming ne peuvent pas être remplies en arrière avec backfill_features. Pour ajouter des données historiques à un flux pour l’entraînement, configurez une source de remblai sur le flux.
• Une RollingWindow fonctionnalité de la boutique en ligne ne couvre que les événements arrivant après le début de la matérialisation, de sorte que ses valeurs ne sont achevées qu’après le passage complet de la boutique window_duration . Une caractéristique calcule ses valeurs historiques à partir de la table d’ingestion du Flux lorsque la SawtoothWindow matérialisation commence. La matérialisation ne recalcule pas ces valeurs si vous corrigez ensuite les données dans la table d’ingestion.
• Seul databricks Online Feature Store est pris en charge.
• Les pipelines de matérialisation de streaming s’exécutent sous forme de pipelines Lakeflow serverless.