Calidad de los datos en vistas materializadas del lago

En la era de macrodatos, la arquitectura de medallón obtuvo importancia como un marco sólido para administrar y procesar datos en diferentes fases de refinamiento, desde datos sin procesar hasta conjuntos de datos altamente mantenidos. Este enfoque estructurado no solo mejora la capacidad de administración de datos, sino que también garantiza que la calidad de los datos se mantenga a lo largo del ciclo de vida de los datos.

Garantizar la calidad de los datos es esencial en cada fase de la arquitectura de medallón, que es fundamental para tomar decisiones empresariales fundamentadas. La mala calidad de los datos puede dar lugar a conclusiones incorrectas e ineficacias operativas.

En este artículo se explica cómo implementar la calidad de los datos en vistas materializadas de lago (MLV) en Microsoft Fabric.

Implementación de la calidad de los datos

Al transformar datos, es importante crear consultas precisas para excluir datos de mala calidad de las tablas de origen, lo que aumenta el tiempo de procesamiento y, en ocasiones, hace que se produzca un error en toda la canalización debido a problemas de datos menores.

La calidad de los datos se mantiene estableciendo restricciones al definir los MLV. Las vistas materializadas de Fabric proporcionan un enfoque para implementar comprobaciones de la administración de la calidad de los datos de forma eficaz.

Las siguientes acciones se pueden implementar cuando se especifican restricciones.

FAIL — esta acción detiene la actualización de un MLV si se infringe alguna restricción, deteniéndose en la primera instancia. Es el comportamiento predeterminado, incluso sin especificar la palabra clave FAIL.

DROP : esta acción procesa el MLV y quita los registros que no cumplen la restricción especificada. También proporciona el recuento de registros quitados en la vista de linaje.

Definición de las comprobaciones de calidad de datos en una vista de lago materializada

En el ejemplo siguiente se define la restricción cust_blank, que comprueba si el customerName campo no es NULL. Las filas con un valor NULL customerName se excluyen del procesamiento.

CREATE MATERIALIZED LAKE VIEW IF NOT EXISTS silver.customers_enriched  
(CONSTRAINT cust_blank CHECK (customerName is not null) on MISMATCH DROP)
AS
SELECT
    c.customerID,
    c.customerName,
    c.contact, 
    CASE  
       WHEN COUNT(o.orderID) OVER (PARTITION BY c.customerID) > 0 THEN TRUE  
       ELSE FALSE  
    END AS has_orders 
FROM bronze.customers c LEFT JOIN bronze.orders o 
ON c.customerID = o.customerID; 

Limitaciones actuales

• No se admite la actualización de restricciones de calidad de datos después de crear un MLV. Para actualizar las restricciones de calidad de los datos, debe volver a crear el MLV (Modelo de Lógica de Validación).
• El uso de funciones y búsqueda de patrones con operadores como LIKE o regex en la condición de restricción está restringido.

Problemas conocidos

• La creación y actualización de un MLV con una restricción de acción FAIL puede dar lugar a un problema de "tabla delta no encontrada". En tales casos, se recomienda volver a crear el MLV y evitar el uso de la acción FAIL.

Contenido relacionado

• Actualizar vistas materializadas del lago