Engenharia de Dados é a disciplina que projeta, implementa e mantém fluxos e estruturas para capturar, integrar, transformar, validar e disponibilizar dados com qualidade e se
Confira!
Engenharia de Dados é a disciplina que projeta, implementa e mantém fluxos e estruturas para capturar, integrar, transformar, validar e disponibilizar dados com qualidade e segurança. Envolve Data Pipelines, modelos, armazenamento, controles de acesso e observabilidade. É diferente de Business Intelligence: a Engenharia de Dados constrói e verifica a cadeia que viabiliza a informação; o BI utiliza os dados para indicadores, relatórios e decisões. A tecnologia escolhida depende da natureza das fontes, do volume, do atraso aceitável e dos requisitos de rastreabilidade, não de uma plataforma universal.
O que faz a Engenharia de Dados
Do sistema de origem ao produto de dados
Uma empresa costuma registrar fatos em ERP, CRM, CMMS, aplicações de manutenção e sistemas operacionais. Cada plataforma possui propósito, estados, cadastros e datas próprios. O trabalho de Engenharia de Dados começa ao compreender o que cada registro representa e como ele pode ser consumido sem perder significado. Capturar um status atualizado não equivale a receber todos os eventos que produziram aquele estado. Assim, um relatório de ordens de serviço precisa distinguir novas ordens, alterações, cancelamentos e reaberturas. A definição de origem oficial, identificador e janela temporal antecede a criação das transformações.
Um produto de dados publicável deve ter consumidor, responsável, formato, granularidade, periodicidade, classificação de segurança e condições de qualidade. Um dataset de faturamento não se torna confiável apenas porque tem tabelas acessíveis; a equipe precisa saber quais documentos entram na medida, qual data define o período e como tratar estornos. A engenharia documenta essas decisões, cria testes reproduzíveis e mantém versões. Dessa forma, novos consumidores conseguem utilizar a informação sem refazer hipóteses ocultas no código do primeiro desenvolvedor.
Engenharia de Dados não é sinônimo de Analytics
Data Engineering, Data Analytics, Business Intelligence e Data Governance são capacidades complementares. A engenharia produz e sustenta os meios técnicos de captura e transformação. A área de negócio aprova definições de medidas, população elegível e finalidade. A governança estabelece ownership, retenção, classificação e decisões de alteração. Analistas avaliam padrões e implicações. Confundir essas responsabilidades leva a falhas nas quais o time técnico recebe a tarefa impossível de corrigir um indicador sem saber qual interpretação comercial ou contratual deve prevalecer.
A mesma fronteira vale para modelos preditivos. Um pipeline pode entregar séries históricas coerentes, mas não demonstra que determinada correlação é causal, nem que a amostra representa todos os regimes operacionais. A Engenharia de Dados precisa garantir disponibilidade, integridade e linhagem dos dados de treinamento e inferência. O especialista responsável pela análise avalia métodos, desempenho e limitações do modelo. Caso um sensor esteja mal calibrado, o ajuste exige evidência do processo físico; uma transformação estatística não deve ocultar defeitos de instrumentação.
Requisitos e critérios de sucesso
O levantamento especifica origens, registros esperados, formato, latência, retenção, acesso, recuperação e uso do resultado. Um pedido genérico de dados em tempo real pode não corresponder a necessidade concreta, especialmente quando o sistema produtor consolida informações mensalmente. A equipe deve perguntar qual decisão depende do dado, qual atraso é tolerável e quais mudanças na origem precisam aparecer no destino. Requisitos de disponibilidade e performance precisam considerar o conjunto da cadeia, e não apenas o servidor do dashboard.
A especificação também delimita responsabilidades de fornecedor, regras de autenticação, limites de extração e critérios de aceite. Quando o consumidor exige correções retroativas, o projeto deve comprovar que consegue identificá-las. Quando uma integração oferece somente estado atual, não se pode prometer reconstrução integral de eventos passados. Essas restrições são documentadas desde o início, permitindo comparar alternativas técnicas e contratar escopos verificáveis.
Ingestão: batch, CDC e streaming
Extração periódica e consistência
O processamento batch recolhe dados em janelas definidas. É adequado quando os relatórios são periódicos ou quando a origem não disponibiliza eventos confiáveis. Porém, uma execução bem-sucedida não prova que todos os registros foram capturados. Se documentos mudam durante a paginação, pode ocorrer leitura duplicada ou perda de alterações. A engenharia precisa investigar garantias de snapshot, ordenação e retenção, e adotar mecanismo de reconciliação compatível. Uma política de lookback pode ajudar a recuperar mudanças recentes, mas deve ter limites explícitos.
O uso de dados de sistemas operacionais exige interfaces capazes de preservar identificadores, alterações e estados de negócio. Sem esse cuidado, os pipelines transportam inconsistências para o ambiente analítico.
O impacto no sistema produtor também importa. Consultas extensas podem afetar faturamento, estoque e operações, sobretudo em horários de pico. Uma carga histórica inicial pode precisar de janela e capacidade distintas da atualização incremental. O contrato deve indicar limites de chamadas, quantidade esperada e comportamento quando o volume ultrapassa o planejamento. O aceite inclui uma amostra com registros criados, alterados e cancelados durante o processamento, verificando tanto completude quanto efeito da extração sobre a origem.
CDC e eventos
Change Data Capture pode representar mudanças em tabelas ou logs, mas a garantia de entrega depende da implementação e do período de retenção. É necessário diferenciar inserção, atualização, exclusão e alteração de estrutura, preservando identidade e ordem quando relevante. Em sistemas que publicam eventos de negócio, um webhook pode indicar mudança de status sem conter o histórico completo. O consumidor deve saber se recebeu uma ocorrência imutável ou apenas uma solicitação para consultar o estado atual.
No streaming, mensagens podem chegar repetidas ou fora de ordem. A deduplicação exige identificador confiável; timestamp semelhante não é prova de identidade. A política de entrega do broker não substitui idempotência de processamento nem reconciliação de resultados. A engenharia precisa definir janelas, atraso máximo, tratamento de mensagens inválidas e replay após falha. Um canal com baixa latência não deve ser escolhido somente por parecer mais avançado, principalmente quando aumenta complexidade sem beneficiar a decisão.
ETL, ELT e transformações versionadas
ETL realiza transformação antes de carregar dados no repositório de destino; ELT carrega informações e processa transformações no ambiente escolhido. São estratégias de execução, não garantias de qualidade. Uma arquitetura pode combinar normalização de dados sensíveis na entrada com regras semânticas posteriores. A escolha depende de volume, custo, computação disponível, segurança, latência e necessidade de reprocessar histórico. Em todos os casos, o código deve ter versão e cada execução precisa registrar parâmetros, janela e conjunto de dados utilizado.
Transformações de moeda, unidade, horário e classificação podem alterar indicadores. Um evento ocorrido em um turno pode ser recebido no seguinte e não deve trocar de período automaticamente. Um pedido com vários itens precisa de grain distinto do pedido agregado. O contrato estabelece como tratar campos nulos, registros rejeitados, alterações tardias e regras de arredondamento. Uma correção de código que muda resultados históricos deve gerar avaliação de impacto e documentação, não substituir silenciosamente números já utilizados em decisões.
Orquestração, armazenamento e modelo de consumo
Dependências de execução e recuperação
Data Pipelines podem conter extração, verificação de origem, transformação, reconciliação e publicação. O Scheduler inicia tarefas; a orquestração controla dependências, status e logs. O fluxo deve distinguir sucesso técnico de aprovação para consumo. Uma transformação concluída com sucesso pode ser bloqueada pelo Quality Gate porque faltou uma unidade inteira. Cada Run precisa identificar origem, período, versão do código e resultado dos controles. Essa rastreabilidade permite reproduzir divergências após mudanças de sistema.
Retries e backfill exigem idempotência. Reexecutar uma etapa não deve duplicar movimentações nem enviar o mesmo relatório oficial várias vezes. Quando a falha acontece depois da publicação e antes da confirmação, o procedimento precisa verificar o estado anterior para evitar efeitos colaterais. A recuperação deve demonstrar que o número de registros, os períodos e os totais continuam coerentes, e não apenas que o Job retornou estado de sucesso. Um runbook registra responsáveis, sequência segura de retomada e condição de escalonamento.
Data Warehouse, Data Lake e retenção
A escolha de armazenamento depende de consultas, formatos, volume, retenção, classificação e necessidade de histórico. Data Warehouse costuma atender consumo estruturado e governado; Data Lake pode acomodar dados de formatos e detalhamentos variados. O uso combinado não é obrigatório. Uma organização com plataforma atual funcional pode não ter benefício ao migrar para outra arquitetura. É necessário avaliar custos de licenciamento, computação, replicação e recuperação, além da capacidade de documentar e controlar os datasets.
Dados brutos e curados cumprem funções diferentes. Registros originais podem permitir replay ou investigação, enquanto modelos curados representam regras aprovadas para indicadores. Guardar todas as amostras em granularidade máxima pode ampliar custo sem necessidade, mas reduzir a série prematuramente pode ocultar picos e eventos. A política de retenção especifica finalidade, segurança, janelas e o que será preservado para auditoria. Criar várias cópias sem uma versão autoritativa pode agravar divergências entre departamentos.
Fatos, dimensões e Semantic Model
Uma Fact Table deve possuir grain definido: item de pedido, transação, amostra ou ocorrência. Dimensões atribuem contexto, como ativo, unidade, contrato ou período. Uma ligação entre tabelas de granularidade incompatível pode multiplicar valores. Cadastros que mudam precisam de política de histórico e vigência. O projeto deve decidir se relatórios mostram a estrutura corporativa atual ou a vigente quando o fato ocorreu. Essa escolha modifica comparações e deve ficar explícita no Semantic Model.
O consumidor precisa saber fórmulas, filtros, população e atualização das medidas. Uma taxa não deve ser consolidada pela soma de percentuais de unidades diferentes. O modelo deve distinguir documento cancelado de documento válido, previsão de realizado e ausência de observação de valor zero. Os casos de homologação devem permitir calcular um resultado de referência a partir da origem e compará-lo com o indicador. A capacidade de explicar uma diferença é mais importante que produzir o mesmo valor por ajustes manuais.
Qualidade, segurança e observabilidade
Regras de qualidade aplicadas ao uso
Completude, validade, atualidade, consistência e unicidade são dimensões úteis, mas o controle precisa estar associado a decisões reais. Em um fechamento financeiro, um conjunto parcial de documentos pode bloquear a publicação. Em análise exploratória de manutenção, uma lacuna explicitada pode permitir consulta condicionada. O projeto define universo esperado, tolerância, Data Owner e tratamento de exceções. Rejeitar registros sem conservar a causa prejudica a investigação; transformá-los em valores médios sem identificação cria falsa precisão.
A avaliação deve distinguir erro de transporte, problema de cadastro e comportamento legítimo da operação. Uma medição extrema pode refletir falha física que justamente precisa ser analisada. Quando a regra é alterada, os resultados afetados devem ser identificados e aprovados. Os Quality Gates não são meras mensagens de log: devem impedir publicação ou qualificar o estado dos dados, de acordo com a criticidade. A equipe precisa provar o comportamento com amostras conhecidas, dados atrasados e falhas controladas.
Definir critérios de qualidade e de aceitação das medidas antes da implantação ajuda a separar erros de processamento de divergências legítimas entre sistemas. A avaliação técnica pode estabelecer quais evidências sustentam uma decisão.
Proteção de dados de ponta a ponta
A combinação de fontes pode revelar informação mais sensível do que cada sistema isolado. A arquitetura deve prever classificação, minimização, segregação de ambientes, acesso por função, contas de serviço, gestão de credenciais e retenção. Um gestor que pode consultar receita total de sua unidade não recebe automaticamente acesso a registros pessoais. Restrições precisam alcançar exportações, arquivos temporários e relatórios automatizados, pois filtros do dashboard podem não proteger todos os formatos de saída.
Em ambientes de OT, usar dados de automação predial e controle industrial não autoriza comandos em PLC ou SCADA. As fronteiras de comunicação devem ser definidas com responsáveis por segurança e continuidade. Quando houver tratamento de dados pessoais, a finalidade e as responsabilidades precisam considerar a LGPD conforme o caso. Uma plataforma tecnicamente protegida não assegura conformidade legal por si só. Logs devem registrar ações relevantes sem expor segredos ou dados desnecessários, e as permissões precisam ser revistas após mudanças de contrato e de função.
Observabilidade versus Data Lineage
Observabilidade monitora freshness, volumes, falhas, rejeições, desempenho e saúde das dependências. Data Lineage descreve relações entre origem, transformação e consumidor. São capacidades complementares: um diagrama de dependências não comprova que todas as execuções foram concluídas, e um servidor disponível não demonstra que um KPI está correto. Uma falha de fonte deve indicar quais janelas e indicadores podem ter sido afetados. O alerta precisa chegar à equipe responsável pelo componente, com evidências para decidir sobre recuperação e republicação.
O runbook deve contemplar dados duplicados, mudanças de schema e interrupção da origem. Após replay, a equipe precisa reconciliar resultados e informar possíveis revisões históricas. No-data não deve ser interpretado como desempenho zero nem como operação normal. A manutenção também precisa revisar thresholds e controles quando as fontes e os volumes mudarem. Sem ownership, o monitoramento produz um volume crescente de alertas sem reduzir o tempo necessário para resolver problemas.
| Decisão de engenharia | Variáveis que condicionam | Evidência de aceite |
|---|---|---|
| Batch, CDC ou streaming | Latência, eventos e capacidade da origem | Mudanças tardias reconciliadas |
| Armazenamento e retenção | Volume, formatos, segurança e custo | Histórico e recuperação verificáveis |
| Modelagem de dados | Grain, chaves, períodos e regras | Resultado reproduzível por caso |
| Quality Gates | Criticidade, completude e exceções | Rejeições rastreáveis e tratamento |
| Observabilidade e replay | Dependências, SLA, falhas e idempotência | Incidente simulado e retorno consistente |
Exemplos e critérios de aceite
Caso ERP e indicadores comerciais
Considere o desenvolvimento de uma base corporativa que reúna pedidos, faturamento e recebimentos. Cada fenômeno tem estados e datas diferentes. A engenharia define chaves, timestamps, período de competência e regras de elegibilidade antes de criar um relatório. O teste deve selecionar pedido com vários itens, faturamento parcial, cancelamento, estorno e recebimento em outro período. A soma de documentos não deve ser alterada apenas para coincidir visualmente com um relatório de referência. É preciso esclarecer se as fontes estão medindo o mesmo evento e a mesma população.
A homologação também precisa simular alteração de unidade e reclassificação retroativa, com registro de versões. Um cálculo de margem pode depender de custo disponível apenas após fechamento; essa limitação deve ser exibida no consumo. A prova de qualidade compara totais por unidade, período e status, incluindo registros rejeitados. A equipe deve demonstrar que consegue reprocessar uma janela conhecida e reproduzir resultado idêntico quando não houve mudança de regra. Se a transformação mudou, a diferença precisa de trilha e aprovação.
Caso telemetria e manutenção
Em uma instalação, medições de temperatura e consumo podem ser reunidas a ordens do CMMS. A origem física e a administrativa não representam o mesmo fenômeno: uma ordem encerrada não comprova equipamento disponível, e uma perda de comunicação não significa falha física. O projeto deve manter identificadores e horários que permitam relacionar esses fatos sem confundi-los. A conversão de unidade e o tratamento de sensores substituídos precisam constar do Data Contract. A média por período deve registrar como lida com amostras ausentes.
O ensaio integrado cria interrupção de gateway, retransmissão de eventos e correção de cadastro de ativo. É necessário confirmar que séries temporais e ordens mantêm identidade correta, que duplicações não alteram medidas e que períodos incompletos ficam marcados. Um KPI de disponibilidade deve declarar janela e exclusões, distinguindo monitoramento analítico de controle operacional. A entrega requer evidência de recuperação de dados e capacidade de investigar uma anomalia sem recorrer à memória da equipe de desenvolvimento.
Entregáveis, manutenção e contratação
O escopo de Engenharia de Dados precisa explicitar sistemas, interfaces, volume, atualização, critérios de qualidade e responsáveis pelas definições. Os entregáveis incluem arquitetura, contratos de dados, modelos, pipelines versionados, testes, documentação de configuração, segurança e procedimentos de operação. Uma consultoria de diagnóstico, uma implementação e uma verificação independente possuem objetivos diferentes; o contrato deve evitar prometer todos eles quando apenas um foi solicitado. A seleção de tecnologias deve respeitar a plataforma existente e os riscos da organização.
Na operação assistida, a equipe acompanha incidentes reais para testar diagnóstico, escalonamento e correção. O aceite deve demonstrar extração completa, reprocessamento seguro, coerência semântica, proteção por perfis e continuidade após falha. A expansão deve ter prioridade baseada em necessidades: inclusão de uma unidade, redução de latência útil ou melhoria de qualidade. O resultado não é criar um ambiente tecnicamente complexo, mas manter informação reproduzível e utilizável mesmo quando sistemas, fornecedores e processos evoluem.
O desenvolvimento dos fluxos é aprofundado em Data Pipeline, enquanto ETL e ELT e Data Quality detalham disciplinas técnicas complementares.
Ensaio de mudança de contrato, reconciliação e recuperação
Um ensaio integrado de Engenharia de Dados pode utilizar uma origem com documentos de faturamento, cancelamentos e alterações de unidade de negócio. Antes de executar a carga, é necessário congelar uma amostra de referência com identificadores, timestamps, valores e status conhecidos. A equipe registra a versão do contrato, o esquema da fonte e a transformação vigente, além dos totais esperados por período e população. A primeira execução deve comprovar que o conjunto completo foi capturado e que nenhuma transformação alterou o significado de faturamento, pagamento ou pedido. Em seguida, uma alteração retroativa em documento previamente importado deve ser identificada por mecanismo previsto na arquitetura. A homologação compara o dataset curado à referência e explica diferenças que resultem de mudança legítima no processo. A validação não pode simplesmente eliminar registros conflitantes para obter um total conveniente.
Quando fontes, cadastros e regras de aprovação apresentam inconsistências recorrentes, automatizar extrações não elimina a causa. Identificar as etapas e responsabilidades do processo permite corrigir a origem e evitar retrabalho analítico.
O segundo ensaio interrompe a extração entre duas páginas ou a transformação entre a escrita de dados temporários e a publicação da versão final. O procedimento de recuperação precisa distinguir o conjunto incompleto daquele que recebeu aprovação para consumo. Um replay não deve multiplicar documentos e precisa conservar os identificadores que permitam relacionar a execução original à tentativa de recuperação. Quando a origem limita o histórico ou altera o cursor após determinado período, o contrato precisa estabelecer a janela de reconciliação possível. A equipe verifica logs de Run, Quality Gates e quantidade de registros por chave; também mede impacto da recuperação sobre o ERP. Um processamento que retorna sucesso, mas deixa metade das unidades sem atualização, não satisfaz o aceite do indicador corporativo.
Outro cenário introduz uma alteração de schema em que um campo opcional passa a ser exigido por um consumidor, enquanto outro continua utilizando versão anterior. A arquitetura precisa manter compatibilidade ou apresentar plano de migração com avisos e testes. Adicionar uma propriedade não é sempre uma mudança inofensiva, especialmente quando clientes rejeitam campos inesperados. O catálogo deve identificar produtores, consumidores e regras semânticas afetadas. A equipe avalia se a mudança altera a população de um KPI e se é necessário recalcular períodos anteriores. A execução de regressão usa dados de referência, e o resultado aprovado conserva versão do código e documentação do novo comportamento. O objetivo é provar que a cadeia pode evoluir sem apagar a capacidade de explicar resultados emitidos anteriormente.
Na integração de fontes temporais, o teste inclui sensores que chegam atrasados, timestamps divergentes e substituição de equipamento. O contrato precisa registrar unidade de engenharia, identificação do ativo, regime de operação e estado de qualidade da medição. Uma média calculada apenas sobre amostras recebidas pode esconder falha integral de comunicação. A equipe deve comparar contagem esperada e observada e manter explícitos intervalos inválidos. Se o projeto exige associar medições a ordens do CMMS, é necessário separar o histórico físico de estados administrativos. A medição de disponibilidade não pode ser inferida simplesmente da existência de ordem concluída. Essa distinção sustenta análise de manutenção sem produzir causalidade fictícia.
A prova de segurança deve executar consultas com usuários de áreas e unidades distintas, além de serviços que só possuem privilégio de leitura. Uma conta com acesso para coletar dados agregados não deveria conseguir alterar pedidos na origem. O teste verifica restrições por objeto e por propriedade, tokens expirados, exportação e arquivos temporários de processamento. Em ambientes sujeitos à LGPD, a finalidade e a minimização das informações precisam ser consideradas conforme o caso, e os logs não devem incluir segredos ou valores pessoais desnecessários. Uma extração que funciona tecnicamente, mas expõe informações fora do escopo, deve ser considerada não conforme. O pacote de entrega registra a matriz de acesso efetivamente testada.
Na operação assistida, os resultados dos ensaios orientam limites e alertas por criticidade. Um atraso de quinze minutos pode ser normal para um relatório com fechamento diário e inadequado para um acompanhamento de incidentes que exige resposta imediata. A equipe define critérios de freshness, retenção e escalonamento a partir do uso. Quando há erro, o runbook precisa apontar a etapa e o responsável, indicar como identificar a última execução válida e como publicar uma correção auditável. O aceite final reúne arquitetura, contratos, dicionário, amostras reconciliadas, resultados de carga, documentação e plano de manutenção. A capacidade de repetir o teste por outra equipe representa maturidade maior que uma demonstração isolada do pipeline.
Custos de sustentação e capacidade futura
O custo total da Engenharia de Dados inclui mais que armazenamento e computação. Conectores podem depender de licenças, limites de API e manutenção de versões; a observabilidade exige monitoramento; dados históricos criam obrigações de retenção e segurança; e correções de fontes podem demandar reprocessamento de períodos inteiros. O projeto deve estimar crescimento das fontes, janelas de carga, tamanho de mensagens e concorrência dos consumidores. Ao comparar alternativas, convém medir o comportamento de uma amostra representativa e não apenas utilizar tabela de preço por volume. Uma arquitetura econômica no piloto pode ser onerosa em produção se exigir cópias redundantes, consultas repetidas ao ERP ou transformação de toda a base a cada execução.
A evolução também depende de transferência de conhecimento. Scripts sem versão, credenciais pessoais e regras conhecidas apenas pelo desenvolvedor criam dependência que não aparece no diagrama. A entrega deve registrar variáveis de ambiente sem expor segredos, contratos, origem das medidas, procedimentos de mudança e critérios de qualidade. Um teste com equipe diferente da responsável pela construção ajuda a demonstrar se a solução é operável. O aceite deve valorizar a capacidade de diagnosticar falhas e reconstituir resultados após mudanças de fornecedor ou de plataforma.
Considerações finais
Engenharia de Dados cria as condições para transformar registros operacionais em informação utilizável com confiança. O projeto deve preservar significado, identificação, temporalidade, regras de transformação e controle sobre o estado de atualização. Batch, CDC e streaming são alternativas condicionadas ao processo, e nenhuma substitui qualidade, reconciliação, segurança ou responsabilidade por resultados. A capacidade de recuperar falhas e reproduzir indicadores é parte do aceite, não apenas requisito de manutenção posterior.
Em uma contratação, convém distinguir diagnóstico, implantação e verificação independente, com responsabilidades pelas regras de negócio e pelos sistemas de origem. A entrega deve reunir códigos e configurações versionados, testes de casos reais, documentação e procedimentos de operação assistida. A evolução da plataforma pode incorporar mais fontes e capacidades analíticas, desde que não perca rastreabilidade ou transforme divergências legítimas em números artificialmente harmonizados.
Referências técnicas
[1] APACHE SOFTWARE FOUNDATION. Apache Airflow: Core Concepts. Disponível em: https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/
[2] MICROSOFT CORPORATION. Understand star schema and the importance for Power BI. Microsoft Learn. Disponível em: https://learn.microsoft.com/en-us/power-bi/guidance/star-schema
[3] MICROSOFT CORPORATION. Cloud Adoption Framework for Azure. Microsoft Learn. Disponível em: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/overview
[4] CLOUD NATIVE COMPUTING FOUNDATION. CloudEvents Specification. Disponível em: https://github.com/cloudevents/spec
Perguntas frequentes
Disciplina que projeta e mantém pipelines, modelos, armazenamento, segurança e controles de qualidade para disponibilizar dados confiáveis.
A primeira prepara e sustenta os dados; Business Intelligence os utiliza para análises, relatórios e decisões.
Não. Pipeline é um fluxo; Engenharia de Dados engloba arquitetura, modelagem, contratos, qualidade e operação de vários fluxos.
Quando a latência necessária permite consolidação periódica e a fonte suporta extração confiável nesse regime.
Change Data Capture representa alterações na origem, dependendo de garantias de retenção, exclusão e consistência.
Não. Eventos podem ser repetidos ou chegar fora de ordem e exigem identidade, idempotência e reconciliação.
Não. A decisão depende de infraestrutura, volume, segurança, custo e necessidade de reprocessamento.
Para estabelecer esquema, semântica, atualização, qualidade e responsabilidades entre produtores e consumidores.
Verificação que aprova, bloqueia ou condiciona publicação conforme regras e responsáveis definidos.
Pela associação entre fontes, regras, versões, execuções e registros de Data Lineage.
Avaliando consulta, volume, histórico, retenção, classificação, custo e capacidade de recuperação.
Reconciliação, mudanças retroativas, duplicados, indisponibilidade, replay, autorização e desempenho sob carga.
