Migración de Hadoop a la Nube: 2X de Capacidad de Almacenamiento y Menos Costos de Operaciones

Yimian es un proveedor líder de análisis de datos impulsado por IA especializado en datos de comercio digital. Ofrecemos información en tiempo real sobre estrategia comercial, desarrollo de productos y operaciones de comercio digital. Muchos de nuestros clientes son líderes en el sector de cuidado personal, maquillaje, F&B, mascotas y automóviles, como Procter and Gamble, Unilever y Mars.

Nuestra arquitectura de tecnología original era un clúster de big data construido con CDH (Cloudera Distributed Hadoop) en un centro de datos en las instalaciones. A medida que creció nuestro negocio, el volumen de datos aumentó drásticamente.

Para abordar desafíos como ciclos de escalamiento prolongados, recursos de cómputo y almacenamiento desalineados, y costos de mantenimiento elevados, decidimos transformar nuestra arquitectura de datos y migrar a la nube, adoptando un enfoque de separación de almacenamiento y cómputo. Después de una evaluación cuidadosa, adoptamos Alibaba Cloud Elastic MapReduce (EMR) + JuiceFS + Alibaba Cloud Object Storage Service (OSS).

Actualmente, con JuiceFS, hemos implementado una arquitectura desacoplada de cómputo y almacenamiento, duplicando nuestra capacidad total de almacenamiento. Es digno de mención que no observamos un impacto significativo en el rendimiento, y nuestros costos operativos se han reducido significativamente.

En este artículo, compartiremos nuestro diseño de arquitectura para migrar Hadoop a la nube, por qué elegimos JuiceFS+EMR+OSS y cómo nos beneficiamos de la nueva arquitectura. Nuestro objetivo es ofrecer ideas valiosas para aquellos que enfrentan desafíos similares a través de esta publicación.

Nuestra Antigua Arquitectura y Desafíos

Para satisfacer nuestras crecientes demandas de aplicaciones, hemos estado rastreando datos de cientos de sitios web grandes, con el recuento actual superando los 500. Con el tiempo, hemos acumulado cantidades sustanciales de datos crudos, intermedios y de resultados. A medida que continuamos expandiendo nuestros rastreos de sitios web y base de clientes, nuestro volumen de datos aumentaba rápidamente. Por lo tanto, decidimos escalar nuestro hardware para adaptarnos a las crecientes necesidades.

La Arquitectura Original

La siguiente figura muestra nuestra arquitectura anterior, que involucraba un clúster de big data basado en CDH desplegado en un centro de datos:

• Los componentes clave incluían Hive, Spark y HDFS.
• Varios sistemas de producción de datos, siendo Kafka uno de ellos, alimentaban el clúster.
• Utilizamos otras soluciones de almacenamiento, como TiDB, HBase y MySQL, junto con Kafka.

Original architecture at Yimian

Los datos fluían desde los sistemas de aplicaciones y sistemas de recopilación de datos de nivel superior, donde se escribían en Kafka. Utilizamos un clúster de Kafka Connect para sincronizar los datos en HDFS.

Sobre esta arquitectura, desarrollamos una plataforma de desarrollo de datos personalizada llamada OneWork para administrar diversas tareas. Estas tareas se programaban a través de Airflow y se procesaban en colas de tareas.

Nuestros Puntos Débiles

Los desafíos a los que nos enfrentábamos eran los siguientes:

• Crecimiento rápido de datos de aplicaciones y largos ciclos de escalado: Nuestro clúster CDH, desplegado en 2016, ya manejaba petabytes de datos para 2021. Sin embargo, el crecimiento de los datos a menudo superaba la planificación de hardware, lo que llevaba a frecuentes escalas cada seis meses. Esto consumía importantes recursos y tiempo.
• Agrupamiento de almacenamiento y cómputo y dificultad en la planificación de capacidad: La arquitectura tradicional de Hadoop tiene un acoplamiento estrecho entre almacenamiento y cómputo, lo que dificulta escalar e planificar de manera independiente según las necesidades de almacenamiento o cómputo. Por ejemplo, expandir el almacenamiento también requeriría adquirir recursos de cómputo innecesarios. Esto llevó a una asignación de recursos ineficiente.
• Miedo a actualizar debido a nuestra versión de CDH: Nuestra versión de CDH era antigua, y dudamos en actualizar debido a preocupaciones sobre estabilidad y compatibilidad.
• Altos costos de operaciones: Con aproximadamente 200 empleados, solo teníamos un personal de operaciones a tiempo completo. Esto generó una pesada carga de trabajo. Para aliviar esto, buscamos una arquitectura más estable y sencilla.
• Punto de fallo único en el centro de datos: Almacenar todos los datos en un solo centro de datos representaba un riesgo a largo plazo. En caso de daños en los cables u otros problemas, tener un solo centro de datos crea un único punto de fallo.

Nuestras Requisitos para la Nueva Arquitectura

Para abordar nuestras desafíos y satisfacer las crecientes demandas, decidimos realizar algunos cambios arquitectónicos. Los aspectos principales que consideramos para la actualización incluyen lo siguiente:

• Adopción de la nube, escalabilidad elástica y flexibilidad operativa: Aprovechar los servicios en la nube simplificaría las operaciones. Por ejemplo, utilizar almacenamiento basado en la nube nos permite centrarnos en la aplicación evitando tareas de mantenimiento. Además, los recursos en la nube permiten escalabilidad elástica sin largos despliegues de hardware y configuraciones de sistema.
• Desacoplamiento de almacenamiento y cómputo: Nuestro objetivo era separar el almacenamiento y el cómputo para lograr una mejor flexibilidad y rendimiento.
• Preferencia por componentes de código abierto, evitando el bloqueo de proveedores: Aunque utilizamos servicios en la nube, buscamos minimizar la dependencia de proveedores específicos. Mientras usamos AWS Redshift para servicios de clientes, nos inclinamos hacia componentes de código abierto para operaciones internas.
• Compatibilidad con soluciones existentes, controlando costos y riesgos: Nuestro objetivo era garantizar la compatibilidad con soluciones actuales para minimizar los costos de desarrollo y el impacto en nuestra aplicación.

Por qué elegimos JuiceFS+EMR+OSS

Después de evaluar varias soluciones, elegimos EMR+JuiceFS+OSS para construir una plataforma de big data con almacenamiento y cómputo separados y gradualmente migramos nuestro centro de datos on-premise a la nube.

New architecture at Yimian

En esta configuración, el almacenamiento de objetos reemplaza a HDFS, y JuiceFS actúa como capa de protocolo debido a su soporte para protocolos POSIX y HDFS. En la parte superior, utilizamos una solución semi-gestionada de Hadoop, EMR. Incluye componentes como Hive, Impala, Spark, Presto/Trino, entre otros.

Alibaba Cloud vs. Otras Nubes Públicas

Después de una cuidadosa evaluación, elegimos Alibaba Cloud frente a AWS y Azure debido a los siguientes factores:

• Proximidad: La zona de disponibilidad de Alibaba Cloud en la misma ciudad que nuestro centro de datos garantiza baja latencia y costos reducidos de red.
• Componentes de código abierto integrales: Alibaba Cloud EMR ofrece una amplia gama de componentes de código abierto relacionados con Hadoop. Además de nuestro intenso uso de Hive, Impala, Spark y Hue, también proporciona integración sin problemas con Presto, Hudi, Iceberg y más. Durante nuestra investigación, descubrimos que solo EMR incluye nativamente Impala, mientras que AWS y Azure ofrecen versiones más bajas o requieren instalación y despliegue manuales.

JuiceFS vs. JindoFS

¿Qué es JuiceFS?

JuiceFS es un sistema de archivos distribuido, de código abierto y nativo de la nube con alto rendimiento. Proporciona compatibilidad completa con POSIX, permitiendo el uso de almacenamiento de objetos como un disco local masivo en diferentes plataformas y regiones.

JuiceFS adopta una arquitectura separada de datos-metadatos, lo que permite un diseño de sistema de archivos distribuido. Al usar JuiceFS para almacenar datos, los datos se persisten en almacenamiento de objetos como Amazon S3, mientras que los metadatos pueden almacenarse en bases de datos como Redis, MySQL, TiKV, SQLite, entre otros.

Además de POSIX, JuiceFS es completamente compatible con el SDK de HDFS, permitiendo la sustitución sin problemas de HDFS para la separación de almacenamiento-cómputo.

The JuiceFS architecture

¿Por qué elegimos JuiceFS sobre JindoFS?

Optamos por JuiceFS en lugar de JindoFS basándonos en las siguientes consideraciones:

• Diseño de almacenamiento: JuiceFS emplea una arquitectura de almacenamiento separada para datos y metadatos, lo que permite un diseño de sistema de archivos distribuido. Los datos se persisten en almacenamiento de objetos, mientras que los metadatos pueden almacenarse en varios tipos de bases de datos como Redis, MySQL, TiKV y SQLite, lo que ofrece mayor flexibilidad. Por otro lado, JindoFS almacena los metadatos en el disco local del clúster EMR, lo que hace que el mantenimiento, las actualizaciones y las migraciones sean menos convenientes.
• Flexibilidad de almacenamiento: JuiceFS ofrece diversas soluciones de almacenamiento, soportando la migración en línea entre diferentes esquemas y aumentando la portabilidad. JindoFS solo soporta datos de bloque en OSS.
• Soporte de la comunidad de código abierto: JuiceFS se basa en una comunidad de código abierto, soportando todos los entornos de nube pública. Esto facilita la futura expansión a una arquitectura multi-nube.

El Diseño Arquitectónico Completo

Teniendo en cuenta que algunas aplicaciones seguirán estando en el clúster Hadoop del centro de datos, en realidad adoptamos una arquitectura de nube híbrida, como se muestra en la figura a continuación.

A hybrid cloud architecture

En el diagrama de arquitectura:

• En la parte superior se encuentran Airflow y OneWork, ambos soportan el despliegue distribuido, por lo que pueden escalarse horizontalmente fácilmente.
• A la izquierda se encuentra el IDC, que utiliza la arquitectura CDH tradicional y algunos clústeres de Kafka.
• A la derecha se encuentra el clúster EMR desplegado en Alibaba Cloud.

El IDC y el clúster EMR están conectados mediante una línea dedicada de alta velocidad.

Cómo Beneficiamos de la Nueva Arquitectura

Beneficios de la Separación Almacenamiento-Cómputo

Con la implementación del desacoplamiento de almacenamiento y cómputo, nuestra capacidad total de almacenamiento se ha duplicado, mientras que los recursos de cómputo permanecen estables. A veces, habilitamos nodos de tareas temporales según sea necesario. En nuestro escenario, el volumen de datos experimenta un crecimiento rápido, mientras que las demandas de consulta permanecen estables. Desde 2021, nuestro volumen de datos se ha duplicado. Hemos realizado cambios mínimos en los recursos de cómputo desde el inicio hasta ahora, excepto por la habilitación ocasional de recursos elásticos y nodos de tareas temporales para atender necesidades específicas de aplicaciones.

Cambios en el Rendimiento

Para nuestro escenario de aplicación, que principalmente involucra procesamiento masivo por lotes para cálculos fuera de línea, no hay un impacto significativo en el rendimiento. Sin embargo, durante la fase de PoC, observamos mejoras en los tiempos de respuesta para consultas ad-hoc de Impala.

Durante la fase de PoC, realizamos algunas pruebas simples. Sin embargo, interpretar los resultados de manera precisa es desafiante debido a varios factores influyentes:

• La transición de HDFS a JuiceFS
• Actualizaciones de versiones de componentes
• Cambios en el motor de Hive
• Cambios en la carga del clúster

Todo esto hace difícil sacar conclusiones definitivas sobre las diferencias de rendimiento en comparación con nuestra configuración anterior de CDH en servidores de metal suave.

Facilidad de Uso y Estabilidad

No hemos enfrentado problemas con JuiceFS.

Al utilizar EMR, tuvimos problemas menores. En general, CDH se percibe como más estable y amigable para el usuario.

Complejidad de Implementación

En nuestro escenario, los procesos más costosos en términos de tiempo son la escritura dual incremental y la verificación de datos. En retrospectiva, invertimos excesivamente en verificación y podríamos simplificarla.

Varias factores influyen en la complejidad:

• Escenarios de aplicación (offline/en tiempo real, número de tablas/tareas, aplicaciones de nivel superior)
• Versiones de componentes
• Herramientas de soporte y reservas

Planes futuros

Nuestros planes futuros incluyen:

• Continuar la migración de las aplicaciones restantes a la nube.
• Explorar una estrategia de almacenamiento escalonada frío/caliente utilizando JuiceFS+OSS. Los archivos de JuiceFS se desensamblan completamente en OSS, lo que dificulta la implementación de escalonamiento a nivel de archivo. Nuestro enfoque actual implica migrar datos fríos de JuiceFS a OSS, configurándolos como almacenamiento de archivo, y modificar la LOCALIZACIÓN de las tablas o particiones de Hive sin afectar el uso.
• Si el volumen de datos aumenta y hay presión en el uso de Redis, podríamos considerar cambiar a TiKV u otros motores en el futuro.
• Explorar instancias de cómputo elásticas de EMR para reducir los costos de uso mientras se cumplen los acuerdos de nivel de servicio de la aplicación.