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

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

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

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

O Delta Live Tables tem uma alternância de interface do usuário para controlar se as atualizações de pipeline são executadas no modo de desenvolvimento ou produção. Esse modo controla como as atualizações do 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 que um cluster seja iniciado.
• O modo de desenvolvimento não repete automaticamente em caso de falha da tarefa, permitindo que você detecte e corrija erros lógicos ou sintáticos em seu pipeline imediatamente.

O Databricks recomenda usar o 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.

Confira os Modos de desenvolvimento e produção.

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

Para verificar problemas no código-fonte do seu pipeline, como erros de sintaxe e análise, durante o desenvolvimento e testes, você pode executar uma Validação de atualização. Como uma atualização de Validate apenas verifica a exatidã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 real do pipeline.

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

Todos os conjuntos de dados em um pipeline do 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 LIVE apontará para o esquema de destino. Você deve especificar um esquema de destino para revisar os resultados gravados em cada tabela durante uma atualização.

É necessário especificar um esquema de destino 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 que você remova a logica que utiliza interpolação da cadeia de caracteres ou outros widgets ou parâmetros para controlar as fontes de dados e os destinos.

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

Usar as pastas Git do Databricks para gerenciar os pipelines do Delta Live Tables

O Databricks recomenda usar as pastas Git durante o desenvolvimento, teste e implantação de pipeline do Delta Live Tables para produção. As pastas Git habilitam o seguinte:

• Manter o controle de como o código está sendo alterado 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.

A Databricks recomenda configurar um único repositório Git para todo o código relacionado a um pipeline.

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

O branch resultante deve ser verificado em uma pasta Git do Databricks e um pipeline deve ser configurado usando conjuntos de dados de teste e um esquema de desenvolvimento. Supondo que a logica seja executada conforme o esperado, uma solicitação de pull ou ramificação de versão deve ser preparada para efetuar push das alterações para a produção.

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

Esse fluxo de trabalho é semelhante ao uso das 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 etapas de assimilação e transformação

O Databricks recomenda isolar as consultas que ingerem dados da logica de transformação que enriquece e valida os dados. Se você organizar o código-fonte para ingerir 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 teste. Consulte Criar conjuntos de dados de amostra para desenvolvimento e teste.

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

Como os pipelines do Delta Live Tables usam o LIVE esquema virtual para gerenciar todas as relações do 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 utilizada em todos os ambientes.

Criar conjuntos de dados de amostra 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. Existem várias maneiras de criar conjuntos de dados que podem ser úteis para desenvolvimento e teste, incluindo as seguintes:

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

Por exemplo, se você tiver um notebook que define um conjunto de dados usando o código a seguir:

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

Você deve criar um conjunto de dados de amostra contendo registros específicos utilizando 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 dos 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 conjuntos de dados diferentes, crie vários pipelines com os notebooks implementando a lógica de transformação. Cada pipeline pode ler dados a partir do conjunto de dados LIVE.input_data, mas está configurado para incluir o notebook que criar o conjunto de dados específico do ambiente.