Automatización de copias de seguridad de BigQuery escalable

Last reviewed 2024-09-17 UTC

Esta arquitectura proporciona un marco y una implementación de referencia para ayudarte a desarrollar tu estrategia de copia de seguridad de BigQuery. Este marco recomendado y su automatización pueden ayudar a tu organización a hacer lo siguiente:

  • Cumple los objetivos de recuperación tras desastres de tu organización.
  • Recuperar datos que se hayan perdido debido a errores humanos.
  • Cumplir las normativas.
  • Mejorar la eficiencia operativa.

El ámbito de los datos de BigQuery puede incluir (o excluir) carpetas, proyectos, conjuntos de datos y tablas. Esta arquitectura recomendada muestra cómo automatizar las operaciones de copia de seguridad recurrentes a gran escala. Puedes usar dos métodos de copia de seguridad para cada tabla: instantáneas de BigQuery y exportaciones de BigQuery a Cloud Storage.

Este documento está dirigido a arquitectos de la nube, ingenieros y responsables de la gobernanza de datos que quieran definir y automatizar políticas de datos en sus organizaciones.

Arquitectura

En el siguiente diagrama se muestra la arquitectura de las copias de seguridad automáticas:

Arquitectura de la solución de copia de seguridad automatizada.

El flujo de trabajo que se muestra en el diagrama anterior incluye las siguientes fases:

  1. Cloud Scheduler activa una ejecución del servicio de distribución a través de un mensaje de Pub/Sub, que contiene el ámbito de los datos de BigQuery incluidos y excluidos. Las ejecuciones se programan mediante una expresión cron.
  2. El servicio de distribución, que se basa en Cloud Run, usa la API de BigQuery para enumerar las tablas que están dentro del ámbito de BigQuery.
  3. El servicio de distribuidor envía una solicitud por cada tabla al servicio de configuración a través de un mensaje de Pub/Sub.

  4. El servicio de configuración de Cloud Run calcula la política de copias de seguridad de la tabla a partir de una de las siguientes opciones definidas:

    1. La política a nivel de tabla, que definen los propietarios de los datos.
    2. La política alternativa, definida por el responsable de la gestión de datos, para las tablas que no tienen políticas definidas.

    Para obtener más información sobre las políticas de copia de seguridad, consulta Políticas de copia de seguridad.

  5. El servicio de configuración envía una solicitud por cada tabla al siguiente servicio, en función de la política de copia de seguridad calculada.

  6. En función del método de copia de seguridad, uno de los siguientes servicios personalizados de Cloud Run envía una solicitud a la API de BigQuery y ejecuta el proceso de copia de seguridad:

    1. El servicio de las copias de la tabla de BigQuery crea una copia de seguridad de la tabla en forma de copia de la tabla.
    2. El servicio de exportación de datos crea una copia de seguridad de la tabla como una exportación de datos a Cloud Storage.

  7. Cuando el método de copia de seguridad es la exportación de datos de una tabla, un receptor de registro de Cloud Logging monitoriza los eventos de finalización de los trabajos de exportación para habilitar la ejecución asíncrona del paso siguiente.

  8. Una vez que los servicios de copia de seguridad completen sus operaciones, Pub/Sub activará el servicio de etiquetado.

  9. En cada tabla, el servicio de etiquetado registra los resultados de los servicios de copia de seguridad y actualiza el estado de la copia de seguridad en la capa de metadatos de Cloud Storage.

Productos usados

Esta arquitectura de referencia usa los siguientes Google Cloud productos:

  • BigQuery: un almacén de datos empresariales que te ayuda a gestionar y analizar tus datos con funciones integradas como el aprendizaje automático, el análisis geoespacial y la inteligencia empresarial.
  • Cloud Logging: un sistema de gestión de registros en tiempo real con funciones de almacenamiento, búsqueda, análisis y alertas.
  • Pub/Sub: un servicio de mensajería asíncrono y escalable que desacopla los servicios que producen mensajes de los que los procesan.
  • Cloud Run: una plataforma de computación sin servidor que te permite ejecutar contenedores directamente en la infraestructura escalable de Google.
  • Cloud Storage: un almacén de objetos ilimitado y a un coste bajo para diversos tipos de datos. Se puede acceder a los datos desde dentro y fuera de Google Cloud, y se replican en varias ubicaciones para ofrecer redundancia.
  • Cloud Scheduler: un programador de tareas cron de nivel empresarial totalmente gestionado que te permite configurar unidades de trabajo programadas para que se ejecuten en horas definidas o a intervalos regulares.
  • Datastore: una base de datos NoSQL muy escalable que puedes usar con tus aplicaciones web y móviles.

Casos prácticos

En esta sección se proporcionan ejemplos de casos prácticos en los que puedes usar esta arquitectura.

Automatización de copias de seguridad

Por ejemplo, tu empresa puede operar en un sector regulado y usar BigQuery como almacén de datos principal. Aunque tu empresa siga las prácticas recomendadas en desarrollo de software, revisión de código e ingeniería de lanzamientos, sigue habiendo riesgo de pérdida o corrupción de datos debido a errores humanos. En un sector regulado, debe minimizar este riesgo en la medida de lo posible.

Estos son algunos ejemplos de errores humanos:

  • Eliminación accidental de tablas.
  • Datos dañados debido a una lógica errónea en la canalización de datos.

Estos tipos de errores humanos suelen resolverse con la función Viaje en el tiempo, que te permite recuperar datos de hace hasta siete días. Además, BigQuery también ofrece un periodo de seguridad, durante el cual los datos eliminados se conservan en el almacenamiento de seguridad durante siete días más después del periodo de viaje en el tiempo. Esos datos están disponibles para la recuperación de emergencia a través de Cloud Customer Care. Sin embargo, si su empresa no detecta ni corrige estos errores en este plazo combinado, los datos eliminados ya no se podrán recuperar desde su último estado estable.

Para evitarlo, te recomendamos que hagas copias de seguridad periódicas de las tablas de BigQuery que no se puedan reconstruir a partir de los datos de origen (por ejemplo, registros históricos o KPIs con una lógica empresarial en constante evolución).

Tu empresa podría usar secuencias de comandos básicas para crear copias de seguridad de decenas de tablas. Sin embargo, si necesitas crear copias de seguridad de cientos o miles de tablas de toda la organización con regularidad, necesitas una solución de automatización escalable que pueda hacer lo siguiente:

  • Gestionar los diferentes límites de la API. Google Cloud
  • Proporciona un marco de trabajo estandarizado para definir políticas de copias de seguridad.
  • Proporcionar transparencia y funciones de monitorización para las operaciones de copia de seguridad.

Políticas de copias de seguridad

Es posible que tu empresa también requiera que las políticas de copia de seguridad las definan los siguientes grupos de personas:

  • Los propietarios de los datos, que son quienes mejor conocen las tablas y pueden definir las políticas de copia de seguridad a nivel de tabla adecuadas.
  • El equipo de gobierno de datos, que se encarga de que haya una política de respaldo para cubrir las tablas que no tengan una política a nivel de tabla. La política de respaldo asegura que se creen copias de seguridad de determinados conjuntos de datos, proyectos y carpetas para cumplir las normativas de conservación de datos de tu empresa.

En la implementación de esta arquitectura de referencia, hay dos formas de definir las políticas de copias de seguridad de las tablas, y se pueden usar juntas:

  • Configuración del propietario de los datos (descentralizada): una política de copia de seguridad a nivel de tabla que se adjunta manualmente a una tabla.

    • El propietario de los datos define un archivo JSON a nivel de tabla que se almacena en un segmento común.
    • Las políticas manuales tienen prioridad sobre las políticas de respaldo cuando la solución determina la política de copia de seguridad de una tabla.
    • Para obtener más información sobre la implementación, consulta Definir políticas de copia de seguridad a nivel de tabla.

  • Configuración predeterminada de la organización (centralizada): una política de respaldo que solo se aplica a las tablas que no tienen políticas adjuntas manualmente.

    • Un equipo de gobierno de datos define un archivo JSON central en Terraform como parte de la solución.
    • La política de respaldo ofrece estrategias de copia de seguridad predeterminadas a nivel de carpeta, proyecto, conjunto de datos y tabla.
    • Para obtener más información sobre la implementación, consulta Definir políticas de copia de seguridad alternativas.

Copia de seguridad frente a replicación

El proceso de copia de seguridad crea una copia de los datos de la tabla en un momento determinado para que se puedan restaurar si se pierden o se dañan. Las copias de seguridad se pueden ejecutar una sola vez o de forma recurrente (mediante una consulta o un flujo de trabajo programados). En BigQuery, las copias de seguridad de un momento dado se pueden crear con instantáneas. Puedes usar las copias de los datos más allá del periodo de 7 días de la función de viaje en el tiempo en la misma ubicación de almacenamiento que los datos de origen. Las copias de BigQuery son especialmente útiles para recuperar datos después de errores humanos que provocan la pérdida o el daño de datos, en lugar de recuperarse de fallos regionales. BigQuery ofrece un objetivo de nivel de servicio (SLO) de entre el 99,9% y el 99,99%, según la edición.

Por el contrario, la replicación es el proceso continuo de copiar los cambios de la base de datos en una base de datos secundaria (o réplica) en otra ubicación. En BigQuery, la replicación entre regiones puede ayudar a proporcionar redundancia geográfica creando copias de solo lectura de los datos en Google Cloud regiones secundarias, que son diferentes de la región de datos de origen. Sin embargo, la replicación entre regiones de BigQuery no está diseñada para usarse como plan de recuperación tras fallos en situaciones de interrupción en una región completa. Para protegerte frente a desastres regionales, te recomendamos que uses la recuperación tras fallos gestionada de BigQuery.

La replicación interregional de BigQuery proporciona una copia de solo lectura sincronizada de los datos en una región cercana a los consumidores de datos. Estas copias de datos permiten realizar combinaciones en la misma ubicación y evitar el tráfico y los costes entre regiones. Sin embargo, en los casos de daños en los datos debido a errores humanos, la replicación por sí sola no puede ayudar con la recuperación, ya que los datos dañados se copian automáticamente en la réplica. En estos casos, las copias de seguridad de un momento dado (las instantáneas) son una mejor opción.

En la siguiente tabla se muestra una comparación resumida de los métodos de copia de seguridad y replicación:

Método Frecuencia Ubicación de almacenamiento Casos prácticos Costes
Copia de seguridad

(Capturas o exportación de Cloud Storage)		 Una sola vez o de forma recurrente Igual que los datos de la tabla de origen Restaurar los datos originales más allá del periodo de viaje en el tiempo Las instantáneas generan cargos de almacenamiento solo por los cambios en los datos de la instantánea.

Las exportaciones pueden generar cargos de almacenamiento estándar.

Consulta la sección Optimización de costes.
Replicación interregional Continuamente Remoto Crear una réplica en otra región

Migraciones únicas entre regiones		 Se aplican cargos por almacenar datos en la réplica.

Se aplican costes de replicación de datos.

Factores del diseño

En esta sección se ofrecen directrices que debes tener en cuenta al usar esta arquitectura de referencia para desarrollar una topología que cumpla tus requisitos específicos de seguridad, fiabilidad, optimización de costes, eficiencia operativa y rendimiento.

Seguridad, privacidad y cumplimiento

La implementación incorpora las siguientes medidas de seguridad en su diseño:

  • El ajuste de entrada de red de Cloud Run solo acepta tráfico interno para restringir el acceso desde Internet. También permite que solo los usuarios y las cuentas de servicio autenticados llamen a los servicios.
  • Cada servicio de Cloud Run y suscripción de Pub/Sub usa una cuenta de servicio independiente que solo tiene asignados los permisos necesarios. De esta forma, se mitigan los riesgos asociados al uso de una cuenta de servicio para el sistema y se sigue el principio de mínimos accesos.

Por motivos de privacidad, la solución no recoge ni trata información personal identificable (IPI). Sin embargo, si las tablas de origen tienen información personal identificable expuesta, las copias de seguridad de esas tablas también incluirán estos datos expuestos. El propietario de los datos de origen es responsable de proteger la información personal identificable (IPI) de las tablas de origen (por ejemplo, aplicando seguridad a nivel de columna, máscaras de datos o redacción). Las copias de seguridad solo son seguras si los datos de origen también lo son. Otra opción es asegurarse de que los proyectos, conjuntos de datos o contenedores que contengan datos de copia de seguridad con información personal identificable expuesta tengan las políticas de Gestión de Identidades y Accesos (IAM) necesarias para restringir el acceso solo a los usuarios autorizados.

Como solución de uso general, la implementación de referencia no tiene por qué cumplir los requisitos específicos de un sector concreto.

Fiabilidad

En esta sección se describen las funciones y las consideraciones de diseño para la fiabilidad.

Mitigación de errores con granularidad

Para crear copias de seguridad de miles de tablas, es probable que alcances los límites de la API de los productos subyacentes (por ejemplo, los límites de las operaciones snapshot y export de cada proyecto). Google Cloud Sin embargo, si la copia de seguridad de una tabla falla debido a un error de configuración u otros problemas transitorios, esto no debería afectar a la ejecución general ni a la capacidad de crear copias de seguridad de otras tablas.

Para mitigar posibles fallos, la implementación de referencia desacopla los pasos de procesamiento mediante servicios de Cloud Run granulares y los conecta a través de Pub/Sub. Si una solicitud de copia de seguridad de una tabla falla en el paso final del servicio de etiquetado, Pub/Sub vuelve a intentar solo este paso y no todo el proceso.

Dividir el flujo en varios servicios de Cloud Run, en lugar de en varios endpoints alojados en un solo servicio de Cloud Run, ayuda a proporcionar un control granular de la configuración de cada servicio. El nivel de configuración depende de las funciones del servicio y de las APIs con las que se comunica. Por ejemplo, el servicio de distribuidor se ejecuta una vez por cada ejecución, pero requiere una cantidad de tiempo considerable para enumerar todas las tablas del ámbito de la copia de seguridad de BigQuery. Por lo tanto, el servicio de envío requiere ajustes de tiempo de espera y memoria más altos. Sin embargo, el servicio Cloud Run para las copias de BigQuery se ejecuta una vez por tabla en una sola ejecución y se completa en menos tiempo que el servicio de distribución. Por lo tanto, el servicio Cloud Run requiere un conjunto de configuraciones diferente a nivel de servicio.

Coherencia de datos

La coherencia de los datos en las tablas y las vistas es fundamental para mantener una estrategia de copia de seguridad fiable. Como los datos se actualizan y modifican continuamente, las copias de seguridad realizadas en momentos diferentes pueden capturar estados distintos de tu conjunto de datos. Estas copias de seguridad en estados diferentes pueden provocar incoherencias al restaurar datos, sobre todo en el caso de las tablas que pertenecen al mismo conjunto de datos funcional. Por ejemplo, si restauras una tabla de ventas a un momento diferente al de su tabla de inventario correspondiente, podría haber una discrepancia en el stock disponible. Del mismo modo, las vistas de bases de datos que agregan datos de varias tablas pueden ser especialmente sensibles a las incoherencias. Si restauras estas vistas sin asegurarte de que las tablas subyacentes se encuentran en un estado coherente, podrías obtener resultados imprecisos o engañosos. Por lo tanto, al diseñar tus políticas y frecuencias de copia de seguridad de BigQuery, es fundamental tener en cuenta esta coherencia y asegurarte de que los datos restaurados reflejen con precisión el estado real de tu conjunto de datos en un momento dado.

Por ejemplo, en la implementación de esta arquitectura de referencia, la coherencia de los datos se controla mediante las dos configuraciones siguientes en las políticas de copia de seguridad. Estas configuraciones calculan la hora exacta de la instantánea de la tabla mediante desplazamiento en el tiempo, sin necesidad de crear copias de seguridad de todas las tablas al mismo tiempo.

  • backup_cron: controla la frecuencia con la que se crea una copia de seguridad de una tabla. La marca de tiempo de inicio de una ejecución se usa como punto de referencia para calcular el tiempo de todas las tablas de las que se ha creado una copia de seguridad en esta ejecución.
  • backup_time_travel_offset_days: controla cuántos días del pasado se deben restar del punto de referencia en el tiempo (hora de inicio de la ejecución) para calcular la versión de la tabla con el tiempo exacto.

Restauración de copias de seguridad automatizada

Aunque esta arquitectura de referencia se centra en la automatización de copias de seguridad a gran escala, también puedes restaurar estas copias de seguridad de forma automática. Esta automatización adicional puede ofrecer ventajas similares a las de la automatización de copias de seguridad, como una mayor eficiencia y velocidad de recuperación, con menos tiempo de inactividad. Como la solución registra todos los parámetros y resultados de las copias de seguridad a través del servicio de etiquetado, puedes desarrollar una arquitectura similar para aplicar las operaciones de restauración a gran escala.

Por ejemplo, puedes crear una solución basada en un activador bajo demanda que envíe un ámbito de datos de BigQuery a un servicio de distribución, que a su vez envíe una solicitud por tabla a un servicio de configuración. El servicio de configuración puede obtener el historial de copias de seguridad que quieras de una tabla concreta. A continuación, el servicio de configuración podría transferirlo a un servicio de restauración de instantáneas de BigQuery o a un servicio de restauración de Cloud Storage para aplicar la operación de restauración correspondiente. Por último, un servicio de etiquetado podría almacenar los resultados de estas operaciones en un almacén de estados. De esta forma, el marco de restauración automática puede beneficiarse de los mismos objetivos de diseño que el marco de copia de seguridad, que se detallan en este documento.

Optimización de costes

El marco de esta arquitectura proporciona políticas de copia de seguridad que definen los siguientes parámetros para optimizar los costes generales:

  • Método de copia de seguridad: el framework ofrece los dos métodos de copia de seguridad siguientes:
    • Las instantáneas de BigQuery, que generan costes de almacenamiento en función de los datos actualizados y eliminados en comparación con la tabla base. Por lo tanto, las capturas son más rentables para las tablas que solo admiten anexiones o que tienen actualizaciones limitadas.
    • Exportaciones de BigQuery a Cloud Storage, que incurren en cargos de almacenamiento estándar. Sin embargo, en el caso de las tablas grandes que siguen un enfoque de truncar y cargar, resulta más rentable hacer una copia de seguridad de ellas como exportaciones en clases de almacenamiento menos caras.
  • Vencimiento de la captura: se define el tiempo de vida (TTL) de una sola captura de tabla para evitar que se apliquen costes de almacenamiento a la captura de forma indefinida. Los costes de almacenamiento pueden aumentar con el tiempo si las tablas no tienen fecha de vencimiento.

Eficiencia operativa

En esta sección se describen las funciones y las consideraciones para la eficiencia operativa.

Políticas de copia de seguridad granulares y escalables

Uno de los objetivos de este marco es la eficiencia operativa, que se consigue aumentando la producción de la empresa y manteniendo los recursos relativamente bajos y fáciles de gestionar. Por ejemplo, la salida es un número elevado de tablas con copias de seguridad periódicas, mientras que la entrada es un número reducido de políticas y configuraciones de copias de seguridad mantenidas.

Además de permitir políticas de copia de seguridad a nivel de tabla, el marco también permite políticas a nivel de conjunto de datos, proyecto, carpeta y global. Esto significa que, con unas pocas configuraciones en niveles superiores (por ejemplo, a nivel de carpeta o proyecto), se pueden crear copias de seguridad de cientos o miles de tablas de forma periódica y a gran escala.

Observabilidad

Con un marco de automatización, es fundamental que conozcas los estados de los procesos. Por ejemplo, deberías poder encontrar la información de las siguientes consultas habituales:

  • La política de copia de seguridad que usa el sistema para cada tabla.
  • El historial de copias de seguridad y las ubicaciones de las copias de seguridad de cada tabla.
  • El estado general de una sola ejecución (el número de tablas procesadas y el número de tablas fallidas).
  • Los errores críticos que se han producido en una sola ejecución y los componentes o pasos del proceso en los que se han producido.

Para proporcionar esta información, la implementación escribe registros estructurados en Cloud Logging en cada paso de ejecución que utiliza un servicio de Cloud Run. Los registros incluyen la entrada, la salida y los errores, así como otros puntos de control del progreso. Un sumidero de registros enruta estos registros a una tabla de BigQuery. Puedes ejecutar varias consultas para monitorizar ejecuciones y obtener informes de casos prácticos de observabilidad habituales. Para obtener más información sobre los registros y las consultas en BigQuery, consulta el artículo Ver registros enrutados a BigQuery.

Optimización del rendimiento

Para gestionar miles de tablas en cada ejecución, la solución procesa las solicitudes de copia de seguridad en paralelo. El servicio de distribución enumera todas las tablas incluidas en el ámbito de la copia de seguridad de BigQuery y genera una solicitud de copia de seguridad por tabla en cada ejecución. De esta forma, la aplicación puede procesar miles de solicitudes y tablas en paralelo, no de forma secuencial.

Es posible que algunas de estas solicitudes fallen inicialmente por motivos temporales, como alcanzar los límites de las APIs Google Cloud subyacentes o experimentar problemas de red. Hasta que se completen las solicitudes, Pub/Sub vuelve a enviar automáticamente las solicitudes con la política de reintentos de espera exponencial. Si se producen errores graves, como destinos de copia de seguridad no válidos o falta de permisos, se registran los errores y se termina la ejecución de esa solicitud de tabla concreta sin que afecte a la ejecución general.

Límites

Se aplican los siguientes límites y cuotas a esta arquitectura.

En el caso de las copias de seguridad de tablas, se aplica lo siguiente a cada proyecto de operación de copia de seguridad que especifique:

  • Un proyecto puede ejecutar hasta 100 tareas de creación de instantáneas de tablas simultáneas.
  • Un proyecto puede ejecutar hasta 50.000 tareas de creación de instantáneas de tablas al día.
  • Un proyecto puede ejecutar hasta 50 tareas de creación de instantáneas de tablas por tabla y día.

Para obtener más información, consulta Capturas de tablas.

En el caso de las tareas de exportación (exportaciones a Cloud Storage), se aplican las siguientes condiciones:

  • Puedes exportar hasta 50 TiB de datos al día de un proyecto de forma gratuita con el grupo de ranuras compartido.
  • Un proyecto puede ejecutar hasta 100.000 exportaciones al día. Para ampliar este límite, crea una reserva de espacio.

Para obtener más información sobre cómo ampliar estos límites, consulta el artículo Tareas de exportación.

En cuanto a los límites de simultaneidad, esta arquitectura usa Pub/Sub para reintentar automáticamente las solicitudes que fallan debido a estos límites hasta que la API las atiende. Sin embargo, en el caso de otros límites en el número de operaciones por proyecto al día, se pueden mitigar mediante una solicitud de aumento de cuota o repartiendo las operaciones de copia de seguridad (creación de snapshots o exportaciones) entre varios proyectos. Para distribuir las operaciones entre proyectos, configura las políticas de copias de seguridad tal como se describe en las siguientes secciones de implementación:

Implementación

Para desplegar esta arquitectura, consulta Desplegar la automatización de copias de seguridad de BigQuery escalable.

Siguientes pasos

Colaboradores

Autor: Karim Wadie | Ingeniero estratégico de Cloud

Otros colaboradores: