Materializar exibições de recursos

Depois de criar suas definições da Feature View, que ficam armazenadas no Unity Catalog, você pode gerar dados de atributos a partir da tabela de origem usando essas definições. Esse processo é chamado de materialização de seus recursos. O Azure Databricks cria e gerencia pipelines do Lakeflow a fim de preencher tabelas no Unity Catalog para treinamento de modelo e pontuação de lote ou serviço online.

Para informações sobre como disponibilizar Feature Views, consulte Disponibilizar Feature Views.

Para remover valores materializados para entidades selecionadas, veja Eliminar valores de recursos para entidades.

Requirements

• Os recursos devem ser criados como Exibições de Recursos e armazenados no Catálogo do Unity.
• Para obter 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:

• Recursos do ColumnSelection podem ser materializadas para armazenamentos virtuais. Consulte Materialização ColumnSelection.
• Os recursos em lote Last com um RollingWindow podem ser materializados em armazenamentos online. Veja Materialize valores mais recentes com limite de atualidade.
• Os recursos RequestSource, FeatureViewSource e CustomUDF não podem ser materializados. Veja Recursos sob demanda e materialização.

Os recursos que se materializam apenas em armazenamentos online ainda podem ser usados offline: create_training_set e compute_features calculam seus valores pontuais diretamente da fonte, portanto, nenhuma materialização offline é necessária.

Materialização ColumnSelection

Os recursos ColumnSelection selecionam o valor mais recente de uma única coluna para cada chave de entidade sem realizar agregação. Eles só podem ser implementados em armazenamentos online. Para casos de uso offline (treinamento e inferência em lote), ColumnSelection os recursos são buscados diretamente dos dados de origem no momento da consulta, portanto, a materialização offline não é necessária.

Comportamento de materialização

• O pipeline grava a linha mais recente de cada chave de entidade na tabela online, sem janela de agregação.
• A materialização online preenche a tabela online com o valor mais recente 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(),
)

Os recursos ColumnSelection usam TableTrigger, que executa o pipeline sempre que a tabela Delta de origem recebe uma nova confirmação. Nenhum offline_config é necessário porque as ColumnSelection características são lidas diretamente da fonte para usos offline (treinamento e inferência em lote).

Materializa os valores mais recentes com limite de atualização

Uma agregação em lote Last com um RollingWindow atribui um tempo de vida (TTL) a um recurso online: seu valor expira no armazenamento online quando nenhum valor da fonte se enquadra na janela. Isso é útil quando a idade de um valor determina se é seguro servi-lo. Por exemplo, o estado de um dispositivo da última hora pode ser retornado, enquanto um estado mais antigo resulta em null, 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 publica valores diariamente e você quiser manter apenas os valores dos últimos sete dias, use a RollingWindow com duração de sete dias. A cada acionamento, a materialização substitui completamente a tabela online, de modo que os valores fora da janela sejam removidos em intervalos previsíveis. Isso produz o mesmo resultado que um fluxo de streaming Last com um RollingWindow, mas custa menos porque não executa processamento continuamente.

Esse padrão de publicação é semelhante a uma tabela de características com TTL que é publicada em modo snapshot. Se você mantém um conjunto de tabelas de características e quiser usá-las junto com outras Feature Views, pode adaptá-las ao framework de autoria de Feature Views. Use um lote Last com um RollingWindow e um TableTrigger.

Essa combinação possui 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 sua janela deve ser um RollingWindow.
• A materialização deve fornecer um OnlineStoreConfig, omitir OfflineStoreConfig, e usar TableTrigger.

No exemplo a seguir, latest_device_state_1h há uma Funcionalidade registrada que atende a 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 treinamento offline e pontuação em lote, o cliente de engenharia de atributos calcula diretamente na fonte o valor pontual no tempo. Ela não lê uma materialização offline para este recurso.

Considerations

• A expiração só avança mediante um gatilho. O valor online e sua expiração avançam quando um commit na tabela de origem aciona uma atualização de materialização. O passar do tempo sozinho não desencadeia uma atualização. Se a fonte parar de publicar, o último valor materializado permanece na loja online até que um commit posterior acione uma atualização.
• Alinhe a coluna da série temporal com o horário 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 o armazenamento online realiza a junção no momento do gatilho, enquanto as leituras offline realizam a junção no momento da série temporal.
• Defina a duração da janela para múltiplo da cadência de publicação. Se a duração RollingWindow não for múltipla da cadência de publicação da fonte, alguns valores serão tratados como expirados durante o treinamento offline, embora ainda estejam visíveis online.

Funcionalidades sob demanda e materialização

RequestSource os valores vêm do DataFrame de treinamento ou da solicitação de inferência, portanto não há tabela de origem a ser materializada. Os recursos FeatureViewSource aplicam um CustomUDF aos valores dos recursos upstream durante o treinamento ou a disponibilização. Eles não armazenam um resultado pré-computado. A materialização também não é compatível com recursos CustomUDF baseados em uma tabela Delta.

Para um grafo de dependência em que revenue_sum_7d e cost_sum_7d alimentam uma margin funcionalidade:

• Para treinamento offline, chame create_training_set com margin. Eles resolvem os recursos upstream e calculam valores pontuais, usando materializações offline compatíveis quando disponíveis.
• Para a disponibilização online, materialize os recursos de receita e custo compatíveis em uma loja online. O endpoint os consulta e calcula margin para cada requisição.
• Passe apenas os recursos upstream compatíveis para materialize_features, não margin ou quaisquer recursos com suporte de solicitação. A materialização não materializa recursivamente as dependências de uma característica derivada.

Um gráfico que usa apenas recursos com suporte a requisições não precisa de uma loja online. Veja Treinar com recursos do FeatureViewSource e recursos derivados do Serve.

Permissões

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

• A materialização de um recurso requer MANAGE. Ao chamar materialize_features, são criados e gerenciados os pipelines subjacentes do Lakeflow e as tabelas do Unity Catalog; portanto, trata-se de uma operação de gerenciamento. Você deve ter MANAGE na funcionalidade, juntamente com READ FEATURE para ler a definição da funcionalidade que está sendo materializada.

• Deletar um recurso materializado é restrito ao seu criador. Apenas o usuário que criou um recurso materializado pode excluí-lo com delete_materialized_feature. Essa restrição é independente dos privilégios do Catálogo do Unity: MANAGE no recurso ou em seu esquema pai não permite que outro usuário o exclua.

• Ler dados de origem requer SELECT. Para um recurso que usa uma fonte de tabela Delta, você deve ter SELECT na tabela de fonte. Para um recurso que usa uma fonte Stream, você deve 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. Você deve ter CREATE TABLE em cada esquema especificado por 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 em um armazenamento online requer CAN USE. Você deve ter CAN USE na instância ou projeto do Lakebase usado pela loja online. Para obter informações sobre permissões do Lakebase, consulte Conceder permissões do projeto.

• Listar recursos materializados requer READ FEATURE no recurso pai. Para usar list_materialized_features, você deve ter READ FEATURE no recurso que foi materializado.

• A leitura de dados materializados requer SELECT. Você deve ter SELECT em cada tabela de saída offline ou online que você acessa. READ FEATURE na funcionalidade principal não concede acesso a essas tabelas.

Para cada recurso do Unity Catalog envolvido na materialização, você também precisa de USE CATALOG no catálogo pai e USE SCHEMA no esquema pai. Esse requisito se aplica ao recurso, a cada tabela de ingestão de origem ou de fluxo e a cada destino configurado. READ FEATURE e MANAGE concedidos em um esquema ou catálogo se aplicam a todos os recursos atuais e futuros que ele contém.

Estruturas de dados de API

OfflineStoreConfig

Configuração para o armazenamento offline em que os recursos materializados serão gravados. Quando materialize_features é chamado, o back-end do repositório de recursos cria tabelas usando esse prefixo. Cada execução de pipeline materializa os valores de recurso mais recentes para a tabela de acordo com o agendamento 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 o armazenamento online, que armazena recursos usados pelo Serviço de Modelo. A materialização cria tabelas Delta com o catalog.schema.table_name_prefixe transmite as tabelas para o Armazenamento de Recursos Online 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 visualização de recurso que foi materializada, ou seja, que tem uma representação pré-computada disponível no Unity Catalog. Há recursos materializados separados para a tabela offline e a tabela online. Normalmente, os usuários não instanciarão diretamente um MaterializedFeature.

Chamadas de função de API

materialize_features()

Materializa uma lista de Exibições de Recursos em uma tabela Delta offline ou em um Repositório de Recursos Online. Os recursos devem ser registrados no Catálogo do Unity antes de chamar essa função (por exemplo, usando create_feature ou register_feature). Recursos construídos localmente que não foram registrados não funcionarão.

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 retorna uma lista de recursos materializados, que contêm metadados sobre quando os valores de recurso são atualizados e as tabelas do Catálogo do Unity em que os recursos são materializados.

Se um OnlineStoreConfig e um OfflineStoreConfig forem fornecidos, dois recursos materializados serão exibidos por recurso fornecido, um para cada tipo de armazenamento.

O parâmetro trigger define quando o pipeline de materialização será executado.

• CronSchedule: executa de acordo com uma programação derivada do tempo de execução do recurso ou de acordo com uma programação cron do Quartz fornecida pelo solicitante. Compatível com funcionalidades de agregação em lote (AggregationFunction de DeltaTableSource).
• TableTrigger: é executado quando a tabela Delta upstream recebe uma confirmação. Compatível com funcionalidades ColumnSelection e funcionalidades de agregação (AggregationFunction) com suporte de um DeltaTableSource. Para funcionalidades de agregação, o pipeline tem sua execução limitada a, no máximo, uma vez a cada metade da granularidade da funcionalidade (o intervalo de deslizamento para uma janela deslizante ou a duração da janela para uma janela fixa), com limite máximo de 1 hora e nunca em intervalos menores que 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, então um commit que chega após o fim desse intervalo ainda aciona uma execução imediatamente.
• StreamingMode: é executado como um pipeline de streaming contínuo. Necessário para recursos apoiados por um StreamSource.

Não é possível misturar recursos que exigem tipos de gatilho diferentes em uma ú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 os aplica ao trabalho ou pipeline que cria, de modo que seu gasto carregue sua atribuição na tabela de uso faturável do sistema. Ambos são aplicados na criação, então atribuir uma materialização existente de forma diferente significa criar uma nova. budget_policy_id assume o ID de uma política de uso serverless. Para criar um e obter seu ID, veja Criar uma política de uso serverless. Para os limites de tags, os recursos que cada valor abrange e como consultar o gasto atribuído, consulte Gerenciamento de custos do Feature Store.

Materializar para o armazenamento 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",
    ),
)

Materializar para o armazenamento 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",
    ),
)

Materializar recursos de streaming

Os recursos de streaming só podem ser materializados para lojas online; não há suporte para o offline_config parâmetro. A materialização offline não é compatível porque as funcionalidades de streaming exigem um pipeline em tempo real para garantir atualização em menos de um segundo. Para treinamento ou avaliação offline, o cliente de engenharia de recursos recompilará os valores de recurso com base em cada ponto de dados avaliado.

Os recursos de streaming não podem ser misturados com recursos de 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()

Retorna as materializações de um único recurso, identificado pelo nome completo. feature_name é obrigatório e somente palavra-chave. Para examinar as materializações em muitos recursos, primeiro liste os recursos em um catálogo ou esquema e, em seguida, chame list_materialized_features em cada recurso retornado.

Por padrão, no máximo 100 materializações são retornadas. Você pode alterar esse 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 excluir um recurso materializado, remova ou atualize quaisquer modelos ou especificações de recursos que façam referência ao recurso.

Exclui uma funcionalidade materializada. O recurso que será passado depende do tipo de recurso:

• Recursos de agregação: transmitem o recurso materializado offline. Se houver um recurso materializado online para o mesmo recurso, ambos os recursos serão excluídos. Para um recurso de lote Last somente online com um RollingWindow, passe o recurso materializado online.
• Recursos ColumnSelection: transmitem o recurso materializado online. Os recursos ColumnSelection são materializados apenas para o armazenamento online (consulte a Materialização ColumnSelection), portanto, não há um recurso offline correspondente.

Como parte da materialização, as características são agrupadas pela fonte de dados e pela janela de agregação para maior eficiência. ColumnSelection os recursos não têm janela de agregação, portanto, são agrupados apenas pela fonte de dados. O pipeline de materialização, a tabela offline e a tabela online não são excluídos até que todos os recursos agrupados tenham sido excluídos. Quando o último recurso materializado em um grupo é excluído, o armazenamento de recursos programa a limpeza automática dos recursos associados por meio de um processo em segundo plano. Consulte a limpeza de recursos em segundo plano.

Para limpar características materializadas, consulte a tabela associada a uma característica materializada. Cada recurso na tabela (um por coluna) deve ser excluído antes que a computação e os recursos da tabela Delta sejam limpos.

Use list_materialized_features() para obter 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 você exclui um recurso materializado, o Databricks remove os metadados do recurso imediatamente. A infraestrutura associada (tabelas, pipelines e tarefas) é removida de forma assíncrona por um processo em segundo plano.

Como vários recursos materializados podem compartilhar as mesmas tabelas e pipelines, esses recursos compartilhados não são removidos até que todos os recursos materializados que fazem referência a eles sejam excluídos. Quando o último recurso materializado que compartilha um conjunto de tabelas é excluído, o processo em segundo plano exclui automaticamente os seguintes recursos:

• As tabelas offline do Delta que contêm os dados de atributos materializados
• As tabelas online, se os recursos foram materializados para um armazenamento online
• O pipeline de materialização
• O trabalho de orquestração

Esse processo em segundo plano usa uma entidade de serviço do sistema gerenciada pelo Databricks para realizar essas ações de limpeza em seu nome, incluindo a exclusão de tabelas, pipelines e trabalhos em seu espaço de trabalho. Você não precisa fazer nada. A limpeza é totalmente gerenciada pelo armazenamento de recursos.

Exibir status de materialização

Para ver o status de materialização das suas exibições de recursos na interface do Databricks e depurar erros de materialização, consulte Explorar exibições de recursos no Unity Catalog.

Limitações

Funcionalidades de processamento em lote

• Os pipelines de materialização de lote são executados como pipelines sem servidor do Lakeflow.
• Os recursos de janela deslizante de lote não podem ser materializados, exceto para o caso especial Last somente online descrito em Materializar valores mais recentes com limite de atualização. Para treinamento offline ou inferência em lote, os atributos de janela deslizante são calculados a partir dos dados de origem para cada consulta pontual no tempo.
• ColumnSelection as funcionalidades apenas podem ser implementadas em lojas virtuais.
• Os recursos RequestSource, FeatureViewSource e CustomUDF não podem ser materializados. Veja Recursos sob demanda e materialização.
• Os recursos materializados só podem ser excluídos no workspace no qual foram criados.
• Somente o usuário que criou uma funcionalidade materializada pode excluí-la, independentemente dos privilégios do Catálogo Unity sobre a funcionalidade ou seu esquema pai.
• Para recursos de agregação materializados, o recurso materializado online não pode ser excluído diretamente. Exclua o recurso materializado offline emparelhado e a alteração se propaga para ambos.
• Para recursos de agregação materializados criados antes de 20 de abril de 2026, o pipeline de materialização continua produzindo novos valores de recurso até que todos os recursos materializados no pipeline sejam excluídos, iniciando a limpeza de recursos. Para criar um pipeline atualizado que dê suporte à exclusão por recurso, exclua e materialize novamente o recurso.
• Para recursos materializados ColumnSelection, o pipeline de materialização continua produzindo novos valores de recursos até que todos os recursos materializados no pipeline sejam excluídos, o que dispara a limpeza de recursos.

Recursos de streaming

• Os recursos de streaming só podem ser materializados para lojas online. A materialização offline não é necessária porque os atributos em streaming durante o treinamento são projetados para ser recomputados com base em eventos históricos para cada ponto de dados, a fim de fornecer precisão na escala de milissegundos.
• Os recursos de streaming não podem ser misturados com recursos de lote em uma única materialize_features chamada.
• compute_features não dá suporte a recursos de streaming.
• O workspace deve estar em uma região que dê suporte a instâncias do Lakebase.
• Há suporte apenas para mensagens Kafka serializadas por JSON. Os esquemas de mensagem devem ser fornecidos diretamente no formato de esquema JSON. Os registros de esquema (Confluent, Glue) não têm suporte formal durante a versão prévia, mas se você fornecer o esquema diretamente, os pipelines poderão ler a partir de tópicos regidos por um registro de esquema.
• Há suporte apenas RollingWindow para recursos de agregação de streaming. TumblingWindow e SlidingWindow devem ser usados com funcionalidades de processamento em lote.
• Apenas as funções de agregação Count, Sum, Avg, StddevPop, Max, LastN, First, Last, FirstN, Min, FirstDistinct e LastDistinct são compatíveis com funcionalidades de streaming.
• As funcionalidades de seleção de colunas em fontes de streaming não oferecem suporte a mensagens fora de ordem. O evento mais recente no fluxo Kafka é exibido, mesmo que o valor da coluna de série temporal seja anterior ao de um evento recebido anteriormente.
• Os pipelines de streaming são reiniciados duas vezes por semana. Cada reinicialização pode causar atrasos de processamento e tempos de inicialização de até 1 minuto. Excluindo reinicializações, a atualização p99 é de 200ms.
• Não há suporte para backfill de atributos na materialização. Quando uma funcionalidade é materializada, os cálculos são feitos a partir desse ponto em diante. As agregações recém-criadas na loja online são imprecisas até que a respectiva janela de tempo se encerre.
• Há suporte apenas para o Repositório de Recursos do Databricks Online .
• Os pipelines de materialização de streaming são executados como pipelines sem servidor do Lakeflow.
• Somente para espaços de trabalho do nível Enterprise.