Qunar de China agregó un sistema de archivos distribuido virtual llamado Alluxio, que hizo que HDFS pasara de perezoso a rápido.
Si vamos a hablar de datos verdaderamente GRANDES, tenemos que mirar a China. Con 1.300 millones de personas, una economía urbana en rápida expansión y tasas crecientes de penetración de Internet y teléfonos inteligentes, China genera una cantidad de datos alucinante cada año.
A modo de ejemplo, hablé con Baidu, el gigante de las búsquedas de China, acerca de cómo cruje petabytes de datos todos los días para realizar consultas analíticas en menos de 30 segundos. Puede mover datos a velocidades de memoria utilizando un nuevo software de almacenamiento distribuido virtual llamado Alluxio, anteriormente Tachyon, que fue desarrollado originalmente en el AMPLab de UC Berkeley.
Recientemente me puse al día con Lei Xu, ingeniero senior de grandes plataformas de datos de Qunar, el sitio de viajes de comercio electrónico más importante de China que transporta más del 80% de los negocios de viajes en línea en el Reino Medio. Tenía curiosidad por saber cómo su gran base de datos se mantiene al día con los crecientes requisitos de rendimiento y escala de su negocio.
ConsejoTecnologico.com: Primero, por favor describa la escala de sus grandes operaciones de datos en Qunar.
Xu: Nuestra plataforma de streaming procesa alrededor de seis mil millones de entradas de registro de sistema al día, es decir, más de 4,5 terabytes de datos. Todos los días. Y está creciendo rápidamente. Un ejemplo de un trabajo crítico que se ejecuta en esta plataforma es nuestro motor de recomendación de usuarios en tiempo real. La estabilidad y la baja latencia lo son todo. Se basa en el análisis de los registros de los clics y el comportamiento de búsqueda de los usuarios. Un análisis más rápido proporciona a nuestros usuarios una retroalimentación más precisa.
ConsejoTecnologico.com: ¿Cómo diseñó su backend original para el procesamiento de grandes datos y cuáles fueron los problemas con los que se encontró a medida que más usuarios visitaban su sitio?
Xu: Nuestros sistemas de procesamiento de flujos en tiempo real utilizan Apache Mesos para la gestión de clústeres. Utilizamos Mesos para gestionar Apache Spark, Flink, Logstash y Kibana. Los troncos provienen de múltiples fuentes y los consolidamos con Kafka. Los principales marcos de computación, Spark streaming y Flink, se suscriben a los datos en Kafka, procesan los datos y luego persisten los resultados en HDFS[Hadoop Distributed File System].
VER Momento de aleluya de los grandes desarrolladores de datos para el almacenamiento distribuido
Pero esta arquitectura tenía serios cuellos de botella.
Más información sobre Big Data
En primer lugar, el sistema de almacenamiento HDFS se ubicaba en un clúster remoto, añadiendo una mayor latencia de red. El intercambio de datos se convirtió en un punto de estrangulamiento. Debido a que HDFS utiliza discos giratorios, las operaciones de E/S (especialmente de escritura) también tienen una alta latencia. Los ejecutores de streaming de Spark necesitan leer desde HDFS y las repetitivas operaciones de lectura de cross-cluster realmente deprecian el rendimiento.
A continuación, si un ejecutor de streaming de Spark se queda sin memoria y falla, se reiniciará en otro nodo pero no podrá reutilizar la información de puntos de control del nodo original. Eso significa que algunos trabajos nunca pueden terminar.
Finalmente, cuando las tareas de streaming persisten con datos usando MEMORY_ONLY, se replican los datos en la memoria de la JVM causando problemas de recolección de basura e incluso fallos. Supongamos que te vuelves listo y usas MEMORY_TO_DISK o DISK_ONLY, entonces toda la arquitectura de procesamiento del rendimiento se ve limitada por la velocidad de la E/S del disco. Necesitábamos más velocidad.
ConsejoTecnologico.com: ¿Cómo eliminó estos cuellos de botella en su nueva arquitectura?
Xu: La lógica original de procesamiento del stream permanece sin cambios en la nueva arquitectura, pero hemos desplegado Alluxio entre los frameworks de computación y HDFS. En esta arquitectura, sólo es necesario que los resultados finales se mantengan en el clúster HDFS remoto. Los marcos de cálculo intercambian datos a través de Alluxio en tiempo real, con acceso a la velocidad de la memoria.
La principal diferencia antes y después es que muchos de los datos utilizados y generados por Spark streaming se almacenan en Alluxio, eliminando la comunicación con el lento y remoto clúster HDFS. Flink y Zeppelin y otros marcos de cálculo también acceden a los datos almacenados en Alluxio a velocidades de memoria.
VER ¿Podría Concord derribar a Apache Spark de su gran trono de datos?
Había varias características clave en Alluxio que nos ayudaron a mejorar drásticamente el rendimiento general del sistema y a reducir la latencia:
En primer lugar, Alluxio utiliza un enfoque de almacenamiento por niveles. Alluxio se ejecuta en todos los nodos de computación para administrar la memoria local, las SSD y el disco. Los datos requeridos por el procesamiento del flujo se guardan localmente tanto como sea posible, reduciendo el ancho de banda de la red. Alluxio aplica un aviso de desalojo inteligente para almacenar los datos en la memoria que se utiliza con más frecuencia.
El espacio de nombres unificado simplifica en gran medida la lógica de entrada y salida. Alluxio unifica la gestión de HDFS y proporciona un espacio de nombres global y unificado para todos los marcos de cálculo. La otra característica importante es una API simple con fácil integración. Es realmente fácil convertir aplicaciones que se ejecutan en HDFS a Alluxio cambiando «Alluxio» por «hdfs» en las URIs. ¡Eso es todo!
Por último, el almacenamiento fuera de pilas de Alluxio ayuda a la recogida de basura de Java. Los trabajos de Spark streaming almacenan datos en Alluxio en lugar de en la JVM del ejecutor de Spark. Esto mantiene los beneficios del rendimiento en memoria, a la vez que reduce en gran medida los costes de recogida de basura de Java. También previene errores fuera de memoria causados por bloques de datos redundantes en memoria en los ejecutores de Spark.
ConsejoTecnologico.com: ¿Qué tipo de recompensa viste al cambiar la arquitectura?
Xu: La actuación fue la gran recompensa. Nuestro nuevo sistema es mucho más rápido. Vimos una velocidad media de 15X con una velocidad de 300X en las horas de mayor servicio. El rendimiento aumentó de unos 20 a 300 eventos por segundo a un rendimiento estable de 7.800 eventos por segundo. A los usuarios de nuestro sitio de viajes les encantan los tiempos de respuesta más rápidos.
Boletín informativo de Big Data Insights
Domine los fundamentos de la analítica de datos de gran tamaño siguiendo estos consejos de expertos y leyendo los conocimientos sobre las innovaciones de la ciencia de datos. Lunes de entrega
mismo