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

Engenheiro de Dados

Pipelines e qualidade de dados.

Atualizado: 2026-04-24 14 seções Baixar .zip

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

  1. 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.
  2. 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.
  3. Como Engenheiro de Dados, eu quero um gate de qualidade em cada dataset, para que consumidores downstream possam confiar no frescor e completude.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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ã

  1. Abra o Azure Monitor e o monitoramento do Microsoft Fabric para revisar as execuções de pipeline noturnas.
  2. No VS Code, rode /quality-gate --since=yesterday para identificar qualquer dataset que falhou em verificações de frescor ou completude.
  3. Revise PRs de schema pendentes; o Pipeline Keeper já pré-redigiu relatórios de /schema-diff.
  4. Confirme atualizações de classificação do Microsoft Purview vindas do time de Governança.
  5. 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

  1. Para cada nova fonte, invoque /etl-scaffold com 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.
  2. Para cada PR de schema, rode /schema-diff para produzir o relatório de impacto (tabelas, relatórios, pipelines downstream) e anexá-lo ao PR.
  3. Implemente transformações em SQL ou PySpark com instruções com escopo enforçando estilo e segurança.
  4. Conecte /quality-gate no workflow de CI para que merges sejam bloqueados em regras de frescor ou nulabilidade quebradas.

Revisão no fim da tarde

  1. Rode /lineage-map para atualizar o grafo de linhagem; exporte para o Microsoft Fabric e envie um snapshot em Markdown para o repositório.
  2. Triar quaisquer anomalias de custo reportadas pelo Azure Monitor e abrir issues de acompanhamento.
  3. Pareie com o DBA em migrações futuras para stores operacionais.

Primitivas recomendadas

Agente

AgenteArquivoPropósito
pipeline-keeper.github/agents/pipeline-keeper.agent.mdCria scaffolds de pipelines, diffa schemas, enforça gates de qualidade, atualiza linhagem

Slash prompts

ComandoArquivoPropósito
/etl-scaffold.github/prompts/etl-scaffold.prompt.mdGerar um pipeline de ingestão com testes, retries, gate de qualidade
/schema-diff.github/prompts/schema-diff.prompt.mdDiffar mudanças de schema e reportar impacto downstream
/quality-gate.github/prompts/quality-gate.prompt.mdRodar verificações de qualidade de dados no CI e bloquear merge em falha
/lineage-map.github/prompts/lineage-map.prompt.mdAtualizar o grafo de linhagem e exportar para o Fabric

Instruções com escopo

Escopo (applyTo)ArquivoPropósito
**/*.sql.github/instructions/sql.instructions.mdMigrações idempotentes, passos reversíveis de down, sem DDL destrutivo fora de revisão
pipelines/**/*.json.github/instructions/adf.instructions.mdConvenções de pipeline do Azure Data Factory, retries, alertas
fabric/**/*.py.github/instructions/fabric.instructions.mdPadrões de notebook e dataflow do Microsoft Fabric
cosmos/**/*.ts.github/instructions/cosmos.instructions.mdRegras 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 segredos
  • pre-push: rodar testes unitários em transformações e schema diff em DDL alterado
  • post-merge: deploy de definições de pipeline via GitHub Actions para o Azure Data Factory
  • nightly: rodar gate de qualidade completo e atualizar linhagem
  • on-cost-anomaly: abrir uma issue quando métricas de custo do Azure Monitor ultrapassam um limiar

MCPs validados

MCPPropósitoDono
GitHub MCP ServerPRs, execuções do Actions, relatórios de schema-diffGitHub
Azure MCP ServerOperar Azure Data Factory, Synapse, Fabric, SQL e Cosmos DBMicrosoft
Microsoft Learn Docs MCPResolver documentação atual de serviços de dados Azure durante a implementaçãoMicrosoft
Azure DevOps MCP ServerRunbooks de pipeline e rastreamento de work items para projetos de dadosMicrosoft
Playwright MCPValidação ponta a ponta de superfícies de dados expostas via web appsMicrosoft

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étricaLinha base (manual)Meta (agêntico)Fonte
Tempo de integração de pipeline7 dias< 1 diaLead time de PR no GitHub
Incidentes de drift de schema por trimestre80Relatórios de /schema-diff
Cobertura do gate de qualidade de dados40 por cento100 por centoVerificação no CI
Tempo médio para detectar falha de pipeline2 horas< 5 minutosAlertas do Azure Monitor
Anomalias de custo não resolvidas > 24h5 por trimestre0Azure Monitor, hook de custo
Frescor do mapa de linhagemSemanalEm tempo real no mergeExportação de linhagem do Fabric
Classificações de PII sincronizadasAd hocDiariamenteMicrosoft 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