Dicas, recomendações e recursos para desenvolver e testar pipelines Delta Live Tables

Este artigo descreve padrões que você pode usar para desenvolver e testar pipelines Delta Live Tables. Por meio das configurações de pipeline, o Delta Live Tables permite especificar configurações para isolar pipelines em ambientes de desenvolvimento, teste e produção. As recomendações deste artigo aplicam-se ao desenvolvimento de código SQL e Python.

O Databricks recomenda o uso de parâmetros para escrever código extensível de Delta Live Tables. Isso é especialmente útil para escrever código portátil entre ambientes dev, test e prod. Por exemplo, você pode apontar seus pipelines para dados de teste com problemas conhecidos para testar a resiliência do código. Consulte Controlar fontes de dados com parâmetros.

Usar o modo de desenvolvimento para executar atualizações de pipeline

O Delta Live Tables tem uma alternância de interface do usuário para controlar se as atualizações do pipeline são executadas no modo de desenvolvimento ou produção. Este modo controla como as atualizações de pipeline são processadas, incluindo:

• O modo de desenvolvimento não encerra imediatamente os recursos de computação depois que uma atualização é bem-sucedida ou falha. Você pode reutilizar os mesmos recursos de computação para executar várias atualizações de pipeline sem esperar pelo início de um cluster.
• O modo de desenvolvimento não tenta novamente automaticamente em caso de falha de tarefa, permitindo que você detete e corrija erros lógicos ou sintáticos em seu pipeline imediatamente.

O Databricks recomenda o uso do modo de desenvolvimento durante o desenvolvimento e o teste. No entanto, ao implantar em um ambiente de produção, sempre alterne para o modo de produção.

Consulte Modos de desenvolvimento e produção.

Teste o código-fonte do pipeline sem esperar pela atualização das tabelas

Para verificar se há problemas com o código-fonte do pipeline, como erros de sintaxe e análise, durante o desenvolvimento e o teste, você pode executar uma atualização Validar. Como uma Validate atualização apenas verifica a correção do código-fonte do pipeline sem executar uma atualização real em nenhuma tabela, você pode identificar e corrigir problemas mais rapidamente antes de executar uma atualização de pipeline real.

Especificar um esquema de destino durante todas as fases do ciclo de vida do desenvolvimento

Todos os conjuntos de dados em um pipeline Delta Live Tables fazem referência ao LIVE esquema virtual, que é inacessível fora do pipeline. Se um esquema de destino for especificado, o esquema virtual apontará LIVE para o esquema de destino. Você deve especificar um esquema de destino para revisar os resultados gravados em cada tabela durante uma atualização.

Você deve especificar um esquema de destino que seja exclusivo para seu ambiente. Cada tabela em um determinado esquema só pode ser atualizada por um único pipeline.

Você pode isolar esses ambientes criando pipelines separados para desenvolvimento, teste e produção com destinos diferentes. O uso do parâmetro de esquema de destino permite remover a lógica que usa interpolação de cadeia de caracteres ou outros widgets ou parâmetros para controlar fontes de dados e destinos.

Consulte Usar o catálogo Unity com seus pipelines Delta Live Tables e Usar pipelines Delta Live Tables com metastore herdado do Hive.

Usar pastas Git Databricks para gerenciar pipelines Delta Live Tables

O Databricks recomenda o uso de pastas Git durante o desenvolvimento, teste e implantação do pipeline Delta Live Tables na produção. As pastas Git permitem o seguinte:

• Acompanhar como o código está mudando ao longo do tempo.
• Mesclando alterações que vários desenvolvedores estão fazendo.
• Práticas de desenvolvimento de software, como revisões de código.

O Databricks recomenda a configuração de um único repositório Git para todo o código relacionado a um pipeline.

Cada desenvolvedor deve ter sua própria pasta Databricks Git configurada para desenvolvimento. Durante o desenvolvimento, o usuário configura seu próprio pipeline a partir de sua pasta Databricks Git e testa a nova lógica usando conjuntos de dados de desenvolvimento e esquemas e locais isolados. Depois de concluir o trabalho de desenvolvimento, o usuário confirma e envia as alterações de volta para sua ramificação no repositório central do Git e abre uma solicitação pull na ramificação de teste ou QA.

A ramificação resultante deve ser verificada em uma pasta Databricks Git e um pipeline deve ser configurado usando conjuntos de dados de teste e um esquema de desenvolvimento. Supondo que a lógica seja executada conforme o esperado, uma ramificação de solicitação pull ou liberação deve estar preparada para enviar as alterações para a produção.

Embora as pastas Git possam ser usadas para sincronizar código entre ambientes, as configurações de pipeline devem ser mantidas atualizadas manualmente ou usando ferramentas como o Terraform.

Esse fluxo de trabalho é semelhante ao uso de pastas Git para CI/CD em todos os trabalhos do Databricks. Consulte Técnicas de CI/CD com pastas Git e Databricks Git (Repos).

Segmentar o código-fonte para as etapas de ingestão e transformação

O Databricks recomenda isolar consultas que ingerem dados da lógica de transformação que enriquece e valida dados. Se você organizar o código-fonte para a ingestão de dados de fontes de dados de desenvolvimento ou teste em um diretório separado da lógica de ingestão de dados de produção, poderá configurar pipelines para vários ambientes com conjuntos de dados específicos para esses ambientes. Por exemplo, você pode acelerar o desenvolvimento usando conjuntos de dados menores para testes. Consulte Criar conjuntos de dados de exemplo para desenvolvimento e teste.

Você também pode usar parâmetros para controlar fontes de dados para desenvolvimento, teste e produção. Consulte Usar parâmetros com pipelines Delta Live Tables.

Como os pipelines Delta Live Tables usam o LIVE esquema virtual para gerenciar todos os relacionamentos de conjunto de dados, configurando pipelines de desenvolvimento e teste com código-fonte de ingestão que carrega dados de exemplo, você pode substituir conjuntos de dados de exemplo usando nomes de tabela de produção para testar o código. A mesma lógica de transformação pode ser usada em todos os ambientes.

Criar conjuntos de dados de exemplo para desenvolvimento e teste

O Databricks recomenda a criação de conjuntos de dados de desenvolvimento e teste para testar a lógica do pipeline com dados esperados e registros potencialmente malformados ou corrompidos. Há várias maneiras de criar conjuntos de dados que podem ser úteis para desenvolvimento e teste, incluindo o seguinte:

• Selecione um subconjunto de dados de um conjunto de dados de produção.
• Use dados anonimizados ou gerados artificialmente para fontes que contenham PII.
• Crie dados de teste com resultados bem definidos com base na lógica de transformação downstream.
• Antecipe possíveis corrupção de dados, registros malformados e alterações de dados upstream criando registros que quebram as expectativas do esquema de dados.

Por exemplo, se você tiver um bloco de anotações que define um conjunto de dados usando o seguinte código:

CREATE OR REFRESH STREAMING TABLE input_data AS SELECT * FROM read_files("/production/data", "json")

Você pode criar um conjunto de dados de exemplo contendo registros específicos usando uma consulta como a seguinte:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS
SELECT "2021/09/04" AS date, 22.4 as sensor_reading UNION ALL
SELECT "2021/09/05" AS date, 21.5 as sensor_reading

O exemplo a seguir demonstra a filtragem de dados publicados para criar um subconjunto dos dados de produção para desenvolvimento ou teste:

CREATE OR REFRESH MATERIALIZED VIEW input_data AS SELECT * FROM prod.input_data WHERE date > current_date() - INTERVAL 1 DAY

Para usar esses diferentes conjuntos de dados, crie vários pipelines com os blocos de anotações implementando a lógica de transformação. Cada pipeline pode ler dados do conjunto de dados, LIVE.input_data mas está configurado para incluir o bloco de anotações que cria o conjunto de dados específico para o ambiente.