Usar tabelas de transmissão em Databricks SQL

info

Visualização

Esse recurso está em Public Preview.

Databricks recomenda o uso de tabelas de transmissão para ingerir o uso de dados Databricks SQL. Uma tabela de transmissão é uma tabela registrada em Unity Catalog com suporte extra para transmissão ou processamento de dados incrementais. Um DLT pipeline é criado automaticamente para cada tabela de transmissão. O senhor pode usar tabelas de transmissão para carregamento incremental de dados de Kafka e armazenamento de objetos na nuvem.

nota

Para saber como usar as tabelas Delta Lake como fontes e sumidouros de transmissão, consulte Delta table transmission reads and writes.

Requisitos

Para usar as tabelas de transmissão, o senhor deve atender aos seguintes requisitos.

requisitos de espaço de trabalho :

As tabelas de transmissão criadas em Databricks SQL são apoiadas por um serverless DLT pipeline. Seu site workspace deve ser compatível com o pipeline serverless para usar essa funcionalidade.

• Um Databricks account com serverless ativado. Para obter mais informações, consulte Habilitar serverless SQL warehouse.
• Um workspace com Unity Catalog ativado. Para obter mais informações, consulte Configurar e gerenciar Unity Catalog.

requisitos de computação :

Você deve usar um dos seguintes:

• Um SQL warehouse que usa o canal Current.
• computar com o modo de acesso padrão (anteriormente modo de acesso compartilhado) em Databricks Runtime 13.3 LTS ou acima.

Requisitos de permissões :

• USE CATALOG e USE SCHEMA no catálogo e no esquema em que o senhor cria a tabela de transmissão.
• O privilégio CREATE TABLE no esquema em que o senhor cria a tabela de transmissão.
• Privilégios para acessar as tabelas ou locais que fornecem os dados de origem para sua tabela de transmissão.

Criar tabelas de transmissão

Uma tabela de transmissão é definida por uma consulta SQL em Databricks SQL. Quando o senhor cria uma tabela de transmissão, os dados que estão nas tabelas de origem são usados para criar a tabela de transmissão. Depois disso, o senhor refresh a tabela, geralmente em um programa, para extrair quaisquer dados adicionados nas tabelas de origem para anexar à tabela de transmissão.

Ao criar uma tabela de transmissão, o senhor é considerado o proprietário da tabela.

Para criar uma tabela de transmissão a partir de uma tabela existente, use a instruçãoCREATE STREAMING TABLE, como no exemplo a seguir:

SQL

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT product, price FROM STREAM raw_data;

Nesse caso, a tabela de transmissão sales é criada a partir de colunas específicas da tabela raw_data, com um programar para refresh a cada hora. A consulta usada deve ser uma consulta de transmissão . Use a palavra-chave STREAM para usar a semântica de transmissão para ler a partir da fonte.

Quando o senhor cria uma tabela de transmissão usando a instrução CREATE OR REFRESH STREAMING TABLE, os dados iniciais refresh e a população começam imediatamente. Essas operações não consomem o DBSQL warehouse compute. Em vez disso, a tabela de transmissão depende de serverless DLT tanto para a criação quanto para refresh. Um site dedicado serverless DLT pipeline é criado automaticamente e gerenciado pelo sistema para cada tabela de transmissão.

Carregar arquivos com o Auto Loader

Para criar uma tabela de transmissão a partir de arquivos em um volume, use Auto Loader. Use Auto Loader com DLT para a maioria das tarefas de ingestão de dados do armazenamento de objetos na nuvem. O Auto Loader e o DLT foram projetados para carregar de forma incremental e idempotente dados cada vez maiores à medida que eles chegam ao armazenamento em nuvem.

Para usar o Auto Loader no Databricks SQL, use a função read_files. Os exemplos a seguir mostram o uso do site Auto Loader para ler um volume de arquivos JSON em uma tabela de transmissão:

SQL

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT * FROM STREAM read_files(
    "/Volumes/my_catalog/my_schema/my_volume/path/to/data",
    format => "json"
  );

Para ler dados do armazenamento em nuvem, o senhor também pode usar o Auto Loader:

SQL

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    'gs://mybucket/analysis/*/*/*.json',
    format => "json"
  );

Para saber mais sobre o Auto Loader, consulte O que é o Auto Loader? Para saber mais sobre o uso do Auto Loader no SQL, com exemplos, consulte Carregar dados do armazenamento de objetos.

transmissão ingestão de outras fontes

Para obter um exemplo de ingestão de outras fontes, incluindo Kafka, consulte Carregar dados com DLT.

Ingira somente novos dados

Em default, a função read_files lê todos os dados existentes no diretório de origem durante a criação da tabela e, em seguida, processa os registros recém-chegados a cada refresh.

Para evitar a ingestão de dados que já existem no diretório de origem no momento da criação da tabela, defina a opção includeExistingFiles como false. Isso significa que somente os dados que chegam ao diretório após a criação da tabela são processados. Por exemplo:

SQL

CREATE OR REFRESH STREAMING TABLE sales
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM read_files(
    '/path/to/files',
    includeExistingFiles => false
  );

Definir o canal de tempo de execução

As tabelas de transmissão criadas usando o warehouse SQL são atualizadas automaticamente usando um DLT pipeline. DLT O pipeline usa o tempo de execução no canal current por default. Consulte DLT notas sobre a versão e o processo de upgrade de versão para saber mais sobre o processo de versão.

A Databricks recomenda o uso do canal current para cargas de trabalho de produção. Novos recursos são liberados primeiro no canal preview. O senhor pode definir um pipeline para o canal DLT de visualização para testar o novo recurso especificando preview como uma propriedade de tabela. Você pode especificar essa propriedade ao criar a tabela ou após a criação da tabela usando uma instrução ALTER.

O exemplo de código a seguir mostra como definir o canal para visualização em uma instrução CREATE:

SQL

CREATE OR REFRESH STREAMING TABLE sales
  TBLPROPERTIES ('pipelines.channel' = 'preview')
  SCHEDULE EVERY 1 hour
  AS SELECT *
  FROM STREAM raw_data;

Ocultar dados confidenciais

info

Visualização

Esse recurso está em Public Preview.

O senhor pode usar tabelas de transmissão para ocultar dados confidenciais dos usuários que acessam a tabela. Uma abordagem é definir a consulta de forma que ela exclua totalmente as colunas ou linhas confidenciais. Como alternativa, você pode aplicar máscaras de coluna ou filtros de linha com base nas permissões do usuário que está consultando. Por exemplo, você pode ocultar a coluna tax_id para usuários que não estão no grupo HumanResourcesDept. Para fazer isso, use a sintaxe ROW FILTER e MASK durante a criação da tabela de transmissão. Para obter mais informações, consulte Filtro sensível à tabela uso de dados filtros de linha e máscaras de coluna.

atualizar a tabela de transmissão

A atualização pode ser agendada automaticamente quando o senhor cria a tabela de transmissão. O senhor também pode refresh manualmente as tabelas de transmissão. Mesmo que o senhor tenha um refresh agendado, pode chamar um refresh manual a qualquer momento. são tratadas pelo mesmo pipeline que foi criado automaticamente junto com a tabela de transmissão.

Para refresh uma tabela de transmissão:

SQL

REFRESH STREAMING TABLE sales;

O senhor pode verificar o status do último refresh com DESCRIBE TABLE EXTENDED.

nota

Somente o proprietário da tabela pode refresh uma tabela de transmissão para obter os dados mais recentes. O usuário que cria a tabela é o proprietário, e o proprietário não pode ser alterado. Talvez o senhor precise acessar refresh a tabela de transmissão antes de usar as consultas de viagem do tempo.

Como funciona o site refresh

Uma tabela de transmissão refresh avalia somente as novas linhas que chegaram desde a última atualização e anexa somente os novos dados.

Cada refresh usa a definição atual da tabela de transmissão para processar esses novos dados. A modificação da definição de uma tabela de transmissão não recalcula automaticamente os dados existentes. Se uma modificação for incompatível com os dados existentes (por exemplo, alterar um tipo de dados), o próximo refresh falhará com um erro.

Os exemplos a seguir explicam como as alterações em uma definição de tabela de transmissão afetam o comportamento do site refresh:

• A remoção de um filtro não reprocessará as linhas filtradas anteriormente.
• Alterar as projeções das colunas não afetará a forma como os dados existentes foram processados.
• As uniões com Snapshot estático usam o estado do Snapshot no momento do processamento inicial. Os dados que chegarem tardiamente e que corresponderiam ao Snapshot atualizado serão ignorados. Isso pode fazer com que os fatos sejam descartados se as dimensões estiverem atrasadas.
• Modificar o CAST de uma coluna existente resultará em um erro.

Se seus dados forem alterados de uma forma que não possa ser suportada na tabela de transmissão existente, o senhor poderá executar um refresh completo.

Totalmente refresh a mesa de transmissão

A atualização completa processa novamente todos os dados disponíveis na fonte com a definição mais recente. Não é recomendável chamar a atualização completa em fontes que não mantêm todo o histórico dos dados ou que têm períodos de retenção curtos, como Kafka, porque a atualização completa refresh trunca os dados existentes. Talvez você não consiga recuperar dados antigos se eles não estiverem mais disponíveis na fonte.

Por exemplo:

SQL

REFRESH STREAMING TABLE sales FULL;

Alterar o programar para uma tabela de transmissão

O senhor pode modificar (ou definir) um refresh programar automático para sua tabela de transmissão. Os exemplos a seguir mostram como definir um programar usando ALTER STREAMING TABLE:

SQL

ALTER STREAMING TABLE sales
  ADD SCHEDULE every 1 hour;

Para obter exemplos de consultas do programa refresh, consulte ALTER STREAMING TABLE.

Acompanhe o status de um refresh

O senhor pode view o status de uma tabela de transmissão refresh visualizando o pipeline que gerencia a tabela de transmissão na interface do usuário DLT ou visualizando as informações de atualização retornadas pelo DESCRIBE EXTENDED comando para a tabela de transmissão.

SQL

DESCRIBE TABLE EXTENDED <table-name>;

Como alternativa, o senhor pode acessar view a tabela de transmissão no Catalog Explorer e ver o status de refresh:

1. Clique em Catálogo na barra lateral.
2. Na árvore Catalog Explorer, à esquerda, abra o catálogo e selecione o esquema em que a tabela de transmissão está localizada.
3. Abra o item Tables (Tabelas ) no esquema que o senhor selecionou e clique na tabela de transmissão.

A partir daí, o senhor pode usar a guia abaixo do nome da tabela de transmissão para view e editar informações sobre a tabela de transmissão, inclusive:

• status de atualização e histórico
• O esquema da tabela
• Dados de amostra (requer um site ativo compute)
• Permissões
• Linhagem, incluindo tabelas e pipeline dos quais essa tabela de transmissão depende
• percepções em uso
• Monitores que o senhor criou para essa tabela de transmissão

Controle o acesso às tabelas de transmissão

As tabelas de transmissão oferecem suporte a controles de acesso avançados para o compartilhamento de dados, evitando a exposição de dados potencialmente privados. O proprietário de uma tabela de transmissão ou um usuário com o privilégio MANAGE pode conceder privilégios SELECT a outros usuários. Os usuários com acesso SELECT à tabela de transmissão não precisam de acesso SELECT às tabelas referenciadas pela tabela de transmissão. Esse controle de acesso permite o compartilhamento de dados e, ao mesmo tempo, controla o acesso aos dados subjacentes.

Conceder privilégios a uma tabela de transmissão

Para conceder acesso a uma tabela de transmissão, use a instruçãoGRANT:

SQL

GRANT <privilege_type> ON <st_name> TO <principal>;

O privilege_type pode ser:

• SELECT - o usuário pode SELECT a tabela de transmissão.
• REFRESH - o usuário pode REFRESH a tabela de transmissão. As atualizações são executadas usando as permissões do proprietário.

O exemplo a seguir cria uma tabela de transmissão e concede privilégios de seleção e refresh aos usuários:

SQL

CREATE MATERIALIZED VIEW st_name AS SELECT * FROM source_table;

-- Grant read-only access:
GRANT SELECT ON st_name TO read_only_user;

-- Grand read and refresh access:
GRANT SELECT ON st_name TO refresh_user;
GRANT REFRESH ON st_name TO refresh_user;

Para obter mais informações sobre a concessão de privilégios em Unity Catalog objetos protegidos, consulte Unity Catalog privileges and securable objects.

Revogar privilégios de uma tabela de transmissão

Para revogar o acesso de uma tabela de transmissão, use a instruçãoREVOKE:

SQL

REVOKE privilege_type ON <st_name> FROM principal;

Quando os privilégios de SELECT em uma tabela de origem são revogados do proprietário da tabela de transmissão ou de qualquer outro usuário que tenha recebido privilégios de MANAGE ou SELECT na tabela de transmissão, ou quando a tabela de origem é descartada, o proprietário da tabela de transmissão ou o usuário ao qual foi concedido acesso ainda pode consultar a tabela de transmissão. No entanto, ocorre o seguinte comportamento:

• O proprietário da tabela de transmissão ou outras pessoas que perderam o acesso a uma tabela de transmissão não podem mais REFRESH essa tabela de transmissão, e a tabela de transmissão se tornará obsoleta.
• Se automatizado com um programar, o próximo programar REFRESH falha ou não é executado.

O exemplo a seguir revoga o privilégio SELECT de read_only_user:

SQL

REVOKE SELECT ON st_name FROM read_only_user;

Excluir permanentemente registros de uma tabela de transmissão

info

Visualização

O suporte para a declaração REORG com tabelas de transmissão está em Public Preview.

nota

• O uso de uma declaração REORG com uma tabela de transmissão requer Databricks Runtime 15.4 e acima.
• Embora seja possível usar a instrução REORG com qualquer tabela de transmissão, ela só é necessária ao excluir registros de uma tabela de transmissão com vetores de exclusão ativados. O comando não tem efeito quando usado com uma tabela de transmissão sem vetores de exclusão ativados.

Para excluir fisicamente os registros do armazenamento subjacente de uma tabela de transmissão com vetores de exclusão ativados, como no caso do site GDPR compliance, é necessário tomar medidas adicionais para garantir que uma vacuum operações executadas nos dados da tabela de transmissão.

Para excluir fisicamente os registros do armazenamento subjacente:

1. Atualizar registros ou excluir registros da tabela de transmissão.
2. executar uma instrução REORG na tabela de transmissão, especificando o parâmetro APPLY (PURGE). Por exemplo, REORG TABLE <streaming-table-name> APPLY (PURGE);.
3. Aguarde o término do período de retenção de dados da tabela de transmissão. O período de retenção de dados do default é de sete dias, mas pode ser configurado com a propriedade da tabela delta.deletedFileRetentionDuration. Consulte Configurar a retenção de dados para consultas de viagem do tempo.
4. REFRESH a tabela de transmissão. Consulte atualizar uma tabela de transmissão. Dentro de 24 horas após as REFRESH operações, DLT tarefas de manutenção, incluindo as VACUUM operações necessárias para garantir que os registros sejam permanentemente excluídos, são executadas automaticamente.

Monitorar a execução usando o histórico de consultas

O senhor pode usar a página de histórico de consultas para acessar detalhes e perfis de consultas que podem ajudá-lo a identificar consultas com baixo desempenho e gargalos no site DLT pipeline usado para executar as atualizações da tabela de transmissão. Para obter uma visão geral do tipo de informação disponível no histórico de consultas e nos perfis de consultas, consulte Histórico de consultas e Perfil de consultas.

info

Visualização

Esse recurso está em Public Preview. Os administradores do espaço de trabalho podem ativar esse recurso na página Pré-visualizações . Veja gerenciar Databricks Previews.

Todas as declarações relacionadas às tabelas de transmissão aparecem no histórico de consultas. O senhor pode usar o filtro suspenso Statement (Declaração ) para selecionar qualquer comando e inspecionar as consultas relacionadas. Todas as declarações CREATE são seguidas por uma declaração REFRESH que é executada de forma assíncrona em um pipeline DLT. As declarações do REFRESH normalmente incluem planos de consulta detalhados que fornecem percepções sobre a otimização do desempenho.

Para acessar as declarações do REFRESH na interface do usuário da história da consulta, siga as etapas abaixo:

1. Clique em na barra lateral esquerda para abrir a Query History UI.
2. Selecione a caixa de seleção REFRESH no filtro suspenso Statement (Declaração ).
3. Clique no nome da instrução de consulta para acessar view detalhes resumidos, como a duração da consulta e as métricas agregadas.
4. Clique em Ver perfil de consulta para abrir o perfil de consulta. Consulte Perfil de consulta para obter detalhes sobre como navegar pelo perfil de consulta.
5. Opcionalmente, é possível usar os links na seção Fonte da consulta para abrir a consulta ou o pipeline relacionado.

O senhor também pode acessar os detalhes da consulta usando links no editor SQL ou em um Notebook anexado a um SQL warehouse.

Recurso adicional

• DLT
• read_files função com valor de tabela
• read_kafka função com valor de tabela
• CREATE STREAMING TABLE
• ALTER STREAMING TABLE
• Usar visualizações materializadas no Databricks SQL