Conservación de datos con viajes en el tiempo y a prueba de fallos

En este documento se describen los periodos de conservación de datos de viaje en el tiempo y protección contra fallos de los conjuntos de datos. Durante los periodos de viaje en el tiempo y de seguridad, los datos que hayas cambiado o eliminado de cualquier tabla del conjunto de datos se seguirán almacenando por si necesitas recuperarlos.

Viaje en el tiempo y conservación de datos

Puedes acceder a los datos modificados o eliminados desde cualquier punto de la ventana de viaje en el tiempo, que abarca los últimos siete días de forma predeterminada. La función de viaje en el tiempo te permite consultar datos que se hayan actualizado o eliminado, restaurar una tabla o un conjunto de datos que se haya eliminado, o restaurar una tabla que haya caducado.

Puedes definir la duración de la ventana de viaje en el tiempo, que puede ser de entre dos y siete días. Una ventana de viaje en el tiempo más larga es útil en los casos en los que es importante poder recuperar datos actualizados o eliminados. Si reduces el periodo de tiempo, puedes ahorrar en costes de almacenamiento cuando utilices el modelo de facturación de almacenamiento físico. Estos ahorros no se aplican cuando se usa el modelo de facturación de almacenamiento lógico. Para obtener más información sobre cómo afecta el modelo de facturación del almacenamiento al coste, consulta la sección Facturación.

Configurar la ventana de viaje en el tiempo

El periodo de retroceso en el tiempo se define a nivel de conjunto de datos o de proyecto. Estos ajustes se aplican a todas las tablas asociadas al conjunto de datos o al proyecto.

Definir el periodo de viaje en el tiempo a nivel de proyecto

Para especificar el periodo predeterminado de viaje en el tiempo a nivel de proyecto, puedes usar instrucciones del lenguaje de definición de datos (DDL). Para saber cómo definir la ventana de viaje en el tiempo a nivel de proyecto, consulta Gestionar ajustes de configuración.

Definir el periodo de viaje en el tiempo a nivel del conjunto de datos

Para especificar o modificar el periodo de viaje en el tiempo de un conjunto de datos, puedes usar la consolaGoogle Cloud , la herramienta de línea de comandos bq o la API de BigQuery.

Cuando se modifica un intervalo de viaje en el tiempo, si la marca de tiempo especifica una hora fuera del intervalo o anterior a la creación de la tabla, la consulta falla y devuelve un error como el siguiente:

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

Cómo funciona la función de viajes en el tiempo

BigQuery usa un formato de almacenamiento en columnas. Esto significa que los datos se organizan y almacenan por columnas en lugar de por filas. Cuando tienes una tabla con varias columnas, los valores de cada columna de todas las filas se almacenan juntos en bloques de almacenamiento.

Cuando modificas una celda de una tabla de BigQuery, cambias un valor específico de una fila y una columna concretas. Como BigQuery almacena las columnas juntas, para modificar incluso una sola celda de una columna, normalmente es necesario leer todo el bloque de almacenamiento que contiene los datos de esa columna en las filas afectadas, aplicar el cambio y, a continuación, escribir una nueva versión de ese bloque de almacenamiento.

La función de viaje en el tiempo funciona monitorizando las versiones de los bloques de almacenamiento que componen tu tabla. Cuando actualizas datos, BigQuery no se limita a modificar el bloque de almacenamiento en el mismo lugar. En su lugar, crea una nueva versión de los bloques de almacenamiento afectados con los datos actualizados. La versión anterior se conserva para poder volver a ella.

BigQuery usa tamaños de archivo y bloques de almacenamiento adaptativos. El tamaño de los bloques de almacenamiento no es fijo, sino que puede variar en función de factores como el tamaño de la tabla y la distribución de sus datos. Si se cambia aunque solo sea una celda de un bloque de almacenamiento, se modifican los datos de esa columna, lo que puede afectar a muchas filas. Por lo tanto, la unidad de datos que se versiona y se envía a la función de viaje en el tiempo suele ser todo el bloque de almacenamiento que contiene los datos modificados de esa columna, no solo una celda.

Por este motivo, si se cambia una celda, se pueden enviar más datos a la función de viajes en el tiempo que el tamaño del cambio.

Cómo afecta el periodo de viaje en el tiempo a la recuperación de tablas y conjuntos de datos

Una tabla o un conjunto de datos eliminados usan la duración del periodo de recuperación que estaba vigente en el momento de la eliminación.

Por ejemplo, si tienes una ventana de viaje en el tiempo de dos días y luego aumentas la duración a siete días, las tablas eliminadas antes de ese cambio solo se podrán recuperar durante dos días. Del mismo modo, si tienes una ventana de viaje en el tiempo de cinco días y la reduces a tres, las tablas que se hayan eliminado antes del cambio se podrán recuperar durante cinco días.

Como las ventanas de retroceso en el tiempo se definen a nivel del conjunto de datos, no puedes cambiar la ventana de retroceso en el tiempo de un conjunto de datos eliminado hasta que se restaure.

Si reduces la duración de la ventana de viaje en el tiempo, eliminas una tabla y te das cuenta de que necesitas un periodo de recuperación más largo para esos datos, puedes crear una instantánea de la tabla desde un momento anterior a la eliminación de la tabla. Debes hacerlo mientras la tabla eliminada aún se pueda recuperar. Para obtener más información, consulta el artículo Crear una captura de una tabla con la función de viaje en el tiempo.

Viaje en el tiempo y acceso a nivel de fila

Si una tabla tiene o ha tenido políticas de acceso a nivel de fila, solo un administrador de la tabla puede acceder al historial de datos de la tabla.

Se requiere el siguiente permiso de Gestión de Identidades y Accesos (IAM):

Permiso Recurso
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions La tabla cuyo historial de datos se está consultando

El siguiente rol de BigQuery proporciona el permiso necesario:

Role Recurso
roles/bigquery.admin La tabla cuyo historial de datos se está consultando

El permiso bigquery.rowAccessPolicies.overrideTimeTravelRestrictions no se puede añadir a un rol personalizado.

  • Ejecuta el siguiente comando para obtener la hora de época de Unix equivalente pasando la marca de tiempo UTC:

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

  • Sustituye la hora de la época de UNIX 1691164834000 recibida del comando anterior en la herramienta de línea de comandos bq. Ejecuta el siguiente comando para restaurar una copia de la tabla deletedTableID eliminada en otra tabla restoredTable, dentro del mismo conjunto de datos myDatasetID:

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

A prueba de fallos

BigQuery ofrece un periodo de seguridad. Durante el periodo de seguridad, los datos eliminados se conservan automáticamente durante siete días más después del periodo de recuperación, de modo que estén disponibles para la recuperación de emergencia. Los datos se pueden recuperar a nivel de tabla. Los datos de una tabla se recuperan desde el momento representado por la marca de tiempo en la que se eliminó esa tabla. El periodo de seguridad no se puede configurar.

Cuando realizas las siguientes operaciones, los datos que se sustituyen o eliminan se pueden recuperar a través de la ventana de viaje en el tiempo. Una vez que finaliza el periodo de la ventana de viaje en el tiempo, estos datos entran en el periodo de seguridad para el tiempo de recuperación ampliado:

  • Eliminación o sustitución de tablas: cuando se elimina una tabla o cuando se sustituyen por completo sus datos (por ejemplo, mediante la disposición de escritura WRITE_TRUNCATE en un trabajo de carga o mediante la instrucción CREATE OR REPLACE TABLE ), se conservan los contenidos anteriores de la tabla.
  • Eliminación de particiones: si se elimina una partición específica de una tabla con particiones, se conservan los datos que pertenecen a esa partición. Las demás particiones de la tabla no se verán afectadas.

No puedes consultar ni recuperar datos directamente en el almacenamiento a prueba de fallos. Para recuperar datos del almacenamiento a prueba de fallos, ponte en contacto con Cloud Customer Care.

Facturación

Si configuras el modelo de facturación del almacenamiento para que use bytes físicos, se te cobrarán por separado los bytes usados para el viaje en el tiempo y el almacenamiento a prueba de fallos. El almacenamiento de viajes en el tiempo y a prueba de fallos se cobra según la tarifa de almacenamiento físico activo. Puedes configurar el periodo de la función de viaje en el tiempo para equilibrar los costes de almacenamiento con tus necesidades de conservación de datos.

Si configuras tu modelo de facturación de almacenamiento para que use bytes lógicos, los costes totales de almacenamiento de la función de viaje en el tiempo y del almacenamiento a prueba de fallos se incluirán en la tarifa base que se te cobre.

En la siguiente tabla se comparan los costes de almacenamiento físico y lógico:

Modelo de facturación ¿Qué es lo que pagas?
Almacenamiento físico (comprimido)
  • Pagas por los bytes activos
  • Pagas por el almacenamiento a largo plazo
  • Pagas por el almacenamiento de los viajes en el tiempo
  • Pagas por el almacenamiento a prueba de fallos
Almacenamiento lógico (sin comprimir) (configuración predeterminada)
  • Pagas por el almacenamiento activo
  • Pagas por el almacenamiento a largo plazo
  • No pagas por el almacenamiento de Time Travel
  • No tienes que pagar por el almacenamiento a prueba de fallos

Si utilizas almacenamiento físico, puedes ver los bytes utilizados por la función de viaje en el tiempo y la función de seguridad a prueba de fallos consultando las columnas TIME_TRAVEL_PHYSICAL_BYTES y FAIL_SAFE_PHYSICAL_BYTES de las vistas TABLE_STORAGE y TABLE_STORAGE_BY_ORGANIZATION. Para ver un ejemplo de cómo usar una de estas vistas para estimar tus costes, consulta Previsión de la facturación del almacenamiento.

Los costes de almacenamiento se aplican a los datos de viajes en el tiempo y a los de recuperación ante fallos, pero solo se te facturan si no se aplican tarifas de almacenamiento de datos en otras partes de BigQuery. Se aplican los siguientes detalles:

  • Cuando se crea una tabla, no hay costes de almacenamiento de viajes en el tiempo ni de almacenamiento a prueba de fallos.
  • Si los datos se modifican o se eliminan, se te cobrará por el almacenamiento de los datos modificados o eliminados guardados por la función de viaje en el tiempo durante el periodo de viaje en el tiempo y el periodo de seguridad. Es similar a los precios de almacenamiento de las copias y los clones de tablas.

Ejemplo de conservación de datos

En la siguiente tabla se muestra cómo se mueven los datos eliminados o modificados entre los periodos de retención del almacenamiento. En este ejemplo se muestra una situación en la que el almacenamiento activo total es de 200 GiB y se eliminan 50 GiB con un periodo de recuperación de siete días:

Día 0 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 Día 8 Día 9 Día 10 Día 11 Día 12 Día 13 Día 14 Día 15
Almacenamiento activo 200 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
Almacenamiento de viajes en el tiempo 50 50 50 50 50 50 50
Almacenamiento a prueba de fallos 50 50 50 50 50 50 50

La eliminación de datos del almacenamiento físico a largo plazo funciona de la misma forma.

Limitaciones

La recuperación de datos con la función de viaje en el tiempo está sujeta a las siguientes limitaciones:

Siguientes pasos