Implementar verificações de tipo de dados

Cada coluna em seu conjunto de dados tem um tipo de dados esperado e, quando os dados de entrada não correspondem a essa expectativa, os problemas se propagam para os processos subsequentes. Um valor de cadeia de caracteres em que um inteiro pode interromper cálculos, corromper agregações ou causar falhas de pipeline. As verificações de tipo de dados garantem que cada campo contenha valores do tipo correto antes de inserirem suas tabelas.

Nesta unidade, você aprenderá a implementar verificações de tipo de dados usando imposição de esquema, conversão explícita de tipo e restrições de validação no Azure Databricks.

Entender a aplicação de esquema

O Delta Lake valida os tipos de dados automaticamente quando você grava dados em uma tabela. Esse mecanismo interno, chamado de imposição de esquema, compara os tipos de dados de colunas de entrada com o esquema da tabela de destino. Quando ocorre uma incompatibilidade de tipo, o Delta Lake tenta converter o valor de forma segura. Se a conversão falhar, a operação de gravação gerará um erro.

A aplicação do esquema aplica as seguintes regras durante as operações de inserção:

• Todas as colunas inseridas devem existir na tabela de destino
• Todos os tipos de dados de coluna devem ser compatíveis ou conversíveis com segurança para os tipos de dados de destino

Considere uma tabela com uma coluna de inteiros.

CREATE TABLE inventory (
    product_id INT,
    quantity INT,
    last_updated DATE
);

Quando você insere dados em que quantity é a cadeia de caracteres que representa um número, o Delta Lake a converte no tipo de destino:

-- This succeeds because '100' can be cast to INT
INSERT INTO inventory VALUES (1, '100', '2026-01-15');

No entanto, a inserção de uma cadeia de caracteres que não pode ser convertida em um inteiro faz com que a operação falhe:

-- This fails because 'fifty' cannot be cast to INT
INSERT INTO inventory VALUES (2, 'fifty', '2026-01-15');

A aplicação de esquema fornece uma primeira linha de defesa contra incompatibilidades de tipo. Para ter maior controle sobre como as incompatibilidades são tratadas, você pode usar a conversão explícita.

Usar a conversão de tipo explícita

A cast função converte valores de um tipo de dados para outro. Quando a conversão falha, um erro é gerado. A try_cast função funciona da mesma maneira, mas retorna NULL em vez de gerar um erro quando a conversão falhar.

Use cast quando quiser uma validação estrita que pare o processamento em dados inválidos:

SELECT 
    cast(raw_amount AS DECIMAL(10,2)) AS amount,
    cast(raw_date AS DATE) AS transaction_date
FROM staging_data;

Use try_cast quando quiser identificar valores inválidos sem falhar na consulta:

SELECT 
    raw_amount,
    try_cast(raw_amount AS DECIMAL(10,2)) AS validated_amount,
    CASE 
        WHEN try_cast(raw_amount AS DECIMAL(10,2)) IS NULL 
        THEN 'Invalid amount format'
        ELSE 'Valid'
    END AS validation_status
FROM staging_data;

Com try_cast, os registros com valores inválidos retornam NULL para a coluna de cast. Em seguida, você pode filtrar, sinalizar ou colocar esses registros em quarentena com base em seus requisitos de qualidade de dados.

Implementar a validação de tipo com restrições

As restrições CHECK permitem definir regras de validação personalizadas que são impostas sempre que os dados são inseridos ou atualizados. Embora normalmente usado para intervalos de valores e padrões, você pode combiná-los com funções com reconhecimento de tipo para criar verificações de tipo sofisticadas.

Por exemplo, você pode validar que uma coluna de cadeia de caracteres contém apenas caracteres numéricos:

CREATE TABLE orders (
    order_id INT,
    order_total STRING
);

ALTER TABLE orders
ADD CONSTRAINT valid_order_total CHECK (order_total REGEXP '^[0-9]+(\\.[0-9]+)?$')

Essa restrição garante que a order_total coluna contenha valores que se parecem com números válidos, capturando dados malformados antes de entrar na tabela.

Para validação de data, você pode usar a try_cast função dentro de uma restrição:

ALTER TABLE events 
ADD CONSTRAINT valid_event_date CHECK (try_cast(event_date_str AS DATE) IS NOT NULL);

Essa abordagem rejeita registros onde event_date_str não contém um formato de data válido.

Tratar incompatibilidades de tipo em pipelines

Ao processar dados de fontes externas, incompatibilidades de tipo são comuns. Implemente um padrão que separe válido de registros inválidos, permitindo que você processe bons dados ao colocar em quarentena registros problemáticos para revisão:

-- Insert valid records into the target table
INSERT INTO silver_transactions
SELECT 
    transaction_id,
    cast(amount AS DECIMAL(10,2)) AS amount,
    cast(transaction_date AS DATE) AS transaction_date
FROM bronze_transactions
WHERE try_cast(amount AS DECIMAL(10,2)) IS NOT NULL
  AND try_cast(transaction_date AS DATE) IS NOT NULL;

-- Capture invalid records for investigation
INSERT INTO quarantine_transactions
SELECT 
    transaction_id,
    amount AS raw_amount,
    transaction_date AS raw_date,
    current_timestamp() AS quarantined_at,
    'Type validation failed' AS reason
FROM bronze_transactions
WHERE try_cast(amount AS DECIMAL(10,2)) IS NULL
   OR try_cast(transaction_date AS DATE) IS NULL;

Esse padrão assegura que o seu pipeline continue processando dados válidos, ao mesmo tempo que preserva registros inválidos para análise posterior.

Usar as expectativas do pipeline para verificação de tipo

Os pipelines do Lakeflow fornecem expectations que permitem definir regras de qualidade de dados diretamente em suas definições de pipeline. Você pode usar as expectativas para verificar se os valores podem ser convertidos em tipos esperados:

from pyspark import pipelines as dp

@dp.table
@dp.expect_or_drop("valid_amount", "try_cast(amount AS DECIMAL(10,2)) IS NOT NULL")
@dp.expect_or_drop("valid_date", "try_cast(event_date AS DATE) IS NOT NULL")
def validated_transactions():
    return spark.readStream.table("raw_transactions")

Com expect_or_drop, os registros que falham na verificação de tipo são descartados antes de atingir a tabela de destino. Use expect para registrar violações sem remover registros ou para expect_or_fail parar o pipeline quando ocorrerem violações.

Para pipelines baseados em SQL:

CREATE OR REFRESH STREAMING TABLE validated_transactions (
    CONSTRAINT valid_amount EXPECT (try_cast(amount AS DECIMAL(10,2)) IS NOT NULL) ON VIOLATION DROP ROW,
    CONSTRAINT valid_date EXPECT (try_cast(event_date AS DATE) IS NOT NULL) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(raw_transactions);

As expectativas de pipeline integram a validação de tipo de dados diretamente à lógica de ETL, oferecendo visibilidade de métricas de qualidade de dados via interface de usuário do pipeline.

Implementar verificações de tipo de dados em múltiplos níveis (imposição de esquema, conversão explícita, restrições e expectativas de pipeline) cria uma defesa profunda. Cada camada identifica problemas que podem passar despercebidos por outras, resultando em uma maior qualidade de dados em suas tabelas do Catálogo do Unity.