Como solucionar problemas de qualidade de dados na sincronização em lote de tabela única - DataWorks: Central de Documentação do Alibaba Cloud

Como funciona

O dataworks Data Integration utiliza uma arquitetura baseada em processamento paralelo e plugins para garantir uma sincronização de dados eficiente e estável.

Modelo de execução paralela (job e task)

Para maximizar o throughput de dados, uma tarefa de sincronização adota uma estrutura de execução em dois níveis:

Job: Uma instância em execução de uma tarefa de sincronização.
Task: A menor unidade de execução de um job. Um job é dividido em múltiplas tasks que podem ser executadas simultaneamente em uma ou mais máquinas.

Cada task processa um shard de dados independente. Esse mecanismo de processamento paralelo melhora significativamente a eficiência geral da sincronização de dados.

Fluxo de dados baseado em plugins (reader e writer)

Dentro de cada task, o fluxo de dados é orquestrado por um plugin reader e um plugin writer, conectados por um buffer em memória:

Plugin reader: Conecta-se ao armazenamento de dados source, lê os dados e os envia para o buffer interno.
Plugin writer: Consome dados do buffer e os grava no armazenamento de dados de destino.

Nota

Os plugins reader e writer seguem rigorosamente os protocolos e restrições nativos, como tipos de dados e restrições de chave primária, de suas respectivas fontes de dados. Portanto, o comportamento final da sincronização e a consistência dos dados dependem da implementação dos sistemas source e de destino.

Solucionar problemas de consistência de dados no lado do writer

O plugin writer do Data Integration grava dados da source para o destino. Cada tipo de fonte de dados de destino possui um plugin writer correspondente. O plugin writer envia dados ao destino usando JDBC ou o SDK da fonte de dados, com base no modo de gravação configurado, incluindo estratégias de resolução de conflitos.

Nota

Os resultados reais de gravação e o conteúdo dos dados no destino dependem do modo de gravação e das restrições da tabela de destino.

Caso enfrente problemas de qualidade de dados, como contagem de registros ou conteúdo dos dados, após a conclusão de uma tarefa de sincronização, revise os seguintes problemas comuns relacionados ao writer.

Causa	Descrição	Solução
Modo de gravação configurado incorretamente	O plugin writer grava os dados da source no destino usando o modo de gravação selecionado. Se os dados da source entrarem em conflito com as restrições da tabela de destino, isso pode resultar em falhas de inserção (dirty data), descartes silenciosos ou substituição de registros.	Selecione o modo de gravação correto para o seu caso de uso. Para obter mais informações, consulte Appendix: Write modes for relational databases.
Limiar de dirty data atingido	A quantidade de dirty data, causada por problemas como incompatibilidade de tipos de dados ou conteúdo excessivamente grande, excede o limiar configurado. Isso faz com que a tarefa falhe e impede que alguns dados sejam gravados.	Identifique a causa da dirty data e resolva o problema. Alternativamente, determine se a dirty data pode ser tolerada e ignorada. Nota Se sua tarefa não puder tolerar dirty data, modifique o limiar de dirty data em Task Configuration > Channel Configuration. Para obter mais informações sobre como configurar o limiar de dirty data, consulte codeless UI configuration. Para saber mais sobre o que constitui dirty data, consulte Data Integration.
Consulta de dados prematura	Os dados são consultados antes da conclusão da tarefa de sincronização. Em algumas fontes de dados, como Hive e MaxCompute (configurável), os dados podem ficar parcial ou totalmente indisponíveis até que a tarefa termine.	Sempre verifique os dados na tabela de destino após confirmar que a instância da tarefa de sincronização foi executada com sucesso.
Dependência de nó ausente	Se nenhuma dependência explícita de Grafo Acíclico Direcionado (DAG) for configurada entre uma tarefa de análise downstream e uma tarefa de sincronização upstream, a tarefa downstream poderá iniciar prematuramente e ler dados incompletos.	No DataStudio, configure uma dependência explícita de nó pai-filho entre as tarefas upstream e downstream. Evite usar dependências fracas, como `max_pt`.
Múltiplas tarefas de sincronização gravando na mesma tabela ou partição simultaneamente, causando interferência.	Execução simultânea insegura de tarefas de sincronização. No MaxCompute e Hologres, se duas tarefas gravarem na mesma partição e estiverem configuradas para truncar a partição antes da gravação, a segunda tarefa poderá apagar os dados gravados pela primeira. Em bancos de dados relacionais, se instruções pre-SQL ou post-SQL estiverem configuradas, as instruções SQL de uma segunda tarefa podem interferir nos dados gravados pela primeira tarefa.	Se o conflito for causado por múltiplas instâncias periódicas do mesmo nó, configure uma self-dependency para garantir que a próxima instância inicie somente após a conclusão da anterior. Evite projetar tarefas que gravem no mesmo destino simultaneamente.
Tarefa não configurada para execução idempotente	A tarefa não é idempotente, o que significa que execuções múltiplas produzem resultados diferentes. Reexecutar a tarefa pode causar a inserção de dados duplicados ou a sobrescrita incorreta de dados.	1. Sempre que possível, projete a tarefa para ser idempotente. Por exemplo, use o modo `REPLACE INTO`. 2. Se não for possível tornar a tarefa idempotente, tenha cautela ao reexecutá-la e configure alertas de sucesso para evitar novas tentativas desnecessárias.
Expressão de partição incorreta	No MaxCompute, a maioria das tabelas de dados é particionada, e os valores de partição costumam ser parâmetros de agendamento do dataworks, como $bizdate. Erros comuns incluem: O parâmetro de agendamento não é substituído corretamente. Como resultado, os dados são gravados em uma partição com um nome literal, como ds=$bizdate, em vez da data comercial real, como ds=20230118. Uma consulta downstream usa uma expressão de partição que não é avaliada corretamente, fazendo com que a consulta leia dados da partição errada.	Verifique as expressões de variáveis na tarefa de sincronização de dados. Confirme se a configuração do parâmetro de agendamento está correta e se os parâmetros de tempo de execução na instância da tarefa avaliam para os valores esperados.
Incompatibilidade de tipo de dados ou fuso horário	Tipos de dados ou configurações de fuso horário inconsistentes entre a source e o destino podem causar truncamento de dados, conversão incorreta ou discrepâncias durante comparações.	Confirme as diferenças de tipo de dados e fuso horário entre a source e o destino. Decida se deve aceitar o estado atual ou modificar os parâmetros de tipo de dados e fuso horário no destino.
Dados de destino alterados por outros processos	Se outros aplicativos modificarem a fonte de dados de destino simultaneamente, seu conteúdo poderá ficar inconsistente com os dados da source.	Garanta que nenhum outro processo grave na tabela de destino durante a janela de sincronização. Se gravações simultâneas forem um comportamento esperado, você deve aceitar as discrepâncias de dados resultantes.

Apêndice: Modos de gravação para bancos de dados relacionais

Tipo de protocolo	Modo de gravação	Comportamento em caso de conflito	Comportamento sem conflito	Quando usar
Protocolo Geral/MySQL	`insert into`	A inserção falha e gera dirty data.	Insere novos dados.	Anexar dados para sincronização completa ou incremental sem sobrescrever ou modificar registros existentes.
	`replace into`	Substitui a linha antiga excluindo-a primeiro e depois inserindo a nova linha.	Insere novos dados.	Sobrescrever completamente registros antigos com os dados mais recentes.
	`insert into ... on duplicate key update`	Atualiza a linha antiga modificando apenas campos especificados com novos dados.	Insere novos dados.	Atualizar campos específicos em um registro enquanto preserva outros, como um timestamp de criação.
	`insert ignore into`	Ignora a nova linha sem gravá-la ou gerar um erro.	Insere novos dados.	Inserir apenas dados que ainda não existem e não realizar nenhuma ação em registros existentes.
PostgreSQL	`insert on conflict do nothing`	Ignora a nova linha sem gravá-la ou gerar um erro.	Insere novos dados.	Inserir apenas dados que ainda não existem e não realizar nenhuma ação em registros existentes.
	`insert on conflict do update`	Atualiza a linha antiga modificando campos especificados na linha conflitante com novos dados.	Insere novos dados.	Atualizar campos específicos em um registro enquanto preserva outros, como um timestamp de criação.
	`copy on conflict do nothing`	Descarta linhas conflitantes. Usa o protocolo `COPY` de alto desempenho e ignora novos dados em caso de conflito sem gerar dirty data.	Insere novos dados em massa.	Anexar grandes lotes de dados de forma eficiente, permitindo que registros duplicados sejam ignorados.
	`copy on conflict do update`	Atualiza linhas conflitantes. Usa o protocolo `COPY` e sobrescreve dados antigos com novos dados em caso de conflito.	Insere novos dados em massa.	Sincronizar grandes lotes de dados de forma eficiente, sobrescrevendo registros antigos com os dados mais recentes.
-	`merge into`	Não suportado.

Solucionar problemas de consistência de dados no lado do reader

O plugin reader do Data Integration conecta-se ao armazenamento de dados source, extrai os dados e os entrega ao plugin writer. Cada tipo de fonte de dados source possui um plugin reader correspondente. O plugin usa JDBC ou o SDK da fonte de dados para extrair dados com base no modo de extração configurado, que pode incluir filtros, tabelas, partições e colunas.

Nota

Os resultados reais de leitura dependem do mecanismo de sincronização de dados, das alterações nos dados da source e da configuração da tarefa.

Caso enfrente problemas de qualidade de dados, como contagem de registros ou conteúdo dos dados, após a conclusão de uma tarefa de sincronização, revise os seguintes problemas comuns relacionados ao reader.

Causa	Descrição	Solução
Alterações simultâneas nos dados da source	Aplicativos externos podem ainda estar modificando os dados da source durante a operação de leitura. Portanto, a tarefa de sincronização captura um snapshot dos dados no momento da leitura, e não o estado absolutamente mais recente dos dados. Para habilitar a leitura paralela, um job de sincronização é dividido em múltiplas tasks que emitem consultas independentes ao banco de dados. Devido ao isolamento de transações do banco de dados, cada task recupera um snapshot de dados de um ponto diferente no tempo. Como resultado, o job não consegue capturar alterações de dados que ocorrem após o início de todas as suas tasks.	Aceite esse comportamento como um resultado esperado da sincronização de dados de alto throughput. Reexecutar a tarefa pode produzir resultados diferentes devido a alterações em tempo real nos dados da source.
Condições de filtro incorretas	Para MySQL, é possível configurar uma cláusula `WHERE` para filtrar dados extraídos. Se a cláusula contiver um parâmetro de agendamento, como em `gmt_modify >= ${bizdate}`, um erro comum é a substituição incorreta do parâmetro. Por exemplo, a tarefa pode filtrar apenas um dia de dados quando dois dias são necessários. Para MaxCompute, ao ler dados de uma tabela particionada, expressões de variáveis são frequentemente configuradas para parâmetros de partição, como `pt=${bizdate}`. Esses parâmetros podem ser facilmente mal configurados ou falhar na substituição.	Verifique as expressões de variáveis de agendamento na tarefa de sincronização de dados. Confirme se a configuração do parâmetro de agendamento está correta e se os valores dos parâmetros são substituídos conforme esperado em tempo de execução.
Dirty data no lado do reader	Ocorre uma falha de análise ao ler dados da source. Isso é raro em bancos de dados estruturados, mas pode acontecer com fontes de dados semiestruturadas, como arquivos CSV ou JSON no oss. Erros de formato podem fazer com que alguns registros sejam ignorados.	Verifique o log de execução da tarefa em busca de erros de análise ou exceções de formato e corrija os arquivos de dados da source. Ajuste a configuração de tolerância a dirty data.

Solucionar problemas de ambiente

Causa	Solução
Consulta à fonte de dados, tabela ou partição errada	Em um workspace do dataworks no modo padrão, a development and production environment isolation é aplicada. Uma tarefa de sincronização em lote de tabela única usa a fonte de dados de desenvolvimento no ambiente de desenvolvimento e a fonte de dados de produção no ambiente de produção. Ao comparar quantidade e conteúdo de dados, confirme qual ambiente de fonte de dados você está consultando para evitar discrepâncias. Em produção, fontes de dados online frequentemente possuem ambientes de staging ou teste correspondentes. O banco de dados usado pela tarefa de sincronização pode diferir do banco de dados de staging ou teste. Ao verificar dados, cheque essas diferenças ambientais. Ao sincronizar dados semiestruturados, múltiplos arquivos costumam estar envolvidos. Confirme se você está lendo e gravando o conjunto completo de arquivos.
Dependências upstream não atendidas	Se os dados forem gerados periodicamente, como por uma tarefa recorrente de sincronização ou mesclagem de dados, garanta que as tarefas upstream que geram esses dados tenham sido executadas e concluídas com sucesso.

Nota

Como etapa geral de solução de problemas, execute a tarefa várias vezes para observar e comparar os resultados da sincronização. Você também pode tentar alternar a fonte de dados source ou de destino para testes comparativos. Esses testes ajudam a restringir o problema.