Vistas de Funcionalidade do Materialize

Depois de criar as suas definições da Feature View, que são armazenadas no Unity Catalog, pode produzir dados de características a partir da sua tabela de origem usando as definições de características. Este processo chama-se materializar as suas características. O Azure Databricks cria e gere pipelines Lakeflow para preencher tabelas no Unity Catalog para treino de modelos e pontuação em lote ou serviço online.

Para informações sobre como servir Visualizações de Funcionalidade, consulte Servir Visualizações de Funcionalidades.

Para remover valores materializados para entidades selecionadas, veja Purgar valores de funcionalidades para entidades.

Requerimentos

• As funcionalidades devem ser criadas como Vistas de Funcionalidades e armazenadas no Catálogo Unity.
• Para requisitos de versão, consulte Requisitos.

Suporte à materialização por tipo de característica

Se e onde uma característica pode ser materializada depende do seu tipo:

• ColumnSelection funcionalidades podem ser materializadas em lojas online. Consulte Materialização de Seleção de Coluna.
• As funcionalidades em lote Last com um RollingWindow podem ser materializadas em lojas online. Veja Materialize os valores mais recentes com limite de atualização.
• As características RequestSource, FeatureViewSource e CustomUDF não podem ser materializadas. Ver funcionalidades a pedido e materialização.

Funcionalidades que só se materializam em lojas online continuam a ser utilizáveis offline: create_training_set e compute_features calculam os seus valores no momento diretamente da fonte, pelo que não é necessária materialização offline.

Materialização da Seleção da Coluna

ColumnSelection As funcionalidades selecionam o valor mais recente de uma única coluna por chave de entidade sem agregação. Só podem ser materializadas em lojas online. Para casos de uso offline (treino e inferência em lote), ColumnSelection as funcionalidades são obtidas diretamente dos dados de origem no momento da consulta, pelo que a materialização offline não é necessária.

Comportamento de materialização

• O pipeline escreve, por chave de entidade, a linha mais recente na tabela online, sem janela de agregação.
• A materialização online preenche a tabela online com o valor mais recente e atual por chave de entidade.

Exemplo

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 as funcionalidades usam TableTrigger, que executa o pipeline sempre que a tabela Delta de origem recebe um novo commit. offline_config não é necessário porque as características ColumnSelection são lidas diretamente da fonte para casos de uso offline (treino e inferência em lote).

Materializar os valores mais recentes limitados pela frescura

Uma agregação em lote Last com a RollingWindow atribui a um atributo online um tempo de vida (TTL): o seu valor expira do armazenamento online quando nenhum valor de origem se enquadra na janela. Isto é útil quando a idade de um valor determina se é seguro servir. Por exemplo, um estado de dispositivo da última hora pode ser servido, enquanto um estado mais antigo resolve para nulo em vez de permanecer disponível indefinidamente.

A RollingWindow define uma duração explícita que confere à característica um comportamento semelhante ao TTL. Por exemplo, se a fonte publicar valores diariamente e quiser manter apenas os valores dos últimos sete dias, use a RollingWindow com duração de sete dias. A cada acionamento, a materialização efetua uma substituição completa da tabela online, pelo que os valores que ficam fora da janela são removidos de acordo com uma programação previsível. Isto produz o mesmo resultado que um streaming Last com um RollingWindow, mas custa menos porque não executa computação contínua.

Este padrão de publicação é semelhante a uma tabela de características com um TTL que é publicada em modo snapshot. Se mantiver um conjunto de tabelas de características e quiser usá-las juntamente com outras Feature Views, pode adaptá-las ao framework de autoria das Feature Views. Utilize um lote Last com um RollingWindow e um TableTrigger.

Esta combinação tem um modo especial de materialização exclusivamente online com os seguintes requisitos:

• A fonte deve ser um DeltaTableSource.
• A função de agregação deve ser Last, e a sua janela deve ser RollingWindow.
• A materialização deve fornecer OnlineStoreConfig, omitir OfflineStoreConfig e usar TableTrigger.

No exemplo seguinte, latest_device_state_1h está uma Funcionalidade registada que cumpre estes requisitos:

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

Para treino fora de linha e avaliação em lote, o cliente de engenharia de atributos calcula diretamente na origem o valor num determinado momento temporal. Não lê uma materialização em modo offline para esta funcionalidade.

Considerations

• A expiração só avança mediante acionamento. O valor online e a respetiva expiração são antecipados quando um commit da tabela de origem desencadeia uma atualização da materialização. O passar do tempo por si só não desencadeia uma atualização. Se a fonte deixar de publicar, o último valor materializado permanece na loja online até que um commit posterior desencadeie uma atualização.
• Alinhe a coluna da série temporal com a hora de publicação da fonte. A coluna da série temporal deve refletir quando a fonte publicou os dados. Caso contrário, os valores online e offline divergem, porque a loja online junta-se no momento de ativação, enquanto as leituras offline juntam-se no tempo da série temporal.
• Defina a duração da janela para múltiplo da cadência de publicação. Se a duração de RollingWindow não for um múltiplo da cadência de publicação de origem, alguns valores são tratados como expirados durante o treino em modo offline, embora ainda estejam visíveis online.

Funcionalidades e materialização a pedido

RequestSource os valores provêm do DataFrame de treino ou do pedido de inferência, pelo que não existe nenhuma tabela de origem a materializar. FeatureViewSource As funcionalidades aplicam uma CustomUDF aos valores das funcionalidades de origem durante o treino ou a disponibilização. Não armazenam um resultado pré-computado. A materialização também não é suportada para funcionalidades CustomUDF baseadas numa tabela Delta.

Para um grafo de dependência como revenue_sum_7d e cost_sum_7d que alimenta uma margin característica:

• Para formação offline, chame create_training_set com margin. Resolve as funcionalidades a montante e calcula valores num determinado momento, recorrendo a materializações offline compatíveis quando disponíveis.
• Para o serviço online, integre os recursos de receita e custo suportados numa loja online. O endpoint consulta-os e calcula margin para cada solicitação.
• Passe apenas as funcionalidades upstream suportadas para materialize_features, não margin ou quaisquer funcionalidades suportadas por pedidos. A materialização não materializa recursivamente as dependências de uma característica derivada.

Um grafo que utiliza apenas funcionalidades suportadas por pedidos não precisa de uma loja online. Veja Treinar com funcionalidades de FeatureViewSource e Servir funcionalidades derivadas.

Permissions

A materialização requer privilégios sobre a funcionalidade e sobre os recursos de origem e destino. Para descrições completas dos privilégios do Unity Catalog, consulte a referência de privilégios do Unity Catalog.

• Materializar uma característica requer MANAGE. Chamar materialize_features cria e gere os pipelines Lakeflow subjacentes e as tabelas do Unity Catalog, pelo que é uma operação de gestão. Tem de ter MANAGE na funcionalidade, bem como READ FEATURE para ler a definição da funcionalidade que está a ser materializada.

• Eliminar uma funcionalidade materializada está restrito ao seu criador. Só o utilizador que criou uma funcionalidade materializada pode eliminá-la com delete_materialized_feature. Esta restrição é independente dos privilégios do Unity Catalog: MANAGE na funcionalidade ou no respetivo esquema principal não permite a outro utilizador eliminá-la.

• A leitura de dados de origem requer SELECT. Para uma funcionalidade que utiliza uma fonte de tabela Delta, é necessário ter SELECT na tabela de origem. Para uma funcionalidade que utiliza uma origem Stream, tem de ter SELECT na tabela de ingestão do Stream.

  Para outras permissões exigidas pela configuração de autenticação de um Stream, veja autenticação Kafka.

• Criar tabelas de destino requer CREATE TABLE. Tem de ter CREATE TABLE em todos os esquemas especificados em OfflineStoreConfig ou OnlineStoreConfig. Destinos offline e online podem estar em esquemas ou catálogos diferentes, e a materialização requer privilégios em cada destino.

• A materialização numa loja online requer CAN USE. Deve ter CAN USE na instância ou projeto Lakebase usado pela loja online. Para informações sobre permissões Lakebase, consulte Conceder permissões de projeto.

• A listagem de funcionalidades materializadas requer READ FEATURE na funcionalidade principal. Para usar list_materialized_features, deve ter READ FEATURE na funcionalidade que foi materializada.

• A leitura de dados materializados requer SELECT. Deve ter SELECT em cada tabela de saída offline ou online a que acede. READ FEATURE na funcionalidade principal não concede acesso a estas tabelas.

Para cada recurso do Catálogo Unity envolvido na materialização, também é necessário ter USE CATALOG no seu catálogo pai e USE SCHEMA no seu esquema pai. Este requisito aplica-se à funcionalidade, a cada fonte ou tabela de ingestão do Stream, e a cada destino configurado. READ FEATURE e MANAGE concedidos num esquema ou catálogo aplicam-se a todos os objetos atuais e futuros que este contém.

Estruturas de dados API

OfflineStoreConfig

Configuração para a loja offline onde as funcionalidades materializadas serão escritas. Quando materialize_features é chamado, o backend da feature store cria tabelas usando este prefixo. Cada execução de pipeline materializa os valores mais recentes das funcionalidades na tabela de acordo com o calendário de materialização.

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

Configuração para a loja online, que armazena as funcionalidades usadas pelo modelo que serve. A Materialization cria tabelas Delta com o catalog.schema.table_name_prefix, e transmite as tabelas para a Online Feature Store com o mesmo nome.

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

Representa uma Feature View que foi materializada, ou seja, que tem uma representação pré-computada disponível no Unity Catalog. Existem funcionalidades materializadas separadas para a mesa offline e a mesa online. Normalmente, os utilizadores não instanciam um MaterializedFeature direto.

Chamadas de função API

materialize_features()

Materializa uma lista de Feature Views numa tabela Delta offline ou numa Feature Store online. As funcionalidades devem ser registadas no Catálogo Unity antes de chamar esta função (por exemplo, usando create_feature ou register_feature). Características construídas localmente que não foram registadas não funcionam.

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

O método devolve uma lista de funcionalidades materializadas, que contêm metadados sobre quando os valores das funcionalidades são atualizados e as tabelas do Catálogo Unity onde as funcionalidades são materializadas.

Se forem fornecidas tanto uma OnlineStoreConfig como uma OfflineStoreConfig, então duas características materializadas são devolvidas por cada funcionalidade fornecida, uma para cada tipo de armazém.

O trigger parâmetro controla quando o pipeline de materialização é executado:

• CronSchedule: É executado de acordo com um agendamento derivado da temporização da funcionalidade ou de um agendamento cron do Quartz fornecido pelo chamador. Suportado para funcionalidades de agregação em lote (AggregationFunction de DeltaTableSource).
• TableTrigger: Executa-se quando a tabela Delta a montante recebe um commit. Compatível com funcionalidades do ColumnSelection e de agregação (AggregationFunction) suportadas por um DeltaTableSource. Para funcionalidades de agregação, o pipeline é limitado para funcionar no máximo uma vez a cada metade da granularidade da funcionalidade (a duração do deslizamento para uma janela deslizante, ou o comprimento da janela para uma janela de rotação), limitado a 1 hora e nunca mais frequentemente do que a cada 5 minutos. Por exemplo, no máximo uma vez a cada 30 minutos para uma granularidade de 1 hora, ou no máximo uma vez por hora para uma granularidade de 2 horas ou mais. O intervalo é medido a partir da execução anterior, pelo que um commit que chegue depois de o intervalo decorrer desencadeia ainda assim uma execução de imediato.
• StreamingMode: Funciona como uma canalização de fluxo contínuo. Obrigatório para funcionalidades suportadas por um StreamSource.

Não podes misturar funcionalidades que exigem diferentes tipos de gatilhos numa única materialize_features chamada. Em vez disso, emita chamadas separadas.

Para atribuir o custo de uma materialização, passe tags, budget_policy_id, ou ambos. O Azure Databricks aplica-os à tarefa ou ao pipeline que cria, pelo que o respetivo custo inclui a sua atribuição na tabela do sistema de utilização faturável. Ambos são aplicados na criação, por isso atribuir uma materialização existente de forma diferente significa criar uma nova. budget_policy_id aceita o ID de uma política de utilização sem servidor. Para criar uma e obter o respetivo ID, consulte Criar uma política de utilização serverless. Para os limites de etiquetas, os recursos que cada valor atinge e como consultar o gasto atribuído, veja Gestão de custos da Feature Store.

Materializar para a loja offline

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

Materialize na loja online

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

Funcionalidades de streaming do Materialize

As funcionalidades de streaming só podem ser materializadas para lojas online; O offline_config parâmetro não é suportado. A materialização em modo offline não é suportada porque as funcionalidades de streaming requerem um pipeline em tempo real para garantir uma atualização inferior a um segundo. Para treino ou avaliação offline, o cliente de engenharia de funcionalidades irá recalcular os valores das funcionalidades com base em cada ponto de dados avaliado.

Funcionalidades de streaming não podem ser misturadas com funcionalidades em lote na mesma materialize_features chamada.

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

Devolve as materializações de uma única característica, identificada pelo seu nome completo. feature_name é obrigatório e apenas com palavras-chave. Para consultar as materializações em vários atributos, primeiro liste os atributos num catálogo ou num esquema e, em seguida, invoque list_materialized_features em cada atributo devolvido.

Por predefinição, são devolvidas no máximo 100 materializações. Pode alterar este limite usando o max_results parâmetro.

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

Antes de eliminar uma funcionalidade materializada, remova ou atualize quaisquer modelos ou especificações de funcionalidades que façam referência a essa funcionalidade.

Apaga uma funcionalidade materializada. A funcionalidade a passar depende do tipo de característica:

• Funcionalidades de agregação: Passe a funcionalidade materializada offline. Se existir uma funcionalidade online materializada para a mesma funcionalidade, ambas são eliminadas. Para uma funcionalidade em lote Last exclusivamente online com um RollingWindow, forneça a funcionalidade materializada online.
• ColumnSelection funcionalidades: Forneça a funcionalidade materializada online. ColumnSelection as funcionalidades são materializadas apenas na loja online (ver materialização de ColumnSelection), portanto, não existe uma funcionalidade correspondente offline.

Como parte da materialização, as funcionalidades são agrupadas por fonte de dados e janela de agregação para maior eficiência. ColumnSelection As funcionalidades não têm janela de agregação, pelo que são agrupadas apenas por fonte de dados. O pipeline de materialização, a tabela offline e a tabela online não são eliminados até que todas as funcionalidades agrupadas tenham sido eliminadas. Quando a última funcionalidade materializada num grupo é eliminada, o armazenamento de funcionalidades agenda os recursos associados para limpeza automática por um processo em segundo plano. Ver Limpeza de recursos de antecedentes.

Para limpar as características materializadas, veja a tabela associada a uma característica materializada. Cada característica da tabela (uma por coluna) deve ser eliminada antes de os recursos de computação e tabela Delta serem limpos.

Usa list_materialized_features() para perceber o materialized_feature argumento.

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)

Limpeza de recursos em segundo plano

Quando elimina uma funcionalidade materializada, o Databricks remove imediatamente os metadados da funcionalidade. A infraestrutura associada (tabelas, pipelines e tarefas) é limpa de forma assíncrona por um processo em segundo plano.

Como múltiplas funcionalidades materializadas podem partilhar as mesmas tabelas e pipelines, estes recursos partilhados não são removidos até que todas as funcionalidades materializadas que as referenciam tenham sido eliminadas. Quando a última funcionalidade materializada que partilha um conjunto de tabelas é eliminada, o processo em segundo plano elimina automaticamente os seguintes recursos:

• As tabelas Delta offline que contêm os dados de funcionalidades materializadas
• As tabelas online, se as funcionalidades fossem materializadas numa loja online
• A canalização de materialização
• O trabalho de orquestração

Este processo em segundo plano utiliza um principal de serviço de sistema gerido pela Databricks para realizar estas ações de limpeza em seu nome, incluindo a eliminação de tabelas, pipelines e trabalhos no seu espaço de trabalho. Não é necessária qualquer ação da tua parte. A limpeza é totalmente gerida pela feature store.

Ver estado de materialização

Para ver o estado de materialização das suas Vistas de Funcionalidades na IU do Databricks e depurar erros de materialização, consulte Explorar Vistas de Funcionalidades no Unity Catalog.

Limitações

Funcionalidades em lote

• Os pipelines de materialização por lote são executados como pipelines Lakeflow sem servidor.
• As funcionalidades de janela deslizante em lote não podem ser materializadas, exceto no caso especial exclusivamente online Last descrito em Materializar os valores mais recentes limitados pela atualização. Para treino offline ou inferência em lote, as funcionalidades da janela rolante são calculadas a partir dos dados de origem para cada pesquisa em um ponto no tempo.
• ColumnSelection As funcionalidades só podem ser materializadas em lojas online.
• As características RequestSource, FeatureViewSource e CustomUDF não podem ser materializadas. Ver funcionalidades a pedido e materialização.
• As funcionalidades materializadas só podem ser eliminadas no espaço de trabalho onde foram criadas.
• Só o utilizador que criou uma funcionalidade materializada pode eliminá-la, independentemente dos privilégios do Catálogo Unity sobre a funcionalidade ou o seu esquema pai.
• Para funcionalidades de agregação materializada, a funcionalidade materializada online não pode ser eliminada diretamente. Elimine a funcionalidade de materialização offline emparelhada e a alteração propaga-se para ambos.
• Para funcionalidades de agregação materializadas criadas antes de 20 de abril de 2026, o pipeline de materialização continua a produzir novos valores de funcionalidades até que todas as funcionalidades materializadas no pipeline sejam eliminadas, o que desencadeia a limpeza de recursos. Criar um pipeline atualizado que suporte a eliminação por característica, eliminação e reconstrução da funcionalidade.
• Para as características materializadas ColumnSelection, o pipeline de materialização continua a produzir novos valores de características até que todas as características materializadas no âmbito do pipeline sejam eliminadas, o que desencadeia a limpeza dos recursos.

Funcionalidades de streaming

• As funcionalidades de streaming só podem ser materializadas em lojas online. A materialização offline não é necessária porque as funcionalidades de streaming durante o treino são concebidas para serem recalculadas a partir de eventos históricos por ponto de dados, de modo a proporcionar precisão ao nível de milissegundos.
• Funcionalidades de streaming não podem ser misturadas com funcionalidades em lote numa única materialize_features chamada.
• compute_features não suporta funcionalidades de streaming.
• O espaço de trabalho deve estar numa região que suporte instâncias Lakebase.
• Apenas mensagens Kafka serializadas em JSON são suportadas. Os esquemas de mensagens devem ser fornecidos diretamente em formato de esquema JSON. Os registos de esquemas (Confluent, Glue) não são oficialmente suportados durante a versão preliminar, mas, se fornecer o esquema diretamente, os pipelines podem ler a partir de tópicos geridos por um registo de esquemas.
• Apenas RollingWindow é suportado para funcionalidades de agregação de streaming. TumblingWindow e SlidingWindow deve ser usado com funcionalidades em lote.
• Apenas as funções de agregação Count, Avg, Sum, StddevPop, LastN, Last, Max, First, FirstN, Min, FirstDistinct e LastDistinct são suportadas para funcionalidades de streaming.
• As funcionalidades de seleção de colunas provenientes de fontes de streaming não tratam mensagens fora de ordem. O evento mais recente no stream de Kafka é mostrado, mesmo que o valor da coluna da série temporal seja anterior ao de um evento previamente recebido.
• Os fluxos de processamento em streaming são reiniciados duas vezes por semana. Cada reinício pode causar atrasos no processamento e tempos de arranque de até 1 minuto. Excluindo os reinícios, a atualização no p99 é de 200 ms.
• O retropreenchimento da funcionalidade para a materialização não é suportado. Quando uma característica é materializada, calcula a partir desse ponto em diante. As agregações recém-criadas na loja online são imprecisas até que o seu período de tempo tenha passado.
• Apenas a Databricks Online Feature Store é suportada.
• Os pipelines de materialização em streaming são executados como pipelines Lakeflow serverless.
• Apenas espaços de trabalho de nível empresarial.