Casos prácticos de recuperación tras desastres: aplicaciones de analíticas de datos restringidas a una localidad

Last reviewed 2024-07-20 UTC

Este documento forma parte de una serie sobre la recuperación tras fallos en Google Cloud. En este documento se describe cómo aplicar las restricciones de localidad del documento Diseño de la recuperación tras fallos para cargas de trabajo con restricciones de localidad a las aplicaciones de analíticas de datos. En concreto, en este documento se describe cómo encajan los componentes que utiliza en una plataforma de analíticas de datos en una arquitectura de recuperación ante desastres que cumpla las restricciones de localidad a las que puedan estar sujetos sus aplicaciones o datos.

La serie consta de las siguientes partes:

Este documento está dirigido a arquitectos de sistemas y responsables de TI. Se presupone que tienes los siguientes conocimientos y habilidades:

Requisitos de localidad de una plataforma de analíticas de datos

Las plataformas de analíticas de datos suelen ser aplicaciones complejas de varios niveles que almacenan datos en reposo. Estas aplicaciones generan eventos que se procesan y almacenan en su sistema de analíticas. Tanto la aplicación como los datos almacenados en el sistema pueden estar sujetos a normativas locales. Estas normativas varían no solo de un país a otro, sino también de un sector a otro. Por lo tanto, debes tener claro cuáles son tus requisitos de localidad de los datos antes de empezar a diseñar tu arquitectura de recuperación ante desastres.

Para determinar si tu plataforma de analíticas de datos tiene requisitos de localidad, responde a las dos preguntas siguientes:

  • ¿Tu aplicación debe desplegarse 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 analíticas de datos no tiene ningún requisito específico de localidad. Como tu plataforma no tiene requisitos de localidad, sigue las directrices de recuperación ante desastres para servicios y productos conformes que se indican en la guía de planificación de recuperación ante desastres.

Sin embargo, si respondes "sí" a alguna de las preguntas, tu solicitud estará restringida a una localidad. Como tu plataforma de analíticas está restringida por localidad, debes hacer la siguiente pregunta: ¿Puedes usar técnicas de cifrado para mitigar los requisitos de datos en reposo?

Si puedes usar técnicas de cifrado, puedes usar los servicios multirregionales 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 tras fallos (HA/DR) que se describen en Situaciones de recuperación tras fallos con los datos.

Si no puedes usar técnicas de cifrado, debes usar soluciones personalizadas u ofertas de partners para planificar la recuperación ante desastres. Para obtener más información sobre las técnicas para abordar las restricciones de localidad en escenarios de recuperación ante desastres, consulta el artículo Diseñar la recuperación ante desastres para cargas de trabajo con restricciones de localidad.

Componentes de una plataforma de analíticas de datos

Una vez que conozcas los requisitos de localidad, el siguiente paso es familiarizarte con los componentes que usa tu plataforma de analíticas de datos. Algunos componentes habituales de una plataforma de analíticas de datos son las bases de datos, los data lakes, los flujos de procesamiento y los almacenes de datos, como se describe en la siguiente lista:

  • Google Cloud tiene un conjunto de servicios de bases de datos que se adaptan a diferentes casos prácticos.

  • Los data lakes, los almacenes de datos y las pipelines de procesamiento pueden tener definiciones ligeramente diferentes. En este documento se utiliza un conjunto de definiciones que hacen referencia a Google Cloud servicios:

    • Un lago de datos es una plataforma escalable y segura para ingerir y almacenar datos de varios sistemas. Un lago de datos típico puede usar Cloud Storage como repositorio de almacenamiento central.
    • Una canalización de procesamiento es un proceso integral que toma datos o eventos de uno o varios sistemas, los transforma y los carga en otro sistema. El flujo de datos puede seguir un proceso de extracción, transformación y carga (ETL) o de extracción, carga y transformación (ELT). Normalmente, el sistema en el que se cargan los datos procesados es un almacén de datos. Pub/Sub, Dataflow y Dataproc son componentes que se suelen usar en un flujo de procesamiento.
    • Un almacén de datos es un sistema empresarial que se usa para analizar y generar informes de datos, que suelen proceder de una base de datos operativa. BigQuery es un sistema de almacén de datos que se usa con frecuencia y que se ejecuta en Google Cloud.

La implementación de la recuperación ante desastres varía en función de los requisitos de localidad y de los componentes de analíticas de datos que utilices. En las siguientes secciones se muestra esta variación con dos casos prácticos.

Caso práctico de procesamiento por lotes: un trabajo de ETL periódico

En el primer caso práctico se describe un proceso por lotes en el que una plataforma de comercio minorista recoge periódicamente eventos de ventas como archivos de varias tiendas y, a continuación, escribe los archivos en un segmento de Cloud Storage. En el siguiente diagrama se muestra la arquitectura de analíticas de datos de la tarea por lotes de este comercio.

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

La arquitectura incluye las siguientes fases y componentes:

  • La fase de ingestión consiste en que las tiendas envían sus datos de punto de venta (PdV) a Cloud Storage. Estos datos insertados están pendientes de procesarse.
  • En la fase de orquestación se usa Cloud Composer para orquestar el flujo de procesamiento por lotes de principio a fin.
  • La fase de procesamiento implica una tarea de Apache Spark que se ejecuta en un clúster de Dataproc. La tarea de Apache Spark realiza un proceso de ETL en los datos ingeridos. Este proceso de ETL proporciona métricas empresariales.
  • En la fase de lago de datos, se toman los datos procesados y se almacena información en los siguientes componentes:
    • Los datos procesados se suelen almacenar en formatos de columnas de Cloud Storage, como Parquet y ORC, ya 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 de proceso (como bases de datos, tablas, columnas y particiones) se almacenan en el servicio de almacén de metadatos de Hive proporcionado por Dataproc Metastore.

En situaciones con restricciones de localidad, puede ser difícil proporcionar capacidad de procesamiento y orquestación redundante para mantener la disponibilidad. Como los datos se procesan en lotes, las canalizaciones de procesamiento y de orquestación se pueden volver a crear y las tareas por lotes se pueden reiniciar una vez que se haya resuelto un problema. Por lo tanto, en la recuperación tras desastres, el objetivo principal es recuperar los datos reales: los datos de POS insertados, los datos procesados almacenados en el data lake y los metadatos almacenados en el data lake.

Ingestión en Cloud Storage

Lo primero que debes tener en cuenta son los requisitos de localidad del segmento de Cloud Storage que se usa para ingerir los datos del sistema de punto de venta. Usa esta información de localidad cuando tengas en cuenta las siguientes opciones:

  • Si los requisitos de localidad permiten que los datos en reposo se encuentren en una de las ubicaciones multirregionales o birregionales, elige el tipo de ubicación correspondiente al crear el segmento de Cloud Storage. El tipo de ubicación que elijas define las regiones que se usan para replicar tus datos en reposo. Google Cloud Si se produce una interrupción en una de las regiones, se podrá seguir accediendo a los datos que residan en segmentos multirregionales o birregionales.
  • Cloud Storage también admite claves de cifrado gestionadas por el cliente (CMEK) y claves de cifrado proporcionadas por el cliente (CSEK). Algunas reglas de localidad permiten que los datos en reposo se almacenen en varias ubicaciones cuando se usan CMEK o CSEK para gestionar las claves. Si tus reglas de localidad permiten el uso de CMEK o CSEK, puedes diseñar tu arquitectura de recuperación ante desastres para que use regiones de Cloud Storage.
  • Es posible que tus requisitos de localidad no te permitan usar ni tipos de ubicación ni gestión de claves de cifrado. Si no puedes usar los tipos de ubicación o la gestión de claves de cifrado, puedes usar el comando gcloud storage rsync para sincronizar datos con otra ubicación, como un almacenamiento local o soluciones de almacenamiento de otro proveedor de la nube.

Si se produce un desastre, es posible que los datos de los puntos de venta insertados en el segmento de Cloud Storage incluyan datos que aún no se hayan procesado ni importado en el lago de datos. De lo contrario, es posible que los datos del TPV no se puedan ingerir en el segmento de Cloud Storage. En estos casos, tienes las siguientes opciones de recuperación ante desastres:

  • Deja que el sistema de PdV vuelva a intentarlo. Si el sistema no puede escribir los datos del TPV en Cloud Storage, el proceso de ingestión de datos fallará. Para mitigar esta situación, puedes implementar una estrategia de reintento para permitir que el sistema de punto de venta vuelva a intentar la operación de ingestión de datos. Como Cloud Storage ofrece una alta durabilidad, la ingestión de datos y la canalización de procesamiento posterior se reanudarán con una pérdida de datos mínima o nula después de que se reanude el servicio Cloud Storage.

  • Crea copias de los datos ingeridos. Cloud Storage admite los tipos de ubicación multirregional y birregional. En función de tus requisitos de localidad de los datos, puedes configurar un segmento de Cloud Storage multirregional o de dos regiones para aumentar la disponibilidad de los datos. También puedes usar herramientas como el comando gcloud storage Google Cloud CLI para sincronizar datos entre Cloud Storage y otra ubicación.

Orquestación y tratamiento de los datos de PdV insertados

En el diagrama de arquitectura del caso práctico de procesamiento por lotes, Cloud Composer lleva a cabo los siguientes pasos:

  • Valida que se hayan subido archivos nuevos al segmento de ingestión de Cloud Storage.
  • Inicia un clúster de Dataproc efímero.
  • Inicia un trabajo de Apache Spark para procesar los datos.
  • Elimina el clúster de Dataproc al final del trabajo.

Cloud Composer usa archivos de grafo acíclico dirigido (DAG) para definir estas series de pasos. Estos archivos DAG se almacenan en un segmento de Cloud Storage que no se muestra en el diagrama de arquitectura. En cuanto a la localidad birregional y multirregional, las consideraciones de recuperación ante desastres del segmento de archivos DAG son las mismas que las que se han tratado en el segmento de ingestión.

Los clústeres de Dataproc son efímeros. Es decir, los clústeres solo existen mientras se ejecuta la fase de procesamiento. Esta naturaleza efímera significa que no tienes que hacer nada de forma explícita para la recuperación ante desastres en relación con los clústeres de Dataproc.

Almacenamiento de lagos de datos con Cloud Storage

El segmento de Cloud Storage que uses para el lago de datos tiene las mismas consideraciones de localidad que las que se han descrito para el segmento de ingestión: consideraciones birregionales y multirregionales, el uso del cifrado y el uso del comando gcloud storage rsync de la CLI de gcloud.

Al diseñar el plan de recuperación tras desastres de tu lago de datos, ten en cuenta los siguientes aspectos:

  • Tamaño de los datos. El volumen de datos de un lago de datos puede ser grande. Restaurar un gran volumen de datos lleva tiempo. En un escenario de recuperación ante desastres, debe tener en cuenta el impacto que tiene el volumen del lago de datos en el tiempo que se tarda en restaurar los datos hasta un punto que cumpla los siguientes criterios:

    En el caso práctico del lote actual, Cloud Storage se usa para la ubicación del lago de datos y proporciona una alta durabilidad. Sin embargo, los ataques de ransomware han ido en aumento. Para asegurarte de que puedes recuperarte de estos ataques, te recomendamos que sigas las prácticas recomendadas que se describen en el artículo Cómo ofrece Cloud Storage una durabilidad de 11 nueves.

  • Dependencia de los datos. Los datos de los lagos de datos suelen ser consumidos por otros componentes de un sistema de analíticas de datos, como un flujo de procesamiento. En un escenario de recuperación ante desastres, el flujo de procesamiento y los datos de los que depende deben compartir el mismo tiempo de recuperación. En este contexto, céntrate en cuánto tiempo puedes permitir que el sistema no esté disponible.

  • Antigüedad de los datos. El historial de datos puede permitir un RPO más alto. Es posible que este tipo de datos ya se haya analizado o procesado mediante otros componentes de analíticas de datos y que se haya conservado en otro componente que tenga sus propias estrategias de recuperación ante desastres. Por ejemplo, los registros de ventas que se exportan a Cloud Storage se importan a BigQuery a diario para analizarlos. Con las estrategias de recuperación ante desastres adecuadas para BigQuery, los registros de ventas históricos que se hayan importado a BigQuery pueden tener objetivos de recuperación más bajos que los que no se hayan importado.

Almacenamiento de metadatos de lagos de datos con Dataproc Metastore

Dataproc Metastore es un almacén de metadatos de Apache Hive totalmente gestionado, de alta disponibilidad, con reparación automática y sin servidor. El metastore proporciona funciones de abstracción y descubrimiento de datos. La metastore se puede respaldar y restaurar en caso de desastre. El servicio Dataproc Metastore también te permite exportar e importar metadatos. Puedes añadir una tarea para exportar el metastore y mantener una copia de seguridad externa junto con tu trabajo de ETL.

Si se produce una situación en la que hay una discrepancia en los metadatos, puede volver a crear el metastore a partir de los datos mediante el comando MSCK.

Caso práctico de streaming: captura de datos de cambios mediante ELT

El segundo caso de uso describe una plataforma de comercio que utiliza la captura de datos de cambios (CDC) para actualizar los sistemas de inventario backend y monitorizar las métricas de ventas en tiempo real. En el siguiente diagrama se muestra una arquitectura en la que se procesan los eventos de una base de datos transaccional, como Cloud SQL, y se almacenan en un almacén de datos.

Diagrama de arquitectura de un caso práctico de streaming que implica la captura de datos de cambios de datos de comercio.

La arquitectura incluye las siguientes fases y componentes:

  • La fase de ingestión consiste en enviar los eventos de cambio entrantes a Pub/Sub. Como servicio de entrega de mensajes, Pub/Sub se usa para ingerir y distribuir de forma fiable datos de analíticas en tiempo real. Pub/Sub también ofrece las ventajas de ser escalable y sin servidor.
  • La fase de procesamiento implica usar Dataflow para llevar a cabo un proceso de ELT en los eventos ingeridos.
  • En la fase de almacén de datos se 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 depende de Cloud Composer, algunas arquitecturas de CDC requieren Cloud Composer para orquestar la integración del flujo en cargas de trabajo por lotes. En esos casos, el flujo de trabajo de Cloud Composer implementa comprobaciones de integridad, rellenos y proyecciones que no se pueden realizar en tiempo real debido a las restricciones de latencia. Las técnicas de recuperación ante desastres de Cloud Composer se describen en el caso práctico de procesamiento por lotes que se ha explicado anteriormente en el documento.

En el caso de las canalizaciones de datos de streaming, debe tener en cuenta lo siguiente al planificar su arquitectura de recuperación ante desastres:

  • Dependencias de los flujos de procesamiento. Las canalizaciones de procesamiento reciben datos de uno o varios sistemas (las fuentes). A continuación, las canalizaciones procesan, transforman y almacenan estas entradas en otros sistemas (los receptores). Es importante diseñar tu arquitectura de recuperación ante desastres para conseguir el RTO de extremo a extremo. Debes asegurarte de que el RPO de las fuentes y los receptores de datos te permita cumplir el RTO. Además de diseñar tu arquitectura de nube para cumplir los requisitos de localidad, también tendrás que diseñar tus fuentes de CDC originales para que se cumpla el tiempo de recuperación objetivo de extremo a extremo.
  • Cifrado y localidad. Si el cifrado te permite mitigar las restricciones de localidad, puedes usar Cloud KMS para alcanzar los siguientes objetivos:
    • Gestiona tus propias claves de cifrado.
    • Aprovecha la función de cifrado de los servicios individuales.
    • Implementar servicios en regiones en las que, de lo contrario, no se podrían usar debido a restricciones de localidad.
  • Reglas de localidad sobre los datos en movimiento. Es posible que algunas reglas de localidad se apliquen solo a los datos en reposo, pero no a los datos en movimiento. Si tus reglas de localidad no se aplican a los datos en movimiento, diseña tu arquitectura de recuperación ante desastres para que use recursos de otras regiones y así mejorar los objetivos de recuperación. Puedes complementar el enfoque regional integrando técnicas de cifrado.

Ingestión en Pub/Sub

Si no tienes restricciones de localidad, puedes publicar mensajes en el endpoint global de Pub/Sub. Los endpoints de Pub/Sub globales son visibles y accesibles desde cualquierGoogle Cloud ubicación.

Si los requisitos de tu localidad permiten el uso del cifrado, puedes configurar Pub/Sub para conseguir un nivel de alta disponibilidad similar al de los endpoints globales. Aunque los mensajes de Pub/Sub se cifran conGoogle-owned and Google-managed encryption keys de forma predeterminada, puedes configurar Pub/Sub para que use CMEK en su lugar. Si usas Pub/Sub con CMEK, puedes cumplir las reglas de localidad sobre el cifrado y, al mismo tiempo, mantener una alta disponibilidad.

Algunas reglas de localidad requieren que los mensajes permanezcan en una ubicación específica incluso después del cifrado. 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 utiliza este método de almacenamiento de mensajes, los mensajes que se publican en un tema nunca se conservan fuera del conjunto de regiones de Google Cloud que especifique. Si las reglas de localidad permiten usar más de una Google Cloud región, puedes aumentar la disponibilidad del servicio habilitando esas regiones en el tema de Pub/Sub. Debes tener en cuenta que, al implementar una política de almacenamiento de mensajes para restringir las ubicaciones de recursos de Pub/Sub, se producen intercambios en cuanto a la disponibilidad.

Una suscripción de Pub/Sub te permite almacenar mensajes no confirmados durante un máximo de 7 días sin restricciones en el número de mensajes. Si tu acuerdo de nivel de servicio permite que los datos se retrasen, puedes almacenarlos en el búfer de tu suscripción de Pub/Sub si las canalizaciones dejan de ejecutarse. Cuando las canalizaciones vuelvan a estar activas, podrás procesar los eventos de la copia de seguridad. Este diseño tiene la ventaja 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 de las cuotas de Pub/Sub.

Procesamiento de eventos con Dataflow

Dataflow es un servicio gestionado para ejecutar una amplia variedad de patrones de tratamiento de datos. El SDK de Apache Beam es un modelo de programación de código abierto que te permite desarrollar flujos de procesamiento por lotes y de streaming. Crea tus flujos de procesamiento con un programa de Apache Beam y, a continuación, ejecútalos en el servicio Dataflow.

Cuando diseñes para cumplir las restricciones de localidad, debes tener en cuenta 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 otras regiones. Si tus reglas de localidad permiten que los datos se procesen en otra ubicación, diseña tu arquitectura de recuperación ante desastres para implementar trabajadores en otras regiones y ofrecer una alta disponibilidad. Google Cloud

Si las restricciones de localidad limitan el tratamiento a una sola ubicación, puedes crear una tarea de Dataflow que esté restringida a una región o zona específica. Cuando envías una tarea de Dataflow, puedes especificar los parámetros punto de conexión regional, región de los trabajadores y zona de los trabajadores. Estos parámetros controlan dónde se despliegan los trabajadores y dónde se almacenan los metadatos de los trabajos.

Apache Beam proporciona un marco que permite ejecutar las canalizaciones en varios ejecutores. Puedes diseñar tu arquitectura de recuperación ante desastres para aprovechar esta función. Por ejemplo, puedes diseñar una arquitectura de recuperación ante desastres para que tenga una canalización de copia de seguridad que se ejecute en tu clúster de Spark local on-premise mediante Apache Spark Runner. Para saber si un runner específico puede llevar a cabo una determinada operación de la canalización, consulta la matriz de funciones de Beam.

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

Almacén de datos creado en BigQuery

Los almacenes de datos admiten analíticas y la toma de decisiones. Además de contener una base de datos analítica, los almacenes de datos incluyen varios componentes y procedimientos analíticos.

Al diseñar el plan de recuperación ante desastres de 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 online (OLTP). No es raro que los almacenes de datos tengan entre terabytes y petabytes de datos. Debes tener en cuenta cuánto tiempo tardarías en restaurar estos datos para alcanzar los valores de RPO y RTO. Al planificar tu estrategia de recuperación ante desastres, también debes tener en cuenta el coste asociado a la recuperación de terabytes de datos. Para obtener más información sobre las técnicas de mitigación de desastres en BigQuery, consulta la información sobre BigQuery en la sección sobre mecanismos de copia de seguridad y recuperación de los servicios de bases de datos gestionados en Google Cloud.

  • Disponibilidad. Cuando creas un conjunto de datos de BigQuery, seleccionas una ubicación en la que almacenar los datos: regional o multirregional. Una ubicación regional es una ubicación geográfica específica, como Iowa (us-central1). Una ubicación multirregional es una zona geográfica grande, como Estados Unidos o Europa, que contiene dos o más ubicaciones geográficas.

    Al diseñar tu plan de recuperación ante desastres para cumplir las restricciones de localidad, el dominio de error (es decir, si el error se produce a nivel de máquina, de zona o regional) influirá directamente en el cumplimiento del tiempo de recuperación definido. Para obtener más información sobre estos dominios de errores y cómo afectan a 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 antiguos suelen ser estáticos. Muchos almacenes de datos se diseñan para que solo se puedan añadir datos. Si tu almacén de datos es de solo anexión, es posible que puedas alcanzar el tiempo de recuperación restaurando solo los datos que se están añadiendo. Con este método, solo se crea una copia de seguridad de los datos añadidos. Si se produce un desastre, podrá restaurar los datos añadidos y usar su almacén de datos, pero con un subconjunto de los datos.

  • Patrón de adición y actualización de datos. Los almacenes de datos se suelen actualizar mediante patrones ETL o ELT. Si tienes rutas de actualización controladas, puedes reproducir eventos de actualización recientes desde fuentes alternativas.

Tus requisitos de localidad pueden limitar 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 sencilla y rentable de asegurar la disponibilidad de tus datos en caso de desastre. Si el almacenamiento multirregional no está disponible en tu región, pero puedes usar otra, utiliza BigQuery Data Transfer Service para copiar tu conjunto de datos en otra región. Si puedes usar el cifrado para mitigar los requisitos de localidad, puedes gestionar tus propias claves de cifrado con Cloud KMS y BigQuery.

Si solo puedes usar una región, te recomendamos que crees una copia de seguridad de las tablas de BigQuery. La solución más rentable para crear copias de seguridad de tablas es usar exportaciones de BigQuery. Usa Cloud Scheduler o Cloud Composer para programar periódicamente una tarea de exportación que escriba en Cloud Storage. Puedes usar formatos como Avro con compresión SNAPPY o JSON con compresión GZIP. Cuando diseñes tus estrategias de exportación, ten en cuenta los límites de las exportaciones.

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

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

En concreto, 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 de la tarea de Apache Spark permite la evolución del esquema.
  • Una vez que la tarea de Dataproc ha procesado los archivos de BigQuery, estos se escriben en Cloud Storage y, a continuación, se transfieren a una ubicación de recuperación ante desastres local.
  • Cloud Interconnect se usa para conectar tu red de nube privada virtual con tu red local.
  • La transferencia a la ubicación de recuperación ante desastres local se puede realizar mediante el trabajo de Spark.

Si el diseño de tu almacén es de solo anexión 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. A continuación, puedes usar una herramienta como el comando gcloud storage de la CLI de gcloud para transferir los archivos actualizados a tu ubicación de copia de seguridad local o en otra nube. (Es posible que se apliquen cargos por salida cuando transfieras datos fuera de Google Cloud).

Por ejemplo, tiene un almacén de datos de ventas que consta de una tabla ordersde solo anexión en la que los nuevos pedidos se anexan a la partición que representa la fecha actual. Sin embargo, una política de devoluciones puede permitir que los artículos se devuelvan en un plazo de 7 días. Por lo tanto, es posible que se actualicen los registros de la tabla orders de los últimos 7 días. Sus estrategias de exportación deben tener en cuenta la política de devoluciones. En este ejemplo, cualquier tarea de exportación para crear una copia de seguridad de la tabla orders también debe exportar las particiones que representan los pedidos de los últimos 7 días para evitar que se pierdan actualizaciones debido a devoluciones.

Siguientes pasos

Colaboradores

Autores: