Implementación de comprobaciones de tipos de datos

Cada columna de tu conjunto de datos tiene un tipo de datos esperado, y cuando los datos entrantes no coinciden con esa expectativa, se generan problemas en cadena. Un valor de cadena donde pertenece un entero puede interrumpir cálculos, dañar agregaciones o provocar fallas en la canalización. Las comprobaciones del tipo de datos garantizan que cada campo contenga valores del tipo correcto antes de ingresar a las tablas.

En esta unidad, aprenderá a implementar comprobaciones de tipos de datos mediante la aplicación de esquemas, la conversión explícita de tipos y las restricciones de validación en Azure Databricks.

Comprender la aplicación del esquema

Delta Lake valida los tipos de datos automáticamente al escribir datos en una tabla. Este mecanismo integrado, denominado aplicación de esquemas, compara los tipos de datos de las columnas entrantes con el esquema de la tabla de destino. Cuando ocurre una falta de coincidencia de tipos, Delta Lake intenta convertir el valor de forma segura. Si la conversión falla, la operación de escritura genera un error.

La aplicación del esquema aplica las siguientes reglas durante las operaciones de inserción:

• Todas las columnas insertadas deben existir en la tabla de destino
• Todos los tipos de datos de columna deben coincidir con o ser convertibles de forma segura a los tipos de destino.

Considere una tabla con una columna de enteros:

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

Al insertar datos donde quantity es una cadena que representa un número, Delta Lake lo convierte en el tipo de destino:

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

Sin embargo, la inserción de una cadena que no se puede convertir en un entero hace que se produzca un error en la operación:

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

La aplicación de esquemas proporciona una primera línea de defensa contra las discrepancias de tipos. Para tener más control sobre cómo se manejan las discrepancias, puedes utilizar la conversión explícita.

Utilice conversión de tipos explícita

La cast función convierte valores de un tipo de datos a otro. Cuando falla la conversión, se genera un error. La try_cast función funciona de la misma manera, pero devuelve NULL en lugar de generar un error cuando se produce un error en la conversión.

Use cast cuando desee una validación estricta que detenga el procesamiento de datos no vá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 cuando desee identificar valores no válidos sin errores en la 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;

Con try_cast, registros con valores no válidos, devuelve NULL para la columna de fundición. Después, puede filtrar, marcar o poner en cuarentena estos registros en función de los requisitos de calidad de los datos.

Implementación de la validación de tipos con restricciones

Las restricciones CHECK permiten definir reglas de validación personalizadas que se aplican cada vez que se insertan o actualizan los datos. Aunque normalmente se usa para intervalos de valores y patrones, puede combinarlos con funciones compatibles con tipos para crear comprobaciones de tipos sofisticadas.

Por ejemplo, puede validar que una columna de cadena contiene solo 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 restricción garantiza que la order_total columna contenga valores que parecen números válidos, capturando datos con formato incorrecto antes de entrar en la tabla.

Para la validación de fechas, puede usar la try_cast función dentro de una restricción:

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

Este enfoque rechaza los registros donde event_date_str no contiene un formato de fecha válido.

Manejar desajustes de tipos en tuberías

Al procesar datos de orígenes externos, los errores de coincidencia de tipos son comunes. Implemente un patrón que separa los registros válidos de los registros no válidos, lo que le permite procesar datos correctos mientras se protegen registros problemáticos para su revisión:

-- 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 patrón garantiza que la canalización siga procesando datos válidos al tiempo que conserva registros no válidos para su análisis posterior.

Utilice las expectativas de canalización para la verificación de tipos

Las canalizaciones de Lakeflow proporcionan expectativas que te permiten definir reglas de calidad de datos directamente en las definiciones de tus canalizaciones. Puede usar expectativas para comprobar que los valores se pueden convertir a 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")

Con expect_or_drop, los registros que producen un error en la comprobación de tipos se quitan antes de llegar a la tabla de destino. Use expect para registrar infracciones sin quitar registros o expect_or_fail para detener la canalización cuando se produzcan infracciones.

Para canalizaciones basadas en 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);

Las expectativas de flujo de procesos integran la validación de tipos de datos directamente en la lógica de ETL, proporcionando visibilidad de las métricas de calidad de los datos a través de la interfaz de usuario del flujo de procesos.

La implementación de verificaciones de tipos de datos en múltiples niveles (aplicación de esquemas, conversión explícita, restricciones y expectativas de canalización) crea una defensa en profundidad. Cada capa detecta problemas que podrían pasar desapercibidos por otras capas, lo que resulta en una mayor calidad de los datos en las tablas del Catálogo de Unity.