Resumo

  • Simulações sobre tabelas protegidas por segurança em nível de linha retornam sempre zero byte para evitar vazamentos de informação. O resultado não serve como previsão de custo.
  • Algumas estatísticas continuam ocultas depois da execução. Tratar campos vazios como consumo zero pode distorcer o rateio entre equipes.

O fechamento do mês tem pouca paciência para lacunas. Falta um número, alguém preenche, a planilha finalmente soma. No BigQuery, esse pequeno favor pode produzir uma grande confusão: premiar uma equipe por um consumo que simplesmente deixou de aparecer.

A segurança em nível de linha restringe quais registros cada usuário pode ver dentro de uma tabela compartilhada. Para impedir que o volume previsto de processamento revele informações sobre os registros protegidos, o BigQuery faz a simulação da consulta retornar zero byte. É uma decisão de confidencialidade, não uma promoção de preço.

O guia de execução de consultas diz que não se pode confiar nessa simulação para estimar custos. A simulação, ou dry run, é gratuita e não usa slots de processamento. A execução real vem depois e obedece ao regime de cobrança aplicável. Juntar as duas coisas é usar o silêncio do sistema como autorização de despesa.

O sigilo alcança o extrato do trabalho

Proteger as linhas exige cuidado também com as informações ao redor delas. Tempos de execução, erros e volumes processados podem revelar algo que o resultado da consulta deixou escondido.

Nas práticas recomendadas de segurança, Google explica que o BigQuery oculta bytes e partições processados, bytes faturados e etapas do plano de consulta para consultas sobre essas tabelas. A restrição não termina quando o trabalho acaba.

Na visão INFORMATION_SCHEMA.JOBS, os campos total_bytes_billed e total_bytes_processed ficam vazios quando a consulta lê tabelas com políticas de acesso por linha. A documentação de JOBS chega a apresentar uma estimativa que conta os trabalhos possivelmente afetados, mas ressalva que não dispõe de seu uso faturável. Contar notas fiscais dentro de envelopes fechados não resolve o valor do pagamento.

Imagine um rateio interno que substitui cada campo ausente por zero. A equipe com mais trabalhos de estatística oculta parecerá gastar menos do que gastou na parcela que deixou de ser contabilizada. O exemplo é hipotético, mas o erro tem endereço: a transformação feita no relatório interno. O sistema de segurança pode funcionar exatamente como deveria enquanto o painel de eficiência distribui medalhas pela informação que não recebeu.

Abrir a cobrança também abre informação

Pedir mais permissão costuma ser a saída mais rápida para um relatório incompleto. Aqui, os acessos precisam ser separados.

Segundo Google, o proprietário do projeto pode ver bytes processados nos registros de auditoria associados. Isso não torna visíveis os metadados de cobrança ocultos nos detalhes do trabalho; não existe uma permissão ou um papel específico que os libere ali. Já o papel Cloud Billing Viewer dá acesso a informações de faturamento.

Google recomenda evitar esse acesso para quem deveria enxergar apenas linhas filtradas, pois a cobrança também pode fornecer pistas sobre dados sensíveis. O financeiro precisa explicar o gasto, mas não ganha por isso uma licença para distribuir todas as pistas a todos os gestores.

A pergunta útil passa a ser quem pode conferir a conta completa e qual retorno cada unidade pode receber. Pode haver uma equipe autorizada a conciliar despesas e produzir informações agregadas compatíveis com os direitos dos destinatários. Isso exige trabalho, definição de responsabilidade e um modo de contestar o rateio. Transparência sem destinatário definido é uma palavra bonita para uma permissão mal pensada.

A janela menor não encolhe automaticamente a leitura

Outra intuição enganosa é a de que ver poucas linhas equivale a pagar por poucas linhas. Google explica que filtros das políticas de acesso por linha não participam da eliminação de partições ou de blocos de tabelas em clusters. Colocar a coluna de partição na política não traz, por si só, esse benefício de redução de processamento. Os filtros da própria consulta são um mecanismo distinto.

A regra de acesso decide o que aparece para o usuário. Ela não fornece uma proporção pronta para calcular o preço.

A tarifação do BigQuery distingue cobrança sob demanda, baseada em bytes processados, de cobrança por capacidade de computação. Ao consultar dados compartilhados, a conta vai para a conta de faturamento ligada ao projeto que executa a consulta. O dono dos dados não vira automaticamente patrocinador de quem os consulta.

Assim, o limite do que alguém pode ver, o volume que precisa ser processado e a fronteira de quem paga têm de ser examinados separadamente. Um zero protegido por sigilo não unifica os três.

As orientações de controle de custos oferecem cotas diárias e um máximo de bytes faturados por consulta no modelo sob demanda. Os documentos consultados não descrevem toda a interação desse máximo com a estimativa ocultada pela segurança por linha; o caso concreto exige verificação autorizada. O número zero na simulação não comprova que o limite será ignorado nem que resolverá sozinho o orçamento.

Não há neste levantamento fatura de cliente e registro de rateio que permitam medir um prejuízo. Esses documentos seriam necessários para calculá-lo. Há, porém, um mecanismo documentado que obriga a empresa a distinguir ausência de estatística de ausência de despesa.

O primeiro passo custa pouco: deixar o desconhecido como desconhecido. O restante é gestão de verdade. Alguém habilitado confere a cobrança, alguém responde pelo critério usado nos custos sem atribuição precisa, e os usuários recebem informação suficiente para ajustar seu comportamento dentro do acesso permitido. O BigQuery pode esconder o medidor. A empresa precisa continuar sabendo quem cuida da conta.