Dicas, recomendações e recursos para desenvolver e testar o pipeline 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 que você especifique configurações para isolar pipelines em ambientes de desenvolvimento, teste e produção. As recomendações neste artigo são aplicáveis para desenvolvimento de código SQL e Python.

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

Delta Live Tables fornece uma alternância de interface do usuário para controlar se o pipeline atualiza a execução 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 compute após uma atualização bem-sucedida ou falha. Você pode reutilizar os mesmos recursos compute para executar várias atualizações do pipeline sem esperar que os clusters comecem.

  • O modo de desenvolvimento não repete automaticamente a falha da tarefa, permitindo que você detecte e corrija imediatamente erros lógicos ou sintáticos em seu pipeline.

Databricks recomenda usar o modo de desenvolvimento durante o desenvolvimento e teste e sempre alternar para o modo de produção ao atualizar para um ambiente 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 dataset em um pipeline Delta Live Tables fazem referência ao esquema virtual LIVE, que não pode ser acessado fora do pipeline. Se um esquema de destino for especificado, o esquema virtual LIVE apontará para o esquema de destino. Para revisar os resultados gravados em cada tabela durante uma atualização, você deve especificar um esquema de destino.

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.

Ao criar pipelines separados para desenvolvimento, teste e produção com destinos diferentes, você pode manter esses ambientes isolados. O uso do parâmetro de esquema de destino permite remover a lógica que usa interpolação strings ou outros widgets ou parâmetros para controlar a fonte de dados e destinos.

Consulte Publicar dados de pipelines Delta Live Tables no 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.

  • Mesclar alterações que estão sendo feitas por vários desenvolvedores.

  • 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 a partir da pasta Git do Databricks e testa a nova lógica usando o conjunto de dados de desenvolvimento, o esquema isolado e os locais. À medida que o trabalho de desenvolvimento é concluído, 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.

A ramificação resultante deve ser verificada em uma pasta Git do Databricks e um pipeline 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 precisam 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).

Biblioteca de segmentos para ingestão e quedas de passos

Databricks recomenda isolar query que ingere dados da lógica que evoluiu e que enriquece e valida os dados. Em seguida, você pode organizar as bibliotecas usadas para ingerir dados de desenvolvimento ou testar a fonte de dados em um diretório separado da lógica de ingestão de dados de produção, permitindo que você configure facilmente pipelines para vários ambientes. Você pode então usar dataset menor para testar, acelerando o desenvolvimento. Consulte Criar dataset de amostra para desenvolvimento e teste.

Você também pode usar parâmetros para controlar a fonte de dados para desenvolvimento, teste e produção. Consulte Controlar fonte de dados com parâmetros.

Como os pipelines Delta Live Tables usam o esquema virtual LIVE para gerenciar todos os relacionamentos dataset , configurando pipelines de teste e desenvolvimento com bibliotecas de ingestão que carregam dados de amostra, você pode substituir dataset de amostra usando nomes de tabelas de produção para testar o código. A mesma lógica de transformação pode ser utilizada em todos os ambientes.

Crie conjuntos de dados de amostra para desenvolvimento e teste

Databricks recomenda a criação de dataset 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 dataset que podem ser úteis para desenvolvimento e teste, incluindo o seguinte:

  • 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 cloud_files("/production/data", "json")

Você pode criar um dataset de amostra contendo registros específicos usando uma query como a seguinte:

CREATE OR REFRESH LIVE TABLE 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 LIVE TABLE 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.

Controlar fonte de dados com parâmetros

Você pode fazer referência a parâmetros definidos durante a configuração do pipeline em suas bibliotecas. Esses parâmetros são definidos como valor- keypar na parte compute > Avançado > Configurações da IU de configurações do pipeline. Este padrão permite especificar diferentes fontes de dados em diferentes configurações do mesmo pipeline.

Por exemplo, você pode especificar diferentes caminhos em configurações de desenvolvimento, teste e produção para um pipeline usando a variável data_source_path e, em seguida, referenciá-la usando o seguinte código:

CREATE STREAMING TABLE bronze
AS (
    SELECT
    *,
    _metadata.file_path AS source_file_path
    FROM cloud_files( '${data_source_path}', 'csv',
            map("header", "true"))
)

import dlt
from pyspark.sql.functions import col

data_source_path = spark.conf.get("data_source_path")

@dlt.table
def bronze():
    return (spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "csv")
        .option("header", True)
        .load(data_source_path )
        .select("*", col("_metadata.file_path").alias("source_file_name"))
    )

Esse padrão é especialmente útil se você precisar testar como a lógica de ingestão pode manipular alterações no esquema ou dados malformados durante a ingestão inicial. Você pode usar o código idêntico em todo o pipeline em todos os ambientes enquanto troca dataset.