Data EngineerEngenheiro de DadosIngeniero de Datos
Pipelines and data quality.Pipelines e qualidade de dados.Pipelines y calidad de datos.
The Data Engineer is the persona that builds and operates the data pipelines the rest of the org depends on. In an AI-native SDLC, the Data Engineer operates a Pipeline Keeper agent, four slash prompts, and a validated MCP catalog spanning Azure Data Factory, Synapse, Fabric, SQL Database, and Cosmos DB — not a forest of brittle notebooks.
Executive summary
The Data Engineer owns the movement, transformation, and quality of data between systems. In an AI-native SDLC, their primary deliverables are idempotent pipelines, tested schema migrations, quality gates enforced in CI, and a lineage map that any stakeholder can read. The toolkit is fixed: the Pipeline Keeper agent, the /etl-scaffold, /schema-diff, /quality-gate, /lineage-map slash prompts, scoped instructions for SQL and pipeline definitions, and validated MCPs reaching into Azure Data Factory, Azure Synapse, Microsoft Fabric, Azure SQL Database, and Azure Cosmos DB.
The Data Engineer protects the organization from the most common data failure modes: silent schema drift, missing nulls turning into poisoned joins, late-arriving data breaking downstream contracts, and pipelines that succeed while producing subtly wrong results. Every pipeline ships with tests, a lineage entry, and a data-quality gate.
Data work is now inseparable from software work. Pipelines are code, reviewed in GitHub, tested in Actions, governed by Microsoft Purview, and observed through Azure Monitor.
Role and responsibilities
Think of the Data Engineer like the bridge master of a municipal water system. Pipes move water from reservoirs to neighborhoods; meters, valves, and testing stations ensure quality; any leak or contamination must be detected and routed before the kitchen tap. In an AI-native SDLC, the Data Engineer owns that plumbing for facts instead of liquid.
Primary responsibilities:
- Design and operate ingestion pipelines in Azure Data Factory and Microsoft Fabric
- Own transformations in Azure Synapse and curated layers in Fabric lakehouses
- Model operational stores in Azure SQL Database and Azure Cosmos DB
- Version every schema change with idempotent, reversible migrations
- Enforce quality gates: schema validation, null rates, freshness, row-count deltas
- Produce and maintain a lineage map for every dataset, queryable by downstream consumers
- Operate the Pipeline Keeper agent and
/etl-scaffold,/schema-diff,/quality-gate,/lineage-mapprompts - Collaborate with the DBA on operational schemas and with the ML AI Engineer on feature stores
Jobs to be done
- As a Data Engineer, I want to scaffold a new ETL pipeline in minutes, so that onboarding a new source is not a week-long ticket.
- As a Data Engineer, I want every schema change reviewed with a diff and impact report, so that no silent breakage reaches production.
- As a Data Engineer, I want a quality gate on every dataset, so that downstream consumers can trust freshness and completeness.
- As a Data Engineer, I want a live lineage map, so that impact analysis for a schema change is a query, not a meeting.
- As a Data Engineer, I want pipeline failures to produce actionable alerts in Azure Monitor, so that on-call work is prioritized correctly.
- As a Data Engineer, I want cost anomalies in Synapse and Fabric detected automatically, so that runaway jobs do not blow the monthly budget.
- As a Data Engineer, I want sensitive-data classifications from Microsoft Purview propagated into pipeline tests, so that PII handling is proven, not assumed.
- As a Data Engineer, I want every transformation expressed in version-controlled code, so that no one-off SQL lives only in a notebook.
Pain points before AI-native
- Notebook archaeology. Critical logic lives in untested notebooks that reference columns by position.
- Silent schema drift. A source adds a column; a join silently duplicates rows; a report is wrong for a week.
- Quality checks after the fact. Data-quality rules run in a separate dashboard the team forgets to open.
- Lineage in heads. Only the senior Data Engineer knows which table feeds which report.
- Cost surprises. A misconfigured Synapse pool runs overnight; the finance team notices before engineering does.
- Pipeline as snowflake. Each pipeline invented its own retry, logging, alerting conventions.
- No rollback. Migrations ran forward-only; reverting a bad change required a restore.
AI-native daily workflow
The Data Engineer works from Visual Studio Code with GitHub Copilot and from the terminal with Claude Code, invoking the Pipeline Keeper agent throughout the day.
Morning setup
- Open Azure Monitor and Microsoft Fabric monitoring to review overnight pipeline runs.
- In VS Code, run
/quality-gate --since=yesterdayto surface any dataset that failed freshness or completeness checks. - Review pending schema PRs; the Pipeline Keeper has pre-drafted
/schema-diffreports. - Confirm Microsoft Purview classification updates from the Governance team.
- Post the Daily Data Health digest to Microsoft Teams with links to any open incidents.
Midday execution
- For each new source, invoke
/etl-scaffoldwith the source metadata; the Pipeline Keeper generates an Azure Data Factory pipeline definition, Fabric dataflow, or Synapse notebook with tests. - For every schema PR, run
/schema-diffto produce the impact report (downstream tables, reports, pipelines) and attach it to the PR. - Implement transformations in SQL or PySpark with scoped instructions enforcing style and safety.
- Wire
/quality-gateinto the CI workflow so merges block on broken freshness or nullability rules.
Afternoon review
- Run
/lineage-mapto refresh the lineage graph; export to Microsoft Fabric and push a Markdown snapshot to the repo. - Triage any cost anomalies reported by Azure Monitor and open follow-up issues.
- Pair with the DBA on upcoming migrations for operational stores.
Recommended primitives
Agent
| Agent | File | Purpose |
|---|---|---|
pipeline-keeper | .github/agents/pipeline-keeper.agent.md | Scaffolds pipelines, diffs schemas, enforces quality gates, refreshes lineage |
Slash prompts
| Command | File | Purpose |
|---|---|---|
/etl-scaffold | .github/prompts/etl-scaffold.prompt.md | Generate an ingestion pipeline with tests, retries, quality gate |
/schema-diff | .github/prompts/schema-diff.prompt.md | Diff schema changes and report downstream impact |
/quality-gate | .github/prompts/quality-gate.prompt.md | Run data-quality checks in CI and block merge on failure |
/lineage-map | .github/prompts/lineage-map.prompt.md | Refresh the lineage graph and export to Fabric |
Instructions scoped
Scope (applyTo) | File | Purpose |
|---|---|---|
**/*.sql | .github/instructions/sql.instructions.md | Idempotent migrations, reversible down steps, no destructive DDL outside review |
pipelines/**/*.json | .github/instructions/adf.instructions.md | Azure Data Factory pipeline conventions, retries, alerts |
fabric/**/*.py | .github/instructions/fabric.instructions.md | Microsoft Fabric notebook and dataflow standards |
cosmos/**/*.ts | .github/instructions/cosmos.instructions.md | Azure Cosmos DB partition key rules and SDK usage |
Hooks
pre-commit: SQL lint, Purview classification check, secret scanpre-push: run unit tests on transformations and schema diff on changed DDLpost-merge: deploy pipeline definitions via GitHub Actions to Azure Data Factorynightly: run full quality gate and refresh lineageon-cost-anomaly: open an issue when Azure Monitor cost metrics exceed a threshold
Validated MCPs
| MCP | Purpose | Owner |
|---|---|---|
| GitHub MCP Server | PRs, Actions runs, schema-diff reports | GitHub |
| Azure MCP Server | Drive Azure Data Factory, Synapse, Fabric, SQL, and Cosmos DB operations | Microsoft |
| Microsoft Learn Docs MCP | Resolve current Azure data-service documentation during implementation | Microsoft |
| Azure DevOps MCP Server | Pipeline runbooks and work-item tracking for data projects | Microsoft |
| Playwright MCP | End-to-end validation of data surfaces exposed via web apps | Microsoft |
Real examples
Example 1: onboarding a new SaaS source
A new CRM feed needs ingestion. The Data Engineer runs /etl-scaffold --source=crm-api --target=fabric-lakehouse. The Pipeline Keeper generates an Azure Data Factory pipeline with retries, checkpoint logic, and a /quality-gate rule for freshness and primary-key uniqueness. After review, a single PR merges 14 files; Actions deploys the pipeline to Azure Data Factory. The first run lands within the hour; the lineage graph updates overnight.
Example 2: catching schema drift before production
A Synapse table gains a column. The PR triggers /schema-diff, which identifies three downstream Power BI reports and two Azure SQL Database consumers. The Pipeline Keeper flags one consumer that assumes fixed positional selects; the Data Engineer updates the SQL and requests a compatibility test. The merge proceeds without surprise to finance or analytics.
Example 3: killing a runaway Synapse query
Overnight, Azure Monitor fires a cost anomaly. The on-cost-anomaly hook opens an issue assigned to the Pipeline Keeper owner. The next morning, the Data Engineer identifies a missing predicate; /schema-diff shows the affected query plan; a one-line fix merges and the cost returns to baseline.
Anti-patterns
- Notebooks as production. If a notebook produces a signal the business relies on, it belongs in a versioned pipeline with tests.
- Trust-me migrations. Migrations without a rollback plan are not safe, regardless of team confidence.
- Quality checks in dashboards only. Quality rules belong in CI and in runtime hooks, not on a monitor someone might look at.
- Lineage by memory. Every dataset should have a generated lineage entry; the graph is the source of truth.
- Unclassified PII. Treat every un-labeled column as sensitive until Purview says otherwise.
- Pipelines without alerts. A failing pipeline that does not page anyone is a bug.
- Hand-rolled retries. Use pipeline-native retry policies; bespoke retry logic is a future incident.
KPIs and impact metrics
| Metric | Baseline (manual) | Target (agentic) | Source |
|---|---|---|---|
| Pipeline onboarding time | 7 days | < 1 day | GitHub PR lead time |
| Schema-drift incidents per quarter | 8 | 0 | /schema-diff reports |
| Data-quality gate coverage | 40 percent | 100 percent | CI check |
| Mean time to detect pipeline failure | 2 hours | < 5 minutes | Azure Monitor alerts |
| Cost anomalies unresolved > 24h | 5 per quarter | 0 | Azure Monitor, cost hook |
| Lineage map freshness | Weekly | Live on merge | Fabric lineage export |
| PII classifications synced | Ad hoc | Daily | Microsoft Purview |
Maturity in four levels
- L1 Manual: Notebooks in email, migrations in a shared drive, no tests, no lineage.
- L2 Assisted: Copilot autocomplete in SQL, some pipelines in Azure Data Factory, but no schema diff and no quality gate.
- L3 Augmented: Pipeline Keeper agent, four slash prompts, scoped instructions, quality gate in CI, lineage refreshed weekly.
- L4 Autonomous: Quality gate blocking merges, cost anomalies opening issues within minutes, lineage refreshed on every merge, Purview classifications propagated into tests.
Integration with other personas
- From Business Analyst: data requirements mapped to EARS, source-system contracts.
- From Software Architect: storage and throughput constraints, target platform selection.
- With DBA: shared schema governance for operational stores; migration reviews.
- To ML AI Engineer: curated feature datasets in Microsoft Fabric with a documented lineage.
- To BI Analyst: certified datasets with freshness and completeness guarantees.
- To SRE: Azure Monitor runbooks for pipeline failures.
- To Compliance Auditor: Purview classifications, lineage map, and quality-gate history as audit evidence.
Glossary
- Pipeline: a version-controlled, testable definition that moves or transforms data.
- Quality gate: a set of automated checks (freshness, completeness, schema) gating a merge or release.
- Schema diff: a structured comparison of schema versions with downstream impact analysis.
- Lineage: the directed graph from source system to consumer dataset, with transformations between.
- Curated zone: the layer of Microsoft Fabric or Synapse where data is trusted and reported on.
- Idempotent: a pipeline that produces the same result whether run once or ten times on the same input.
- Rollback: a reversible migration script that returns the schema to a previous state.
References
- Azure Data Factory documentation — authoritative guidance on ingestion pipelines
- Azure Synapse Analytics — transformation at scale
- Microsoft Fabric documentation — lakehouse, notebooks, pipelines, lineage
- Azure SQL Database — operational relational store
- Azure Cosmos DB — globally distributed document store
- Microsoft Purview — data governance and classification
- Azure Monitor — observability and cost anomaly detection
- GitHub Actions — CI and deployment orchestration across the stack
- Microsoft Learn Docs MCP — first-party documentation retrieval at implementation time
- GitHub Advanced Security — CodeQL, Dependabot, Secret Scanning, Push Protection
O Engenheiro de Dados é a persona que constrói e opera os pipelines de dados dos quais o restante da organização depende. Em um SDLC AI-nativo, o Engenheiro de Dados opera um agente Pipeline Keeper, quatro slash prompts e um catálogo validado de MCPs abrangendo Azure Data Factory, Synapse, Fabric, SQL Database e Cosmos DB — não uma floresta de notebooks frágeis.
Resumo executivo
O Engenheiro de Dados é dono da movimentação, transformação e qualidade dos dados entre sistemas. Em um SDLC AI-nativo, suas entregas primárias são pipelines idempotentes, migrações de schema testadas, gates de qualidade enforçados no CI e um mapa de linhagem que qualquer stakeholder consegue ler. O toolkit é fixo: o agente Pipeline Keeper, os slash prompts /etl-scaffold, /schema-diff, /quality-gate, /lineage-map, instruções com escopo para SQL e definições de pipeline, e MCPs validados alcançando Azure Data Factory, Azure Synapse, Microsoft Fabric, Azure SQL Database e Azure Cosmos DB.
O Engenheiro de Dados protege a organização dos modos de falha de dados mais comuns: drift silencioso de schema, nulos faltantes transformando-se em joins envenenados, dados atrasados quebrando contratos downstream e pipelines que sucedem enquanto produzem resultados sutilmente errados. Todo pipeline é entregue com testes, uma entrada de linhagem e um gate de qualidade de dados.
O trabalho de dados agora é inseparável do trabalho de software. Pipelines são código, revisados no GitHub, testados no Actions, governados pelo Microsoft Purview e observados através do Azure Monitor.
Papel e responsabilidades
Pense no Engenheiro de Dados como o mestre de pontes de um sistema municipal de água. Tubos movem água de reservatórios para bairros; medidores, válvulas e estações de teste garantem qualidade; qualquer vazamento ou contaminação deve ser detectado e encaminhado antes da torneira da cozinha. Em um SDLC AI-nativo, o Engenheiro de Dados é dono dessa tubulação para fatos em vez de líquido.
Responsabilidades primárias:
- Projetar e operar pipelines de ingestão no Azure Data Factory e Microsoft Fabric
- Ser dono das transformações no Azure Synapse e nas camadas curadas em lakehouses do Fabric
- Modelar stores operacionais no Azure SQL Database e Azure Cosmos DB
- Versionar cada mudança de schema com migrações idempotentes e reversíveis
- Enforçar gates de qualidade: validação de schema, taxas de nulo, frescor, deltas de contagem de linhas
- Produzir e manter um mapa de linhagem para cada dataset, consultável por consumidores downstream
- Operar o agente Pipeline Keeper e os prompts
/etl-scaffold,/schema-diff,/quality-gate,/lineage-map - Colaborar com o DBA em schemas operacionais e com o ML AI Engineer em feature stores
Jobs to be done
- Como Engenheiro de Dados, eu quero criar o scaffold de um novo pipeline ETL em minutos, para que a integração de uma nova fonte não seja um ticket de uma semana.
- Como Engenheiro de Dados, eu quero cada mudança de schema revisada com um diff e relatório de impacto, para que nenhuma quebra silenciosa chegue à produção.
- Como Engenheiro de Dados, eu quero um gate de qualidade em cada dataset, para que consumidores downstream possam confiar no frescor e completude.
- Como Engenheiro de Dados, eu quero um mapa de linhagem em tempo real, para que a análise de impacto de uma mudança de schema seja uma consulta, não uma reunião.
- Como Engenheiro de Dados, eu quero falhas de pipeline que produzam alertas acionáveis no Azure Monitor, para que o trabalho de plantão seja priorizado corretamente.
- Como Engenheiro de Dados, eu quero anomalias de custo no Synapse e Fabric detectadas automaticamente, para que jobs descontrolados não estourem o orçamento mensal.
- Como Engenheiro de Dados, eu quero classificações de dados sensíveis do Microsoft Purview propagadas nos testes de pipeline, para que o tratamento de PII seja provado, não assumido.
- Como Engenheiro de Dados, eu quero cada transformação expressa em código versionado, para que nenhum SQL avulso viva apenas em um notebook.
Dores antes do AI-nativo
- Arqueologia de notebooks. Lógica crítica vive em notebooks não testados que referenciam colunas por posição.
- Drift silencioso de schema. Uma fonte adiciona uma coluna; um join duplica linhas silenciosamente; um relatório fica errado por uma semana.
- Verificações de qualidade após o fato. Regras de qualidade de dados rodam em um dashboard separado que o time esquece de abrir.
- Linhagem na cabeça. Só o Engenheiro de Dados sênior sabe qual tabela alimenta qual relatório.
- Surpresas de custo. Um pool do Synapse mal configurado roda durante a noite; o time financeiro percebe antes da engenharia.
- Pipeline como floco de neve. Cada pipeline inventou suas próprias convenções de retry, logging e alertas.
- Sem rollback. Migrações rodavam apenas para frente; reverter uma mudança ruim exigia uma restauração.
Fluxo diário AI-nativo
O Engenheiro de Dados trabalha a partir do Visual Studio Code com GitHub Copilot e do terminal com Claude Code, invocando o agente Pipeline Keeper ao longo do dia.
Setup da manhã
- Abra o Azure Monitor e o monitoramento do Microsoft Fabric para revisar as execuções de pipeline noturnas.
- No VS Code, rode
/quality-gate --since=yesterdaypara identificar qualquer dataset que falhou em verificações de frescor ou completude. - Revise PRs de schema pendentes; o Pipeline Keeper já pré-redigiu relatórios de
/schema-diff. - Confirme atualizações de classificação do Microsoft Purview vindas do time de Governança.
- Poste o resumo diário de Saúde de Dados no Microsoft Teams com links para quaisquer incidentes abertos.
Execução no meio do dia
- Para cada nova fonte, invoque
/etl-scaffoldcom os metadados da fonte; o Pipeline Keeper gera uma definição de pipeline do Azure Data Factory, dataflow do Fabric ou notebook do Synapse com testes. - Para cada PR de schema, rode
/schema-diffpara produzir o relatório de impacto (tabelas, relatórios, pipelines downstream) e anexá-lo ao PR. - Implemente transformações em SQL ou PySpark com instruções com escopo enforçando estilo e segurança.
- Conecte
/quality-gateno workflow de CI para que merges sejam bloqueados em regras de frescor ou nulabilidade quebradas.
Revisão no fim da tarde
- Rode
/lineage-mappara atualizar o grafo de linhagem; exporte para o Microsoft Fabric e envie um snapshot em Markdown para o repositório. - Triar quaisquer anomalias de custo reportadas pelo Azure Monitor e abrir issues de acompanhamento.
- Pareie com o DBA em migrações futuras para stores operacionais.
Primitivas recomendadas
Agente
| Agente | Arquivo | Propósito |
|---|---|---|
pipeline-keeper | .github/agents/pipeline-keeper.agent.md | Cria scaffolds de pipelines, diffa schemas, enforça gates de qualidade, atualiza linhagem |
Slash prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/etl-scaffold | .github/prompts/etl-scaffold.prompt.md | Gerar um pipeline de ingestão com testes, retries, gate de qualidade |
/schema-diff | .github/prompts/schema-diff.prompt.md | Diffar mudanças de schema e reportar impacto downstream |
/quality-gate | .github/prompts/quality-gate.prompt.md | Rodar verificações de qualidade de dados no CI e bloquear merge em falha |
/lineage-map | .github/prompts/lineage-map.prompt.md | Atualizar o grafo de linhagem e exportar para o Fabric |
Instruções com escopo
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
**/*.sql | .github/instructions/sql.instructions.md | Migrações idempotentes, passos reversíveis de down, sem DDL destrutivo fora de revisão |
pipelines/**/*.json | .github/instructions/adf.instructions.md | Convenções de pipeline do Azure Data Factory, retries, alertas |
fabric/**/*.py | .github/instructions/fabric.instructions.md | Padrões de notebook e dataflow do Microsoft Fabric |
cosmos/**/*.ts | .github/instructions/cosmos.instructions.md | Regras de partition key e uso do SDK do Azure Cosmos DB |
Hooks
pre-commit: lint de SQL, verificação de classificação Purview, scan de segredospre-push: rodar testes unitários em transformações e schema diff em DDL alteradopost-merge: deploy de definições de pipeline via GitHub Actions para o Azure Data Factorynightly: rodar gate de qualidade completo e atualizar linhagemon-cost-anomaly: abrir uma issue quando métricas de custo do Azure Monitor ultrapassam um limiar
MCPs validados
| MCP | Propósito | Dono |
|---|---|---|
| GitHub MCP Server | PRs, execuções do Actions, relatórios de schema-diff | GitHub |
| Azure MCP Server | Operar Azure Data Factory, Synapse, Fabric, SQL e Cosmos DB | Microsoft |
| Microsoft Learn Docs MCP | Resolver documentação atual de serviços de dados Azure durante a implementação | Microsoft |
| Azure DevOps MCP Server | Runbooks de pipeline e rastreamento de work items para projetos de dados | Microsoft |
| Playwright MCP | Validação ponta a ponta de superfícies de dados expostas via web apps | Microsoft |
Exemplos reais
Exemplo 1: integrando uma nova fonte SaaS
Um novo feed de CRM precisa de ingestão. O Engenheiro de Dados roda /etl-scaffold --source=crm-api --target=fabric-lakehouse. O Pipeline Keeper gera um pipeline do Azure Data Factory com retries, lógica de checkpoint e uma regra /quality-gate para frescor e unicidade de chave primária. Após revisão, um único PR faz merge de 14 arquivos; Actions deploya o pipeline no Azure Data Factory. A primeira execução aterrissa dentro de uma hora; o grafo de linhagem atualiza durante a noite.
Exemplo 2: capturando drift de schema antes da produção
Uma tabela do Synapse ganha uma coluna. O PR dispara /schema-diff, que identifica três relatórios do Power BI e dois consumidores do Azure SQL Database. O Pipeline Keeper sinaliza um consumidor que assume selects posicionais fixos; o Engenheiro de Dados atualiza o SQL e solicita um teste de compatibilidade. O merge prossegue sem surpresa para finanças ou analytics.
Exemplo 3: matando uma query descontrolada do Synapse
Durante a noite, o Azure Monitor dispara uma anomalia de custo. O hook on-cost-anomaly abre uma issue atribuída ao dono do Pipeline Keeper. Na manhã seguinte, o Engenheiro de Dados identifica um predicado faltante; /schema-diff mostra o plano de consulta afetado; uma correção de uma linha faz merge e o custo retorna à linha base.
Anti-padrões
- Notebooks como produção. Se um notebook produz um sinal do qual o negócio depende, ele pertence a um pipeline versionado com testes.
- Migrações confiança-cega. Migrações sem um plano de rollback não são seguras, independentemente da confiança do time.
- Verificações de qualidade só em dashboards. Regras de qualidade pertencem ao CI e a hooks de runtime, não a um monitor que alguém pode olhar.
- Linhagem de memória. Cada dataset deve ter uma entrada de linhagem gerada; o grafo é a fonte da verdade.
- PII não classificado. Trate cada coluna não rotulada como sensível até que o Purview diga o contrário.
- Pipelines sem alertas. Um pipeline falhando que não aciona ninguém é um bug.
- Retries artesanais. Use políticas de retry nativas do pipeline; lógica de retry customizada é um incidente futuro.
KPIs e métricas de impacto
| Métrica | Linha base (manual) | Meta (agêntico) | Fonte |
|---|---|---|---|
| Tempo de integração de pipeline | 7 dias | < 1 dia | Lead time de PR no GitHub |
| Incidentes de drift de schema por trimestre | 8 | 0 | Relatórios de /schema-diff |
| Cobertura do gate de qualidade de dados | 40 por cento | 100 por cento | Verificação no CI |
| Tempo médio para detectar falha de pipeline | 2 horas | < 5 minutos | Alertas do Azure Monitor |
| Anomalias de custo não resolvidas > 24h | 5 por trimestre | 0 | Azure Monitor, hook de custo |
| Frescor do mapa de linhagem | Semanal | Em tempo real no merge | Exportação de linhagem do Fabric |
| Classificações de PII sincronizadas | Ad hoc | Diariamente | Microsoft Purview |
Maturidade em quatro níveis
- L1 Manual: Notebooks por email, migrações em um drive compartilhado, sem testes, sem linhagem.
- L2 Assistido: Autocomplete do Copilot em SQL, alguns pipelines no Azure Data Factory, mas sem schema diff e sem gate de qualidade.
- L3 Aumentado: Agente Pipeline Keeper, quatro slash prompts, instruções com escopo, gate de qualidade no CI, linhagem atualizada semanalmente.
- L4 Autônomo: Gate de qualidade bloqueando merges, anomalias de custo abrindo issues em minutos, linhagem atualizada a cada merge, classificações do Purview propagadas nos testes.
Integração com outras personas
- Do Business Analyst: requisitos de dados mapeados para EARS, contratos de sistema-fonte.
- Do Software Architect: restrições de armazenamento e throughput, seleção de plataforma alvo.
- Com o DBA: governança de schema compartilhada para stores operacionais; revisões de migração.
- Para o ML AI Engineer: datasets de features curados no Microsoft Fabric com linhagem documentada.
- Para o BI Analyst: datasets certificados com garantias de frescor e completude.
- Para o SRE: runbooks do Azure Monitor para falhas de pipeline.
- Para o Compliance Auditor: classificações do Purview, mapa de linhagem e histórico de gates de qualidade como evidência de auditoria.
Glossário
- Pipeline: uma definição versionada e testável que move ou transforma dados.
- Gate de qualidade: um conjunto de verificações automatizadas (frescor, completude, schema) bloqueando um merge ou release.
- Schema diff: uma comparação estruturada de versões de schema com análise de impacto downstream.
- Linhagem: o grafo direcionado do sistema-fonte ao dataset consumidor, com transformações entre eles.
- Zona curada: a camada do Microsoft Fabric ou Synapse onde os dados são confiáveis e reportados.
- Idempotente: um pipeline que produz o mesmo resultado seja executado uma ou dez vezes na mesma entrada.
- Rollback: um script de migração reversível que retorna o schema a um estado anterior.
Referências
- Documentação do Azure Data Factory — orientação autoritativa sobre pipelines de ingestão
- Azure Synapse Analytics — transformação em escala
- Documentação do Microsoft Fabric — lakehouse, notebooks, pipelines, linhagem
- Azure SQL Database — store relacional operacional
- Azure Cosmos DB — store de documentos distribuído globalmente
- Microsoft Purview — governança e classificação de dados
- Azure Monitor — observabilidade e detecção de anomalias de custo
- GitHub Actions — orquestração de CI e deploy em todo o stack
- Microsoft Learn Docs MCP — recuperação de documentação first-party no momento da implementação
- GitHub Advanced Security — CodeQL, Dependabot, Secret Scanning, Push Protection
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
- 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.
- 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.
- Como Data Engineer, quiero un quality gate en cada dataset, para que los consumidores downstream confíen en la freshness y completitud.
- 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.
- Como Data Engineer, quiero que los fallos de pipeline produzcan alertas accionables en Azure Monitor, para que el trabajo on-call sea priorizado correctamente.
- 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.
- 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.
- 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
- Abre Azure Monitor y Microsoft Fabric monitoring para revisar los pipeline runs de la noche.
- En VS Code, ejecuta
/quality-gate --since=yesterdaypara exponer cualquier dataset que haya fallado en los controles de freshness o completitud. - Revisa los schema PRs pendientes; el Pipeline Keeper ha pre-redactado reportes de
/schema-diff. - Confirma las actualizaciones de clasificación de Microsoft Purview del equipo de Governance.
- Publica el resumen diario de Salud de Datos a Microsoft Teams con links a cualquier incidente abierto.
Ciclo de ejecución al mediodía
- Para cada nueva fuente, invoca
/etl-scaffoldcon 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. - Para cada schema PR, ejecuta
/schema-diffpara producir el reporte de impacto (tablas downstream, reportes, pipelines) y adjúntalo al PR. - Implementa transformaciones en SQL o PySpark con instrucciones con alcance que ejecuten estilo y seguridad.
- Integra
/quality-gateen el workflow de CI para que los merges se bloqueen en reglas rotas de freshness o nullability.
Revisión al final de la tarde
- Ejecuta
/lineage-mappara refrescar el gráfico de lineage; exporta a Microsoft Fabric y haz push de una snapshot de Markdown al repo. - Triage cualquier anomalía de costo reportada por Azure Monitor y abre issues de seguimiento.
- Trabaja en pareja con el DBA en migraciones próximas para stores operacionales.
Primitivas recomendadas
Agente
| Agente | Archivo | Propósito |
|---|---|---|
pipeline-keeper | .github/agents/pipeline-keeper.agent.md | Estructura pipelines, diferencia schemas, ejecuta quality gates, refresca lineage |
Slash prompts
| Comando | Archivo | Propósito |
|---|---|---|
/etl-scaffold | .github/prompts/etl-scaffold.prompt.md | Genera un pipeline de ingesta con pruebas, retries y quality gate |
/schema-diff | .github/prompts/schema-diff.prompt.md | Diferencia cambios de schema y reporta impacto downstream |
/quality-gate | .github/prompts/quality-gate.prompt.md | Ejecuta controles de data-quality en CI y bloquea merge en fallo |
/lineage-map | .github/prompts/lineage-map.prompt.md | Refresca el gráfico de lineage y exporta a Fabric |
Instrucciones con alcance
Alcance (applyTo) | Archivo | Propósito |
|---|---|---|
**/*.sql | .github/instructions/sql.instructions.md | Migraciones idempotentes, pasos down reversibles, sin DDL destructivo fuera de revisión |
pipelines/**/*.json | .github/instructions/adf.instructions.md | Convenciones de pipeline de Azure Data Factory, retries, alertas |
fabric/**/*.py | .github/instructions/fabric.instructions.md | Estándares de notebook y dataflow de Microsoft Fabric |
cosmos/**/*.ts | .github/instructions/cosmos.instructions.md | Reglas 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 secretospre-push: ejecuta pruebas unitarias en transformaciones y schema diff en DDL modificadopost-merge: despliega definiciones de pipeline via GitHub Actions a Azure Data Factorynightly: ejecuta quality gate completo y refresca lineageon-cost-anomaly: abre un issue cuando las métricas de costo de Azure Monitor superan un umbral
MCPs validados
| MCP | Propósito | Dueño |
|---|---|---|
| GitHub MCP Server | PRs, runs de Actions, reportes de schema-diff | GitHub |
| Azure MCP Server | Impulsa operaciones de Azure Data Factory, Synapse, Fabric, SQL y Cosmos DB | Microsoft |
| Microsoft Learn Docs MCP | Resuelve documentación actual de servicios de datos de Azure durante la implementación | Microsoft |
| Azure DevOps MCP Server | Runbooks de pipeline y rastreo de work-items para proyectos de datos | Microsoft |
| Playwright MCP | Validación end-to-end de superficies de datos expuestas vía web apps | Microsoft |
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étrica | Baseline (manual) | Objetivo (agéntico) | Fuente |
|---|---|---|---|
| Tiempo de incorporación de pipeline | 7 días | < 1 día | Tiempo de lead del PR de GitHub |
| Incidentes de schema-drift por trimestre | 8 | 0 | Reportes de /schema-diff |
| Cobertura de data-quality gate | 40 por ciento | 100 por ciento | Comprobación de CI |
| Tiempo medio para detectar fallo de pipeline | 2 horas | < 5 minutos | Alertas de Azure Monitor |
| Anomalías de costo sin resolver > 24h | 5 por trimestre | 0 | Azure Monitor, hook de costo |
| Freshness del mapa de lineage | Semanal | En vivo en merge | Exportación de lineage de Fabric |
| Clasificaciones de PII sincronizadas | Ad hoc | Diariamente | Microsoft 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
- Documentación de Azure Data Factory — orientación autoritativa en pipelines de ingesta
- Azure Synapse Analytics — transformación a escala
- Documentación de Microsoft Fabric — lakehouse, notebooks, pipelines, lineage
- Azure SQL Database — store relacional operacional
- Azure Cosmos DB — store de documentos distribuido globalmente
- Microsoft Purview — gobernanza y clasificación de datos
- Azure Monitor — observabilidad y detección de anomalías de costo
- GitHub Actions — orquestación de CI y deployment a través del stack
- Microsoft Learn Docs MCP — recuperación de documentación first-party en tiempo de implementación
- GitHub Advanced Security — CodeQL, Dependabot, Secret Scanning, Push Protection