IEBSchool - La Escuela de los Negocios y los Emprendedores

Contenido destacado del mes

Procesos ETL. Descripción general y particularidades

Los procesos ETL, de sus siglas en ingles Extract, transform and load, son un conjunto de técnicas que permiten la extracción o migración de un origen o varios orígenes de datos, de una o diversa naturaleza hacia un destino. Durante … [ leer más ]

Lo más leído

Tags

ETL

Procesos ETL. Descripción general y particularidades

8 noviembre, 2019, en Sin categoría por Roberto Madrid
Tags:

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Los procesos ETL, de sus siglas en ingles Extract, transform and load, son un conjunto de técnicas que permiten la extracción o migración de un origen o varios orígenes de datos, de una o diversa naturaleza hacia un destino.

Durante el proceso generalmente es necesario una transformación de los datos, bien por simplificación, masterización o normalización, depuración, estandarización, etc, a fin de facilitar un análisis de estos.

Figura 1. Esquema General ETL

grafico ETL general

En general se establece un repositorio intermedio, determinado Data Mart (o muchas veces simplemente Mart) que recopilara toda la información antes de volcarla en el aplicativo final, este Mart, a veces puede ser incompatibles en entornos de tiempo real con volúmenes pequeños de datos, o entornos donde se busque un tiempo de respuesta corto.

Asi mismo entre el origen de datos y el Destino de los datos o el mart se establece lo que se conoce como Staging Area, que será un almacenamiento intermedio utilizado para los procesos antes descritos.

La carga de datos puede ser Full o Delta, en el primer caso se vuelcan todos los datos  y en el segundo solamente los datos no almacenados en el Mart previamente.

Figura 2. Ejemplo de Diagrama ETL.

Diagrama ETL

En el proceso ETL, entre otras, las tareas frecuentes a realizar son:

  • Unificación de tipos.
    • En sql server, cualquier cadena de caracteres desde los orígenes a varchar o nvarchar para soportar caracteres Unicode y evitar incompatibilidades de caracteres o problemas con funciones Trim (eliminación espacios en blanco).
    • Conversión de tipos numéricos almacenados como texto en origen a tipos numéricos u otras conversiones de tipo.
  • Transformación de datos.
    • Sustitución de valores nulos
    • Sustitución de caracteres, por ejemplo, caracteres Unicode a caracteres no Unicode.
    • Desglose en columnas de un campo que contenga varios campos separados por tabulaciones u otro carácter.
  • Campos calculados.
    • Integración de varios campos en uno mediante una formula, por ejemplo, conversión de facturas en diferentes monedas desde diferentes orígenes traduciendo a una única moneda, (dólares o euros), aplicando el tipo de cambio de la fecha de factura o el tipo de cambio del cierre del mes contable de la factura.
  • Estandarización de bases de datos.
    • Garantizar formas normales el Mart o Staging Area
    • Creación de índices y claves.
  • Validación de datos.
    • Eliminación de datos no válidos.
    • Eliminación o tratamiento de inconsistencias.
    • Garantizar integridad de datos. Por ejemplo, datos duplicados.

En cuanto a la carga de datos, la elección de opciones Full o Delta objetivamente es mejor una carga de datos Delta, es decir que solo vuelque las diferencias con respecto a la ultima carga,sin embargo depende de diferentes factores.

  • Orígenes de datos. Hay veces que la naturaleza del origen de datos imposibilita determinar cuales han sido las últimas modificaciones con respecto a la última carga.
  • Volumen de datos.
    • Si el volumen de datos es pequeño es posible que no se precise de un Mart, por consiguiente la carga seria Full.
    • Si el volumen es muy grande el tiempo y coste computacional podría ser muy elevado para una carga Full.
  • Velocidad de respuesta. En entornos donde se requiera una cierto tiempo de respuesta una carga Full puede no ser viable, sin embargo, en entornos donde la velocidad sea irrelevante, por ejemplo un Dashboard mensual una carga Full seria válida y mas facil de desarrollar.
  • Niveles de Servicio. En algunos entornos, como Azure SQL se paga por lo que llaman DTU’s, (que es un calculo de transacciones, uso de memoria, procesador, etc) con lo cual una gran carga podría comprometer el la carga si existen time outs, es por eso que una carga Full puede requerir incrementar el coste.

Históricamente era un proceso a cargo administradores de bases de datos (también conocidos como dba’s), si bien hoy en día, con la aparición de múltiples herramientas es una labor habitualmente desarrollada por programadores y desarrolladores en general.

Algunos ejemplos de herramientas habituales son:

Si bien en entornos SSMS de Microsoft, también existen alternativas como OPENDATASOURCE o bien OPENROWSET ademas de las herramientas de conexión que Microsoft proporciona en entornos 365 como Powerquery, Flow, o incluso powerapps para pequeñas aplicaciones.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

comentarios para esta entrada