Migra datos de HDFS local a Google Cloud Platform

En esta guía, se describe el proceso de trasladar datos de Hadoop Distributed File System (HDFS) local a Google Cloud Platform (GCP).

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

Planifica el traspaso de tus datos

La siguiente sección describe las recomendaciones para planificar la migración de tus datos de HDFS local a GCP. Planifica hacerlo de manera progresiva con el fin de que tengas tiempo de migrar trabajos, experimentar y realizar una prueba luego de trasladar cada cuerpo de datos.

Decide cómo trasladar tus 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 tus 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 fuente ejecuta los trabajos distcp en sus nodos de datos y envía los archivos de forma directa 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 Cloud Dataproc ejecuta los trabajos distcp en sus nodos de datos, extrae los archivos del clúster de fuente y los copia a 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 fuente puede enviar los datos de forma directa 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 fuente, ya que los nodos fuente se usan solo para entregar bloques fuera del clúster. Optimización de las especificaciones de los recursos del clúster de extracción en GCP para administrar las copias del trabajo y eliminar 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 fuente, debido a que el clúster efímero de Cloud Dataproc, que ya tiene el conector instalado, administra la transferencia de datos a Cloud Storage.

A fin de comprender las implicaciones de uso de red para ambos modelos, considera cómo Hadoop administra la replicación de datos en HDFS. Hadoop divide cada archivo en múltiples bloques, cuyo tamaño suele estar entre 128 y 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 con el modelo de envío, es decir, cuando el asignador de tareas distcp se ejecuta en el nodo de datos del clúster de fuente, se agrupan todos los bloques del archivo de varios nodos de datos. Luego, se extraen los bloques de archivo del clúster de fuente 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 con el método de envío (es decir, cuando el asignador de tareas distcp se ejecuta en un nodo de datos del clúster de envío en GCP), cada bloque viaja por la red una sola vez, ya que salen del clúster de fuente de forma directa. 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 asignadores de tareas distcp y ancho de banda usadas para evitar abrumar al clúster de fuente con demasiadas conexiones paralelas.

Decide a qué lugar mover tus 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 tus datos a Cloud Storage. Sin embargo, hay algunos casos en los que quizás quieras considerar mover datos a otro producto de GCP:

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

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

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

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

GCP no usa los mismos permisos detallados para archivos que puedes lograr con HDFS local. El enfoque menos complicado a los permisos de archivo es configurarlos a nivel de cada depósito 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 depósito 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 Cloud Dataproc, necesitarás proporcionar los patrones correctos para tus datos en sus nuevas ubicaciones.

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, puedes ejecutar todos tus trabajos de ETL en la nube, realizar un análisis y, luego, informar los trabajos locales.

Divide los datos por propiedad

En algunos casos, puedes dividir tus datos por áreas de propiedad. Una ventaja de este enfoque es que tu organización de datos se alinea con la organización de tu negocio. Otra ventaja es que te permite aprovechar la administración de accesos basada en funciones de GCP. Por ejemplo, migrar datos usados por una función de negocios determinada a un depósito 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.

Sincroniza tus datos en una solución híbrida

Uno de los desafíos de usar una solución híbrida es que, algunas veces, un trabajo necesita acceder a datos de GCP y de sistemas locales. 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 una sola copia local y una en GCP.

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

Mueve tus datos

Las secciones siguientes describen las consideraciones para mover tus datos a GCP.

Configura el acceso a tus datos

Los permisos de archivo funcionan de forma diferente en Cloud Storage y HDFS. Antes de mover tus datos a Cloud Storage, necesitas familiarizarte con Cloud Identity and Access Management (Cloud IAM).

La forma más fácil de administrar el control de acceso es ordenar los datos en depósitos de Cloud Storage según los requisitos de acceso y configurar tu política de autorización a nivel de depósito. 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 tus datos en Cloud Storage.

Cada producto de GCP tiene sus propios permisos y funciones. Asegúrate de comprender las relaciones entre los controles de acceso de Cloud Storage y los de Cloud 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, Cloud IAM es la opción preferida. Usa LCA solo si tus 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. Usa Cloud VPN para establecer un túnel de red privada virtual entre tu proyecto de GCP y tu red local.

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

  3. Usa la herramienta de línea de comandos de gcloud para conectar con la instancia principal de tu clúster. Por ejemplo:

    gcloud compute ssh [CLUSTER_NAME]-m
    

    Cuando CLUSTER_NAME es el nombre del clúster de Cloud Dataproc que creaste para tu 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 tus 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 en los que se almacenan tus datos de origen, y bucket es el nombre del depósito de Cloud Storage en el que copias el archivo.

Validar 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 objeto para cada depósito 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 depósito. Agregar y borrar objetos cuyas claves existen en un rango pequeño del índice aumenta, como es lógico, 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 simple de transferir datos de tus clústeres locales a GCP es con un túnel VPN en la Internet pública. Si un solo túnel VPN no proporciona la capacidad de procesamiento necesaria, se pueden crear múltiples túneles VPN y GCP distribuirá de forma automática el tráfico entre los túneles para proporcionar 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 tu migración. Considera los siguientes enfoques para mejorar la capacidad de procesamiento:

  • Usa intercambio de tráfico directo entre tu red y los puntos de presencia periféricos (PoP) de Google. Esta opción reduce la cantidad de saltos entre tu red y GCP.

  • 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 de forma directa a un proveedor de servicio para obtener más información.

Trabaja con socios de GCP

GCP trabaja con una variedad de socios que pueden ayudarte a migrar tus datos. Consulta socios que trabajan con Cloud Storage con el fin de obtener más información sobre los servicios disponibles para ayudarte con tu 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

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Cómo migrar Hadoop a GCP