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

Este documento descreve as janelas de retenção de dados de viagem no tempo e segurança para conjuntos de dados. Durante os períodos de viagem no tempo e de segurança, os dados que alterou ou eliminou em qualquer tabela no conjunto de dados continuam a ser armazenados caso precise de os recuperar.

Viagem no tempo e retenção de dados

Pode aceder aos dados alterados ou eliminados a partir de qualquer ponto na janela de viagem no tempo, que abrange os últimos sete dias por predefinição. A viagem no tempo permite-lhe consultar dados que foram atualizados ou eliminados, restaurar uma tabela ou um conjunto de dados que foi eliminado, ou restaurar uma tabela que expirou.

Pode definir a duração do período de viagem no tempo, de um mínimo de dois dias a um máximo de sete dias. Um período de viagem no tempo mais longo é útil nos casos em que é importante poder recuperar dados atualizados ou eliminados. Um período de deslocação mais curto permite-lhe poupar nos custos de armazenamento quando usa o modelo de faturação de armazenamento físico. Estas poupanças não se aplicam quando usa o modelo de faturação de armazenamento lógico. Para mais informações sobre como o modelo de faturação do armazenamento afeta o custo, consulte a secção Faturação.

Configure a janela de viagem no tempo

Define o período de viagem no tempo ao nível do conjunto de dados ou do projeto. Estas definições aplicam-se a todas as tabelas associadas ao conjunto de dados ou ao projeto.

Defina o período de viagem no tempo ao nível do projeto

Para especificar o período de viagem no tempo predefinido ao nível do projeto, pode usar declarações de linguagem de definição de dados (LDD). Para saber como definir o período de deslocação no tempo ao nível do projeto, consulte o artigo Faça a gestão das definições de configuração.

Defina o intervalo de viagem no tempo ao nível do conjunto de dados

Para especificar ou modificar o período de viagem no tempo de um conjunto de dados, pode usar a Google Cloud consola, a ferramenta de linha de comandos bq ou a API BigQuery.

Quando modifica um período de viagem no tempo, se a data/hora especificar uma hora fora do período de viagem no tempo ou anterior à criação da tabela, a consulta falha e devolve um erro semelhante ao seguinte:

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. Isto significa que os dados são organizados e armazenados por coluna, em vez de por linha. Quando tem uma tabela com várias colunas, os valores de cada coluna em todas as linhas são armazenados em conjunto em blocos de armazenamento.

Quando modifica uma célula numa tabela do BigQuery, está a alterar um valor específico numa linha específica e numa coluna específica. Uma vez que o BigQuery armazena as colunas em conjunto, a modificação de uma única célula numa coluna requer normalmente a leitura de todo o bloco de armazenamento que contém os dados dessa coluna para as linhas afetadas, a aplicação da alteração e, em seguida, a escrita de uma nova versão desse bloco de armazenamento.

A funcionalidade de viagem no tempo funciona através da monitorização das versões dos blocos de armazenamento que compõem a sua tabela. Quando atualiza dados, o BigQuery não se limita a modificar o bloco de armazenamento existente no local. Em vez disso, 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 ficheiros e blocos de armazenamento adaptáveis. O tamanho dos blocos de armazenamento não é fixo, mas pode variar consoante fatores como o tamanho da tabela e a respetiva distribuição de dados. A alteração de apenas uma célula num bloco de armazenamento altera os dados dessa coluna, o que pode afetar muitas linhas. Por conseguinte, a unidade de dados com controlo de versões e enviada para a viagem no tempo é frequentemente o bloco de armazenamento completo que contém os dados modificados dessa coluna e não apenas uma única célula.

Por este motivo, a alteração de uma célula pode resultar no envio de mais dados para a análise de séries temporais do que apenas o tamanho da alteração.

Como o período de viagem no tempo afeta a recuperação de tabelas e conjuntos de dados

Uma tabela ou um conjunto de dados eliminados usa a duração do período de viagem no tempo que estava em vigor no momento da eliminação.

Por exemplo, se tiver uma duração do período de viagem no tempo de dois dias e, em seguida, aumentar a duração para sete dias, as tabelas eliminadas antes dessa alteração continuam a ser recuperáveis apenas durante dois dias. Da mesma forma, se tiver uma duração do período de viagem no tempo de cinco dias e reduzir essa duração para três dias, todas as tabelas eliminadas antes da alteração continuam a ser recuperáveis durante cinco dias.

Uma vez que os intervalos de viagem no tempo são definidos ao nível do conjunto de dados, não pode alterar o intervalo de viagem no tempo de um conjunto de dados eliminado até que a eliminação seja anulada.

Se reduzir a duração do período de viagem no tempo, eliminar uma tabela e, em seguida, perceber que precisa de um período de capacidade de recuperação mais longo para esses dados, pode criar uma captura instantânea da tabela a partir de um ponto no tempo anterior à eliminação da tabela. Tem de o fazer enquanto a tabela eliminada ainda for recuperável. Para mais informações, consulte o artigo Crie uma captura instantânea de uma tabela com a funcionalidade de viagem no tempo.

Viagem no tempo e acesso ao nível da linha

Se uma tabela tiver ou tiver tido políticas de acesso ao nível da linha, apenas um administrador da tabela pode aceder aos dados do histórico da tabela.

É necessária a seguinte autorização de Identity and Access Management (IAM):

Autorização Recurso
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions A tabela cujos dados do histórico estão a ser acedidos

A seguinte função do BigQuery fornece a autorização necessária:

Role Recurso
roles/bigquery.admin A tabela cujos dados do histórico estão a ser acedidos

Não é possível adicionar a autorização bigquery.rowAccessPolicies.overrideTimeTravelRestrictions a uma função personalizada.

  • Execute o seguinte comando para obter a hora de época Unix equivalente transmitindo a indicação de tempo UTC:

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

  • Substitua a hora da época UNIX 1691164834000 recebida do comando anterior na ferramenta de linhas de comando bq. Execute o seguinte comando para restaurar uma cópia da tabela eliminada deletedTableID noutra tabela restoredTable, no mesmo conjunto de dados myDatasetID:

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

Seguro em caso de falha

O BigQuery oferece um período de segurança. Durante o período de segurança, os dados eliminados são automaticamente retidos durante mais sete dias após o período de reversão no tempo, para que os dados estejam disponíveis para recuperação de emergência. Os dados são recuperáveis ao nível da tabela. Os dados são recuperados para uma tabela a partir do ponto no tempo representado pela data/hora em que essa tabela foi eliminada. O período de segurança não é configurável.

Quando realiza as seguintes operações, os dados substituídos ou removidos podem ser recuperados através da janela de viagem no tempo. Após o período de deslocação no tempo, estes dados entram no período de segurança para o tempo de recuperação prolongado:

  • Eliminação ou substituição de tabelas: quando uma tabela é eliminada, ou quando os respetivos dados são totalmente substituídos (por exemplo, através da WRITE_TRUNCATE disposição de gravação num trabalho de carregamento ou através da CREATE OR REPLACE TABLE declaração), o conteúdo anterior da tabela é retido.
  • Eliminação de partições: se uma partição específica for eliminada de uma tabela particionada, os dados pertencentes a essa partição específica são retidos. As outras partições na tabela não são afetadas.

Não pode consultar nem recuperar diretamente dados no armazenamento à prova de falhas. Para recuperar dados do armazenamento de segurança, contacte o apoio ao cliente do Google Cloud.

Faturação

Se definir o modelo de faturação de armazenamento para usar bytes físicos, a faturação dos bytes usados para a viagem no tempo e o armazenamento à prova de falhas é feita separadamente. O armazenamento de viagem no tempo e à prova de falhas é cobrado à taxa de armazenamento físico ativo. Pode configurar o período de tempo de viagem no tempo para equilibrar os custos de armazenamento com as suas necessidades de retenção de dados.

Se definir o modelo de faturação do armazenamento para usar bytes lógicos, os custos totais de armazenamento para a viagem no tempo e o armazenamento à prova de falhas estão incluídos na taxa base que lhe é cobrada.

A tabela seguinte mostra uma comparação dos custos de armazenamento físico e lógico:

Modelo de faturação O que paga?
Armazenamento físico (comprimido)
  • Paga pelos bytes ativos
  • Paga pelo armazenamento a longo prazo
  • Paga o armazenamento de viagens no tempo
  • Paga pelo armazenamento à prova de falhas
Armazenamento lógico (não comprimido) (predefinição)
  • Paga pelo armazenamento ativo
  • Paga pelo armazenamento a longo prazo
  • Não paga pelo armazenamento de viagens no tempo
  • Não paga pelo armazenamento à prova de falhas

Se usar o armazenamento físico, pode ver os bytes usados pela viagem no tempo e pelo modo de segurança consultando as colunas TIME_TRAVEL_PHYSICAL_BYTES e FAIL_SAFE_PHYSICAL_BYTES nas vistas TABLE_STORAGE e TABLE_STORAGE_BY_ORGANIZATION. Para ver um exemplo de como usar uma destas vistas para estimar os seus custos, consulte Previsão da faturação do armazenamento.

Aplicam-se custos de armazenamento para a funcionalidade de viagem no tempo e os dados à prova de falhas, mas a faturação só é feita se as taxas de armazenamento de dados não se aplicarem noutro local no BigQuery. Aplicam-se os seguintes detalhes:

  • Quando uma tabela é criada, não existe custo de armazenamento de viagem no tempo nem de segurança.
  • Se os dados forem alterados ou eliminados, é-lhe cobrado o armazenamento dos dados alterados ou eliminados guardados pela viagem no tempo durante o período da viagem no tempo e o período de segurança. Isto é semelhante aos preços de armazenamento para instantâneos e clones de tabelas.

Exemplo de retenção de dados

A tabela seguinte mostra como os dados eliminados ou alterados se movem entre os períodos 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 eliminados com um período de reversão de sete dias:

Dia 0 Dia 1 Dia 2 Dia 3 Dia 4 Dia 5 Dia 6 Dia 7 Dia 8 Dia 9 Dia 10 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 viagens no tempo 50 50 50 50 50 50 50
Armazenamento à prova de falhas 50 50 50 50 50 50 50

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

Limitações

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

O que se segue?