paulasilvatech ASP Personas del SDLC Agéntico v1.0.0
EN PT ES
15 data · Implementation

Ingeniero de Datos

Pipelines y calidad de datos.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El Data Engineer es la persona que construye y opera los pipelines de datos de los que el resto de la organización depende. En un SDLC AI-nativo, el Data Engineer opera un agente Pipeline Keeper, cuatro slash prompts y un catálogo validado de MCPs que abarcan Azure Data Factory, Synapse, Fabric, SQL Database y Cosmos DB — no un bosque de notebooks frágiles.

Resumen ejecutivo

El Data Engineer es responsable del movimiento, transformación y calidad de los datos entre sistemas. En un SDLC AI-nativo, los deliverables primarios son pipelines idempotentes, migraciones de schema probadas, quality gates ejecutadas en CI y un mapa de lineage que cualquier stakeholder pueda leer. El kit de herramientas es fijo: el agente Pipeline Keeper, los slash prompts /etl-scaffold, /schema-diff, /quality-gate, /lineage-map, instrucciones con alcance para SQL y definiciones de pipeline, y MCPs validados que alcanzan Azure Data Factory, Azure Synapse, Microsoft Fabric, Azure SQL Database y Azure Cosmos DB.

El Data Engineer protege a la organización de los modos de falla de datos más comunes: drift silencioso de schema, nulos faltantes que se convierten en joins envenenados, datos que llegan tarde rompiendo contratos downstream y pipelines que tienen éxito mientras producen resultados sutilmente incorrectos. Cada pipeline se entrega con pruebas, una entrada de lineage y un data-quality gate.

El trabajo de datos es ahora inseparable del trabajo de software. Los pipelines son código, revisados en GitHub, probados en Actions, gobernados por Microsoft Purview y observados a través de Azure Monitor.

Rol y responsabilidades

Piensa en el Data Engineer como el maestro de puentes de un sistema municipal de agua. Las tuberías mueven agua desde depósitos hasta vecindarios; medidores, válvulas y estaciones de prueba aseguran la calidad; cualquier fuga o contaminación debe ser detectada y desviada antes de la llave de cocina. En un SDLC AI-nativo, el Data Engineer es dueño de esa plomería para hechos en lugar de líquido.

Responsabilidades principales:

  • Diseñar y operar pipelines de ingesta en Azure Data Factory y Microsoft Fabric
  • Ser dueño de las transformaciones en Azure Synapse y capas curadas en Microsoft Fabric lakehouses
  • Modelar stores operacionales en Azure SQL Database y Azure Cosmos DB
  • Versionar cada cambio de schema con migraciones idempotentes y reversibles
  • Ejecutar quality gates: validación de schema, tasas de nulos, freshness, deltas de conteo de filas
  • Producir y mantener un mapa de lineage para cada dataset, consultable por consumidores downstream
  • Operar el agente Pipeline Keeper y los slash prompts /etl-scaffold, /schema-diff, /quality-gate, /lineage-map
  • Colaborar con el DBA en schemas operacionales y con el ML/AI Engineer en feature stores

Jobs to be done

  1. Como Data Engineer, quiero estructurar un nuevo pipeline ETL en minutos, para que la incorporación de una nueva fuente no sea un ticket de una semana.
  2. Como Data Engineer, quiero que cada cambio de schema sea revisado con un diff y reporte de impacto, para que ninguna ruptura silenciosa llegue a producción.
  3. Como Data Engineer, quiero un quality gate en cada dataset, para que los consumidores downstream confíen en la freshness y completitud.
  4. Como Data Engineer, quiero un mapa de lineage en vivo, para que el análisis de impacto de un cambio de schema sea una consulta, no una reunión.
  5. Como Data Engineer, quiero que los fallos de pipeline produzcan alertas accionables en Azure Monitor, para que el trabajo on-call sea priorizado correctamente.
  6. Como Data Engineer, quiero que las anomalías de costo en Synapse y Fabric sean detectadas automáticamente, para que los trabajos sin control no exploten el presupuesto mensual.
  7. Como Data Engineer, quiero que las clasificaciones de datos sensibles de Microsoft Purview se propaguen en las pruebas de pipeline, para que el manejo de PII esté probado, no asumido.
  8. Como Data Engineer, quiero que cada transformación esté expresada en código versionado, para que ningún SQL único viva solo en un notebook.

Dolores antes del AI-nativo

  • Arqueología de notebooks. La lógica crítica vive en notebooks sin pruebas que hacen referencia a columnas por posición.
  • Drift silencioso de schema. Una fuente agrega una columna; un join duplica silenciosamente filas; un reporte es incorrecto por una semana.
  • Controles de calidad después del hecho. Las reglas de data-quality se ejecutan en un dashboard separado que el equipo olvida abrir.
  • Lineage en cabezas. Solo el Data Engineer senior sabe qué tabla alimenta qué reporte.
  • Sorpresas de costo. Un pool de Synapse mal configurado se ejecuta durante la noche; el equipo de finanzas se da cuenta antes que engineering.
  • Pipeline como copo de nieve. Cada pipeline inventó sus propias convenciones de retry, logging y alerting.
  • Sin rollback. Las migraciones se ejecutaban solo hacia adelante; revertir un cambio malo requería una restauración.

Flujo diario AI-nativo

El Data Engineer trabaja desde Visual Studio Code con GitHub Copilot y desde la terminal con Claude Code, invocando el agente Pipeline Keeper a lo largo del día.

Setup matinal

  1. Abre Azure Monitor y Microsoft Fabric monitoring para revisar los pipeline runs de la noche.
  2. En VS Code, ejecuta /quality-gate --since=yesterday para exponer cualquier dataset que haya fallado en los controles de freshness o completitud.
  3. Revisa los schema PRs pendientes; el Pipeline Keeper ha pre-redactado reportes de /schema-diff.
  4. Confirma las actualizaciones de clasificación de Microsoft Purview del equipo de Governance.
  5. Publica el resumen diario de Salud de Datos a Microsoft Teams con links a cualquier incidente abierto.

Ciclo de ejecución al mediodía

  1. Para cada nueva fuente, invoca /etl-scaffold con los metadatos de la fuente; el Pipeline Keeper genera una definición de pipeline de Azure Data Factory, dataflow de Fabric o notebook de Synapse con pruebas.
  2. Para cada schema PR, ejecuta /schema-diff para producir el reporte de impacto (tablas downstream, reportes, pipelines) y adjúntalo al PR.
  3. Implementa transformaciones en SQL o PySpark con instrucciones con alcance que ejecuten estilo y seguridad.
  4. Integra /quality-gate en el workflow de CI para que los merges se bloqueen en reglas rotas de freshness o nullability.

Revisión al final de la tarde

  1. Ejecuta /lineage-map para refrescar el gráfico de lineage; exporta a Microsoft Fabric y haz push de una snapshot de Markdown al repo.
  2. Triage cualquier anomalía de costo reportada por Azure Monitor y abre issues de seguimiento.
  3. Trabaja en pareja con el DBA en migraciones próximas para stores operacionales.

Primitivas recomendadas

Agente

AgenteArchivoPropósito
pipeline-keeper.github/agents/pipeline-keeper.agent.mdEstructura pipelines, diferencia schemas, ejecuta quality gates, refresca lineage

Slash prompts

ComandoArchivoPropósito
/etl-scaffold.github/prompts/etl-scaffold.prompt.mdGenera un pipeline de ingesta con pruebas, retries y quality gate
/schema-diff.github/prompts/schema-diff.prompt.mdDiferencia cambios de schema y reporta impacto downstream
/quality-gate.github/prompts/quality-gate.prompt.mdEjecuta controles de data-quality en CI y bloquea merge en fallo
/lineage-map.github/prompts/lineage-map.prompt.mdRefresca el gráfico de lineage y exporta a Fabric

Instrucciones con alcance

Alcance (applyTo)ArchivoPropósito
**/*.sql.github/instructions/sql.instructions.mdMigraciones idempotentes, pasos down reversibles, sin DDL destructivo fuera de revisión
pipelines/**/*.json.github/instructions/adf.instructions.mdConvenciones de pipeline de Azure Data Factory, retries, alertas
fabric/**/*.py.github/instructions/fabric.instructions.mdEstándares de notebook y dataflow de Microsoft Fabric
cosmos/**/*.ts.github/instructions/cosmos.instructions.mdReglas de partition key de Azure Cosmos DB y uso de SDK

Hooks

  • pre-commit: SQL lint, comprobación de clasificación de Purview, escaneo de secretos
  • pre-push: ejecuta pruebas unitarias en transformaciones y schema diff en DDL modificado
  • post-merge: despliega definiciones de pipeline via GitHub Actions a Azure Data Factory
  • nightly: ejecuta quality gate completo y refresca lineage
  • on-cost-anomaly: abre un issue cuando las métricas de costo de Azure Monitor superan un umbral

MCPs validados

MCPPropósitoDueño
GitHub MCP ServerPRs, runs de Actions, reportes de schema-diffGitHub
Azure MCP ServerImpulsa operaciones de Azure Data Factory, Synapse, Fabric, SQL y Cosmos DBMicrosoft
Microsoft Learn Docs MCPResuelve documentación actual de servicios de datos de Azure durante la implementaciónMicrosoft
Azure DevOps MCP ServerRunbooks de pipeline y rastreo de work-items para proyectos de datosMicrosoft
Playwright MCPValidación end-to-end de superficies de datos expuestas vía web appsMicrosoft

Ejemplos reales

Escenario 1: incorporar una nueva fuente SaaS

Una nueva alimentación de CRM necesita ingesta. El Data Engineer ejecuta /etl-scaffold --source=crm-api --target=fabric-lakehouse. El Pipeline Keeper genera un pipeline de Azure Data Factory con retries, lógica de checkpoint y una regla de /quality-gate para freshness y unicidad de clave primaria. Después de revisión, un único PR fusiona 14 archivos; Actions despliega el pipeline a Azure Data Factory. El primer run se completa dentro de la hora; el gráfico de lineage se actualiza durante la noche.

Escenario 2: capturar drift de schema antes de producción

Una tabla de Synapse gana una columna. El PR dispara /schema-diff, que identifica tres reportes Power BI downstream y dos consumidores de Azure SQL Database. El Pipeline Keeper marca un consumidor que asume selects posicionales fijos; el Data Engineer actualiza el SQL y solicita una prueba de compatibilidad. El merge procede sin sorpresas para finanzas o analytics.

Escenario 3: matar una query de Synapse sin control

Durante la noche, Azure Monitor dispara una anomalía de costo. El hook on-cost-anomaly abre un issue asignado al propietario del Pipeline Keeper. La mañana siguiente, el Data Engineer identifica un predicado faltante; /schema-diff muestra el plan de query afectado; un fix de una línea se fusiona y el costo vuelve a la baseline.

Anti-patrones

  • Notebooks como producción. Si un notebook produce una señal en la que el negocio confía, pertenece a un pipeline versionado con pruebas.
  • Migraciones de confianza ciega. Las migraciones sin un plan de rollback no son seguras, independientemente de la confianza del equipo.
  • Controles de calidad solo en dashboards. Las reglas de calidad pertenecen en CI y en hooks de tiempo de ejecución, no en un monitor que alguien podría mirar.
  • Lineage en memoria. Cada dataset debe tener una entrada de lineage generada; el gráfico es la fuente de verdad.
  • PII sin clasificar. Trata cada columna sin etiquetar como sensible hasta que Purview diga lo contrario.
  • Pipelines sin alertas. Un pipeline que falla y no notifica a nadie es un bug.
  • Retries hechos a mano. Usa políticas de retry nativas del pipeline; la lógica de retry personalizada es un incidente futuro.

KPIs y métricas de impacto

MétricaBaseline (manual)Objetivo (agéntico)Fuente
Tiempo de incorporación de pipeline7 días< 1 díaTiempo de lead del PR de GitHub
Incidentes de schema-drift por trimestre80Reportes de /schema-diff
Cobertura de data-quality gate40 por ciento100 por cientoComprobación de CI
Tiempo medio para detectar fallo de pipeline2 horas< 5 minutosAlertas de Azure Monitor
Anomalías de costo sin resolver > 24h5 por trimestre0Azure Monitor, hook de costo
Freshness del mapa de lineageSemanalEn vivo en mergeExportación de lineage de Fabric
Clasificaciones de PII sincronizadasAd hocDiariamenteMicrosoft Purview

Madurez en cuatro niveles

  • L1 Manual: Notebooks en email, migraciones en una unidad compartida, sin pruebas, sin lineage.
  • L2 Asistido: Autocompletado de Copilot en SQL, algunos pipelines en Azure Data Factory, pero sin schema diff y sin quality gate.
  • L3 Aumentado: Agente Pipeline Keeper, cuatro slash prompts, instrucciones con alcance, quality gate en CI, lineage refrescado semanalmente.
  • L4 Autónomo: Quality gate bloqueando merges, anomalías de costo abriendo issues en minutos, lineage refrescado en cada merge, clasificaciones de Purview propagadas a pruebas.

Integración con otras personas

  • Del Business Analyst: requisitos de datos mapeados a EARS, contratos de sistemas de origen.
  • Del Software Architect: restricciones de almacenamiento y throughput, selección de plataforma objetivo.
  • Con el DBA: gobernanza compartida de schema para stores operacionales; revisiones de migración.
  • Para el ML/AI Engineer: datasets de feature curados en Microsoft Fabric con un lineage documentado.
  • Para el BI Analyst: datasets certificados con garantías de freshness y completitud.
  • Para el SRE: runbooks de Azure Monitor para fallos de pipeline.
  • Para el Compliance Auditor: clasificaciones de Purview, mapa de lineage e historial de quality-gate como evidencia de auditoría.

Glosario

  • Pipeline: una definición versionada y testeable que mueve o transforma datos.
  • Quality gate: un conjunto de comprobaciones automatizadas (freshness, completitud, schema) que actúan como compuerta en un merge o release.
  • Schema diff: una comparación estructurada de versiones de schema con análisis de impacto downstream.
  • Lineage: el gráfico dirigido desde el sistema de origen hasta el dataset consumidor, con transformaciones entre ellos.
  • Zona curada: la capa de Microsoft Fabric o Synapse donde los datos son confiables y se reportan.
  • Idempotente: un pipeline que produce el mismo resultado ya sea ejecutado una o diez veces con la misma entrada.
  • Rollback: un script de migración reversible que devuelve el schema a un estado anterior.

Referencias