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

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

A 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, o senhor pode apontar o pipeline para dados de teste com problemas conhecidos para testar a resiliência do código. Consulte Controlar fonte de dados com parâmetros.

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

Delta Live Tables tem um botão de alternância na interface do usuário para controlar se a execução das atualizações do pipeline está no modo de desenvolvimento ou de produção. Esse modo controla como as atualizações do pipeline são processadas, inclusive:

  • O modo de desenvolvimento não encerra imediatamente o compute recurso depois que uma atualização é bem-sucedida ou falha. O senhor pode reutilizar o mesmo recurso compute para executar várias atualizações pipeline sem esperar que uma cluster comece.

  • O modo de desenvolvimento não tenta novamente de forma automática em caso de falha na tarefa, o que permite detectar e corrigir imediatamente erros lógicos ou sintáticos no pipeline.

A Databricks recomenda o uso do modo de desenvolvimento durante o desenvolvimento e os testes. No entanto, quando for implantado em um ambiente de produção, sempre mude para o modo de produção.

Consulte Modos de desenvolvimento e produção.

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

Para verificar problemas com o código-fonte do pipeline, como erros de sintaxe e análise, durante o desenvolvimento e teste, você pode executar um Validate update. Como uma atualização Validate verifica apenas 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.

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

Todos os conjuntos de dados em um Delta Live Tables pipeline fazem referência ao esquema virtual LIVE, 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.

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

O senhor pode isolar esses ambientes criando um pipeline separado para desenvolvimento, teste e produção com alvos diferentes. O uso do parâmetro target schema permite que o senhor remova a lógica que usa interpolação de strings ou outros widgets ou parâmetros para controlar fontes de dados e alvos.

Consulte Usar Unity Catalog com seu pipeline Delta Live Tables e Usar o pipeline Delta Live Tables com o legado Hive metastore.

Use as pastas Git do Databricks para gerenciar o pipeline do Delta Live Tables

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

  • Acompanhar como o código está mudando ao longo do tempo.

  • Mesclando as mudanças que vários desenvolvedores estão fazendo.

  • Práticas de desenvolvimento de software, como revisões de código.

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 da Databricks configurada para desenvolvimento. Durante o desenvolvimento, o usuário configura seu próprio pipeline na pasta Databricks Git e testa a nova lógica usando o conjunto de dados de desenvolvimento, o esquema isolado e os locais. Depois de concluir o trabalho de desenvolvimento, o usuário faz o commit 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.

O branch resultante deve ser verificado em uma pasta Databricks Git e um pipeline deve ser configurado usando um conjunto de dados de teste e um esquema de desenvolvimento. Supondo que a lógica seja executada conforme o esperado, um pull request ou branch de liberação deve ser preparado para enviar as alterações para a produção.

Embora as pastas do Git possam ser usadas para sincronizar o código entre os ambientes, as configurações do 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 as técnicas de CI/CD com pastas Git e Databricks Git (Repos).

Código-fonte do segmento para ingestão e transformações dos passos

Databricks recomenda isolar as consultas que ingerem dados da lógica de transformações que enriquece e valida os dados. Se o senhor organizar o código-fonte para ingestão de dados de desenvolvimento ou teste de fonte de dados em um diretório separado da lógica de ingestão de dados de produção, poderá configurar o pipeline para vários ambientes com um conjunto de dados específico para esses ambientes. Por exemplo, o senhor pode acelerar o desenvolvimento usando um conjunto de dados menor para testes. Consulte Criar conjunto de dados de amostra para desenvolvimento e teste.

O senhor também pode usar parâmetros para controlar a fonte de dados para desenvolvimento, teste e produção. Consulte Usar parâmetros com o pipeline Delta Live Tables .

Como o pipeline Delta Live Tables usa o esquema virtual LIVE para gerenciar todos os relacionamentos dataset, ao configurar o pipeline de desenvolvimento e teste com o código-fonte de ingestão que carrega dados de amostra, o senhor pode substituir o conjunto de dados de amostra usando nomes de tabelas de produção para testar o código. A mesma lógica de transformações pode ser usada em todos os ambientes.

Crie conjuntos de dados de amostra para desenvolvimento e teste

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 as seguintes:

  • Selecione um subconjunto de dados de um dataset de produção.

  • Use dados anônimos ou gerados artificialmente para fontes que contenham PII.

  • Crie dados de teste com resultados bem definidos com base na lógica downstream das transformações.

  • Antecipe a possível 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 Notebook que defina um dataset usando o seguinte código:

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

Você pode criar um dataset de amostra contendo registros específicos usando uma query 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 dataset, crie vários pipelines com o Notebook implementando a lógica das transformações. Cada pipeline pode ler dados do dataset LIVE.input_data, mas é configurado para incluir o Notebook que cria o dataset específico para o ambiente.