Francisco MinguezDatos e IA

Objeto de evidencia

Entrega profesional de ingeniería de datos

Caso de estudio

Modernización de pipeline analítico

Migré un proceso analítico recurrente desde una implementación heredada en SQL Server a un flujo modular en Databricks y PySpark, con controles de calidad de datos, validación y reconciliación integrados en la entrega.

Entrada directa: esta página se sostiene sola. No implica un recorrido de Decision Room desde Home.

Forma, Procedencia y Estado son dimensiones separadas, no una sola insignia.

Forma
Trabajo profesional
Procedencia
ProfesionalMixto
Estado
Publicado
Qué es
Entrega profesional de data engineering migrando un proceso analítico recurrente desde lógica heredada de SQL Server a Databricks y PySpark.
Pregunta / contexto
¿Cómo modernizar un cálculo analítico frágil sin perder trazabilidad de las reglas de negocio?
Qué se hizo
Mapeé la lógica heredada, reconstruí en Databricks/PySpark, añadí controles de calidad y validación, reconcilié salidas y preparé el traspaso.
Qué se aprendió
La reconciliación explícita y los componentes modulares hacen discutible la migración; los artefactos privados del cliente no entran en el registro público.
Qué sostiene aquí
Experiencia profesional de entrega en modernización de pipelines y disciplina de validación.
Qué no demuestra
ROI cuantificado, KPIs de cliente, un entorno privado reproducible ni garantías de producción.

No se incluyen datos, código ni arquitectura específicos de la organización.

Contexto

Trabajé en un entorno de datos financieros sobre un cálculo analítico recurrente que dependía de un proceso heredado en SQL Server. Mi trabajo abarcó comprender la lógica existente, migrar el flujo a Databricks y PySpark, añadir controles de calidad y validación, y preparar la transferencia.

Por qué los procesos analíticos heredados se vuelven difíciles de cambiar

Los procesos analíticos heredados suelen crecer como una mezcla de SQL, procedimientos almacenados y reglas de negocio implícitas. Cuando la lógica es difícil de aislar, los cambios pequeños se vuelven arriesgados, la validación es lenta y los equipos dudan a la hora de modificar o escalar el proceso con seguridad. Esa era la situación en la que trabajé: un cálculo recurrente difícil de mantener, adaptar y operar con confianza.

De qué me hice responsable

  • Mapear la lógica de cálculo heredada, las dependencias y las salidas esperadas.
  • Reconstruir el flujo en Databricks con PySpark.
  • Introducir componentes de transformación reutilizables y parametrizados.
  • Añadir controles automatizados de calidad de datos y validación estadística.
  • Reconciliar las salidas migradas frente al proceso heredado.
  • Preparar documentación técnica y material de traspaso para los equipos que iban a operar el proceso.

Restricciones de la entrega

  • Las reglas de negocio debían seguir siendo trazables mientras cambiaba la implementación.
  • Las diferencias entre las salidas heredadas y las migradas exigían una reconciliación explícita.

Cómo abordé el trabajo

  1. 01

    Estudiar la lógica existente

    Empecé documentando reglas de cálculo, dependencias, salidas esperadas y criterios de aceptación. Antes de reescribir nada, necesitaba una imagen clara de lo que el proceso heredado debía producir.

  2. 02

    Migrar a Databricks y PySpark

    Reimplementé el flujo como transformaciones PySpark en Databricks, para que el proceso pudiera desarrollarse, probarse y operarse como un pipeline de datos modular, en lugar de como un cálculo heredado frágil.

  3. 03

    Hacer el flujo modular y parametrizado

    Descompuse la lógica en componentes reutilizables con parámetros explícitos. Así el proceso era más fácil de entender, ajustar y reutilizar sin reescribir todo el cálculo cada vez que cambiaba un requisito.

  4. 04

    Añadir calidad, validación y reconciliación

    Introduje comprobaciones automatizadas de calidad de datos, validación estadística y reconciliación de salidas frente al flujo heredado. La idea era hacer visibles y discutibles las diferencias, no ocultarlas.

  5. 05

    Documentar y traspasar

    Preparé documentación sobre requisitos de ejecución, limitaciones conocidas y consideraciones de integración, para que quienes operaran el proceso entendieran cómo ejecutarlo y dónde debían prestar atención.

Qué entregué

  • Flujo migrado en Databricks y PySpark.
  • Componentes de transformación reutilizables y parametrizados.
  • Controles automatizados de calidad de datos.
  • Flujo de validación estadística y reconciliación.
  • Documentación técnica y material de traspaso.

Tecnologías que utilicé

  • PySpark
  • Databricks
  • SQL Server
  • SQL
  • Calidad de datos
  • Validación estadística

Qué muestra esta experiencia

  • Experiencia profesional

    Alcance de entrega

    Migración a Databricks y PySpark con controles de calidad y validación

    Este caso recoge el alcance, las responsabilidades y los entregables de mi trabajo.

Evidencia y límites

  • Este caso no proporciona una copia reproducible del entorno original.
  • No atribuyo mejoras cuantificadas de rendimiento ni impacto de negocio medido.

Qué revisaría en un caso semejante

  • Cómo funcionarían la orquestación, los reintentos y la recuperación ante fallos en el entorno de destino.
  • Si los contratos de datos y la gestión de cambios de esquema son lo bastante explícitos.
  • Control de acceso y gobernanza de datos sensibles alrededor del proceso.
  • Monitorización, linaje y alertas operativas.
  • Ajuste de coste de cómputo y rendimiento bajo cargas realistas.
  • Reconciliación, rollback y una ruta de migración controlada desde el proceso heredado.

Dónde resulta útil esta experiencia

  • Migración de procesos analíticos SQL o SAS a PySpark.
  • Modernización de pipelines y flujos en Databricks.
  • Diseño de ETL y calidad de datos.
  • Automatización de procesos analíticos.
  • Evaluación técnica y hoja de ruta de migración.
  • Documentación de entrega y traspaso.

Implementación pública relacionada

  • Ver el repositorio público

    Data Quality Pipeline Lab es una implementación pública independiente. Usa datos sintéticos, reglas sintéticas y una arquitectura sintética. No reproduce código, datos ni sistemas de empleadores. Demuestra contratos, cuarentena, reconciliación, idempotencia, tests y CI.

Siguientes pasos

Volver a proyectos