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.
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?
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.
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:
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:
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
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
:
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
:
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.
- 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
.
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:
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;