Great Expectations em 2026: Validação de Qualidade de Dados e Perguntas de Entrevista

Great Expectations (GX) representa o framework open-source padrão para validação de qualidade de dados em pipelines baseados em Python. A versão 1.22, lançada em agosto de 2026, consolida as mudanças de API introduzidas no GX 1.0 e adiciona suporte experimental para Python 3.14. Para data engineers que constroem pipelines de produção, essa ferramenta constitui um componente essencial da infraestrutura moderna.

Problemas que o Great Expectations Resolve em Pipelines de Dados

Pipelines de dados falham silenciosamente. Uma mudança de schema upstream, um valor nulo onde não deveria existir nenhum, um formato de data que muda de ISO para Unix timestamp: esses problemas frequentemente chegam a dashboards ou modelos de machine learning antes que alguém perceba. O Great Expectations trata dados como código, aplicando asserções (chamadas Expectations) que executam automaticamente em pontos de verificação do pipeline.

O framework se integra com Apache Airflow, Databricks, Snowflake e serviços de armazenamento em nuvem como AWS S3 e Azure Blob Storage. Cada validação produz Data Docs, relatórios HTML que stakeholders não técnicos podem consultar.

Conceitos Fundamentais: Data Context, Data Sources e Expectations

O GX 1.22 organiza a validação em torno de quatro componentes: o Data Context, os Data Sources, os Data Assets e as Expectation Suites.

O Data Context é o objeto de configuração central. Ele armazena metadados para Data Sources, Expectation Suites, Checkpoints e histórico de Validation Results. Na maioria dos projetos, um único diretório gx/ contém os arquivos de configuração YAML e os Data Docs gerados.

Um Data Source representa uma conexão a um banco de dados, data warehouse ou sistema de arquivos. Um Data Asset é uma coleção lógica de registros dentro dessa fonte, similar a uma tabela ou ao conjunto de resultados de uma query.

# gx_setup.py
import great_expectations as gx

# Initialize or load an existing Data Context
context = gx.get_context()

# Add a Pandas Data Source for local files
data_source = context.data_sources.add_pandas("local_files")

# Define a Data Asset pointing to a specific CSV pattern
data_asset = data_source.add_csv_asset(
    name="user_events",
    filepath_or_buffer="data/user_events_*.csv"  # Glob pattern
)

Essa configuração permite que o GX valide qualquer CSV que corresponda a user_events_*.csv no diretório data/.

Construção de uma Expectation Suite para Validação de Colunas

Uma Expectation Suite é uma coleção de asserções contra um Data Asset. Cada Expectation declara uma condição que deve ser verdadeira para os dados, como "a coluna user_id nunca deve ser nula" ou "a coluna age deve conter valores entre 0 e 120."

# build_suite.py
import great_expectations as gx

context = gx.get_context()

# Create or retrieve an Expectation Suite
suite = context.suites.add(
    gx.ExpectationSuite(name="user_events_suite")
)

# Add Expectations to the suite
suite.add_expectation(
    gx.expectations.ExpectColumnToExist(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="age",
        min_value=0,
        max_value=120
    )
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToMatchRegex(
        column="email",
        regex=r"^[\w.-]+@[\w.-]+\.\w+$"
    )
)

# Save the suite to the Data Context
context.suites.save(suite)

O GX 1.0+ utiliza uma API baseada em classes para Expectations. A sintaxe antiga baseada em dicionários (expect_column_to_exist) permanece disponível, mas a abordagem baseada em classes fornece melhor autocompletação no IDE e segurança de tipos.

Execução de Validações com Checkpoints

Um Checkpoint vincula um Data Asset, uma Expectation Suite e Actions opcionais que disparam quando a validação passa ou falha. Os Checkpoints são o ponto de entrada principal para validação automatizada em produção.

# run_checkpoint.py
import great_expectations as gx

context = gx.get_context()

# Create a Checkpoint
checkpoint = context.checkpoints.add(
    gx.Checkpoint(
        name="user_events_checkpoint",
        validation_definitions=[
            gx.ValidationDefinition(
                name="validate_user_events",
                data=context.data_sources.get("local_files")
                    .get_asset("user_events")
                    .build_batch_request(),
                suite=context.suites.get("user_events_suite")
            )
        ],
        actions=[
            gx.checkpoint.UpdateDataDocsAction(name="update_docs"),
        ]
    )
)

# Run the Checkpoint
result = checkpoint.run()

# Check overall success
if result.success:
    print("All validations passed")
else:
    print("Validation failures detected")
    for validation_result in result.run_results.values():
        for expectation_result in validation_result.results:
            if not expectation_result.success:
                print(f"  Failed: {expectation_result.expectation_config}")

Quando o Checkpoint executa, o GX carrega o batch, aplica cada Expectation e atualiza os Data Docs. Validações com falha podem disparar notificações do Slack, alertas do PagerDuty ou terminação do pipeline dependendo das Actions configuradas.

Integração do GX com DAGs do Apache Airflow

A maioria dos pipelines de dados em produção utiliza um orquestrador como o Apache Airflow. O GX fornece uma integração oficial com Airflow que encapsula a execução de Checkpoints em um operador.

# dags/user_events_pipeline.py
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
import great_expectations as gx

def validate_user_events():
    """Run GX Checkpoint for user events data."""
    context = gx.get_context(context_root_dir="/opt/airflow/gx")
    checkpoint = context.checkpoints.get("user_events_checkpoint")
    result = checkpoint.run()
    
    if not result.success:
        # Raise exception to fail the Airflow task
        raise ValueError("Data validation failed. Check Data Docs for details.")

with DAG(
    dag_id="user_events_pipeline",
    start_date=datetime(2026, 1, 1),
    schedule_interval="@daily",
    catchup=False
) as dag:
    
    validate_task = PythonOperator(
        task_id="validate_user_events",
        python_callable=validate_user_events
    )
    
    # Downstream tasks depend on validation passing
    # transform_task >> load_task

Colocar a validação antes das tarefas de transformação impede que dados ruins se propaguem downstream. Esse padrão, às vezes chamado de "shift-left testing", detecta problemas na ingestão em vez de após a conclusão de jobs de computação custosos.

Perguntas de Entrevista Comuns sobre Great Expectations

Entrevistas de data engineering em 2026 frequentemente incluem perguntas sobre ferramentas de qualidade de dados. Abaixo estão perguntas que aparecem em entrevistas técnicas, junto com as respostas que distinguem candidatos experientes de juniores.

"Como você implementaria verificações de qualidade de dados em um pipeline de produção?"

Respostas sólidas mencionam integrar validação como uma etapa do pipeline, não como um dashboard separado. Especificamente:

• Validação de schema na ingestão detecta problemas estruturais imediatamente, por exemplo uma string aparecendo onde um inteiro era esperado
• Validação de lógica de negócios verifica restrições de domínio como preços positivos e intervalos de datas
• Alertas automatizados notificam engenheiros de plantão quando a validação falha, prevenindo corrupção silenciosa de dados
• Testes do dbt lidam com verificações da camada de transformação enquanto o GX lida com validação de ingestão e saída

"Qual é a diferença entre uma Expectation Suite e um Checkpoint?"

Uma Expectation Suite contém as asserções em si: quais colunas devem existir, quais intervalos de valores são aceitáveis, quais padrões regex devem corresponder. Ela define o que verificar.

Um Checkpoint define quando e como executar essas verificações. Ele conecta um Data Asset específico (os dados a validar), uma Expectation Suite (as regras a aplicar) e Actions (o que acontece após a validação).

"Como lidar com Expectations que variam por ambiente?"

Dados de produção frequentemente têm características diferentes de dados de staging. Duas abordagens:

1. Expectations Parametrizadas: Usar variáveis de ambiente ou parâmetros de runtime para ajustar limites. Por exemplo, min_value=int(os.getenv("AGE_MIN", 0)).

2. Múltiplas Suites: Manter suites separadas para staging e produção. Staging pode permitir nulls em campos opcionais para testar fluxos de dados incompletos.

"O que acontece quando um Checkpoint falha em um pipeline agendado?"

O Checkpoint retorna um CheckpointResult com success=False. O comportamento do pipeline depende de como o orquestrador lida com a falha:

• No Airflow, levantar uma exceção marca a tarefa como falha, bloqueando tarefas downstream
• No Databricks, o notebook pode sair com um status de erro
• Actions anexadas ao Checkpoint podem enviar mensagens do Slack, criar tickets do Jira ou disparar procedimentos de rollback

Expectations Personalizadas para Validação Específica do Domínio

O GX inclui mais de 300 Expectations embutidas, mas regras específicas do domínio frequentemente requerem implementações personalizadas. Uma Expectation personalizada estende a classe base e implementa a lógica de validação.

# custom_expectations/expect_valid_iso_country_code.py
from great_expectations.expectations import Expectation
from great_expectations.core import ExpectationConfiguration
import pycountry

class ExpectValidIsoCountryCode(Expectation):
    """Expect column values to be valid ISO 3166-1 alpha-2 country codes."""
    
    column: str
    
    @classmethod
    def _prescriptive_template(cls) -> str:
        return "Column {column} values must be valid ISO country codes"
    
    def _validate(self, metrics, runtime_configuration=None, execution_engine=None):
        column_values = metrics.get("column_values")
        valid_codes = {c.alpha_2 for c in pycountry.countries}
        
        invalid_values = [
            v for v in column_values 
            if v is not None and v not in valid_codes
        ]
        
        return {
            "success": len(invalid_values) == 0,
            "result": {
                "observed_value": len(invalid_values),
                "unexpected_list": invalid_values[:10]  # Sample
            }
        }

Expectations personalizadas são registradas colocando-as no diretório great_expectations/plugins/ ou adicionando o módulo ao plugins_directory em great_expectations.yml.

Data Docs: Comunicando Qualidade aos Stakeholders

Data Docs são sites HTML estáticos gerados a partir de resultados de validação. Cada execução produz uma página mostrando quais Expectations passaram ou falharam, com detalhes sobre valores inesperados.

# Generate and open Data Docs
context = gx.get_context()
context.build_data_docs()
context.open_data_docs()  # Opens browser

Para sistemas de produção, Data Docs podem ser hospedados no S3, GCS ou Azure Blob Storage com controles de acesso apropriados. A plataforma GX Cloud oferece Data Docs hospedados com recursos de colaboração em equipe.

Migração GX 1.0: Mudanças Importantes desde 0.x

Equipes atualizando do GX 0.x enfrentam mudanças de API. As principais diferenças:

O guia de migração oficial cobre cada mudança. Para bases de código grandes, a migração incremental usando shims de compatibilidade reduz o risco.

Pontos-Chave para Qualidade de Dados com GX 1.22

• Great Expectations 1.22 (agosto 2026) suporta Python 3.10 a 3.13, com suporte experimental a 3.14 através da variável de ambiente GX_PYTHON_EXPERIMENTAL
• Expectation Suites definem o que validar, Checkpoints definem quando e como
• Integrar Checkpoints como etapas de pipeline em DAGs do Airflow ou notebooks do Databricks para detectar dados ruins na ingestão
• Expectations personalizadas lidam com regras específicas do domínio que Expectations embutidas não podem cobrir
• Data Docs fornecem relatórios HTML legíveis para stakeholders; hospedá-los em armazenamento em nuvem para acesso em produção
• Respostas de entrevista devem enfatizar qualidade de dados como uma etapa de pipeline integrada, não como um dashboard adicionado posteriormente