Qué es un proceso ETL y cuándo lo necesita una empresa

Qué es un proceso ETL

ETL son las siglas en inglés de extract, transform, load: extraer, transformar y cargar. Un proceso ETL es un programa que se ejecuta cada cierto tiempo, o cuando ocurre algo, lee datos de una o varias fuentes, los adapta a un formato común y los guarda en un destino preparado para consultarlos, normalmente una base de datos o un almacén de datos.

Cada paso tiene su trabajo. Al extraer se leen los registros de un programa de facturación, una hoja de cálculo, una API o un archivo publicado por un organismo. Al transformar se unifican fechas e importes, se eliminan duplicados, se cruzan tablas y se calculan campos nuevos. Al cargar se escribe el resultado en el destino. Yo lo preparo para que una segunda ejecución con los mismos datos no duplique filas. Un ejemplo corriente: cada noche se leen los pedidos de la tienda online y las facturas del programa de contabilidad, se relacionan por número de pedido y se guardan juntos para que un cuadro de mando que se actualice solo los muestre a primera hora.

ETL y ELT: cambia el sitio donde se transforma

En un proceso ELT se invierte el orden de los dos últimos pasos. Los datos se copian casi tal como llegan al destino y la transformación se hace después, dentro de él, con consultas SQL que se ejecutan en el propio almacén. Tiene sentido cuando el destino puede hacer ese cálculo con soltura y cuando interesa conservar el dato en bruto para rehacer un indicador si cambia su definición.

ETL encaja mejor cuando hay que limpiar o recortar el dato antes de que llegue al destino. Pasa, por ejemplo, si una fuente trae datos personales que el análisis no necesita, o si el destino es una base de datos sencilla a la que no conviene cargar con transformaciones pesadas. En la práctica, muchos procesos mezclan los dos enfoques: una limpieza mínima al extraer y el resto de cálculos en el destino. En cada encargo decido dónde vive cada regla de transformación y la dejo escrita en un único sitio.

Cuándo lo necesita una pyme

Muchas empresas ya tienen un ETL sin llamarlo así. Alguien descarga cada lunes un informe de un programa, lo pega en una hoja, corrige a mano las columnas y lo cruza con otra. Funciona mientras esa persona esté disponible y no se equivoque. Suele merecer la pena automatizarlo cuando la tarea se repite a menudo, cuando las cifras de dos departamentos no coinciden porque cada uno las prepara a su manera o cuando una decisión diaria depende de datos que llegan tarde.

Hay casos en los que no lo recomendaría. Si toda la información está en un solo programa y sus informes ya responden a lo que necesitas, una carga aparte solo añade algo más que mantener. Una migración que se hace una única vez se resuelve con un proceso de un solo uso, bien comprobado, sin programar ejecuciones. Y si nadie va a revisar los avisos cuando una carga falle, conviene resolver eso antes de automatizar.

Qué reviso y qué decido antes de construirlo

Empiezo por las fuentes. De cada una anoto cómo se accede, con qué cuenta, cada cuánto cambia y si sus condiciones permiten el uso previsto; en qué reviso antes de integrar una fuente de datos lo explico con más detalle. Después busco cómo reconocer un mismo registro en dos fuentes distintas. Un cliente con el nombre escrito de dos formas o un pedido sin referencia común obligan a fijar una regla de cruce y a decidir qué pasa con los casos que no encajan.

Con eso dejo por escrito varias decisiones:

• Si cada ejecución carga todo de nuevo o solo lo que ha cambiado desde la anterior.
• Qué errores detienen la carga y cuáles apartan el registro para revisarlo después.
• Dónde se guardan el origen y la fecha de obtención de cada dato.
• Qué datos personales hacen falta en el destino y cuáles se quedan en la fuente.

El último punto conviene decidirlo pronto. Copiar la tabla de clientes completa en un almacén de análisis es lo más cómodo, pero el artículo 5.1.c del Reglamento General de Protección de Datos pide que los datos personales sean «adecuados, pertinentes y limitados a lo necesario» en relación con sus fines. Propongo qué campos copiar y lo contrastamos con quien lleve la protección de datos en tu empresa. La valoración jurídica le corresponde a esa persona o a tu asesor.

Qué herramientas existen

Para empezar no hace falta una plataforma grande. Las opciones se agrupan en unas pocas familias:

• Scripts escritos en un lenguaje de programación de uso general, lanzados por el programador de tareas del servidor.
• Orquestadores, que encadenan pasos, los reintentan si fallan y guardan el historial de cada ejecución.
• Plataformas de integración con conectores ya preparados para programas y servicios habituales, de pago o de código abierto.
• Las funciones de carga y transformación de la propia base de datos o del almacén, que es donde suele vivir la parte de transformación de un ELT.
• Los conectores de algunas hojas de cálculo y herramientas de visualización, que bastan para una consulta sencilla.

Para elegir miro el volumen de datos, cada cuánto se ejecuta la carga, quién la mantendrá cuando termine el encargo y lo que cuesta cada opción en licencias e infraestructura. Un conector comercial ahorra desarrollo a cambio de depender de su proveedor. Un script propio da más control y exige que alguien sepa leerlo. Trabajo con software de código abierto, lo que no elimina los costes de servidor ni cambia las condiciones de uso de los datos que se cargan.

Cómo lo pruebo y qué entrego

Antes de dar una carga por buena la ejecuto varias veces con el mismo lote, para comprobar que no duplica filas. Comparo sus totales con un periodo ya cerrado que tu equipo conozca y, si no coinciden, busco la causa antes de seguir. También le paso archivos con columnas renombradas, fechas en otro formato o registros a medias. Quiero ver que se detiene o aparta lo que debe y que el aviso llega a la persona acordada.

La entrega incluye el código del proceso, el modelo de datos del destino, la programación de las ejecuciones, los avisos y una documentación que explica cada regla de transformación y cómo repetir una carga. Salvo que lo acordemos, quedan fuera la corrección de los datos en su origen, los cambios de configuración de los programas de tu empresa y las licencias de servicios externos. Tampoco puedo garantizar que una fuente ajena siga disponible o mantenga su formato.

Una primera fase

Un encargo así puede empezar por una fase corta. En ella entrego el inventario de las fuentes con sus permisos, las reglas de cruce y de calidad revisadas contigo y una carga de prueba con datos reales de un periodo cerrado que tengas autorización para usar. Trabajo en remoto, con los accesos que tu empresa me facilite. Con ese resultado decides si construir la carga programada, conmigo o con otra persona.

Si alguna fuente es pública, como los conjuntos del portal de datos abiertos de la Región de Murcia, la fase incluye revisar su licencia y si de verdad se actualiza. El resto del trabajo, desde el modelo de datos hasta la salida por API, cuadro de mando o aplicación, lo explico en la página de ingeniería de datos e integraciones.