Um guia abrangente de testes dbt para garantir a qualidade dos dados

O dbt está crescendo em popularidade no campo da análise por suas funções de transformação e teste de dados. Neste artigo, compartilharemos o que é dbt e como você pode realizar alguns testes de dbt para garantir a qualidade dos dados. Se você está apenas começando com o dbt, não deixe de conferir nosso curso Introdução ao dbt para saber mais. 

O que é dbt?

Conforme exploramos em nosso guia separado, a dbt (ferramenta de criação de dados) é uma ferramenta popular de código aberto usada pelas equipes de dados para transformar dados brutos em seu warehouse em conjuntos de dados limpos, testados, documentados e prontos para análise. 

Diferentemente das ferramentas de ETL, o dbt se concentra apenas no componente "T" (Transformar) do pipeline de dados e opera em cima de data warehouses modernos em nuvem, como BigQuery, Snowflake, Redshift e Databricks.

Um dos recursos mais poderosos do dbt é sua estrutura integrada de teste de dados, que permite que os profissionais de dados escrevam testes que validem suposições sobre seus dados. Essa estrutura de testes não é apenas útil para detectar problemas com antecedência, mas também é crucial para manter a qualidade dos dados e a confiança em uma base de código de análise modular e em crescimento.

Por que testar no dbt?

O teste é uma parte fundamental da engenharia analítica. À medida que os conjuntos de dados crescem e mais partes interessadas dependem dos dados, o custo de problemas de dados não detectados aumenta. Os recursos de teste da dbt ajudam você:

• Detectar problemas de dados antecipadamente: Antes que os painéis e relatórios downstream sejam afetados.
• Automatize as verificações de qualidade: Evite o trabalho de validação manual.
• Incentivar boas práticas de modelagem de dados: Promova transformações modulares e testáveis.
• Suporte às práticas de CI/CD: Integre-se perfeitamente a fluxos de trabalho automatizados.
• Aplique contratos de dados: Valide se as restrições de chave (por exemplo, sem duplicatas) se mantêm verdadeiras ao longo do tempo.

Tipos de testes dbt

No dbt, os testes são afirmações baseadas em SQL que validam as suposições de dados. Os testes em dbt se enquadram em duas categorias principais:

1. Testes genéricos (incorporados)

Esses testes são predefinidos pelo dbt e são aplicados declarativamente em arquivos YAML. Os testes genéricos abrangem restrições comuns que normalmente são encontradas na modelagem e no warehouse de dados. 

São eles:

• Fácil de configurar
• Reutilizável em colunas e modelos
• Alto desempenho para verificações simples

Os quatro tipos de testes genéricos incorporados incluem:

• not_null: Garante que uma coluna não contenha nenhum valor NULL.
• unique: Garante que os valores de uma coluna sejam distintos entre as linhas (geralmente usado para chaves primárias).
• accepted_values: Restringe uma coluna a um conjunto predefinido de valores permitidos.
• relationships: Valida a integridade referencial entre tabelas, garantindo que as chaves estrangeiras correspondam aos valores em outra tabela.

Esses testes são ideais para que você reforce a integridade dos dados de linha de base, especialmente em relação a chaves, campos categóricos e relacionamentos de tabela principais.

Os testes genéricos funcionam gerando automaticamente o SQL sob o capô. 

Por exemplo, um teste not_null na coluna customer_id gerará um SQL semelhante a este:

SELECT *
FROM {{ ref('customers') }}
WHERE customer_id IS NULL

Se essa consulta retornar alguma linha, o teste falhará.

2. Testes personalizados (singular)

Os testes personalizados ou singulares são consultas SQL definidas pelo usuário, salvas como arquivos .sql no diretório tests/. Eles são usados para:

• Validações complexas que os testes genéricos não podem expressar
• Aplicação de regras de negócios
• Lógica entre modelos
• Limites estatísticos ou condicionais

Os testes singulares oferecem o máximo de flexibilidade. Você pode validar os dados de praticamente qualquer maneira, desde que sua consulta SQL retorne apenas as linhas que violam as expectativas.

Por exemplo:

• Garantir que a data de lançamento de um produto não seja posterior à sua data de aposentadoria
• Detecção de valores anormalmente altos ou baixos (detecção de outlier)
• Validação de que os valores agregados estão alinhados com os totais do negócio

Devido à sua flexibilidade, os testes personalizados são ideais para equipes de análise que desejam aplicar contratos de qualidade de dados diferenciados na produção.

As macros incluídas no dbt também podem ser usadas para testar, como o pacote dbt-utils.

Em resumo:

A combinação dos dois tipos oferece a você o melhor dos dois mundos: alguma consistência e cobertura dos testes genéricos e alguma precisão dos testes personalizados. Vamos explorar cada tipo em mais detalhes. 

1. Testes genéricos (incorporados)

Os testes genéricos são predefinidos pelo dbt e usados de forma declarativa, adicionando-os ao arquivo schema.yml do seu modelo. 

Esses testes normalmente validam restrições como exclusividade, não nulidade, integridade referencial ou valores em um conjunto definido.

Vamos explorar um tutorial simples para você experimentar testes genéricos no dbt.

Como declarar um teste genérico

No arquivo schema.yml correspondente ao seu modelo, defina os testes na seção columns::

version: 2

models:
  - name: customers
    description: "Customer dimension table"
    columns:
      - name: customer_id
        description: "Unique customer identifier"
        tests:
          - not_null
          - unique
      - name: email
        tests:
          - not_null

Exemplo: not_null e unique

yaml
columns:
  - name: customer_id
    tests:
      - not_null
      - unique

O teste acima garante que customer_id esteja presente em todas as linhas e seja distinto. É comumente usado para impor a suposição de que customer_id é uma chave primária para a tabela.

Exemplo: accepted_values

columns:
  - name: customer_type
    tests:
      - accepted_values:
          values: ['new', 'returning', 'vip']

Isso verifica se o campo customer_type contém apenas uma das três cadeias de caracteres permitidas: new, returning, ou vip. Esse teste é frequentemente usado para campos categóricos que devem estar em conformidade com um conjunto conhecido de valores, como enums ou status.

Exemplo: relacionamentos

columns:
  - name: customer_id
    tests:
      - relationships:
          to: ref('customers')
          field: id

Isso impõe uma restrição de integridade referencial, verificando se cada customer_id no modelo atual existe como um id na tabela customers. Ele imita uma restrição de chave estrangeira no SQL, mas na camada analítica.

2. Testes personalizados (singulares)

Quando os testes integrados não forem suficientes para o seu caso de uso, por exemplo, se você quiser validar a lógica comercial complexa, poderá escrever testes personalizados usando SQL. Esses testes são conhecidos como testes singulares.

Como criar um teste personalizado

1. Crie um arquivo .sql dentro do diretório tests/ em seu projeto dbt.

2. Escreva uma consulta SQL que retorne as linhas que não passaram no teste.

Exemplo: Não há datas futuras em orders

Na pasta de testes, crie um arquivo chamado no_future_dates.sql.

SELECT *
FROM {{ ref('orders') }}
WHERE order_date > current_date

Esse teste verifica se algum registro na tabela orders tem um order_date no futuro. Se as linhas forem retornadas, o teste falhará, alertando você sobre dados inválidos que podem ser causados por erros de fuso horário, erros de ETL ou entradas incorretas no sistema de origem.

Exemplo: E-mails duplicados por região

-- File: tests/duplicate_emails_per_region.sql

SELECT email, region, COUNT(*) as occurrences
FROM {{ ref('customers') }}
GROUP BY email, region
HAVING COUNT(*) > 1

Esse teste garante que cada e-mail seja único em uma determinada região. Isso pode refletir uma regra comercial em que a mesma pessoa não pode se registrar duas vezes na mesma região. Qualquer linha retornada indica uma violação da qualidade dos dados.

Como implementar testes no dbt

Esta seção apresenta as etapas práticas para implementar, configurar e executar testes dbt no seu projeto e nos pipelines de implantação.

Etapa 1: Configuração do dbt

Antes de começar a escrever testes ou modelos, você precisa ter o dbt instalado e um novo projeto inicializado.

Instruções passo a passo:

1. Crie uma pasta de projeto:

Crie uma pasta em um local de sua escolha.

2. Navegue até a pasta do projeto:

cd dbt-test-project

3. Crie um ambiente virtual Python:

python3 -m venv dbt-env

Em seguida, ative o ambiente depois que ele tiver sido criado.

dbt-venv\Scripts\activate

4. Instalar o dbt

pip dbt install

5. Criar a pasta .dbt

mkdir $home\.dbt

6. Inicializar o dbt

dbt init

7. Criar o arquivo profiles.yml

Crie um novo arquivo em sua pasta .dbt com o seguinte conteúdo:

austi:
  target: dev
  outputs:
    dev:
      type: sqlite
      threads: 1
      database: ./dbt_project.db
      schema: main
      schema_directory: ./schemas
      schemas_and_paths:
        main: ./dbt_project.db

Você pode substituir "austi" pelo nome do seu perfil de usuário do computador Windows.

8. Criar o arquivo dbt_project.yml

Em seguida, você precisará criar outro arquivo de configuração na pasta .dbt com o seguinte conteúdo.

name: dbt_test_project
version: '1.0'
profile: austi

seeds:
  dbt_test_project:
    +quote_columns: false

Mais uma vez, substitua "austi" pelo nome do seu perfil de usuário.

9. Verifique se o projeto funciona:

dbt debug

Quando a configuração estiver concluída, você estará pronto para começar a criar conjuntos de dados e construir modelos dbt.

Etapa 2: Criando o conjunto de dados

Se você estiver trabalhando sem acesso a um data warehouse, poderá simular testes de dbt localmente usando arquivos CSV e a funcionalidade de semente do dbt.

Instruções passo a passo:

1. Criar arquivos CSV: Coloque-os em uma nova pasta /seeds do seu projeto dbt.

Veja como você deve nomeá-lo:

seeds/customers.csv

customer_id,name,email,customer_type
1,Alice Smith,alice@example.com,new
2,Bob Jones,bob@example.com,returning
3,Carol Lee,carol@example.com,vip
4,David Wu,david@example.com,new

2. Crie outro arquivo no mesmo diretório:

Use essa convenção de nomenclatura:

seeds/orders.csv

order_id,customer_id,order_date,order_total,order_status
1001,1,2023-12-01,150.00,shipped
1002,2,2023-12-03,200.00,delivered
1003,1,2023-12-05,175.00,cancelled
1004,3,2024-01-01,225.00,pending

3. Crie um arquivo de configuração para identificar as sementes:

Em seguida, você precisará criar um arquivo de configuração chamado dbt_project.yml.

Cole o seguinte conteúdo no arquivo de configuração. 

name: dbt_test_project
version: '1.0'
profile: austi

seeds:
  dbt_test_project:
    +quote_columns: false

Altere o campo profile para que corresponda ao nome do seu perfil de usuário no computador Windows.

4. Carregar dados de sementes:

dbt seed

Esse comando cria as tabelas main.customers e main.orders a partir dos arquivos CSV. Essas são as sementes necessárias para substituir um banco de dados.

Como você pode ver na imagem acima, duas sementes foram encontradas e carregadas.

Etapa 3: Ingerindo no dbt

Agora, criaremos modelos de preparação para transformar e testar seus dados brutos.

Instruções passo a passo:

1. Crie modelos de preparação:

Crie uma nova pasta chamada models na pasta do seu projeto. Nessa pasta, crie um arquivo chamado stg_customers.sql.

Cole o código a seguir no arquivo:

SELECT
  *
FROM {{ ref('customers') }}

Em outro arquivo chamado stg_orders.sql, cole o seguinte código:

SELECT
  *
FROM {{ ref('orders') }}

2. Definir testes de esquema:

Crie um novo arquivo no seguinte local:

models/schema.yml

Cole o seguinte no arquivo

version: 2

models:
  - name: stg_customers
    description: "Customer staging table"
    columns:
      - name: customer_id
        description: "Unique identifier for each customer"
        tests:
          - not_null:
              tags: [critical]
          - unique:
              tags: [critical]

      - name: email
        description: "Email address of the customer"
        tests:
          - not_null

  - name: stg_orders
    description: "Orders staging table"
    columns:
      - name: order_id
        description: "Unique identifier for each order"
        tests:
          - not_null:
              tags: [critical]
          - unique:
              tags: [critical]

      - name: customer_id
        description: "Foreign key to stg_customers"
        tests:
          - not_null:
              tags: [critical]

3. Execute o dbt para criar modelos de preparação:

dbt run --select stg_customers stg_orders

Esses modelos de preparação agora funcionam como base para a aplicação de testes dbt usando seus dados semeados localmente.

Um exemplo de saída seria:

Etapa 4: Criando seu primeiro teste

Agora que seus dados estão preparados, vamos implementar o primeiro teste dbt usando a estrutura de teste genérica integrada.

Instruções passo a passo:

1. Abra o arquivo schema.yml onde o modelo de preparação está definido.

2. Na seção columns: do seu modelo, defina um teste como not_null ou exclusivo.

Exemplo:

models:

  - name: stg_customers

    columns:

      - name: customer_id

        tests:

          - not_null

          - unique

3. Execute o teste usando a CLI:

dbt test --select stg_customers

Aqui está um resultado esperado:

Etapa 5: Desenvolvimento de testes personalizados e singulares

Quando suas necessidades vão além dos testes integrados, você pode criar testes personalizados usando SQL.

Instruções passo a passo:

1. Crie um novo arquivo na pasta tests/, por exemplo: tests/no_future_orders.sql

2. Adicione a lógica SQL que retorna a linha com falha s:

SELECT *
FROM {{ ref('stg_orders') }}
WHERE order_date > current_date

3. Execute o teste:

dbt test --select no_future_orders

Esse teste falhará se algum pedido tiver valores order_date com data futura.

Aqui está um resultado esperado:

Etapa 6: Execução de testes em pipelines de CI/CD

Para garantir a execução consistente dos testes, integre os testes dbt ao seu pipeline de desenvolvimento.

Instruções passo a passo:

1. Use tags para priorizar ou isolar testes:

Você pode modificar qualquer esquema de modelo para incluir as seguintes tags nesse formato:

columns:
  - name: customer_id
    tests:
      - not_null:
          tags: [critical]

2. Execute testes seletivos localmente:

dbt test --select tag:critical

Se os testes forem executados corretamente, você deverá esperar esse resultado:

3. Configure seu fluxo de trabalho de CI para executar testes dbt automaticamente. Você pode conectar isso a uma plataforma de CI, como o GitHub Actions. 

Práticas recomendadas para testes dbt

A implementação eficaz de testes dbt não se resume a escrevê-los; trata-se de integrar os testes ao ciclo de vida e à cultura de desenvolvimento da sua equipe. Aqui estão algumas práticas recomendadas para orientar você:

1. Comece com chaves primárias

Sempre aplique os testes not_null e unique às colunas de chave primária nas tabelas de dimensão e de fatos. Essas duas restrições são a base das uniões confiáveis e da lógica de deduplicação nas consultas downstream.

2. Validar chaves estrangeiras com relacionamentos

As chaves estrangeiras são essenciais para manter a integridade referencial. Use o teste relationships para imitar as restrições de chave estrangeira, especialmente em data warehouses que não as impõem nativamente.

3. Use accepted_values para colunas categóricas

Controle a consistência dimensional impondo valores específicos em colunas como status, region, ou product_type. Isso reduz o risco de erros de digitação ou expansões de enum não tratadas.

4. Escreva testes personalizados para a lógica comercial

A lógica comercial nem sempre é mapeada de forma clara para regras genéricas. Exemplos de lógica para a qual você deve escrever testes personalizados incluem:

• As vendas devem ser não negativas
• As datas dos pedidos não podem estar no futuro
• Um usuário não pode ter várias assinaturas ativas

5. Organizar os testes com clareza

Se você tiver muitos testes definidos, a situação pode ficar complicada rapidamente. Você deve considerar estas práticas recomendadas para mantê-los organizados:

• Coloque os testes personalizados na pasta tests/ e dê a eles um nome descritivo.
• Evite SQL excessivamente complexo nos testes - mantenha a lógica focada e legível.
• Sempre que possível, agrupe os testes por modelo ou domínio.

6. Falha rápida e integração com CI/CD

Execute o dbt test como parte de seu pipeline de CI. Isso garante que o código não possa ser mesclado a menos que as restrições de qualidade dos dados sejam aprovadas. A integração de testes à CI/CD reforça a responsabilidade e a confiança no pipeline de dados.

7. Evite o excesso de testes

Testes excessivos ou desnecessários (especialmente em grandes volumes de dados) podem tornar as implementações mais lentas. Concentre-se em testes que sejam:

• Business-critical
• É provável que você falhe devido a problemas de upstream
• Útil para depuração quando quebrado

Evite testar campos calculados, a menos que eles façam parte de um SLA contratual.

Exemplo avançado: Detecção de outlier

Para um exemplo de teste avançado, podemos realizar um teste de detecção de outlier.

Crie um arquivo SQL em sua pasta de testes com o seguinte código:

SELECT *
FROM {{ ref('orders') }}
WHERE order_total > 100000

Esse é um teste básico de detecção de outlier. Se a sua empresa normalmente recebe pedidos abaixo de US$ 10.000, você pode sinalizar pedidos acima de US$ 100.000 para revisão manual. Embora não seja uma violação estrita da qualidade dos dados, isso pode ser valioso para a detecção de fraudes ou o monitoramento operacional.

Considerações sobre o desempenho

À medida que o seu projeto de dbt se expande e a cobertura de testes aumenta, o desempenho se torna cada vez mais importante. Esta seção descreve técnicas e estratégias para manter a eficiência do teste e controlar os custos computacionais.

Testar técnicas de otimização

Para testar, experimente estas técnicas para otimizar o desempenho:

• Teste incremental: Concentre os testes apenas nos dados recém-adicionados ou modificados usando a estrutura de modelo incremental do dbt. Isso reduz as varreduras desnecessárias em conjuntos de dados completos.
• Paralelização de consultas: Use a execução paralela integrada do dbt configurando o parâmetro threads: em dbt_project.yml para executar vários testes simultaneamente.
• Execução seletiva de testes: Use sinalizadores como --select e --exclude para executar somente testes relevantes, especialmente durante o desenvolvimento. Por exemplo:

dbt test --select customers
dbt test --exclude tag:slow

Estratégias de gerenciamento de custos

A implementação de estratégias de gerenciamento de custos garante que os testes de dbt permaneçam eficientes e econômicos, especialmente em ambientes em que o faturamento da computação está vinculado à complexidade e à frequência da consulta.

Algumas estratégias são:

• Execução de testes com base em tags: Atribua tags a testes opcionais ou com uso intensivo de recursos para que eles possam ser excluídos das execuções padrão, a menos que sejam explicitamente exigidos.
• Cache de resultados: Utilize recursos específicos do warehouse (por exemplo, cache de resultados no BigQuery ou Snowflake) para evitar cálculos repetidos sempre que possível. Organize os testes para que você se beneficie dos resultados em cache de consultas executadas anteriormente.
• Lote de teste programado: Programe conjuntos de testes mais pesados fora do horário de pico ou fora das janelas de produção para minimizar o impacto nas cargas de trabalho do warehouse.

Conclusão

Os testes dbt são uma maneira eficiente de garantir a alta qualidade dos dados, automatizar verificações de validação e detectar problemas no início do pipeline de transformação. Os testes genéricos e personalizados podem ser usados para criar fluxos de trabalho de dados robustos e de fácil manutenção.

Saiba mais sobre a dbt em nosso Curso de introdução à dbt ou em nosso tutorial de dbt.