Pular para o conteúdo principal
Última atualização em

Materializar view de recurso

Depois de criar suas definições de Feature View, que são armazenadas no Unity Catalog, você pode produzir dados de recursos da sua tabela de origem usando as definições de recursos. Este processo é chamado de materialização de seus recursos. O Databricks cria e gerencia Lakeflow pipelines para preencher tabelas no Unity Catalog para treinamento de modelo e pontuação em lote ou serviço online.

Para obter informação sobre como disponibilizar Recurso Views, consulte Disponibilizar Recurso Views.

Para recalcular os valores materializados após corrigir ou adicionar dados históricos de origem, consulte Preenchimento retroativo de views de recursos.

Para remover valores materializados para entidades selecionadas, consulte Limpar valores de recursos para entidades.

Requisitos​

  • Os recursos devem ser criados como Views de recursos e armazenados no Unity Catalog.
  • Para requisitos de versão, consulte Requisitos.

Suporte à materialização por tipo de recurso​

Se e onde um recurso pode ser materializado depende do seu tipo:

Recursos que se materializam apenas para lojas online ainda podem ser usados offline: create_training_set e compute_features compute seus valores pontuais diretamente da origem, portanto, nenhuma materialização offline é necessária.

Materialização de seleção de coluna​

ColumnSelection recurso seleciona o valor mais recente de uma única coluna por key de entidade sem agregação. Eles só podem ser materializados em lojas online. Para casos de uso offline (treinamento e inferência de lotes), os recursos ColumnSelection são obtidos 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 por key de entidade na tabela online, sem janela de agregação.
  • A materialização online preenche a tabela online com o valor mais recente para cada key de entidade.

Exemplo​

Python
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 recurso use TableTrigger, que executa o pipeline sempre que a tabela Delta de origem recebe um novo commit. Não é necessário offline_config porque ColumnSelection recurso são lidos diretamente da fonte para casos de uso offline (treinamento e inferência de lotes).

nota

RequestSource Os recursos não podem ser materializados porque eles representam dados fornecidos pelo chamador no momento da inferência (ou extraídos do DataFrame rotulado no momento do treinamento). Não há tabela de origem para ler. Os valores existem apenas no payload da solicitação ou no DataFrame de treinamento.

Materializar os últimos valores limitados por atualização​

Uma agregação em lotes Last com um RollingWindow concede a um recurso online um tempo de vida (TTL): o valor expira do armazenamento online quando nenhum valor de origem estiver dentro da janela. Isso é útil quando a idade de um valor determina se é seguro disponibilizá-lo. Por exemplo, um estado de dispositivo da última hora pode ser disponibilizado, enquanto um estado mais antigo é resolvido como nulo em vez de permanecer disponível indefinidamente.

Um RollingWindow define uma duração explícita que dá ao recurso um comportamento semelhante ao TTL. Por exemplo, se a origem publica valores diariamente e você deseja manter apenas os valores dos últimos sete dias, use um RollingWindow com uma duração de sete dias. A cada Trigger, a materialização faz uma substituição completa da tabela online, de modo que os valores que ficam fora da janela são removidos em um programar previsível. Isso produz o mesmo resultado que um Last de transmissão com um RollingWindow, mas custa menos porque não executa o compute continuamente.

Esse padrão de publicação é semelhante a uma tabela de recursos com um TTL publicado no modo de snapshot. Se você mantiver um conjunto de tabelas de recursos e quiser usá-las junto com outras views de recursos, poderá adaptá-las à estrutura de criação de views de recursos. Use um Last em lote com um RollingWindow e um TableTrigger.

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

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

No exemplo a seguir, latest_device_state_1h é um recurso registrado que atende a estes requisitos:

Python
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 lotes, o cliente de engenharia de recursos calcula o valor pontual diretamente da origem. Ele não lê uma materialização offline para esse recurso.

Considerações​

  • A expiração avança apenas em um trigger. O valor online e sua expiração avançam quando um commit da tabela de origem Trigger um refresh da materialização. A passagem do tempo por si só não Trigger um refresh. Se a origem parar de publicar, o último valor materializado permanecerá no armazenamento online até que um commit posterior acione um refresh.
  • Alinhe a coluna de série temporal com o horário de publicação de origem. A coluna de série temporal deve refletir quando a origem publicou os dados. Caso contrário, os valores online e offline divergem, pois o armazenamento online faz o join no horário do trigger, enquanto as leituras offline fazem o join no horário da série temporal.
  • Set the window duração to a multiple of the publish cadence. If the RollingWindow duração is not a multiple of the source publish cadence, some values are treated as expired during offline treinamento while they are still visible online.

Recursos sob demanda e materialização​

RequestSource os valores vêm do treinamento DataFrame ou da solicitação de inferência, portanto, não há tabela de origem para materializar. Os recursos FeatureViewSource aplicam um CustomUDF aos valores de 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 gráfico de dependências como revenue_sum_7d e cost_sum_7d alimentando um recurso margin:

  • Para treinamento offline, chame create_training_set com margin. Ele resolve os recursos upstream e calcula valores pontuais, usando materializações offline compatíveis quando disponíveis.
  • Para veiculação online, materialize os recursos de receita e custo compatíveis em um armazenamento online. O endpoint os procura e computa margin para cada solicitação.
  • Encaminhe apenas os recursos upstream compatíveis para materialize_features, não para margin ou quaisquer recursos baseados em solicitação. A materialização não materializa recursivamente as dependências de um recurso derivado.

Um gráfico que usa apenas recursos apoiados por solicitações não precisa de um armazenamento online. Consulte Ensinar com recursos do FeatureViewSource e Disponibilizar recursos derivados.

Permissões​

A materialização exige privilégios no recurso e nos recursos de origem e destino. Para obter descrições completas dos privilégios do Unity Catalog, consulte Referência de privilégios do Unity Catalog.

  • Materializing a recurso requires MANAGE. Calling materialize_features creates and manages the backing LakeFlow Pipelines and Unity Catalog tables, so it is a management operation. You must have MANAGE on the recurso, along with READ FEATURE to read the recurso definition being materialized.

  • A exclusão de um recurso materializado é restrita ao seu criador. Only the user who created a materialized recurso can delete it with delete_materialized_feature. This restriction is independent of Unity Catalog privileges: MANAGE on the recurso or its parent schema does not let another user delete it.

  • Reading source data requires SELECT. For a recurso that uses a Delta table source, you must have SELECT on the source table. For a recurso that uses a transmissão source, you must have SELECT on the transmissão's ingestion table.

    Para outras permissões exigidas pela configuração de autenticação de uma transmissão, consulte a autenticação do Kafka para o Kafka ou a autenticação do Kinesis para o Kinesis.

  • A criação de tabelas de destino requer CREATE TABLE. Você deve ter CREATE TABLE em todos os esquemas especificados por OfflineStoreConfig ou OnlineStoreConfig. Os destinos offline e online podem estar em esquemas ou catálogos diferentes, e a materialização exige privilégios em cada destino.

  • A materialização em um armazenamento online requer CAN USE. Você deve ter CAN USE na instância ou no projeto do Lakebase usado pelo armazenamento online. Para obter informações sobre permissões do Lakebase, consulte Conceder permissões de projeto.

  • Listar recursos materializados exige 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 online ou offline que você acessar. READ FEATURE no recurso pai não concede acesso a essas tabelas.

Para cada recurso do Unity Catalog envolvido na materialização, você também precisa de USE CATALOG em seu catálogo principal e de USE SCHEMA em seu esquema principal. This requirement applies to the recurso, each source or transmissão ingestion table, and each configured destination. READ FEATURE e MANAGE concedidos em um esquema ou catálogo se aplicam a todos os recursos atuais e futuros contidos nele.

Estruturas de dados da API​

OfflineStoreConfig​

Configuração para o armazenamento offline onde o recurso materializado será gravado. Quando materialize_features é chamado, o backend do repositório de recursos cria tabelas usando esse prefixo. Cada execução pipeline materializa os valores mais recentes dos recursos na tabela, de acordo com a materialização programada.

Python
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
)
Python
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 do armazenamento online, que armazena recurso utilizado pelo modelo de operação. A materialização cria tabelas Delta com o catalog.schema.table_name_prefix e transmite as tabelas para o Feature Store Online com o mesmo nome.

Python
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 um recurso view que foi materializado, isto é, que possui uma representação pré-calculada disponível no Unity Catalog. Existem recursos materializados separados para a tabela offline e a tabela online. Normalmente, você não instancia um MaterializedFeature diretamente.

O campo latest_backfill_operation contém o nome do preenchimento retroativo mais recente do recurso materializado. Veja Backfill Feature Views (Preencher views de recurso).

chamadas de funções da API​

materialize_features()​

Materializa uma lista de Views de Recursos em uma tabela Delta offline ou em uma Feature Store Online. Recursos devem ser registrados no Unity Catalog antes de chamar esta função (por exemplo, usando create_feature ou register_feature). Recursos construídos localmente que não foram registrados não funcionarão.

Python
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 dos recursos são atualizados e as tabelas Unity Catalog onde os recursos são materializados.

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

O parâmetro trigger controla quando a execução do pipeline de materialização:

  • CronSchedule : é executado em uma programação derivada do tempo do recurso ou em uma programação cron do Quartz fornecida pelo chamador. Com suporte para recursos de agregação em lotes (AggregationFunction de DeltaTableSource).
  • TableTrigger : Runs when the upstream Delta table receives a commit. Compatível com recursos de ColumnSelection e recursos de agregação (AggregationFunction) apoiados por um DeltaTableSource. For aggregation recursos, the pipeline is throttled to execução at most once per half the recurso's granularity (the slide duração for a sliding window, or the window length for a tumbling window), capped at 1 hour and never more often than every 5 minutes. For example, at most once every 30 minutes for a 1-hour granularity, or at most once an hour for a granularity of 2 hours or more. O intervalo é medido a partir da execução anterior, portanto, um commit que chega após o término do intervalo ainda aciona uma execução prontamente.
  • StreamingMode : Em execução como um pipeline de transmissão contínua. Necessário para recursos suportados por um StreamSource.

Não é possível misturar recursos que exigem diferentes tipos de gatilho em uma única chamada materialize_features. Faça chamadas separadas em vez disso.

Para atribuir o custo de uma materialização, passe tags, budget_policy_id ou ambos. O Databricks os aplica ao job ou pipeline que ele cria, de modo que o gasto carregue sua atribuição na tabela do sistema de uso faturável. Ambos são aplicados na criação, portanto, atribuir uma materialização existente de forma diferente significa criar uma nova. budget_policy_id aceita o ID de uma política de uso serverless. Para criar um e obter seu ID, consulte Criar uma política de uso serverless. Para obter os limites de tags, os recursos que cada valor alcança e como fazer query dos gastos atribuídos, consulte Gerenciamento de custos do Feature Store.

Materializar para armazenamento offline​

Python
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 armazenamento online​

nota

Para materializar a maioria dos recursos de agregação em um armazenamento online, você também deve materializar em um armazenamento offline. Tanto offline_config quanto online_config são obrigatórios. O online_store_name deve fazer referência a um Online Feature Store existente. Para obter instruções sobre como criar um, consulte Databricks Online Feature Stores.

ColumnSelection recurso não requer um OfflineStoreConfig. Veja a materialização de ColumnSelection.

O caso especial de lote Last com RollingWindow também é somente online. Consulte Materializar os valores mais recentes limitados por frescor.

Python
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 transmissão​

Recursos de transmissão só podem ser materializados em armazenamentos online; o parâmetro offline_config não é suportado. A materialização offline não é suportada porque recursos de transmissão exigem um pipeline em tempo real para garantir a atualização em microssegundos. Para treinamento ou avaliação offline, o cliente de engenharia de recursos recalculará os valores dos recursos com base em cada pontos de dados avaliado.

Recursos de transmissão não podem ser misturados com recursos de lotes na mesma chamada materialize_features.

Python
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 por palavra-chave. Para revisar as materializações em vários recursos, primeiro liste os recursos em um catálogo ou esquema, depois chame list_materialized_features em cada recurso retornado.

Por default, um máximo de 100 materializações são retornadas. Você pode alterar este limite usando o parâmetro max_results.

Python
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 a ele.

Exclui um recurso materializado. O recurso a ser passado depende do tipo de recurso:

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

Como parte da materialização, os recursos são agrupados por fonte de dados e janela de agregação para maior eficiência. ColumnSelection recursos não têm janela de agregação, portanto, são agrupados apenas por 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 sejam excluídos. Quando o último recurso materializado em um grupo é excluído, o repositório de recursos programa os recursos associados para limpeza automática por um processo em segundo plano. Consulte limpeza de recurso em segundo plano.

Para limpar recursos materializados, consulte a tabela associada a eles. Cada recurso na tabela (um por coluna) deve ser excluído antes que os recursos das tabelas compute e Delta sejam limpos.

Use list_materialized_features() para obter o argumento materialized_feature .

Python
FeatureEngineeringClient.delete_materialized_feature(
    materialized_feature: MaterializedFeature,  # Required: The materialized feature to delete
) -> None
Python
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, a Databricks remove os metadados do recurso imediatamente. A infraestrutura associada (tabelas, pipelines e jobs) é limpa assincronamente por um processo em segundo plano.

Como múltiplos recursos materializados podem compartilhar as mesmas tabelas e pipelines, esses recursos compartilhados não são removidos até que todo recurso materializado que os referencia tenha sido excluído. 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 Delta offline que contêm os dados de recurso materializados
  • As tabelas online, se os recursos foram materializados para um armazenamento online.
  • O pipeline de materialização
  • O Job de orquestração

Esse processo em segundo plano usa uma entidade de serviço de sistema gerenciada pelo Databricks para realizar essas ações de limpeza em seu nome, incluindo a exclusão de tabelas, pipelines e Jobs em seu workspace. Não é necessária nenhuma ação do(a) senhor(a). A limpeza é totalmente gerenciada pelo repositório de recursos.

nota

Pode haver um pequeno atraso entre a exclusão do último recurso materializado em um grupo e a remoção das tabelas associadas e outros recursos.

Status de materialização da view​

Para visualizar o status de materialização de suas Feature Views na interface do Databricks e depurar erros de materialização, consulte Explore Feature Views in Unity Catalog.

Validar a atualização de ponta a ponta da RollingWindow​

nota

A validação de atualização usa Lakebase Change Data Feed (CDF), que está em pré-lançamento público. Um administrador de workspace deve habilitar a prévia do Lakebase Change Data Feed antes de você poder ativar o CDF.

Esta seção se aplica apenas a agregações RollingWindow. Os recursos em lote não expõem os metadados de frescor de transmissão descritos aqui.

Recursos de transmissão RollingWindow materializados em um armazenamento online Lakebase contêm metadados de frescor por linha. Com o CDF, você captura todas as atualizações na tabela online em uma tabela de história Delta no Unity Catalog e mede o frescor de ponta a ponta sem executar um pipeline adicional. O frescor de ponta a ponta é o intervalo entre o momento em que um evento ocorreu e quando o seu valor agregado ficou disponível para servir.

Como os recursos da RollingWindow emitem linhas​

Para um recurso RollingWindow, o valor de cada entidade resume os eventos dentro de uma janela de tempo fixa (por exemplo, a contagem de transações na última hora). A janela desliza para frente continuamente, portanto, uma linha é gravada no armazenamento online em duas situações:

  • Atualização data-driven (is_timer = false): um novo evento chega e atualiza o agregado. A linha reflete o evento mais recente na janela.
  • Expiração da janela (is_timer = true): nenhum novo evento chega, mas o tempo avança e os eventos mais antigos ficam fora da janela ou envelhecem . Como esses eventos não contam mais para o agregado, o valor muda (por exemplo, uma contagem diminui), então o recurso emite uma linha atualizada em um timer. A linha reflete o momento em que o evento mais antigo envelheceu, que é o fim da janela desse evento.

Duas formas de um recurso de transmissão de janela deslizante escrever uma linha: uma atualização data-driven quando um novo evento chega (is_timer = false) e uma atualização de expiração de janela quando o evento mais antigo expira da janela (is_timer = true).

Em ambos os casos, event_time é quando a alteração que produziu a linha ocorreu: um novo evento chegando ou o evento mais antigo expirando. Portanto, commit_time - event_time é a atualidade da linha, independentemente de como ela foi emitida.

Metadados de atualização​

Cada linha online de transmissão transporta as seguintes colunas:

Coluna

Descrição

event_time

Quando ocorreu a alteração que produziu a linha. Em uma atualização data-driven (is_timer = false), o horário do evento mais recente (máximo) na janela. Em uma atualização de expiração de janela (is_timer = true), o horário em que o evento mais antigo envelheceu: o horário desse evento mais a duração da janela. Se a tabela online mantiver recursos com diferentes durações de janela, a janela que expirou será usada.

output_time

A fronteira da janela de transmissão (marca d'água) na emissão.

is_timer

Como a linha foi emitida: false = um evento recém-chegado avançou o agregado (data-driven); true = a janela avançou em um temporizador e os dados mais antigos expiraram (expiração da janela).

commit_time

Quando a linha foi gravada no armazenamento online do Lakebase.

Coluna

Descrição

event_time

Quando ocorreu a alteração que produziu a linha. Em uma atualização data-driven (is_timer = false), o horário do evento mais recente (máximo) na janela. Em uma atualização de expiração de janela (is_timer = true), o horário em que o evento mais antigo envelheceu: o horário desse evento mais a duração da janela. Se a tabela online mantiver recursos com diferentes durações de janela, a janela que expirou será usada.

output_time

A fronteira da janela de transmissão (marca d'água) na emissão.

is_timer

Como a linha foi emitida: false = um evento recém-chegado avançou o agregado (data-driven); true = a janela avançou em um temporizador e os dados mais antigos expiraram (expiração da janela).

commit_time

Quando a linha foi gravada no armazenamento online do Lakebase.

Quando o CDF está ativado, cada alteração é anexada a uma tabela Delta lb_<online_table>_history com colunas de metadados CDF. A coluna _pg_change_type (insert, update_preimage, update_postimage ou delete) identifica cada tipo de alteração.

Habilitar CDF na tabela online​

atenção

Use o CDF para validar a atualização de ponta a ponta, por exemplo, enquanto testa um pipeline ou ajusta sua configuração, em vez de monitorar a atualização continuamente em um armazenamento online de produção. O CDF e o REPLICA IDENTITY FULL adicionam carga à instância do Lakebase, principalmente CPU para decodificar alterações e volume extra de write-ahead log. A sobrecarga cresce com o número de tabelas sendo sincronizadas e com grandes valores de coluna, como matrizes ou mapas. Se você habilitar o CDF em um armazenamento online que atende ao tráfego de produção, aumente as unidades de computação (CU) máximas para que o autoscale tenha espaço e monitore a CPU e a latência de disponibilização online.

  1. O Lakebase CDF requer que a identidade de réplica seja definida como FULL em cada tabela de origem para que as atualizações sejam capturadas com imagens de linha completas antes e depois. Defina na tabela online:

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

  2. Iniciar o CDF do Lakebase para o armazenamento online, escolhendo o esquema de origem e um catálogo e esquema de destino do Unity Catalog. Para detalhes de configuração, consulte Alteração do feed de dados do Lakebase.

O CDF cria lb_<online_table>_history no esquema de destino.

Para parar de capturar alterações, consulte Desativar o CDF do Lakebase. Desativar o CDF interrompe o feed para todos os esquemas no projeto. Depois de desativar o CDF, você pode Reset a identidade da réplica da tabela online para remover o volume extra de Logs de gravação antecipada:

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

Atualidade do compute​

A atualização é commit_time - event_time para linhas data-driven e de expiração de janela. Inclua is_timer para que você possa comparar os dois tipos de emissão e limitar a query ao período que deseja medir.

SQL
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 é o atraso, em milissegundos, desde o horário do evento até a gravação na loja online. Esta é a atualidade do valor disponível para servir.

nota

Quando você habilita CDF em uma tabela online que já possui linhas, o Snapshot inicial copia cada linha existente na tabela de história como um insert. Cada linha copiada mantém o event_time e commit_time da última gravação dessa entidade, portanto seu valor de frescor é preciso, mas o snapshot contribui exatamente com uma amostra por entidade. Para medir apenas as gravações capturadas pelo feed, aguarde até que o status da tabela na tab Lakebase CDF mude de Snapshotting para Streaming, anote o horário e use-o como o limite inferior em vez de max(commit_time) - INTERVAL 1 DAY. Uma alteração de esquema na tabela online Trigger outro Snapshot completo, que repete as gravações que o feed já capturou. Não filtre todas as insert linhas, porque a primeira gravação de cada nova entidade também é um insert.

Interpretar os resultados​

  • Acompanhe tanto p50 quanto p99 de feature_freshness_ms e compare linhas data-driven (is_timer = false) com linhas de expiração de janela (is_timer = true).
  • Espere um pequeno pico periódico no limite de lotes de modo em tempo real (5 minutos por default), quando o pipeline pausa brevemente para fazer checkpoint e commit. Isso geralmente é negligenciável no intervalo default.
  • Observe a rara cauda longa (o máximo, além de p99). Isso reflete a recuperação do pipeline em vez do estado estável, mais notavelmente após uma reinicialização, como uma reinicialização de manutenção, quando o pipeline processa eventos em buffer. Meça a atualização do estado estável em uma janela que exclui reinicializações e avalie os picos de reinicialização separadamente.

Limitações​

Recursos de lotes​

  • Pipelines de materialização em lotes são executados como serverless Lakeflow pipelines.
  • Recursos de janela deslizante em lotes não podem ser materializados, exceto para o caso especial de Last apenas online descrito em Materialize freshness-bounded latest values. Para treinamento offline ou inferência em lotes, os recursos de janela deslizante são computados a partir dos dados de origem para cada pesquisa pontual.
  • ColumnSelection O recurso só pode ser materializado em lojas online.
  • RequestSource, FeatureViewSource e CustomUDF recursos não podem ser materializados. Consulte Recursos sob demanda e materialização.
  • Recursos materializados só podem ser excluídos no workspace em que foram criados.
  • Only the user who created a materialized recurso can delete it, regardless of Unity Catalog privileges on the recurso or its parent schema.
  • Para recursos de agregação materializados, o recurso materializado online não pode ser excluído diretamente. Ao excluir o recurso materializado offline correspondente, 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 recursos até que todos os recursos materializados no pipeline sejam excluídos, o que aciona a limpeza de recursos. Para criar um pipeline atualizado que suporte a exclusão por recurso, exclua e rematerialize 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 tenham sido excluídos, o que aciona a limpeza de recursos.

Recursos de transmissão​

  • Recursos de transmissão podem ser materializados apenas para repositórios online. A materialização offline não é necessária porque os recursos de transmissão no momento do treinamento são projetados para serem recalculados a partir de eventos históricos por pontos de dados para fornecer precisão em nível de milissegundos.
  • Recursos de transmissão não podem ser misturados com recursos de lotes em uma única chamada materialize_features.
  • compute_features não é compatível com recursos de transmissão.
  • O workspace deve estar em uma região que suporte instâncias Lakebase.
  • As mensagens do Kafka podem usar JSON, Avro ou Protobuf. Para consultar os requisitos de esquema e as limitações do registro de esquemas, consulte Registro de esquemas.
  • Somente RollingWindow e SawtoothWindow são suportados para recursos de agregação de transmissão. TumblingWindow e SlidingWindow devem ser usados com recursos de lote. Consulte Janelas de tempo para recursos de transmissão.
  • Apenas as funções de agregação Count, Avg, Sum, StddevPop, Max, Min, First, Last, FirstN, LastN, FirstDistinct e LastDistinct são compatíveis com recursos de transmissão.
  • Recursos de seleção de coluna de fontes de transmissão não lidam com mensagens fora de ordem. O evento mais recente na transmissão do Kafka é mostrado, mesmo que o valor da coluna de série temporal seja anterior a um evento recebido anteriormente.
  • Os pipelines de transmissão são reiniciados duas vezes por semana. Cada reinício pode causar atrasos de processamento e tempos de startup de até 1 minuto. Excluindo reinícios, a atualização p99 é de 200ms.
  • Os recursos de transmissão não podem ser preenchidos retroativamente com backfill_features. Para adicionar data histórica a uma transmissão para treinamento, configure uma fonte de preenchimento retroativo na transmissão.
  • Um recurso RollingWindow no armazenamento online cobre apenas eventos que chegam após a materialização começar, portanto, seus valores são completos apenas após a passagem de todo o seu window_duration. Um recurso SawtoothWindow compute seus valores históricos da tabela de ingestão da transmissão quando a materialização começar. A materialização não recalcula esses valores se você corrigir os dados posteriormente na tabela de ingestão.
  • Somente a Feature Store Online da Databricks é compatível.
  • Pipelines de materialização de transmissão são executados como LakeFlow Pipelines Serverless.
Nesta página