9 min leitura • Guide 765 of 877
Gerenciamento de Projetos de Pipeline de Dados
Pipelines de dados requerem coordenação cuidadosa entre engenheiros de dados, analistas e stakeholders. O GitScrum ajuda equipes a gerenciar projetos de infraestrutura de dados com fluxos de trabalho claros.
Desenvolvimento de Pipeline
Estrutura de Tarefas de Pipeline
DIVISÃO DE TAREFAS DE PIPELINE DE DADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ÉPICO DE PIPELINE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DATA-100: Pipeline de Analytics de Clientes ││
│ │ ││
│ │ Objetivo: Métricas diárias de clientes para analytics ││
│ │ ││
│ │ Origem: BD de produção (clientes, pedidos) ││
│ │ Destino: Warehouse de analytics ││
│ │ Agenda: Diariamente às 2 AM ││
│ │ ││
│ │ Tarefas: ││
│ │ ├── DATA-101: Extrair dados de clientes ││
│ │ ├── DATA-102: Extrair dados de pedidos ││
│ │ ├── DATA-103: Transformar métricas de clientes ││
│ │ ├── DATA-104: Carregar no warehouse ││
│ │ ├── DATA-105: Verificações de qualidade de dados ││
│ │ ├── DATA-106: Alertas e monitoramento ││
│ │ └── DATA-107: Documentação ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TAREFA DE ESTÁGIO INDIVIDUAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DATA-103: Transformar métricas de clientes ││
│ │ ││
│ │ Entrada: Dados brutos de cliente + pedido ││
│ │ ││
│ │ Métricas de saída: ││
│ │ • total_pedidos por cliente ││
│ │ • total_receita por cliente ││
│ │ • valor_medio_pedido ││
│ │ • data_primeiro_pedido ││
│ │ • data_ultimo_pedido ││
│ │ • dias_desde_ultimo_pedido ││
│ │ ││
│ │ Regras de negócio: ││
│ │ • Contar apenas pedidos concluídos ││
│ │ • Excluir contas de teste ││
│ │ • Lidar com reembolsos corretamente ││
│ │ ││
│ │ Testes: ││
│ │ ☐ Testes unitários para cada cálculo ││
│ │ ☐ Caso extremo: nenhum pedido ││
│ │ ☐ Caso extremo: todos reembolsados ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Contratos de Dados
DEFINIÇÃO DE CONTRATO DE DADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ POR QUE CONTRATOS DE DADOS: │
│ │
│ • Definir esquema esperado │
│ • Capturar mudanças disruptivas cedo │
│ • Habilitar desenvolvimento paralelo │
│ • Documentar fluxo de dados │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TAREFA DE CONTRATO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DATA-110: Definir contrato customer_metrics ││
│ │ ││
│ │ Esquema: ││
│ │ ┌─────────────────────────────────────────────────────┐││
│ │ │ customer_metrics │││
│ │ ├─────────────────────────────────────────────────────┤││
│ │ │ customer_id: STRING (obrigatório) │││
│ │ │ total_orders: INTEGER (>= 0) │││
│ │ │ total_revenue: DECIMAL(10,2) │││
│ │ │ avg_order_value: DECIMAL(10,2) │││
│ │ │ first_order_date: DATE (anulável) │││
│ │ │ last_order_date: DATE (anulável) │││
│ │ │ days_since_last_order: INTEGER (anulável) │││
│ │ │ computed_at: TIMESTAMP (obrigatório) │││
│ │ └─────────────────────────────────────────────────────┘││
│ │ ││
│ │ Restrições: ││
│ │ • Sem nulos em customer_id ││
│ │ • total_orders >= 0 ││
│ │ • first_order_date <= last_order_date ││
│ │ ││
│ │ Consumidores: ││
│ │ • Dashboard BI ││
│ │ • Modelo ML de churn ││
│ │ • Automação de marketing ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MUDANÇAS DISRUPTIVAS: │
│ • Remoção de colunas │
│ • Mudança de tipos │
│ • Mudança de semântica │
│ → Requer coordenação com consumidores │
└─────────────────────────────────────────────────────────────┘
Qualidade de Dados
Verificações de Qualidade
IMPLEMENTAÇÃO DE QUALIDADE DE DADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA DE QUALIDADE DE DADOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DATA-105: Verificações de qualidade de dados ││
│ │ ││
│ │ COMPLETUDE: ││
│ │ ☐ Sem customer_ids nulos ││
│ │ ☐ Todos os clientes têm computed_at ││
│ │ ☐ Contagem de linhas dentro do intervalo esperado ││
│ │ ││
│ │ ATUALIDADE: ││
│ │ ☐ computed_at dentro das últimas 24 horas ││
│ │ ☐ last_order_date não no futuro ││
│ │ ││
│ │ PRECISÃO: ││
│ │ ☐ total_revenue = soma dos valores dos pedidos ││
│ │ ☐ avg_order_value = receita / pedidos ││
│ │ ☐ Verificação spot contra fonte ││
│ │ ││
│ │ CONSISTÊNCIA: ││
│ │ ☐ Cliente existe na tabela de clientes ││
│ │ ☐ Sem customer_ids duplicados ││
│ │ ││
│ │ RAZOABILIDADE: ││
│ │ ☐ avg_order_value dentro do intervalo esperado ││
│ │ ☐ Sem receita negativa ││
│ │ ☐ Mudanças de métricas dentro dos limites vs ontem ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PORTÃO DE QUALIDADE: │
│ │
│ Pipeline só tem sucesso se: │
│ • Todas as verificações de completude passam │
│ • Todas as verificações de precisão passam │
│ • Atualidade é aceitável │
│ │
│ Avisos (não bloqueiam): │
│ • Limites de razoabilidade excedidos │
│ → Alertar, mas carregar dados │
└─────────────────────────────────────────────────────────────┘
Problemas de Qualidade
TRATAMENTO DE BUG DE QUALIDADE DE DADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENTE DE QUALIDADE DE DADOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 DATA-BUG-42: Registros duplicados de clientes ││
│ │ ││
│ │ Descoberto: 2024-01-15 alerta de monitoramento ││
│ │ Impacto: Dashboards BI mostrando contagens infladas ││
│ │ ││
│ │ Causa raiz: ││
│ │ Sistema fonte tem customer_ids duplicados devido a ││
│ │ problema de mesclagem de aquisição. ││
│ │ ││
│ │ Correção imediata: ││
│ │ ☐ Adicionar desduplicação à transformação ││
│ │ ☐ Executar novamente pipeline para datas afetadas ││
│ │ ☐ Notificar consumidores sobre dados corrigidos ││
│ │ ││
│ │ Correção de longo prazo: ││
│ │ ☐ Trabalhar com equipe fonte na desduplicação ││
│ │ ☐ Adicionar verificação de unicidade aos portões ││
│ │ ││
│ │ Rótulos: data-quality, pipeline, high-priority ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CLASSIFICAÇÃO: │
│ │
│ Crítico: Dados estão errados, decisões afetadas │
│ → Corrigir imediatamente, notificar stakeholders │
│ │
│ Alto: Dados incompletos, algumas consultas falham │
│ → Corrigir em 1-2 dias │
│ │
│ Médio: Dados atrasados, atualidade impactada │
│ → Corrigir dentro do sprint │
│ │
│ Baixo: Problemas menores, soluções alternativas existem │
│ → Adicionar ao backlog │
└─────────────────────────────────────────────────────────────┘
Gerenciamento de Stakeholders
Coleta de Requisitos
REQUISITOS DE PROJETO DE DADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA DE INTAKE DE STAKEHOLDER: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DATA-REQ-01: Requisitos de métricas de clientes ││
│ │ ││
│ │ Stakeholder: Equipe de marketing ││
│ │ Caso de uso: Segmentação de clientes ││
│ │ ││
│ │ Perguntas respondidas: ││
│ │ ││
│ │ QUAIS DADOS: ││
│ │ ☑ Que métricas você precisa? ││
│ │ → Contagem de pedidos, receita, recência ││
│ │ ││
│ │ POR QUÊ: ││
│ │ ☑ Que decisões isso informará? ││
│ │ → Segmentação de clientes para campanhas ││
│ │ ││
│ │ COM QUE FREQUÊNCIA: ││
│ │ ☑ Quão atual precisa ser? ││
│ │ → Diário é suficiente ││
│ │ ││
│ │ VOLUME: ││
│ │ ☑ Quantos registros? ││
│ │ → ~500K clientes ││
│ │ ││
│ │ ACESSO: ││
│ │ ☑ Quem precisa de acesso? ││
│ │ → Analistas de marketing, ferramenta BI ││
│ │ ││
│ │ DEFINIÇÕES: ││
│ │ ☑ O que conta como um "pedido"? ││
│ │ → Pedidos concluídos, não reembolsados ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROBLEMAS COMUNS A ESCLARECER: │
│ • Definição de métricas │
│ • Tratamento de fuso horário │
│ • Conversão de moeda │
│ • Necessidades de dados históricos │
│ • Requisitos de backfill │
└─────────────────────────────────────────────────────────────┘
Manutenção
Trabalho Contínuo de Pipeline
MANUTENÇÃO DE PIPELINE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFAS DE MANUTENÇÃO (Recorrentes): │
│ │
│ SEMANAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DATA-MAINT: Verificação semanal de saúde do pipeline ││
│ │ ││
│ │ ☐ Revisar falhas de pipeline ││
│ │ ☐ Verificar tendências de qualidade de dados ││
│ │ ☐ Revisar uso de recursos ││
│ │ ☐ Resolver quaisquer alertas ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MENSAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DATA-MAINT: Manutenção mensal de pipeline ││
│ │ ││
│ │ ☐ Revisar e atualizar documentação ││
│ │ ☐ Verificar dependências descontinuadas ││
│ │ ☐ Otimizar consultas lentas ││
│ │ ☐ Limpar dados/logs antigos ││
│ │ ☐ Revisar limites de monitoramento ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TRIMESTRAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DATA-MAINT: Revisão trimestral de pipeline ││
│ │ ││
│ │ ☐ Revisar arquitetura geral ││
│ │ ☐ Verificar necessidades de evolução de esquema ││
│ │ ☐ Atualizar dependências ││
│ │ ☐ Revisar controles de acesso ││
│ │ ☐ Check-in com stakeholders (ainda atendendo necessidades?) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALOCAR CAPACIDADE: │
│ ~20% do tempo de engenharia de dados para manutenção │
│ Não apenas construir novo - manter existente │
└─────────────────────────────────────────────────────────────┘