Implementar verificações de tipos de dados
Cada coluna do seu conjunto de dados tem um tipo de dado esperado e, quando os dados recebidos não correspondem a essa expectativa, os problemas surgem a jusante. Um valor de cadeia onde pertence um inteiro pode quebrar cálculos, corromper agregações ou causar falhas no pipeline. As verificações de tipos de dados garantem que cada campo contém valores do tipo correto antes de entrarem nas suas tabelas.
Nesta unidade, vais aprender como implementar verificações de tipos de dados usando imposição de esquema, conversão explícita de tipos e restrições de validação no Azure Databricks.
Compreender a imposição de esquemas
O Delta Lake valida automaticamente os tipos de dados quando escreve dados numa tabela. Este mecanismo incorporado, chamado aplicação de esquema, compara os tipos de dados das colunas recebidas com o esquema da tabela de destino. Quando ocorre uma incompatibilidade de tipos, a Delta Lake tenta converter o valor em segurança. Se o cast falhar, a operação de escrita gera um erro.
A aplicação de esquemas aplica as seguintes regras durante as operações de inserção:
- Todas as colunas inseridas devem existir na tabela alvo
- Todos os tipos de dados de coluna devem coincidir ou ser convertíveis de forma segura para os tipos alvo.
Considere uma tabela com uma coluna inteira:
CREATE TABLE inventory (
product_id INT,
quantity INT,
last_updated DATE
);
Quando insere dados onde quantity é uma cadeia que representa um número, Delta Lake lança-os para o tipo alvo:
-- This succeeds because '100' can be cast to INT
INSERT INTO inventory VALUES (1, '100', '2026-01-15');
No entanto, inserir uma cadeia que não pode ser convertida num 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 esquemas fornece uma primeira linha de defesa contra incompatibilidades de tipos. Para mais controlo sobre a forma como as incompatibilidades são geridas, pode usar a conversão explícita.
Utilizar a conversão explícita de tipos
A cast função converte valores de um tipo de dado para outro. Quando a conversão falha, surge um erro. A try_cast função funciona da mesma forma, mas retorna NULL em vez de gerar um erro quando a conversão falha.
Use cast quando quiser uma validação rigorosa que pare de processar dados inválidos:
SELECT
cast(raw_amount AS DECIMAL(10,2)) AS amount,
cast(raw_date AS DATE) AS transaction_date
FROM staging_data;
try_cast Use quando quiser identificar valores inválidos sem falhar a 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 o uso de try_cast, os registos com valores inválidos retornam NULL para a coluna de conversão. Depois, pode filtrar, sinalizar ou colocar em quarentena esses registos com base nos requisitos de qualidade dos seus dados.
Implementar validação de tipos com restrições
As restrições CHECK permitem-lhe definir regras de validação personalizadas que são aplicadas sempre que os dados são inseridos ou atualizados. Embora normalmente seja usado para intervalos de valores e padrões, pode combiná-los com funções conscientes do tipo para criar verificações de tipos sofisticadas.
Por exemplo, pode validar que uma coluna de cadeia 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]+)?$')
Esta restrição garante que a order_total coluna contém valores que parecem números válidos, apanhando dados mal formados antes de entrarem na tabela.
Para validação de datas, 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);
Esta abordagem rejeita registos que event_date_str não contêm um formato de data válido.
Importante
Antes de adicionar uma restrição a uma tabela existente, o Azure Databricks verifica se todas as linhas existentes satisfazem essa restrição. Planeie esta etapa de validação, especialmente em tabelas grandes.
Incompatibilidades de tipos de handle em pipelines
Ao processar dados de fontes externas, são comuns incompatibilidades de tipos. Implemente um padrão que separe registos válidos de inválidos, permitindo-lhe processar bons dados enquanto coloca em quarentena registos 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;
Este padrão garante que o seu pipeline continue a processar dados válidos, preservando registos inválidos para análise posterior.
Use expectativas de pipeline para verificação de tipos
Os pipelines Lakeflow fornecem expectativas que permitem definir regras de qualidade de dados diretamente nas definições dos pipelines. Pode usar expectativas para verificar se os valores podem ser convertidos nos 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 o expect_or_drop, os registos que falham na verificação de tipo são eliminados antes de chegarem à tabela de destino. Use expect para registar violações sem perder registos, ou expect_or_fail para parar o pipeline quando ocorrem 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 do pipeline integram a validação do tipo de dados diretamente na lógica do seu ETL, proporcionando visibilidade das métricas de qualidade dos dados através da interface do pipeline.
Implementar verificações de tipos de dados em múltiplos níveis — aplicação de esquemas, casting explícito, restrições e expectativas do pipeline — cria uma defesa em profundidade. Cada camada deteta problemas que podem passar despercebidos por outras, resultando numa melhor qualidade de dados nas suas tabelas do Catálogo Unity.