DataWorks:Sincronização em tempo real de tabela única: O&M e ajuste

Iniciar e parar

• Após iniciar uma tarefa, verifique primeiro se a preparação do esquema foi concluída, observe se a inicialização completa começou e está progredindo e, por fim, confirme se a sincronização incremental em tempo real está lendo e gravando dados continuamente. Para tarefas com source de mensagens, monitore também o offset do consumidor e o acúmulo de mensagens. Em tarefas baseadas em logs de banco de dados, monitore o Binlog, WAL ou o tempo de retenção de logs.

• Antes de parar uma tarefa, confirme se o período de retenção de logs ou mensagens da source cobre a janela de inatividade. Se o tempo de inatividade exceder o período de retenção, a tarefa poderá não conseguir retomar a partir do offset original. Nesses casos, geralmente é necessário redefinir o offset, ignorar o backlog histórico ou reinicializar. Antes de realizar essas operações, avalie os riscos de gravações duplicadas e perda de dados.

Modificar configurações

As modificações comuns para tarefas de tempo real de tabela única incluem ajustes em mapeamentos de colunas, chaves primárias, modos de gravação, regras de partição, concorrência, recursos, offsets e políticas de tratamento de dados sujos.

Configuração de alertas

Para tarefas de tempo real de tabela única, recomendamos monitorar pelo menos o status da tarefa, a latência de negócios e o Failover. Dependendo das capacidades do canal e da configuração da tarefa, adicione também alertas para utilização de recursos, erros de gravação, notificações de DDL e acúmulo de mensagens.

Em tarefas com source de mensagens, monitore também o backlog do tópico de source, shard, Logstore ou grupo de consumidores. Para tarefas baseadas em logs de banco de dados, monitore Binlog, WAL, log de arquivamento ou retenção de slot de replicação. Configurar apenas alertas de falha na tarefa não detecta problemas em que a tarefa ainda está em execução, mas a latência aumenta continuamente, as gravações ficam lentas ou os offsets não avançam por um longo período.

A tarefa não produz saída de dados

Quando a tarefa aparece como em execução, mas nenhum novo dado surge no destino, confirme primeiro se a source realmente tem novos dados e determine se o problema é que o leitor não está consumindo dados, o pipeline está enfrentando erros de processamento ou o gravador não está confirmando os dados.

Sequência de solução de problemas:

1. Verifique se a tabela de source, tópico, Logstore ou offset de log possui novos dados.

2. Confira se a tarefa está na fase de inicialização completa, sincronização incremental em tempo real ou estado de Failover.

3. Analise se as métricas de leitura, métricas de gravação, latência de negócios e Checkpoint estão progredindo normalmente.

4. Valide se a tabela de destino, partição de destino, chave primária e modo de gravação correspondem à configuração.

5. Investigue se existem dados sujos, falhas no mapeamento de colunas ou problemas de permissão no destino.

Se as estatísticas de DML/DDL nos detalhes de execução não mostrarem dados por um curto período, mas os logs e as gravações no destino estiverem normais, verifique também se há latência na coleta de métricas ou anomalias de coleta para evitar interpretar erroneamente um problema de exibição de monitoramento como uma interrupção na sincronização.

Inicialização completa lenta ou com falha

Quando a inicialização completa estiver lenta, identifique primeiro se o gargalo está nas leituras da source, na rede, no grupo de recursos, nas gravações do destino ou na divisão desigual de dados.

Durante a fase de inicialização completa, não confie apenas no throughput médio. Alguns shards grandes, tabelas largas, colunas grandes ou partições quentes podem determinar o tempo total de conclusão.

Aumento da latência em tempo real

Quando a latência em tempo real aumentar, verifique primeiro se ela está diminuindo continuamente. Se a tarefa acabou de concluir a inicialização completa, o pipeline em tempo real pode estar reproduzindo dados incrementais acumulados durante a fase de sincronização completa. Caso a latência continue crescendo, identifique se o gargalo está no leitor, no gravador, nos recursos, na rede ou em um sistema externo.

Recomendamos seguir esta ordem para solucionar o problema:

1. Verifique o tempo de espera da janela nos detalhes de execução da tarefa para determinar se o gargalo está principalmente no leitor ou no gravador.

2. Examine os logs da tarefa durante o período de alta latência e pesquise palavras-chave como Error, Exception e OutOfMemory.

3. Consulte os registros de Failover para determinar se ocorreram Failovers frequentes, erros OOM ou exceções de serviço externo.

4. Analise as métricas e eventos de execução, focando em throughput, contrapressão, Checkpoint, memória JVM, GC, eventos DDL e dados sujos.

5. Em seguida, continue identificando a causa examinando a source, o destino, os recursos, a concorrência e a rede. Não recomendamos aumentar a concorrência ou os recursos antes de identificar o gargalo.

O tempo de espera da janela pode ser usado como indicador de primeiro nível:

Após identificar a localização do gargalo, investigue mais detalhadamente com base no sintoma específico:

• Para origens de mensagens como Kafka, DataHub e LogHub, preste muita atenção ao número de partições ou shards. Normalmente, uma única partição ou shard só pode ser consumida por um único thread concorrente. Quando os dados estão concentrados em poucas partições, simplesmente aumentar a concorrência total pode não ajudar. Verifique os bytes acumulados de diferentes threads do Reader combinados com o monitoramento da source para determinar se existem hotspots de partição ou shard.

• Para origens baseadas em logs de banco de dados, como MySQL, preste muita atenção a transações grandes, alto volume de DML, DDL frequente e taxa de crescimento do Binlog. Se a velocidade de sincronização não for alta, mas a latência continuar aumentando, verifique os logs de auditoria do banco de dados de source, cpu, I/O, conexões e crescimento do Binlog para determinar se a source está sob pressão ou se bancos de dados e tabelas não sincronizados estão gerando um grande volume de entradas de Binlog.

• Ao gravar no MaxCompute, se o log mostrar uploader map size has reached uploaderMapMaximumSize, isso geralmente indica que o número de valores de partição dinâmica dentro de um único intervalo de Flush é muito grande. Priorize o ajuste da granularidade da partição ou das colunas de partição dinâmica para evitar o uso de colunas de alta cardinalidade, como timestamps de nível de segundo, IDs de pedido ou IDs de usuário como valores de partição. Em seguida, avalie se é necessário aumentar a concorrência ou os recursos.

Erros no processamento de eventos DDL

Quando uma tarefa falha, a latência aumenta ou o esquema do destino fica inconsistente após um evento DDL, verifique primeiro se o canal atual suporta o tipo de DDL e qual é a política de tratamento de DDL da tarefa.

Foco da solução de problemas:

• Identifique quais operações DDL ocorreram na source, como adicionar colunas, remover colunas, alterar tipos, renomear, criar tabelas, excluir tabelas ou modificar índices.

• Verifique se o destino suporta o mesmo DDL ou uma alteração de esquema equivalente.

• Confira se a política da tarefa está definida para processar normalmente, ignorar, alertar ou parar.

• Valide se a conta de destino tem permissões ALTER TABLE.

• Assegure-se de que mapeamentos de colunas, chaves primárias e partições permaneçam consistentes antes e depois do DDL.

Não recomendamos ignorar diretamente operações DDL não suportadas. Ignorar um DDL pode permitir que a tarefa continue executando, mas gravações DML subsequentes podem continuar falhando devido a incompatibilidades de colunas, alterações de chave primária ou inconsistências no esquema do destino.

Update ou Delete não produzindo os resultados esperados

Quando os dados no destino não corresponderem às expectativas após operações de Update ou Delete, verifique primeiro se o destino possui uma chave primária ou chave única capaz de localizar registros e se os mapeamentos de chave primária entre source e destino são consistentes.

As causas comuns incluem:

• O destino não possui chave primária ou chave única, impossibilitando a atualização ou exclusão por registro.

• A chave primária da source e a chave primária do destino são inconsistentes.

• Colunas de chave primária foram transformadas, renomeadas ou gravadas como nulas.

• O modo de gravação do destino não suporta atualizações ou exclusões.

• A tarefa está configurada para ignorar operações Delete ou usa uma política de gravação especial.

• Falhas de gravação são registradas como dados sujos, mas a tarefa continua executando.

Para solucionar o problema, use primeiro um pequeno conjunto de registros de amostra para verificar os eventos de source, os mapeamentos da tarefa e os resultados no destino, e então decida se deve ajustar chaves primárias, modos de gravação ou reinicializar a tabela de destino.

Aumento de dados sujos

Quando os dados sujos aumentarem, não recomendamos elevar diretamente o limiar de dados sujos. Determine primeiro se os dados sujos causam dados ausentes, colunas nulas, truncamento de colunas, conflitos de chave primária ou anomalias de partição no destino.

Foco da solução de problemas:

• Verifique se os tipos de coluna, comprimentos, precisões e restrições NOT NULL correspondem.

• Confira se as chaves primárias, chaves únicas ou colunas de partição do destino atendem aos requisitos.

• Investigue se a source introduziu strings excessivamente longas, codificações inválidas, JSON especial, timestamps não analisáveis ou tipos de dados não suportados.

• Analise se o destino apresenta limitação, falhas de gravação ou filtragem no lado do servidor.

Considere aumentar temporariamente o limiar de dados sujos apenas quando tiver confirmado que o negócio aceita o descarte desses registros anormais. Em seguida, corrija os dados de source ou o esquema do destino.