Estime e controle os custos

Esta página descreve as práticas recomendadas para estimar e controlar os custos no BigQuery.

Os custos principais no BigQuery são de computação, usados para o processamento de consultas, e de armazenamento, para os dados armazenados no BigQuery. O BigQuery oferece dois tipos de modelos de preços para o processamento de consultas: preços a pedido e com base na capacidade. Cada modelo oferece diferentes práticas recomendadas para o controlo de custos. Para os dados armazenados no BigQuery, os custos dependem do modelo de faturação de armazenamento configurado para cada conjunto de dados.

Compreenda os preços de computação do BigQuery

Existem diferenças subtis nos preços de computação do BigQuery que afetam o planeamento da capacidade e o controlo de custos.

Modelos de preços

Para a computação a pedido no BigQuery, incorre em custos por TiB para consultas do BigQuery.

Em alternativa, para a computação de capacidade no BigQuery, incorre em custos pelos recursos de computação (slots) que são usados para processar a consulta. Para usar este modelo, configura reservas para espaços.

As reservas têm as seguintes funcionalidades:

  • São alocados em conjuntos de vagas e permitem-lhe gerir a capacidade e isolar cargas de trabalho de formas que fazem sentido para a sua organização.
  • Têm de residir num projeto de administração e estão sujeitos a quotas e limites.

O modelo de preços de capacidade oferece várias edições, que oferecem uma opção de pagamento conforme a utilização cobrada em horas de espaço. As edições Enterprise e Enterprise Plus também oferecem compromissos de espaço opcionais de um ou três anos que podem poupar dinheiro em comparação com a tarifa de pagamento conforme a utilização.

Também pode definir reservas de escalamento automático através da opção de pagamento por utilização. Para mais informações, consulte o seguinte:

Restrinja os custos para cada modelo

Quando usa o modelo de preços a pedido, a única forma de restringir os custos é configurar quotas diárias ao nível do projeto ou do utilizador. No entanto, estas quotas aplicam um limite máximo que impede os utilizadores de executar consultas além do limite da quota. Para definir quotas, consulte o artigo Crie quotas de consultas personalizadas.

Quando usa o modelo de preços de capacidade com reservas de horários disponíveis, especifica o número máximo de horários disponíveis que estão disponíveis para uma reserva. Também pode comprar compromissos de espaços que oferecem preços com desconto por um período de tempo comprometido.

Pode usar edições totalmente a pedido definindo a base da reserva como 0 e o máximo como uma definição que satisfaça as necessidades da sua carga de trabalho. O BigQuery é dimensionado automaticamente até ao número de slots necessários para a sua carga de trabalho, nunca excedendo o máximo que definiu. Para mais informações, consulte o artigo Gestão de cargas de trabalho através de reservas.

Controle os custos das consultas

Para controlar os custos das consultas individuais, recomendamos que siga primeiro as práticas recomendadas para otimizar o cálculo de consultas e otimizar o armazenamento.

As secções seguintes descrevem práticas recomendadas adicionais que pode usar para controlar ainda mais os custos das consultas.

Crie quotas de consultas personalizadas

Prática recomendada: use quotas de consultas diárias personalizadas para limitar a quantidade de dados processados por dia.

Pode gerir os custos definindo uma quota personalizada que especifica um limite para a quantidade de dados processados por dia por projeto ou por utilizador. Os utilizadores não podem executar consultas quando a quota é atingida.

Para definir uma quota personalizada, precisa de funções ou autorizações específicas. Para ver as quotas a definir, consulte o artigo Quotas e limites.

Para mais informações, consulte o artigo Restrinja os custos para cada modelo de preços.

Verifique o custo estimado antes de executar uma consulta

Prática recomendada: antes de executar consultas, pré-visualize-as para estimar os custos.

Quando usa o modelo de preços a pedido, as consultas são faturadas de acordo com o número de bytes lidos. Para estimar os custos antes de executar uma consulta:

Use o validador de consultas

Quando introduz uma consulta na Google Cloud consola, o validador de consultas valida a sintaxe da consulta e fornece uma estimativa do número de bytes lidos. Pode usar esta estimativa para calcular o custo da consulta na calculadora de preços.

  • Se a consulta não for válida, o validador de consultas apresenta uma mensagem de erro. Por exemplo:

    Not found: Table myProject:myDataset.myTable was not found in location US

  • Se a sua consulta for válida, o validador de consultas fornece uma estimativa do número de bytes necessários para processar a consulta. Por exemplo:

    This query will process 623.1 KiB when run.

Faça uma execução de ensaio

Para fazer um teste de execução, faça o seguinte:

Consola

  1. Aceda à página do BigQuery.

    Aceda ao BigQuery

  2. Introduza a consulta no editor de consultas.

    Se a consulta for válida, é apresentado automaticamente uma marca de verificação juntamente com a quantidade de dados que a consulta vai processar. Se a consulta for inválida, é apresentado um ponto de exclamação juntamente com uma mensagem de erro.

bq

Introduza uma consulta como a seguinte usando a flag --dry_run.

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
   COUNTRY,
   AIRPORT,
   IATA
 FROM
   `project_id`.dataset.airports
 LIMIT
   1000'

Para uma consulta válida, o comando produz a seguinte resposta:

Query successfully validated. Assuming the tables are not modified,
running this query will process 10918 bytes of data.

API

Para executar um teste simulado através da API, envie uma tarefa de consulta com o valor dryRun definido como true no tipo JobConfiguration.

Go

Antes de experimentar este exemplo, siga as Goinstruções de configuração no início rápido do BigQuery com bibliotecas cliente. Para mais informações, consulte a API Go BigQuery documentação de referência.

Para se autenticar no BigQuery, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure a autenticação para bibliotecas de cliente. 

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/bigquery"
)

// queryDryRun demonstrates issuing a dry run query to validate query structure and
// provide an estimate of the bytes scanned.
func queryDryRun(w io.Writer, projectID string) error {
	// projectID := "my-project-id"
	ctx := context.Background()
	client, err := bigquery.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("bigquery.NewClient: %v", err)
	}
	defer client.Close()

	q := client.Query(`
	SELECT
		name,
		COUNT(*) as name_count
	FROM ` + "`bigquery-public-data.usa_names.usa_1910_2013`" + `
	WHERE state = 'WA'
	GROUP BY name`)
	q.DryRun = true
	// Location must match that of the dataset(s) referenced in the query.
	q.Location = "US"

	job, err := q.Run(ctx)
	if err != nil {
		return err
	}
	// Dry run is not asynchronous, so get the latest status and statistics.
	status := job.LastStatus()
	if err := status.Err(); err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

Java

Antes de experimentar este exemplo, siga as Javainstruções de configuração no início rápido do BigQuery com bibliotecas cliente. Para mais informações, consulte a API Java BigQuery documentação de referência.

Para se autenticar no BigQuery, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure a autenticação para bibliotecas de cliente. 

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Job;
import com.google.cloud.bigquery.JobInfo;
import com.google.cloud.bigquery.JobStatistics;
import com.google.cloud.bigquery.QueryJobConfiguration;

// Sample to run dry query on the table
public class QueryDryRun {

  public static void runQueryDryRun() {
    String query =
        "SELECT name, COUNT(*) as name_count "
            + "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
            + "WHERE state = 'WA' "
            + "GROUP BY name";
    queryDryRun(query);
  }

  public static void queryDryRun(String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      QueryJobConfiguration queryConfig =
          QueryJobConfiguration.newBuilder(query).setDryRun(true).setUseQueryCache(false).build();

      Job job = bigquery.create(JobInfo.of(queryConfig));
      JobStatistics.QueryStatistics statistics = job.getStatistics();

      System.out.println(
          "Query dry run performed successfully." + statistics.getTotalBytesProcessed());
    } catch (BigQueryException e) {
      System.out.println("Query not performed \n" + e.toString());
    }
  }
}

Node.js

Antes de experimentar este exemplo, siga as Node.jsinstruções de configuração no início rápido do BigQuery com bibliotecas cliente. Para mais informações, consulte a API Node.js BigQuery documentação de referência.

Para se autenticar no BigQuery, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure a autenticação para bibliotecas de cliente. 

// Import the Google Cloud client library
const {BigQuery} = require('@google-cloud/bigquery');
const bigquery = new BigQuery();

async function queryDryRun() {
  // Runs a dry query of the U.S. given names dataset for the state of Texas.

  const query = `SELECT name
    FROM \`bigquery-public-data.usa_names.usa_1910_2013\`
    WHERE state = 'TX'
    LIMIT 100`;

  // For all options, see https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/query
  const options = {
    query: query,
    // Location must match that of the dataset(s) referenced in the query.
    location: 'US',
    dryRun: true,
  };

  // Run the query as a job
  const [job] = await bigquery.createQueryJob(options);

  // Print the status and statistics
  console.log('Status:');
  console.log(job.metadata.status);
  console.log('\nJob Statistics:');
  console.log(job.metadata.statistics);
}

PHP

Antes de experimentar este exemplo, siga as PHPinstruções de configuração no início rápido do BigQuery com bibliotecas cliente. Para mais informações, consulte a API PHP BigQuery documentação de referência.

Para se autenticar no BigQuery, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure a autenticação para bibliotecas de cliente. 

use Google\Cloud\BigQuery\BigQueryClient;

/** Uncomment and populate these variables in your code */
// $projectId = 'The Google project ID';
// $query = 'SELECT id, view_count FROM `bigquery-public-data.stackoverflow.posts_questions`';

// Construct a BigQuery client object.
$bigQuery = new BigQueryClient([
 >   'projectId' = $projectId,
]);

// Set job configs>
$jobConfig = $bigQuery-qu>ery($query);
$jobConfig-useQueryC>ache(false);
$jobConfig-dryRun(true);

// Extract query result>s
$queryJob = $bigQuery-startJob($jobCon>fig);
$info = $queryJob-info();

printf('This query will process %s bytes' . PHP_EOL, $info['statistics']['totalBytesProcessed']);

Python

Defina a propriedade QueryJobConfig.dry_run como True. Client.query() devolve sempre um QueryJob concluído quando é fornecida uma configuração de consulta de teste.

Antes de experimentar este exemplo, siga as Pythoninstruções de configuração no início rápido do BigQuery com bibliotecas cliente. Para mais informações, consulte a API Python BigQuery documentação de referência.

Para se autenticar no BigQuery, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure a autenticação para bibliotecas de cliente. 

from google.cloud import bigquery

# Construct a BigQuery client object.
client = bigquery.Client()

job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Start the query, passing in the extra configuration.
query_job = client.query(
    (
        "SELECT name, COUNT(*) as name_count "
        "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
        "WHERE state = 'WA' "
        "GROUP BY name"
    ),
    job_config=job_config,
)  # Make an API request.

# A dry run query completes immediately.
print("This query will process {} bytes.".format(query_job.total_bytes_processed))

Estime os custos das consultas

Quando usa o modelo de preços a pedido, pode estimar o custo de execução de uma consulta calculando o número de bytes processados.

Cálculo do tamanho da consulta a pedido

Para calcular o número de bytes processados pelos vários tipos de consultas, consulte as secções seguintes:

Evite executar consultas para explorar dados de tabelas

Prática recomendada: não execute consultas para explorar ou pré-visualizar dados de tabelas.

Se estiver a experimentar ou a explorar os seus dados, pode usar as opções de pré-visualização de tabelas para ver os dados sem custo financeiro e sem afetar as quotas.

O BigQuery suporta as seguintes opções de pré-visualização de dados:

  • Na Google Cloud consola, na página de detalhes da tabela, clique no separador Pré-visualizar para ver uma amostra dos dados.
  • Na ferramenta de linhas de comando bq, use o comando bq head e especifique o número de linhas a pré-visualizar.
  • Na API, use tabledata.list para obter dados de tabelas de um conjunto especificado de linhas.
  • Evite usar LIMIT em tabelas não agrupadas. Para tabelas não agrupadas, uma cláusula LIMIT não reduz os custos de computação.

Restrinja o número de bytes faturados por consulta

Prática recomendada: use a definição de bytes faturados máximos para limitar os custos das consultas quando usar o modelo de preços a pedido.

Pode limitar o número de bytes faturados para uma consulta através da definição de bytes máximos faturados. Quando define o máximo de bytes faturados, o número de bytes que a consulta lê é estimado antes da execução da consulta. Se o número de bytes estimados exceder o limite, a consulta falha sem incorrer numa cobrança.

Para tabelas agrupadas, a estimativa do número de bytes faturados para uma consulta é um limite superior e pode ser superior ao número real de bytes faturados após a execução da consulta. Assim, em alguns casos, se definir o máximo de bytes faturados, uma consulta numa tabela agrupada pode falhar, mesmo que os bytes reais faturados não excedam a definição do máximo de bytes faturados.

Se uma consulta falhar devido à definição de bytes faturados máximos, é devolvido um erro semelhante ao seguinte:

Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher required.

Para definir o máximo de bytes faturados:

Consola

  1. No editor de consultas, clique em Mais > Definições da consulta > Opções avançadas.
  2. No campo Máximo de bytes faturados, introduza um número inteiro.
  3. Clique em Guardar.

bq

Use o comando bq query com a flag --maximum_bytes_billed.

  bq query --maximum_bytes_billed=1000000 \
  --use_legacy_sql=false \
  'SELECT
     word
   FROM
     `bigquery-public-data`.samples.shakespeare'

API

Defina a propriedade maximumBytesBilled em JobConfigurationQuery ou QueryRequest.

Evite usar LIMIT em tabelas não agrupadas

Prática recomendada: para tabelas não agrupadas, não use uma cláusula LIMIT como método de controlo de custos.

Para tabelas não agrupadas, a aplicação de uma cláusula LIMIT a uma consulta não afeta a quantidade de dados lidos. A leitura de todos os bytes na tabela inteira é faturada, conforme indicado pela consulta, mesmo que a consulta devolva apenas um subconjunto. Com uma tabela agrupada, uma cláusula LIMIT pode reduzir o número de bytes analisados, porque a análise para quando são analisados blocos suficientes para obter o resultado. A faturação é feita apenas pelos bytes analisados.

Materialize os resultados das consultas em fases

Prática recomendada: se possível, materialize os resultados da consulta em fases.

Se criar uma consulta grande de várias fases, sempre que a executar, o BigQuery lê todos os dados necessários para a consulta. Tem de pagar todos os dados lidos sempre que a consulta é executada.

Em alternativa, divida a consulta em fases em que cada fase materializa os resultados da consulta escrevendo-os numa tabela de destino. A consulta da tabela de destino mais pequena reduz a quantidade de dados lidos e diminui os custos. O custo de armazenamento dos resultados materializados é muito inferior ao custo de processamento de grandes quantidades de dados.

Controle os custos das cargas de trabalho

Esta secção descreve as práticas recomendadas para controlar os custos numa carga de trabalho. Uma carga de trabalho é um conjunto de consultas relacionadas. Por exemplo, uma carga de trabalho pode ser um pipeline de transformação de dados executado diariamente, um conjunto de painéis de controlo executado por um grupo de analistas de negócios ou várias consultas ad hoc executadas por um conjunto de cientistas de dados.

Use a Google Cloud calculadora de preços

Prática recomendada: use a Google Cloud calculadora de preços para criar uma estimativa de custo mensal geral para o BigQuery com base na utilização projetada. Em seguida, pode comparar esta estimativa com os custos reais para identificar áreas de otimização.

A pedido

Para estimar os custos na Google Cloud calculadora de preços quando usar o modelo de preços a pedido, siga estes passos:

  1. Abra a Google Cloud calculadora de preços.
  2. Clique em Adicionar à estimativa.
  3. Selecione BigQuery.
  4. Selecione "A pedido" para Tipo de serviço.
  5. Escolha a localização onde as suas consultas vão ser executadas.
  6. Para Quantidade de dados consultados, introduza os bytes estimados lidos a partir da execução de teste ou do validador de consultas.
  7. Introduza as suas estimativas de utilização de armazenamento para armazenamento ativo, armazenamento a longo prazo, inserções de streaming e leituras de streaming. Só tem de estimar o armazenamento físico ou o armazenamento lógico, consoante o modelo de faturação do armazenamento do conjunto de dados.
  8. A estimativa é apresentada no painel Detalhes do custo. Para mais informações sobre o custo estimado, clique em Abrir vista detalhada. Também pode transferir e partilhar a estimativa de custos.

Para mais informações, consulte a secção Preços a pedido.

Edições

Para estimar os custos na Google Cloud calculadora de preços quando usar o modelo de preços baseado na capacidade com as edições do BigQuery, siga estes passos:

  1. Abra a Google Cloud calculadora de preços.
  2. Clique em Adicionar à estimativa.
  3. Selecione BigQuery.
  4. Selecione "Edições" para Tipo de serviço.
  5. Escolha a localização onde os espaços são usados.
  6. Escolha a sua edição.
  7. Escolha o Número máximo de vagas, o Número de vagas de base, o Compromisso opcional e a Utilização estimada da escala automática.
  8. Escolha a localização onde os dados são armazenados.
  9. Introduza as suas estimativas de utilização de armazenamento para armazenamento ativo, armazenamento a longo prazo, inserções de streaming e leituras de streaming. Só tem de estimar o armazenamento físico ou o armazenamento lógico, consoante o modelo de faturação do armazenamento do conjunto de dados.
  10. A estimativa é apresentada no painel Detalhes do custo. Para mais informações sobre o custo estimado, clique em Abrir vista detalhada. Também pode transferir e partilhar a estimativa de custos.

Para mais informações, consulte o artigo Preços baseados na capacidade.

Use reservas e compromissos

Prática recomendada: use reservas e compromissos do BigQuery para controlar os custos.

Para mais informações, consulte o artigo Restrinja os custos para cada modelo de preços.

Use o estimador de slots

Prática recomendada: use o estimador de slots para estimar o número de slots necessários para as suas cargas de trabalho.

O estimador de slots do BigQuery ajuda a gerir a capacidade dos slots com base nas métricas do histórico de desempenho.

Além disso, os clientes que usam o modelo de preços a pedido podem ver recomendações de dimensionamento para compromissos e reservas de dimensionamento automático com um desempenho semelhante quando mudam para preços baseados na capacidade.

Cancele tarefas de longa duração desnecessárias

Para libertar capacidade, verifique as tarefas de longa duração para se certificar de que devem continuar a ser executadas. Caso contrário, cancele-as.

Veja os custos através de um painel de controlo

Prática recomendada: crie um painel de controlo para analisar os seus dados de faturação do Google Cloud, de modo a poder monitorizar e ajustar a sua utilização do BigQuery.

Pode exportar os seus dados de faturação para o BigQuery e visualizá-los numa ferramenta como o Looker Studio. Para um tutorial sobre a criação de um painel de controlo de faturação, consulte o artigo Visualize Google Cloud a faturação através do BigQuery e do Looker Studio.

Use orçamentos e alertas de faturação

Prática recomendada: use orçamentos do Cloud Billing para monitorizar as suas cobranças do BigQuery num único local.

Os orçamentos do Cloud Billing permitem-lhe acompanhar os custos reais em comparação com os custos planeados. Depois de definir um valor de orçamento, define as regras de limite de alerta de orçamento usadas para acionar notificações por email. Os emails de alerta de orçamento ajudam a manter-se informado sobre a forma como os seus gastos do BigQuery estão a evoluir em relação ao orçamento.

Controle os custos de armazenamento

Use estas práticas recomendadas para otimizar o custo do armazenamento do BigQuery. Também pode otimizar o armazenamento para o desempenho das consultas.

Use armazenamento a longo prazo

Prática recomendada: use a tabela de preços de armazenamento a longo prazo para reduzir o custo dos dados mais antigos.

Quando carrega dados para o armazenamento do BigQuery, os dados estão sujeitos aos preços de armazenamento do BigQuery. Para dados mais antigos, pode tirar partido automaticamente dos preços de armazenamento a longo prazo do BigQuery.

Se tiver uma tabela que não seja modificada durante 90 dias consecutivos, o preço do armazenamento dessa tabela diminui automaticamente 50%. Se tiver uma tabela particionada, cada partição é considerada separadamente para elegibilidade para preços a longo prazo, sujeita às mesmas regras que as tabelas não particionadas.

Configure o modelo de faturação de armazenamento

Prática recomendada: otimize o modelo de faturação de armazenamento com base nos seus padrões de utilização.

O BigQuery suporta a faturação do armazenamento através de bytes lógicos (não comprimidos) ou físicos (comprimidos), ou uma combinação de ambos. O modelo de faturação de armazenamento configurado para cada conjunto de dados determina o preço de armazenamento, mas não afeta o desempenho das consultas.

Pode usar as vistas INFORMATION_SCHEMA para determinar o modelo de faturação de armazenamento que funciona melhor com base nos seus padrões de utilização.

Evite substituir tabelas

Prática recomendada: quando usar o modelo de faturação de armazenamento físico, evite substituir tabelas repetidamente.

Quando substitui uma tabela, por exemplo, usando o parâmetro --replace em tarefas de carregamento em lote ou usando a declaração SQL TRUNCATE TABLE, os dados substituídos são mantidos durante a duração das janelas de viagem no tempo e de segurança. Se substituir uma tabela com frequência, incorre em custos de armazenamento adicionais.

Em alternativa, pode carregar dados incrementalmente para uma tabela através do parâmetro WRITE_APPEND em tarefas de carregamento, da declaração SQL MERGE ou da API Storage Write.

Reduza o período de viagem no tempo

Prática recomendada: com base nos seus requisitos, pode reduzir o período de deslocação no tempo.

Reduzir o período de viagem no tempo do valor predefinido de sete dias reduz o período de retenção dos dados eliminados ou alterados numa tabela. A faturação do armazenamento de viagem no tempo só é feita quando usa o modelo de faturação de armazenamento físico (comprimido).

O intervalo de tempo de viagem no tempo é definido ao nível do conjunto de dados. Também pode definir o período de deslocação no tempo predefinido para novos conjuntos de dados através das definições de configuração.

Use a expiração de tabelas para tabelas de destino

Prática recomendada: se estiver a escrever resultados de consultas grandes numa tabela de destino, use o tempo de validade predefinido da tabela para remover os dados quando já não forem necessários.

Manter grandes conjuntos de resultados no armazenamento do BigQuery tem um custo. Se não precisar de acesso permanente aos resultados, use o prazo de validade predefinido da tabela para eliminar automaticamente os dados.

Arquive dados no Cloud Storage

Prática recomendada: considere arquivar dados no Cloud Storage.

Pode mover dados do BigQuery para o Cloud Storage com base na necessidade empresarial de arquivo. Como prática recomendada, considere os preços de armazenamento a longo prazo e o modelo de faturação de armazenamento físico antes de exportar dados do BigQuery.

Resolução de problemas relacionados com discrepâncias de custos e encargos inesperados do BigQuery

Siga estes passos para resolver problemas de cobranças inesperadas do BigQuery ou discrepâncias de custos:

  1. Para compreender a origem das cobranças do BigQuery quando analisa o relatório de faturação do Google Cloud, a primeira recomendação é agrupar as cobranças por SKU para que seja mais fácil observar a utilização e as cobranças dos serviços do BigQuery correspondentes.

  2. Depois disso, estude os preços das SKUs correspondentes na página de documentação de SKUs ou na página Pricing na IU de faturação do Google Cloud para compreender que funcionalidade é, por exemplo, a API BigQuery Storage Read, o armazenamento a longo prazo, os preços a pedido ou a edição Standard.

  3. Depois de identificar os SKUs correspondentes, use as visualizações INFORMATION_SCHEMA para identificar os recursos específicos associados a estes custos, por exemplo:

Considerações importantes para a resolução de problemas:

  • Tenha em atenção que um período de tempo diário no relatório de faturação na nuvem começa à meia-noite, hora do Pacífico dos EUA e do Canadá (UTC-8), e observa as mudanças da hora nos Estados Unidos. Ajuste os seus cálculos e agregações de dados para corresponderem aos mesmos intervalos de tempo.

  • Filtre por projeto se existirem vários projetos anexados à conta de faturação e quiser rever os encargos provenientes de um projeto específico.

  • Certifique-se de que seleciona a região correta quando realizar investigações.

A resolução de problemas de cobranças inesperadas relacionadas com a execução de tarefas depende da origem destas cobranças:

  • Se vir um aumento nos custos de análise a pedido, isto pode estar relacionado com um aumento no número de tarefas iniciadas ou com a alteração na quantidade de dados que precisam de ser processados pelas tarefas. Investigue esta situação através da vista INFORMATION_SCHEMA.JOBS.
  • Se houver um aumento nas cobranças de espaços comprometidos, investigue-o consultando INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES para ver se foram comprados ou modificados novos compromissos.
  • Para aumentos nos encargos originados da utilização de reservas, analise as alterações às reservas registadas em INFORMATION_SCHEMA.RESERVATION_CHANGES. Para fazer corresponder a utilização da reserva de escala automática aos dados de faturação, siga o exemplo de escala automática.

As horas de slots faturadas são superiores às horas de slots calculadas na vista INFORMATION_SCHEMA.JOBS

Quando usa uma reserva de escalamento automático, a faturação é calculada de acordo com o número de slots dimensionados e não com o número de slots usados. O BigQuery é dimensionado automaticamente em múltiplos de 50 slots, o que leva à faturação do múltiplo mais próximo, mesmo que seja usado um valor inferior ao valor dimensionado automaticamente. O escalador automático tem um período mínimo de 1 minuto antes de reduzir a escala, o que se traduz na cobrança de, pelo menos, 1 minuto, mesmo que a consulta tenha usado os espaços durante menos tempo, por exemplo, apenas 10 segundos do minuto. A forma correta de estimar os custos de uma reserva de escala automática está documentada na página de escala automática de espaços. Para mais informações sobre a utilização eficiente da escala automática, consulte as práticas recomendadas da escala automática.

Observa-se um cenário semelhante para as reservas sem escalabilidade automática: a faturação é calculada de acordo com o número de espaços aprovisionados e não com o número de espaços usados. Se quiser estimar as cobranças de uma reserva sem dimensionamento automático, pode consultar diretamente a vista RESERVATIONS_TIMELINE.

A faturação é inferior ao total de bytes faturados calculados através de INFORMATION_SCHEMA.JOBS para o projeto que executa consultas a pedido

Podem existir vários motivos para a faturação real ser inferior aos bytes processados calculados:

  • Cada projeto recebe 1 TB de consultas do nível gratuito por mês sem custo financeiro adicional.
  • Os trabalhos do tipo SCRIPT não foram excluídos do cálculo, o que pode levar a que alguns valores sejam contabilizados duas vezes.
  • Diferentes tipos de poupanças aplicadas à sua conta do Cloud Billing, como descontos negociados, créditos promocionais e outros. Consulte a secção Poupanças do relatório de faturação do Google Cloud. O nível gratuito de 1 TB de consultas por mês também está incluído aqui.

A faturação é superior aos bytes processados calculados através de INFORMATION_SCHEMA.JOBS para o projeto que executa consultas a pedido

Se o valor de faturação for superior ao valor calculado através da consulta da vista INFORMATION_SCHEMA.JOBS, podem existir determinadas condições que causaram esta situação:

  • Consultas em tabelas com segurança ao nível das linhas

    • As consultas em tabelas com segurança ao nível das linhas não produzem um valor para total_bytes_billed na vista INFORMATION_SCHEMA.JOBS. Por conseguinte, a faturação calculada com base em total_bytes_billed da vista INFORMATION_SCHEMA.JOBS será inferior ao valor faturado. Consulte a página Práticas recomendadas de segurança ao nível da linha para ver mais detalhes sobre o motivo pelo qual estas informações não estão visíveis.

  • Realizar operações de ML no BigQuery

    • O preço do BigQuery ML para consultas a pedido depende do tipo de modelo que está a ser criado. Algumas destas operações de modelos são cobradas a uma taxa mais elevada do que as consultas não relacionadas com ML. Por conseguinte, se apenas somar todos os total_billed_bytes do projeto e usar a taxa padrão de preços a pedido por TB, esta não será uma agregação de preços correta. Tem de ter em conta a diferença de preços por TB.

  • Valores de preços incorretos

    • Confirme se os valores de preços por TB corretos são usados nos cálculos. Certifique-se de que escolhe a região correta, uma vez que os preços dependem da localização. Consulte a documentação de preços.

A recomendação geral é seguir a forma recomendada de calcular a utilização de tarefas a pedido para faturação na nossa documentação pública.

Faturação da utilização da API BigQuery Reservations, mesmo que a API esteja desativada e não sejam usadas reservas nem compromissos

Inspeccione o SKU para compreender melhor que serviços são cobrados. Se a SKU faturada for BigQuery Governance SKU, trata-se de cobranças provenientes do catálogo universal do Dataplex. Algumas funcionalidades do catálogo universal do Dataplex acionam a execução de tarefas através do BigQuery. Estes encargos são agora processados ao abrigo do SKU da API BigQuery Reservations correspondente. Consulte a documentação Preços do catálogo universal do Dataplex para ver mais detalhes.

O projeto está atribuído a uma reserva, mas continua a ver custos a pedido da análise do BigQuery

Leia a secção Resolução de problemas com reservas para identificar a origem das cobranças da Analysis.

Custos inesperados de slots de pagamento conforme o uso (PAYG) para a edição padrão do BigQuery

No relatório de faturação do Google Cloud, aplique um filtro com a etiqueta goog-bq-feature-type e o valor BQ_STUDIO_NOTEBOOK. A utilização que vê é medida como slots de pagamento conforme a utilização na edição padrão do BigQuery. Estes são custos pela utilização do bloco de notas do BigQuery Studio. Leia mais acerca dos preços dos blocos de notas do BigQuery Studio.

Custos da API BigQuery Reservations apresentados após a desativação da API Reservation

A desativação do BigQuery não impede os custos de compromisso. Para parar as cobranças de compromisso, tem de eliminar um compromisso. Defina o plano de renovação como NONE e o compromisso é eliminado automaticamente quando expirar.

Cobranças inesperadas de armazenamento

Cenários que podem levar a aumentos nos custos de armazenamento:

A eliminação de tabelas ou conjuntos de dados resultou em custos de armazenamento do BigQuery mais elevados

A funcionalidade de viagem no tempo do BigQuery retém os dados eliminados durante a duração do período de viagem no tempo configurado e mais 7 dias para recuperação de segurança. Durante este período de retenção, os dados eliminados nos conjuntos de dados do modelo de faturação de armazenamento físico contribuem para o custo de armazenamento físico ativo, mesmo que as tabelas já não apareçam no INFORMATION_SCHEMA.TABLE_STORAGE nem na consola. Se os dados da tabela estiverem no armazenamento a longo prazo, a eliminação faz com que estes dados sejam movidos para o armazenamento físico ativo. Isto faz com que o custo correspondente aumente, porque os bytes físicos ativos são cobrados aproximadamente 2 vezes mais do que os bytes físicos de longo prazo, de acordo com a página de preços de armazenamento do BigQuery. A abordagem recomendada para minimizar os custos causados pela eliminação de dados para conjuntos de dados do modelo de faturação de armazenamento físico é reduzir o período de deslocação no tempo para 2 dias.

Custos de armazenamento reduzidos sem modificações nos dados

No BigQuery, os utilizadores pagam pelo armazenamento ativo e a longo prazo. As cobranças de armazenamento ativo incluem qualquer tabela ou partição de tabela que não tenha sido modificada durante 90 dias consecutivos, enquanto as cobranças de armazenamento a longo prazo incluem tabelas e partições que não foram modificadas durante 90 dias consecutivos. A redução do custo de armazenamento geral pode ser observada quando os dados transitam para o armazenamento a longo prazo, que é cerca de 50% mais barato do que o armazenamento ativo. Leia acerca dos preços de armazenamento para ver mais detalhes.

Os cálculos de armazenamento INFORMATION_SCHEMA não correspondem à faturação

O que se segue?