Get best of the week

Los 10 conceptos erróneos principales sobre la portabilidad de Hadoop a la nube


Muchas empresas y corporaciones quieren usar la nube para procesar datos por razones obvias: flexibilidad, escalabilidad, solo puede pagar por lo que usa, etc.

De hecho, transferir un proyecto con un sistema de procesamiento de datos multicomponente, de la escala de Petabyte, desde el entorno local a la nube es un "pero" sólido. Hay muchos productos para la migración: Hadoop , Hive , Yarn , Spark , Kafka , Zookeeper , Jupyter , Zeppelin . Dada la diferencia fundamental en el entorno, es fácil perderse y cometer errores en esta variedad.

En este artículo hablaré sobre conceptos erróneos comunes y daré algunos consejos sobre la migración de calidad a la nube. Personalmente, uso AWS , pero todos los trucos son relevantes para otros proveedores con soluciones similares, por ejemplo, para Azure o GCP .

1. Copiar datos a la nube es fácil


Transferir varios petabytes de datos a la nube pública (por ejemplo, S3 ), que en nuestro caso funcionará como un lago de datos, no es una tarea fácil. Esto puede llevar mucho tiempo y recursos.

A pesar de la gran cantidad de soluciones, comerciales y de código abierto, no encontré una sola que cubriera todas las necesidades:

  • transmisión
  • integración de datos
  • verificación de datos
  • informes

Si cierta parte de los datos es mayormente estática o moderadamente dinámica, puede usar una solución como AWS Snowball , que le permite copiar matrices en un dispositivo físico. Los datos se descargarán de su red local, después de lo cual la unidad se enviará de vuelta al centro de datos de AWS y los datos se vertirán en el almacenamiento S3 .

Texto oculto
, , AWS.

Es una buena práctica dividir la transferencia de datos en dos fases. Después de que la mayor parte de la matriz se haya enviado y cargado en el repositorio, use una conexión directa del proveedor de la nube para descargar el resto. Puede usar los métodos Hadoop DistCP o Kafka Mirroring para esto . Ambos métodos tienen sus propios matices. DistCP requiere una planificación constante y un ajuste profundo, además, no todos los objetos se pueden colocar en listas en blanco y negro. Kafka MirrorMaker , además del ajuste profundo, necesita exportar métricas a través de la extensión de administración JMX para medir el rendimiento, la latencia y la estabilidad general.

Texto oculto
. — , .

2. La nube funciona igual que el almacenamiento local


El almacenamiento local y el almacenamiento en la nube no son lo mismo. Un buen ejemplo es Zookeeper y Kafka . La biblioteca del cliente ZK almacena en caché las direcciones permitidas de los servidores ZK durante toda la vida útil: este es un gran problema para la implementación en la nube, que requerirá muletas: las interfaces de red estáticas ENI para los servidores ZK .

Para la supervisión del rendimiento, es una buena idea ejecutar una serie de pruebas NFT no funcionales en la infraestructura de la nube para asegurarse de que la configuración y la configuración se adapten a sus cargas de trabajo.

Texto oculto
, , .

3. El almacenamiento de objetos 100% reemplaza HDFS


Separar las capas de almacenamiento e informática es una gran idea, pero hay una advertencia.

Con la excepción de Google Cloud the Storage , que utiliza una fuerte consistencia de datos ( consistencia fuerte) , la mayoría de las otras instalaciones de almacenamiento operan en el modelo de "consistencia eventualmente» (eventualmente consistente) . Esto significa que se pueden usar para ingresar datos sin procesar y procesados, y para generar resultados, pero no como un almacenamiento temporal.

Texto oculto
, HDFS.

4. Puede implementar infraestructura en la nube desde la interfaz de usuario


Para un entorno de prueba pequeño, esto puede ser fácil, pero cuanto más altos sean los requisitos de infraestructura, más probable es que escriba código. Es posible que desee tener varios entornos (Dev, QA, Prod) . Esto se puede implementar usando CloudFormation y Terraform , pero al copiar las piezas de código necesarias fallará, tendrá que rehacer mucho por sí mismo.

Texto oculto
— CI/CD . , .

5. Para una visibilidad correcta en la nube solo necesita usar $ {SaaS_name}


La buena visibilidad (registro y monitoreo) del entorno antiguo y nuevo es una condición crítica para una migración exitosa.

Esto puede ser difícil debido al uso de diferentes sistemas en entornos. Por ejemplo, Prometheus y ELK para el entorno local, y NewRelic y Sumologic para la nube. Incluso si una solución SaaS se aplica en ambos entornos, es difícil de escalar.

Texto oculto
, ( , , JMX, , ).

6. La nube escala al infinito


Los usuarios a menudo se regocijan cuando son niños cuando aprenden sobre la función de escala automática y piensan que la aplicarán inmediatamente en sus plataformas de procesamiento de datos. Es realmente fácil de configurar para nodos EMR sin HDFS , pero requerirá conocimientos adicionales para el almacenamiento persistente (por ejemplo, el corredor de software Kafka ). Antes de cambiar todo el tráfico a la infraestructura de la nube, debe verificar los límites de recursos actuales: el número de instancias de clase, discos, también debe precalentar los equilibradores de carga. Sin dicha capacitación, el potencial de trabajo no puede utilizarse como debería.

Texto oculto
, — , — .

7. Solo muevo mi infraestructura sin cambios


De hecho, en lugar de centrarse únicamente en las capacidades de un posible proveedor de servicios, es mejor centrarse en sus propios repositorios, por ejemplo, DynamoDB . Pero no se olvide de los servicios compatibles con la API. Alternativamente, puede usar el servicio en la nube de Amazon RDS para la base de datos Hive Metastore .

Otro buen ejemplo es la plataforma de big data optimizada para la nube EMR . A primera vista, simple, requiere un ajuste fino utilizando scripts posteriores a la instalación. Puede personalizar el tamaño de almacenamiento dinámico , archivos JAR , UDF de terceroscomplementos de seguridad. También tenga en cuenta que todavía no hay forma de proporcionar alta disponibilidad (HA) para los nodos principales NameNode o YARN ResourceManager .

Texto oculto
, , .

8. Transfiera las tareas de Hadoop / Spark a la nube: es fácil


Realmente no. Para transferir con éxito las tareas, debe tener una idea clara de la lógica y las canalizaciones de su negocio: desde la recepción inicial de datos sin procesar hasta las matrices de alta calidad. Todo se vuelve aún más complicado cuando los resultados de las tuberías X e Y son los datos de entrada de la tubería Z. Todos los componentes de los flujos y las relaciones deben mostrarse con la mayor claridad posible. Esto se puede implementar usando DAG .

Texto oculto
SLA.

9. Cloud reducirá los costos operativos y el presupuesto del personal


El equipo propio requiere costos y salarios físicos para los empleados. Después de pasar a la nube, todos los costos no desaparecerán: aún debe responder a las necesidades del negocio y contratar personas que se involucrarán en el desarrollo, el soporte, la resolución de problemas y la planificación del presupuesto. También deberá invertir en software y herramientas para la nueva infraestructura.

El personal debe ser una persona que entienda cómo funcionan las nuevas tecnologías. Esto implica un empleado altamente calificado. Por lo tanto, incluso teniendo en cuenta la reducción de personal, puede gastar tanto, si no más, en el salario de un buen especialista.

Texto oculto
— (, EMR), . , , .

10. No-Ops cerca ...


No-Ops es el sueño de cualquier negocio. Un entorno totalmente automatizado sin la necesidad de servicios y productos de terceros. ¿Es posible?

Un equipo modesto de varias personas es relevante solo para pequeñas empresas cuyas actividades no están directamente relacionadas con los datos. Todos los demás necesitarán al menos un especialista que integre y empaque todos los sistemas, los compare, los automatice, brinde visibilidad y elimine todos los errores que surjan en el camino.

Texto oculto
Data-Ops , .


Para resumir. La transferencia de canalizaciones de procesamiento de datos a la nube es buena. Para que la migración funcione como debería, debe planificar cuidadosamente el proceso, teniendo en cuenta todas las dificultades descritas anteriormente. Piense unos pasos adelante y todo saldrá bien.

More articles:


All Articles