Pular para o conteúdo principal

Esquema LIVE (legado)

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

O esquema virtual LIVE é um recurso legado do pipeline DLT e é considerado obsoleto. O senhor ainda pode usar o modo de publicação herdado e o esquema virtual LIVE para o pipeline que foi criado com esse modo.

O suporte ao esquema virtual LIVE legado e ao modo de publicação legado será removido em uma versão futura do Databricks.

nota

O pipeline do modo de publicação legado é indicado no campo Summary (Resumo ) da UI de configurações do DLT pipeline. O senhor também pode confirmar que um pipeline usa o modo de publicação herdado se o campo target estiver definido na especificação JSON do pipeline.

O senhor não pode usar a UI de configuração do pipeline para criar um novo pipeline com o modo de publicação herdado. Se o senhor precisar implantar um novo pipeline usando a sintaxe LIVE legada, entre em contato com o representante do Databricks account .

O que é o esquema virtual LIVE?

nota

O esquema virtual LIVE não é mais necessário para analisar a dependência de dataset no modo de publicação default 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 definição, o esquema LIVE não está vinculado diretamente ao conjunto 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 o conjunto de dados em um esquema.

No pipeline do modo de publicação herdado, o senhor pode usar a palavra-chave LIVE para fazer referência a outro conjunto de dados no site pipeline atual para leituras, por exemplo, SELECT * FROM LIVE.bronze_table. No modo de publicação default para o novo pipeline DLT, essa sintaxe é silenciosamente ignorada, o que significa que os identificadores não qualificados usam o esquema atual. Consulte Definir o catálogo e o esquema de destino.

Modo de publicação legado para pipeline

O esquema virtual LIVE é usado com o modo de publicação herdado para o pipeline DLT. Todas as tabelas criadas antes de 5 de fevereiro de 2025 usam o modo de publicação legado pelo site default.

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

Opção de armazenamento

Local de armazenamento ou catálogo

Esquema de destino

Comportamento

Hive metastore

Nenhum especificado

Nenhum especificado

Os metadados e dados do conjunto de dados são armazenados no site DBFS root. Nenhum objeto de banco de dados está registrado no site Hive metastore.

Hive metastore

Um URI ou caminho de arquivo para o armazenamento de objetos na nuvem.

Nenhum especificado

Os metadados e dados do conjunto de dados são armazenados no local de armazenamento especificado. Nenhum objeto de banco de dados está registrado no site Hive metastore.

Hive metastore

Nenhum especificado

Um esquema existente ou novo no site Hive metastore.

Os metadados e dados do conjunto de dados são armazenados no site DBFS root. Todas as visualizações materializadas e tabelas de transmissão no site pipeline são publicadas no esquema especificado em Hive metastore.

Hive metastore

Um URI ou caminho de arquivo para o armazenamento de objetos na nuvem.

Um esquema existente ou novo no site Hive metastore.

Os metadados e dados do conjunto de dados são armazenados no local de armazenamento especificado. Todas as visualizações materializadas e tabelas de transmissão no site pipeline são publicadas no esquema especificado em Hive metastore.

Unity Catalog

Um catálogo existente do Unity Catalog.

Nenhum especificado

Os metadados e dados do conjunto de dados são armazenados no local de armazenamento default associado ao catálogo de destino. Nenhum objeto de banco de dados está registrado no Unity Catalog.

Unity Catalog

Um catálogo existente do Unity Catalog.

Um esquema existente ou novo no Unity Catalog.

Os metadados e dados do conjunto de dados são armazenados no local de armazenamento default associado ao esquema ou catálogo de destino. Todas as visualizações materializadas e tabelas de transmissão no site pipeline são publicadas no esquema especificado em Unity Catalog.

Atualize o código-fonte do esquema LIVE

O pipeline configurado para execução com o novo modo de publicação default ignora silenciosamente a sintaxe do esquema LIVE. Em default, todas as leituras de tabela usam o catálogo e o esquema especificados na configuração pipeline.

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

important

O código legado com leituras que utilizam o catálogo e o esquema workspace default exige atualizações de código. Considere a seguinte definição de view materializado:

SQL
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 workspace default , por exemplo, main.default.raw_data. No novo modo default pipeline , o catálogo e o esquema usados pelo default são aqueles configurados na configuração pipeline. Para garantir que esse código continue funcionando conforme o esperado, atualize a referência para usar o identificador totalmente qualificado para a tabela, como no exemplo a seguir:

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

Trabalhar com o evento log para o pipeline do modo de publicação legado Unity Catalog

important

O event_log TVF está disponível para o pipeline do modo de publicação herdado que publica tabelas em Unity Catalog. O comportamento padrão do novo pipeline publica o evento log no catálogo de destino e no esquema configurado para o pipeline. Consulte Consultar o evento log.

As tabelas configuradas com Hive metastore também têm suporte e comportamento diferentes para o evento log. Consulte Trabalhar com o evento log para o pipeline Hive metastore.

Se o seu pipeline publicar tabelas no Unity Catalog com o modo de publicação herdado, o senhor deverá usar a função de valor de tabela (TVF) event_log para buscar o log de eventos do pipeline. O senhor recupera 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 do log de eventos do pipeline com ID 04c78631-3dd7-4856-b2a6-7d84e9b2638b:

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

Para recuperar os registros de log de eventos do pipeline que criou ou possui a tabela my_catalog.my_schema.table1:

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

Para chamar o TVF, o senhor deve usar um clustering compartilhado ou um SQL warehouse. Por exemplo, o senhor pode usar um Notebook anexado a um clustering compartilhado ou usar o editorSQL conectado a um SQL warehouse.

Para simplificar a consulta de eventos para um pipeline, o proprietário do pipeline pode criar um view sobre o event_log TVF. O exemplo a seguir cria um view sobre o evento log para um pipeline. Esse view é usado no exemplo de consultas do evento log incluídas neste artigo.

nota
  • O event_log TVF só pode ser chamado pelo proprietário do pipeline.
  • O senhor não pode usar a função event_log table valued em um pipeline ou consulta para acessar o evento logs de vários pipelines.
  • O senhor não pode compartilhar com outros usuários um view criado na função de valor da tabela event_log.
SQL
CREATE VIEW event_log_raw AS SELECT * FROM event_log("<pipeline-ID>");

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

Cada instância de uma execução de pipeline é chamada de atualização . O senhor geralmente deseja extrair informações para a atualização mais recente. Execute a consulta a seguir para encontrar o identificador da atualização mais recente e salve-o na pasta temporária latest_update_id view. Esse view é usado no exemplo de consultas do evento log incluídas neste artigo:

SQL
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;