Migra en todas las regiones de Google Cloud: Prepara los datos y las cargas de trabajo por lotes para la migración entre regiones

Last reviewed 2023-12-08 UTC

En este documento, se describe cómo diseñar una plataforma de datos en Google Cloud para minimizar el impacto de una expansión futura a otras regiones o de una migración de región a región. Este documento es parte de una serie que te ayuda a comprender el impacto de la expansión de tu plataforma de datos a otra región. Te ayuda a hacer lo siguiente:

  • Prepárate para mover datos y canalizaciones de datos.
  • Configura verificaciones durante las fases de migración.
  • Crea una estrategia de migración flexible mediante la separación del almacenamiento y el procesamiento de datos.

La guía de esta serie también es útil si no planificaste una migración entre regiones o una expansión a varias regiones con anticipación. En este caso, es posible que debas invertir un esfuerzo adicional para preparar la infraestructura, las cargas de trabajo y los datos de la migración entre regiones y la expansión a varias regiones.

Este documento forma parte de una serie:

En esta serie, suponemos que leíste los siguientes documentos y los conoces:

En el siguiente diagrama, se ilustra la ruta del recorrido de tu migración.

Ruta de migración con cuatro fases

Durante cada paso de migración, debes seguir las fases definidas en Migra a Google Cloud: comienza ahora:

  1. Evalúa y descubre las cargas de trabajo.
  2. Planifica y compila una base.
  3. Implementar tus cargas de trabajo
  4. Optimiza el entorno.

La plataforma de datos moderna en Google Cloud

En esta sección, se describen las diferentes partes de una plataforma de datos moderna y cómo se suelen crear en Google Cloud. Las plataformas de datos como concepto general se pueden dividir en dos secciones:

  • La capa de almacenamiento de datos es donde se guardan los datos. Los datos que guardas pueden tener la forma de archivos en los que administras bytes reales en un sistema de archivos, como el sistema de archivos distribuido de Hadoop (HDFS) o Cloud Storage, o puedes usar un lenguaje específico del dominio (DSL) para administrar los datos en un sistema de administración de bases de datos.
  • La capa de cálculo de datos es cualquier procesamiento de datos que puedas activar sobre el sistema de almacenamiento. Al igual que con la capa de almacenamiento, hay muchas implementaciones posibles y algunas herramientas de almacenamiento de datos también controlan el procesamiento de datos. El rol de la capa de procesamiento de datos en la plataforma es cargar datos desde la capa de almacenamiento, procesarlos y, luego, guardar los resultados en un sistema de destino. El sistema de destino puede ser la capa de almacenamiento de origen.

Algunas plataformas de datos usan varios sistemas de almacenamiento para su capa de almacenamiento de datos y varios sistemas de procesamiento de datos para su capa de procesamiento de datos. En la mayoría de los casos, la capa de almacenamiento de datos y la capa de procesamiento de datos están separadas. Por ejemplo, es posible que hayas implementado tu capa de almacenamiento de datos mediante los siguientes servicios de Google Cloud:

Es posible que hayas implementado la capa de procesamiento de datos mediante otros servicios de Google Cloud como los siguientes:

Para reducir el tiempo y la latencia de la comunicación, el costo de la transferencia de datos salientes y la cantidad de operaciones de E/S entre la capa de almacenamiento y la de procesamiento, te recomendamos que almacenes los datos en la misma zona donde se procesan los datos.

También te recomendamos mantener tu capa de almacenamiento de datos separada de la capa de procesamiento de datos. Mantener estas capas separadas mejora tu flexibilidad para cambiar las capas de procesamiento y migrar datos. Mantener las capas separadas también reduce el uso de recursos, ya que no tienes que mantener la capa de procesamiento en ejecución todo el tiempo. Por lo tanto, te recomendamos que implementes el almacenamiento y el procesamiento de datos en plataformas separadas en la misma zona y región. Por ejemplo, puedes mover el almacenamiento de datos de HDFS a Cloud Storage y usar un clúster de Dataproc para el procesamiento.

Evalúa el entorno

En la fase de evaluación, determinarás los requisitos y las dependencias para migrar las canalizaciones de datos por lotes que implementaste:

  1. Crea un inventario completo de tus canalizaciones de datos.
  2. Cataloga tus cargas de trabajo según sus propiedades y dependencias.
  3. Capacita y educa a tus equipos en Google Cloud.
  4. Compila un experimento y prueba de concepto en Google Cloud.
  5. Calcula el costo total de propiedad (TCO) del entorno de destino.
  6. Elige las cargas de trabajo que deseas migrar primero.

Para obtener más información sobre la fase de evaluación y estas tareas, consulta Migración a Google Cloud: Evalúa y descubre tus cargas de trabajo. Las siguientes secciones se basan en la información de ese documento.

Compila tus inventarios

Para determinar el alcance de tu migración, debes comprender el entorno de la plataforma de datos en el que se implementan tus canalizaciones de datos:

  1. Crea un inventario de tu infraestructura de datos: las diferentes capas de almacenamiento y las diferentes capas de procesamiento que usas para el almacenamiento de datos y el procesamiento de datos por lotes.
  2. Crea un inventario de las canalizaciones de datos que están programadas para migrarse.
  3. Crea un inventario de los conjuntos de datos que leen las canalizaciones de datos y que se deben migrar.

Con el fin de compilar un inventario de la plataforma de datos, considera lo siguiente para cada parte de la infraestructura de datos:

  • Capas de almacenamiento. Junto con las plataformas de almacenamiento estándar, como Cloud Storage, considera otras capas de almacenamiento, como las bases de datos, por ejemplo, Firebase, BigQuery, Bigtable y Postgres, o bien otros clústeres, como Apache Kafka. Cada plataforma de almacenamiento tiene su propia estrategia y método para completar la migración. Por ejemplo, Cloud Storage tiene servicios de migración de datos y una base de datos podría tener una herramienta de migración integrada. Asegúrate de que cada producto que usas para el almacenamiento de datos esté disponible en tu entorno de destino o que tengas un reemplazo compatible. Practica y verifica el proceso de transferencia de datos técnicos para cada una de las plataformas de almacenamiento involucradas.
  • Capas de procesamiento. Para cada plataforma de procesamiento, verifica el plan de implementación y los cambios en la configuración que puedas haber realizado en las diferentes plataformas.
  • Latencia de red. Prueba y verifica la latencia de red entre el entorno de origen y el entorno de destino. Es importante que comprendas cuánto tiempo tomará copiar los datos. También debes probar la latencia de la red de los clientes y los entornos externos (como un entorno local) al entorno de destino en comparación con el entorno de origen.

  • Configuración e implementación. Cada producto de infraestructura de datos tiene sus propios métodos de configuración. Realiza un inventario de las configuraciones personalizadas que realizaste para cada componente y de qué componentes usas en las versiones predeterminadas (por ejemplo, qué versión de Dataproc o versión de Apache Kafka estás usando). Asegúrate de que esas opciones de configuración se puedan implementar como parte del proceso de implementación automatizado.

    Debes saber cómo se configura cada componente porque los motores de procesamiento pueden comportarse de manera diferente cuando se configuran de forma diferente, en especial si el framework de la capa de procesamiento cambia durante la migración. Por ejemplo, si el entorno de destino ejecuta una versión diferente de Apache Spark, es posible que algunas opciones de configuración del framework de Spark hayan cambiado entre versiones. Este tipo de cambio de configuración puede causar cambios en los resultados, las serializaciones y el procesamiento.

    Durante la migración, te recomendamos que uses implementaciones automatizadas para asegurarte de que las versiones y opciones de configuración sean las mismas. Si no puedes mantener versiones y configuraciones iguales, asegúrate de tener pruebas que validen los resultados de datos que calcula el framework.

  • Tamaños de clústeres. Para los clústeres autoadministrados, como un clúster de Dataproc de larga duración o un clúster de Apache Kafka que se ejecuta en Compute Engine, ten en cuenta la cantidad de nodos y CPU y la memoria de cada nodo en los clústeres. La migración a otra región puede provocar un cambio en el procesador que usa tu implementación. Por lo tanto, te recomendamos que crees un perfil y optimices tus cargas de trabajo después de implementar la infraestructura migrada en la producción. Si un componente es completamente administrado o sin servidores (por ejemplo, Dataflow), el tamaño será parte de cada trabajo individual y no de la parte del clúster.

Los siguientes elementos que debes evaluar en tu inventario se centran en las canalizaciones de datos:

  • Fuentes de datos y receptores. Asegúrate de tener en cuenta las fuentes y los receptores que cada canalización de datos usa para leer y escribir datos.
  • Acuerdos de Nivel de Servicio (ANS) y objetivos de nivel de servicio (SLO) Los ANS y los SLO de canalizaciones de datos por lotes suelen medirse a tiempo hasta que se completan, pero también se pueden medir de otras maneras, como la potencia de procesamiento usada. Estos metadatos empresariales son importantes para impulsar los procesos del plan de recuperación ante desastres y continuidad del negocio (BCDR), como la conmutación por error de un subconjunto de tus canalizaciones más importantes a otra región en caso de una falla zonal o regional.
  • Dependencias de canalizaciones de datos. Algunas canalizaciones de datos se basan en datos que genera otra canalización de datos. Cuando dividas canalizaciones en ciclos de migración, asegúrate de considerar las dependencias de los datos.
  • Conjuntos de datos generados y consumidos. Para cada canalización de datos, identifica los conjuntos de datos que consume y qué conjuntos de datos genera. Esto puede ayudarte a identificar dependencias entre canalizaciones y entre otros sistemas o componentes de tu arquitectura general.

Los siguientes elementos que debes evaluar en tu inventario se centran en los conjuntos de datos que se migrarán:

  • Datasets. Identifica los conjuntos de datos que se deben migrar al entorno de destino. Puedes considerar que algunos datos históricos no son necesarios para la migración o que se migren en otro momento, si los datos están archivados y no se usan de forma activa. Cuando defines el alcance del proceso de migración y los ciclos de migración, puedes reducir los riesgos en la migración.
  • Tamaños de los datos. Si planeas comprimir archivos antes de transferirlos, asegúrate de anotar el tamaño del archivo antes y después de la compresión. El tamaño de tus datos afectará el tiempo y el costo necesarios para copiar los datos desde la fuente hasta el destino. Tener en cuenta estos factores te ayudará a elegir entre estrategias de tiempo de inactividad, como se describe más adelante en este documento.
  • Estructura de datos. Clasifica cada conjunto de datos que se migrará y asegúrate de comprender si los datos están estructurados, semiestructurados o no estructurados. Comprender la estructura de datos puede informar a tu estrategia cómo verificar que los datos se migren de manera correcta y completa.

Completa la evaluación

Después de compilar los inventarios relacionados con tus clústeres y cargas de trabajo de Kubernetes, completa el resto de las actividades de la fase de evaluación en Migración a Google Cloud: Evalúa y descubre tus cargas de trabajo.

Planifica y compila tu base

La fase de planificación y compilación de la migración a Google Cloud consta de las siguientes tareas:

  1. Compila una jerarquía de recursos.
  2. Configura Identity and Access Management (IAM)
  3. Configura la facturación.
  4. Configura la conectividad de red.
  5. Endurece tu seguridad.
  6. Configurar el registro, la supervisión y las alertas

Para obtener más información sobre cada una de estas tareas, consulta Migra a Google Cloud: Planifica y compila tu base.

Migra canalizaciones de datos y datos

En las siguientes secciones, se describen algunos aspectos del plan para migrar canalizaciones de datos y por lotes. Define algunos conceptos en torno a las características de las canalizaciones de datos que son importantes para comprender cuando creas el plan de migración. También se analizan algunos conceptos de prueba de datos que pueden ayudar a aumentar tu confianza en la migración de datos.

Plan de migración

En tu plan de migración, debes incluir el tiempo para completar la transferencia de datos. Tu plan debe tener en cuenta la latencia de red, el tiempo para probar la integridad de los datos y obtener los datos que no se pudieron migrar y los costos de red. Debido a que los datos se copiarán de una región a otra, tu plan para los costos de red debe incluir los costos de red interregionales.

Te recomendamos que dividas las diferentes canalizaciones y conjuntos de datos en ciclos y los migres por separado. Este enfoque ayuda a reducir los riesgos de cada ciclo de migración y permite mejoras en cada ciclo. Para mejorar la estrategia de migración y descubrir problemas con anticipación, te recomendamos que priorices las cargas de trabajo más pequeñas y no críticas antes de migrar las cargas de trabajo más grandes y críticas.

Otra parte importante de un plan de migración es describir la estrategia, las dependencias y la naturaleza de las diferentes canalizaciones de datos de la capa de procesamiento. Si la capa de almacenamiento de datos y la capa de procesamiento de datos se compilan en el mismo sistema, te recomendamos que supervises el rendimiento del sistema mientras se copian los datos. Por lo general, el acto de copiar grandes cantidades de datos puede causar una sobrecarga de E/S en el sistema y degradar el rendimiento en la capa de procesamiento. Por ejemplo, si ejecutas una carga de trabajo para extraer datos de un clúster de Kafka en lotes, las operaciones adicionales de E/S a fin de leer grandes cantidades de datos pueden causar una degradación del rendimiento en cualquier canalización de datos activa que se siga ejecutando en el entorno de origen. En ese tipo de situación, debes supervisar el rendimiento del sistema mediante el uso de métricas integradas o personalizadas. Para evitar abrumar el sistema, te recomendamos que tengas un plan para retirar algunas cargas de trabajo durante el proceso de copia de datos o limitar la fase de copia.

Debido a que la copia de datos hace que la migración sea un proceso de larga duración, te recomendamos que tengas planes de contingencia para abordar cualquier problema que pueda salir mal durante la migración. Por ejemplo, si el movimiento de datos tarda más de lo esperado o si las pruebas de integridad fallan antes de poner el sistema nuevo en línea, considera si deseas revertir o intentar corregir y reintentar las operaciones con errores. Aunque una reversión puede ser una solución más limpia, puede llevar mucho tiempo y ser costoso copiar conjuntos de datos grandes varias veces. Recomendamos que tengas una comprensión clara y pruebas predefinidas para determinar qué acción tomar en qué condiciones, cuánto tiempo permitir que se intente crear parches y cuándo realizar una reversión completa.

Es importante distinguir entre las herramientas y las secuencias de comandos que usas para la migración y los datos que copias. Revertir el movimiento de datos significa que debes volver a copiar los datos y anular o borrar los datos que ya copiaste. Revierte los cambios en las herramientas y las secuencias de comandos es más fácil y menos costoso, pero los cambios en las herramientas pueden obligar a volver a copiar los datos. Por ejemplo, es posible que debas volver a copiar los datos si creas una ruta de destino nueva en una secuencia de comandos que genera una ubicación de Cloud Storage de forma dinámica. Para evitar volver a copiar datos, compila tus secuencias de comandos a fin de permitir la reanudación y la idempotencia.

Características de la canalización de datos

Para crear un plan de migración óptimo, debes comprender las características de las diferentes canalizaciones de datos. Es importante recordar que las canalizaciones por lotes que escriben datos son diferentes de las canalizaciones por lotes que leen datos:

  • Canalizaciones de datos que escriben datos: Debido a que cambian el estado del sistema de origen, puede ser difícil escribir datos en el entorno de origen al mismo tiempo que se copian los datos al entorno de destino. Considera los entornos de ejecución de las canalizaciones que escriben datos y, luego, intenta priorizar su migración en etapas anteriores del proceso general. Esto te permitirá tener datos listos en el entorno de destino antes de migrar las canalizaciones que leen los datos.
  • Canalizaciones de datos que leen datos: Las canalizaciones que leen datos pueden tener requisitos diferentes para la actualidad de datos. Si las canalizaciones que generan datos se detienen en el sistema de origen, las canalizaciones que leen datos podrían ejecutarse mientras se copian los datos en el entorno de destino.

Los datos son un estado y copiarlos entre regiones no es una operación atómica. Por lo tanto, debes estar al tanto de los cambios de estado mientras se copian los datos.

También es importante en el plan de migración diferenciar entre sistemas. Es posible que tus sistemas tengan diferentes requisitos funcionales y no funcionales (por ejemplo, un sistema para la transmisión por lotes y otro para la transmisión). Por lo tanto, tu plan debe incluir diferentes estrategias para migrar cada sistema. Asegúrate de especificar las dependencias entre los sistemas y especificar cómo reducirás el tiempo de inactividad de cada sistema durante cada fase de la migración.

Un plan típico para un sprint de migración debe incluir los siguientes:

  • Estrategia general. Describe la estrategia para manejar la migración en este ciclo. Para ver estrategias comunes, consulta Implementa tus cargas de trabajo.
  • Lista de herramientas y métodos para la copia de datos y la implementación de recursos. Especifica cualquier herramienta que planeas usar para copiar datos o implementar recursos en el entorno de destino. En esta lista, se deben incluir secuencias de comandos personalizadas que se usan para copiar elementos de Cloud Storage, herramientas estándar como Google Cloud CLI y herramientas de Google Cloud, como Servicios de migración.
  • Lista de recursos para implementar en el entorno de destino. Enumera todos los recursos que se deben implementar en el entorno de destino. Esta lista debe incluir todos los componentes de la infraestructura de datos, como los depósitos de Cloud Storage, los conjuntos de datos de BigQuery y los clústeres de Dataproc. En algunos casos, los ciclos de migración temprana incluirán la implementación de un clúster de tamaño (como un clúster de Dataproc) en una capacidad más pequeña, mientras que los ciclos posteriores incluirán el cambio de tamaño para adaptarse a cargas de trabajo nuevas. Asegúrate de que tu plan incluya cambios de tamaño posibles.
  • Lista de conjuntos de datos que se copiarán. Asegúrate de especificar la siguiente información para cada conjunto de datos:
    • Orden en la copia (si corresponde): Para la mayoría de las estrategias, el orden de la operación puede ser importante. La excepción es la estrategia de mantenimiento programado que se describe más adelante en este documento.
    • Tamaño
    • Estadísticas de claves: Gráficos de estadísticas de claves, como el número de fila, que pueden ayudarte a verificar que el conjunto de datos se haya copiado correctamente.
    • Tiempo estimado para copiar: Es el momento en que se completa tu transferencia de datos, según el plan de migración.
    • Método para copiar: Consulta la lista de herramientas y métodos descrita antes en este documento.
    • Pruebas de verificación: Enumera de forma explícita las pruebas que planeas completar para verificar que los datos se hayan copiado por completo.
    • Plan de contingencia: Describe qué hacer si alguna prueba de verificación falla. Tu plan de contingencia debe especificar cuándo reintentar y reanudar la copia o llenar el intervalo, y cuándo hacer una reversión completa y volver a copiar todo el conjunto de datos.

Pruebas

En esta sección, se describen algunos tipos típicos de pruebas que puedes planificar. Las pruebas pueden ayudarte a garantizar la completitud y la integridad de los datos. También pueden ayudarte a garantizar que la capa de procesamiento funcione según lo esperado y que esté lista para ejecutar las canalizaciones de datos.

  • Comparación de hashing o de resumen: Para validar la integridad de los datos después de copiarlos, debes comparar el conjunto de datos original con la copia nueva en el entorno de destino. Si los datos están estructurados dentro de tablas de BigQuery, no puedes unir las dos tablas en una consulta para ver si todos los datos existen, ya que las tablas residen en diferentes regiones. Debido al costo y la latencia, BigQuery no permite que las consultas unan datos entre regiones. En su lugar, el método de comparación debe resumir cada conjunto de datos y comparar los resultados. Según la estructura del conjunto de datos, el método para resumir puede ser diferente. Por ejemplo, una tabla de BigQuery puede usar una consulta de agregación, pero un conjunto de archivos en Cloud Storage puede usar una canalización de Spark para calcular un hash de cada archivo y, luego, agregar los hash.

  • Flujos canary: Los flujos canary activan trabajos que se compilan para validar la completitud y la integridad de los datos. Antes de continuar con los casos de uso empresariales, como el análisis de datos, puede ser útil ejecutar trabajos de flujo canary para asegurarte de que los datos de entrada cumplan con un conjunto de requisitos previos. Puedes implementar flujos de versión canary como canalizaciones de datos personalizadas o flujos en un DAG basado en Cloud Composer. Los flujos de versión canary pueden ayudarte a completar tareas, como verificar que no falten valores para ciertos campos o validar que el recuento de filas de conjuntos de datos específicos coincida con el recuento esperado.

    También puedes usar flujos de versiones canary para crear resúmenes u otras agregaciones de una columna o un subconjunto de los datos. Luego, puedes usar el flujo de versión canary para comparar los datos con un resumen o agregación similar que se toma de la copia de los datos.

    Los métodos de flujo de versión canary son valiosos cuando necesitas evaluar la exactitud de los datos que se almacenan y copian en formatos de archivo, como los archivos Avro en Cloud Storage. Por lo general, los flujos de versión canary no generan datos nuevos, pero fallan si no se cumple un conjunto de reglas dentro de los datos de entrada.

  • Entorno de prueba: Después de completar el plan de migración, debes probarlo en un entorno de pruebas. El entorno de pruebas debe incluir la copia de datos de etapa de pruebas o los datos de etapa de pruebas en otra región para estimar el tiempo que lleva copiar datos en la red. Esta prueba te ayuda a identificar cualquier problema con el plan de migración y te ayuda a verificar que los datos se puedan migrar de forma correcta. Las pruebas deben incluir pruebas funcionales y no funcionales. Las pruebas funcionales verifican que los datos se migren correctamente. Las pruebas no funcionales verifican que la migración cumpla con los requisitos de rendimiento, seguridad y otros no funcionales. Cada paso de migración en tu plan debe incluir un criterio de validación que detalle cuándo se puede considerar que se completó.

Para ayudar con la validación de datos, puedes usar la Herramienta de validación de datos (DVT). La herramienta realiza funciones de validación de datos de varios niveles, desde el nivel de la tabla hasta el nivel de la fila, y te ayuda a comparar los resultados de tus sistemas de origen y destino.

Tus pruebas deben verificar la implementación de la capa de procesamiento y los conjuntos de datos que se copiaron. Un enfoque para hacerlo es construir una canalización de prueba que pueda calcular algunas agregaciones de los conjuntos de datos copiados y asegurarte de que los conjuntos de datos de origen y los de destino coincidan. Una discrepancia entre los conjuntos de datos de origen y de destino es más común cuando los archivos que copias entre regiones no son representaciones exactas de copia de bytes entre los sistemas de origen y de destino (como cuando cambias formatos de archivo o compresión de archivos).

Por ejemplo, considera un conjunto de datos compuesto por archivos JSON delimitados por líneas nuevas. Los archivos se almacenan en un bucket de Cloud Storage y se activan como una tabla externa en BigQuery. Para reducir la cantidad de datos que se mueven a través de la red, puedes realizar la compresión de Avro como parte de la migración, antes de copiar archivos al entorno de destino. Esta conversión tiene muchas ventajas, pero también tiene algunos riesgos, ya que los archivos que se escriben en el entorno de destino no son una representación de copia de bytes de los archivos en el entorno de origen.

A fin de mitigar los riesgos de la situación de conversión, puedes crear un trabajo de Dataflow o usar BigQuery para calcular algunas agregaciones y hashes de suma de verificación del conjunto de datos (por ejemplo, mediante el cálculo de sumas, promedios o cuantiles para cada columna numérica). Para las columnas de string, puedes calcular agregaciones sobre la longitud de la string o en el código hash de esa string. Para cada fila, puedes calcular un hash agregado a partir de una combinación de todas las demás columnas, lo que puede verificar con alta exactitud que una fila sea la misma que su origen. Estos cálculos se realizan en los entornos de origen y de destino y, luego, se comparan. En algunos casos, por ejemplo, si tu conjunto de datos se almacena en BigQuery, no puedes unir tablas de los entornos de origen y destino porque están en regiones diferentes, por lo que debes usar un cliente que pueda conectarse a ambos entornos.

Puedes implementar los métodos de prueba anteriores en BigQuery o como un trabajo por lotes (como en Dataflow). Luego, puedes ejecutar los trabajos de agregación y comparar los resultados calculados para el entorno de origen con los resultados calculados para el entorno de destino. Este enfoque puede ayudarte a asegurarte de que los datos estén completos y sean precisos.

Otro aspecto importante de la prueba de la capa de procesamiento es ejecutar canalizaciones que incluyen todas las variedades de motores de procesamiento y métodos de procesamiento. Probar la canalización es menos importante para los motores de procesamiento administrados, como BigQuery o Dataflow. Sin embargo, es importante probar la canalización para motores de procesamiento no administrados como Dataproc. Por ejemplo, si tienes un clúster de Dataproc que controla varios tipos de procesamiento diferentes, como Apache Spark, Apache Hive, Apache Flink o Apache MapReduce, debes probar cada entorno de ejecución para asegurarte de que los diferentes tipos de cargas de trabajo están listos para transferirse.

Estrategias de migración

Después de verificar tu plan de migración con las pruebas adecuadas, puedes migrar datos. Cuando migras datos, puedes usar estrategias diferentes para cargas de trabajo diferentes. Los siguientes son ejemplos de estrategias de migración que puedes usar tal como están o personalizarlas según tus necesidades:

  • Mantenimiento programado: Planeas cuando se produce la ventana de migración de sistemas. Esta estrategia es adecuada cuando los datos cambian con frecuencia, pero los SLO y los ANS pueden soportar cierto tiempo de inactividad. Esta estrategia ofrece una alta confianza en los datos transferidos porque los datos están completamente inactivos mientras se copian. Para obtener más información, consulta Mantenimiento programado en “Migración a Google Cloud: transfiere conjuntos de datos grandes”.
  • Migración de sistemas de solo lectura: Una leve variación de la estrategia de mantenimiento programada, en la que la plataforma de datos del sistema de origen permite que las canalizaciones de datos de solo lectura continúen leyendo datos mientras se copian los datos. Esta estrategia es útil porque algunas canalizaciones de datos pueden seguir funcionando y proporcionar estadísticas a los sistemas finales. La desventaja de esta estrategia es que los datos que se producen están inactivos durante la migración, ya que los datos de origen no se actualizan. Por lo tanto, es posible que debas implementar una estrategia de actualización después de la migración para dar cuenta de los datos obsoletos en los sistemas finales.
  • Completamente activo: Copias los datos en una marca de tiempo específica, mientras el entorno de origen aún está activo para las canalizaciones de datos de lectura y de escritura. Después de copiar los datos y cambiar a la nueva implementación, debes realizar una fase de copia delta para obtener los datos que se generaron después de la marca de tiempo de migración en el entorno de origen. Este enfoque requiere más coordinación y consideración en comparación con otras estrategias. Por lo tanto, tu plan de migración debe incluir cómo manejarás las operaciones de actualización y eliminación en los datos de origen.
  • Escrituras dobles: las canalizaciones de datos pueden ejecutarse en los entornos de origen y de destino, mientras se copian los datos. Esta estrategia evita la fase de copia delta necesaria para reabastecer datos si usas las estrategias completamente activas o de solo lectura. Sin embargo, para garantizar que las canalizaciones de datos produzcan resultados idénticos, una estrategia de escritura doble requiere más pruebas antes de la migración. Si no realizas pruebas avanzadas, tendrás problemas para consolidar una situación de cerebro dividido. La estrategia de escrituras dobles también presenta costos potenciales de ejecutar las mismas cargas de trabajo dos veces en diferentes regiones. Esta estrategia tiene el potencial de migrar tu plataforma sin tiempo de inactividad, pero requiere mucho más coordinación para ejecutarla de manera correcta.

Pruebas posteriores a la migración

Una vez completada la migración, debes probar la integridad de los datos y las canalizaciones de datos para comprobar su validez. Si completas tu migración en ciclos, debes realizar estas pruebas después de cada ciclo. Las pruebas que realizas en esta etapa son similares a las pruebas de integración: pruebas la validez de una canalización de datos que ejecuta casos de uso empresariales con datos de nivel de producción completos como entrada y, luego, inspeccionas la salida para determinar la validez. Puedes comparar el resultado de la prueba de integración con el del entorno de origen si ejecutas la misma canalización de datos en el entorno de origen y en el de destino. Este tipo de prueba funciona solo si la canalización de datos es determinista y si puedes asegurarte de que la entrada a ambos entornos sea idéntica.

Puedes confirmar que los datos están completos cuando cumplen con un conjunto de criterios predefinidos, en el que los datos en el entorno de origen son iguales (o lo suficientemente similares) a los datos en el entorno de destino. Según la estrategia que usaste en la sección anterior, es posible que los datos no coincidan uno a uno. Por lo tanto, debes predefinir criterios que describan la integridad de los datos para tu caso de uso. Por ejemplo, en el caso de los datos de series temporales, puedes considerar que los datos están completos cuando el registro más actualizado no está más de cinco minutos detrás de la marca de tiempo actual.

Migración de sistemas

Después de verificar y probar las canalizaciones de datos y datos en el entorno de destino, puedes iniciar la fase de migración de sistemas. Cuando se inicia esta fase, es posible que los clientes necesiten cambiar su configuración para hacer referencia a los nuevos sistemas. En algunos casos, la configuración no puede ser la misma que la que apunta al sistema de origen. Por ejemplo, si un servicio necesita leer datos de un bucket de Cloud Storage, los clientes deben cambiar la configuración para qué bucket se usará. Los nombres de buckets de Cloud Storage son únicos a nivel global, por lo que tu bucket de entorno de destino de Cloud Storage será diferente del entorno de origen.

Durante la fase de migración de sistemas, debes retirar el servicio y anular la programación de las cargas de trabajo del entorno de origen. Te recomendamos conservar los datos del entorno de origen durante un tiempo, en caso de que necesites revertir.

La fase de prueba previa a la migración no es tan completa como una ejecución de producción de una canalización de datos. Por lo tanto, después de que se completa la migración de sistemas y el sistema de destino está en funcionamiento, debes supervisar las métricas, los entornos de ejecución y los resultados semánticos de tus canalizaciones de datos. Esta supervisión te ayudará a detectar errores que tu fase de prueba podría haber perdido y te ayudará a garantizar el éxito de la migración.

Optimiza el entorno

La optimización es la última fase de la migración. En esta fase, harás que tu entorno sea más eficiente mediante la ejecución de varias iteraciones de un bucle repetible hasta que el entorno cumpla con tus requisitos de optimización:

  1. Evalúa tu entorno actual, los equipos y el ciclo de optimización.
  2. Establece tus requisitos y objetivos de optimización.
  3. Optimiza el entorno y los equipos.
  4. Ajustar el bucle de optimización

Para obtener más información sobre cómo optimizar tu entorno de Google Cloud, consulta Migración a Google Cloud: Optimiza el entorno.

Prepara tus datos de Google Cloud y los recursos de procesamiento para una migración entre regiones

En esta sección, se proporciona una descripción general de los datos y los recursos de procesamiento en Google Cloud y de los principios de diseño para preparar una migración entre regiones.

BigQuery

Debido a que BigQuery es un almacén de datos de SQL sin servidores, no tienes que implementar la capa de procesamiento. Si algunos de tus clientes de BigQuery especifican regiones para su procesamiento, deberás ajustar esos clientes. De lo contrario, BigQuery es el mismo en el entorno de origen y en el de destino. Los datos de BigQuery se almacenan en dos tipos de tablas:

  • Tablas de BigQuery: tablas en el formato de BigQuery. BigQuery administra la fuente de datos por ti. Para obtener más información sobre la migración de datos en formato de BigQuery, consulta Administra conjuntos de datos.
  • Tablas externas de BigQuery: Tablas para las que se almacenan los datos fuera de BigQuery. Una vez que se transfieran los datos, deberás volver a crear las tablas externas en el destino nuevo. Para obtener más información sobre la migración de tablas externas, consulta Introducción a las tablas externas.

Cloud Storage

Cloud Storage ofrece un Servicio de transferencia de almacenamiento que puede ayudarte a migrar tus datos.

Dataflow (Batch)

Dataflow es un motor de procesamiento de datos administrado por Google. Para simplificar tu migración de Dataflow y garantizar que tus trabajos se puedan implementar con facilidad en cualquier región, debes insertar todas las entradas y salidas como parámetros en tu trabajo. En lugar de escribir ubicaciones de datos de entrada y salida en tu código fuente, te recomendamos que pases las rutas de Cloud Storage y las cadenas de conexión de la base de datos como argumentos o parámetros.

Dataproc

Dataproc es un entorno de Apache Hadoop administrado que puede ejecutar cualquier carga de trabajo que sea compatible con el framework de Apache Hadoop. Es compatible con frameworks como Apache Spark, Apache Flink y Apache Hive.

Puedes usar Dataproc de las siguientes maneras, que afectan cómo debes migrar tu entorno de Dataproc en las regiones:

  • Clústeres efímeros con datos en Cloud Storage: Los clústeres se compilan para ejecutar trabajos específicos y se destruyen después de que se completan los trabajos. Esto significa que la capa de HDFS o cualquier otro estado del clúster también se destruye. Si tu configuración cumple con los siguientes criterios, este tipo de uso es más fácil de migrar en comparación con otros tipos de uso:
    • Las entradas y salidas de tus trabajos no están codificadas en el código fuente. En cambio, tus trabajos reciben entradas y resultados como argumentos.
    • El aprovisionamiento del entorno de Dataproc está automatizado, incluidas las opciones de configuración para los marcos de trabajo individuales que usa tu entorno.
  • Clústeres de larga duración con datos externos: Tienes uno o más clústeres, pero son clústeres de larga duración, incluso si no hay trabajos en ejecución en el clúster, este sigue en funcionamiento. Los datos y el procesamiento son independientes porque se guardan fuera del clúster en las soluciones de Google Cloud, como Cloud Storage o BigQuery. Por lo general, este modelo es efectivo cuando siempre hay trabajos que se ejecutan en el clúster, por lo que no tiene sentido eliminar y configurar clústeres como en el modelo efímero. Debido a que los datos y el procesamiento son independientes, la migración es similar a la migración del modelo efímero.
  • Clústeres de larga duración con datos en el clúster: El clúster es de larga duración, pero también mantiene el estado, los datos o ambos, dentro del clúster, por lo general, como datos en HDFS. Este tipo de uso complica los esfuerzos de migración porque los datos y el procesamiento no son independientes. Si migras una sin la otra, existe un alto riesgo de crear inconsistencias. En esta situación, considera mover los datos y el estado fuera del clúster antes de la migración, para separarlos. Si esto no es posible, te recomendamos que uses la estrategia de mantenimiento programado para reducir el riesgo de crear inconsistencias en tus datos.

Debido a que hay muchos frameworks posibles y muchas versiones y opciones de configuración de esos frameworks, debes realizar una prueba exhaustiva antes de ejecutar el plan de migración.

Cloud Composer

Cloud Composer es la versión administrada de Apache Airflow de Google Cloud para la organización y la programación de flujos. Los DAG, la configuración y los registros se administran en un bucket de Cloud Storage que se debe migrar con la implementación de Cloud Composer. Para migrar el estado de tu implementación de Cloud Composer, puedes guardar y cargar instantáneas del entorno.

Si implementaste complementos personalizados en tu instancia de Cloud Composer, te recomendamos que apliques una metodología de infraestructura como código para volver a crear el entorno de forma completamente automatizada.

Cloud Composer no administra datos, pero activa otros frameworks y plataformas de procesamiento de datos. Por lo tanto, la migración de Cloud Composer puede aislarse por completo de los datos. Además, Cloud Composer no procesa los datos, por lo que no es necesario que la implementación esté en la misma región que los datos. Por lo tanto, puedes crear una implementación de Cloud Composer en el entorno de destino y ejecutar canalizaciones en el entorno de origen. En algunos casos, hacerlo puede ser útil para operar diferentes canalizaciones en diferentes regiones mientras se migra toda la plataforma.

Cloud Data Fusion

Cloud Data Fusion es una herramienta de integración visual que te ayuda a compilar canalizaciones de datos con un editor visual. Cloud Data Fusion se basa en el proyecto de código abierto CDAP. Al igual que Cloud Composer, Cloud Data Fusion no administra datos en sí, pero activa otros frameworks y plataformas de procesamiento de datos. Las canalizaciones de Cloud Data Fusion deben exportarse desde el entorno de origen y, luego, importarse al entorno de destino de una de las siguientes maneras:

Según la cantidad de flujos que necesites migrar, es posible que prefieras un método en lugar del otro. El uso de la API de CDAP para compilar una secuencia de comandos de migración puede ser difícil y requiere más habilidades de ingeniería de software. Sin embargo, si tienes muchos flujos o si los flujos cambian con cierta frecuencia, un proceso automatizado puede ser el mejor enfoque.

Pasos siguientes

Colaboradores

Eyal Ben Ivri | Arquitecto de Soluciones de Cloud

Otro colaborador: Marco Ferrari | Arquitecto de Soluciones de Cloud