Este tópico explica como configurar os parâmetros de Channel Control em tarefas de sincronização em lote para minimizar erros de configuração e chamados de suporte. O conteúdo descreve a relação entre concorrência e limitação de velocidade na sincronização em lote.
Conceitos principais e melhores práticas
Concorrência
Esta seção responde às seguintes perguntas:
Pergunta 1: Como configuro a concorrência para uma tarefa de sincronização de dados?
Pergunta 2: Por que minha tarefa de sincronização de dados está lenta e com concorrência real insuficiente?
Pergunta 3: Por que minha tarefa de sincronização continua lenta mesmo com alta concorrência configurada, e por que meu grupo de recursos exclusivo frequentemente fica aguardando recursos?
Concorrência refere-se ao número máximo de threads que leem dados de uma origem e gravam em um destino paralelamente em uma tarefa de sincronização de dados. Para melhorar a eficiência da sincronização, ajuste a concorrência da tarefa e reduza o tempo de migração de dados. Defina essa configuração na seção Channel Control da página de configuração da tarefa de sincronização de dados, usando a lista suspensa Desired Maximum Task Parallelism. O valor definido corresponde à concorrência configurada para a tarefa. Em origens baseadas em arquivos (OSS, FTP, HDFS e S3), a leitura dos dados ocorre simultaneamente por arquivo. A concorrência real será limitada se a quantidade de arquivos a serem lidos for menor que a concorrência configurada. O valor configurado representa a concorrência máxima desejada para a tarefa. No entanto, devido a fatores como limites do grupo de recursos do Data Integration ou características da própria tarefa, a concorrência real durante a execução pode ser menor ou igual ao valor configurado. Em cenários de faturamento (como ao usar um grupo de recursos de depuração do Data Integration), a cobrança baseia-se na concorrência real da tarefa. O Data Integration tenta garantir que a concorrência de execução corresponda à concorrência configurada. Os cenários comuns em que a concorrência real de execução é menor que a configurada incluem:
Ao ler de um banco de dados relacional como MySQL, PolarDB, SQL Server, PostgreSQL ou Oracle, a tarefa não consegue dividir e ler os dados da tabela em paralelo sem uma chave de divisão (splitPk) válida e configurada. A chave de divisão deve ser do tipo inteiro. Para Oracle, além de tipos inteiros, colunas do tipo data/hora também são suportadas.
No PolarDB-X (DRDS), os dados são divididos em fatias para leitura com base na topologia física das tabelas lógicas. A concorrência real é limitada pelo número de shards da tabela física caso este seja menor que a concorrência configurada.
Em origens baseadas em arquivos (OSS, FTP, HDFS e S3), a leitura dos dados ocorre simultaneamente por arquivo. A concorrência real é limitada pela quantidade de arquivos a serem lidos se esta for menor que a concorrência configurada.
Se a distribuição dos dados na origem for muito desigual, algumas fatias de dados podem levar mais tempo para processar. Nas etapas finais da execução da tarefa, após a conclusão das outras fatias, a concorrência real diminuirá para abaixo do valor configurado.
Melhores práticas para configurar a concorrência:
Quanto maior a concorrência, mais recursos a tarefa precisará obter. O Data Integration aloca recursos com base no princípio FIFO (first-in, first-out), ou seja, as tarefas enviadas primeiro recebem recursos antes. Configure uma concorrência adequada para evitar que tarefas longas e de alta concorrência bloqueiem a aquisição de recursos por tarefas subsequentes.
Para tabelas com pequenos volumes de dados, configure uma baixa concorrência. Isso exige menos recursos, permitindo que a tarefa obtenha rapidamente recursos fragmentados e inicie a execução. Como o volume de dados é pequeno, o tempo de execução mantém-se dentro de uma faixa razoável.
Para tarefas de sincronização na mesma origem de dados, intercale os horários de execução. Essa prática ajuda a equilibrar a utilização de recursos do grupo de recursos e reduz a pressão de acesso simultâneo sobre a origem de dados.
Velocidade de sincronização
Esta seção responde às seguintes perguntas:
Pergunta 1: Como configuro a velocidade de sincronização de dados? Como entender a limitação e a não limitação de velocidade?
Pergunta 2: Por que a limitação de velocidade às vezes não surte efeito na sincronização de dados?
Pergunta 3: Por que a velocidade real de sincronização de dados às vezes é significativamente menor que o limiar de limitação?
Velocidade de sincronização: A velocidade de sincronização de dados e a concorrência máxima desejada da tarefa são parâmetros intimamente relacionados. Juntos, eles protegem a origem e o destino contra pressão excessiva de leitura/gravação, evitando que as tarefas de sincronização causem carga significativa na origem de dados e afetem sua estabilidade.
Velocidade de sincronização (sem limitação) significa que a tarefa executa com a concorrência máxima desejada configurada (supondo que a concorrência real de execução seja ActualConcurrent), e cada fatia concorrente roda sem limites de velocidade (supondo que a velocidade real de cada fatia seja Speed). A velocidade real geral da tarefa é ActualConcurrent × Speed. No modo sem limitação, o Data Integration oferece o máximo de desempenho de transferência possível sob a configuração atual da tarefa (concorrência e memória) e o ambiente de hardware (especificações da origem de dados e rede). Para usar esse modo, selecione Non-throttling em Synchronization Speed na seção Channel Control.
Velocidade de sincronização (com limitação) significa que a tarefa executa com um limite de velocidade geral e a concorrência máxima configurada. Quando o Data Integration cria o plano de execução, calcula a velocidade de cada fatia concorrente como (velocidade do trabalho / concorrência do trabalho, arredondado para cima). A velocidade mínima por fatia é de 1 MB/s. Portanto, o limite superior da velocidade real da tarefa é a concorrência real × o limite de velocidade real por fatia. Para usar esse modo, selecione Throttling e insira um valor de velocidade (em MB/s) no campo à direita. Os exemplos comuns a seguir ilustram cenários de limitação:
-
Se você configurar uma concorrência de 5 e um limite de velocidade de 5 MB/s, a tarefa tentará se dividir em 5 fatias para execução simultânea, com cada fatia limitada a 1 MB/s.
Se a concorrência real for 5, a velocidade geral máxima será de 5 MB/s, valor menor ou igual ao limite de velocidade da tarefa.
A concorrência real de execução depende das características específicas da origem de dados. A concorrência real pode ser menor que os 5 configurados (consulte a seção sobre concorrência máxima desejada da tarefa). Se a concorrência real de execução for 1, a velocidade geral máxima será de 1 MB/s, valor menor ou igual ao limite de velocidade da tarefa.
-
Se você configurar uma concorrência de 5 e um limite de velocidade de 3 MB/s, a tarefa tentará se dividir em 5 fatias para execução simultânea, com a velocidade de cada fatia calculada como 3 / 5, arredondado para cima resultando em 1 MB/s.
Se a concorrência real de execução for 5, a velocidade geral máxima será de 5 MB/s, o que excede o limite de velocidade da tarefa.
Se a concorrência real de execução for 1, a velocidade geral máxima será de 1 MB/s, valor menor ou igual ao limite de velocidade da tarefa.
-
Se você configurar uma concorrência de 5 e um limite de velocidade de 10 MB/s, a tarefa tentará se dividir em 5 fatias para execução simultânea, com a velocidade de cada fatia calculada como 10 / 5 = 2 MB/s.
Se a concorrência real de execução for 5, a velocidade geral máxima será de 10 MB/s, valor menor ou igual ao limite de velocidade da tarefa.
Se a concorrência real de execução for 1, a velocidade geral máxima será de 2 MB/s, valor menor ou igual ao limite de velocidade da tarefa.
Processamento distribuído
Esta seção responde às seguintes perguntas:
Pergunta 1: Em quais cenários preciso configurar o modo distribuído para trabalhos de sincronização?
Pergunta 2: Por que o trabalho de sincronização continua lento mesmo executando no modo distribuído?
Sem o modo distribuído, a concorrência configurada executa apenas em uma única máquina como paralelismo no nível de processo, sem aproveitar a computação multimáquina. O modo de execução distribuída distribui as fatias da tarefa entre vários nós de execução para processamento simultâneo. Isso permite que a velocidade de sincronização escale horizontalmente conforme o tamanho do cluster, superando gargalos de máquina única. Se você tiver altos requisitos de desempenho de sincronização, use o modo distribuído. Além disso, o modo distribuído pode utilizar recursos fragmentados entre máquinas, o que melhora a utilização de recursos.
Limites e melhores práticas:
No modo de execução distribuída, configurar uma alta concorrência pode criar uma pressão de acesso significativa no armazenamento de dados. Avalie a carga de acesso do armazenamento de dados antes de usar este modo.
Caso seu grupo de recursos exclusivo tenha apenas uma máquina, evite o modo de execução distribuída. Os processos de execução ainda serão distribuídos em um único nó de trabalho, o que não maximiza os benefícios do processamento distribuído multimáquina.
Para tarefas de sincronização com pequenos volumes de dados, evite o modo distribuído. Em vez disso, configure uma tarefa de máquina única com baixa concorrência.
Ative o modo distribuído somente quando a concorrência for 8 ou superior.
Limites de dados sujos
Esta seção responde às seguintes perguntas:
Pergunta 1: O que são dados sujos na sincronização de dados?
Pergunta 2: Como configuro limites de dados sujos para tarefas de sincronização de dados?
Pergunta 3: Qual é a relação entre a velocidade de sincronização de dados e dados sujos?
Os limites de dados sujos controlam o comportamento de uma tarefa ao encontrar dados sujos. Dados sujos referem-se a registros de dados que encontram uma exceção durante o processo de gravação na origem de dados de destino. Devido à complexidade e às diferenças no processamento de dados entre sistemas heterogêneos, a política atual classifica todos os dados que falham na gravação como dados sujos. Em alguns cenários de sincronização de dados, dados sujos podem degradar a eficiência da sincronização. Por exemplo, ao gravar em um banco de dados relacional, o modo padrão é a gravação em lote. Ao encontrar dados sujos, o processo reverte para o modo de gravação de registro único (para identificar qual registro no lote está sujo e garantir que os registros normais sejam gravados com sucesso). No entanto, a gravação de registro único é muito mais lenta que a gravação em lote. Portanto, encontrar uma grande quantidade de dados sujos pode desacelerar significativamente o desempenho geral da tarefa.
Atualmente, a maioria dos canais do Data Integration suporta limites de limiar para dados sujos. Para canais que suportam esse recurso, os cenários comuns de configuração são descritos a seguir:
Nenhum limite de dados sujos configurado: Todos os dados sujos são tolerados, dados sujos não causam falha na tarefa e o campo errorLimit na configuração da tarefa permanece vazio.
Limite de dados sujos definido como 0: Nenhum dado sujo é tolerado. A tarefa falha ao encontrar mais de 1 registro de dado sujo.
Limite de dados sujos definido como um número inteiro positivo N: Um máximo de N registros de dados sujos é tolerado. A tarefa falha quando o número de registros de dados sujos excede N. Insira o limiar de dados sujos no campo Error Count Exceeds na seção Channel Control. Deixe este campo vazio para indicar que não há limite.
Melhores práticas:
Em cenários sensíveis à qualidade dos dados, como bancos de dados relacionais (MySQL, SQL Server, PostgreSQL, Oracle, PolarDB e PolarDB-X), Hologres, ClickHouse e AnalyticDB for MySQL, defina o limite de dados sujos como 0 para identificar riscos de qualidade de dados oportunamente.
Para cenários não sensíveis à qualidade dos dados, não configure um limite de dados sujos ou configure um limiar razoável com base nos seus requisitos de negócio. Isso ajuda a reduzir a carga operacional de lidar com dados sujos diariamente.
Configure alertas de falha e latência de tarefa para tarefas críticas e detecte problemas em tempo hábil.
Para tarefas reexecutáveis, configure a reexecução automática em caso de falha e reduza o impacto de problemas ambientais ocasionais.
Limites de cota de conexão da origem de dados
Esta seção responde às seguintes perguntas:
Pergunta 1: O que é o limite de cota de conexão da origem de dados e como configuro um limite de conexão razoável?
Pergunta 2: Por que as tarefas de sincronização completa em lote na solução de sincronização de dados estão lentas e permanecem no estado Submit por muito tempo?
O recurso de limite de conexão da origem de dados refere-se a:
Concorrência de gravação no destino: Número máximo de threads que gravam dados no destino em uma tarefa de sincronização em tempo real. Configure este valor com base no tamanho do grupo de recursos e na escala real do destino. O limite superior configurável é 32, e o valor padrão é 3.
Máximo de conexões de leitura na origem: Durante a fase de inicialização completa de dados em lote de uma solução de sincronização de dados, conexões JDBC são estabelecidas com o banco de dados para ler todos os dados históricos. Esta configuração controla o número máximo de conexões JDBC com a origem, evitando que um grande número de tarefas inicie simultaneamente e esgote o pool de conexões do banco de dados, o que poderia afetar a estabilidade do banco. Configure este valor com base na capacidade real dos recursos do seu banco de dados. O valor padrão é 15. Se você notar que as tarefas permanecem no estado Submit por muito tempo, isso geralmente é causado pelo limite máximo de conexão da origem de dados (tente intercalar a execução das tarefas ou aumentar o limite máximo de conexões).
Configure os limites de cota de conexão da origem de dados na solução de sincronização de dados da seguinte forma: Na etapa Runtime Resource Settings, defina Destination Write Concurrency na seção de sincronização em tempo real (padrão: 3, limite superior configurável: 32). Na seção 6.2 Batch Full Synchronization, defina Maximum Source Read Connections (padrão: 15) para controlar o número de conexões JDBC com o banco de dados durante a fase de inicialização completa de dados.