Documentação HorusBI
Buscar K

Aparência

Abrir no Claude Abrir no ChatGPT

Consumo de Processamento ​

O GB cobrado no mês soma duas parcelas contra a mesma franquia: o tamanho do arquivo Parquet que cada execução envia ao Data Warehouse, e a média de storage ocupado ao longo do mês. A parcela de inserção não é o volume lido na origem nem contagem de linha: é o arquivo comprimido que o fluxo grava. A parcela de storage é o tamanho que as tabelas carregam consigo, mês a mês.

Se a franquia de GB contratada esvaziou em poucos dias, a causa quase sempre está na parcela de inserção, isto é, em como um fluxo carrega, não em quanto dado a empresa guarda. Este guia parte do sintoma até a ação, com foco nessa parcela: qual configuração está gravando mais bytes do que precisaria, e o que trocar. Ele não reexplica os tipos de carga: para isso, veja Tipos de Carga.

💰 Como o GB do mês é somado ​

O GB cobrado no mês soma duas parcelas, e elas caem na mesma franquia, contra o mesmo limite: não são orçamentos separados.

A parcela de inserção é o tamanho do arquivo Parquet que cada execução envia ao Data Warehouse, acumulado ao longo do mês. Parquet é colunar e comprimido: o que pesa não é o tamanho lógico da linha, é quanto cada coluna comprime, e isso é detalhado nas receitas mais abaixo. A parcela é cumulativa e irreversível dentro do mês: byte gravado, byte contado, e nada desconta esse total antes do fechamento do mês.

A parcela de storage é a média de GB ocupado ao longo do mês. Ela responde ao tamanho que as tabelas têm: aumentar ou reduzir esse tamanho muda a média dali para frente, no mês corrente e nos seguintes.

A diferença entre as duas não é de orçamento, é de comportamento: uma não retrocede dentro do mês, a outra reage ao estado atual da tabela. Isso muda o que cada ação consegue fazer.

TIP

Apagar dado antigo do Data Warehouse reduz a conta, mas só a parcela de storage. Os bytes que aquela linha gravou pertencem à parcela de inserção do mês em que ela entrou, e apagar depois não devolve nada disso: aquele mês já fechou. Mas a tabela fica menor, a média cai a partir dali, e a parcela de storage do mês corrente (e dos seguintes, enquanto a linha ficar fora) diminui. Reter menos histórico é uma alavanca real sobre o GB cobrado, não uma confusão entre contas.

🔍 Onde olhar antes de contratar GB a mais ​

Antes de trocar tipo de carga ou contratar GB extra, vale confirmar onde o consumo está indo. A Home do HEC mostra o card Processamento, com o GB do período selecionado já somado (inserção mais a média de storage). O padrão é o mês corrente, mas a tela tem um seletor de período: confira qual está selecionado antes de tirar conclusão do número. O limite contratado é definido em Recursos > Gerenciar Recursos, dentro de Plataforma e Administração. Veja Gestão de Clientes e Plataforma e Administração.

Quem avisa "quanto falta" é o alerta automático de uso: o sistema confere o consumo de Processamento a cada 4 horas e notifica os administradores ao atingir 80% do limite contratado, e de novo ao ultrapassar 100%. Veja Central de Notificações.

O suspeito mais comum é um fluxo com carga Total ou Janela, numa tabela grande, rodando com frequência alta: veja o agendamento de cada fluxo em Execução e Agendamento, e a duração das execuções recentes em Logs e Monitoramento. Um fluxo que recarrega uma tabela fato inteira várias vezes ao dia é o primeiro lugar para olhar, antes de qualquer contratação.

📐 A regra ​

Esta seção e a de Frequência, logo abaixo, cobrem a parcela de inserção: ela é a alavanca mais rápida para quem estourou a franquia em poucos dias. A parcela de storage tem sua própria lógica, veja Como o GB do mês é somado.

O consumo de um fluxo, num mês, é aproximadamente:

custo ≈ bytes gravados por execução × execuções no mês

Dois fatores. O primeiro (bytes gravados por execução) depende do tipo de carga; no Incremental ele também muda com a frequência, porque cada execução cobre um intervalo menor desde a anterior.

Tipo de cargaO que grava por execução
TotalA tabela inteira
JanelaA janela inteira
IncrementalSó as linhas novas ou alteradas desde a última execução

Total e Janela regravam a cada execução algo que já estava lá: a tabela inteira num caso, a janela inteira no outro. O custo de uma Total é o arquivo enviado com a tabela inteira, não a limpeza que ela faz antes: o DELETE que esvazia a tabela não entra na conta, só o INSERT que a repõe. Incremental grava só o que mudou desde a execução anterior. Detalhe de cada tipo em Tipos de Carga.

WARNING

A Janela não é barata só por não ser Total. O que decide é a proporção entre a janela e o histórico total da tabela, multiplicada pela frequência: quanto mais vezes por mês a janela é regravada, e quanto maior ela for perto do histórico inteiro, mais perto a Janela chega do custo de uma Total.

Fazendo a conta pela própria regra acima: uma janela de 30 dias recarregada de hora em hora grava, por mês, algo como 720 execuções × (30 ÷ histórico em dias) × tamanho da tabela. Uma Total diária grava 30 × tamanho da tabela. As duas contas se igualam quando o histórico tem cerca de 720 dias (2 anos). Numa tabela com 5 anos de histórico, a Janela horária sai mais barata que a Total diária; numa tabela com 1 ano, sai cerca do dobro. Quem decide é o tamanho do histórico, não o tipo de carga sozinho.

O padrão em camadas de Execução e Agendamento (por exemplo, dado de hoje a cada 10 minutos, do mês a cada hora, dos últimos seis meses a cada 6 horas, do total uma vez por dia) resolve atualidade e exclusão, não consumo. A camada "do mês a cada hora" é exatamente a conta acima: 720 execuções mensais sobre uma janela de 30 dias. Ele não está errado, mas custa relativamente mais numa tabela nova, com pouco histórico, do que numa tabela madura, pela mesma conta. Vale medir antes de assumir que o padrão em camadas é sempre a opção barata.

⏱️ Frequência ​

O segundo fator da regra é quantas vezes o fluxo roda no mês, e o efeito dele sobre o custo depende inteiramente do tipo de carga.

Em Total e Janela, dobrar a frequência dobra o consumo. É linear, sem exceção: cada execução grava a tabela inteira ou a janela inteira de novo, então rodar duas vezes mais grava duas vezes mais bytes.

Em Incremental, dobrar a frequência quase não muda o consumo. O delta do mês é o mesmo, fatiado em 30 execuções diárias ou em 720 de hora em hora: o total de linhas novas ou alteradas no período não muda por rodar mais vezes, só chega mais dividido.

IMPORTANT

Essa quase gratuidade vale para tabela append-only, onde uma linha, uma vez gravada, não é alterada de novo. Numa tabela onde a mesma linha muda várias vezes ao dia (um pedido que troca de status, por exemplo), rodar de hora em hora regrava aquela linha a cada hora em que ela mudou, enquanto rodar uma vez por dia grava só o estado final dela. Frequência alta nesse caso custa mais, não é de graça: dizer só "frequência não importa no Incremental" é conselho incompleto, e vale checar se a tabela é append-only ou mutável antes de confiar nessa regra.

🧭 Receitas ​

Seis sintomas comuns, e a ação que ataca cada um.

Carga Total repetida numa tabela grande ​

Sintoma: um fluxo com load_type: Total rodando várias vezes ao dia sobre uma tabela fato de milhões de linhas. Toda execução grava a tabela inteira: o consumo do mês é, na prática, o tamanho da tabela vezes o número de execuções.

Ação: trocar para Incremental. A coluna de rastreio e o key_type da tabela de destino precisam vir juntos, não escolhidos separadamente:

OrigemColuna de rastreiokey_type da tabela
Log ou evento append-only (a linha nunca muda depois de gravada)created_at ou ID sequencialduplicate
Registro mutável (pedido, chamado, contas a receber)updated_atunique, com key_columns

Veja a tabela completa em Tipos de Carga: Como escolher.

WARNING

As duas colunas da tabela acima precisam bater. Rastrear por updated_at (registro mutável) numa tabela com key_type: duplicate, que é o padrão e ainda é a maioria das tabelas, não deduplica nada: cada alteração vira uma cópia nova da linha ao lado da antiga, e a tabela cresce sem parar em vez de estabilizar. key_type é uma propriedade estrutural da tabela: mudar depois força um DROP e CREATE físico, e as linhas existentes são perdidas.

A troca também abre um buraco que a carga Total não tinha: Incremental nunca apaga. Um registro excluído na origem fica no Data Warehouse para sempre, entrando em todo total e todo dashboard, sem erro nenhum na execução. Entre as duas saídas, a mais barata em GB é a Sincronização de Exclusões: ela também envia um arquivo, mas só com as colunas de chave dos registros vivos, muito menor que o arquivo da tabela inteira que uma carga Total periódica exigiria. É um custo recorrente, mas pequeno; a carga Total periódica é recorrente e grande. Decida qual usar antes de trocar para Incremental, não depois.

Sem updated_at nem ID sequencial ​

Sintoma: a origem não oferece uma coluna confiável de rastreio para Incremental, mas a tabela é grande demais para recarregar por inteiro com frequência.

Ação: Janela, com o intervalo mais estreito que a origem permitir, ancorada numa data imutável (emissão, criação, movimento; nunca uma data que pode ser alterada depois). Cada execução grava só a janela, não a tabela inteira. A mesma janela que economiza processamento também limita até onde a carga reflete exclusão: veja o aviso em Janela larga demais. Veja também Tipos de Carga: Extração.

Janela larga demais ​

Sintoma: uma janela generosa "para garantir" (60, 90 dias), quando a origem raramente corrige algo além dos últimos dias.

Antes de mexer, confira duas coisas:

  • Os nós de extração usam {StartDate} e {EndDate}? Se não usam, o fluxo já traz a base inteira independente da janela configurada, e estreitar a janela economiza zero. Pior: com key_type: duplicate, o DELETE passa a cobrir só a janela nova e estreita, mas o INSERT continua trazendo tudo, então o histórico fora da janela passa a duplicar a cada execução. Veja Tipos de Carga: Extração.
  • O volume está distribuído ou concentrado nos dias recentes? A conta de "30 para 3 dias corta cerca de 10 vezes" é aritmética pura, e assume volume parecido entre os dias da janela. Se os dias mais recentes concentram o grosso do volume, os 3 dias que sobram já eram os mais pesados, e o corte real fica bem abaixo de 10 vezes.

Ação: estreitar a janela até o ponto em que a origem deixa de corrigir ou apagar dado, não até onde for tecnicamente possível.

WARNING

A janela é o único jeito de uma carga Janela refletir exclusão. Um registro apagado na origem só some do Data Warehouse se a data dele cair dentro da janela recarregada; fora dela, ele fica lá para sempre, do mesmo jeito que no ponto cego do Incremental. Uma nota cancelada há 12 dias sai do Data Warehouse com uma janela de 30 dias e continua lá, intacta, com uma janela de 3.

Diferente da Incremental, a carga Janela não tem a sincronização de exclusões como saída, porque esse recurso existe só para a Extração Incremental. Quando a janela estreitada deixar exclusões relevantes de fora, a alternativa é rodar uma carga Total periódica por cima.

Fluxo que roda direto e quase nunca tem novidade ​

Sintoma: agendamento por horário rodando a cada poucos minutos numa origem que muda raramente. A maior parte das execuções grava a tabela ou a janela de novo sem encontrar nada novo.

Ação: trocar o gatilho por horário pelo gatilho de mudança de dados (CDC). Ele não muda o que uma execução grava, muda quantas execuções acontecem: uma sonda leve consulta a origem a cada N segundos, e o fluxo só dispara quando o valor sondado muda. O ganho de processamento aparece em carga Total ou Janela, onde frequência é linear (veja Frequência): cortar execuções que não achariam nada corta bytes gravados na mesma proporção. Numa carga Incremental o ganho sobre processamento é pequeno, porque ali a frequência já é quase de graça; o benefício do CDC nesse caso é sobre a origem (menos consultas cheias rodando à toa), não sobre o GB cobrado.

Isso vale só enquanto as execuções disparadas terminam bem: se o flow falhar, o valor observado não avança, a mesma mudança é detectada de novo na sondagem seguinte e o gatilho dispara outra vez. Um flow Total falhando em sequência continua multiplicando bytes gravados, CDC ou não.

A sonda decide se vale rodar, não o que mudou: ela não devolve ao fluxo uma lista de registros alterados, e o fluxo carrega do jeito que já carregava. Dependendo da regra escolhida, ela pode até detectar que uma linha sumiu (contagem, ou contagem e maior valor juntos, pegam exclusão), mas detectar não é o mesmo que espelhar: quem carrega continua sendo o flow, e uma carga Incremental só traz o que existe, então a linha excluída permanece no Data Warehouse mesmo com o gatilho disparando. Veja Gatilho por Mudança de Dados (CDC) para a decisão de uso e a tabela de regras, e Referência: Schedule para o formato do YAML.

SELECT * com colunas que ninguém usa ​

Sintoma: a consulta de extração traz todas as colunas da origem, mas só uma fração delas chega a aparecer num dashboard ou é usada por um fluxo posterior.

Ação: enxugar a consulta para as colunas realmente necessárias, escolhendo por cardinalidade, não por contagem nem por largura declarada. O arquivo que o fluxo envia é Parquet, colunar e comprimido, e quem domina o tamanho dele é quanta variação cada coluna tem, não quantos bytes ela declara.

Uma coluna de valor repetido (status, código de filial, uma flag, qualquer coluna com poucos valores distintos) comprime para quase nada. Uma coluna de alta cardinalidade (UUID, texto livre, timestamp com milissegundos, hash) comprime mal e domina o arquivo. Cortar dez colunas de status pode não mudar o tamanho gravado; cortar uma coluna de texto livre pode cortar metade dele. Comece pelas colunas de alta cardinalidade que ninguém usa, não pela lista mais longa. Vale em qualquer tipo de carga: Total, Janela ou Incremental.

Tabela que só cresce ​

Sintoma: uma tabela de log ou histórico, que só recebe inserção, nunca é reprocessada, e mesmo assim pesa na fatura.

Ação: aqui a parcela de inserção já costuma ser pequena. Uma carga Incremental sobre uma tabela append-only grava só o delta a cada execução, e ainda assim a franquia cai, porque a tabela acumulada engorda a parcela de storage mês após mês. A alavanca aqui não é o tipo de carga, é retenção: arquivar ou apagar histórico que ninguém consulta mais reduz o tamanho médio da tabela, e o efeito aparece na mesma franquia da parcela de inserção, a partir do mês seguinte. Veja Como o GB do mês é somado.

🚫 O que não reduz consumo ​

Três coisas mudam o desempenho da execução sem mudar uma linha do que é cobrado, porque nenhuma altera quantos bytes são gravados no Data Warehouse:

  • Hardware do agente. Mais CPU ou memória deixa a execução mais rápida. Não muda o volume gravado.
  • Driver de conexão. Um driver mais eficiente lê mais rápido da origem. A leitura ficar mais rápida não muda o que é gravado do outro lado.
  • Compressão na origem. Como o dado está armazenado na origem não muda o que a consulta devolve, nem o arquivo que o fluxo grava depois. A compressão que importa é a do Parquet enviado ao Data Warehouse, não a da origem; é por isso que cardinalidade da coluna pesa mais que largura declarada, veja colunas que ninguém usa.

Apagar dado, ao contrário destas três, reduz sim a conta, pela parcela de storage: veja Como o GB do mês é somado.

📚 Relacionados ​