Introdução ao escalonamento automático de slots

As reservas que você configura para usar o escalonamento automático de slots escalonam automaticamente a capacidade alocada para acomodar as demandas de carga de trabalho. À medida que a carga de trabalho aumenta ou diminui, o BigQuery ajusta dinamicamente os slots para um nível apropriado. As reservas com escalonamento automático de slots estão disponíveis apenas com as edições do BigQuery.

Observação: os clientes que começarem a usar o escalonador automático após 10 de julho de 2024 terão acesso ao escalonamento automático, conforme descrito neste documento. Os clientes que usam o escalonador automático antes de 10 de julho de 2024 podem continuar a usar o escalonamento automático com incrementos de 100 slots e escalonamento não instantâneo até que a atualização seja lançada. Para clientes que não foram migrados, o aumento e a redução de escala são baseados em uma estimativa que pode ser provisionada em excesso ou insuficiente. O faturamento é baseado nos slots provisionados pela estimativa. A migração acontece para todas as reservas no projeto, não para reservas individuais.

Usar reservas de escalonamento automático

Você não precisa adquirir compromissos de slot antes de criar reservas de escalonamento automático. Os compromissos de slot fornecem um preço com desconto para slots usados de forma consistente, mas são opcionais com reservas de escalonamento automático. Para criar uma reserva de escalonamento automático, atribua uma reserva a um número máximo de slots (o tamanho máximo da reserva). Para identificar o número máximo de slots de escalonamento automático, subtraia o tamanho máximo da reserva de todos os slots de valor de referência opcionais atribuídos à reserva.

Ao criar reservas de escalonamento automático, considere o seguinte:

• O BigQuery escalona reservas quase instantaneamente até atingir o número de slots necessários para executar os jobs ou atingir o número máximo de slots disponíveis para a reserva. Os slots sempre são escalonados automaticamente para um múltiplo de 50.
• O escalonamento é baseado no uso real e é arredondado para o incremento de 50 slots mais próximo.
• Os slots com escalonamento automático são cobrados de acordo com os preços de capacidade de computação da edição associada durante o escalonamento vertical. Você é cobrado pelo número de slots escalonados, não pelo número de slots usados. Essa cobrança será aplicada mesmo se o job que faz o BigQuery escalonar verticalmente falhar. Por esse motivo, não use o esquema de informações de jobs para corresponder ao faturamento. Consulte Monitorar o escalonamento automático com o esquema de informações.
• Embora o número de slots sempre seja escalonado por múltiplos de 50, é possível escalonar mais de 50 slots em uma etapa. Por exemplo, se sua carga de trabalho exigir mais 450 slots, o BigQuery pode tentar escalonar por 450 slots de uma vez para atender ao requisito de capacidade.
• O BigQuery é reduzido quando os jobs associados à reserva não precisam mais da capacidade (sujeito a um mínimo de 1 minuto).

Qualquer capacidade com escalonamento automático é retida por pelo menos 60 segundos. Esse período de 60 segundos é chamado de janela de redução. Qualquer pico na capacidade redefine a janela de redução, tratando todo o nível de capacidade como uma nova concessão. No entanto, se 60 segundos ou mais tiverem se passado desde o último aumento de capacidade e houver menos demanda, o sistema vai reduzir a capacidade sem redefinir a janela de redução, permitindo reduções consecutivas sem um atraso imposto.

Para saber como trabalhar com o escalonamento automático, consulte Trabalhar com escalonamento automático de slots.

Como usar reservas com slots de valor de referência e escalonamento automático

Além de especificar o tamanho máximo da reserva, é possível opcionalmente determinar um número de referência de slots por reserva. O valor de referência é o número mínimo de slots que sempre serão alocados na reserva e que sempre serão cobrados. Os slots de escalonamento automático são adicionados somente depois que todos os slots de linha de base (e os slots inativos, se aplicável) são consumidos. É possível compartilhar slots de valor de referência inativos em uma reserva com outras que precisam de capacidade.

É possível aumentar o número de slots de valor de referência em uma reserva a cada poucos minutos. Se você quiser diminuir os slots de valor de referência, terá o limite de uma hora por hora se tiver alterado recentemente a capacidade de slots do valor de referência e os slots de referência excederem os slots confirmados. Caso contrário, é possível diminuir os slots de valor de referência em intervalos de alguns minutos.

Os slots de valor de referência e de escalonamento automático foram projetados para fornecer capacidade com base na sua carga de trabalho recente. Se você antecipar uma grande carga de trabalho que seja muito diferente das suas cargas de trabalho recentes, recomendamos aumentar a capacidade de valor de referência antes do evento, em vez de depender de slots de escalonamento automático para cobrir a capacidade. Se você encontrar um problema ao aumentar a capacidade de referência, tente novamente a solicitação após 15 minutos.

Se a reserva não tiver slots de valor de referência ou não estiver configurada para emprestar slots inativos de outras reservas, o BigQuery tentará escalonar. Caso contrário, os slots de valor de referência precisam ser totalmente utilizados antes do escalonamento.

As reservas usam e adicionam slots na seguinte prioridade:

1. Slots de referência:
2. Compartilhamento de slots inativos (se ativado). As reservas só podem compartilhar valor de referência ocioso ou slots confirmados de outras reservas que foram criadas com a mesma edição e a mesma região.
3. Slots de escalonamento automático.

No exemplo a seguir, os slots são dimensionados de acordo com um valor de referência especificado. As reservas etl e dashboard têm um tamanho de referência de 700 e 300 slots, respectivamente.

Neste exemplo, a reserva etl pode ser dimensionada para 1.300 slots (700 slots de valor de referência mais 600 slots de escalonamento automático). Se a reserva dashboard não estiver em uso, a reserva etl poderá usar os 300 slots da reserva dashboard se nenhum job estiver em execução lá, levando a um máximo de 1.600 slots possíveis slots.

A reserva dashboard pode ser escalonada para 1.100 slots (300 slots de valor de referência mais 800 slots de escalonamento automático). Se a reserva etl estiver totalmente inativa, a reserva dashboard poderá ser escalonada para, no máximo, 1.800 slots (300 slots de valor de referência, 800 slots de escalonamento automático, mais 700 slots inativos na reserva etl).

Se a reserva etl exigir mais de 700 slots de valor de referência, que estão sempre disponíveis, ela tentará adicionar slots usando os seguintes métodos na ordem:

1. 700 slots de referência.
2. Compartilhamento de slot inativo com os 300 slots de valor de referência na reserva dashboard. Sua reserva compartilha apenas slots de valor de referência ociosos com outras reservas criadas com a mesma edição.
3. Escalonar verticalmente mais 600 slots para o tamanho máximo de reserva.

Como usar compromissos de slot

No exemplo a seguir, mostramos o escalonamento automático de slots usando compromissos de capacidade.

Assim como os valores de referência de reserva, os compromissos de slot permitem alocar um número fixo de slots disponíveis para todas as reservas. Ao contrário dos slots de valor de referência, não é possível reduzir um compromisso durante o prazo. Os compromissos de slot são opcionais, mas podem economizar custos se forem necessários slots de valor de referência por longos períodos.

Neste exemplo, é cobrada uma taxa predefinida pelos slots de compromisso de capacidade. Você será cobrado pela taxa de escalonamento automático pelo número de slots de escalonamento automático após a ativação do escalonamento automático e as reservas em um estado otimizado. Para a taxa de escalonamento automático, você é cobrado pelo número de slots escalonados, não pelo número de slots usados.

Máximo de slots disponíveis

É possível calcular o número máximo de slots que uma reserva pode usar adicionando os slots de valor de referência, o número máximo de slots de escalonamento automático e todos os slots em confirmações que foram criadas com escalonamento automático de slots e não são cobertas pelo slots de referência. O exemplo na imagem anterior é configurado da seguinte maneira:

• Um compromisso de capacidade de 1.000 slots anuais. Esses slots são atribuídos como slots de referência na reserva etl e na reserva dashboard.
• 700 slots de valor de referência atribuídos à reserva etl.
• 300 slots de valor de referência atribuídos à reserva dashboard.
• Escalonamento automático de slots de 600 para a reserva etl.
• Escalonamento automático de slots de 800 para a reserva dashboard.

Para a reserva etl, o número máximo de slots possível é igual aos slots de referência etl (700) mais os slots de valor de referência dashboard (300, se todos os slots estiverem inativos). mais o número máximo de slots de escalonamento automático (600). Portanto, o número máximo de slots que a reserva etl pode usar neste exemplo é 1.600. Esse número excede o do compromisso de capacidade.

No exemplo a seguir, o compromisso anual excede os slots de valor de referência atribuídos.

Neste exemplo, temos:

• Um compromisso de capacidade de 1.600 slots anuais.
• Um tamanho máximo de reserva de 1.500 (incluindo 500 slots de escalonamento automático).
• 1.000 slots de valor de referência atribuídos à reserva etl.

O número máximo de slots disponíveis para a reserva é igual aos slots de valor de referência (1.000), mais os slots inativos com compromisso não dedicados aos slots de valor de referência (1.600 slots anuais - 1.000 slots de valor de referência = 600) mais o número de slots de escalonamento automático (500). Portanto, o número máximo de slots possíveis nessa reserva é de 2.100. Os slots com escalonamento automático são slots adicionais acima do compromisso de capacidade.

Práticas recomendadas para escalonamento automático

1. Ao usar o escalonador automático pela primeira vez, defina o número de slots de escalonamento automático como um número significativo com base no desempenho anterior e esperado. Depois que a reserva for criada, monitore ativamente a taxa de falhas, o desempenho e o faturamento e ajuste o número de slots de escalonamento automático conforme necessário.

2. O escalonador automático tem um mínimo de um minuto antes de reduzir o dimensionamento. Portanto, é importante definir o número máximo de slots de escalonamento automático para equilibrar o desempenho e o custo. Se o número máximo de slots de escalonamento automático for muito grande e seu job puder usar todos os slots para concluir um job em segundos, você ainda vai incorrer em custos para os slots máximos do minuto inteiro. Se você reduzir os slots máximos para metade do valor atual, a reserva será dimensionada para um número menor, e o job poderá usar mais slot_seconds durante esse minuto, reduzindo o desperdício. Para determinar seus requisitos de slot, consulte Monitorar a performance do job. Como alternativa para determinar os requisitos de slot, consulte Conferir recomendações de slot da edição.

3. De vez em quando, o uso de slots pode exceder a soma do valor de referência mais os slots dimensionados. Você não vai receber cobranças pelo uso de slots maior que o valor de referência mais os slots escalonados.

4. O autoescalador é mais eficiente para cargas de trabalho pesadas e de longa duração, como cargas de trabalho com várias consultas simultâneas. Evite enviar consultas uma por vez, já que cada consulta dimensiona a reserva, onde ela vai permanecer dimensionada por um mínimo de um minuto. Se você enviar consultas continuamente, causando uma carga de trabalho constante, definir uma referência e comprar um compromisso oferece capacidade constante a um preço com desconto.

5. O escalonamento automático do BigQuery está sujeito à disponibilidade de capacidade. O BigQuery tenta atender à demanda de capacidade do cliente com base no uso histórico. Para alcançar as garantias de capacidade, defina um valor de referência de slot opcional, que é o número de slots garantidos em uma reserva. Com os valores de referência, os slots ficam disponíveis imediatamente e você paga por eles, independentemente de usá-los ou não. Para garantir que a capacidade esteja disponível para grandes demandas inorgânicas, como feriados de alto tráfego, entre em contato com a equipe do BigQuery com várias semanas de antecedência.

6. Os slots de valor de referência sempre são carregados. Se um compromisso de capacidade expirar, talvez seja necessário ajustar manualmente a quantidade de slots de valor de referência nas reservas para evitar cobranças indesejadas. Por exemplo, considere que você tem um compromisso de um ano com 100 slots e uma reserva com 100 slots de valor de referência. O compromisso expira e não tem um plano de renovação. Quando o compromisso expirar, você pagará por 100 slots de valor de referência com a taxa de pagamento por utilização.

Monitorar o escalonamento automático

Ao monitorar o uso de slots com gráficos de recursos administrativos, é possível conferir mais slots significativamente dimensionados do que o uso de slots, porque os gráficos suavizam o número de slots usados durante o período de alinhamento. Para visualizar o uso de slots de escalonamento automático com detalhes mais precisos, reduza a opção de período. Isso atualiza automaticamente o período de alinhamento para um incremento menor.

No exemplo a seguir, o gráfico mostra muito mais slots dimensionados do que as demandas da carga de trabalho.

No entanto, se você reduzir a opção de período para que o período de alinhamento seja dois segundos, o escalonador automático é escalonado de acordo com a demanda da carga de trabalho e mostra dados mais precisos. Para ajustar a opção de período, arraste os intervalos de início e término dela. Para exibir os dados de demanda de carga de trabalho mais precisos, selecione p99 na lista métrica.

Para ter a visualização mais precisa do uso do escalonamento automático, use um período de alinhamento entre 1 e 15 segundos. Para mais informações sobre o período de alinhamento dos gráficos de recursos administrativos, consulte Opção de período.

Para informações sobre como visualizar o uso de slots, consulte Ver gráficos de recursos administrativos

Monitorar o escalonamento automático com esquema de informações

É possível usar os seguintes scripts SQL para verificar os segundos de slot faturados de uma edição específica. Execute esses scripts no mesmo projeto em que as reservas foram criadas. O primeiro script mostra os segundos de slot faturados cobertos por commitment_plan, enquanto o segundo mostra os segundos de slot faturados que não são cobertos por um compromisso.

Você só precisa definir o valor de três variáveis para executar esses scripts:

• start_time
• end_time
• edition_to_check

Esses scripts estão sujeitos às seguintes ressalvas:

• As reservas e os compromissos de capacidade excluídos são removidos das visualizações do esquema de informações no final do período de armazenamento de dados. Especifique uma janela de tempo recente que não contenha reservas e compromissos excluídos para resultados corretos.

• O resultado dos scripts pode não corresponder exatamente à fatura devido a pequenos erros de arredondamento.

O script a seguir verifica o uso de slot coberto pelos compromissos de uma edição específica.

Clique para abrir o script das situações abordadas

DECLARE start_time,end_time TIMESTAMP;

DECLARE
  edition_to_check STRING;

/* Google uses Pacific Time to calculate the billing period for all customers,
regardless of their time zone. Use the following format if you want to match the
billing report. Change the start_time and end_time values to match the desired
window. */

/* The following three variables (start_time, end_time, and edition_to_check)
are the only variables that you need to set in the script.

During daylight savings time, the start_time and end_time variables should
follow this format: 2024-02-20 00:00:00-08. */

SET start_time = "2023-07-20 00:00:00-07";
SET end_time = "2023-07-28 00:00:00-07";
SET edition_to_check = 'ENTERPRISE';

/* The following function returns the slot seconds for the time window between
two capacity changes. For example, if there are 100 slots between (2023-06-01
10:00:00, 2023-06-01 11:00:00), then during that window the total slot seconds
will be 100 * 3600.

This script calculates a specific window (based on the variables defined above),
which is why the following script includes script_start_timestamp_unix_millis
and script_end_timestamp_unix_millis. */

CREATE TEMP FUNCTION
GetSlotSecondsBetweenChanges(
  slots FLOAT64,
  range_begin_timestamp_unix_millis FLOAT64,
  range_end_timestamp_unix_millis FLOAT64,
  script_start_timestamp_unix_millis FLOAT64,
  script_end_timestamp_unix_millis FLOAT64)
RETURNS INT64
LANGUAGE js
AS r"""
    if (script_end_timestamp_unix_millis < range_begin_timestamp_unix_millis || script_start_timestamp_unix_millis > range_end_timestamp_unix_millis) {
      return 0;
    }
    var begin = Math.max(script_start_timestamp_unix_millis, range_begin_timestamp_unix_millis)
    var end = Math.min(script_end_timestamp_unix_millis, range_end_timestamp_unix_millis)
    return slots * Math.ceil((end - begin) / 1000.0)
""";

/*
Sample CAPACITY_COMMITMENT_CHANGES data (unrelated columns ignored):
+---------------------+------------------------+-----------------+--------+------------+--------+
|  change_timestamp   | capacity_commitment_id | commitment_plan | state  | slot_count | action |
+---------------------+------------------------+-----------------+--------+------------+--------+
| 2023-07-20 19:30:27 | 12954109101902401697   | ANNUAL          | ACTIVE |        100 | CREATE |
| 2023-07-27 22:29:21 | 11445583810276646822   | FLEX            | ACTIVE |        100 | CREATE |
| 2023-07-27 23:10:06 | 7341455530498381779    | MONTHLY         | ACTIVE |        100 | CREATE |
| 2023-07-27 23:11:06 | 7341455530498381779    | FLEX            | ACTIVE |        100 | UPDATE |

The last row indicates a special change from MONTHLY to FLEX, which happens
because of commercial migration.

*/

WITH
  /*
  Information containing which commitment might have plan
  updated (e.g. renewal or commercial migration). For example:
  +------------------------+------------------+--------------------+--------+------------+--------+-----------+----------------------------+
  |  change_timestamp   | capacity_commitment_id | commitment_plan | state  | slot_count | action | next_plan | next_plan_change_timestamp |
  +---------------------+------------------------+-----------------+--------+------------+--------+-----------+----------------------------+
  | 2023-07-20 19:30:27 | 12954109101902401697   | ANNUAL          | ACTIVE |        100 | CREATE | ANNUAL    |        2023-07-20 19:30:27 |
  | 2023-07-27 22:29:21 | 11445583810276646822   | FLEX            | ACTIVE |        100 | CREATE | FLEX      |        2023-07-27 22:29:21 |
  | 2023-07-27 23:10:06 | 7341455530498381779    | MONTHLY         | ACTIVE |        100 | CREATE | FLEX      |        2023-07-27 23:11:06 |
  | 2023-07-27 23:11:06 | 7341455530498381779    | FLEX            | ACTIVE |        100 | UPDATE | FLEX      |        2023-07-27 23:11:06 |
  */
  commitments_with_next_plan AS (
    SELECT
      *,
      IFNULL(
        LEAD(commitment_plan)
          OVER (
            PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC
          ),
        commitment_plan)
        next_plan,
      IFNULL(
        LEAD(change_timestamp)
          OVER (
            PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC
          ),
        change_timestamp)
        next_plan_change_timestamp
    FROM
      `region-us.INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES_BY_PROJECT`
  ),

  /*
  Insert a 'DELETE' action for those with updated plans. The FLEX commitment
  '7341455530498381779' is has no 'CREATE' action, and is instead labeled as an
  'UPDATE' action.

  For example:
  +---------------------+------------------------+-----------------+--------+------------+--------+
  |  change_timestamp   | capacity_commitment_id | commitment_plan | state  | slot_count | action |
  +---------------------+------------------------+-----------------+--------+------------+--------+
  | 2023-07-20 19:30:27 | 12954109101902401697   | ANNUAL          | ACTIVE |        100 | CREATE |
  | 2023-07-27 22:29:21 | 11445583810276646822   | FLEX            | ACTIVE |        100 | CREATE |
  | 2023-07-27 23:10:06 | 7341455530498381779    | MONTHLY         | ACTIVE |        100 | CREATE |
  | 2023-07-27 23:11:06 | 7341455530498381779    | FLEX            | ACTIVE |        100 | UPDATE |
  | 2023-07-27 23:11:06 | 7341455530498381779    | MONTHLY         | ACTIVE |        100 | DELETE |
  */

  capacity_changes_with_additional_deleted_event_for_changed_plan AS (
    SELECT
      next_plan_change_timestamp AS change_timestamp,
      project_id,
      project_number,
      capacity_commitment_id,
      commitment_plan,
      state,
      slot_count,
      'DELETE' AS action,
      commitment_start_time,
      commitment_end_time,
      failure_status,
      renewal_plan,
      user_email,
      edition,
      is_flat_rate,
    FROM commitments_with_next_plan
    WHERE commitment_plan <> next_plan
    UNION ALL
    SELECT * FROM `region-us.INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES_BY_PROJECT`
  ),

  /*
  The committed_slots change the history. For example:
  +---------------------+------------------------+------------------+-----------------+
  |  change_timestamp   | capacity_commitment_id | slot_count_delta | commitment_plan |
  +---------------------+------------------------+------------------+-----------------+
  | 2023-07-20 19:30:27 | 12954109101902401697   |              100 | ANNUAL          |
  | 2023-07-27 22:29:21 | 11445583810276646822   |              100 | FLEX            |
  | 2023-07-27 23:10:06 | 7341455530498381779    |              100 | MONTHLY         |
  | 2023-07-27 23:11:06 | 7341455530498381779    |             -100 | MONTHLY         |
  | 2023-07-27 23:11:06 | 7341455530498381779    |              100 | FLEX            |
  */

  capacity_commitment_slot_data AS (
    SELECT
      change_timestamp,
      capacity_commitment_id,
      CASE
        WHEN action = "CREATE" OR action = "UPDATE"
          THEN
            IFNULL(
              IF(
                LAG(action)
                  OVER (
                    PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC
                  )
                  IN UNNEST(['CREATE', 'UPDATE']),
                slot_count - LAG(slot_count)
                  OVER (
                    PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC
                  ),
                slot_count),
              slot_count)
        ELSE
          IF(
            LAG(action)
              OVER (PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC)
              IN UNNEST(['CREATE', 'UPDATE']),
            -1 * slot_count,
            0)
        END
        AS slot_count_delta,
      commitment_plan
    FROM
      capacity_changes_with_additional_deleted_event_for_changed_plan
    WHERE
      state = "ACTIVE"
      AND edition = edition_to_check
      AND change_timestamp <= end_time
  ),

  /*
  The total_committed_slots history for each plan. For example:
  +---------------------+---------------+-----------------+
  |  change_timestamp   | capacity_slot | commitment_plan |
  +---------------------+---------------+-----------------+
  | 2023-07-20 19:30:27 |           100 | ANNUAL          |
  | 2023-07-27 22:29:21 |           100 | FLEX            |
  | 2023-07-27 23:10:06 |           100 | MONTHLY         |
  | 2023-07-27 23:11:06 |             0 | MONTHLY         |
  | 2023-07-27 23:11:06 |           200 | FLEX            |
  */

  running_capacity_commitment_slot_data AS (
    SELECT
      change_timestamp,
      SUM(slot_count_delta)
        OVER (
          PARTITION BY commitment_plan
          ORDER BY change_timestamp
          RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        )
        AS capacity_slot,
      commitment_plan,
    FROM
      capacity_commitment_slot_data
  ),

  /*

  The slot_seconds between each changes, partitioned by each plan. For example:
  +---------------------+--------------+-----------------+
  |  change_timestamp   | slot_seconds | commitment_plan |
  +---------------------+--------------+-----------------+
  | 2023-07-20 19:30:27 |     64617300 | ANNUAL          |
  | 2023-07-27 22:29:21 |       250500 | FLEX            |
  | 2023-07-27 23:10:06 |         6000 | MONTHLY         |
  | 2023-07-27 23:11:06 |            0 | MONTHLY         |
  | 2023-07-27 23:11:06 |      5626800 | FLEX            |
  */

  slot_seconds_data AS (
    SELECT
      change_timestamp,
      GetSlotSecondsBetweenChanges(
        capacity_slot,
        UNIX_MILLIS(change_timestamp),
        UNIX_MILLIS(
          IFNULL(
            LEAD(change_timestamp)
              OVER (PARTITION BY commitment_plan ORDER BY change_timestamp ASC),
            CURRENT_TIMESTAMP())),
        UNIX_MILLIS(start_time),
        UNIX_MILLIS(end_time)) AS slot_seconds,
      commitment_plan,
    FROM
      running_capacity_commitment_slot_data
    WHERE
      change_timestamp <= end_time
  )

/*

The final result is similar to the following:
+-----------------+--------------------+
| commitment_plan | total_slot_seconds |
+-----------------+--------------------+
| ANNUAL          |           64617300 |
| MONTHLY         |               6000 |
| FLEX            |            5877300 |
*/

SELECT
  commitment_plan,
  SUM(slot_seconds) AS total_slot_seconds
FROM
  slot_seconds_data
GROUP BY
  commitment_plan

O script a seguir verifica o uso de slots não coberto pelos compromissos de uma edição específica. Esse uso contém dois tipos de slots: escalonados e de referência não cobertos por compromissos.

Clique para abrir o script em situações não abrangidas

/*
This script has several parts:
1. Calculate the baseline and scaled slots for reservations
2. Calculate the committed slots
3. Join the two results above to calculate the baseline not covered by committed
   slots
4. Aggregate the number
*/

-- variables
DECLARE start_time, end_time TIMESTAMP;

DECLARE
  edition_to_check STRING;

/* Google uses Pacific Time to calculate the billing period for all customers,
regardless of their time zone. Use the following format if you want to match the
billing report. Change the start_time and end_time values to match the desired
window. */

/* The following three variables (start_time, end_time, and edition_to_check)
are the only variables that you need to set in the script.

During daylight savings time, the start_time and end_time variables should
follow this format: 2024-02-20 00:00:00-08. */

SET start_time = "2023-07-20 00:00:00-07";
SET end_time = "2023-07-28 00:00:00-07";
SET edition_to_check = 'ENTERPRISE';

/*
The following function returns the slot seconds for the time window between
two capacity changes. For example, if there are 100 slots between (2023-06-01
10:00:00, 2023-06-01 11:00:00), then during that window the total slot seconds
will be 100 * 3600.

This script calculates a specific window (based on the variables defined above),
which is why the following script includes script_start_timestamp_unix_millis
and script_end_timestamp_unix_millis. */

CREATE TEMP FUNCTION GetSlotSecondsBetweenChanges(
  slots FLOAT64,
  range_begin_timestamp_unix_millis FLOAT64,
  range_end_timestamp_unix_millis FLOAT64,
  script_start_timestamp_unix_millis FLOAT64,
  script_end_timestamp_unix_millis FLOAT64)
RETURNS INT64
LANGUAGE js
AS r"""
    if (script_end_timestamp_unix_millis < range_begin_timestamp_unix_millis || script_start_timestamp_unix_millis > range_end_timestamp_unix_millis) {
      return 0;
    }
    var begin = Math.max(script_start_timestamp_unix_millis, range_begin_timestamp_unix_millis)
    var end = Math.min(script_end_timestamp_unix_millis, range_end_timestamp_unix_millis)
    return slots * Math.ceil((end - begin) / 1000.0)
""";
/*
Sample RESERVATION_CHANGES data (unrelated columns ignored):
+---------------------+------------------+--------+---------------+---------------+
|  change_timestamp   | reservation_name | action | slot_capacity | current_slots |
+---------------------+------------------+--------+---------------+---------------+
| 2023-07-27 22:24:15 | res1             | CREATE |           300 |             0 |
| 2023-07-27 22:25:21 | res1             | UPDATE |           300 |           180 |
| 2023-07-27 22:39:14 | res1             | UPDATE |           300 |           100 |
| 2023-07-27 22:40:20 | res2             | CREATE |           300 |             0 |
| 2023-07-27 22:54:18 | res2             | UPDATE |           300 |           120 |
| 2023-07-27 22:55:23 | res1             | UPDATE |           300 |             0 |

Sample CAPACITY_COMMITMENT_CHANGES data (unrelated columns ignored):
+---------------------+------------------------+-----------------+--------+------------+--------+
|  change_timestamp   | capacity_commitment_id | commitment_plan | state  | slot_count | action |
+---------------------+------------------------+-----------------+--------+------------+--------+
| 2023-07-20 19:30:27 | 12954109101902401697   | ANNUAL          | ACTIVE |        100 | CREATE |
| 2023-07-27 22:29:21 | 11445583810276646822   | FLEX            | ACTIVE |        100 | CREATE |
| 2023-07-27 23:10:06 | 7341455530498381779    | MONTHLY         | ACTIVE |        100 | CREATE |
*/

WITH
  /*
  The scaled_slots & baseline change history:
  +---------------------+------------------+------------------------------+---------------------+
  |  change_timestamp   | reservation_name | autoscale_current_slot_delta | baseline_slot_delta |
  +---------------------+------------------+------------------------------+---------------------+
  | 2023-07-27 22:24:15 | res1             |                            0 |                 300 |
  | 2023-07-27 22:25:21 | res1             |                          180 |                   0 |
  | 2023-07-27 22:39:14 | res1             |                          -80 |                   0 |
  | 2023-07-27 22:40:20 | res2             |                            0 |                 300 |
  | 2023-07-27 22:54:18 | res2             |                          120 |                   0 |
  | 2023-07-27 22:55:23 | res1             |                         -100 |                   0 |
  */
  reservation_slot_data AS (
    SELECT
      change_timestamp,
      reservation_name,
      CASE action
        WHEN "CREATE" THEN autoscale.current_slots
        WHEN "UPDATE"
          THEN
            IFNULL(
              autoscale.current_slots - LAG(autoscale.current_slots)
                OVER (
                  PARTITION BY project_id, reservation_name
                  ORDER BY change_timestamp ASC, action ASC
                ),
              IFNULL(
                autoscale.current_slots,
                IFNULL(
                  -1 * LAG(autoscale.current_slots)
                    OVER (
                      PARTITION BY project_id, reservation_name
                      ORDER BY change_timestamp ASC, action ASC
                    ),
                  0)))
        WHEN "DELETE"
          THEN
            IF(
              LAG(action)
                OVER (
                  PARTITION BY project_id, reservation_name
                  ORDER BY change_timestamp ASC, action ASC
                )
                IN UNNEST(['CREATE', 'UPDATE']),
              -1 * autoscale.current_slots,
              0)
        END
        AS autoscale_current_slot_delta,
      CASE action
        WHEN "CREATE" THEN slot_capacity
        WHEN "UPDATE"
          THEN
            IFNULL(
              slot_capacity - LAG(slot_capacity)
                OVER (
                  PARTITION BY project_id, reservation_name
                  ORDER BY change_timestamp ASC, action ASC
                ),
              IFNULL(
                slot_capacity,
                IFNULL(
                  -1 * LAG(slot_capacity)
                    OVER (
                      PARTITION BY project_id, reservation_name
                      ORDER BY change_timestamp ASC, action ASC
                    ),
                  0)))
        WHEN "DELETE"
          THEN
            IF(
              LAG(action)
                OVER (
                  PARTITION BY project_id, reservation_name
                  ORDER BY change_timestamp ASC, action ASC
                )
                IN UNNEST(['CREATE', 'UPDATE']),
              -1 * slot_capacity,
              0)
        END
        AS baseline_slot_delta,
    FROM
      `region-us.INFORMATION_SCHEMA.RESERVATION_CHANGES`
    WHERE
      edition = edition_to_check
      AND change_timestamp <= end_time
  ),

  -- Convert the above to running total
  /*
  +---------------------+-------------------------+----------------+
  |  change_timestamp   | autoscale_current_slots | baseline_slots |
  +---------------------+-------------------------+----------------+
  | 2023-07-27 22:24:15 |                       0 |            300 |
  | 2023-07-27 22:25:21 |                     180 |            300 |
  | 2023-07-27 22:39:14 |                     100 |            300 |
  | 2023-07-27 22:40:20 |                     100 |            600 |
  | 2023-07-27 22:54:18 |                     220 |            600 |
  | 2023-07-27 22:55:23 |                     120 |            600 |
  */
  running_reservation_slot_data AS (
    SELECT
      change_timestamp,
      SUM(autoscale_current_slot_delta)
        OVER (ORDER BY change_timestamp RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
        AS autoscale_current_slots,
      SUM(baseline_slot_delta)
        OVER (ORDER BY change_timestamp RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
        AS baseline_slots,
    FROM
      reservation_slot_data
  ),

  /*
  The committed_slots change history. For example:
  +---------------------+------------------------+------------------+
  |  change_timestamp   | capacity_commitment_id | slot_count_delta |
  +---------------------+------------------------+------------------+
  | 2023-07-20 19:30:27 | 12954109101902401697   |              100 |
  | 2023-07-27 22:29:21 | 11445583810276646822   |              100 |
  | 2023-07-27 23:10:06 | 7341455530498381779    |              100 |
  */
  capacity_commitment_slot_data AS (
    SELECT
      change_timestamp,
      capacity_commitment_id,
      CASE
        WHEN action = "CREATE" OR action = "UPDATE"
          THEN
            IFNULL(
              IF(
                LAG(action)
                  OVER (
                    PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC
                  )
                  IN UNNEST(['CREATE', 'UPDATE']),
                slot_count - LAG(slot_count)
                  OVER (
                    PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC
                  ),
                slot_count),
              slot_count)
        ELSE
          IF(
            LAG(action)
              OVER (PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC)
              IN UNNEST(['CREATE', 'UPDATE']),
            -1 * slot_count,
            0)
        END
        AS slot_count_delta
    FROM
      `region-us.INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES_BY_PROJECT`
    WHERE
      state = "ACTIVE"
      AND edition = edition_to_check
      AND change_timestamp <= end_time
  ),

  /*
  The total_committed_slots history. For example:
  +---------------------+---------------+
  |  change_timestamp   | capacity_slot |
  +---------------------+---------------+
  | 2023-07-20 19:30:27 |           100 |
  | 2023-07-27 22:29:21 |           200 |
  | 2023-07-27 23:10:06 |           300 |
  */
  running_capacity_commitment_slot_data AS (
    SELECT
      change_timestamp,
      SUM(slot_count_delta)
        OVER (ORDER BY change_timestamp RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
        AS capacity_slot
    FROM
      capacity_commitment_slot_data
  ),

  /* Add next_change_timestamp to the above data,
   which will be used when joining with reservation data. For example:
  +---------------------+-----------------------+---------------+
  |  change_timestamp   | next_change_timestamp | capacity_slot |
  +---------------------+-----------------------+---------------+
  | 2023-07-20 19:30:27 |   2023-07-27 22:29:21 |           100 |
  | 2023-07-27 22:29:21 |   2023-07-27 23:10:06 |           200 |
  | 2023-07-27 23:10:06 |   2023-07-31 00:14:37 |           300 |
  */
  running_capacity_commitment_slot_data_with_next_change AS (
    SELECT
      change_timestamp,
      IFNULL(LEAD(change_timestamp) OVER (ORDER BY change_timestamp ASC), CURRENT_TIMESTAMP())
        AS next_change_timestamp,
      capacity_slot
    FROM
      running_capacity_commitment_slot_data
  ),

  /*
  Whenever we have a change in reservations or commitments,
  the scaled_slots_and_baseline_not_covered_by_commitments will be changed.
  Hence we get a collection of all the change_timestamp from both tables.
  +---------------------+
  |  change_timestamp   |
  +---------------------+
  | 2023-07-20 19:30:27 |
  | 2023-07-27 22:24:15 |
  | 2023-07-27 22:25:21 |
  | 2023-07-27 22:29:21 |
  | 2023-07-27 22:39:14 |
  | 2023-07-27 22:40:20 |
  | 2023-07-27 22:54:18 |
  | 2023-07-27 22:55:23 |
  | 2023-07-27 23:10:06 |
  */
  merged_timestamp AS (
    SELECT
      change_timestamp
    FROM
      running_reservation_slot_data
    UNION DISTINCT
    SELECT
      change_timestamp
    FROM
      running_capacity_commitment_slot_data
  ),

  /*
  Change running reservation-slots and make sure we have one row when commitment changes.
  +---------------------+-------------------------+----------------+
  |  change_timestamp   | autoscale_current_slots | baseline_slots |
  +---------------------+-------------------------+----------------+
  | 2023-07-20 19:30:27 |                       0 |              0 |
  | 2023-07-27 22:24:15 |                       0 |            300 |
  | 2023-07-27 22:25:21 |                     180 |            300 |
  | 2023-07-27 22:29:21 |                     180 |            300 |
  | 2023-07-27 22:39:14 |                     100 |            300 |
  | 2023-07-27 22:40:20 |                     100 |            600 |
  | 2023-07-27 22:54:18 |                     220 |            600 |
  | 2023-07-27 22:55:23 |                     120 |            600 |
  | 2023-07-27 23:10:06 |                     120 |            600 |
  */
  running_reservation_slot_data_with_merged_timestamp AS (
    SELECT
      change_timestamp,
      IFNULL(
        autoscale_current_slots,
        IFNULL(
          LAST_VALUE(autoscale_current_slots IGNORE NULLS) OVER (ORDER BY change_timestamp ASC), 0))
        AS autoscale_current_slots,
      IFNULL(
        baseline_slots,
        IFNULL(LAST_VALUE(baseline_slots IGNORE NULLS) OVER (ORDER BY change_timestamp ASC), 0))
        AS baseline_slots
    FROM
      running_reservation_slot_data
    RIGHT JOIN
      merged_timestamp
      USING (change_timestamp)
  ),

  /*
  Join the above, so that we will know the number for baseline not covered by commitments.
  +---------------------+-----------------------+-------------------------+------------------------------------+
  |  change_timestamp   | next_change_timestamp | autoscale_current_slots | baseline_not_covered_by_commitment |
  +---------------------+-----------------------+-------------------------+------------------------------------+
  | 2023-07-20 19:30:27 |   2023-07-27 22:24:15 |                       0 |                                  0 |
  | 2023-07-27 22:24:15 |   2023-07-27 22:25:21 |                       0 |                                200 |
  | 2023-07-27 22:25:21 |   2023-07-27 22:29:21 |                     180 |                                200 |
  | 2023-07-27 22:29:21 |   2023-07-27 22:39:14 |                     180 |                                100 |
  | 2023-07-27 22:39:14 |   2023-07-27 22:40:20 |                     100 |                                100 |
  | 2023-07-27 22:40:20 |   2023-07-27 22:54:18 |                     100 |                                400 |
  | 2023-07-27 22:54:18 |   2023-07-27 22:55:23 |                     220 |                                400 |
  | 2023-07-27 22:55:23 |   2023-07-27 23:10:06 |                     120 |                                400 |
  | 2023-07-27 23:10:06 |   2023-07-31 00:16:07 |                     120 |                                300 |
  */
  scaled_slots_and_baseline_not_covered_by_commitments AS (
    SELECT
      r.change_timestamp,
      IFNULL(LEAD(r.change_timestamp) OVER (ORDER BY r.change_timestamp ASC), CURRENT_TIMESTAMP())
        AS next_change_timestamp,
      r.autoscale_current_slots,
      IF(
        r.baseline_slots - IFNULL(c.capacity_slot, 0) > 0,
        r.baseline_slots - IFNULL(c.capacity_slot, 0),
        0) AS baseline_not_covered_by_commitment
    FROM
      running_reservation_slot_data_with_merged_timestamp r
    LEFT JOIN
      running_capacity_commitment_slot_data_with_next_change c
      ON
        r.change_timestamp >= c.change_timestamp
        AND r.change_timestamp < c.next_change_timestamp
  ),

  /*
  The slot_seconds between each changes. For example:
  +---------------------+--------------------+
  |  change_timestamp   | slot_seconds |
  +---------------------+--------------+
  | 2023-07-20 19:30:27 |            0 |
  | 2023-07-27 22:24:15 |        13400 |
  | 2023-07-27 22:25:21 |        91580 |
  | 2023-07-27 22:29:21 |       166320 |
  | 2023-07-27 22:39:14 |        13200 |
  | 2023-07-27 22:40:20 |       419500 |
  | 2023-07-27 22:54:18 |        40920 |
  | 2023-07-27 22:55:23 |       459160 |
  | 2023-07-27 23:10:06 |     11841480 |
  */
  slot_seconds_data AS (
    SELECT
      change_timestamp,
      GetSlotSecondsBetweenChanges(
        autoscale_current_slots + baseline_not_covered_by_commitment,
        UNIX_MILLIS(change_timestamp),
        UNIX_MILLIS(next_change_timestamp),
        UNIX_MILLIS(start_time),
        UNIX_MILLIS(end_time)) AS slot_seconds
    FROM
      scaled_slots_and_baseline_not_covered_by_commitments
    WHERE
      change_timestamp <= end_time AND next_change_timestamp > start_time
  )

/*
Final result for this example:
+--------------------+
| total_slot_seconds |
+--------------------+
|           13045560 |
*/
SELECT
  SUM(slot_seconds) AS total_slot_seconds
FROM
  slot_seconds_data

Monitorar a performance do job

Talvez seja necessário ajustar o max_slots de escalonamento automático para evitar custos mais altos. A consulta a seguir fornece contexto sobre a performance do job para que você possa escolher a quantidade correta de slots de escalonamento automático para sua carga de trabalho.

A consulta a seguir fornece detalhes sobre a performance anterior dos jobs das suas reservas:

SELECT
    AVG(TIMESTAMP_DIFF(end_time, creation_time, MILLISECOND)) as avg_latency_ms,
    SUM(total_bytes_processed) as total_bytes,
    COUNT(*) as query_numbers,
FROM
    `PROJECT_ID.region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION
WHERE creation_time >= START_TIME
    AND creation_time < END_TIME
    AND (statement_type != "SCRIPT" OR statement_type IS NULL)
    AND reservation_id = RESERVATION_ID

Substitua:

• PROJECT_ID: o ID do projeto
• REGION_NAME: a região do projeto;
• START_TIME: o horário de criação em que você quer começar a visualizar os dados
• END_TIME: o horário de criação em que você quer parar de visualizar os dados
• RESERVATION_ID: o ID da reserva

O exemplo a seguir recebe os detalhes do job em um período de cinco dias:

SELECT
    AVG(TIMESTAMP_DIFF(end_time, creation_time, MILLISECOND)) as avg_latency_ms,
    SUM(total_bytes_processed) as total_bytes,
    COUNT(*) as query_numbers,
FROM
    `myproject.region-us`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION
WHERE creation_time >= '2024-06-25 00:00:00-07'
    AND creation_time < '2024-06-30 00:00:00-07'
    AND (statement_type != "SCRIPT" OR statement_type IS NULL)
    AND reservation_id = reservationID

Cotas

A soma do tamanho máximo da reserva não pode exceder sua cota de slots.

Para mais informações sobre cotas, consulte Cotas e limites.

A seguir

• Para mais informações sobre as edições do BigQuery, consulte Introdução ao BigQuery.
• Para saber mais sobre slots, consulte Entender os slots.
• Para mais informações sobre reservas, consulte Introdução às reservas.