Prueba ETL - Guía rápida

Los datos en un sistema de almacenamiento de datos se cargan con una herramienta ETL (Extraer, Transformar, Cargar). Como su nombre indica, realiza las siguientes tres operaciones:

Extrae los datos de su sistema transaccional, que puede ser Oracle, Microsoft o cualquier otra base de datos relacional.
Transforma los datos realizando operaciones de limpieza de datos y luego
Carga los datos en el almacén de datos OLAP.

También puede extraer datos de archivos planos como hojas de cálculo y archivos CSV utilizando una herramienta ETL y cargarlos en un almacén de datos OLAP para análisis e informes de datos. Tomemos un ejemplo para entenderlo mejor.

Ejemplo

Supongamos que hay una empresa de fabricación que tiene varios departamentos, como ventas, recursos humanos, gestión de materiales, EWM, etc. Todos estos departamentos tienen bases de datos separadas que utilizan para mantener la información de su trabajo y cada base de datos tiene una tecnología, paisaje, tabla nombres, columnas, etc. Ahora, si la empresa desea analizar datos históricos y generar informes, todos los datos de estas fuentes de datos deben extraerse y cargarse en un almacén de datos para guardarlos para el trabajo analítico.

Una herramienta ETL extrae los datos de todas estas fuentes de datos heterogéneas, transforma los datos (como aplicar cálculos, unir campos, claves, eliminar campos de datos incorrectos, etc.) y los carga en un almacén de datos. Posteriormente, puede utilizar varias herramientas de Business Intelligence (BI) para generar informes, cuadros de mando y visualizaciones significativos con estos datos.

Diferencia entre ETL y herramientas de BI

Se utiliza una herramienta ETL para extraer datos de diferentes fuentes de datos, transformar los datos y cargarlos en un sistema DW; sin embargo, se utiliza una herramienta de BI para generar informes interactivos y ad-hoc para los usuarios finales, un tablero para la alta gerencia, visualizaciones de datos para las reuniones mensuales, trimestrales y anuales de la junta.

Las herramientas ETL más comunes incluyen - SAP BO Data Services (BODS), Informatica - Power Center, Microsoft - SSIS, Oracle Data Integrator ODI, Talend Open Studio, Clover ETL Open source, etc.

Algunas herramientas de BI populares incluyen: SAP Business Objects, SAP Lumira, IBM Cognos, JasperSoft, Microsoft BI Platform, Tableau, Oracle Business Intelligence Enterprise Edition, etc.

Proceso ETL

Analicemos ahora con un poco más de detalle los pasos clave involucrados en un procedimiento ETL:

Extrayendo los datos

Implica extraer los datos de diferentes fuentes de datos heterogéneas. La extracción de datos de un sistema transaccional varía según el requisito y la herramienta ETL en uso. Normalmente se realiza ejecutando trabajos programados fuera del horario comercial, como ejecutar trabajos por la noche o durante el fin de semana.

Transformando los datos

Implica transformar los datos en un formato adecuado que se pueda cargar fácilmente en un sistema DW. La transformación de datos implica aplicar cálculos, combinaciones y definir claves primarias y externas en los datos. Por ejemplo, si desea un porcentaje del ingreso total que no está en la base de datos, aplicará la fórmula del porcentaje en la transformación y cargará los datos. Del mismo modo, si tiene el nombre y el apellido de los usuarios en diferentes columnas, puede aplicar una operación de concatenar antes de cargar los datos. Algunos datos no requieren ninguna transformación; tales datos se conocen comodirect move o pass through data.

La transformación de datos también implica la corrección y limpieza de datos, la eliminación de datos incorrectos, la formación de datos incompletos y la corrección de errores de datos. También incluye integridad de datos y formateo de datos incompatibles antes de cargarlos en un sistema DW.

Carga de datos en un sistema DW

Implica cargar los datos en un sistema DW para informes e información analíticos. El sistema de destino puede ser un simple archivo plano delimitado o un almacén de datos.

Función de herramienta ETL

Un almacén de datos típico basado en herramientas ETL utiliza áreas de preparación, integración de datos y capas de acceso para realizar sus funciones. Normalmente es una arquitectura de 3 capas.

Staging Layer - La capa de ensayo o la base de datos de ensayo se utiliza para almacenar los datos extraídos de diferentes sistemas de datos fuente.
Data Integration Layer - La capa de integración transforma los datos de la capa de preparación y mueve los datos a una base de datos, donde los datos se organizan en grupos jerárquicos, a menudo llamados dimensionsy en facts y aggregate facts. La combinación de tablas de hechos y dimensiones en un sistema DW se denominaschema.
Access Layer - Los usuarios finales utilizan la capa de acceso para recuperar los datos para informes e información analíticos.

La siguiente ilustración muestra cómo interactúan las tres capas entre sí.

Las pruebas ETL se realizan antes de que los datos se muevan a un sistema de almacenamiento de datos de producción. A veces también se le llama comotable balancing o production reconciliation. Es diferente de las pruebas de bases de datos en términos de su alcance y los pasos a seguir para completarlo.

El objetivo principal de las pruebas ETL es identificar y mitigar los defectos de los datos y los errores generales que ocurren antes del procesamiento de los datos para los informes analíticos.

Pruebas ETL: tareas a realizar

Aquí hay una lista de las tareas comunes involucradas en las pruebas ETL:

Comprender los datos que se utilizarán para los informes.
Revisar el modelo de datos
Mapeo de origen a destino
Verificaciones de datos en datos de origen
Validación de paquetes y esquemas
Verificación de datos en el sistema de destino
Verificación de cálculos de transformación de datos y reglas de agregación
Comparación de datos de muestra entre el sistema de origen y el de destino
Comprobaciones de la integridad y la calidad de los datos en el sistema de destino
Prueba de rendimiento en datos

Tanto las pruebas ETL como las pruebas de bases de datos implican la validación de datos, pero no son lo mismo. Las pruebas ETL se realizan normalmente en datos en un sistema de almacenamiento de datos, mientras que las pruebas de bases de datos se realizan comúnmente en sistemas transaccionales donde los datos provienen de diferentes aplicaciones en la base de datos transaccional.

Aquí, hemos resaltado las principales diferencias entre las pruebas ETL y las pruebas de bases de datos.

Pruebas ETL

La prueba ETL implica las siguientes operaciones:

Validación del movimiento de datos desde el sistema de origen al de destino.
Verificación del recuento de datos en el sistema de origen y destino.
Verificación de extracción de datos, transformación según requerimiento y expectativa.
Verificar si las relaciones de la tabla (uniones y claves) se conservan durante la transformación.

Las herramientas de prueba de ETL comunes incluyen QuerySurge, Informaticaetc.

Prueba de base de datos

Las pruebas de bases de datos enfatizan más la precisión de los datos, la corrección de los datos y los valores válidos. Implica las siguientes operaciones:

Verificar si se mantienen las claves primarias y externas.
Verificar si las columnas de una tabla tienen valores de datos válidos.
Verificación de la precisión de los datos en columnas. Example - La columna de número de meses no debe tener un valor superior a 12.
Verificación de datos faltantes en columnas. Compruebe si hay columnas nulas que realmente deberían tener un valor válido.

Las herramientas de prueba de bases de datos comunes incluyen Selenium, QTPetc.

La siguiente tabla captura las características clave de las pruebas de base de datos y ETL y su comparación:

Función	Prueba de base de datos	Pruebas ETL
Objetivo principal	Integración y validación de datos	Extracción, transformación y carga de datos para informes de BI
Sistema aplicable	Sistema transaccional donde ocurre el flujo de negocios	Sistema que contiene datos históricos y no en un entorno de flujo empresarial
Herramientas comunes	QTP, Selenio, etc.	QuerySurge, Informatica, etc.
Necesidad de Negocios	Se utiliza para integrar datos de múltiples aplicaciones, Severo impacto.	Se utiliza para informes analíticos, información y previsiones.
Modelado	Método ER	Multidimensional
Tipo de base de datos	Normalmente se utiliza en sistemas OLTP.	Se aplica a sistemas OLAP
Tipo de datos	Datos normalizados con más uniones	Datos desnormalizados con menos combinaciones, más índices y agregaciones.

La categorización de las pruebas ETL se realiza en función de los objetivos de las pruebas y los informes. Las categorías de prueba varían según los estándares de la organización y también depende de los requisitos del cliente. Generalmente, las pruebas ETL se clasifican en función de los siguientes puntos:

Source to Target Count Testing - Implica la coincidencia del recuento de registros en los sistemas de origen y destino.
Source to Target Data Testing- Implica la validación de datos entre los sistemas de origen y destino. También implica la integración de datos y la verificación del valor umbral y la verificación de datos duplicados en el sistema de destino.
Data Mapping or Transformation Testing- Confirma el mapeo de objetos en los sistemas de origen y destino. También implica verificar la funcionalidad de los datos en el sistema de destino.
End-User Testing- Implica generar informes para que los usuarios finales verifiquen si los datos en los informes cumplen con las expectativas. Implica encontrar desviaciones en los informes y verificar los datos en el sistema de destino para la validación del informe.
Retesting - Implica corregir los errores y defectos en los datos en el sistema de destino y ejecutar los informes nuevamente para la validación de los datos.
System Integration Testing- Implica probar todos los sistemas individuales y luego combinar los resultados para encontrar si hay alguna desviación. Hay tres enfoques que se pueden utilizar para realizar esto: descendente, ascendente e híbrido.

Según la estructura de un sistema de almacenamiento de datos, las pruebas ETL (independientemente de la herramienta que se utilice) se pueden dividir en las siguientes categorías:

Prueba del nuevo sistema DW

En este tipo de pruebas, hay un nuevo sistema DW construido y verificado. Las entradas de datos se toman de los clientes / usuarios finales y también de diferentes fuentes de datos y se crea un nuevo almacén de datos. Posteriormente, los datos se verifican en el nuevo sistema con la ayuda de herramientas ETL.

Prueba de migración

En las pruebas de migración, los clientes tienen un almacén de datos y un ETL, pero buscan una nueva herramienta ETL para mejorar la eficiencia. Implica la migración de datos del sistema existente utilizando una nueva herramienta ETL.

Prueba de cambio

En las pruebas de cambio, se agregan nuevos datos de diferentes fuentes de datos a un sistema existente. Los clientes también pueden cambiar las reglas existentes para ETL o también se puede agregar una nueva regla.

Prueba de informe

La prueba de informes implica la creación de informes para la validación de datos. Los informes son el resultado final de cualquier sistema DW. Los informes se prueban según su diseño, los datos del informe y los valores calculados.

Las pruebas ETL son diferentes de las pruebas de bases de datos o de cualquier otra prueba convencional. Es posible que uno tenga que enfrentar diferentes tipos de desafíos al realizar las pruebas ETL. Aquí enumeramos algunos desafíos comunes:

Pérdida de datos durante el proceso ETL.
Datos incorrectos, incompletos o duplicados.
El sistema DW contiene datos históricos, por lo que el volumen de datos es demasiado grande y extremadamente complejo para realizar pruebas ETL en el sistema de destino.
Los probadores ETL normalmente no tienen acceso para ver los horarios de trabajo en la herramienta ETL. Apenas tienen acceso a las herramientas de informes de BI para ver el diseño final de los informes y los datos dentro de los informes.
Difícil de generar y construir casos de prueba, ya que el volumen de datos es demasiado alto y complejo.
Los probadores de ETL normalmente no tienen una idea de los requisitos de informes del usuario final y el flujo comercial de la información.
Las pruebas ETL implican varios conceptos complejos de SQL para la validación de datos en el sistema de destino.
A veces, a los evaluadores no se les proporciona la información de mapeo de origen a destino.
El entorno de prueba inestable retrasa el desarrollo y la prueba de un proceso.

Un probador ETL es principalmente responsable de validar las fuentes de datos, extraer datos, aplicar la lógica de transformación y cargar los datos en las tablas de destino.

Las responsabilidades clave de un probador ETL se enumeran a continuación.

Verifique las tablas en el sistema fuente

Implica las siguientes operaciones:

Cuenta cheque
Conciliar registros con los datos de origen
Verificación del tipo de datos
Asegúrese de que no se carguen datos de spam
Eliminar datos duplicados
Verifique que todas las llaves estén en su lugar

Aplicar lógica de transformación

La lógica de transformación se aplica antes de cargar los datos. Implica las siguientes operaciones:

Verificación de validación del umbral de datos, por ejemplo, el valor de edad no debe ser superior a 100.
Comprobación del recuento de registros, antes y después de aplicar la lógica de transformación.
Validación del flujo de datos desde el área de ensayo hasta las tablas intermedias.
Comprobación de llave sustituta.

Carga de datos

Los datos se cargan desde el área de preparación al sistema de destino. Implica las siguientes operaciones:

Registro de verificación de recuento de la tabla intermedia al sistema de destino.
Asegúrese de que los datos del campo clave no falten o sean nulos.
Compruebe si los valores agregados y las medidas calculadas se cargan en las tablas de hechos.
Verifique las vistas de modelado basadas en las tablas de destino.
Compruebe si se ha aplicado CDC en la tabla de carga incremental.
Verificación de datos en la tabla de dimensiones y verificación de la tabla de historial.
Verifique los informes de BI basados en la tabla de hechos y dimensiones cargada y según los resultados esperados.

Prueba de las herramientas ETL

Los probadores ETL también deben probar las herramientas y los casos de prueba. Implica las siguientes operaciones:

Pruebe la herramienta ETL y sus funciones
Pruebe el sistema de almacenamiento de datos ETL
Cree, diseñe y ejecute los planes de prueba y los casos de prueba.
Pruebe las transferencias de datos de archivos planos.

Es importante que defina la técnica de prueba ETL correcta antes de comenzar el proceso de prueba. Debe tener la aceptación de todas las partes interesadas y asegurarse de que se seleccione una técnica correcta para realizar las pruebas ETL. Esta técnica debe ser bien conocida por el equipo de prueba y debe conocer los pasos involucrados en el proceso de prueba.

Hay varios tipos de técnicas de prueba que se pueden utilizar. En este capítulo, analizaremos brevemente las técnicas de prueba.

Pruebas de validación de producción

Para realizar informes y análisis analíticos, los datos de su producción deben ser correctos. Esta prueba se realiza sobre los datos que se mueven al sistema de producción. Implica la validación de datos en el sistema de producción y su comparación con los datos de origen.

Prueba de recuento de origen a destino

Este tipo de prueba se realiza cuando el probador tiene menos tiempo para realizar la operación de prueba. Implica verificar el recuento de datos en los sistemas de origen y destino. No implica verificar los valores de los datos en el sistema de destino. Tampoco implica si los datos están en orden ascendente o descendente después de la asignación de datos.

Prueba de datos de origen a destino

En este tipo de prueba, un probador valida los valores de los datos desde el origen hasta el sistema de destino. Comprueba los valores de los datos en el sistema de origen y los valores correspondientes en el sistema de destino después de la transformación. Este tipo de prueba requiere mucho tiempo y normalmente se realiza en proyectos financieros y bancarios.

Prueba de validación de valor umbral / integración de datos

En este tipo de prueba, un evaluador valida el rango de datos. Todos los valores de umbral en el sistema de destino se verifican si están de acuerdo con el resultado esperado. También implica la integración de datos en el sistema de destino desde múltiples sistemas de origen después de la transformación y carga.

Example - El atributo de edad no debe tener un valor mayor que 100. En la columna de fecha DD / MM / AA, el campo del mes no debe tener un valor mayor que 12.

Prueba de migración de aplicaciones

Las pruebas de migración de aplicaciones normalmente se realizan automáticamente cuando se pasa de una aplicación antigua a un nuevo sistema de aplicaciones. Esta prueba ahorra mucho tiempo. Comprueba si los datos extraídos de una aplicación antigua son los mismos que los del nuevo sistema de aplicaciones.

Comprobación de datos y pruebas de restricción

Incluye la realización de varias verificaciones, como la verificación del tipo de datos, la verificación de la longitud de los datos y la verificación del índice. Aquí, un ingeniero de pruebas realiza los siguientes escenarios: clave principal, clave externa, NOT NULL, NULL y UNIQUE.

Prueba de verificación de datos duplicados

Esta prueba implica la verificación de datos duplicados en el sistema de destino. Cuando hay una gran cantidad de datos en el sistema de destino, es posible que haya datos duplicados en el sistema de producción que pueden resultar en datos incorrectos en los informes analíticos.

Los valores duplicados se pueden verificar con una declaración SQL como:

Select Cust_Id, Cust_NAME, Quantity, COUNT (*) 
FROM Customer
GROUP BY Cust_Id, Cust_NAME, Quantity HAVING COUNT (*) >1;

Aparecen datos duplicados en el sistema de destino debido a las siguientes razones:

Si no se define una clave principal, pueden aparecer valores duplicados.
Debido a mapeo incorrecto o problemas ambientales.
Errores manuales al transferir datos desde el origen al sistema de destino.

Pruebas de transformación de datos

La prueba de transformación de datos no se realiza ejecutando una sola instrucción SQL. Lleva mucho tiempo e implica ejecutar varias consultas SQL para cada fila para verificar las reglas de transformación. El probador debe ejecutar consultas SQL para cada fila y luego comparar la salida con los datos de destino.

Pruebas de calidad de datos

Las pruebas de calidad de datos implican realizar una verificación de números, una verificación de fechas, una verificación de nulos, una verificación de precisión, etc. Syntax Test para informar caracteres no válidos, orden incorrecto de mayúsculas / minúsculas, etc. y Reference Tests para comprobar si los datos están de acuerdo con el modelo de datos.

Prueba incremental

Se realizan pruebas incrementales para verificar si las sentencias Insert y Update se ejecutan según el resultado esperado. Esta prueba se realiza paso a paso con datos nuevos y antiguos.

Pruebas de regresión

Cuando realizamos cambios en las reglas de transformación y agregación de datos para agregar una nueva funcionalidad que también ayuda al evaluador a encontrar nuevos errores, se denomina Prueba de regresión. Los errores en los datos que vienen en las pruebas de regresión se denominan Regresión.

Nueva prueba

Cuando ejecuta las pruebas después de corregir los códigos, se llama volver a probar.

Prueba de integración del sistema

Las pruebas de integración de sistemas implican probar los componentes de un sistema individualmente y luego integrar los módulos. Hay tres formas en que se puede realizar la integración de un sistema: descendente, ascendente e híbrida.

Pruebas de navegación

Las pruebas de navegación también se conocen como probar el front-end del sistema. Implica la prueba del punto de vista del usuario final mediante la verificación de todos los aspectos del informe front-end; incluye datos en varios campos, cálculos y agregados, etc.

Las pruebas ETL cubren todos los pasos involucrados en un ciclo de vida ETL. Comienza con la comprensión de los requisitos comerciales hasta la generación de un informe resumido.

Los pasos comunes en el ciclo de vida de las pruebas ETL se enumeran a continuación:

Comprensión de los requisitos comerciales.
Validación del requerimiento comercial.
La estimación de prueba se utiliza para proporcionar el tiempo estimado para ejecutar casos de prueba y completar el informe de resumen.
La planificación de pruebas implica encontrar la técnica de prueba basada en las entradas según los requisitos comerciales.
Creación de escenarios de prueba y casos de prueba.
Una vez que los casos de prueba están listos y aprobados, el siguiente paso es realizar una verificación previa a la ejecución.
Ejecute todos los casos de prueba.
El último paso es generar un informe de resumen completo y presentar un proceso de cierre.

Los escenarios de prueba ETL se utilizan para validar un proceso de prueba ETL. La siguiente tabla explica algunos de los escenarios y casos de prueba más comunes que utilizan los probadores de ETL.

Escenarios de prueba	Casos de prueba
Validación de estructura	Implica validar la estructura de la tabla de origen y de destino según el documento de mapeo. El tipo de datos debe validarse en los sistemas de origen y destino. La longitud de los tipos de datos en el sistema de origen y de destino debe ser la misma. Los tipos de campos de datos y su formato deben ser los mismos en el sistema de origen y de destino. Validación de los nombres de las columnas en el sistema de destino.
Validación del documento de mapeo	Implica validar el documento de mapeo para asegurar que se haya proporcionado toda la información. El documento de mapeo debe tener un registro de cambios, mantener los tipos de datos, la longitud, las reglas de transformación, etc.
Validar restricciones	Implica validar las restricciones y asegurarse de que se apliquen en las tablas esperadas.
Comprobación de coherencia de datos	Implica verificar el uso indebido de restricciones de integridad como la clave externa. La longitud y el tipo de datos de un atributo pueden variar en diferentes tablas, aunque su definición sigue siendo la misma en la capa semántica.
Validación de integridad de datos	Implica verificar si todos los datos se cargan en el sistema de destino desde el sistema de origen. Contando el número de registros en los sistemas de origen y destino. Análisis de valor límite. Validando los valores únicos de claves primarias.
Validación de la exactitud de los datos	Implica validar los valores de los datos en el sistema de destino. En la tabla se encuentran datos incorrectos o inexactos. Los datos nulos, no únicos se almacenan cuando deshabilita la restricción de integridad en el momento de la importación.
Validación de transformación de datos	Implica crear una hoja de cálculo de escenarios para los valores de entrada y los resultados esperados y luego validar con los usuarios finales. Validación de la relación padre-hijo en los datos mediante la creación de escenarios. Usar perfiles de datos para comparar el rango de valores en cada campo. Validar si los tipos de datos en el almacén son los mismos que se mencionan en el modelo de datos.
Validación de la calidad de los datos	Implica realizar verificación de número, verificación de fecha, verificación de precisión, verificación de datos, verificación de nulos, etc. Example - El formato de fecha debe ser el mismo para todos los valores.
Validación nula	Implica comprobar los valores Null donde se menciona Not Null para ese campo.
Validación duplicada	Implica validar valores duplicados en el sistema de destino cuando los datos provienen de varias columnas del sistema de origen. Validación de claves primarias y otras columnas si hay valores duplicados según el requisito comercial.
Verificación de validación de fecha	Campo de fecha de validación para diversas acciones realizadas en el proceso ETL. Casos de prueba comunes para realizar la validación de fecha - From_Date no debe ser mayor que To_Date El formato de los valores de fecha debe ser adecuado. Los valores de fecha no deben tener valores basura ni valores nulos
Validación de datos completa menos consulta	Implica validar el conjunto de datos completo en las tablas de origen y destino mediante el uso de una consulta negativa. Necesitas realizar ambos source minus target y target minus source. Si la consulta menos devuelve un valor, eso debe considerarse como filas que no coinciden. Debe hacer coincidir las filas en el origen y el destino utilizando el Intersect declaración. El recuento devuelto por Intersect debe coincidir con los recuentos individuales de las tablas de origen y destino. Si la consulta menos no devuelve filas y el recuento de intersecciones es menor que el recuento de origen o el recuento de la tabla de destino, entonces la tabla contiene filas duplicadas.
Otros escenarios de prueba	Otros escenarios de prueba pueden ser verificar que el proceso de extracción no extrajo datos duplicados del sistema de origen. El equipo de pruebas mantendrá una lista de declaraciones SQL que se ejecutan para validar que no se hayan extraído datos duplicados de los sistemas de origen.
Limpieza de datos	Los datos no deseados deben eliminarse antes de cargarlos en el área de preparación.

El ajuste del rendimiento de ETL se utiliza para garantizar que un sistema ETL pueda manejar una carga esperada de múltiples usuarios y transacciones. El ajuste del rendimiento generalmente implica una carga de trabajo del lado del servidor en el sistema ETL. Se utiliza para probar la respuesta del servidor en un entorno multiusuario y para encontrar cuellos de botella. Estos se pueden encontrar en sistemas de origen y destino, mapeo de sistemas, configuraciones como propiedades de administración de sesiones, etc.

¿Cómo realizar el ajuste del rendimiento de las pruebas ETL?

Siga los pasos que se indican a continuación para realizar el ajuste del rendimiento de las pruebas ETL:

Step 1 - Encuentra la carga que se está transformando en producción.
Step 2 - Cree nuevos datos de esa misma carga o muévalos de los datos de producción a su servidor de rendimiento local.
Step 3 - Desactive el ETL hasta que genere la carga requerida.
Step 4 - Tome el recuento de los datos necesarios de las tablas de la base de datos.
Step 5- Anote la última ejecución de ETL y habilite ETL, para que reciba suficiente tensión para transformar toda la carga creada. Ejecutarlo
Step 6 - Una vez que ETL complete su ejecución, realice el recuento de los datos creados.

Indicadores clave de rendimiento

Descubra el tiempo total que tardó en transformar la carga.
Descubra si el tiempo de rendimiento ha mejorado o disminuido.
Compruebe que se haya extraído y transferido toda la carga esperada.

El objetivo de las pruebas ETL es lograr datos creíbles. La credibilidad de los datos se puede lograr haciendo que el ciclo de prueba sea más efectivo.

Una estrategia de prueba integral es la creación de un ciclo de prueba eficaz. La estrategia de prueba debe cubrir la planificación de prueba para cada etapa del proceso ETL, cada vez que los datos se mueven y establecer las responsabilidades de cada parte interesada, por ejemplo, analistas comerciales, equipo de infraestructura, equipo de control de calidad, administradores de bases de datos, desarrolladores y usuarios comerciales.

Para garantizar la preparación de la prueba desde todos los aspectos, las áreas clave en las que debe centrarse una estrategia de prueba son:

Alcance de la prueba: describa las técnicas de prueba y los tipos que se utilizarán.
Configuración del entorno de prueba.
Disponibilidad de datos de prueba: se recomienda tener datos de producción que cubran todos los requisitos comerciales críticos.
Criterios de aceptación de calidad y rendimiento de los datos.

En las pruebas ETL, la precisión de los datos se utiliza para garantizar que los datos se carguen con precisión en el sistema de destino según las expectativas. Los pasos clave para realizar la precisión de los datos son los siguientes:

Comparación de valores

La comparación de valores implica comparar los datos en el sistema de origen y destino con una transformación mínima o nula. Se puede hacer utilizando varias herramientas de prueba ETL, por ejemplo, Source Qualifier Transformation en Informatica.

Algunas transformaciones de expresión también se pueden realizar en pruebas de precisión de datos. Se pueden utilizar varios operadores de conjuntos en sentencias SQL para comprobar la precisión de los datos en los sistemas de origen y destino. Los operadores comunes son los operadores Menos e Intersecar. Los resultados de estos operadores pueden considerarse como una desviación de valor en el sistema de destino y de origen.

Verifique las columnas de datos críticos

Las columnas de datos críticos se pueden verificar comparando valores distintos en los sistemas de origen y de destino. Aquí hay una consulta de muestra que se puede usar para verificar columnas de datos críticos:

SELECT cust_name, Order_Id, city, count(*) FROM customer 
GROUP BY cust_name, Order_Id, city;

La verificación de los metadatos implica validar la estructura de la tabla de origen y de destino con el documento de mapeo. El documento de mapeo tiene detalles de las columnas de origen y destino, las reglas de transformación de datos y los tipos de datos, todos los campos que definen la estructura de las tablas en los sistemas de origen y destino.

Verificación de longitud de datos

La longitud del tipo de datos de la columna de destino debe ser igual o mayor que el tipo de datos de la columna de origen. Tomemos un ejemplo. Suponga que tiene los nombres y apellidos en la tabla de origen y la longitud de los datos para cada uno se define como 50 caracteres. Entonces, la longitud de los datos de destino para la columna de nombre completo en el sistema de destino debe ser un mínimo de 100 o más.

Verificación del tipo de datos

La verificación del tipo de datos implica verificar el tipo de datos de origen y de destino y asegurarse de que sean los mismos. Existe la posibilidad de que el tipo de datos de destino sea diferente de los datos de origen después de una transformación. Por lo tanto, también es necesario verificar las reglas de transformación.

Verificación de restricción / índice

La verificación de restricciones implica verificar los valores del índice y las restricciones según el documento de especificación de diseño. Todas las columnas que no pueden tener valores nulos deben tener la restricción No nulo. Las columnas de claves primarias están indexadas según el documento de diseño.

Realizar transformaciones de datos es un poco complejo, ya que no se puede lograr escribiendo una sola consulta SQL y luego comparando la salida con el objetivo. Para la transformación de datos de prueba de ETL, es posible que deba escribir varias consultas SQL para cada fila para verificar las reglas de transformación.

Para empezar, asegúrese de que los datos de origen sean suficientes para probar todas las reglas de transformación. La clave para realizar una prueba ETL exitosa para las transformaciones de datos es seleccionar los datos de muestra correctos y suficientes del sistema de origen para aplicar las reglas de transformación.

Los pasos clave para ETL Testing Data Transformation se enumeran a continuación:

El primer paso es crear una lista de escenarios de datos de entrada y los resultados esperados y validarlos con el cliente comercial. Este es un buen enfoque para la recopilación de requisitos durante el diseño y también podría usarse como parte de las pruebas.
El siguiente paso es crear los datos de prueba que contienen todos los escenarios. Utilice un desarrollador ETL para automatizar todo el proceso de completar los conjuntos de datos con la hoja de cálculo de escenarios para permitir versatilidad y movilidad debido a que es probable que los escenarios cambien.
A continuación, utilice los resultados del perfil de datos para comparar el rango y el envío de valores en cada campo entre los datos de destino y de origen.
Valide el procesamiento preciso de los campos generados por ETL, por ejemplo, claves sustitutas.
La validación de los tipos de datos dentro del almacén es la misma que se especificó en el modelo o diseño de datos.
Cree escenarios de datos entre tablas que prueben la integridad referencial.
Valide las relaciones de padres a hijos en los datos.
El paso final es realizar lookup transformation. Su consulta de búsqueda debe ser directa sin ningún tipo de agregación y se espera que devuelva solo un valor por la tabla de origen. Puede unirse directamente a la tabla de búsqueda en el calificador de origen como en la prueba anterior. Si este no es el caso, escriba una consulta uniendo la tabla de búsqueda con la tabla principal en el origen y compare los datos en las columnas correspondientes en el destino.

La verificación de la calidad de los datos durante las pruebas ETL implica realizar controles de calidad en los datos cargados en el sistema de destino. Incluye las siguientes pruebas:

Verificación de número

El formato de número debe ser el mismo en todo el sistema de destino. Por ejemplo, en el sistema fuente, el formato de numeración de las columnas esx.30, pero si el objetivo es solo 30, entonces tiene que cargar sin prefijar x. en el número de columna de destino.

Verificación de fecha

El formato de fecha debe ser coherente tanto en el sistema de origen como en el de destino. Por ejemplo, debería ser el mismo en todos los registros. El formato estándar es: aaaa-mm-dd.

Verificación de precisión

El valor de precisión debe mostrarse como se esperaba en la tabla de destino. Por ejemplo, en la tabla de origen, el valor es 15.2323422, pero en la tabla de destino, debería mostrarse como 15.23 o una ronda de 15.

Verificación de datos

Implica verificar los datos según los requisitos comerciales. Los registros que no cumplen con ciertos criterios deben filtrarse.

Example - Solo aquellos registros cuyo date_id> = 2015 y Account_Id! = '001' deben cargarse en la tabla de destino.

Verificación nula

Algunas columnas deben tener Null según el requisito y los posibles valores para ese campo.

Example - La columna Fecha de terminación debe mostrar Nulo a menos que y hasta que su Columna de estado activo sea "T" o "Fallecido".

Otros cheques

Las comprobaciones comunes como From_Date no deben ser mayores que To_Date.

La verificación de la integridad de los datos se realiza para verificar que los datos en el sistema de destino cumplan con las expectativas después de la carga.

Las pruebas comunes que se pueden realizar para esto son las siguientes:

Verificación de funciones agregadas (suma, máximo, mínimo, recuento),
Verificar y validar los recuentos y los datos reales entre el origen y el destino para columnas sin transformaciones o con transformaciones simples.

Validación de recuento

Compare el recuento del número de registros en las tablas de origen y de destino. Se puede hacer escribiendo las siguientes consultas:

SELECT count (1) FROM employee; 
SELECT count (1) FROM emp_dim;

Validación del perfil de datos

Implica verificar las funciones agregadas como recuento, suma y máximo en las tablas de origen y destino (hecho o dimensión).

Validación del perfil de datos de columna

Implica comparar los valores distintos y el recuento de filas para cada valor distinto.

SELECT city, count(*) FROM employee GROUP BY city; 
SELECT city_id, count(*) FROM emp_dim GROUP BY city_id;

Validación de datos duplicados

Implica validar la clave principal y la clave única en una columna o en una combinación de columnas que deben ser únicas según los requisitos comerciales. Puede utilizar la siguiente consulta para realizar la validación de datos duplicados:

SELECT first_name, last_name, date_of_joining, count (1) FROM employee
GROUP BY first_name, last_name HAVING count(1)>1;

La recuperación de la copia de seguridad de un sistema está planificada para garantizar que el sistema se restaure lo antes posible de una falla y las operaciones se reanuden lo antes posible sin perder ningún dato importante.

Las pruebas de recuperación de ETL Backup se utilizan para garantizar que el sistema de almacenamiento de datos se recupere correctamente del hardware, software o de una falla de la red con pérdida de datos.

Se debe preparar un plan de respaldo adecuado para garantizar la máxima disponibilidad del sistema. Los sistemas de respaldo deben poder restaurarse con facilidad y deben hacerse cargo del sistema fallido sin pérdida de datos.

Prueba ETL La recuperación de la copia de seguridad implica exponer la aplicación o el sistema DW a condiciones extremas para cualquier componente de hardware, falla del software, etc. El siguiente paso es asegurarse de que se inicie el proceso de recuperación, se realice la verificación del sistema y se logre la recuperación de datos.

Las pruebas ETL se realizan principalmente mediante secuencias de comandos SQL y recopilación de datos en hojas de cálculo. Este enfoque para realizar pruebas ETL es muy lento y requiere mucho tiempo, es propenso a errores y se realiza con datos de muestra.

Desafío técnico en pruebas ETL manuales

Su equipo de prueba ETL escribe consultas SQL para probar datos en un sistema de almacén y necesitan ejecutarlas manualmente usando un editor SQL y luego colocar los datos en una hoja de cálculo de Excel y compararlos manualmente. Este proceso es lento, requiere muchos recursos e ineficaz.

Existen varias herramientas disponibles en el mercado para automatizar este proceso. Las herramientas de prueba ETL más comunes son QuerySurge e Informatica Data Validation.

QuerySurge

QuerySurge es una solución de prueba de datos diseñada para probar Big Data, Data Warehouses y el proceso ETL. Puede automatizar todo el proceso para usted y encajar perfectamente en su estrategia DevOps.

Las características clave de QuerySurge son las siguientes:

Tiene Query Wizards para crear QueryPairs de prueba rápida y fácilmente sin que el usuario tenga que escribir ningún SQL.
Tiene una biblioteca de diseño con fragmentos de consulta reutilizables. También puede crear QueryPairs personalizados.
Puede comparar datos de archivos de origen y almacenes de datos con el almacén de datos de destino o el almacén de Big Data.
Puede comparar millones de filas y columnas de datos en minutos.
Permite al usuario programar pruebas para que se ejecuten (1) inmediatamente, (2) en cualquier fecha / hora o (3) automáticamente después de que finalice un evento.
Puede producir informes informativos, ver actualizaciones y enviar automáticamente los resultados por correo electrónico a su equipo.

Para automatizar todo el proceso, su herramienta ETL debe iniciar QuerySurge a través de la API de línea de comandos después de que el software ETL complete su proceso de carga.

QuerySurge se ejecutará automáticamente y sin supervisión, ejecutando todas las pruebas y luego enviando un correo electrónico a todos los miembros del equipo con los resultados.

Al igual que QuerySurge, Informatica Data Validation proporciona una herramienta de prueba ETL que le ayuda a acelerar y automatizar el proceso de prueba ETL en el entorno de desarrollo y producción. Le permite ofrecer una cobertura de prueba completa, repetible y auditable en menos tiempo. ¡No requiere conocimientos de programación!

Para probar un sistema de almacenamiento de datos o una aplicación de BI, es necesario tener un enfoque centrado en los datos. Las mejores prácticas de pruebas ETL ayudan a minimizar el costo y el tiempo para realizar las pruebas. Mejora la calidad de los datos que se cargarán en el sistema de destino, lo que genera paneles e informes de alta calidad para los usuarios finales.

A continuación, enumeramos algunas de las mejores prácticas que se pueden seguir para las pruebas ETL:

Analizar los datos

Es extremadamente importante analizar los datos para comprender los requisitos a fin de configurar un modelo de datos correcto. Dedicar tiempo a comprender los requisitos y tener un modelo de datos correcto para el sistema de destino puede reducir los desafíos de ETL. También es importante estudiar los sistemas de origen, la calidad de los datos y crear reglas de validación de datos correctas para los módulos ETL. Se debe formular una estrategia ETL basada en la estructura de datos de los sistemas de origen y destino.

Corregir datos incorrectos en el sistema de origen

Los usuarios finales normalmente están al tanto de los problemas de datos, pero no tienen idea de cómo solucionarlos. Es importante encontrar estos errores y corregirlos antes de que lleguen al sistema ETL. Una forma común de resolver esto es en el momento de ejecución de ETL, pero la mejor práctica es encontrar los errores en el sistema fuente y tomar medidas para corregirlos en el nivel del sistema fuente.

Encuentre una herramienta ETL compatible

Una de las mejores prácticas comunes de ETL es seleccionar una herramienta que sea más compatible con los sistemas de origen y destino. La capacidad de la herramienta ETL para generar scripts SQL para los sistemas de origen y destino puede reducir el tiempo y los recursos de procesamiento. Le permite a uno procesar la transformación en cualquier lugar dentro del entorno que sea más apropiado.

Supervisar trabajos ETL

Otra de las mejores prácticas durante la implementación de ETL es la programación, auditoría y supervisión de trabajos ETL para garantizar que las cargas se realicen según las expectativas.

Integrar datos incrementales

A veces, las tablas del almacén de datos son más grandes y no es posible actualizarlas durante cada ciclo ETL. Las cargas incrementales aseguran que solo los registros cambiados desde la última actualización se incorporen al proceso ETL y tienen un gran impacto en la escalabilidad y el tiempo necesario para actualizar el sistema.

Normalmente, los sistemas de origen no tienen marcas de tiempo ni una clave principal para identificar los cambios fácilmente. Estos problemas pueden ser muy costosos si se identifican en las etapas posteriores del proyecto. Una de las mejores prácticas de ETL es cubrir estos aspectos en el estudio inicial del sistema fuente. Este conocimiento ayuda al equipo de ETL a identificar los problemas de captura de datos modificados y determinar la estrategia más adecuada.

Escalabilidad

Es una buena práctica asegurarse de que la solución ETL ofrecida sea escalable. En el momento de la implementación, es necesario asegurarse de que la solución ETL sea escalable con los requisitos comerciales y su crecimiento potencial en el futuro.

↰ Previous page