Automatización escalable de copias de seguridad de BigQuery

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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 perdidos 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 copias 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 nube, ingenieros y funcionarios de administración de datos que desean definir y automatizar las políticas de datos en sus organizaciones.

Arquitectura

En el siguiente diagrama, se muestra la arquitectura 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 excluyen. Las ejecuciones se programan mediante una expresión cron.
2. El servicio de despachador, que se compila en Cloud Run, usa la API de BigQuery para enumerar las tablas que se encuentran dentro del alcance de BigQuery.
3. El servicio de despachador 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 copia de seguridad de la tabla a partir de una de las siguientes opciones definidas:

   1. La política a nivel de la tabla, que definen los propietarios de los datos.
   2. La política de resguardo, definida por el responsable 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 configuración envía una solicitud por 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 instantáneas de BigQuery crea una copia de seguridad de la tabla como una instantánea.
   2. El servicio para 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 trabajos de exportación para habilitar la ejecución asíncrona del siguiente paso.

8. Una vez 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 Google Cloud productos:

• BigQuery: Un almacén de datos empresarial que te ayuda a administrar y analizar tus datos con funciones integradas como el análisis geoespacial de 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 procesamiento administrada que te permite ejecutar contenedores directamente sobre la infraestructura escalable de Google.
• Cloud Storage: Un depósito de objetos de bajo costo y sin límites para varios tipos de datos. Se puede acceder a los datos desde dentro y fuera de Google Cloud, y se replican en todas las ubicaciones para agregar redundancia.
• Cloud Scheduler: Un programador de trabajos 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: Una base de datos NoSQL altamente escalable 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 lanzamientos, todavía existe el riesgo de pérdida o corrupción de datos debido a errores humanos. En una industria regulada, debes minimizar este riesgo tanto como sea posible.

Los siguientes son algunos ejemplos de estos errores humanos:

• Eliminación accidental de tablas.
• Corrupción de datos debido a 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 recorrido en el tiempo, que te permite recuperar datos de hasta siete días atrás. Además, BigQuery también ofrece un período a prueba de fallas, durante el cual los datos borrados se retienen en un almacenamiento a prueba de fallas durante siete días adicionales después del período de viaje en el tiempo. Esos datos están disponibles para 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 desde su último estado estable.

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

• Controla diferentes Google Cloud límites de la API.
• Proporcionar un framework estandarizado para definir políticas de copias de seguridad
• Proporciona transparencia y capacidades 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:

• Los propietarios de los datos, que están más familiarizados con las tablas y pueden establecer las políticas de copia de seguridad a nivel de tabla adecuadas.
• Equipo de administración de datos, que se asegura de que se aplique una política de resguardo para cubrir cualquier tabla que no tenga una política a nivel de 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 regulaciones de retención de datos de tu empresa.

En la implementación de esta arquitectura de referencia, hay dos formas 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): 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 la 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 tabla.

• Configuración predeterminada de la organización (centralizada): 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 hace una copia de los datos de la tabla de un momento determinado para que se puedan restablecer si se pierden o se dañan. Las copias de seguridad se pueden ejecutar una sola vez o de forma recurrente (a través de una consulta programada o un flujo de trabajo). En BigQuery, las copias de seguridad de un momento determinado se pueden lograr con instantáneas. Puedes usar instantáneas para mantener copias de los datos más allá del período de siete días dentro de la misma ubicación de almacenamiento que los datos de origen. Las instantáneas de BigQuery son muy útiles para recuperar datos después de errores humanos que provocan pérdida o corrupción 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 a una base de datos secundaria (o de réplica) que se encuentra en una ubicación diferente. En BigQuery, la replicación entre regiones puede ayudar a proporcionar redundancia geográfica, ya que crea 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 un plan de recuperación ante desastres en situaciones de interrupción en toda la región. Para resistir 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 las uniones colocadas y evitan el tráfico y los costos entre regiones. Sin embargo, en los 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 (exportación de instantáneas o de Cloud Storage)	Una vez o de forma recurrente	Igual que los datos de la tabla de origen	Restablecer los datos originales más allá del período de viaje en el tiempo	Las instantáneas incurren en cargos de almacenamiento solo por cambios en los datos. Las exportaciones pueden generar cargos de almacenamiento estándar. Consulta Optimización de costos.
Replicación entre regiones	Continuamente	Remoto	Crear una réplica en otra región Migraciones únicas entre regiones	Genera cargos por almacenamiento de 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 incluye las siguientes medidas de seguridad en su diseño y su implementación:

• La configuración de entrada de red de Cloud Run solo acepta tráfico interno para restringir el acceso desde Internet. Permite que solo usuarios autenticados y cuentas de servicio 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 consideraciones de privacidad, la solución no recopila ni procesa información de identificación personal (PII). Sin embargo, si las tablas fuente expusieron PII, las copias de seguridad realizadas de esas tablas también incluirán estos datos expuestos. El propietario de los datos de origen es responsable de proteger cualquier PII en las tablas de origen (por ejemplo, mediante la aplicación de seguridad a nivel de columna, enmascaramiento de datos o ocultación). Las copias de seguridad son seguras solo 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 PII expuesta tienen las políticas de administración de identidades y accesos (IAM) necesarias que restringen 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 API para los productos Google Cloud subyacentes (por ejemplo, límites de 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 posibles fallas, la implementación de referencia separa los pasos de procesamiento mediante el uso de servicios detallados de Cloud Run 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 reintenta 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 de 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 considerable de tiempo para enumerar todas las tablas dentro del alcance de la copia de seguridad de BigQuery. Por lo tanto, el servicio de despachador requiere una configuración más alta de tiempo de espera y de memoria. Sin embargo, el servicio de Cloud Run para 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 entre 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 momentos diferentes pueden capturar distintos estados de tu conjunto de datos. Estas copias de seguridad en diferentes estados pueden generar inconsistencias cuando restableces datos, en especial para tablas que pertenecen al mismo conjunto de datos funcional. Por ejemplo, restablecer una tabla de ventas a un momento determinado diferente 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 incoherencias. Restablecer estas vistas sin asegurarte de que las tablas subyacentes tengan un estado coherente podría generar resultados imprecisos o engañosos. Por lo tanto, cuando diseñas las políticas y frecuencias de copias de seguridad de BigQuery, es imperativo 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 el tiempo exacto de la instantánea de la tabla a través del recorrido en el tiempo, sin necesidad de crear una copia 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 recorrido 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 pasados se deben restar del punto de referencia en el tiempo (tiempo de inicio de ejecución) para calcular la versión exacta de la tabla en el tiempo.

Restablecimiento automático de copias de seguridad

Aunque esta arquitectura de referencia se enfoca en la automatización de copias de seguridad a gran escala, también puedes considerar restablecer estas copias de seguridad de forma automatizada. Esta automatización adicional puede proporcionar beneficios similares a los de la automatización de copias de seguridad, incluida una mejora en la eficiencia y la velocidad de la 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, puedes desarrollar una arquitectura similar para aplicar las operaciones de restablecimiento a gran escala.

Por ejemplo, puedes crear una solución basada en un activador según demanda que envíe un permiso de datos de BigQuery a un servicio de despachador, que envía una solicitud por tabla a un servicio configurador. El servicio de configuración puede recuperar el historial de copias de seguridad que deseas para una tabla en particular. Luego, el servicio configurador 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 etiquetador podría guardar 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 general de costos:

• 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 tablas que solo se adjuntan o tienen actualizaciones limitadas.
  • BigQuery exporta a Cloud Storage, que incurre en cargos de almacenamiento estándar. Sin embargo, para las tablas grandes que siguen un enfoque de truncamiento y carga, es más rentable hacer una copia de seguridad como exportaciones en clases de almacenamiento menos costosas.
• Vencimiento de la instantánea: El tiempo de actividad (TTL) se establece para una instantánea de una sola tabla, a fin de evitar que se generen costos de almacenamiento para 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 características y consideraciones para la eficiencia operativa.

Políticas de copias de seguridad detalladas y escalables

Uno de los objetivos de este marco de trabajo es la eficiencia operativa mediante el escalamiento vertical de los resultados empresariales, a la vez que se mantiene un nivel de entrada empresarial relativamente bajo y manejable. Por ejemplo, el resultado es una gran cantidad de tablas con copia de seguridad periódica, mientras que la entrada es una pequeña cantidad de políticas y configuraciones de copia de seguridad mantenidas.

Además de permitir políticas de copia de seguridad a nivel de tabla, el framework también admite políticas a nivel de conjunto de datos, proyecto, carpeta y nivel global. Esto significa que, con algunas configuraciones en niveles más altos (por ejemplo, a nivel de carpeta o de 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 con errores)
• Los errores fatales que ocurrieron en una sola ejecución y los componentes o pasos del proceso en los que ocurrieron.

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 para casos de uso comunes de observabilidad. Para obtener más información sobre los registros y las consultas en BigQuery, lee Visualiza los registros enrutados a BigQuery.

Optimización del rendimiento

Para manejar miles de tablas en cada ejecución, la solución procesa solicitudes de copia de seguridad en paralelo. El servicio de despachador enumera todas las tablas que se incluyen en el permiso 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 secuencialmente.

En un principio, algunas de estas solicitudes pueden fallar por motivos temporales, como alcanzar los límites de las APIs Google Cloud subyacentes o experimentar problemas de red. Hasta que se completan las solicitudes, Pub/Sub vuelve a intentarlo 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, los errores se registran y la ejecución de esa solicitud de tabla en particular se finaliza sin afectar la ejecución general.

Límites

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

En el caso de las instantáneas de tablas, lo siguiente se aplica a 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 detalles, consulta Instantáneas de tablas.

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 si usas 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.

Si quieres obtener más información para 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 pueden mitigar con una solicitud de aumento de cuota o mediante la distribución de las operaciones de copia de seguridad (instantáneas o exportaciones) en varios proyectos. Para distribuir las operaciones en los proyectos, configura las políticas de copia de seguridad como se describe en las siguientes secciones de implementación:

• Define políticas de copia de seguridad de resguardo
• Configura proyectos de operaciones de copia de seguridad adicionales
• Establece políticas de copia de seguridad a nivel de tabla

Implementación

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

¿Qué sigue?

• Obtén más información sobre BigQuery:
  • Instantáneas de tablas de BigQuery
  • Exportaciones de tablas de BigQuery a Cloud Storage
• Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.

Colaboradores

Autor: Karim Wadie | Ingeniero estratégico de Cloud

Otros colaboradores:

• Chris DeForeest | Ingeniero de confiabilidad de sitios
• Eyal Ben Ivri | Arquitecto de soluciones en la nube
• Jason Davenport | Developers Advocate
• Jaliya Ekanayake | Administradora de Ingeniería
• Muhammad Zain | Ingeniero estratégico de Cloud