El ETL de un banco a Azure Data Factory

Contexto

Un banco grande del Caribe. Su almacén de datos alimentaba los reportes y la analítica de todo el banco, y yo dirigía el equipo del almacén dentro de la Unidad de Transformación Digital.

Fue el mayor volumen de datos de mi carrera: fotos diarias de las cuentas, de unos 1,5 millones de filas al día, guardadas por 7 años, y 10 años de transacciones de todo el banco, de 500 000 a más de 999 000 al día.

Problema

Las cargas del almacén corrían en Pentaho Data Integration y tardaban demasiado para terminar dentro de la ventana nocturna.

Restricciones

• Datos bancarios y sus controles.
• Fuentes en Oracle, SQL Server y DB2.
• Ventanas nocturnas de las que dependían los reportes de cada mañana.
• Entregas en sprints ágiles, junto con otros trabajos.

Arquitectura

El diagrama, paso a paso

1. Fuentes: Oracle, SQL Server, DB2 y archivos.
2. Pipelines de Azure Data Factory que mueven los datos.
3. Zona de preparación en el almacén.
4. Transformaciones en SQL y PL/SQL.
5. Modelos en estrella.
6. Reportes en Tableau y BI Publisher.

El almacén también pasó de Oracle en servidores propios a Oracle Cloud.

Decisiones clave

• ELT en vez de ETL. Data Factory movía los datos y el almacén hacía las transformaciones, donde ya estaban el SQL y el PL/SQL y donde corrían más rápido.
• Migrar por lotes del tamaño de un sprint. Con el scrum master y los product owners, los 400 procesos se volvieron épicas y tareas de sprint, así cada lote salía a producción y se comprobaba antes del siguiente.
• Automatizar las comprobaciones. Scripts de validación y de perfilado comparaban cada carga migrada con la anterior, lo que además redujo las pruebas manuales en un 40 %.

Resultado

400 procesos migrados y tiempos de carga 50 % más cortos.

Mi papel

Líder técnico y gerente del equipo del almacén de datos, con seis personas a mi cargo. Diseñé el patrón ELT, el plan de migración y la validación.

Lo que no puedo contar

El nombre del banco, los nombres de las tablas y los sistemas internos.