Introdução ao Great Expectations para qualidade de dados em pipelines

1. O Problema da Qualidade de Dados em Pipelines Modernos

1.1. Custos e riscos de dados não confiáveis em produção

Em pipelines modernos, dados corrompidos ou inconsistentes podem gerar impactos catastróficos: decisões de negócio equivocadas, retrabalho em modelos de machine learning, violações regulatórias e perda de confiança dos stakeholders. Estima-se que organizações percam milhões anualmente devido a dados de baixa qualidade, incluindo custos com debugging, reprocessamento e danos à reputação.

1.2. Diferença entre validação tradicional e validação declarativa

A validação tradicional geralmente consiste em scripts ad hoc com asserts e verificações manuais espalhadas pelo código. Essa abordagem é frágil, difícil de manter e não oferece visibilidade centralizada. A validação declarativa, por outro lado, permite definir regras de qualidade como configurações reutilizáveis, versionáveis e auditáveis, separando a lógica de validação da lógica de transformação dos dados.

1.3. Por que ferramentas como Great Expectations surgiram no ecossistema de dados

Great Expectations (GE) nasceu da necessidade de uma ferramenta open source que unificasse a definição, execução e documentação de regras de qualidade. Diferente de soluções proprietárias, GE oferece uma abordagem baseada em expectativas declarativas, integração nativa com ferramentas de orquestração e geração automática de relatórios de auditoria.

2. Conceitos Fundamentais do Great Expectations

2.1. Expectations: o que são e como definem regras de qualidade

Expectations são o coração do Great Expectations. Cada expectation é uma declaração verificável sobre um conjunto de dados, como "a coluna 'idade' nunca deve conter valores nulos" ou "o valor máximo da coluna 'salario' deve estar entre 1000 e 50000". Internamente, GE traduz essas declarações em consultas SQL ou operações pandas que são executadas contra os dados reais.

Exemplo de expectation em formato JSON:

{
  "expectation_type": "expect_column_values_to_not_be_null",
  "kwargs": {
    "column": "email"
  },
  "meta": {
    "description": "Emails não podem ser nulos"
  }
}

2.2. Data Context e Data Sources: organizando o ambiente de validação

O Data Context é o ambiente central que gerencia configurações, fontes de dados, suites de expectations e resultados de validação. Ele pode ser configurado como um projeto local (pasta great_expectations/) ou integrado a um repositório Git. Data Sources definem como GE se conecta às fontes de dados — arquivos CSV, bancos PostgreSQL, tabelas Spark, entre outros.

2.3. Suites de Expectations: agrupando regras por contexto de pipeline

Uma Expectation Suite é um conjunto lógico de expectations que se aplicam a um mesmo contexto, como "validação da tabela de clientes antes do carregamento no data warehouse". Isso permite organizar regras por estágio do pipeline, facilitando manutenção e reuso.

3. Instalação e Configuração Inicial do Ambiente

3.1. Instalação via pip e dependências mínimas

Para instalar Great Expectations com suporte básico (pandas e SQLAlchemy):

pip install great_expectations

Para ambientes com Spark ou bancos específicos, instale extras:

pip install great_expectations[spark,postgresql]

3.2. Inicialização do Data Context (local e em projeto)

Crie um novo projeto GE:

great_expectations init

Isso gera a estrutura de pastas necessária:

great_expectations/
├── great_expectations.yml
├── expectations/
├── checkpoints/
├── plugins/
└── uncommitted/
    ├── config_variables.yml
    └── data_docs/

3.3. Configuração de conectores para fontes comuns (CSV, PostgreSQL, Spark)

Adicione uma fonte de dados via linha de comando ou manualmente no arquivo great_expectations.yml:

great_expectations datasource new

Selecione o tipo (por exemplo, "Files on a filesystem" para CSV) e configure o caminho base.

4. Criando e Executando as Primeiras Expectations

4.1. Expectations básicas: expect_column_values_to_not_be_null, expect_column_values_to_be_between

Crie uma suite e adicione expectations básicas:

import great_expectations as ge

df = ge.read_csv("clientes.csv")

df.expect_column_values_to_not_be_null("email")
df.expect_column_values_to_be_between("idade", min_value=18, max_value=120)

4.2. Expectations avançadas: expect_column_pair_values_to_be_equal, expect_table_row_count_to_be_between

df.expect_column_pair_values_to_be_equal("data_inicio", "data_fim") 
# Espera que as colunas sejam iguais (caso especial)

df.expect_table_row_count_to_be_between(min_value=100, max_value=10000)

4.3. Executando validações com checkpoint e interpretando resultados

Checkpoints são configurações que orquestram a execução de suites contra uma fonte de dados específica:

great_expectations checkpoint new validacao_clientes

Execute o checkpoint:

great_expectations checkpoint run validacao_clientes

O resultado inclui estatísticas como número de expectations bem-sucedidas, falhas e exceções.

5. Integração com Pipelines de Dados

5.1. Uso de Great Expectations como etapa de validação em pipelines Prefect/Airflow

Exemplo de integração com Prefect:

from prefect import task, Flow
import great_expectations as ge

@task
def validar_dados():
    context = ge.data_context.DataContext()
    results = context.run_checkpoint("validacao_clientes")
    if not results["success"]:
        raise ValueError("Validação falhou!")
    return results

with Flow("pipeline_clientes") as flow:
    validar_dados()

5.2. Geração de relatórios HTML e Data Docs para auditoria

Data Docs são páginas HTML estáticas que documentam expectations e resultados:

great_expectations docs build

Os relatórios são salvos em uncommitted/data_docs/local_site/ e podem ser servidos por qualquer servidor web.

5.3. Tratamento de falhas: ações de alerta e parada condicional do pipeline

Configure ações pós-validação no checkpoint:

action_list:
  - name: send_slack_notification
    action:
      class_name: SlackNotificationAction
      slack_webhook: ${SLACK_WEBHOOK}
  - name: stop_pipeline_if_fail
    action:
      class_name: ValidationAction
      notify_on: failure

6. Versionamento e Evolução das Regras de Qualidade

6.1. Versionamento de Expectation Suites com Git

As suites são arquivos JSON na pasta expectations/. Basta incluí-los no repositório Git:

git add great_expectations/expectations/
git commit -m "Adiciona suite de validação de clientes"

6.2. Atualização automática de expectations com suite edit e perfilamento

Use o perfilamento para sugerir expectations automaticamente:

great_expectations suite new --profile

Depois edite manualmente com:

great_expectations suite edit minha_suite

6.3. Estratégias para manter regras consistentes entre ambientes (dev, staging, prod)

Utilize variáveis de configuração para ambientes:

# great_expectations.yml
config_variables_file_path: uncommitted/config_variables_${ENVIRONMENT}.yml

Mantenha as suites versionadas e promova entre ambientes via Git.

7. Boas Práticas e Limitações Conhecidas

7.1. Quando usar Great Expectations vs. validação embutida em SQL

Great Expectations é ideal para validações complexas, reutilizáveis e com necessidade de auditoria visual. Para validações simples e de alta performance, constraints SQL diretas podem ser mais eficientes.

7.2. Performance: evitando expectations custosas em grandes volumes

Evite expectations que escaneiam todo o dataset repetidamente, como expect_column_distinct_values_to_be_in_set em colunas com milhões de valores únicos. Prefira amostragem ou agregações prévias.

7.3. Limitações: suporte a streaming, dados não estruturados e governança

Great Expectations foi projetado para dados tabulares e batch. Para streaming, existem adaptações mas não suporte nativo. Dados não estruturados (imagens, áudio) não são cobertos. A governança depende de integrações externas (como Apache Atlas).

Referências