Featureweergaven materialiseren

Nadat u de definities van de functieweergave hebt gemaakt, die zijn opgeslagen in Unity Catalog, kunt u functiegegevens uit uw brontabel produceren met behulp van de functiedefinities. Dit proces wordt het materialiseren van uw functies genoemd. Azure Databricks maakt en beheert Lakeflow-pijplijnen om tabellen in Unity Catalog te vullen voor modeltraining en batchgewijs scoren of online serveren.

Zie Feature Views serveren voor informatie over het serveren van Feature Views.

Om gematerialiseerde waarden voor geselecteerde entiteiten te verwijderen, zie Featurewaarden voor entiteiten opschonen.

Requirements

• Functies moeten worden gemaakt als functieweergaven en worden opgeslagen in Unity Catalog.
• Zie Vereisten voor versievereisten.

Materialisatieondersteuning per featuretype

Of en waar een kenmerk kan worden gematerialiseerd, hangt af van het type ervan:

• ColumnSelection functies kunnen worden gerealiseerd in online winkels. Zie ColumnSelection materialization.
• Batch-features Last met een RollingWindow kunnen worden gematerialiseerd in online stores. Zie Materialize versheidsgebonden meest recente waarden.
• RequestSource, FeatureViewSource, en CustomUDF kenmerken kunnen niet worden gematerialiseerd. Zie On-demand functionaliteit en materialisatie.

Functies die alleen in online winkels verschijnen, zijn nog steeds offline bruikbaar: create_training_set en compute_features berekenen hun moment-in-tijd waarden direct vanaf de bron, zodat offline materialisatie niet nodig is.

Kolomselectie-materialisatie

ColumnSelection functies selecteren de meest recente waarde van één kolom per entiteitssleutel zonder aggregatie. Ze kunnen alleen worden verwezenlijkt bij online winkels. Voor offline gebruikssituaties (training en batchinferences) worden ColumnSelection features rechtstreeks opgehaald uit de brongegevens tijdens de query, zodat offline materialisatie niet nodig is.

Materialisatiegedrag

• De pijplijn schrijft de meest recente rij per entiteitssleutel naar de onlinetabel, zonder aggregatievenster.
• Online materialisatie vult de onlinetabel met de huidige meest recente waarde per entiteitssleutel.

Voorbeeld

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 gebruikt functies TableTrigger, waarmee de pijplijn wordt uitgevoerd wanneer de Delta-brontabel een nieuwe commit ontvangt. Er is geen offline_config nodig omdat ColumnSelection kenmerken rechtstreeks vanuit de bron worden gelezen voor offline gebruiksscenario's (training en batch-inferentie).

Materialiseer versheidsbegrensde laatste waarden

Een batchaggregatie Last met een RollingWindow geeft een online functie een time-to-live (TTL): de waarde vervalt buiten de online winkel wanneer geen bronwaarde binnen het venster valt. Dit is nuttig wanneer de leeftijd van een waarde bepaalt of het veilig is om te serveren. Bijvoorbeeld, een apparaatstatus van het afgelopen uur kan worden teruggegeven, terwijl een oudere status in null resulteert in plaats van onbeperkt beschikbaar te blijven.

A RollingWindow definieert een expliciete duur die de eigenschap TTL-achtig gedrag geeft. Als de bron bijvoorbeeld dagelijks waarden publiceert en je alleen waarden van de afgelopen zeven dagen wilt behouden, gebruik dan een RollingWindow met een duur van zeven dagen. Bij elke trigger voert materialisatie een volledige vervanging uit van de online tabel, zodat waarden die buiten het venster vallen op een voorspelbaar schema worden verwijderd. Dit levert hetzelfde resultaat op als een streaming Last met een RollingWindow, maar kost minder omdat de berekening niet continu wordt uitgevoerd.

Dit publicatiepatroon lijkt op een featuretabel met een TTL die in snapshotmodus wordt gepubliceerd. Als je een set featuretabellen bijhoudt en deze samen met andere Feature Views wilt gebruiken, kun je ze aanpassen aan het Feature Views-authoringframework. Gebruik een batch Last met een RollingWindow en een TableTrigger.

Deze combinatie heeft een specifieke modus voor uitsluitend online materialisatie met de volgende vereisten:

• De bron moet een DeltaTableSourcezijn.
• De aggregatiefunctie moet Lastzijn , en het venster ervan moet een RollingWindowzijn.
• De materialisatie moet voorzien in een OnlineStoreConfig, OfflineStoreConfig weglaten en TableTrigger gebruiken.

In het volgende voorbeeld latest_device_state_1h is er een geregistreerde Feature die aan deze eisen voldoet:

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(),
)

Voor offline training en batch scoring berekent de feature engineering-client de point-in-time waarde direct vanuit de bron. Voor deze functie wordt geen offline materialisatie ingelezen.

Overwegingen

• De vervaldatum schuift alleen op door een trigger. De onlinewaarde en de vervaldatum worden vervroegd wanneer een commit op een brontabel een verversing van de materialisatie activeert. Het verstrijken van de tijd alleen leidt niet tot een verversing. Als de bron stopt met publiceren, blijft de laatst gematerialiseerde waarde in de online winkel staan totdat een latere commit een verversing activeert.
• Lijn de tijdreekskolom af met de publicatietijd van de bron. De tijdreekskolom moet weergeven wanneer de bron de data publiceerde. Anders lopen de online- en offlinewaarden uiteen, omdat de online opslag op het triggertijdstip wordt gekoppeld, terwijl offline leesbewerkingen op het tijdstip van de tijdreeks worden gekoppeld.
• Stel de vensterduur in op een veelvoud van de publicatiecadans. Als de RollingWindow duur niet een veelvoud is van de bronpublicatiecadens, worden sommige waarden tijdens offline training als verlopen beschouwd terwijl ze nog online zichtbaar zijn.

Functies op aanvraag en materialisatie

RequestSource waarden komen uit de trainings-DataFrame of het inferenceverzoek, dus er is geen brontabel om te materialiseren. FeatureViewSource Functies passen een CustomUDF toe op upstream featurewaarden tijdens training of servering. Ze slaan geen vooraf berekend resultaat op. Materialisatie wordt ook niet ondersteund voor CustomUDF-features op basis van een Delta-tabel.

Voor een afhankelijkheidsgrafiek zoals revenue_sum_7d en cost_sum_7d die een margin kenmerk voeden:

• Voor offline training, bel create_training_set met margin. Het lost de upstream-features op en berekent point-in-time waarden, waarbij compatibele offline materialisaties worden gebruikt wanneer beschikbaar.
• Voor online servering materialiseert u de ondersteunde omzet- en kostenfuncties naar een online winkel. Het eindpunt zoekt ze op en berekent margin voor elk verzoek.
• Geef alleen de ondersteunde upstream-functies door aan materialize_features, niet aan margin of aan verzoekgestuurde functies. Materialisatie materialiseert niet recursief de afhankelijkheden van een afgeleide eigenschap.

Een grafiek die alleen op verzoeken gebaseerde functies gebruikt, heeft geen online winkel nodig. Zie Train with FeatureViewSource-functies en Serve-afgeleide functies.

Permissions

Materialisatie vereist privileges op de functie en op de bron- en bestemmingsbronnen. Voor volledige Unity Catalog privilegebeschrijvingen, zie Unity Catalog privileges referentie.

• Voor het materialiseren van een functie is vereist MANAGE. Het aanroepen materialize_features maakt en beheert de ondersteunende Lakeflow-pijplijnen en Unity Catalog-tabellen, dus het is een beheeroperatie. U moet MANAGE voor de functie hebben, samen met READ FEATURE, om de functiedefinitie die wordt gematerialiseerd te kunnen lezen.

• Alleen de maker kan een gematerialiseerde feature verwijderen. Alleen de gebruiker die een gematerialiseerde functie heeft gemaakt, kan deze verwijderen met delete_materialized_feature. Deze beperking staat los van Unity Catalog-machtigingen: MANAGE-machtigingen voor de feature of het bovenliggende schema geven een andere gebruiker niet het recht deze te verwijderen.

• Het lezen van brongegevens vereist SELECT. Voor een functie die een Delta-tabel als bron gebruikt, moet je SELECT hebben op de brontabel. Voor een functie die een Stream-bron gebruikt, moet je SELECT hebben op de innametabel van de Stream.

  Voor andere machtigingen die vereist zijn voor de authenticatieconfiguratie van een Stream, zie Kafka-authenticatie.

• Het maken van bestemmingstabellen vereist CREATE TABLE. Je moet OfflineStoreConfig hebben voor elk schema dat is opgegeven met OnlineStoreConfig of CREATE TABLE. Offline en online bestemmingen kunnen in verschillende schema's of catalogi staan, en materialisatie vereist privileges op elke bestemming.

• Materialiseren naar een onlinewinkel vereist CAN USE. Je moet CAN USE hebben op het Lakebase-exemplaar of project dat door de onlinewinkel wordt gebruikt. Voor informatie over Lakebase-toestemmingen, zie Grant project-vergunningen.

• Het weergeven van gematerialiseerde functies vereist READ FEATURE op de bovenliggende functie. Om list_materialized_features te gebruiken, moet je READ FEATURE hebben voor de functie die is gematerialiseerd.

• Voor het lezen van gematerialiseerde gegevens is SELECT vereist. Je moet beschikken over SELECT voor elke offline- of online-uitvoertabel waartoe je toegang hebt. READ FEATURE op de ouderfunctie geeft geen toegang tot deze tabellen.

Voor elke Unity Catalog-resource die bij materialisatie wordt gebruikt, heb je ook USE SCHEMA op de bovenliggende catalogus en USE CATALOG op het bovenliggende schema nodig. Deze eis geldt voor de feature, elke bron- of stream-invoertabel en elke geconfigureerde bestemming. READ FEATURE en MANAGE verleend op een schema of catalogus zijn van toepassing op alle huidige en toekomstige functies die het bevat.

API-gegevensstructuren

OfflineStoreConfig

Configuratie voor de offline opslag waar gematerialiseerde functies worden geschreven. Wanneer materialize_features wordt aangeroepen, maakt de back-end van de feature store tabellen aan met behulp van dit voorvoegsel. Elke pijplijnrun materialiseert de meest recente kenmerkwaarden naar de tabel volgens het materialisatieschema.

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

Configuratie voor de online winkel, waarin kenmerken worden opgeslagen die worden gebruikt door modelserving. Materialisatie maakt Delta-tabellen met de catalog.schema.table_name_prefixen streamt de tabellen naar de Online Feature Store met dezelfde naam.

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

Vertegenwoordigt een functieweergave die is gerealiseerd, dat wil gezegd, die een vooraf samengestelde weergave bevat die beschikbaar is in Unity Catalog. Er zijn afzonderlijke gematerialiseerde features voor de offlinetabel en de onlinetabel. Normaal gesproken instantiëren gebruikers niet rechtstreeks een MaterializedFeature.

API-functie-aanroepen

materialize_features()

Materialiseert een lijst met Feature Views naar een offline Delta-tabel of naar een Online Feature Store. Features moeten worden geregistreerd in Unity Catalog voordat u deze functie aanroept (bijvoorbeeld met create_feature of register_feature). Lokaal gebouwde functies die niet zijn geregistreerd, werken niet.

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]:

De methode retourneert een lijst met gerealiseerde functies, die metagegevens bevatten over wanneer functiewaarden worden bijgewerkt en de Unity Catalog-tabellen waar functies worden gerealiseerd.

Als er zowel een als OnlineStoreConfig een OfflineStoreConfig worden geleverd, worden er twee gerealiseerde functies geretourneerd per opgegeven functie, één voor elk type winkel.

De trigger parameter bepaalt wanneer de materialisatiepijplijn wordt uitgevoerd:

• CronSchedule: Wordt uitgevoerd volgens een schema dat is afgeleid van de timing van de functie of volgens een door de aanroeper opgegeven Quartz-cronschema. Ondersteund voor batchaggregatiefuncties (AggregationFunction van DeltaTableSource).
• TableTrigger: Wordt uitgevoerd wanneer er een commit in de upstream Delta-tabel plaatsvindt. Ondersteund voor ColumnSelection functies en aggregatiefuncties (AggregationFunction) mogelijk gemaakt door een DeltaTableSource. Voor aggregatiefeatures wordt de pipeline zo beperkt dat deze maximaal eens per halve granulariteit van de feature wordt uitgevoerd (de schuifduur van een schuivend venster, of de vensterlengte van een tuimelvenster), met een maximum van 1 uur en nooit vaker dan eens per 5 minuten. Bijvoorbeeld, hooguit eens in de 30 minuten voor een granulariteit van 1 uur, of hooguit eens per uur voor een granulariteit van 2 uur of meer. Het interval wordt gemeten vanaf de vorige run, dus een commit die na afloop arriveert, activeert nog steeds direct een run.
• StreamingMode: wordt uitgevoerd als een pijplijn voor continue streaming. Vereist voor functies die worden ondersteund door een StreamSource.

U kunt functies waarvoor verschillende triggertypen in één materialize_features aanroep zijn vereist, niet combineren. Gebruik in plaats daarvan afzonderlijke aanroepen.

Om de kosten van een materialisatie toe te wijzen, geef tags, budget_policy_id of beide op. Azure Databricks past deze toe op de job of pijplijn die het maakt, zodat de kosten ervan in de systeemtabel voor factureerbaar gebruik aan jou worden toegeschreven. Beide worden toegepast bij de creatie, dus een bestaande materialisatie anders toeschrijven betekent het creëren van een nieuwe. budget_policy_id accepteert de ID van een beleid voor serverless-gebruik. Om er een te maken en de bijbehorende ID te verkrijgen, raadpleeg Een serverless-gebruiksbeleid maken. Voor de taglimieten, de resources die elke waarde bereikt, en hoe je de geattributeerde uitgaven kunt opvragen, zie Feature Store kostenbeheer.

Materialiseren naar offlineopslag

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",
    ),
)

Materialiseren naar online winkel

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",
    ),
)

Streamingfuncties materialiseren

Streamingfuncties kunnen alleen worden gerealiseerd in online winkels; de offline_config parameter wordt niet ondersteund. Offline-materialisatie wordt niet ondersteund omdat streamingfuncties een realtime-pipeline vereisen om versheid van minder dan een seconde te garanderen. Voor offline training of evaluatie zal de feature-engineeringclient de featurewaarden voor elk geëvalueerd datapunt opnieuw berekenen.

Streamingfuncties kunnen niet worden gecombineerd met batchfuncties in dezelfde materialize_features aanroep.

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()

Retourneert de materialisaties van één functie, geïdentificeerd door de volledige naam. feature_name is vereist en kan alleen als trefwoordargument worden gebruikt. Als u de materialisaties voor veel functies wilt bekijken, moet u eerst de functies in een catalogus of schema vermelden en vervolgens elke geretourneerde functie aanroepen list_materialized_features .

Standaard worden maximaal 100 materialisaties geretourneerd. U kunt deze limiet wijzigen met behulp van de max_results parameter.

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()

Voordat u een gerealiseerde functie verwijdert, moet u alle modellen of functiespecificaties verwijderen of bijwerken die verwijzen naar de functie.

Verwijdert een gematerialiseerde functie. De functie die moet worden doorgegeven, is afhankelijk van het functietype:

• Aggregatie-eigenschappen: Geef de offline gematerialiseerde eigenschap door. Als er een online gerealiseerde functie voor dezelfde functie is, worden beide verwijderd. Voor een alleen-online batchfunctie Last met een RollingWindow, geef de online gematerialiseerde functie over.
• ColumnSelection functies: Geef de online gematerialiseerde functie door. ColumnSelection functies worden alleen gerealiseerd in de online winkel (zie ColumnSelection materialisatie), dus er is geen gekoppelde offlinefunctie.

Als onderdeel van materialisatie worden functies gegroepeerd op gegevensbron en aggregatievenster voor efficiëntie. ColumnSelection functies hebben geen aggregatievenster, dus ze worden alleen gegroepeerd op gegevensbron. De materialisatiepijplijn, offlinetabel en onlinetabel worden pas verwijderd als alle gegroepeerde functies zijn verwijderd. Wanneer de laatst gematerialiseerde feature in een groep wordt verwijderd, plant de feature store de bijbehorende resources in voor automatische opschoning door een achtergrondproces. Zie Het opschonen van achtergrondresources.

Als u gematerialiseerde functies wilt opschonen, bekijkt u de tabel die aan een dergelijke functie is gekoppeld. Elke functie in de tabel (één per kolom) moet worden verwijderd voordat reken- en Delta-tabelresources worden opgeschoond.

Gebruik list_materialized_features() om het materialized_feature argument te verkrijgen.

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)

Opschoning van achtergrondresources

Wanneer u een gerealiseerde functie verwijdert, worden de metagegevens van de functie onmiddellijk verwijderd door Databricks. De bijbehorende infrastructuur (tabellen, pijplijnen en taken) wordt asynchroon opgeschoond door een achtergrondproces.

Omdat meerdere gerealiseerde functies dezelfde tabellen en pijplijnen kunnen delen, worden deze gedeelde resources pas verwijderd nadat elke gerealiseerde functie waarnaar wordt verwezen, is verwijderd. Wanneer de laatste gematerialiseerde feature die een set tabellen deelt, wordt verwijderd, verwijdert het achtergrondproces automatisch de volgende resources:

• De offline Delta-tabellen met de gerealiseerde functiegegevens
• De onlinetabellen, als de functies zijn gerealiseerd in een online winkel
• De materialisatiepijplijn
• De orkestratietaak

In dit achtergrondproces wordt een door Databricks beheerde systeemservice-principal gebruikt om deze opschoonacties namens u uit te voeren, waaronder het verwijderen van tabellen, pijplijnen en taken in uw werkruimte. U hoeft geen actie te ondernemen. Het opschonen wordt volledig beheerd door de feature store.

Materialisatiestatus weergeven

Om de materialisatiestatus van je Feature Views in de Databricks UI te bekijken en debugfouten te debuggen, zie Feature Views verkennen in de Unity-catalogus.

Valideer de end-to-end actualiteit van RollingWindow

Deze sectie geldt alleen voor RollingWindow aggregaties. Batchfuncties stellen de hier beschreven metadata voor streamingvernieuwing niet beschikbaar.

Streaming-features RollingWindow die zijn gematerialiseerd naar een Lakebase online store bevatten metadata over versheid per rij. Met CDF leg je elke update van de online tabel vast in een Delta-geschiedenistabel in Unity Catalog en meet je de end-to-end versheid zonder een extra pipeline te draaien. End-to-end actualiteit is de vertraging tussen het moment dat een gebeurtenis plaatsvond en het moment waarop de geaggregeerde waarde beschikbaar kwam voor gebruik.

Hoe RollingWindow-functies rijen uitzenden

Voor een RollingWindow feature vat de waarde voor elke entiteit de gebeurtenissen samen binnen een vast tijdsvenster (bijvoorbeeld het aantal transacties in het afgelopen uur). Het venster schuift continu naar voren, dus er wordt in twee situaties een record naar de online store geschreven:

• Data-gedreven update (is_timer = false): een nieuw event arriveert en werkt het aggregaat bij. De rij weerspiegelt het meest recente evenement in het venster.
• Vensterverval (is_timer = true): er komt geen nieuw event binnen, maar de tijd verloopt en de oudste events vallen buiten het venster of vervallen. Omdat die events niet langer meetellen voor het totaal, verandert de waarde (bijvoorbeeld een count daalt), waardoor de functie een bijgewerkte rij op een timer stuurt. De rij weerspiegelt het moment waarop het oudste evenement uit het venster is gevallen, wat het einde van het venster van dat evenement is.

In beide gevallen is event_time het moment waarop de wijziging die de rij heeft veroorzaakt plaatsvond: een nieuw event dat arriveert, of het oudste event veroudert en wegvalt. commit_time - event_time is dus de versheid van de rij, ongeacht hoe deze is uitgezonden.

Versheidsmetadata

Elke online-streamingrij bevat de volgende kolommen:

Wanneer CDF is ingeschakeld, wordt elke wijziging toegevoegd aan een lb_<online_table>_history Delta-tabel met CDF-metadatakolommen. De _pg_change_type kolom (insert, update_preimage, update_postimage of delete) identificeert elk wijzigingstype.

Schakel CDF in op de online tabel

1. Lakebase CDF vereist dat replica-identiteit op FULL is ingesteld op elke brontabel, zodat updates worden vastgelegd met volledige voor- en na-rijafbeeldingen. Zet het op de online tabel:

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

2. Start Lakebase CDF voor de online winkel, waarbij je het bronschema en een Unity Catalog-catalogus en -schema kiest. Voor installatiedetails, zie Lakebase Change Data Feed.

CDF maakt lb_<online_table>_history aan in het bestemmingsschema.

Om het vastleggen van wijzigingen te stoppen, zie Lakebase CDF uitschakelen. Het uitschakelen van CDF stopt de feed voor alle schema's in het project. Nadat je CDF hebt uitgeschakeld, kun je de replica-identiteit van de online tabel resetten om het extra write-ahead logvolume te verwijderen:

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

Versheid berekenen

Actualiteit geldt zowel voor commit_time - event_time datagedreven rijen als rijen met vensterverval. Include is_timer zodat je de twee emit types kunt vergelijken en beperk de query tot de periode die je wilt meten.

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 is de vertraging, in milliseconden, van de tijd van het event tot de schrijfbewerking naar de online store. Dit is de actualiteit van de waarde die beschikbaar is om te serveren.

De resultaten interpreteren

• Houd zowel p50 als p99 van feature_freshness_msbij en vergelijk data-gedreven (is_timer = false) rijen met window-expiry (is_timer = true) rijen.
• Verwacht een kleine periodieke piek bij de real-time modus batchgrens (standaard 5 minuten), wanneer de pijplijn kort pauzeert om te checkpointen en te committen. Dit is meestal verwaarloosbaar bij het standaardinterval.
• Let op de zeldzame long tail (de max, voorbij p99). Het weerspiegelt de inhaalbeweging van de pijplijn in plaats van de stationaire toestand, met name na een herstart, zoals een onderhoudsherstart, wanneer de pijplijn gebufferde gebeurtenissen verwerkt. Meet de constante actualiteit over een venster dat herstarten uitsluit, en beoordeel herstartpieken apart.

Beperkingen

Batch-functies

• Batch materialisatiepijplijnen worden uitgevoerd als serverloze Lakeflow-pijplijnen.
• Rollingwindowfuncties voor batchverwerking kunnen niet worden gematerialiseerd, behalve in het speciale geval Last dat uitsluitend online is en wordt beschreven in De meest recente waarden met een freshness-begrenzing materialiseren. Voor offline training of batchgewijze inferentie worden kenmerken op basis van een schuivend venster berekend op basis van de brongegevens voor elke opzoeking op een specifiek tijdstip.
• ColumnSelection functies kunnen alleen worden gerealiseerd in online winkels.
• RequestSource, FeatureViewSource, en CustomUDF kenmerken kunnen niet worden gematerialiseerd. Zie On-demand functionaliteit en materialisatie.
• Gerealiseerde functies kunnen alleen worden verwijderd in de werkruimte waarin ze zijn gemaakt.
• Alleen de gebruiker die een gematerialiseerde functie heeft gemaakt, kan deze verwijderen, ongeacht de Unity Catalog-rechten op de functie of het ouderschema.
• Voor gerealiseerde aggregatiefuncties kan de online gerealiseerde functie niet rechtstreeks worden verwijderd. Verwijder het gekoppelde offline gematerialiseerde kenmerk, en de wijziging wordt doorgevoerd op beide elementen.
• Voor gematerialiseerde aggregatiefuncties die vóór 20 april 2026 zijn gemaakt, blijft de materialisatiepijplijn nieuwe functiewaarden produceren totdat alle gematerialiseerde functies in de pijplijn zijn verwijderd, waarna het opschonen van bronnen wordt geactiveerd. Als u een bijgewerkte pijplijn wilt maken die ondersteuning biedt voor verwijderen per functie, verwijdert en materialiseert u de functie.
• Voor gematerialiseerde ColumnSelection kenmerken blijft de materialisatiepijplijn nieuwe kenmerkwaarden produceren totdat alle gematerialiseerde kenmerken in de pijplijn zijn verwijderd, wat het opschonen van resources triggert.

Streaming-functies

• Streamingfuncties kunnen alleen worden gerealiseerd in online winkels. Offline materialisatie is niet nodig, omdat streamingfeatures tijdens de training zo zijn ontworpen dat ze per gegevenspunt opnieuw kunnen worden berekend op basis van historische gebeurtenissen, om nauwkeurigheid op millisecondenniveau te bieden.
• Streamingfuncties kunnen niet worden gecombineerd met batchfuncties in één materialize_features aanroep.
• compute_features biedt geen ondersteuning voor streamingfuncties.
• De werkruimte moet zich bevinden in een regio die Lakebase-instanties ondersteunt.
• Kafka-berichten kunnen JSON, Avro of Protobuf gebruiken. Voor schemavereisten en beperkingen van het schemaregister, zie Schemaregister.
• Alleen RollingWindow en SawtoothWindow worden ondersteund voor streamingaggregatiefuncties. TumblingWindow en SlidingWindow moet worden gebruikt met batchfuncties. Zie Tijdvensters voor streamingfuncties.
• Alleen Min, First, FirstN, LastN, Last, FirstDistinct, LastDistinct, Max, StddevPop, Sum, Avg en Count-aggregatiefuncties worden ondersteund voor streamingfuncties.
• Kolomselectiefuncties voor streamingbronnen verwerken berichten die niet op volgorde binnenkomen niet. De meest recente gebeurtenis in de Kafka-stroom wordt weergegeven, zelfs als de waarde van de tijdreekskolom eerder is dan een eerder ontvangen gebeurtenis.
• Streaming-pijplijnen worden twee keer per week opnieuw opgestart. Elke herstart kan leiden tot verwerkingsvertragingen en opstarttijden van maximaal 1 minuut. Met uitzondering van herstarts is de p99 versheid 200 ms.
• Functiebackfill voor materialisatie wordt niet ondersteund. Wanneer een functie wordt gerealiseerd, wordt deze vanaf dat punt berekend. Nieuw aangemaakte aggregaties in de webshop zijn niet nauwkeurig zolang hun tijdvenster nog niet is verstreken.
• Alleen Databricks Online Feature Store wordt ondersteund.
• Pijplijnen voor streamingmaterialisatie worden uitgevoerd als serverloze Lakeflow-pijplijnen.