Os logs de sincronização em lote dividem-se em cinco áreas correspondentes a cada etapa de execução. Utilize esses logs para identificar a etapa atual da tarefa, diagnosticar falhas e monitorar o desempenho da sincronização.
Localizar os logs
Abra a página de detalhes do log em um dos seguintes módulos:
|
Módulo |
Caminho |
|
Operation Center |
Acesse Recurring Instance, Test Instance ou Data Backfill. Filtre a instância desejada e abra sua página de detalhes de log. Para obter instruções, consulte Visualizar instâncias recorrentes. Para trabalhar com backfills e execuções de teste, veja Fazer backfill de dados e visualizar instâncias de backfill (nova versão) e Executar um teste e visualizar instâncias de teste. |
|
DataStudio |
Na página Operation History, visualize os logs de execução dos últimos três dias. |
Ler os logs
A página de log contém cinco áreas distintas. A figura a seguir ilustra a aparência do log durante uma execução típica.
|
Área |
Status |
Significado |
|
Área ① |
SUBMIT |
O sistema de mapeamento CDN encaminhou a tarefa de sincronização para um grupo de recursos visando à execução pelo Data Integration. A renderização da tarefa foi concluída. |
|
Área ② |
WAIT |
A tarefa aguarda a disponibilidade de recursos do Data Integration. |
|
Área ③ |
RUN |
A tarefa está em execução ativa, percorrendo suas etapas. |
|
Área ④ |
FAIL / SUCCESS |
A tarefa finalizou, seja com erro ou com êxito. |
|
Área ⑤ |
(link) |
Link para o log detalhado de cada etapa individual de execução. |
Área ①: SUBMIT — identificar o grupo de recursos
No momento do envio da tarefa, o log indica qual grupo de recursos a está executando:
|
Tipo de grupo de recursos |
Saída no log |
|
Grupo de recursos padrão |
|
|
Grupo de recursos exclusivo para Data Integration |
|
|
Grupo de recursos Serverless |
|
Clique em Detail log url na Área ① para abrir o log detalhado de cada etapa.
Área ②: WAIT — resolver contenção de recursos
O status WAIT indica que não há recursos do Data Integration disponíveis no grupo de recursos. Para resolver essa situação:
Aguarde a conclusão das outras tarefas em execução no grupo de recursos para liberar capacidade e, em seguida, execute novamente sua tarefa. Para identificar quais tarefas estão consumindo recursos, consulte Cenários e soluções para sincronização lenta de dados.
Alinhe-se com os responsáveis por essas tarefas para reduzir a concorrência.
Diminua a concorrência da tarefa de sincronização atual e publique-a novamente.
Escale horizontalmente o grupo de recursos. Consulte Operações de scale-out e scale-in.
Área ③: RUN — quatro etapas de execução
Uma tarefa de sincronização em lote percorre quatro etapas sequenciais:
Etapa 1: Pré-preparação
O sistema envia uma instrução SQL prévia ao banco de dados de origem ou de destino antes do início da leitura. Nem todas as tarefas incluem esta etapa.
Se houver um MySQL Writer com uma instrução PreSQL configurada, essa instrução será executada no banco de dados neste momento.
Para um MySQL Reader com uma instrução
querySqlou cláusulawheredefinida, essas instruções são executadas aqui.Por exemplo, ao gravar no MaxCompute com a opção Delete Existing Data Before Writing ativada, a exclusão ocorre nesta fase.
Utilize campos indexados nas condições de filtro. Instruções SQL lentas nesta etapa aumentam o tempo total de sincronização e podem causar timeout na tarefa.
Etapa 2: Divisão da tarefa
Os dados de origem são divididos em subtarefas para permitir a leitura em lotes concorrentes. As regras de divisão variam conforme o tipo de origem:
|
Tipo de origem |
Regra de divisão |
|
Banco de dados relacional |
Divisão por |
|
LogHub, DataHub ou MongoDB |
Divisão baseada no número de shards. A concorrência máxima não pode exceder a quantidade de shards. |
|
Armazenamento semiestruturado (ex.: OSS) |
Divisão por quantidade de arquivos ou volume de dados. No caso do OSS, a concorrência máxima é limitada pelo número de arquivos. |
Etapa 3: Sincronização de dados
As subtarefas são sincronizadas simultaneamente conforme a configuração de concorrência definida. Em bancos de dados relacionais, o DataWorks gera múltiplas instruções SQL a partir da chave de shard e lê os dados em paralelo. Para mais detalhes, consulte Relação entre concorrência de sincronização em lote e limitação de taxa.
A concorrência real durante a execução pode diferir do valor configurado. Uma configuração incorreta da chave de shard pode gerar instruções SQL demoradas no banco de dados, tornando a sincronização lenta ou causando falhas. Cargas elevadas no banco de dados também reduzem o desempenho da sincronização.
Etapa 4: Pós-preparação
Após a conclusão da sincronização dos dados, o sistema envia uma instrução SQL posterior ao banco de dados. Nem todas as tarefas incluem esta etapa.
Caso exista um MySQL Writer com instrução PostSQL configurada, ela será executada neste ponto. O tempo de execução conta para a duração total da tarefa.
Área ④: FAIL / SUCCESS — interpretar o resultado
Em caso de falha na tarefa (FAIL):
O log registra uma mensagem de erro principal. Clique em no link da Área ⑤ para acessar o log de execução detalhado de cada etapa e identificar onde ocorreu a ruptura.
Em caso de êxito na tarefa (SUCCESS):
O log apresenta um resumo dos resultados, incluindo o total de registros sincronizados e a velocidade média de sincronização.
Dados sujos:
Se a tarefa encontrar dados sujos, o log registrará Dirty data: xxR. Dados sujos não são gravados no destino. Um grande volume de dados sujos torna a sincronização mais lenta. Caso tenha requisitos de velocidade de sincronização, resolva primeiro o problema dos dados sujos.
Por padrão, tarefas de sincronização em lote toleram dados sujos. Para controlar esse comportamento, configure a contagem de tolerância a dados sujos nas configurações da tarefa. Consulte Configurar uma tarefa na interface sem código ou Configurar uma tarefa no editor de código para detalhes sobre a configuração. Para saber mais sobre dados sujos, veja Recursos da configuração de tarefas de sincronização em lote.
Configurar a chave de shard para bancos de dados relacionais
O parâmetro splitPk controla como o DataWorks divide os dados de bancos relacionais em subtarefas. Configure-o corretamente para evitar consultas lentas e hot spots de dados.
Melhor prática: Defina splitPk como a chave primária da tabela. Chaves primárias geralmente possuem distribuição uniforme, o que previne hot spots nos shards resultantes.
Restrições:
O parâmetro
splitPkaceita apenas tipos de dados inteiros. Strings, números de ponto flutuante, datas e outros tipos não são suportados. Se você configurarsplitPkcom um tipo incompatível, o DataWorks ignorará a definição e utilizará um único canal.Quando
splitPknão for especificado ou estiver em branco, a sincronização da tabela ocorrerá por meio de um único canal.