DataWorks:Perguntas frequentes sobre reprocessamento de dados

Como o reprocessamento de dados funciona

Por que o paralelismo falha em nós horários e por minuto

• Sintoma

  Em um nó agendado por hora ou minuto, as instâncias não são executadas em paralelo mesmo quando o paralelismo está ativado para o reprocessamento de dados.

• Causa

  A configuração de paralelismo do reprocessamento de dados determina se as instâncias de um intervalo de data timestamps, em granularidade diária, são executadas simultaneamente. Ela não controla a concorrência de instâncias dentro do mesmo dia para nós horários ou por minuto. A concorrência intradiária desses nós depende da existência de uma autodependência configurada. Para mais informações, consulte Scenario 2: Configure a dependency on the previous cycle.

• Resolução

  • Com o paralelismo desativado, as instâncias para diferentes data timestamps são executadas de forma serial. A instância do próximo data timestamp inicia somente após a conclusão da anterior.

  • Com o paralelismo ativado, defina o número de instâncias simultâneas (por exemplo, 2, 3, 4 ou 5) para executar instâncias de reprocessamento de dados para vários data timestamps em paralelo.

  Cenário de exemplo: suponha que você precise reprocessar uma semana de dados para um nó horário ou por minuto.

  • Se o nó tiver uma autodependência, as instâncias dessa semana são executadas sequencialmente em ordem cronológica.

  • Se o nó não tiver uma autodependência, todas as instâncias de cada dia são executadas em paralelo.

Por que instâncias entram no estado Pending (Schedule)

• Sintoma

  Após especificar um data timestamp para reprocessar dados, a instância não é executada. Ela permanece no estado Pending (Schedule) e aparece destacada em amarelo.

• Causa

  Isso ocorre quando o horário de execução agendado para o data timestamp selecionado está no futuro.

• Resolução

  Para executar essas instâncias imediatamente, selecione a opção Run Retroactive Instances Scheduled to Run after the Current Time na caixa de diálogo Backfill Data.

  Nota

  • Se você selecionar um data timestamp correspondente a um horário de execução futuro e não marcar essa caixa de seleção, a instância entra no estado Pending (Schedule).

  • Se você selecionar um data timestamp correspondente a um horário de execução futuro e marcar essa caixa de seleção, a instância é executada imediatamente.

Por que reprocessamentos recentes ficam em estado pendente?

• Sintoma

  Ao reprocessar dados para o data timestamp de ontem ou de hoje, a instância entra no estado Pending (Schedule).

• Causa

  O agendamento da plataforma segue tipicamente o modelo T+1, ou seja, dados com o data timestamp de ontem são processados por uma execução agendada para hoje. Ao reprocessar dados para um data timestamp específico, você reexecuta a instância de ciclo daquela data.

  Para encontrar a instância de ciclo agendada para hoje, filtre pelo data timestamp de ontem. Na página Cycle Instance em Operation Center > Cycle Task O&M, defina o filtro Data Timestamp como Yesterday para visualizar as instâncias de ciclo correspondentes e seus status.

Por que um reprocessamento cria múltiplas instâncias

• Sintoma

  O reprocessamento de dados para um intervalo de tempo como 00:00 a 01:00 gera múltiplas instâncias.

• Causa

  A quantidade de instâncias geradas depende da configuração de agendamento do nó.

  • Por exemplo, se um nó horário estiver agendado para execução a cada hora das 00:00 às 23:59, o reprocessamento de dados para o intervalo de 00:00 a 01:00 gera duas instâncias com horários de execução agendados às 00:00 e 01:00.

  • De forma semelhante, se um nó estiver agendado para execução a cada 30 minutos, o reprocessamento de dados para o intervalo de 00:00 a 01:00 gera três instâncias com horários de execução agendados às 00:00, 00:30 e 01:00.

Por que reprocessamentos em larga escala ficam pendentes por recursos

• Sintoma

  Durante uma operação de reprocessamento de dados em larga escala, algumas instâncias entram no estado Pending (Resources) e aparecem destacadas em amarelo.

• Causa

  Cada grupo de recursos possui um limite máximo de concorrência para execução de nós. Quando o número de nós em execução simultânea ultrapassa esse limite, novas instâncias ficam na fila no estado Pending (Resources).

  Nota

  Para solucionar esse problema, consulte Waiting for resources.

Por que o erro "run time out of range" ocorre?

• Sintoma

  Durante o reprocessamento de dados, pode ocorrer um erro indicando que o horário de execução do nó acionado está fora do intervalo de tempo selecionado.

• Causa

  Esse erro ocorre porque o horário de execução agendado real do nó está fora do intervalo de tempo especificado. Para nós horários e por minuto, é necessário especificar uma janela de horário de execução para o reprocessamento de dados. Por exemplo, na caixa de diálogo Backfill Data, se você definir Select a run time window como 00:00 ~ 01:00, mas o nó acionado estiver agendado para outro horário, a operação de reprocessamento falha. Para resolver, ajuste a janela de horário de execução para incluir o horário agendado do nó.

Por que nenhuma instância de reprocessamento é gerada?

• Sintoma

  Você iniciou uma operação de reprocessamento de dados para um nó, mas nenhuma instância de reprocessamento foi gerada.

• Causa

  As instâncias não são geradas quando o data timestamp está fora do intervalo de datas efetivas do nó. Certifique-se de que os data timestamps do reprocessamento estejam dentro desse intervalo. No painel de scheduling configuration do nó, é possível ver configurações como estas: Time attribute definido como Normal scheduling, Rerun attribute não selecionado, Auto rerun on error não selecionado, o effective date range de 1999-09-09 a 1999-10-22 (o agendamento vigora apenas dentro desse intervalo), Suspend scheduling não selecionado, o scheduling cycle como Daily e o horário agendado como 00:19. Se o data timestamp do reprocessamento estiver fora do effective date range, nenhuma instância de reprocessamento é gerada.

Reprocessamento de nós semanais e mensais

• Descrição: Ao reprocessar dados para nós semanais ou mensais, defina o data timestamp para o dia anterior ao horário de execução agendado. Um nó agendado para execução em um dia específico da semana ou do mês é executado apenas nesse dia designado. Nos demais dias, instâncias de execução simulada (dry-run) são geradas, mas o nó não é executado de fato. O status dessa instância indica um ciclo de dry-run semanal ou mensal. Para mais informações, consulte Scenario 1: Dry run for weekly/monthly cycle.

  Nota

  • O data timestamp do reprocessamento é calculado como: data timestamp = Scheduled run date - 1 day.

  • Para mais informações sobre a relação entre parâmetros de agendamento, data timestamps, horários agendados e horários reais de execução, consulte Supported formats for scheduling parameters.

• Exemplo: Reprocessar dados para um nó mensal

  Para um nó agendado para execução às 00:00 do primeiro dia de cada mês, defina o data timestamp para o último dia do mês anterior. Para um nó mensal cujo scheduling cycle está definido como Monthly e o horário de execução é 00 00 00 1 * ?, defina as datas de início e término do Data Timestamp na caixa de diálogo Backfill Data como 2022-11-30 para processar os dados de novembro de 2022 e, em seguida, clique em OK.

Como o limite de instâncias paralelas afeta os reprocessamentos

• Quando a configuração maximum parallel instances está ativada para um nó, esse limite se aplica tanto às instâncias de reprocessamento de dados quanto às instâncias regulares de ciclo. Ambas compartilham a mesma cota de concorrência.

• Quando a concorrência de instâncias excede o limite, o sistema limita principalmente as instâncias de reprocessamento de dados históricos — ou seja, instâncias com data timestamps anteriores ao dia atual.

• O limite de instâncias paralelas se aplica somente a instâncias geradas após a ativação da configuração. Instâncias já em execução ou na fila não são afetadas.

• O valor de maximum parallel instances pode variar de 1 a 10.000, com valor padrão de 1.

O que fazer se um reprocessamento paralelo de dados via OpenAPI reportar Can't update ObjectId BeginTs less than lastCommitTs ou "ODPS-0429311 metadata transaction conflict"?

• Causa

  Durante o reprocessamento paralelo de dados, tarefas para diferentes data timestamps são executadas ao mesmo tempo e envolvem operações DDL em tabelas — por exemplo, instruções ALTER TABLE concorrentes, uma colisão entre um merge automático e uma operação DDL manual, ou agendamentos sobrepostos. Isso causa um conflito de transação de metadados do MaxCompute ou um conflito DDL.

• Resolução

  Defina o parâmetro Parallelism da API de reprocessamento de dados como false para que as tarefas sejam executadas de forma serial e não modifiquem metadados simultaneamente. Se o conflito ocorrer apenas ocasionalmente, uma nova tentativa geralmente resolve o problema.

• Informações adicionais

  Após definir Parallelism como false, o fluxo de trabalho de reprocessamento de dados para múltiplos data timestamps é executado em ordem serial estrita: a instância do próximo data timestamp inicia somente após todas as instâncias do data timestamp anterior serem concluídas com sucesso. Se uma tarefa de um data timestamp upstream falhar, as instâncias de reprocessamento dos data timestamps downstream permanecem no estado Not Running (exibido como Creating em versões anteriores da API). Atualmente, não há API disponível para consultar o status geral da tarefa diretamente. Só é possível consultar o status das instâncias por data timestamp.

Como investigar uma tarefa de reprocessamento de dados com execução lenta?

• Verifique a carga do grupo de recursos

  Analise a utilização do grupo de recursos. Se a utilização estiver alta, o grupo está totalmente ocupado e as tarefas entram em fila. Reduza o número de tarefas simultâneas ou escale o grupo de recursos.

• Analise o log de jobs do MaxCompute (Logview)

  Se o grupo de recursos não estiver totalmente ocupado, mas a tarefa ainda estiver lenta, obtenha a URL do Logview e analise a eficiência de execução do SQL. Verifique se há expansão de dados — por exemplo, uma operação JOIN cuja saída é muito maior que a entrada. Utilize as informações de Input para localizar o nó SQL específico e as tabelas envolvidas, como uma tabela de dimensão unida a uma tabela fato em que uma distribuição desigual dos valores da chave de junção causa um product cartesiano. Consulte a documentação oficial do MaxCompute para otimização de SQL.

Como investigar uma divergência entre o resultado do reprocessamento e o resultado da execução local da instrução SQL?

• Verifique a consistência do ambiente

  Confirme se a source de dados conectada ao seu ambiente de produção no DataWorks é exatamente a mesma utilizada localmente. Diferencie o banco de dados de teste do banco de dados de produção.

• Confira o valor da partição

  Confirme se o valor de partição utilizado na tarefa de reprocessamento de dados (por exemplo, ds='20260212') corresponde ao valor de partição utilizado na consulta local. Verifique a lógica de atribuição do campo de partição e o formato do data timestamp na instrução SQL.

• Unifique a configuração de fuso horário

  Adicione SET odps.sql.timezone = <time zone>; (por exemplo, SET odps.sql.timezone = America/Cancun;) no início da consulta local para garantir que os campos de tempo sejam interpretados da mesma forma que na tarefa de reprocessamento de dados. Isso evita diferenças de cálculo em funções como TO_CHAR e DATEADD.

• Reproduza a lógica SQL completa

  Execute localmente a instrução SQL completa obtida no log de execução do DataWorks, incluindo toda a lógica de JOIN e CASE e os parâmetros SET, em vez de apenas contar as linhas na tabela de destino.

• Valide no console

  Execute a mesma instrução SQL diretamente no console do DataWorks para descartar interferências do seu ambiente local.