Casos de uso de recuperación ante desastres: aplicaciones de análisis de datos con restricciones de localidad

Last reviewed 2022-01-07 UTC

Este artículo forma parte de una serie en la que se trata la recuperación ante desastres (DR) en Google Cloud. En este documento, se describe cómo aplicar las restricciones de localidad del documento, Arquitectura de recuperación ante desastres para cargas de trabajo con restricciones de localidad, a las aplicaciones de análisis de datos. En particular, este documento describe cómo los componentes que usas en una plataforma de estadísticas de datos se ajustan a una arquitectura de DR que cumple con las restricciones de localidad a las que pueden estar sujetas tus aplicaciones o datos.

La serie consta de las siguientes partes:

Este documento está dirigido a arquitectos de sistemas y administradores de TI. Suponemos que tienes los siguientes conocimientos y habilidades:

Requisitos de localidad para una plataforma de análisis de datos

Las plataformas de análisis de datos suelen ser aplicaciones complejas de varios niveles que almacenan datos en reposo. Estas aplicaciones producen eventos que se procesan y almacenan en tu sistema de estadísticas. Tanto la aplicación como los datos almacenados en el sistema pueden estar sujetos a regulaciones de localidad. Estas regulaciones varían entre los distintos países y también entre las verticales de la industria. Por lo tanto, debes comprender en profundidad los requisitos de localidad de datos antes de comenzar a diseñar la arquitectura de DR.

Puedes determinar si tu plataforma de análisis de datos tiene requisitos de localidad. Para ello, responde las siguientes dos preguntas:

  • ¿Tu aplicación debe implementarse en una región específica?
  • ¿Tus datos en reposo están restringidos a una región específica?

Si respondes “no” a ambas preguntas, tu plataforma de análisis de datos no tiene ningún requisito específico de la localidad. Debido a que tu plataforma no tiene requisitos de localidad, sigue las instrucciones de DR para los servicios y productos compatibles que se describen en la Guía de planificación para la recuperación ante desastres.

Sin embargo, si respondes “sí” a cualquiera de las preguntas, la aplicación está restringida por la localidad. Debido a que tu plataforma de estadísticas está restringida por la localidad, debes hacer la siguiente pregunta: ¿Puedes usar técnicas de encriptación para mitigar los requisitos de datos en reposo?

Si puedes usar técnicas de encriptación, puedes usar los servicios multirregión y birregionales de Cloud External Key Manager y Cloud Key Management Service. También puedes seguir las técnicas estándar de alta disponibilidad y recuperación ante desastres (HA/DR) que se describen en Situaciones de recuperación ante desastres para datos.

Si no puedes usar técnicas de encriptación, debes usar soluciones personalizadas o ofertas de socios para la planificación de DR. Si deseas obtener más información sobre las técnicas de resolución de restricciones de localidad en situaciones de DR, consulta Arquitectura de recuperación ante desastres para cargas de trabajo con restricciones de localidad.

Componentes en una plataforma de análisis de datos

Cuando comprendas los requisitos de localidad, el siguiente paso es comprender los componentes que usa tu plataforma de estadísticas de datos. Algunos componentes comunes de la plataforma de análisis de datos son bases de datos, data lakes, canalizaciones de procesamiento y almacenes de datos, como se describe en la siguiente lista:

  • Google Cloud tiene un conjunto de servicios de base de datos que se adaptan a diferentes casos prácticos.
  • Los data lakes, los almacenes de datos y las canalizaciones de procesamiento pueden tener definiciones ligeramente diferentes. En este documento, se usa un conjunto de definiciones que hacen referencia a los servicios de Google Cloud:
    • Un data lake es una plataforma escalable y segura para transferir y almacenar datos de varios sistemas. Un data lake típico puede usar Cloud Storage como el repositorio de almacenamiento central.
    • Una canalización de procesamiento es un proceso de extremo a extremo que toma datos o eventos de uno o más sistemas, los transforma, y los carga en otro sistema. La canalización puede seguir un proceso de extracción, transformación y carga (ETL) o extracción, carga y transformación (ELT). Por lo general, el sistema en el que se cargan los datos procesados es un almacén de datos. Pub/Sub, Dataflow y Dataproc son los componentes que se usan con frecuencia de una canalización de procesamiento.
    • Un almacén de datos es un sistema empresarial que se usa para el análisis y la generación de informes de datos, por lo general, provienen de una base de datos operativa. BigQuery es un sistema de almacén de datos que se usa con frecuencia y se ejecuta en Google Cloud.

La implementación real de la DR varía según los requisitos de localidad y los componentes de análisis de datos que usas. En las siguientes secciones, se muestra esta variación con dos casos prácticos.

Caso práctico de lote: un trabajo periódico de ETL

El primer caso práctico describe un proceso por lotes en el que una plataforma de venta minorista recopila de manera periódica eventos de ventas como archivos de varias tiendas y, luego, los escribe en un bucket de Cloud Storage. En el siguiente diagrama, se ilustra la arquitectura de estadísticas de datos para el trabajo por lotes de este minorista.

Diagrama de arquitectura de un caso práctico por lotes que involucra datos de puntos de venta

La arquitectura incluye las siguientes fases y componentes:

  • La fase de transferencia consiste en que los almacenes envíen sus datos de punto de venta (PdV) a Cloud Storage. Estos datos transferidos esperan su procesamiento.
  • La fase de organización usa Cloud Composer para organizar la canalización por lotes de extremo a extremo.
  • La fase de procesamiento implica un trabajo de Apache Spark que se ejecuta en un clúster de Dataproc. El trabajo de Apache Spark realiza un proceso ETL en los datos transferidos. En este proceso de ETL, se proporcionan métricas empresariales.
  • La fase de data lake toma los datos procesados y almacena información en los siguientes componentes:
    • Por lo general, los datos procesados se almacenan en formatos de columna de Cloud Storage, como Parquet y ORC dado que estos formatos permiten un almacenamiento eficiente y un acceso más rápido para las cargas de trabajo analíticas.
    • Los metadatos sobre los datos del proceso (como bases de datos, tablas, columnas y particiones) se almacenan en el servicio de almacén de metadatos de Hive que proporciona Dataproc Metastore.

En situaciones con restricciones de localidad, puede ser difícil proporcionar capacidad de procesamiento y organización redundante para mantener la disponibilidad. Debido a que los datos se procesan por lotes, las canalizaciones de procesamiento y organización se pueden volver a crear, y los trabajos por lotes se pueden reiniciar después de resolver una situación de desastre. Por lo tanto, para la recuperación ante desastres, el enfoque principal es recuperar los datos reales: los datos de POS transferidos, los datos procesados en el data lake y los metadatos almacenados en el data lake.

Transferencia a Cloud Storage

La primera consideración debe ser los requisitos de localidad para el bucket de Cloud Storage que se usa a fin de transferir los datos desde el sistema de POS. Usa esta información de localidad cuando consideres las siguientes opciones:

  • Si los requisitos de localidad permiten que los datos en reposo residan en una de las ubicaciones multirregionales o birregionales, elige el tipo de ubicación correspondiente cuando crees el bucket de Cloud Storage. El tipo de ubicación que elijas define qué regiones de Google Cloud se usan para replicar tus datos en reposo. Si ocurre una interrupción en una de las regiones, se podrá acceder a los datos que residen en buckets multirregión o birregionales.
  • Cloud Storage también admite claves de encriptación administradas por el cliente (CMEK) y claves de encriptación proporcionadas por el cliente (CSEK). Algunas reglas de localidad permiten que los datos en reposo se almacenen en varias ubicaciones cuando usas CMEK o CSEK para la administración de claves. Si tus reglas de localidad permiten el uso de CMEK o CSEK, puedes diseñar tu arquitectura de DR para que use regiones de Cloud Storage.
  • Es posible que tus requisitos de localidad no te permitan usar tipos de ubicación o administración de claves de encriptación. Cuando no puedes usar tipos de ubicación o administración de claves de encriptación, puedes usar el comando gsutil rsync para sincronizar datos con otra ubicación, como Soluciones de almacenamiento o almacenamiento locales desde otro proveedor de servicios en la nube.

Si ocurre un desastre, es posible que los datos de POS transferidos en el bucket de Cloud Storage tengan datos que aún no se procesaron ni se importaron al data lake. Como alternativa, es posible que los datos del PdV no se puedan transferir al bucket de Cloud Storage. Para estos casos, tienes las siguientes opciones de recuperación ante desastres:

  • Permite que el sistema de PdV vuelva a intentarlo. En el caso de que el sistema no pueda escribir los datos de POS en Cloud Storage, el proceso de transferencia de datos falla. Para mitigar esta situación, puedes implementar un algoritmo de retirada exponencial truncada a fin de permitir que el sistema de POS vuelva a intentar la operación de transferencia de datos. Debido a que Cloud Storage proporciona una durabilidad de nueve nueve, la transferencia de datos y la canalización de procesamiento posterior se reanudarán con poca o ninguna pérdida de datos después de que se reanude el servicio de Cloud Storage.

  • Haz copias de los datos transferidos. Cloud Storage admite tipos de ubicación multirregión y birregionales. Según tus requisitos de localidad de datos, es posible que puedas configurar un bucket de Cloud Storage multirregión o de región doble para aumentar la disponibilidad de los datos. También puedes usar herramientas como gsutil para sincronizar datos entre Cloud Storage y otra ubicación.

Organización y procesamiento de datos de POS transferidos

En el diagrama de arquitectura del caso práctico por lotes, Cloud Composer realiza los siguientes pasos:

  • Valida si se subieron archivos nuevos al bucket de transferencia de Cloud Storage.
  • Inicia un clúster efímero de Dataproc.
  • Inicia un trabajo de Apache Spark para procesar los datos.
  • Borra el clúster de Dataproc al final del trabajo.

Cloud Composer usa archivos de grafo acíclico dirigido (DAG) que definen estas series de pasos. Estos archivos DAG se almacenan en un bucket de Cloud Storage que no se muestra en el diagrama de arquitectura. En términos de localidad birregional y multirregión, las consideraciones de DR para el bucket de archivos del DAG son las mismas que las que se analizan con el bucket de transferencia.

Los clústeres de Dataproc son efímeros. Es decir, los clústeres solo existen mientras se ejecute la etapa de procesamiento. Esta naturaleza efímera significa que no tienes que hacer nada de manera explícita para la DR en relación con los clústeres de Dataproc.

Almacenamiento de data lakes con Cloud Storage

El bucket de Cloud Storage que usas para el data lake tiene las mismas consideraciones de localidad que las que se analizan en el bucket de transferencia: consideraciones de doble región y multirregión, el uso de la encriptación y el uso de gsutil rsync.

Cuando diseñes el plan de DR para tu data lake, ten en cuenta los siguientes aspectos:

  • Tamaño de los datos. El volumen de datos en un data lake puede ser grande. Restablecer un gran volumen de datos lleva tiempo. En una situación de DR, debes considerar el impacto que tiene el volumen del data lake en la cantidad de tiempo que le toma a
    restablecer los datos a un punto que cumpla con los siguientes criterios:

    Para el caso práctico por lotes actual, Cloud Storage se usa a fin de proporcionar la ubicación del data lake y proporciona una durabilidad de 11 nueves. Sin embargo, los ataques de ransomware aumentaron. Para garantizar que puedas recuperarte de esos ataques, sería prudente seguir las prácticas recomendadas que se describen en:Cómo Cloud Storage ofrece 11 nueves de durabilidad.

  • Dependencia de datos. Por lo general, otros componentes de un sistema de análisis de datos, como una canalización de procesamiento, consumen datos en data lakes. En una situación de DR, la canalización de procesamiento y los datos de los que depende deben compartir el mismo RTO. En este contexto, enfócate en cuánto tiempo puede pasar el sistema sin estar disponible.

  • Edad de los datos. Los datos históricos pueden permitir un RPO más alto. Es posible que otros componentes de análisis de datos ya hayan analizado o procesado este tipo de datos y podrían haberse conservado en otro componente que tiene sus propias estrategias de DR. Por ejemplo, los registros de ventas que se exportan a Cloud Storage se importan a diario a BigQuery para su análisis. Con las estrategias de DR adecuadas para BigQuery, es posible que los registros de ventas históricos que se importaron a BigQuery tengan objetivos de recuperación más bajos que los que no se importaron.

Almacenamiento de metadatos de data lake con Dataproc Metastore

Dataproc Metastore es un almacén de metadatos de Apache Hive que es completamente administrado, tiene alta disponibilidad, reparación automática y sin servidores. El almacén de metadatos proporciona funciones de abstracción de datos y descubrimiento de datos. El almacén de metadatos puede crear una copia de seguridad y restablecerse en caso de que ocurra un desastre. El servicio de Dataproc Metastore también te permite importar y exportar metadatos. Puedes agregar una tarea para exportar el almacén de metadatos y mantener una copia de seguridad externa junto con el trabajo de ETL.

Si encuentras una situación en la que hay una discrepancia de metadatos, puedes volver a crear el almacén de metadatos a partir de los datos con el comando MSCK.

Caso práctico de transmisión: captura de datos modificados con ELTl

El segundo caso práctico describe una plataforma de venta minorista que usa la captura de datos modificados (CDC) para actualizar los sistemas de inventario de backend y realizar un seguimiento de las métricas de ventas en tiempo real. En el siguiente diagrama, se muestra una arquitectura en la que los eventos de una base de datos transaccional, como Cloud SQL, se procesan y se almacenan en un almacén de datos.

Diagrama de arquitectura de un caso práctico de transmisión que implica la captura de datos modificados de los datos minoristas.

La arquitectura incluye las siguientes fases y componentes:

  • La fase de transferencia consta de los eventos de cambio entrantes que se envían a Pub/Sub. Como servicio de entrega de mensajes, Pub/Sub se usa para transferir y distribuir de forma confiable datos de estadísticas de transmisión. Pub/Sub tiene los beneficios adicionales de ser escalable y sin servidores.
  • La fase de procesamiento implica el uso de Dataflow para realizar un proceso ELT en los eventos transferidos.
  • La fase del almacén de datos usa BigQuery para almacenar los eventos procesados. La operación de combinación inserta o actualiza un registro en BigQuery. Esta operación permite que la información almacenada en BigQuery se mantenga actualizada con la base de datos transaccional.

Aunque esta arquitectura de CDC no se basa en Cloud Composer, algunas arquitecturas de CDC requieren que Cloud Composer organice la integración de la transmisión en cargas de trabajo por lotes. En esos casos, el flujo de trabajo de Cloud Composer implementa verificaciones de integridad, reabastecimientos y proyecciones que no se pueden realizar en tiempo real debido a restricciones de latencia. Las técnicas de DR para Cloud Composer se analizan en el caso de uso de procesamiento por lotes que se explicó antes en el documento.

Para una canalización de datos de transmisión, debes considerar lo siguiente cuando planifiques tu arquitectura de DR:

  • Dependencias de canalización. Las canalizaciones de procesamiento toman entradas de uno o más sistemas (las fuentes). Luego, las canalizaciones procesan, transforman y almacenan estas entradas en otros sistemas (los receptores). Es importante diseñar tu arquitectura de DR para lograr tu RTO de extremo a extremo. Debes asegurarte de que el RPO de las fuentes de datos y los receptores te permita cumplir con el RTO. Además de diseñar tu arquitectura de nube para cumplir con los requisitos de localidad, también deberás diseñar tus fuentes de CDC de origen a fin de permitir que se cumpla tu RTO de extremo a extremo.
  • Encriptación y localidad. Si la encriptación te permite mitigar las restricciones de localidad, puedes usar Cloud KMS para lograr los siguientes objetivos:
    • Administra tus propias claves de encriptación.
    • Aprovechar la capacidad de encriptación de los servicios individuales.
    • Implementar servicios en regiones que, de lo contrario, no estarían disponibles debido a restricciones de localidad.
  • Reglas de localidad de los datos en movimiento. Algunas reglas de localidad pueden aplicarse solo a los datos en reposo, pero no a los datos en movimiento. Si las reglas de localidad no se aplican a los datos en movimiento, diseña la arquitectura de DR para aprovechar los recursos en otras regiones a fin de mejorar los objetivos de recuperación. Puedes complementar el enfoque regional mediante la integración de técnicas de encriptación.

Transferencia a Pub/Sub

Si no tienes restricciones de localidad, puedes publicar mensajes en el extremo global de Pub/Sub. Los extremos de Pub/Sub globales son visibles y se puede acceder a ellos desde cualquier ubicación de Google Cloud.

Si tus requisitos de localidad permiten el uso de la encriptación, es posible configurar Pub/Sub para lograr un nivel similar de alta disponibilidad como extremos globales. Aunque los mensajes de Pub/Sub se encriptan con claves administradas por Google de forma predeterminada, puedes configurar Pub/Sub para usar CMEK en su lugar. Si usas Pub/Sub con CMEK, puedes cumplir con las reglas de localidad sobre la encriptación, a la vez que mantienes una alta disponibilidad.

Algunas reglas de localidad requieren que los mensajes permanezcan en una ubicación específica incluso después de la encriptación. Si tus reglas de localidad tienen esta restricción, puedes especificar la política de almacenamiento de mensajes de un tema de Pub/Sub y restringirla a una región. Si usas este enfoque de almacenamiento de mensajes, los mensajes que se publican en un tema nunca se mantienen fuera del conjunto de regiones de Google Cloud que especifiques. Si tus reglas de localidad permiten que se use más de una región de Google Cloud, puedes aumentar la disponibilidad del servicio si habilitas esas regiones en el tema de Pub/Sub. Debes tener en cuenta que implementar una política de almacenamiento de mensajes para restringir las ubicaciones de los recursos de Pub/Sub viene con compensaciones relacionadas con la disponibilidad.

Una suscripción a Pub/Sub te permite almacenar mensajes no confirmados por hasta 7 días sin restricciones para la cantidad de mensajes. Si tu Acuerdo de Nivel de Servicio permite datos retrasados, puedes almacenar los datos en tu suscripción de Pub/Sub si las canalizaciones dejan de ejecutarse. Cuando las canalizaciones se ejecutan de nuevo, puedes procesar los eventos con copia de seguridad. Este diseño tiene el beneficio de tener un RPO bajo. Para obtener más información sobre los límites de recursos de Pub/Sub, consulta los límites de recursos para cuotas de Pub/Sub.

Procesamiento de eventos con Dataflow

Dataflow es un servicio administrado que ejecuta una amplia variedad de patrones de procesamiento de datos. El SDK de Apache Beam es un modelo de programación de código abierto que te permite desarrollar canalizaciones de transmisión y por lotes. Puedes crear tus canalizaciones con un programa de Apache Beam y, luego, ejecutarlas en el servicio de Dataflow.

Cuando diseñes para las restricciones de localidad, debes considerar dónde se encuentran tus fuentes, receptores y archivos temporales. Si estas ubicaciones de archivos están fuera de la región de tu trabajo, es posible que tus datos se envíen a través de las regiones. Si las reglas de localidad permiten que los datos se procesen en una ubicación diferente, diseña la arquitectura de DR para implementar trabajadores en otras regiones de Google Cloud a fin de proporcionar alta disponibilidad.

Si las restricciones de localidad limitan el procesamiento a una sola ubicación, puedes crear un trabajo de Dataflow que esté restringido a una región o zona específica. Cuando envías un trabajo de Dataflow, puedes especificar los parámetros del extremo regional, región del trabajador y zona del trabajador. Estos parámetros controlan dónde se implementan los trabajadores y dónde se almacenan los metadatos del trabajo.

Apache Beam proporciona un marco de trabajo que permite que las canalizaciones se ejecuten en varios ejecutores. Puedes diseñar tu arquitectura de DR para aprovechar esta capacidad. Por ejemplo, puedes diseñar una arquitectura de DR a fin de tener una canalización de copia de seguridad que se ejecute en tu clúster local de Spark con Apache Spark Runner. Para obtener información sobre si un ejecutor específico es capaz de llevar a cabo una operación de canalización determinada, consulta Matriz de capacidad de Beam.

Si la encriptación te permite mitigar las restricciones de localidad, puedes usar CMEK en Dataflow para encriptar artefactos de estado de la canalización y acceder a fuentes y receptores protegidos con claves de Cloud KMS. Mediante la encriptación, puedes diseñar una arquitectura de DR que use regiones que, de lo contrario, no estarían disponibles debido a las restricciones de localidad.

Almacén de datos compilado en BigQuery

Los almacenes de datos son compatibles con las estadísticas y la toma de decisiones. Además de contener una base de datos de estadísticas, los almacenes de datos contienen varios componentes y procedimientos analíticos.

Cuando diseñes el plan de DR para tu almacén de datos, ten en cuenta las siguientes características:

  • Tamaño. Los almacenes de datos son mucho más grandes que los sistemas de procesamiento de transacciones en línea (OLTP). Es común que los almacenes de datos tengan terabytes de petabytes de datos. Debes considerar cuánto tiempo tomaría restablecer estos datos para lograr los valores de RPO y RTO. Cuando planifiques tu estrategia de DR, también debes tener en cuenta el costo asociado con la recuperación de terabytes de datos. Si deseas obtener más información sobre las técnicas de mitigación de DR para BigQuery, consulta la información de BigQuery en la sección sobre mecanismos de copia de seguridad y recuperación para los servicios de base de datos administradas en Google Cloud.

  • Disponibilidad. Cuando creas un conjunto de datos de BigQuery, debes seleccionar una ubicación en la que puedas almacenar tus datos: regional o multirregional. Una ubicación regional es una ubicación geográfica única y específica, como Iowa (us-central1) o Montreal (northamerica-northeast1). Una ubicación multirregional es un área geográfica grande, como los Estados Unidos (EE.UU.) o Europa (UE), que contiene dos o más lugares geográficos.

    Cuando diseñes tu plan de DR para cumplir con las restricciones de localidad, el dominio de falla (es decir, si la falla ocurre a nivel de máquina, zonal o regional) tendrá un impacto directo en el cumplimiento de tu definición. RTO. Para obtener más información sobre estos dominios con fallas y cómo afectan la disponibilidad, consulta Disponibilidad y durabilidad de BigQuery.

  • Naturaleza de los datos. Los almacenes de datos contienen información histórica, y la mayoría de los datos más antiguos son estáticos. Muchos almacenes de datos están diseñados para ser solo anexables. Si tu almacén de datos es solo para agregar, es posible que puedas lograr tu RTO si restableces solo los datos que se agregan. En este enfoque, creas una copia de seguridad solo de estos datos agregados. Si hay un desastre, podrás restablecer los datos agregados y tener tu almacén de datos disponible para usar, pero con un subconjunto de ellos.

  • Patrón de actualización y adición de datos. Por lo general, los almacenes de datos se actualizan con patrones ETL o ELT. Cuando controlas las rutas de actualización, puedes reproducir eventos de actualización recientes de fuentes alternativas.

Es posible que tus requisitos de localidad limiten si puedes usar una o varias regiones para tu almacén de datos. Aunque los conjuntos de datos de BigQuery pueden ser regionales, el almacenamiento multirregional es la forma más simple y rentable de garantizar la disponibilidad de tus datos si ocurre un desastre. Si el almacenamiento multirregión no está disponible en tu región, pero puedes usar una diferente, usa el Servicio de transferencia de datos de BigQuery para copiar tu conjunto de datos en una región diferente. Si puedes usar la encriptación para mitigar los requisitos de localidad, puedes administrar tus propias claves de encriptación con Cloud KMS y BigQuery.

Si solo puedes usar una región, considera crear una copia de seguridad de las tablas de BigQuery. La solución más rentable para crear tablas de copia de seguridad es usar las exportaciones de BigQuery. Usa Cloud Scheduler o Cloud Composer para programar un trabajo de exportación a fin de escribir en Cloud Storage de forma periódica. Puedes usar formatos como Avro con compresión SNAPPY o JSON con compresión GZIP. Mientras diseñas tus estrategias de exportación, ten en cuenta los límites en las exportaciones.

También puedes almacenar copias de seguridad de BigQuery en formatos de columna, como Parquet y ORC. Estas proporcionan una alta compresión y también permiten la interoperabilidad con muchos motores de código abierto, como Hive y Presto, que puedes tener en tus sistemas locales. En el siguiente diagrama, se describe el proceso de exportación de datos de BigQuery a un formato de columna para el almacenamiento en una ubicación local.

Diagrama de arquitectura que muestra la exportación de datos de BigQuery a un almacenamiento en columnas para la recuperación ante desastres.

En particular, este proceso de exportación de datos de BigQuery a una ubicación de almacenamiento local implica los siguientes pasos:

  • Los datos de BigQuery se envían a un trabajo de Apache Spark en Dataproc. El uso del trabajo de Apache Spark permite la evolución de esquema.
  • Después de que el trabajo de Dataproc procesó los archivos de BigQuery, los archivos procesados se escriben en Cloud Storage y, luego, se transfieren a una ubicación de DR local.
  • Cloud Interconnect se usa para conectar tu red de nube privada virtual a tu red local.
  • La transferencia a la ubicación de DR local puede ocurrir a través del trabajo de Spark.

Si el diseño de tu almacén es de solo anexo y está particionado por fecha, debes crear una copia de las particiones necesarias en una tabla nueva antes de ejecutar un trabajo de exportación de BigQuery en la tabla nueva. Luego, puedes usar una herramienta como gsutil para transferir los archivos actualizados a tu ubicación de copia de seguridad local o en otra nube. (Es posible que se apliquen cargos de salida cuando transfieres datos fuera de Google Cloud).

Por ejemplo, tienes un almacén de datos de ventas que consta de una tabla orders de solo adición en la que se agregan pedidos nuevos a la partición que representa la fecha actual. Sin embargo, una política de devolución puede permitir que los elementos se muestren en un plazo de 7 días. Por lo tanto, es posible que se actualicen los registros de la tabla orders correspondientes a los últimos 7 días. Tus estrategias de exportación deben tener en cuenta la política de retorno. En este ejemplo, cualquier trabajo de exportación para crear una copia de seguridad de la tabla orders también debe exportar las particiones que representan pedidos en los últimos 7 días a fin de evitar actualizaciones faltantes debido a devoluciones.

¿Qué sigue?