Automatización escalable de copias de seguridad de BigQuery

Last reviewed 2024-09-17 UTC

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

  • Cumple con los objetivos de recuperación ante desastres de tu organización.
  • Recuperar datos que se perdieron debido a errores humanos
  • Cumplir con las reglamentaciones
  • Mejorar la eficiencia operativa.

El alcance de los datos de BigQuery puede incluir (o excluir) carpetas, proyectos, conjuntos de datos y tablas. En esta arquitectura recomendada, se 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 BigQuery Export a Cloud Storage.

Este documento está dirigido a arquitectos, ingenieros y responsables de administración de datos de la nube que deseen definir y automatizar las políticas de datos en sus organizaciones.

Arquitectura

En el siguiente diagrama, se muestra la arquitectura de las copias de seguridad automatizadas:

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 en el servicio de despachador a través de un mensaje de Pub/Sub, que contiene el alcance de los datos de BigQuery que se incluyen y se excluyen. Las ejecuciones se programan con una expresión cron.
  2. El servicio de despachador, que se basa en Cloud Run, usa la API de BigQuery para enumerar las tablas que se encuentran dentro del permiso de BigQuery.
  3. El servicio de despachador envía una solicitud para cada tabla al servicio de configurador a través de un mensaje de Pub/Sub.

  4. El servicio de configuración de Cloud Run calcula la política de copia 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 de resguardo, que define el oficial de administración de datos, para las tablas que no tienen políticas definidas.

    Para obtener detalles sobre las políticas de copia de seguridad, consulta Políticas de copia de seguridad.

  5. El servicio de configurador envía una solicitud para cada tabla al siguiente servicio, según la política de copia de seguridad calculada.

  6. Según el 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 para las instantáneas de BigQuery crea una copia de seguridad de la tabla como una instantánea.
    2. El servicio para las exportaciones 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 una exportación de datos de tabla, un receptor de registros de Cloud Logging escucha los eventos de finalización de los trabajos de exportación para habilitar la ejecución asíncrona del siguiente paso.

  8. Después de que los servicios de copia de seguridad completan sus operaciones, Pub/Sub activa el servicio de etiquetado.

  9. Para 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

En esta arquitectura de referencia, se usan los siguientes productos de Google Cloud :

  • BigQuery: Es un almacén de datos empresarial que te ayuda a administrar y analizar tus datos con funciones integradas, como el análisis geoespacial, el aprendizaje automático y la inteligencia empresarial.
  • Cloud Logging: Un sistema de administración de registros en tiempo real con almacenamiento, búsqueda, análisis y alertas.
  • Pub/Sub: Un servicio de mensajería asíncrona y escalable que separa los servicios que producen mensajes de servicios que procesan esos mensajes.
  • Cloud Run: Es una plataforma de computación sin servidores que te permite ejecutar contenedores directamente sobre la infraestructura escalable de Google.
  • Cloud Storage: Es un almacén de objetos de bajo costo y sin límites para varios tipos de datos. Se puede acceder a los datos desde y hacia Google Cloud, y estos se replican en las ubicaciones para aumentar la redundancia.
  • Cloud Scheduler: Es un programador de trabajo cron de nivel empresarial completamente administrado que te permite configurar unidades de trabajo programadas para que se ejecuten en horarios definidos o a intervalos regulares.
  • Datastore: Es una base de datos NoSQL con alta escalabilidad para las aplicaciones web y para dispositivos móviles.

Casos de uso

En esta sección, se proporcionan ejemplos de casos de uso para los que puedes usar esta arquitectura.

Automatización de copias de seguridad

Por ejemplo, tu empresa podría operar en una industria regulada y usar BigQuery como el almacén de datos principal. Incluso cuando tu empresa sigue las prácticas recomendadas en el desarrollo de software, la revisión de código y la ingeniería de versiones, aún existe el riesgo de pérdida o daño de datos debido a errores humanos. En una industria regulada, debes minimizar este riesgo tanto como sea posible.

Estos son algunos ejemplos de estos errores humanos:

  • Borrado accidental de tablas
  • Daño de los datos debido a una lógica de canalización de datos errónea

Por lo general, estos tipos de errores humanos se pueden resolver con la función de viaje en el tiempo, que te permite recuperar datos de hasta siete días atrás. Además, BigQuery también ofrece un período de seguridad ante fallas, durante el cual los datos borrados se conservan en el almacenamiento de seguridad ante fallas durante siete días más después del período de viaje en el tiempo. Esos datos están disponibles para la recuperación de emergencia a través de la Atención al cliente de Cloud. Sin embargo, si tu empresa no descubre ni corrige esos errores dentro de este período combinado, los datos borrados ya no se podrán recuperar de su último estado estable.

Para mitigar este problema, te recomendamos que realices 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 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 en toda la organización con regularidad, necesitas una solución de automatización escalable que pueda hacer lo siguiente:

  • Controla diferentes límites de la API de Google Cloud .
  • Proporcionar un framework estandarizado para definir políticas de copia de seguridad
  • Proporcionar transparencia y funciones de supervisión para las operaciones de copia de seguridad

Políticas de copia de seguridad

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

  • Propietarios de datos, que están más familiarizados con las tablas y pueden establecer las políticas de copia de seguridad a nivel de la tabla adecuadas.
  • Equipo de administración de datos, que se asegura de que se aplique una política de resguardo para cubrir las tablas que no tienen una política a nivel de la tabla. La política de resguardo garantiza que se cree una copia de seguridad de ciertos conjuntos de datos, proyectos y carpetas para cumplir con las reglamentaciones de retención de datos de tu empresa.

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

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

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

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

    • Un equipo de administración de datos define un archivo JSON central en Terraform como parte de la solución.
    • La política de resguardo ofrece estrategias de copia de seguridad predeterminadas a nivel de carpeta, proyecto, conjunto de datos y tabla.
    • Para obtener detalles sobre la implementación, consulta Define políticas de copia de seguridad de resguardo.

Copia de seguridad frente a replicación

Un proceso de copia de seguridad crea una copia de los datos de la tabla desde un momento determinado, para que se puedan restablecer si se pierden o dañan. Las copias de seguridad se pueden ejecutar una sola vez o de forma recurrente (a través de una consulta o un flujo de trabajo programados). En BigQuery, las copias de seguridad de un momento determinado se pueden lograr con instantáneas. Puedes usar instantáneas para conservar copias de los datos más allá del período de viaje en el tiempo de siete días en la misma ubicación de almacenamiento que los datos de origen. Las instantáneas de BigQuery son particularmente ú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 fallas regionales. BigQuery ofrece un objetivo de nivel de servicio (SLO) del 99.9% al 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 una ubicación diferente. 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 los datos de origen. Sin embargo, la replicación entre regiones de BigQuery no está diseñada para usarse como un plan de recuperación ante desastres en situaciones de interrupción total de la región. Para obtener resiliencia ante desastres regionales, considera usar la recuperación ante desastres administrada de BigQuery.

La replicación entre regiones de BigQuery proporciona una copia sincronizada de solo lectura de los datos en una región cercana a los consumidores de datos. Estas copias de datos permiten uniones coubicadas y evitan el tráfico entre regiones y el costo. Sin embargo, en casos de daños en los datos debido a un error humano, 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 esos casos, las copias de seguridad de un momento determinado (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 la replicación:

Método Frecuencia Ubicación del almacenamiento Casos de uso Costos
Copia de seguridad

(instantáneas o exportación de Cloud Storage)		 Una vez o de forma recurrente Igual que los datos de la tabla de origen Restablece los datos originales más allá del período de viaje en el tiempo Las instantáneas generan cargos de almacenamiento solo para los cambios de datos en la instantánea

Las exportaciones pueden generar cargos de almacenamiento estándar

Consulta Optimización de costos
Replicación entre regiones Continuamente Remoto Crea una réplica en otra región

Migraciones únicas entre regiones		 Genera cargos por almacenar datos en la réplica

Genera costos de replicación de datos

Consideraciones del diseño

En esta sección, se proporciona orientación para que tengas en cuenta cuando uses esta arquitectura de referencia para desarrollar una topología que cumpla con tus requisitos específicos de seguridad, confiabilidad, optimización de costos, eficiencia operativa y rendimiento.

Security, privacy, and compliance

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

  • La configuración de entrada de red para 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 a Pub/Sub usa una cuenta de servicio independiente, que solo tiene asignados los permisos necesarios. Esto mitiga los riesgos asociados con el uso de una cuenta de servicio para el sistema y sigue el principio de privilegio mínimo.

Por cuestiones de privacidad, la solución no recopila ni procesa información de identificación personal (PII). Sin embargo, si las tablas de origen tienen PII expuesta, las copias de seguridad que se realicen de esas tablas también incluirán estos datos expuestos. El propietario de los datos de origen es responsable de proteger cualquier IIP en las tablas de origen (por ejemplo, aplicando seguridad a nivel de columna, enmascaramiento de datos o redacción). Las copias de seguridad solo están protegidas cuando los datos de origen están protegidos. Otro enfoque es asegurarse de que los proyectos, los conjuntos de datos o los buckets que contienen datos de copia de seguridad con IIP expuesta tengan las políticas de Identity and Access Management (IAM) necesarias que restrinjan el acceso solo a los usuarios autorizados.

Como solución de uso general, la implementación de referencia no necesariamente cumple con los requisitos específicos de un sector en particular.

Confiabilidad

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

Mitigación de fallas con nivel de detalle

Para realizar copias de seguridad de miles de tablas, es probable que alcances los límites de la API para los productos de Google Cloud subyacentes (por ejemplo, los límites de las operaciones de instantánea y exportación para cada proyecto). Sin embargo, si la copia de seguridad de una tabla falla debido a una configuración incorrecta o a otros problemas transitorios, eso no debería afectar la ejecución general ni la capacidad de crear copias de seguridad de otras tablas.

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

Desglosar el flujo en varios servicios de Cloud Run, en lugar de varios extremos alojados en un servicio de Cloud Run, ayuda a proporcionar un control detallado de cada configuración del servicio. El nivel de configuración depende de las capacidades del servicio y de las APIs con las que se comunica. Por ejemplo, el servicio de despachador se ejecuta una vez por ejecución, pero requiere una cantidad de tiempo considerable para enumerar todas las tablas dentro del permiso de copia de seguridad de BigQuery. Por lo tanto, el servicio de despachador requiere una configuración de tiempo de espera y memoria más alta. Sin embargo, el servicio de Cloud Run para las instantáneas de BigQuery se ejecuta una vez por tabla en una sola ejecución y se completa en menos tiempo que el servicio de despachador. Por lo tanto, el servicio de Cloud Run requiere un conjunto diferente de parámetros de configuración a nivel del servicio.

Coherencia de los datos

La coherencia de los datos en las tablas y vistas es fundamental para mantener una estrategia de copia de seguridad confiable. Debido a que los datos se actualizan y modifican de forma continua, las copias de seguridad que se realizan en diferentes momentos pueden capturar diferentes estados de tu conjunto de datos. Estas copias de seguridad en diferentes estados pueden generar inconsistencias cuando restableces datos, en especial para las tablas que pertenecen al mismo conjunto de datos funcional. Por ejemplo, restablecer una tabla de ventas a un momento diferente del de su tabla de inventario correspondiente podría crear una discrepancia en el stock disponible. Del mismo modo, las vistas de bases de datos que agregan datos de varias tablas pueden ser particularmente sensibles a las inconsistencias. Restablecer estas vistas sin garantizar que las tablas subyacentes estén en un estado coherente podría generar resultados imprecisos o engañosos. Por lo tanto, cuando diseñes tus políticas y frecuencias de copia de seguridad de BigQuery, es fundamental considerar esta coherencia y asegurarte de que los datos restablecidos reflejen con precisión el estado real de tu conjunto de datos en un momento determinado.

Por ejemplo, en la implementación de esta arquitectura de referencia, la coherencia de los datos se controla a través de las siguientes dos opciones de configuración en las políticas de copia de seguridad. Estas opciones de configuración calculan la hora exacta de la instantánea de la tabla a través del viaje 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 el cálculo del viaje en el tiempo de todas las tablas de las que se crea una copia de seguridad en esta ejecución.
  • backup_time_travel_offset_days: Controla cuántos días en el pasado se deben restar del punto de referencia en el tiempo (hora de inicio de la ejecución) para calcular la versión exacta de viaje en el tiempo de la tabla.

Restablecimiento de copias de seguridad automáticas

Aunque esta arquitectura de referencia se enfoca en la automatización de las copias de seguridad a gran escala, también puedes considerar restablecer estas copias de seguridad de forma automática. Esta automatización adicional puede proporcionar beneficios similares a los de la automatización de copias de seguridad, incluida una mayor eficiencia y velocidad de recuperación, con menos tiempo de inactividad. Debido a que la solución realiza un seguimiento de todos los parámetros y resultados de la copia de seguridad a través del servicio de etiquetado, podrías desarrollar una arquitectura similar para aplicar las operaciones de restablecimiento a gran escala.

Por ejemplo, podrías crear una solución basada en un activador on demand que envíe un alcance de datos de BigQuery a un servicio de despachador, que envíe una solicitud por tabla a un servicio de configurador. El servicio de configuración podría recuperar el historial de copias de seguridad que deseas para una tabla en particular. Luego, el servicio de configuración podría pasarlo a un servicio de restablecimiento de instantáneas de BigQuery o a un servicio de restablecimiento de Cloud Storage para aplicar la operación de restablecimiento según corresponda. Por último, un servicio de etiquetado podría almacenar los resultados de estas operaciones en un almacén de estado. De esta manera, el framework de restablecimiento automatizado puede beneficiarse de los mismos objetivos de diseño que el framework de copia de seguridad que se detalla en este documento.

Optimización de costos

El framework de esta arquitectura proporciona políticas de copia de seguridad que establecen los siguientes parámetros para la optimización de costos general:

  • Método de copia de seguridad: El framework ofrece los siguientes dos métodos de copia de seguridad:
    • Instantáneas de BigQuery, que generan costos de almacenamiento en función de los datos actualizados y borrados en comparación con la tabla base. Por lo tanto, las instantáneas son más rentables para las tablas que solo se agregan o tienen actualizaciones limitadas.
    • Exportaciones de BigQuery a Cloud Storage, que generan cargos de almacenamiento estándar Sin embargo, para las tablas grandes que siguen un enfoque de truncamiento y carga, es más rentable crear copias de seguridad de ellas como exportaciones en clases de almacenamiento menos costosas.
  • Vencimiento de la instantánea: El tiempo de actividad (TTL) se establece para una sola instantánea de tabla, a fin de evitar incurrir en costos de almacenamiento por la instantánea de forma indefinida. Los costos de almacenamiento pueden aumentar con el tiempo si las tablas no tienen vencimiento.

Eficiencia operativa

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

Políticas de copia de seguridad detalladas y escalables

Uno de los objetivos de este framework es la eficiencia operativa, que se logra aumentando el rendimiento empresarial y manteniendo la entrada empresarial relativamente baja y manejable. Por ejemplo, el resultado es una gran cantidad de tablas con copias de seguridad periódicas, mientras que la entrada es una pequeña cantidad de políticas y parámetros de configuración de copias de seguridad mantenidos.

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

Observabilidad

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

  • La política de copia de seguridad que usa el sistema para cada tabla.
  • El historial y las ubicaciones de las copias de seguridad de cada tabla.
  • El estado general de una sola ejecución (la cantidad de tablas procesadas y tablas con errores).
  • Los errores fatales que se produjeron en una sola ejecución y los componentes o pasos del proceso en los que se produjeron.

Para proporcionar esta información, la implementación escribe registros estructurados en Cloud Logging en cada paso de ejecución que usa un servicio de Cloud Run. Los registros incluyen la entrada, la salida y los errores, junto con otros puntos de control de progreso. Un receptor de registros enruta estos registros a una tabla de BigQuery. Puedes ejecutar varias consultas para supervisar las ejecuciones y obtener informes sobre casos de uso comunes de observabilidad. Para obtener más información sobre los registros y las consultas en BigQuery, consulta Visualiza los registros enrutados a BigQuery.

Optimización del rendimiento

Para controlar miles de tablas en cada ejecución, la solución procesa las solicitudes de copia de seguridad en paralelo. El servicio de despachador enumera todas las tablas que se incluyen en el alcance de la copia de seguridad de BigQuery y genera una solicitud de copia de seguridad por tabla en cada ejecución. Esto permite que la aplicación procese miles de solicitudes y tablas en paralelo, no de forma secuencial.

Es posible que algunas de estas solicitudes fallen al principio por motivos temporales, como alcanzar los límites de las APIs de Google Cloud subyacentes o experimentar problemas de red. Hasta que se completen las solicitudes, Pub/Sub las reintenta de forma automática con la política de reintentos de retirada exponencial. Si hay errores fatales, como destinos de copia de seguridad no válidos o permisos faltantes, se registran los errores y se finaliza la ejecución de esa solicitud de tabla en particular sin afectar la ejecución general.

Límites

Las siguientes cuotas y límites se aplican a esta arquitectura.

En el caso de las instantáneas de tablas, se aplica lo siguiente para cada proyecto de operación de copia de seguridad que especifiques:

  • Un proyecto puede ejecutar hasta 100 trabajos de instantáneas de tablas simultáneos.
  • Un proyecto puede ejecutar hasta 50,000 trabajos de instantáneas de tablas por día.
  • Un proyecto puede ejecutar hasta 50 trabajos de instantáneas de tablas por tabla por día.

Para obtener más información, consulta Instantáneas de tabla.

Para los trabajos de exportación (exportaciones a Cloud Storage), se aplica lo siguiente:

  • Puedes exportar hasta 50 TiB de datos por día desde un proyecto de forma gratuita con el grupo de ranuras compartidas.
  • Un proyecto puede ejecutar hasta 100,000 exportaciones por día. Para extender este límite, crea una reserva de ranuras.

Para obtener más información sobre cómo extender estos límites, consulta Trabajos 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 entregue. Sin embargo, para otros límites en la cantidad de operaciones por proyecto por día, estos se podrían mitigar con una solicitud de aumento de cuota o distribuyendo las operaciones de copia de seguridad (instantáneas o exportaciones) en varios proyectos. Para distribuir las operaciones entre los proyectos, configura las políticas de copia de seguridad como se describe en las siguientes secciones de implementación:

Implementación

Para implementar esta arquitectura, consulta Implementa la automatización de copias de seguridad escalables de BigQuery.

¿Qué sigue?

Colaboradores

Autor: Karim Wadie | Ingeniero estratégico de Cloud

Otros colaboradores: