Escolher o modo de dados por frescor × custo

Selo de estado: Preview (teto atual do produto) · Curso ACD-260 — Arquitetura de solução · Aula 2 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai decidir Import, DirectQuery, cache e refresh incremental com o advisor como consultor — e vai saber separar a decisão do painel da decisão do pipeline.

Vídeo#

Identificador: acd-260-02-modo-de-dados-frescor-e-custo · Duração-alvo: 8 min · Tela: /dashboards.

Roteiro (capítulos):

1. 0:00–1:00 — Duas decisões que todo mundo confunde (/dashboards) — modo de dados do painel × modo de carga do pipeline.
2. 1:00–2:40 — Import e DirectQuery pelo custo (/dashboards/[id]) — snapshot com custo zero por acesso × consulta ao vivo cobrada no cache-miss.
3. 2:40–4:00 — As guardas que tornam a escolha segura — teto de bytes, maxRows, mínimo por consulta.
4. 4:00–5:20 — Incremental: barato sem arriscar o número (/dags) — elegibilidade restritiva e a regra "incremental == completo".
5. 5:20–6:30 — O que o plano permite (/billing) — batch, near_rt e por que rt não está na mesa.
6. 6:30–8:00 — A decisão da Aurora (/dashboards) — o advisor consultado, a escolha registrada e o pedido recusado.

Conteúdo#

Primeiro, separe as duas decisões

"Com que frescor?" tem duas respostas em pontos diferentes do desenho, e trocá-las é o erro mais comum desta aula:

Um painel em DirectQuery sobre uma Gold que só é recarregada de madrugada não é tempo real — ele consulta ao vivo uma tabela velha, pagando por isso. Primeiro resolva o frescor da carga; só então escolha o modo do painel.

Import × DirectQuery: a troca explícita

Em Import, o motor materializa um snapshot em refresh agendado (até 1.000 linhas por gráfico, 5.000 por tabela), debita 1 crédito por refresh e grava no Storage. Depois disso, abrir o painel não gera custo novo — e o Δ% versus o período anterior lê o snapshot bom anterior, sem nova consulta.

Em DirectQuery, o painel consulta a base a cada visualização, com cache de 10 minutos: a cobrança acontece no cache-miss; leituras dentro da janela saem do cache. Se um widget falhar, ele vira card de erro e não derruba o painel. Sem Redis configurado, o cache cai num fallback em memória, que não é compartilhado entre instâncias.

O advisor compara o padrão de uso com o orçamento do workload e sugere o modo para aquele painel. A regra de desenho: ele é consultivo e nunca troca o modo por conta própria — o mesmo vale para os budgets por workload, que são advisory e fail-closed. Isso é importante numa proposta: ninguém acorda com o painel em outro modo porque o produto decidiu.

As guardas que tornam DirectQuery defensável

DirectQuery só é uma opção aceitável porque toda consulta passa por guardas de custo, nos dois modos:

• maximumBytesBilled — 1 GiB por padrão: a consulta é abortada antes de estourar o orçamento;
• maxRows travado em 50.000 (nunca ilimitado);
• custo mínimo por consulta de 10 MB (e 10 MB por tabela referenciada) — toda consulta custa algo; nenhuma sai por R$ 0,00;
• o motor de custo estima por bytes lidos (US$ 6,25/TiB, convertido por câmbio configurável).

Sem essas guardas, habilitar DirectQuery seria terceirizar o orçamento para o comportamento do usuário.

Incremental: barato sem arriscar o número

O refresh incremental recalcula só a janela recente (recentDays, no fuso do painel) em vez de refazer o histórico. A decisão de desenho aqui é a elegibilidade restritiva: o motor só assume o caminho incremental quando garante que o resultado é idêntico ao completo — mesmas linhas, mesma ordem. Na menor dúvida, faz o refresh completo e registra o motivo.

A mesma regra governa a carga: o resultado incremental tem de ser idêntico ao full. E há um limite honesto a respeitar no desenho: o incremental do produto é por marca d'água, não CDC — ele não vê deleções. CDC é Roadmap. Se a origem apaga linhas sem deixar rastro, o desenho correto é full ou janela por período re-buscando dias inteiros; prometer incremental ali é prometer um número errado mais barato.

"Um refresh caro é problema de custo; um número errado é problema de produto."

O que o plano permite

Frescor também é entitlement, e isso restringe o desenho antes de qualquer gosto pessoal:

A decisão da Aurora

A Comércio Aurora está no Growth e pede "tempo real" para dois painéis. O desenho que se defende:

• Painel executivo (receita por filial, lido pela manhã): Import, refresh agendado de madrugada, incremental na série mensal — histórico fixo, últimos 7 dias recalculados. Custo previsível: um crédito por refresh e zero durante o dia.
• Painel operacional (pedidos em aberto): near_rt (~15 min, disponível no Growth) com DirectQuery no visual que realmente precisa, e Import no resto da página. Pagar o cache-miss de um visual é diferente de pagar a página inteira.
• O que é recusado: o modo ao vivo (rt), porque ele exige nuvem própria (aula 5) — não é uma chave a ligar. A frase para o cliente: "a cada 15 minutos é o que o plano entrega hoje; ao vivo depende de rodar o datalake na sua conta GCP, e isso é outra conversa de arquitetura e de custo."
• O que fica registrado: a recomendação do advisor para cada painel e o motivo de aceitá-la ou não. Essa linha é o que evita a discussão de novo no mês seguinte.

Erros comuns de desenho

• DirectQuery sobre Gold de madrugada. Custa como ao vivo e entrega como snapshot.
• Tratar o cache como custo zero. Fora da janela de 10 minutos, a próxima leitura cobra de novo.
• Ligar incremental onde ele não qualifica. O motor cai para full por segurança do número — o toggle não força nada.
• Prometer incremental sobre origem que apaga linhas. Watermark não é CDC; CDC é Roadmap.
• Ignorar o advisor sem registrar o motivo. A sugestão não decide, mas descartá-la sem razão escrita é perder a análise.
• Vender rt no Growth. Ao vivo depende de BYOC.

Faça você mesmo#

O produto desta aula é um artefato de decisão: uma matriz de modo de dados com uma linha por painel e a justificativa ao lado. Use /dashboards no workspace de treino Aurora Varejo para conferir o estado atual.

1. Liste os painéis do workspace e, para cada um, escreva quem abre, quantas vezes por dia e qual decisão depende dele.
2. Para cada painel, escreva o frescor exigido em palavras do negócio ("ontem", "até 15 min", "agora").
3. Preencha a coluna modo de dados (Import / DirectQuery / Import + incremental) e a coluna modo de carga do pipeline que o alimenta — são respostas diferentes.
4. Consulte o advisor de cada painel e anote a recomendação e o motivo; marque onde você concorda e onde discorda, com a razão.
5. Estime o custo mensal de cada linha com os números da aula: 1 crédito por refresh em Import; cache-miss em DirectQuery; mínimo de 10 MB por consulta.
6. Marque na matriz o que o plano permite (batch, near_rt) e risque o que não está disponível.
7. Escreva, em uma linha, a recusa que você entrega ao cliente sobre o pedido de tempo real — com a alternativa.

Você terminou quando: cada painel tem modo, frescor, custo estimado e justificativa numa linha, o advisor foi consultado em todos, e existe uma frase escrita que recusa o rt sem fechar a porta.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

• bi/dados-import-directquery-cache
• data/conceitos-modos-de-carga
• administracao/consumo-e-quotas
• data/custo-limites-seguranca

Capacidades ensinadas#

C07.4 · C07.6 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".