Retenção de dados com viagem no tempo e segurança contra falhas

Neste documento, descrevemos a janela de retenção de dados viagem no tempo e segurança contra falhas para conjuntos de dados. Durante a viagem no tempo e os períodos de segurança contra falhas, os dados que você alterou ou excluiu em qualquer tabela no conjunto de dados continuam sendo armazenados caso seja necessário recuperá-los.

Viagem no tempo e retenção de dados

É possível acessar dados alterados ou excluídos de qualquer ponto na janela de viagem no tempo, que abrange os últimos sete dias. Com a viagem no tempo, é possível consultar dados que foram atualizados ou excluídos, restaurar uma tabela ou conjunto de dados que foi excluída, restaurar uma tabela que expirou, ou restaurar uma tabela para um ponto no tempo.

Você pode definir a duração da janela de viagem no tempo, de um mínimo de dois dias até um máximo de sete dias. Uma janela de viagem no tempo mais longa é útil nos casos em que é importante poder recuperar dados atualizados ou excluídos. Uma janela de viagem no tempo mais curta permite economizar em custos de armazenamento ao utilizar o modelo de faturamento de armazenamento físico. Essa economia não se aplica ao uso do modelo de faturamento do armazenamento lógico. Para mais informações sobre como o modelo de faturamento de armazenamento afeta o custo, consulte Faturamento. Não é possível definir a duração da viagem no tempo por menos de dois dias.

Configurar a janela de viagem no tempo

Você define a janela de viagem no tempo no nível do conjunto de dados ou do projeto. Essas configurações são aplicadas a todas as tabelas associadas ao conjunto de dados ou ao projeto.

Definir a janela de viagem no tempo para envolvidos no projeto

Para especificar a janela de viagem no tempo padrão para envolvidos no projeto, use instruções da linguagem de definição de dados (DDL, na sigla em inglês). Para saber como definir a janela de viagem no tempo para envolvidos no projeto, consulte Gerenciar configurações.

Definir a janela de viagem no tempo no nível do conjunto de dados

Para especificar ou modificar a janela de viagem no tempo de um conjunto de dados, use o Google Cloud console, a ferramenta de linha de comando bq ou a API BigQuery.

Ao modificar uma janela de viagem no tempo, se o carimbo de data/hora especificar um horário fora da janela de viagem no tempo ou de antes da criação da tabela, a consulta falhará e retornará um erro como este:

Table ID was created at time which is
before its allowed time travel interval timestamp. Creation
time: timestamp

Como funciona a viagem no tempo

O BigQuery usa um formato de armazenamento em colunas. Isso significa que os dados são organizados e armazenados por coluna, em vez de por linha. Quando você tem uma tabela com várias colunas, os valores de cada coluna em todas as linhas são armazenados juntos em blocos de armazenamento.

Ao modificar uma célula em uma tabela do BigQuery, você está mudando um valor específico em uma linha e coluna específicas. Como o BigQuery armazena colunas juntas, modificar até mesmo uma única célula em uma coluna geralmente exige a leitura de todo o bloco de armazenamento que contém os dados dessa coluna para as linhas afetadas, a aplicação da mudança e a gravação de uma nova versão desse bloco de armazenamento.

O recurso de viagem no tempo funciona rastreando as versões dos blocos de armazenamento que compõem a tabela. Quando você atualiza os dados, o BigQuery não modifica apenas o bloco de armazenamento atual. Em vez disso, ele cria uma nova versão dos blocos de armazenamento afetados com os dados atualizados. A versão anterior é mantida para fins de viagem no tempo.

O BigQuery usa tamanhos de arquivo e blocos de armazenamento adaptáveis. O tamanho dos blocos de armazenamento não é fixo, mas pode variar dependendo de fatores como o tamanho da tabela e a distribuição de dados. Mudar até mesmo uma célula em um bloco de armazenamento altera os dados dessa coluna, afetando potencialmente muitas linhas. Portanto, a unidade de dados versionada e enviada para a viagem no tempo geralmente é todo o bloco de armazenamento que contém os dados modificados dessa coluna, não apenas uma única célula.

Por esse motivo, mudar uma célula pode resultar no envio de mais dados para a viagem no tempo do que apenas o tamanho da mudança.

Como a janela de viagem no tempo afeta a recuperação de tabelas e conjuntos de dados

Uma tabela ou conjunto de dados excluído usa a duração da janela de viagem no tempo que estava em vigor no momento da exclusão.

Por exemplo, se você tiver uma duração de janela de viagem de dois dias e aumentar a duração para sete dias, as tabelas excluídas antes dessa alteração ainda poderão ser recuperadas por dois dias. Da mesma forma, se você tiver uma duração de janela de viagem de cinco dias e reduzir para três dias, todas as tabelas excluídas antes da alteração ainda poderão ser recuperadas por cinco dias.

Como as janelas de viagem no tempo são definidas no nível do conjunto de dados, não é possível alterar a janela de viagem no tempo de um conjunto de dados excluído até que a exclusão seja cancelada.

Se você reduzir a duração da janela de viagem no tempo, excluir uma tabela e perceber que precisa de um período mais longo para recuperar esses dados, poderá criar um snapshot da tabela a partir de um momento anterior à exclusão da tabela. Faça isso enquanto a tabela excluída ainda puder ser recuperada. Para mais informações, consulte Criar um snapshot da tabela usando a viagem no tempo.

Viagem no tempo e acesso no nível da linha

Se uma tabela tiver ou teve políticas de acesso no nível da linha, somente um administrador poderá acessar os dados históricos da tabela. A permissão do Identity and Access Management (IAM) a seguir é necessária para restaurar tabelas com políticas de acesso à linha:

Permissão Recurso
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions A tabela cujos dados históricos estão sendo acessados

Não é possível adicionar a permissão bigquery.rowAccessPolicies.overrideTimeTravelRestrictions a uma função personalizada. Os papéis a seguir fornecem a permissão necessária:

Papel Recurso
roles/bigquery.admin A tabela cujos dados históricos estão sendo acessados
roles/bigquery.studioAdmin A tabela cujos dados históricos estão sendo acessados
roles/iam.databasesAdmin A tabela cujos dados históricos estão sendo acessados

  • Execute o comando a seguir para mostrar o horário da época Unix equivalente transmitindo o carimbo de data/hora UTC:

    date -d '2023-08-04 16:00:34.456789Z' +%s000

  • Substitua o do horário de época do UNIX 1691164834000 recebido do comando anterior na ferramenta de linha de comando bq. Execute o seguinte comando para restaurar uma cópia da tabela excluída deletedTableID em outra tabela restoredTable, no mesmo conjunto de dados myDatasetID:

    bq cp myProjectID:myDatasetID.deletedTableID@1691164834000 myProjectID:myDatasetID.restoredTable

Segurança contra falhas

O BigQuery oferece um período de segurança contra falhas. Durante esse período, os dados excluídos são retidos automaticamente por mais sete dias após a janela de viagem no tempo para que eles fiquem disponíveis em caso de uma recuperação de emergência. Os dados podem ser recuperados no nível da tabela. Os dados de uma tabela são recuperados a partir do momento representado pelo carimbo de data/hora de quando essa tabela foi excluída. O período de segurança contra falhas não é configurável e não pode ser estendido.

Ao realizar as operações a seguir, os dados substituídos ou removidos podem ser recuperados pela janela de viagem no tempo. Após o término da janela de viagem no tempo, esses dados entram no período de segurança contra falhas para um tempo de recuperação estendido:

  • Exclusão ou substituição de tabelas:quando uma tabela é excluída ou quando os dados são totalmente substituídos (por exemplo, usando a disposição de gravação WRITE_TRUNCATE em um job de carregamento ou usando a instrução CREATE OR REPLACE TABLE ), o conteúdo anterior da tabela é mantido.
  • Exclusão de partições:se uma partição específica for excluída de uma tabela particionada, os dados pertencentes a essa partição específica serão mantidos. Outras partições na tabela não são afetadas.

Não é possível consultar ou recuperar dados diretamente no armazenamento com segurança contra falhas. Para recuperar dados do armazenamento com segurança contra falhas, entre em contato com o Cloud Customer Care.

Faturamento

Se você definir o modelo de faturamento de armazenamento para usar bytes físicos, será cobrado separadamente pelos bytes usados para viagem no tempo e armazenamento com segurança contra falhas. O tempo de deslocamento e o armazenamento com proteção contra falhas são cobrados de acordo com a taxa de armazenamento físico ativo. É possível configurar a janela de tempo para equilibrar os custos de armazenamento com as necessidades de retenção de dados.

Se você definir o modelo de faturamento de armazenamento para usar bytes lógicos, os custos totais de armazenamento para viagem no tempo e armazenamento com segurança contra falhas serão incluídos na taxa básica cobrada.

A tabela a seguir mostra uma comparação entre os custos de armazenamento físico e lógico:

Modelo de faturamento Pelo que você paga?
Armazenamento físico (compactado)
  • Você paga por bytes ativos
  • Você paga pelo armazenamento de longo prazo
  • Você paga pelo armazenamento de viagens no tempo
  • Você paga pelo armazenamento à prova de falhas
Armazenamento lógico (não compactado) (configuração padrão)
  • O armazenamento ativo é pago
  • Você paga pelo armazenamento de longo prazo
  • Você não paga pelo armazenamento de viagens no tempo
  • Você não paga pelo armazenamento à prova de falhas

No armazenamento físico, é possível conferir os bytes usados pela viagem no tempo e usar um método de segurança contra falhas nas colunas TIME_TRAVEL_PHYSICAL_BYTES e FAIL_SAFE_PHYSICAL_BYTES nas visualizações TABLE_STORAGE e TABLE_STORAGE_BY_ORGANIZATION. Para um exemplo de como usar uma dessas visualizações para estimar seus custos, consulte Faturamento de armazenamento de previsão.

Os custos de armazenamento se aplicam a dados de viagem no tempo e à prova de falhas, mas você só vai receber cobranças se as taxas de armazenamento de dados não forem aplicadas em outro lugar no BigQuery. Os seguintes detalhes se aplicam:

  • Quando uma tabela é criada, não há custo de viagem no tempo ou armazenamento com segurança contra falhas.
  • Se os dados forem alterados ou excluídos, a cobrança será feita pelo armazenamento dos dados alterados ou excluídos salvos pela viagem no tempo durante a janela de viagem no tempo e o período de segurança contra falhas. Isso é semelhante ao preço de armazenamento para snapshots e clones de tabelas.
  • Tabelas temporárias não são cobradas pelo armazenamento com segurança contra falhas.

Exemplo de retenção de dados

A tabela a seguir mostra como os dados excluídos ou alterados são transferidos entre janelas de retenção de armazenamento. Este exemplo mostra uma situação em que o armazenamento ativo total é de 200 GiB e 50 GiB são excluídos com uma janela de viagem no tempo de sete dias:

Dia 0 1º dia Dia 2 3º dia Dia 4 5º dia Dia 6 Dia 7 8º dia Dia 9 10º dia Dia 11 Dia 12 Dia 13 Dia 14 Dia 15
Armazenamento ativo 200 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
Armazenamento de viagem no tempo 50 50 50 50 50 50 50
Armazenamento à prova de falhas 50 50 50 50 50 50 50

A exclusão de dados do armazenamento físico de longo prazo funciona da mesma forma.

Limitações

A recuperação de dados com a viagem no tempo está sujeita às seguintes limitações:

A seguir