Esta arquitectura proporciona un marco de trabajo 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 exportaciones de BigQuery a Cloud Storage.
Este documento está dirigido a arquitectos, ingenieros y responsables de la gobernanza 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:
El flujo de trabajo que se muestra en el diagrama anterior incluye las siguientes fases:
- 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.
- El servicio de despachador, que se compila en Cloud Run, usa la API de BigQuery para mostrar una lista de las tablas que se encuentran dentro del alcance de BigQuery.
- El servicio de despachador envía una solicitud para cada tabla al servicio de configurador a través de un mensaje de Pub/Sub.
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:
- La política a nivel de la tabla, que definen los propietarios de los datos
- La política de resguardo, que define el encargado de la administración de datos, para las tablas que no tienen políticas definidas.
Para obtener detalles sobre las políticas de copias de seguridad, consulta Políticas de copias de seguridad.
El servicio del configurador envía una solicitud para cada tabla al siguiente servicio, según la política de copia de seguridad calculada.
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:
- El servicio de instantáneas de BigQuery crea una copia de seguridad de la tabla como una instantánea.
- El servicio de exportaciones de datos crea una copia de seguridad de la tabla como una exportación de datos a Cloud Storage.
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.
Después de que los servicios de copia de seguridad completen sus operaciones, Pub/Sub activa el servicio de etiquetado.
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 estos se replican en las ubicaciones para aumentar la redundancia.
- Cloud Scheduler: Es 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: Es 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, existe el riesgo de que se pierdan o se dañen los datos debido a errores humanos. En una industria regulada, debes minimizar este riesgo tanto como sea posible.
Estos son algunos ejemplos de errores humanos:
- Eliminación accidental de tablas
- Corrupción de datos debido a una lógica errónea de la canalización de datos
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 retienen 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 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 pueden recuperar desde su último estado estable.
Para mitigar esto, 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 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 con regularidad en toda la organización, necesitas una solución de automatización escalable que pueda hacer lo siguiente:
- Controla los diferentes Google Cloud límites de la API.
- Proporciona un framework estandarizado para definir políticas de copia de seguridad.
- Proporcionar 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 exija 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 la tabla adecuadas.
- El equipo de administración de datos, que se asegura de que haya 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 creen copias 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 la tabla que se adjunta manualmente 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 Cómo establecer 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 solo se aplica 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 la carpeta, el proyecto, el conjunto de datos y la tabla.
- Para obtener detalles sobre la implementación, consulta Define políticas de copia de seguridad de resguardo.
Comparación entre la copia de seguridad y la replicación
Un proceso de copia de seguridad crea una copia de los datos de la tabla a partir de un momento determinado para que se puedan restablecer si se pierden o se dañan. Las copias de seguridad se pueden ejecutar como un evento único o de forma recurrente (a través de una consulta o un flujo de trabajo programado). En BigQuery, las copias de seguridad de un momento determinado se pueden lograr con las 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 corrupción de datos, en lugar de recuperarse de fallas regionales. BigQuery ofrece un objetivo de nivel de servicio (SLO) de 99.9% a 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 mediante la creación de copias de solo lectura de los datos en Google Cloud regiones secundarias, que son diferentes de la región de datos fuente. Sin embargo, la replicación entre regiones de BigQuery no está diseñada para usarse como un plan de recuperación ante desastres para situaciones de interrupciones regionales totales. Para obtener resiliencia contra 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 unir las tablas en la misma ubicación y evitar el tráfico y el costo 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 en 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 replicación y de copia de seguridad:
Método | Frecuencia | Ubicación del almacenamiento | Casos de uso | Costos |
---|---|---|---|---|
Copia de seguridad (Instantáneas o exportación a Cloud Storage) |
Único o 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 por 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 | De forma continua | 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 implementación:
- La configuración 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 autenticados y las cuentas de servicio llamen a los servicios.
- Cada servicio de Cloud Run y cada suscripción a Pub/Sub usan una cuenta de servicio independiente, que solo tiene los permisos necesarios asignados. 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 motivos de privacidad, la solución no recopila ni procesa información de identificación personal (PII). Sin embargo, si las tablas de origen expusieron PII, las copias de seguridad que se tomaron de esas tablas también incluyen estos datos expuestos. El propietario de los datos de origen es responsable de proteger cualquier PII en las tablas de origen (por ejemplo, aplicando seguridad a nivel de la columna, enmascaramiento de datos o ocultación). Las copias de seguridad solo son seguras 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 tengan las políticas de administración de identidades y accesos (IAM) requeridas que restrinjan el acceso solo a los usuarios autorizados.
Como solución de uso general, la implementación de referencia no cumple necesariamente con los requisitos específicos de una industria 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 crear copias de seguridad de miles de tablas, es probable que alcances los límites de API de los productos Google Cloud subyacentes (por ejemplo, los límites de operaciones de instantáneas 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 desvincula los pasos de procesamiento mediante el uso de servicios detallados de Cloud Run y su conexión 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.
Dividir 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 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 entre las tablas y las vistas es fundamental para mantener una estrategia de copia de seguridad confiable. Dado que los datos se actualizan y modifican de forma continua, las copias de seguridad que se toman en diferentes momentos pueden capturar diferentes estados de tu conjunto de datos. Estas copias de seguridad en estados diferentes pueden generar inconsistencias cuando restableces datos, en particular para las tablas que pertenecen al mismo conjunto de datos funcionales. Por ejemplo, restablecer una tabla de ventas a un momento diferente de su tabla de inventario correspondiente podría generar una discrepancia en el stock disponible. Del mismo modo, las vistas de bases de datos que aggreguen datos de varias tablas pueden ser particularmente sensibles a las inconsistencias. Si restableces estas vistas sin asegurarte de que las tablas subyacentes estén en un estado coherente, es posible que se generen resultados imprecisos o engañosos. Por lo tanto, cuando diseñes las frecuencias y las políticas de copia de seguridad de BigQuery, es fundamental considerar esta coherencia y asegurarte de que los datos restablecidos reflejen con exactitud 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 configuraciones en las políticas de copia de seguridad. Estas configuraciones calculan el tiempo exacto de la instantánea de la tabla a través del viaje 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 desplazamiento 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 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 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, 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 a pedido que envíe un alcance de datos de BigQuery a un servicio de despachador, que envía 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 del configurador podría pasarlo 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 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 automático puede beneficiarse de los mismos objetivos de diseño que el framework de copia de seguridad detallado 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 según 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.
- BigQuery exporta a Cloud Storage, lo que genera cargos de almacenamiento estándar. Sin embargo, para las tablas grandes que siguen un enfoque de truncamiento y carga, es más rentable crear una copia de seguridad como exportaciones en clases de almacenamiento menos costosas.
- Vencimiento de instantáneas: El tiempo de actividad (TTL) se establece para una sola instantánea de tabla, para evitar incurrir en costos de almacenamiento de 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 las 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, ya que aumenta la producción empresarial y, al mismo tiempo, mantiene la entrada empresarial relativamente baja y manejable. Por ejemplo, el resultado es una gran cantidad de tablas de las que se crean copias de seguridad con regularidad, 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 la tabla, el framework también permite políticas a nivel del conjunto de datos, el proyecto, la carpeta y el nivel global. Esto significa que, con algunas configuraciones en niveles superiores (por ejemplo, a nivel de la carpeta o del 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 para las siguientes consultas comunes:
- Es 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 (la cantidad de tablas procesadas y fallidas).
- 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 ejecuciones y obtener informes para casos de uso comunes de la observabilidad. Para obtener más información sobre los registros y las consultas en BigQuery, consulta Cómo ver 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 inicialmente por motivos temporales, como llegar a 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 automáticamente con la política de reintento de retirada exponencial. Si hay errores fatales, como destinos de copia de seguridad no válidos o permisos faltantes, los errores se registran y se finaliza la ejecución de esa solicitud de tabla en particular 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, 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 tabla 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 tablas.
En el caso de 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 mediante 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 ranura.
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 intentar nuevamente las solicitudes que fallan debido a estos límites, hasta que la API las entrega. 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 con la distribución de 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:
- Define políticas de copia de seguridad de resguardo
- Configura proyectos de operaciones de copia de seguridad adicionales
- Cómo establecer políticas de copia de seguridad a nivel de la 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:
- 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 de Cloud
- Jason Davenport | Developers Advocate
- Jaliya Ekanayake | Gerente de Ingeniería
- Muhammad Zain | Ingeniero estratégico de Cloud