Esquema LIVE (legado)

Este artigo fornece uma visão geral da sintaxe e do comportamento herdados para o esquema virtual LIVE.

O esquema virtual LIVE é uma funcionalidade antiga das pipelines DLT e é considerado preterido. Você ainda pode usar o modo de publicação herdado e o esquema virtual LIVE para pipelines que foram criados com esse modo.

O suporte para esquema virtual LIVE legado e modo de publicação legado será removido numa versão futura do Azure Databricks.

Observação

Os pipelines do modo de publicação herdado são indicados no campo Resumo da UI de definições do pipeline DLT. Você também pode confirmar que um pipeline usa o modo de publicação herdado se o campo target estiver definido na especificação JSON para o pipeline.

Não é possível usar a interface de configuração de pipeline para criar novos pipelines com o modo de publicação herdado. Se você precisar implantar novos pipelines usando sintaxe de LIVE herdada, entre em contato com seu representante de conta Databricks.

O que é o esquema virtual LIVE?

Observação

O esquema virtual LIVE não é mais necessário para analisar a dependência do conjunto de dados no modo de publicação padrão para DLT.

O esquema LIVE é um conceito de programação em DLT que define um limite virtual para todos os conjuntos de dados criados ou atualizados em um pipeline. Por design, o esquema LIVE não está vinculado diretamente a conjuntos de dados em um esquema publicado. Em vez disso, o esquema LIVE permite que a lógica em um pipeline seja planejada e executada mesmo que um usuário não queira publicar conjuntos de dados em um esquema.

Em pipelines no modo de publicação herdado, você pode usar a palavra-chave LIVE para referenciar outros conjuntos de dados no pipeline atual para leitura, por exemplo, SELECT * FROM LIVE.bronze_table. No modo de publicação predefinido para novos pipelines DLT, essa sintaxe é ignorada sem aviso, o que significa que identificadores não qualificados usam o esquema atual. Consulte Definir o catálogo de destino e o esquema.

Modo de publicação herdado para pipelines

O esquema virtual LIVE é usado com o modo de publicação herdado para pipelines DLT. Todas as tabelas criadas antes de 5 de fevereiro de 2025 usam o modo de publicação herdado por padrão.

A tabela a seguir descreve o comportamento de todas as exibições materializadas e tabelas de streaming criadas ou atualizadas em um pipeline no modo de publicação herdado:

Opção de armazenamento	Local de armazenamento ou catálogo	Esquema de destino	Comportamento
Metastore do Hive	Nenhum especificado	Nenhum especificado	Os metadados e dados do conjunto de dados são armazenados na raiz DBFS. Nenhum objeto de banco de dados é registrado no metastore do Hive.
Metastore do Hive	Um URI ou caminho de arquivo para o armazenamento de objetos na nuvem.	Nenhum especificado	Os metadados e os dados do conjunto de dados são armazenados no local de armazenamento especificado. Nenhum objeto de banco de dados é registrado no metastore do Hive.
Metastore do Hive	Nenhum especificado	Um esquema novo ou existente no metastore do Hive.	Os metadados e dados do conjunto de dados são armazenados na raiz DBFS. Todas as visualizações materializadas e tabelas de streaming no pipeline são publicadas no esquema especificado no Hive Metastore.
Metastore do Hive	Um URI ou caminho de arquivo para o armazenamento de objetos na nuvem.	Um esquema existente ou novo no metastore do Hive.	Os metadados e os dados do conjunto de dados são armazenados no local de armazenamento especificado. Todas as visualizações materializadas e tabelas de streaming no pipeline são publicadas no esquema especificado no metastore do Hive.
Catálogo Unity	Um catálogo Unity Catalog existente.	Nenhum especificado	Os metadados e os dados do conjunto de dados são armazenados no local de armazenamento padrão associado ao catálogo de destino. Nenhum objeto de banco de dados é registrado no Catálogo Unity.
Catálogo Unity	O catálogo Unity Catalog existente.	Um esquema existente ou novo no Unity Catalog.	Os metadados e os dados do conjunto de dados são armazenados no local de armazenamento padrão associado ao esquema ou catálogo de destino. Todas as visualizações materializadas e tabelas de streaming do pipeline são publicadas no esquema especificado no Unity Catalog.

Atualizar código-fonte do esquema LIVE

Os pipelines configurados para serem executados com o novo modo de publicação padrão ignoram silenciosamente a sintaxe do esquema LIVE. Por padrão, todas as leituras de tabela usam o catálogo e o esquema especificados na configuração do pipeline.

Para a maioria dos pipelines existentes, essa alteração de comportamento não tem impacto, pois o comportamento do esquema virtual LIVE herdado também direciona leituras para o catálogo e o esquema especificados na configuração do pipeline.

Importante

O código herdado com leituras que aproveitam o catálogo e o esquema padrão do espaço de trabalho exigem atualizações de código. Considere a seguinte definição de visão materializada:

CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM raw_data

No modo de publicação herdado, uma leitura não qualificada da tabela raw_data usa o catálogo e o esquema padrão do espaço de trabalho, por exemplo, main.default.raw_data. No novo modo de pipeline padrão, o catálogo e o esquema usados por padrão são aqueles configurados na configuração do pipeline. Para garantir que esse código continue a funcionar conforme o esperado, atualize a referência para usar o identificador totalmente qualificado para a tabela, como no exemplo a seguir:

CREATE MATERIALIZED VIEW silver_table
AS SELECT * FROM main.default.raw_data

Trabalhar com registo de eventos para pipelines no modo de publicação legado do Unity Catalog

Importante

O event_log TVF está disponível para pipelines do modo de publicação antigos que publicam tabelas no Unity Catalog. O comportamento padrão para novos pipelines publica o log de eventos no catálogo de destino e no esquema configurado para o pipeline. Consulte Consultar o log de eventos.

As tabelas configuradas com o metastore do Hive também têm suporte e comportamento diferentes ao log de eventos. Veja Trabalhar com registo de eventos para pipelines do metastore do Hive.

Se o teu pipeline publicar tabelas no Unity Catalog com o modo de publicação antigo, deverás utilizar a função com valor de tabela event_log (TVF) para obter o registo de eventos do pipeline. Você obtém o log de eventos de um pipeline passando o ID do pipeline ou um nome de tabela para o TVF. Por exemplo, para recuperar os registros de log de eventos para o pipeline com ID 04c78631-3dd7-4856-b2a6-7d84e9b2638b:

SELECT * FROM event_log("04c78631-3dd7-4856-b2a6-7d84e9b2638b")

Para recuperar os registos de log de eventos para o pipeline que criou ou possui a tabela my_catalog.my_schema.table1:

SELECT * FROM event_log(TABLE(my_catalog.my_schema.table1))

Para chamar o TVF, você deve usar um cluster compartilhado ou um SQL warehouse. Por exemplo, você pode usar um bloco de anotações anexado a um cluster compartilhado ou usar o editor SQL conectado a um SQL warehouse.

Para simplificar a consulta de eventos para um pipeline, o proprietário do pipeline pode criar uma exibição sobre o event_log TVF. O exemplo a seguir cria uma exibição sobre o log de eventos para um pipeline. Esse modo de exibição é usado nas consultas de log de eventos de exemplo incluídas neste artigo.

Observação

• O event_log TVF só pode ser chamado pelo proprietário do gasoduto.
• Não é possível usar a função tabelada event_log num pipeline ou consulta para aceder aos registos de eventos de vários pipelines.
• Não é possível partilhar uma visualização criada sobre a função com tabela valorada event_log com outros utilizadores.

CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");

Substitua <pipeline-ID> pelo identificador exclusivo do pipeline DLT. Você pode encontrar a ID no painel de detalhes do Pipeline na interface do usuário DLT.

Cada instância de uma execução de pipeline é chamada de atualização de . Muitas vezes, você deseja extrair informações para a atualização mais recente. Execute a consulta a seguir para localizar o identificador da atualização mais recente e salvá-lo no modo de exibição latest_update_id temporário. Esse modo de exibição é usado nas consultas de log de eventos de exemplo incluídas neste artigo:

CREATE OR REPLACE TEMP VIEW latest_update AS SELECT origin.update_id AS id FROM event_log_raw WHERE event_type = 'create_update' ORDER BY timestamp DESC LIMIT 1;