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

Iniciar e parar

• Ao iniciar uma tarefa, verifique primeiro se a preparação do esquema foi concluída. Em seguida, observe se a inicialização completa começou e está progredindo. 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, acompanhe 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 em tarefas de tabela única em tempo real 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 dirty data.

Configuração de alertas

Para tarefas de tabela única em tempo real, monitore 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, acompanhe a retenção de Binlog, WAL, log de arquivamento ou 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 dado novo surge no destino, confirme se a source realmente possui novos dados. Em seguida, determine se o leitor não está consumindo dados, se o pipeline enfrenta erros de processamento ou se 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 dirty data, 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 na coleta. Isso evita interpretar erroneamente um problema de exibição de monitoramento como uma interrupção da 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 extensas 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 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.

Solucione problemas na seguinte ordem:

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 service externo.

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

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

Use o tempo de espera da janela como indicador de primeiro nível:

Após identificar a localização do gargalo, prossiga com a solução de problemas com base no sintoma específico:

• Para sources 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 pode ser consumida por apenas uma 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 sources baseadas em logs de banco de dados, como MySQL, preste muita atenção a transações grandes, DML de alto volume, 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. Determine assim 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 torna-se 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 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. Confirme também 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 especial de gravação.

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

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

Aumento de dirty data

Quando a dirty data aumentar, não aumente diretamente o limiar de dirty data. Determine primeiro se a dirty data causa 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 tipos de coluna, comprimentos, precisões e restrições NOT NULL correspondem.

• Confira se 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 dirty data apenas quando tiver confirmado que o negócio aceita descartar esses registros anômalos. Em seguida, corrija os dados da source ou o esquema do destino.