Migra datos HDFS de un entorno local a Google Cloud

Last reviewed 2024-04-17 UTC

En esta guía, se describe el proceso de transferencia de datos del sistema de archivos distribuido de Hadoop local (HDFS) a Google Cloud.

Esta es la segunda de cuatro guías que describen cómo trasladar datos de Hadoop local:

Planifica el traslado de los datos

En las siguientes secciones, se describen las prácticas recomendadas para planificar la migración de datos de HDFS local a Google Cloud. Planifica la migración de manera incremental para que tengas tiempo de migrar trabajos, experimentar y probar después de mover cada cuerpo de datos.

Decide cómo trasladar los datos

Existen dos modelos de migración que deberías considerar para transferir datos de HDFS a la nube: envío y extracción. Ambos modelos usan Hadoop DistCp para copiar los datos de los clústeres de HDFS local a Cloud Storage, pero usan enfoques distintos.

El modelo de envío es el más simple: el clúster de origen ejecuta los trabajos distcp en los nodos de datos y envía los archivos directamente a Cloud Storage, como se muestra en el siguiente diagrama:

Migra datos de HDFS con el modelo de envío

El modelo de extracción es más complejo, pero tiene algunas ventajas. Un clúster efímero de Dataproc ejecuta los trabajos distcp en los nodos de datos, extrae archivos del clúster de origen y los copia en Cloud Storage, como se muestra en el siguiente diagrama:

Migra datos de HDFS con el modelo de extracción

El modelo de envío es el modelo más simple porque el clúster de origen puede enviar los datos directamente a Cloud Storage y no necesitas crear recursos de procesamiento adicionales para realizar la copia. Sin embargo, si pretendes usar el clúster de fuente durante la migración para otros trabajos de procesamiento de datos regulares, debes asegurarte de que hay suficientes recursos, como CPU, RAM y ancho de banda de red, disponibles en el clúster de fuente para también realizar los trabajos de copia.

Si el clúster de fuente ya se ejecuta a la capacidad de procesamiento y no puedes aumentar los recursos en el clúster de fuente para realizar la copia, deberías considerar usar el método de extracción.

Si bien es más complejo que el modelo de envío, el modelo de extracción tiene las siguientes ventajas:

  • Se minimiza el impacto en los recursos de CPU y RAM del clúster de origen, ya que los nodos de origen se usan solo para entregar bloques fuera del clúster. También puedes ajustar las especificaciones de los recursos del clúster de extracción en Google Cloud para manejar los trabajos de copia y borrar el clúster de extracción cuando se complete la migración.
  • Se reduce el tráfico de la red del clúster de fuente, que permite un ancho de banda de salida mayor y transferencias más rápidas.
  • No es necesario instalar el conector de Cloud Storage en el clúster de origen, ya que el clúster efímero de Dataproc, que ya tiene el conector instalado, se encarga de transferir los datos a Cloud Storage.

Para comprender las implicaciones del uso de la red en ambos modelos, considera cómo Hadoop maneja la replicación de datos en HDFS. Hadoop divide los archivos en varios bloques; el tamaño del bloque suele ser de 128 a 256 megabytes. Hadoop replica esos bloques en múltiples nodos de datos y bastidores para evitar la pérdida de datos si hay una falla de nodo o bastidor. La configuración estándar es almacenar 3 réplicas de cada bloque.

Hadoop también emplea el “conocimiento de los bastidores”, que garantiza que haya 2 copias de cada bloque en diferentes nodos de datos en el mismo bastidor, de modo que haya una latencia menor y una tercera copia en un bastidor distinto para mayor redundancia y disponibilidad. En el siguiente diagrama, se resume esta lógica de replicación:

Replicación de bloques de HDFS con conocimiento de bastidores

Cuando copias un archivo mediante el modelo de envío, es decir, cuando la tarea de mapeo distcp se ejecuta en un nodo de datos del clúster de origen, primero se recopilan todos los bloques del archivo de los nodos de datos. Luego, se extraen los bloques de archivo del clúster de origen y se envían a Cloud Storage. El tráfico en la red puede ocupar hasta el doble del tamaño total del archivo, como se ilustra en el siguiente diagrama:

Uso de red con el modelo de envío

Cuando copias un archivo mediante el modelo de extracción (es decir, cuando la tarea de mapeo distcp se ejecuta en un nodo de datos del clúster de extracción en Google Cloud), cada bloque se desplaza por la red solo una vez y, para hacerlo, sale directamente del clúster de origen. El tráfico de red total está limitado por el tamaño total del archivo, como se ilustra en el siguiente diagrama:

Uso de red con el modelo de extracción

Cuando usas el modelo de extracción, debes supervisar la cantidad de tareas de mapeo distcp y el ancho de banda usado para evitar sobrecargar el clúster de origen con demasiadas conexiones paralelas.

Decide a qué lugar mover los datos

El resultado final de tu migración de Hadoop puede ser una solución nativa de la nube o una solución híbrida. La diferencia está en si tu sistema retendrá componentes locales. En una solución nativa de la nube, alojas tus datos en la nube y ejecutas trabajos con ellos ahí. En una solución híbrida, algunos de tus datos se conservan de forma local. Quizás también quieras ejecutar trabajos con esos datos locales, o quizás ejecutes trabajos en la nube que trabajan con los datos locales.

Una solución nativa de la nube es más fácil de mantener, pero quizás tengas requisitos técnicos o del negocio por los que mantener algunos datos o procesamientos locales. Todas las soluciones híbridas dependen del caso, incluso su propia mezcla de tecnologías y servicios para cumplir con las necesidades de tu carga de trabajo.

Mueve datos a otros productos distintos a Cloud Storage

Mueve la mayoría de los datos a Cloud Storage. Sin embargo, en los siguientes casos, podrías considerar trasladar los datos a otro producto de Google Cloud:

  • Si migras datos de Apache HBase, considera moverlos a Bigtable, que proporciona características similares.

  • Si migras datos de Apache Impala, considera moverlos a BigQuery, que proporciona características similares.

Es posible que tengas datos en HBase o Impala que puedes usar sin almacenarlos en Bigtable o BigQuery. Si el trabajo no requiere las características de Bigtable o BigQuery, almacena los datos en Cloud Storage.

Ten en cuenta los permisos para planificar la ubicación de los datos

Google Cloud no usa los mismos permisos detallados para los archivos que puedes obtener con HDFS local. El enfoque menos complicado a los permisos de archivo es configurarlos a nivel de cada bucket de Cloud Storage. Si estableciste diferentes permisos para diferentes grupos de datos de HDFS, considera crear diferentes depósitos en Cloud Storage con diferentes permisos. Luego, pon los datos de HDFS en el bucket que tiene los permisos indicados para esos datos.

Si mueves archivos a una estructura en Cloud Storage que es diferente en HDFS, recuerda realizar un seguimiento de todos los cambios. Cuando muevas los trabajos a Dataproc, deberás proporcionar las rutas de acceso correctas a los datos en sus ubicaciones nuevas.

Planifica un traslado progresivo

Planifica mover tus datos en fragmentos discretos en el tiempo. Programa tiempo suficiente para mover los trabajos correspondientes a la nube entre traslados de datos. Comienza tu migración con el traslado de datos de prioridad baja, como copias de seguridad y archivos.

Divide tus datos

Si planeas mover tus datos de forma progresiva, debes dividirlos en múltiples partes. En las siguientes secciones, se describen las estrategias más comunes para dividir conjuntos de datos.

Divide tus datos por marca de tiempo

Un enfoque común para la división de datos de un traslado progresivo es almacenar datos anteriores en la nube y mantener tus datos nuevos en HDFS en tu sistema local. Esto te permite probar los trabajos nuevos y migrados en datos anteriores y menos críticos. Dividir tus datos de esta forma te permite empezar tu traslado con cantidades pequeñas de datos.

Consideraciones importantes:

  • ¿Puedes dividir tus datos mediante otro método además de por tiempo? Puedes obtener un conjunto de datos más parejo si divides los datos por los trabajos con los que son compatibles o por la organización propietaria y, luego, los divides aún más por tiempo.
  • ¿Debes usar una fecha o una hora absolutas o relativas? Algunas veces tiene sentido separar los datos en un punto en el tiempo, como archivar todos los datos generados antes de un cambio importante en tu sistema. A veces, es apropiado usar una fecha o una hora absolutas si quieres crear trabajos de reabastecimiento para probar tu sistema en la nube a fin de ver si puedes procesar datos anteriores a modo de que cumplan con tus estándares actuales. En otros casos, quizás quieras mover datos a la nube según una marca de tiempo relativa a la fecha actual. Por ejemplo, quizás muevas todos tus datos creados hace más de un año o todos los datos que no se editaron en los últimos tres meses.
  • ¿Qué valor de fecha o de hora usas para tomar la decisión? Muchas veces los archivos tienen múltiples valores de fecha o de hora. Algunas veces, la fecha de creación del archivo es la más importante. En otras ocasiones, quizás quieras usar el tiempo de última edición o alguna otra marca de tiempo de los metadatos del archivo.
  • ¿Tienen todos tus datos el mismo formato de marca de tiempo? Hay muchas formas de administrar las marcas de tiempo. Si tus datos provienen de más de una fuente, es posible que las marcas de tiempo se almacenen en formatos diferentes. Asegúrate de que tienes marcas de tiempo coherentes antes de usarlas para dividir tus datos.

Divide tus datos por trabajo

Algunas veces puedes dividir tus datos según los trabajos que los usan. Esto puede ser muy útil si migras trabajos de forma progresiva. Puedes mover solo los datos que usan los trabajos que mueves.

Consideraciones importantes:

  • ¿Los trabajos que mueves a la nube son autosuficientes? Dividir los trabajos es una gran opción para los trabajos en unidades de datos autosuficientes, pero pueden volverse difíciles de administrar si los trabajos usan datos que están dispersos en tu sistema.
  • ¿Qué posibilidades hay de que los datos tengan el mismo uso en el futuro? Piensa con cuidado antes de aislar datos que quizás uses de diferentes maneras.
  • ¿La migración de trabajos tiene el alcance apropiado para dar como resultado fragmentos de datos administrables?

También puedes usar criterios funcionales más amplios para dividir tus datos en lugar de solo un grupo de trabajos. Por ejemplo, podrías ejecutar todo el trabajo de ETL en la nube y, luego, ejecutar trabajos de análisis y de informes de forma local.

Divide los datos por propiedad

En algunos casos, puedes dividir tus datos por áreas de propiedad. Una ventaja de este enfoque es que la organización de datos se alinea con la organización del negocio. Otra ventaja es que te permite aprovechar la administración de acceso basada en funciones de Google Cloud. Por ejemplo, migrar datos que usa una función de negocios determinada a un bucket de Cloud Storage aislado facilita el establecimiento de permisos.

Consideraciones importantes:

  • ¿Están claros los límites entre propietarios? Por lo general, está claro quién es el propietario de un determinado dato. Algunas veces, las personas que más acceden a los datos no son los dueños.
  • ¿Hay otros criterios de división que puedan combinarse con la propiedad? Quizás tengas conjuntos de datos muy extensos con la división por propiedad. Puede ser útil acotar aún más si divides los datos otra vez por tarea o por tiempo.

Mantén los datos sincronizados en una solución híbrida

Uno de los desafíos de usar una solución híbrida es que, a veces, un trabajo necesita acceder a los datos de los sistemas locales y de Google Cloud. Si un conjunto de datos tiene que ser accesible en los dos entornos, necesitas establecer una ubicación de almacenamiento principal en un entorno y mantener una copia sincronizada en el otro.

Los desafíos de sincronizar datos son similares, sin importar qué ubicación primaria eliges. Necesitas una forma de identificar cuando un dato cambió y un mecanismo para propagar cambios en las copias correspondientes. Si hay potencial para cambios conflictivos, también necesitas desarrollar una estrategia a fin de resolverlos.

Consideraciones importantes:

  • Siempre realiza copias de datos de solo lectura si es posible. Tu estrategia de sincronización se vuelve más compleja con cada fuente potencial de ediciones nuevas.
  • En una solución híbrida, evita mantener más de dos copias de datos. Mantén solo una copia en el entorno local y una en Google Cloud.

Puedes usar tecnologías como Apache Airflow para ayudar a administrar la sincronización de datos.

Mueve los datos

En las siguientes secciones, se describen las consideraciones para transferir los datos a Google Cloud.

Configura el acceso a los datos

Los permisos de archivo funcionan de forma diferente en Cloud Storage y en HDFS. Antes de transferir los datos a Cloud Storage, debes familiarizarte con la administración de identidades y accesos (IAM).

La forma más fácil de administrar el control de acceso es ordenar los datos en bucket s de Cloud Storage según los requisitos de acceso y configurar la política de autorización a nivel de bucket. Puedes asignar funciones que le otorgan acceso a usuarios individuales o grupos. Otorga acceso por grupos y, luego, asigna usuarios a grupos según sea necesario. Debes tomar decisiones de acceso a datos mientras importas y estructuras los datos en Cloud Storage.

Todos los productos de Google Cloud tienen sus propios permisos y funciones. Asegúrate de comprender las relaciones entre los controles de acceso de Cloud Storage y los de Dataproc. Evalúa las políticas para cada producto por separado. No supongas que las funciones y los permisos se asignan de forma directa entre productos.

Familiarízate con la documentación siguiente a fin de prepararte para tomar decisiones sobre políticas de tu sistema de Hadoop basado en la nube:

Si necesitas asignar permisos más detallados a archivos individuales, Cloud Storage es compatible con listas de control de acceso (LCA). Sin embargo, IAM es la opción preferida. Usa LCA solo si los permisos son complejos.

Usa DistCp para copiar tus datos a Cloud Storage

Ya que Cloud Storage es un sistema de archivos compatible con Hadoop, puedes usar Hadoop DistCp para mover tus datos de HDFS local a Cloud Storage. Puedes mover datos de distintas formas con DistCp. Recomendamos esta forma:

  1. Establece un vínculo privado entre tu red local y la red de Google con Cloud Interconnect o Cloud VPN.

  2. Crea un clúster de Dataproc para usar en la transferencia de datos.

  3. Usa Google Cloud CLI para conectarte a la instancia principal del clúster. Por ejemplo:

    gcloud compute ssh [CLUSTER_NAME]-m

    En el ejemplo anterior, CLUSTER_NAME es el nombre del clúster de Dataproc que creaste para el trabajo. El sufijo -m identifica la instancia principal.

  4. En la instancia principal del clúster, ejecuta los comandos DistCp para mover los datos.

Los comandos DistCp que necesitas para mover los datos son similares a los comandos siguientes:

hadoop distcp hdfs://nn1:8020/20170202/ gs://bucket/20170202/

En este ejemplo, nn1 y 8020 son el nombre del nodo y el puerto que corresponden al almacenamiento de los datos de origen, y bucket es el nombre del bucket de Cloud Storage en el que copias el archivo.

El tráfico de Cloud Storage se encripta de forma predeterminada con Seguridad de la capa de transporte (TLS).

Valida transferencias de datos

Cuando copias o mueves datos entre sistemas de almacenamiento distintos, como varios clústeres de HDFS o entre HDFS y Cloud Storage, es una buena idea realizar algún tipo de validación para garantizar la integridad de los datos. Esta validación es fundamental para asegurarse de que los datos no se alteraron durante la transferencia. Si deseas obtener más detalles, consulta la guía para validar transferencias de datos.

Aumenta el porcentaje de solicitudes

Cloud Storage mantiene un índice de claves de objetos para cada bucket con el fin de proporcionar una lista coherente de objetos. Este índice se almacena en orden lexicográfico y se actualiza cuando se escriben o borran objetos de un bucket. Agregar y borrar objetos cuyas claves se encuentran en un rango pequeño del índice aumenta las posibilidades de contención.

Cloud Storage detecta esa contención y redistribuye de forma automática la carga en el rango del índice afectado en servidores múltiples. Si escribes objetos bajo un nuevo prefijo y anticipas que alcanzarás un porcentaje mayor a 1,000 solicitudes de escritura por segundo, debes incrementar el porcentaje de solicitudes de manera gradual, como se describe en la documentación de Cloud Storage. No hacerlo puede causar una latencia mayor temporaria y tasas de erros.

Mejora la velocidad de migración de datos

La forma más sencilla de transferir datos de los clústeres locales a Google Cloud es mediante un túnel VPN a través de la Internet pública. Si un solo túnel VPN no proporciona la capacidad de procesamiento necesaria, se pueden crear varios túneles VPN, y Google Cloud distribuirá el tráfico de forma automática entre los túneles para proporcionar un ancho de banda adicional.

Algunas veces, incluso múltiples túneles VPN no proporcionan suficiente ancho de banda o estabilidad de conexión para cumplir con las necesidades de la migración. Considera los siguientes enfoques para mejorar la capacidad de procesamiento:

  • Usa intercambio de tráfico directo entre la red y los puntos de presencia periféricos (PoP) de Google. Con esta opción, se reduce la cantidad de saltos entre la red y Google Cloud.

  • Usa un proveedor de servicios de Cloud Interconnect para establecer una conexión directa con la red de Google. Los detalles del servicio varían entre los distintos socios. La mayoría ofrecen un ANS para disponibilidad y rendimiento de la red. Comunícate directamente con un proveedor de servicios para obtener más información.

Trabaja con socios de Google Cloud

Google Cloud trabaja con una variedad de socios que pueden ayudarte a migrar los datos. Consulta socios que trabajan con Cloud Storage con el fin de obtener más información sobre los servicios disponibles para ayudarte con la migración de datos. Para obtener detalles, comunícate con los proveedores de forma directa, ya que los servicios y términos disponibles varían.

Pasos siguientes