Materialisera funktionsvyer

När du har skapat definitionerna för funktionsvyn, som lagras i Unity Catalog, kan du skapa funktionsdata från källtabellen med hjälp av funktionsdefinitionerna. Den här processen kallas materialisering av dina funktioner. Azure Databricks skapar och hanterar Lakeflow-pipelines för att fylla i tabeller i Unity Catalog för modellträning och batchbedömning eller onlineservering.

Mer information om servering av Feature Views finns i Serve Feature Views.

För att ta bort materialiserade värden för valda entiteter, se Rensa feature-värden för entiteter.

Kravspecifikation

• Funktioner måste skapas som funktionsvyer och lagras i Unity Catalog.
• Versionskrav finns i Krav.

Materialiseringsstöd efter funktionstyp

Om och var en egenskap kan materialiseras beror på dess typ:

• ColumnSelection funktioner kan förverkligas i onlinebutiker. Se ColumnSelection-materialisering.
• Batch-Lastfunktioner med en RollingWindow kan materialiseras i onlinelager. Se Materialize färskhetsbegränsade senaste värden.
• RequestSource, FeatureViewSource, och CustomUDF egenskaper kan inte materialiseras. Se On-demand-funktioner och materialisering.

Funktioner som endast materialiseras i onlinebutiker är fortfarande användbara offline: create_training_set och compute_features beräknar sina tidpunktsvärden direkt från källan, så ingen offline-materialisering behövs.

ColumnSelection-materialisering

ColumnSelection funktioner väljer det senaste värdet för en enskild kolumn per entitetsnyckel utan aggregering. De kan bara realiseras i onlinebutiker. För offlineanvändningsfall (träning och batchinferens) ColumnSelection hämtas funktionerna direkt från källdata vid frågetillfället, så offlinematerialisering behövs inte.

Materialiseringsbeteende

• Pipelinen skriver den senaste raden per entitetsnyckel till onlinetabellen, utan aggregeringsfönster.
• Onlinematerialisering fyller onlinetabellen med det senaste värdet per entitetsnyckel.

Exempel

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-funktioner använder TableTrigger, som kör pipelinen när källtabeln Delta tar emot en ny commit. Nej offline_config behövs eftersom ColumnSelection funktioner läss direkt från källan för offlineanvändningsfall (träning och batchinferens).

Materialisera senaste värden med färskhetsgräns

En batchaggregering Last med en RollingWindow ger en onlinefunktion en time-to-live (TTL): dess värde försvinner utanför onlinebutiken när inget källvärde faller inom fönstret. Detta är användbart när åldern på ett värde avgör om det är säkert att servera det. Till exempel kan ett enhetstillstånd från den senaste timmen serveras, medan ett äldre tillstånd upplöses till null istället för att förbli tillgängligt på obestämd tid.

A RollingWindow definierar en explicit varaktighet som ger funktionen TTL-liknande beteende. Till exempel, om källan publicerar värden dagligen och du vill behålla endast värden från de senaste sju dagarna, använd en RollingWindow med sju dagars varaktighet. Vid varje trigger gör materialiseringen en fullständig ersättning av onlinetabellen, så värden som faller utanför fönstret tas bort enligt ett förutsägbart schema. Detta ger samma resultat som en strömmande Last med en RollingWindow, men kostar mindre eftersom den inte kör beräkningar kontinuerligt.

Detta publiceringsmönster liknar en funktionstabell med en TTL som publiceras i snapshot-läge. Om du underhåller en uppsättning funktionstabeller och vill använda dem tillsammans med andra funktionsvyer kan du anpassa dem till Feature Views-författarramverket. Använd en batch Last med en RollingWindow och en TableTrigger.

Denna kombination har ett speciellt materialiseringsläge endast online med följande krav:

• Källan måste vara en DeltaTableSource.
• Aggregeringsfunktionen måste vara Last, och dess fönster måste vara en RollingWindow.
• Materialiseringen måste tillhandahålla en OnlineStoreConfig, utelämna OfflineStoreConfig och använda TableTrigger.

I följande exempel latest_device_state_1h är en registrerad funktion som uppfyller dessa krav:

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

För offline-träning och batchpoängsättning beräknar feature engineering-klienten punkt-i-tid-värdet direkt från källkoden. Den läser inte en offline-materialisering för denna funktion.

Considerations

• Utgången flyttas bara fram av en utlösare. Onlinevärdet och dess utgångstid flyttas fram när en commit i en källtabell utlöser en uppdatering av materialiseringen. Att tiden går i sig utlöser ingen uppdatering. Om källan slutar publicera stannar det sista materialiserade värdet kvar i onlinebutiken tills en senare commit triggar en uppdatering.
• Justera tidsseriekolumnen med källans publiceringstid. Tidsseriekolumnen måste återspegla när källan publicerade datan. Annars skiljer sig online- och offlinevärdena, eftersom onlinebutiken ansluter vid triggertidpunkten medan offline-läsningar ansluter vid tidsserietiden.
• Ställ in fönsterlängden till en multipel av publiceringsfrekvensen. Om varaktigheten RollingWindow inte är en multipel av källpubliceringsfrekvensen behandlas vissa värden som utgångna under offline-träning medan de fortfarande är synliga online.

Funktioner på begäran och materialisering

RequestSource värdena kommer från träningsdataframes eller inferensförfrågan, så det finns ingen källtabell att materialisera. FeatureViewSource funktioner tillämpar ett CustomUDF på värden för uppströmsfunktioner vid träning eller servering. De lagrar inte ett förberäknat resultat. Materialisering stöds inte heller för CustomUDF funktioner som stöds av en Delta-tabell.

För en beroendegraf som revenue_sum_7d och cost_sum_7d matar en margin funktion:

• För offlineutbildning, anropa create_training_set med margin. Den löser upp uppströmsfunktionerna och beräknar tidpunktsvärden, med hjälp av kompatibla offline-materialiseringar när de är tillgängliga.
• För onlinetjänster, materialisera de stödda intäkterna och kostnadsfunktionerna i en nätbutik. Endpointen slår upp dem och beräknar margin för varje förfrågan.
• Skicka endast de upstream-funktioner som stöds till materialize_features, inte margin eller några förfrågningsbaserade funktioner. Materialisering materialiserar inte rekursivt beroenden för en härledd egenskap.

En graf som endast använder funktioner som baseras på förfrågningar behöver inte något onlinelager. Se Träna med funktioner från FeatureViewSource och Servera härledda funktioner.

behörigheter

Materialisering kräver privilegier på funktionen samt på käll- och destinationsresurserna. För fullständiga Unity Catalog-privilegiebeskrivningar, se referensen för Unity-katalogens privilegier.

• Materialisering av en funktion kräver MANAGE. Att anropa materialize_features skapar och hanterar de underliggande Lakeflow-pipelines och Unity Catalog-tabellerna, så det är en administrativ åtgärd. Du måste ha MANAGE på funktionen, tillsammans med READ FEATURE för att läsa funktionsdefinitionen som materialiseras.

• Att ta bort en materialiserad funktion är begränsad till dess skapare. Endast användaren som skapade en materialiserad funktion kan ta bort den med delete_materialized_feature. Denna begränsning är oberoende av Unity Catalog-privilegier: MANAGE på funktionen eller dess föräldraschema tillåter inte en annan användare att ta bort den.

• Att läsa källdata kräver SELECT. För en funktion som använder en Delta-tabellkälla måste du ha SELECT på källtabellen. För en funktion som använder en Stream-källa måste du ha SELECT på Streamens intagningstabell.

  För andra behörigheter som krävs av en ströms autentiseringskonfiguration, se Kafka-autentisering.

• Att skapa destinationstabeller kräver CREATE TABLE. Du måste ha CREATE TABLE på varje schema specificerat av OfflineStoreConfig eller OnlineStoreConfig. Offline- och onlinedestinationer kan finnas i olika scheman eller kataloger, och materialisering kräver privilegier på varje destination.

• Att publicera i en nätbutik kräver CAN USE. Du måste ha CAN USE på Lakebase-instansen eller i projektet som används av onlinebutiken. För information om Lakebase-tillstånd, se Grant project permissions.

• Att lista materialiserade funktioner kräver READ FEATURE på föräldrafunktionen. För att använda list_materialized_features, måste du ha READ FEATURE på den funktion som materialiserades.

• Läsning av materialiserade data kräver SELECT. Du måste ha SELECT på varje offline- eller online-utdatatabell som du får tillgång till. READ FEATURE på moderfunktionen ger inte åtkomst till dessa tabeller.

För varje Unity Catalog-resurs som ingår i materialiseringen behöver du också USE CATALOG för dess överordnade katalog och USE SCHEMA för dess överordnade schema. Detta krav gäller för funktionen, varje käll- eller strömintagningstabell och varje konfigurerad destination. READ FEATURE och MANAGE som beviljas för ett schema eller en katalog gäller alla nuvarande och framtida objekt som det innehåller.

API-datastrukturer

OfflineStoreConfig

Konfiguration för offline-lagret där materialiserade funktioner skrivs in. När materialize_features anropas skapar funktionsarkivets serverdel tabeller med det här prefixet. Varje pipelinekörning materialiserar de senaste egenskapsvärdena i tabellen enligt schema för materialisering.

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

Konfiguration för onlinebutiken, som lagrar funktioner som används av modellservern. Materialisering skapar Delta-tabeller med catalog.schema.table_name_prefix, och strömmar tabellerna till Online Feature Store med samma namn.

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

Representerar en funktionsvy som har materialiserats, d.v.s. en förberäknad representation som är tillgänglig i Unity Catalog. Det finns separata materialiserade funktioner för offlinetabellen och onlinetabellen. Vanligtvis instansierar användarna inte en MaterializedFeature direkt.

API-funktionsanrop

materialize_features()

Materialiserar en lista över funktionsvyer i antingen en deltatabell offline eller till en onlinefunktionsbutik. Egenskaper måste registreras i Unity Catalog innan den här funktionen anropas (till exempel med create_feature eller register_feature). Lokalt konstruerade funktioner som inte har registrerats fungerar inte.

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

Metoden returnerar en lista över materialiserade funktioner som innehåller metadata om när funktionsvärden uppdateras och Unity Catalog-tabellerna där funktionerna materialiseras.

Om både en OnlineStoreConfig och en OfflineStoreConfig tillhandahålls returneras två materialiserade funktioner per tillhandahållen funktion, en för varje typ av butik.

Parametern trigger styr när materialiseringspipelinen körs:

• CronSchedule: Körs enligt ett schema som härleds från funktionens tidsinställning eller enligt ett Quartz-cronschema som tillhandahålls av anroparen. Stöds för batchaggregeringsfunktioner (AggregationFunction från DeltaTableSource).
• TableTrigger: Körs när den uppströms Delta-tabellen tar emot en commit. Stöd för ColumnSelection funktioner och aggregeringsfunktioner (AggregationFunction) som stöds av en DeltaTableSource. För aggregationsfunktioner stryps pipelinen till att köras högst en gång per halva detaljnivån (slide-tiden för ett glidande fönster eller fönsterlängden för ett tumbling-fönster), med en gräns på 1 timme och aldrig oftare än var femte minut. Till exempel högst en gång var 30:e minut för en detaljnivå på 1 timme, eller högst en gång i timmen för en granularitet på 2 timmar eller mer. Intervallet mäts från den föregående körningen, så en incheckning som kommer in efter att intervallet har löpt ut utlöser ändå snabbt en körning.
• StreamingMode: Körs som en pipeline för kontinuerlig direktuppspelning. Krävs för funktioner som backas upp av en StreamSource.

Du kan inte blanda funktioner som kräver olika utlösartyper i ett enda materialize_features anrop. Utfärda separata anrop i stället.

För att attribuera kostnaden för en materialisering anger du tags, budget_policy_id eller båda. Azure Databricks tillämpar dem på det jobb eller den pipeline som det skapar, så att dess användning får med din attribueringsinformation i systemtabellen för debiterbar användning. Båda tillämpas vid skapandet, så att tillskriva en befintlig materialisering på olika sätt innebär att skapa en ny. budget_policy_id tar ID:t för en serverless användningspolicy. För att skapa en och få dess ID, se Skapa en serverlös användningspolicy. För tagggränser, vilka resurser varje värde når och hur man frågar efter den attributerade kostnaden, se Feature Store kostnadshantering.

Materialisera till offlinebutik

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

Materialisera till onlinebutik

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

Materialisera strömningsfunktioner

Direktuppspelningsfunktioner kan bara materialiseras till onlinebutiker. parametern offline_config stöds inte. Offline-materialisering stöds inte eftersom streamingfunktioner kräver en realtidspipeline för att säkerställa uppdatering inom mindre än en sekund. För offlineträning eller utvärdering beräknar funktionsteknikerklienten om funktionsvärdena baserat på varje utvärderad datapunkt.

Direktuppspelningsfunktioner kan inte blandas med batchfunktioner i samma materialize_features anrop.

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

Returnerar materialiseringarna för en enskild funktion som identifieras med dess fullständiga namn. feature_name är obligatorisk och kan endast anges som nyckelordsargument. Om du vill granska materialiseringarna i många funktioner anger du först funktionerna i en katalog eller ett schema och anropar list_materialized_features sedan varje funktion som returneras.

Som standard returneras högst 100 materialiseringar. Du kan ändra den här gränsen med hjälp av parametern max_results .

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

Innan du tar bort en materialiserad funktion tar du bort eller uppdaterar modeller eller funktionsspecifikationer som refererar till funktionen.

Tar bort en materialiserad funktion. Vilken funktion som ska skickas beror på funktionstypen:

• Sammansättningsfunktioner: Skicka den materialiserade offlinefunktionen. Om det finns en materialiserad onlinefunktion för samma funktion tas båda bort. För en batchfeature Last som endast är online med en RollingWindow, ange det online-materialiserade featuret.
• ColumnSelection funktioner: Överför den materialiserade funktionen online. ColumnSelection funktioner materialiseras endast i onlinebutiken (se ColumnSelection-materialisering), så det finns ingen motsvarande offlinefunktion.

Som en del av materialiseringen grupperas funktionerna efter datakälla och aggregeringsfönster för effektivitet. ColumnSelection funktioner har inget aggregeringsfönster, så de grupperas endast efter datakälla. Materialiseringspipelinen, offlinetabellen och onlinetabellen tas inte bort förrän alla grupperade funktioner har tagits bort. När den senaste materialiserade funktionen i en grupp tas bort schemalägger funktionsarkivet de associerade resurserna för automatisk rensning av en bakgrundsprocess. Se Rensning av bakgrundsresurser.

Om du vill rensa materialiserade funktioner kan du titta på tabellen som är associerad med en materialiserad funktion. Varje funktion i tabellen (en per kolumn) måste tas bort innan beräknings- och Delta-tabellresurser rensas.

Använd list_materialized_features() för att hämta materialized_feature argumentet.

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)

Rensning av bakgrundsresurser

När du tar bort en materialiserad funktion tar Databricks bort funktionsmetadata omedelbart. Den tillhörande infrastrukturen (tabeller, pipelines och jobb) rensas asynkront av en bakgrundsprocess.

Eftersom flera materialiserade funktioner kan dela samma tabeller och pipelines tas inte dessa delade resurser bort förrän alla materialiserade funktioner som refererar till dem har tagits bort. När den senaste materialiserade funktionen som delar en uppsättning tabeller tas bort tar bakgrundsprocessen automatiskt bort följande resurser:

• Delta-offlinetabellerna som innehåller materialiserade funktionsdata
• Onlinetabellerna, om funktionerna materialiserades till en onlinebutik
• Materialiseringspipelinen
• Orkestreringsjobbet

Den här bakgrundsprocessen använder ett systemtjänsthuvudnamn som hanteras av Databricks för att utföra dessa rensningsåtgärder åt dig, bland annat genom att ta bort tabeller, pipelines och jobb i arbetsytan. Ingen åtgärd krävs från din sida. Rensningen hanteras fullständigt av feature store.

Visa materialiseringsstatus

För att se materialiseringsstatusen för dina Feature Views i Databricks UI och felsöka materialiseringsfel, se Utforska Feature Views i Unity-katalogen.

Begränsningar

Batch-funktioner

• Pipelines för materialisering i batch körs som serverlösa Lakeflow-pipelines.
• Funktioner för rullande batchfönster kan inte materialiseras, förutom i det särskilda fallet som endast gäller online och som beskrivs i Materialisera senaste värden med friskhetsgränsLast. För offline-träning eller batchinferens beräknas funktioner baserade på glidande fönster från källdata för varje uppslagning vid en viss tidpunkt.
• ColumnSelection funktioner kan endast göras tillgängliga för onlinebutiker.
• RequestSource, FeatureViewSource, och CustomUDF egenskaper kan inte materialiseras. Se On-demand-funktioner och materialisering.
• Materialiserade funktioner kan bara tas bort på arbetsytan där de skapades.
• Endast användaren som skapade en materialiserad funktion kan ta bort den, oavsett Unity Catalog-rättigheter för funktionen eller dess föräldraschema.
• För materialiserade aggregeringsfunktioner kan den materialiserade onlinefunktionen inte tas bort direkt. Ta bort den kopplade offlinematerialiserade funktionen och ändringen sprids till båda.
• För materialiserade aggregeringsfunktioner som skapades före den 20 april 2026 fortsätter materialiseringspipelinen att producera nya funktionsvärden tills alla materialiserade funktioner i pipelinen har tagits bort, vilket utlöser resursrensning. Om du vill skapa en uppdaterad pipeline som stöder borttagning per funktion tar du bort och materialiserar funktionen igen.
• För materialiserade ColumnSelection funktioner fortsätter materialiseringspipelinen att producera nya funktionsvärden tills alla materialiserade funktioner i pipelinen har tagits bort, vilket utlöser resursrensning.

Direktuppspelningsfunktioner

• Direktuppspelningsfunktioner kan bara materialiseras till onlinebutiker. Offlinematerialisering behövs inte eftersom strömningsfunktioner vid träningstillfället är utformade för att omberäknas från historiska händelser per datapunkt för att ge noggrannhet på millisekundersnivå.
• Strömningsfunktioner kan inte blandas med batchfunktioner i ett enda materialize_features anrop.
• compute_features stöder inte direktuppspelningsfunktioner.
• Arbetsytan måste finnas i en region som stöder Lakebase-instanser.
• Endast JSON-serialiserade Kafka-meddelanden stöds. Meddelandescheman måste anges direkt i JSON-schemaformat. Schemaregister (Confluent, Glue) stöds inte formellt under förhandsversionen, men om du anger schemat direkt kan pipelines läsa från ämnen som styrs av ett schemaregister.
• Endast RollingWindow stöds för strömningsaggregeringsfunktioner. TumblingWindow och SlidingWindow bör användas med batchfunktioner.
• Endast Count, Avg, Sum, StddevPop, Max, Min, First, LastNFirstDistinctLastFirstN, och LastDistinct aggregeringsfunktioner stöds för strömningsfunktioner.
• Kolumnvalsfunktioner från strömmande källor hanterar inte meddelanden som inte är i ordning. Den senaste händelsen på Kafka-strömmen visas, även om kolumnvärdet för tidsserier är tidigare än en tidigare mottagen händelse.
• Streamningspipelines startas om två gånger i veckan. Varje omstart kan orsaka bearbetningsfördröjningar och starttider på upp till 1 minut. Förutom omstarter är p99-färskheten 200 ms.
• Funktionsbakfyllnad för materialisering stöds inte. När en funktion materialiseras beräknas den från den punkten framåt. Nyligen skapade aggregeringar i webbutiken är inte korrekta förrän deras tidsfönster har passerat.
• Endast Databricks Online Feature Store stöds.
• Pipelines för strömmande materialisering körs som serverlösa Lakeflow-pipelines.
• Endast arbetsytor på Enterprise-nivå.