A computação progressiva combina processamento de fluxo e em lote para tratar apenas dados incrementais entre execuções. Em vez de reprocessar todo um intervalo de tempo a cada execução, o recurso captura novos dados, calcula resultados para a nova partição e os mescla com resultados intermediários armazenados de execuções anteriores.
Como funciona
No processamento em lote tradicional, uma consulta de janela deslizante — como calcular o total de vendas semanais de um produto — reprocessa todos os dados da janela a cada execução. A partir do dia n+1 (n>=7), o sistema recalcula redundamente os dados do dia n-5 ao dia n.
A computação progressiva elimina essa redundância. Na primeira execução, o sistema calcula os resultados para cada dia na janela e os armazena como resultados intermediários. Nas execuções subsequentes, apenas os dados do novo dia são computados e mesclados com os resultados armazenados. Essa abordagem reduz a carga computacional em 70% em cada execução após a primeira.
Compensações
Maior duração na primeira execução. O cálculo inicial gera resultados intermediários para cada dia no intervalo, o que pode levar mais tempo que o processamento em lote padrão. Execute o job inicial manualmente com antecedência para garantir que os resultados estejam prontos quando o agendamento do período base começar.
Armazenamento adicional para resultados intermediários. O sistema mantém os resultados intermediários até que deixem de ser utilizados. A eliminação de cálculos redundantes compensa o custo de armazenamento, tornando a computação progressiva mais econômica no geral.
Quando usar a computação progressiva
Use a computação progressiva quando os jobs do MaxCompute atenderem às seguintes condições:
A consulta opera em uma janela de tempo deslizante ou janela de acumulação (por exemplo, últimos 7 dias, últimas 3 horas, acumulado do mês).
O mesmo intervalo de tempo é reprocessado em cada execução agendada, gerando computação redundante.
Há necessidade de reduzir a latência da consulta ou o consumo de recursos sem alterar a lógica subjacente.
A computação progressiva não é necessária para consultas únicas ou jobs em que todo o conjunto de dados muda entre execuções.
Referência de configuração
A tabela a seguir lista todos os parâmetros de computação progressiva.
|
Parâmetro |
Descrição |
Valores válidos |
Padrão |
Obrigatório |
|
|
Ative ou desative a computação progressiva. |
|
|
Sim |
|
|
Modo de computação (estratégia de janela). |
Consulte Modos de computação. |
Nenhum |
Sim |
|
|
Nomes das colunas de partição de tempo para granularidade mais fina. |
Consulte Colunas de partição de tempo. |
Nenhum |
Não (apenas para |
|
|
Armazena tabelas intermediárias como cluster tables para melhorar o desempenho do shuffle. |
|
|
Não |
|
|
Número máximo de instâncias simultâneas durante a primeira execução. |
Inteiro >= 1 |
|
Não |
Modos de computação
Defina odps.progressive.range.query.input.partition.pattern com um dos valores a seguir.
|
Modo |
Tipo de janela |
Caso de uso |
|
|
Janela deslizante no nível de hora ou minuto |
Consultar dados dos últimos 5 minutos ou das últimas 3 horas |
|
|
Janela deslizante de vários dias com partições horárias |
Consultar dados das últimas 3 horas ou dias, em que a janela mais recente armazena dados em partições diferentes por hora |
|
|
Janela deslizante de vários dias |
Consultar dados dos últimos 3 dias |
|
|
Janela de acumulação de vários dias com partições diárias |
Consultar dados dos últimos 50 dias ou dos últimos 3 anos, em que a janela mais recente armazena dados em partições diferentes por dia |
|
|
Janela de acumulação mensal |
Consultar dados acumulados do primeiro dia do mês atual até o dia atual |
|
|
Janela de acumulação anual |
Consultar dados acumulados do primeiro dia do ano atual até o dia atual |
Colunas de partição de tempo
Ao usar PASS_BY_HOUR, especifique colunas de tempo com granularidade mais fina via odps.progressive.range.query.time.partition.col.names utilizando um dos formatos abaixo.
Opção 1: Aplicar a todas as tabelas
set odps.progressive.range.query.time.partition.col.names=default:<col_name_day>:<col_name_hour>:<col_name_minute>|<col_name_day>:<col_name_hour>:<col_name_minute>|...;
Opção 2: Aplicar a tabelas específicas
set odps.progressive.range.query.time.partition.col.names=<table_name>:<col_name_day>:<col_name_hour>:<col_name_minute>|<col_name_day>:<col_name_hour>:<col_name_minute>|...;
Opção 3: Combinar regras padrão e específicas por tabela
set odps.progressive.range.query.time.partition.col.names=default:<col_name_day>:<col_name_hour>:<col_name_minute>,<table_name>:<col_name_day>:<col_name_hour>:<col_name_minute>,...;
Parâmetros:
|
Parâmetro |
Descrição |
|
|
|
Palavra-chave. Aplica a especificação de coluna a todas as tabelas que atendem às condições definidas. |
|
|
|
Nome de uma tabela específica. Separe várias tabelas com vírgulas. |
|
|
|
Especificação da coluna de tempo. Use o caractere pipe ( |
`) para definir múltiplos conjuntos de colunas para uma única tabela. |
Exemplo 1: Executar computação progressiva a cada hora:
set odps.progressive.range.query.input.partition.pattern=PASS_BY_HOUR:1;
Exemplo 2: Especifique colunas de tempo com granularidade mais fina:
set odps.progressive.range.query.time.partition.col.names=default:ds:hh|dt:hour;
Exemplo 3: Aplicar colunas de tempo a duas tabelas específicas:
set odps.progressive.range.query.time.partition.col.names=table_1:day:hour,table_2:hour:minute;
Ajustar a computação progressiva
Armazenar tabelas intermediárias como cluster tables
Durante a computação progressiva, os dados nas tabelas intermediárias passam por shuffle antes do cálculo. Armazenar essas tabelas como cluster tables melhora o desempenho da computação.
set range.query.force.cluster.table=true;
Defina este parâmetro como true para obter o melhor desempenho. Quando definido como false (padrão), o sistema selecione automaticamente um método de armazenamento com base na presença de uma operação de shuffle.
Limitar instâncias simultâneas na primeira execução
A primeira execução processa todos os dados dentro do intervalo de tempo especificado, o que consome muitos recursos. Limite o número de instâncias simultâneas para evitar consumo excessivo.
set odps.progressive.combine.exec.time.limit.num=<number>;
<number> representa o número máximo de instâncias simultâneas. Valor padrão: 15. Valor mínimo: 1. Defina esse valor com base no desempenho real do job, pois um valor inadequado afeta a eficiência da execução.
Exemplo
Este exemplo utiliza uma janela deslizante de vários dias (PASS_BY_DAY) para consultar dados de uma janela de 7 dias.
Primeira execução
A primeira execução processa a janela [20200801, 20200807]. O sistema computa todos os sete dias e salva os resultados em sete tabelas intermediárias — uma por dia.
set odps.progressive.enable=true;
set odps.progressive.range.query.input.partition.pattern=PASS_BY_DAY;
CREATE TABLE adl_aegis_webshell_test_neoke AS
SELECT
request_datetime,host,uri,src_ip,src_port,dst_ip,dst_port,method,post_data,user_agent,ret_code,cookie,
referer,x_forward_for,rsp_content_type,rqs_content_type,content_length,jump_location,set_cookie,ttl,
get_bigwebshell_uri(uri) AS nopar_uri,internet_ip
FROM secbase.adl_aegis_webshell_newadd_beaverlog
WHERE ds >= TO_CHAR(DATEADD(TO_DATE('20200807','yyyymmdd'),-6,'dd') ,'yyyymmdd')
AND ds <= '20200807';
Segunda execução
No dia seguinte, a janela muda para [20200802, 20200808]. O sistema computa separadamente apenas os dados referentes a 20200808 e depois os combina com os resultados nas sete tabelas intermediárias para produzir o resultado final.
Melhores práticas
Teste primeiro no ambiente de desenvolvimento
Antes de ativar a computação progressiva em produção, teste o desempenho no ambiente de desenvolvimento. Verifique se a consulta produz resultados corretos e se a melhoria de desempenho atende às expectativas.
Execute a primeira execução com antecedência
A primeira execução computa resultados intermediários para cada partição no intervalo de tempo, consumindo mais recursos que as execuções subsequentes. Agende a primeira execução durante um período de baixo tráfego ou acione-a manualmente antes que o agendamento de produção comece.
Armazene tabelas intermediárias como cluster tables
Configure range.query.force.cluster.table=true para armazenar tabelas intermediárias como cluster tables. Essa configuração melhora o desempenho do shuffle e reduz o tempo de computação nas execuções subsequentes.