Solução de problemas de qualidade de dados na sincronização offline de tabela única - DataWorks: Central de Documentação do Alibaba Cloud

Como funciona

O Data Integration usa processamento paralelo e arquitetura baseada em plugins para mover dados com eficiência.

Modelo de execução

Uma tarefa de sincronização executa como um Job. Cada Job divide-se em múltiplas Tasks, a menor unidade de execução. As Tasks executam simultaneamente em uma ou mais máquinas, e cada uma processa um shard de dados independente.

Fluxo de dados em cada Task

Source → Reader plugin → memory buffer → Writer plugin → Destination

Plugin Reader: Conecta-se à source, lê os dados e os envia ao buffer.
Plugin Writer: Consome dados do buffer e os grava no destino.

Os plugins Reader e Writer seguem os protocolos nativos de leitura e escrita e as restrições de dados das respectivas fontes, incluindo tipos de dados e limites de chave primária. O resultado final da sincronização depende dessas regras, não apenas da configuração da tarefa.

Solucionar problemas no lado do Writer

O plugin Writer conecta-se ao destino e grava dados via Java Database Connectivity (JDBC) ou pelo kit de desenvolvimento de software (SDK) do destino. O resultado real depende do modo de gravação configurado e das restrições da tabela de destino.

Analise as causas a seguir caso haja registros ausentes, duplicados ou com conteúdo inesperado no destino.

Causa	Descrição	Solução
Modo de gravação configurado incorretamente	O Writer usa o modo de gravação selecionado para resolver conflitos entre os dados da source e as restrições da tabela de destino. Um modo inadequado pode causar falha nas inserções (dados sujos), omissão silenciosa ou sobrescrita incorreta de registros.	Selecione o modo de gravação correto para o seu caso de uso. Consulte Modos de gravação para bancos de dados relacionais.
Limiar de dados sujos atingido	Dados sujos ocorrem quando um valor é incompatível com a coluna de destino — por exemplo, um valor de string como `abc` gravado em uma coluna de inteiro, ou um valor que excede o limite de comprimento da coluna. Cada linha desse tipo conta contra o limiar configurado. Ao exceder o limiar, a tarefa falha e a gravação dos registros restantes cessa. Para verificar quantas linhas foram ignoradas, abra o log de execução da tarefa e procure entradas de dados sujos ou erros de análise.	Identifique e corrija a origem dos dados sujos. Se alguns dados sujos forem aceitáveis, aumente o limiar em Task Configuration > Channel Configuration. Para detalhes de configuração, consulte Configuração pela interface sem código. Para saber o que conta como dado sujo, consulte Termos.
Consulta prematura aos dados	Em fontes como Hive e MaxCompute (configurável), os dados gravados podem ficar parcial ou totalmente invisíveis até a conclusão da tarefa.	Sempre verifique os dados de destino após confirmar a conclusão bem-sucedida da instância da tarefa de sincronização.
Dependências de nó ausentes	Sem dependência configurada entre uma tarefa de análise downstream e a tarefa de sincronização upstream, a tarefa downstream pode iniciar antes do término da sincronização e ler dados incompletos.	No DataStudio, configure dependências de nó pai-filho entre tarefas upstream e downstream. Evite dependências fracas como `max_pt`.
Gravações simultâneas na mesma tabela ou partição	MaxCompute / Hologres: Se duas tarefas gravarem na mesma partição com configuração de truncamento prévio, a segunda tarefa apagará os dados da primeira. Bancos de dados relacionais: instruções pre-SQL ou post-SQL de uma tarefa interferem nos dados gravados por outra.	Para instâncias recorrentes do mesmo nó, configure uma autodependência para que cada instância aguarde a conclusão da anterior. Evite projetar tarefas que gravem simultaneamente no mesmo destino.
Tarefa não configurada para execução idempotente	Uma tarefa não idempotente produz resultados diferentes a cada execução. Reexecutá-la pode causar inserções duplicadas ou sobrescritas incorretas.	Projete a tarefa para ser idempotente — por exemplo, use o modo `REPLACE INTO`. Caso a idempotência não seja viável, tenha cautela ao reexecutar a tarefa. Configure alertas de sucesso para evitar novas tentativas desnecessárias.
Expressão de partição incorreta	No MaxCompute, substitua parâmetros de agendamento como `$bizdate` na expressão de partição durante o tempo de execução. Erros comuns incluem: parâmetro literal (dados direcionados a uma partição chamada `ds=$bizdate` em vez de `ds=20230118`) ou consulta downstream lendo da partição errada.	Verifique as expressões de variáveis na tarefa de sincronização. Confirme a configuração do parâmetro de agendamento e valide se os parâmetros de tempo de execução foram substituídos pelos valores esperados.
Incompatibilidade de tipo de dados ou fuso horário	Tipos de dados ou fusos horários inconsistentes entre source e destino podem truncar valores, causar conversões incorretas ou gerar discrepâncias na comparação de dados.	Confirme as diferenças de tipo e fuso horário entre source e destino. Decida se mantém as configurações atuais ou atualize os parâmetros de tipo de dados e fuso horário no destino.
Alteração nos dados de destino	Gravações simultâneas de outros aplicativos tornam o destino inconsistente com a source.	Garanta que nenhum outro processo grave na tabela de destino durante a janela de sincronização. Se a gravação simultânea for esperada, aceite a discrepância resultante.

Modos de gravação para bancos de dados relacionais

Selecione o modo de gravação adequado aos seus requisitos de tratamento de conflitos.

Protocolo Geral/MySQL

Modo de gravação	Comportamento em conflito	Comportamento sem conflito	Quando usar
`insert into`	Falha e gera dados sujos	Insere normalmente	Anexação completa ou incremental sem sobrescrita de registros existentes
`replace into`	Exclui a linha antiga e insere a nova linha	Insere normalmente	Sobrescrita completa de registros antigos com os dados mais recentes
`insert into ... on duplicate key update`	Atualiza campos especificados na linha existente	Insere normalmente	Atualização de campos específicos mantendo outros, como timestamp de criação
`insert ignore into`	Ignora a nova linha sem erro	Insere normalmente	Inserção exclusiva de novos dados, sem ação sobre registros existentes

PostgreSQL

Modo de gravação	Comportamento em conflito	Comportamento sem conflito	Quando usar
`insert on conflict do nothing`	Ignora a nova linha sem erro	Insere normalmente	Inserção exclusiva de novos dados, sem ação sobre registros existentes
`insert on conflict do update`	Atualiza campos especificados na linha em conflito	Insere normalmente	Atualização de campos específicos mantendo outros, como timestamp de criação
`copy on conflict do nothing`	Descarta linhas conflitantes via protocolo `COPY` de alto desempenho; não gera dados sujos	Insere em massa normalmente	Anexação eficiente de grandes lotes de dados, ignorando duplicatas
`copy on conflict do update`	Sobrescreve a linha conflitante via protocolo `COPY`	Insere em massa normalmente	Sincronização eficiente de grandes lotes de dados, sobrescrevendo registros antigos
`merge into`	Não suportado	—	—

Solucionar problemas no lado do Reader

O plugin Reader conecta-se à source e extrai dados via JDBC ou SDK da source. O resultado real da leitura depende do modo de extração de dados — incluindo condições de filtro, tabelas, partições e colunas — além de alterações nos dados da source e na configuração da tarefa.

Verifique as causas abaixo se a quantidade ou o conteúdo dos dados lidos não corresponder ao esperado.

Causa	Descrição	Solução
Alterações simultâneas nos dados da source	A tarefa de sincronização captura um snapshot dos dados no momento da leitura, não o estado absoluto mais recente. Como um Job divide-se em múltiplas Tasks que emitem consultas independentes, cada Task pode capturar um snapshot de um ponto ligeiramente diferente no tempo. Alterações posteriores ao início de todas as Tasks não são capturadas.	Aceite esse comportamento normal para sincronização de alto throughput. Executar a tarefa várias vezes pode produzir resultados diferentes devido a alterações em tempo real nos dados da source.
Condições de consulta incorretas	MySQL: Substitua corretamente cláusulas `WHERE` com parâmetros de agendamento como `gmt_modify >= ${bizdate}` em tempo de execução. Um erro comum é filtrar dados de apenas um dia quando dois são necessários. MaxCompute: Parâmetros de partição como `pt=${bizdate}` são frequentemente mal configurados ou falham na substituição.	Verifique as expressões de variáveis de agendamento na tarefa de sincronização. Confirme a configuração do parâmetro de agendamento e valide os valores reais de substituição nos parâmetros de tempo de execução da instância da tarefa.
Dados sujos no lado do Reader	A análise falha ao ler dados da source. Isso é raro em bancos de dados estruturados, mas comum em fontes semiestruturadas — por exemplo, arquivos CSV ou JSON no Object Storage Service (OSS) ou Hadoop Distributed File System (HDFS) com erros de formato.	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 origem. Alternativamente, ajuste a configuração de tolerância a dados sujos.

Solucionar problemas de ambiente

Problemas de qualidade de dados também podem originar-se da configuração do ambiente, não da tarefa de sincronização em si.

Causa	Solução
Consulta à source de dados, tabela ou partição errada	Em workspaces do DataWorks no modo padrão, as fontes de dados são isoladas entre os ambientes de desenvolvimento e produção. Uma tarefa de sincronização offline de tabela única usa a source de dados de desenvolvimento no ambiente de desenvolvimento e a source de dados de produção no ambiente de produção. Confirme qual ambiente você está consultando. Verifique também se a produção possui ambiente correspondente de pré-lançamento ou teste, pois esses bancos diferem do banco de produção. Para dados semiestruturados, confirme a inclusão do conjunto completo de arquivos de source e destino.
Dados dependentes indisponíveis	Se a geração de dados for periódica — por tarefa de sincronização recorrente ou tarefa recorrente de mesclagem completa/incremental — a tarefa upstream pode não ter terminado quando a tarefa downstream iniciar. Valide a conclusão bem-sucedida de todas as tarefas dependentes de geração de dados antes de verificar o resultado.

Nota

Para solução geral de problemas de Qualidade de Dados, execute a tarefa várias vezes para observar e comparar os resultados da sincronização. Alterne a source de dados de origem ou de destino para testes comparativos. Múltiplos testes de comparação ajudam a restringir o escopo do problema.