Práctica de evolución nativa de la nube a gran escala de ByteDance Spark Shuffle

Spark es un motor informático ampliamente utilizado dentro de ByteDance y se ha utilizado ampliamente en varios escenarios de procesamiento de datos a gran escala, aprendizaje automático y big data. En la actualidad, el número de tareas diarias en China ha superado los 1,5 millones y el volumen diario de datos de lectura y escritura aleatoria supera los 500 PB. Al mismo tiempo, los datos aleatorios de algunas tareas individuales pueden alcanzar cientos de niveles de TB.

Al mismo tiempo, el volumen de trabajos y el volumen de datos aleatorios siguen creciendo: en comparación con el año pasado, el número de tareas diarias de este año aumentó en 500.000 y el volumen general de datos aumentó en más de 200 PB, alcanzando un 50%. aumentar. Shuffle es una función que a menudo se activa en los trabajos de los usuarios. Shuffle se utiliza en varias operaciones ReduceByKey, groupByKey, Join, sortByKey y Repartition. Por lo tanto, en los clústeres Spark a gran escala , Spark Shuffle a menudo se convierte en un cuello de botella para el rendimiento y la estabilidad; los cálculos aleatorios también implican operaciones frecuentes de E/S de disco y red . La solución es reparticionar y combinar los datos de todos los nodos. A continuación se presentará en detalle la práctica de evolución a gran escala de ByteDance en la dirección de la nativación de la nube Spark Shuffle.

Introducción al principio de Spark Shuffle

En el principio básico del modo Shuffle utilizado de forma predeterminada en el modo ESS de Community Edition, se acaba de mencionar que el cálculo de Shuffle repartirá los datos. Aquí, los datos del mapa se reorganizan en todos los reductores. Si hay M Mappers y R Reducers, los datos de partición de M Mappers se dividirán en la partición de R Reducers posteriores. El proceso Shuffle se puede dividir en dos etapas: Shuffle Write y Shuffle Read. Durante la escritura aleatoria, Mapper dividirá la partición actual en R nuevas particiones de acuerdo con la partición reducida, las ordenará y las escribirá en el disco local. La salida del mapa generada contiene dos archivos: el archivo de índice y el archivo de datos ordenados por partición. Cuando todos los mapeadores terminen de escribir la salida del mapa, comenzará la segunda fase: la fase de lectura aleatoria. En este momento, cada Reductor accederá a todos los ESS que contienen su Partición Reductora y leerá los datos de la Partición Reducida correspondiente. Aquí se podrá solicitar el ESS donde se encuentran todas las Particiones hasta que el Reductor obtenga los datos de todas las Reducir Particiones correspondientes.

En la fase Shuffle Fetch, cada ESS recibirá todas las solicitudes de Reducer y devolverá los datos correspondientes. Esto generará niveles M veces R de conexiones de red y lectura y escritura de disco aleatorias IO , lo que implica una gran cantidad de lecturas y escrituras de disco y transmisiones de red. Es por eso que Shuffle tiene solicitudes muy frecuentes de E/S de disco y red.

Dado que Shuffle tiene requisitos y consumo de recursos muy altos, es probable que la sobrecarga de CPU, disco y red sea la causa de Fetch Failure o el cuello de botella de la baja velocidad de Shuffle. En el escenario Shuffle a gran escala de ByteDance, es posible que el mismo nodo ESS deba servir a varios comerciantes al mismo tiempo, y estos clústeres no realizan aislamiento de IO , lo que puede hacer que Shuffle se convierta en la razón principal del fracaso del trabajo del usuario y en un punto débil.

Por lo tanto, ByteDance comenzó a trabajar en la nativación de Spark Shuffle en la nube a principios de 2021, y los trabajos de Spark y otros ecosistemas de big data comenzaron a migrar desde Yarn Gödel. Gödel es el programador de desarrollo propio de ByteDance basado en Kubernetes . Durante la migración, también proporciona una solución de migración para Hadoop a la nube: Yodel (Yarn on Gödel). Es un protocolo que es totalmente compatible con Hadoop Yarn y tiene como objetivo suavizar todos los grandes aplicaciones de datos Migrar al sistema Kubernetes.

En este conjunto de trabajos de migración, ESS también realizó trabajos relacionados con la personalización, completó el trabajo de adaptación de la migración del Servicio Auxiliar Yarn del modo anterior Yarn Node Manager al modo de implementación Kubernetes DaemonSet y comenzó la migración de trabajos Shuffle. Fueron necesarios dos años para migrar con éxito todas las aplicaciones de big data, incluidas las aplicaciones Spark , al ecosistema nativo de la nube actual en 2023 .

Desafíos nativos de la nube

Durante el proceso de migración nativa de la nube, también encontramos muchos desafíos:

En primer lugar, durante la migración de NM a DaemonSet , la CPU de ESS en DaemonSet tiene restricciones muy estrictas. En el modo NM anterior, ESS básicamente puede usar todos los recursos de la CPU. Por lo tanto, en esta práctica de migración, los recursos de CPU del ESS configurado inicialmente suelen ser insuficientes y requieren ajustes continuos. Más tarde, algunos clústeres de alta gama incluso utilizaron directamente la CPU ESS.
Al mismo tiempo, DaemonSet y Pod tienen límites más estrictos en la CPU de los trabajos de Spark . Esto también ha provocado que el trabajo de muchos usuarios se vuelva más lento después de migrar a la nueva arquitectura. Esto se debe a que en el modo anterior, la CPU estaba sobrecargada hasta cierto punto, por lo que es necesario ajustar esta situación. Hemos habilitado el modo CPU Shares bajo las arquitecturas Kubernetes y Gödel para que los usuarios no noten ninguna diferencia de rendimiento durante el proceso de migración.
Además, Pod tiene restricciones de memoria muy estrictas, lo que resulta en la imposibilidad de utilizar recursos de caché de página libres durante la lectura aleatoria , lo que resulta en una tasa de aciertos de caché de página muy baja durante la lectura aleatoria. En este proceso, se incurrirá en una mayor sobrecarga de E/S del disco, lo que dará como resultado un rendimiento general deficiente. Hemos tomado las medidas adecuadas para reducir el impacto de Shuffle en el rendimiento después de la migración abriendo adecuadamente el uso de la caché de páginas por parte de Pod.

Beneficios nativos de la nube

Después de completar el trabajo de migración, unificamos con éxito todos los grupos de recursos fuera de línea y pudimos implementar algunas estrategias de optimización y programación más amigables a nivel de programación, mejorando así la utilización general de los recursos. ESS Daemonset también ha obtenido muchos beneficios en comparación con Yarn Auxilary Service. En primer lugar, ESS DaemonSet es independiente y se convierte en un servicio, rompiendo el estrecho vínculo con NM, reduciendo los costos de operación y mantenimiento. Además, el aislamiento de los recursos de ESS por parte de Kubernetes y Pods también aumenta la estabilidad de ESS, lo que significa que ESS ya no se verá afectado por otros trabajos u otros servicios en el nodo.

Entorno nativo de la nube

Los trabajos de Spark nativos de la nube actualmente tienen dos entornos operativos principales:

Entorno de clúster de recursos estable . Estos grupos de recursos estables se centran principalmente en la tarea de ofrecer servicios de alta calidad y SLA. El disco implementado es un disco SSD con mejor rendimiento. Para estos grupos de recursos estables, utilizamos principalmente servicios ESS basados en la comunidad y profundamente personalizados; utilizamos discos SSD, lectura y escritura de ESS y discos SSD locales de alto rendimiento; se implementan en modo Daemonset y arquitectura Gödel.
Entorno de clúster de recursos ubicado en el mismo lugar . Estos clústeres sirven principalmente para trabajos de nivel medio a bajo, centrándose en algunas tareas temporales de consulta, depuración o prueba. Los recursos de estos clústeres se implementan principalmente en discos HDD y algunos se transfieren a través de recursos en línea o se comparten con otros servicios, o se implementan junto con otros servicios en línea. Esto significa que los recursos del clúster no son exclusivos y que el rendimiento general del disco y el entorno de almacenamiento no son particularmente excelentes.

Escenario de recursos estables

Dado que hay muchos trabajos de alta calidad en un entorno de clúster estable, la primera tarea es mejorar la estabilidad de la reproducción aleatoria de estos trabajos y la duración del trabajo durante el tiempo de ejecución para garantizar el SLA de estos trabajos. Para resolver el problema de Shuffle, las siguientes tres capacidades se han personalizado profundamente para ESS: mejorar las capacidades de monitoreo/gobernanza de ESS, agregar la función de limitación actual de ESS Shuffle y agregar la función de división de desbordamiento de Shuffle .

Personalización profunda de ESS

Mejorar las capacidades de seguimiento y gobernanza de ESS

Capacidades de monitoreo

En términos de monitoreo, durante el proceso de uso de la versión de código abierto , descubrimos que el monitoreo existente no era suficiente para solucionar en profundidad los problemas de Shuffle encontrados y el estado actual de ESS. Como resultado, no hay manera de localizar rápidamente qué nodos están causando el problema de Shuffle y no hay manera de detectar los nodos problemáticos. Por lo tanto, hemos realizado algunas mejoras en nuestras capacidades de monitoreo.

En primer lugar, se agregaron algunos indicadores clave para monitorear la lentitud de la reproducción aleatoria y las capacidades de tasa de recuperación, incluidos los fragmentos en cola y la tasa de recuperación de fragmentos. Queued Chunks se utiliza para monitorear la acumulación de solicitudes en los nodos ESS actualmente solicitados, mientras que Chunk Fetch Rate se usa para monitorear el tráfico de solicitudes en estos nodos. Al mismo tiempo, también hemos conectado los indicadores de métricas de ESS al sistema de métricas de ByteDance, lo que nos permite localizar rápidamente la acumulación de nodos de ESS a través de los indicadores de dimensión de aplicación proporcionados por el sistema. En términos de interfaz de usuario (UI), nuestra mejora es agregar dos nuevas funciones a la página de detalles de la etapa, que se utilizan para mostrar los nodos más lentos encontrados por cada tarea aleatoria en la etapa actual, así como todos los encuentros de tareas después de las estadísticas de la etapa. Al nodo superior con más tiempos de Shuffle. Las operaciones anteriores no solo facilitan las consultas de los usuarios, sino que también utilizan estos indicadores para construir mercados relevantes.

Con estas mejoras de monitoreo y UI, cuando los usuarios ven que Shuffle es lento en la UI, pueden abrir el monitoreo Shuffle correspondiente a través de la UI. Esto nos facilita a los usuarios y a nosotros localizar rápidamente los nodos ESS que causan problemas de Shuffle y ver rápidamente la situación real en estos nodos, para localizar rápidamente de qué aplicaciones provienen estas solicitudes acumuladas.

El nuevo monitoreo también detectará indicadores clave como la acumulación real de fragmentos y la latencia en el nodo ESS cuando se ejecuta y soluciona problemas de Shuffle . Esto ayuda a tomar medidas de manera más eficiente en tiempo real cuando Shuffle es lento. Una vez que se localiza el problema de Shuffle, podemos analizar la situación y proporcionar dirección y optimización de la gobernanza.

Capacidad de gobernanza

El trabajo de gobernanza se implementa principalmente a través del sistema BatchBrain . BatchBrain es un sistema inteligente de ajuste de trabajos especialmente diseñado para trabajos Spark , que recopila principalmente datos del trabajo y realiza análisis fuera de línea y en tiempo real. Estos datos recopilados incluyen el propio registro de eventos de Spark, eventos de línea de tiempo internos más detallados y varios indicadores de métricas , incluidos indicadores aleatorios personalizados agregados a ESS.

En el análisis fuera de línea, es principalmente necesario gestionar trabajos periódicos. Según las características históricas de cada trabajo y los datos recopilados, se analiza el rendimiento de la etapa Shuffle de estos trabajos. Después de múltiples ajustes iterativos, finalmente se proporciona un conjunto de parámetros Shuffle adecuados. ., para que estos trabajos puedan ejecutar los parámetros optimizados de Shuffle cuando se vuelvan a ejecutar, obteniendo así un mejor rendimiento y resultados.

BatchBrain también puede utilizar los indicadores Shuffle agregados anteriormente para el escaneo automático en la parte de análisis en tiempo real. Los usuarios también pueden consultar el estado de la reproducción aleatoria de trabajos en su clúster a través de la API BatchBrain , localizar de manera efectiva nodos y trabajos que experimenten acumulación aleatoria y notificar al personal relevante mediante alarmas. Si se descubre que Shuffle es lento debido a otros trabajos o trabajos anormales, los usuarios también pueden tomar acciones de administración directa, como detener o desalojar estos trabajos, para liberar más recursos para trabajos de mayor prioridad para Shuffle.

Función de limitación de corriente aleatoria

A través del monitoreo y administración de Shuffle, descubrimos que cuando Shuffle es lento en los nodos ESS, generalmente se debe a que el volumen de datos de algunas tareas es demasiado grande o se establecen parámetros inadecuados, lo que resulta en la cantidad de Mapper y Reducer de estas etapas de Shuffle. siendo demasiado alto Inusualmente grande. Una cantidad anormalmente grande de Mapper y Reducer puede causar una gran acumulación de solicitudes en el nodo ESS, y el tamaño del fragmento de estas solicitudes también puede ser muy pequeño. Es posible que el tamaño de fragmento promedio de algunos trabajos anormales ni siquiera alcance los 20 KB. Estos trabajos envían una gran cantidad de solicitudes a ESS, pero si ESS no las procesa a tiempo, eventualmente puede generar una gran cantidad de solicitudes, incluso causar retrasos en el trabajo o conducir directamente a fallas.

En respuesta a estos fenómenos, la solución que adoptamos es limitar el número total de solicitudes para cada Aplicación en el nodo ESS. Cuando las solicitudes de recuperación de una aplicación alcanzan el límite superior, ESS rechazará las nuevas solicitudes de recuperación enviadas por la aplicación hasta que la aplicación espere a que finalice la solicitud existente antes de poder continuar enviando nuevas solicitudes. Esto evita que una sola aplicación ocupe recursos excesivos en el nodo y provoque que ESS no pueda atender adecuadamente otras solicitudes de trabajo. También puede evitar que otros trabajos fallen o que la velocidad de reproducción aleatoria disminuya, y aliviar el impacto negativo de trabajos de reproducción aleatoria anormales o a gran escala en la reproducción aleatoria de clústeres.

Características de la función de limitación de corriente aleatoria

Cuando el trabajo se ejecuta normalmente, incluso si se inicia la función de limitación actual, no tendrá ningún impacto en el trabajo. Si el nodo puede funcionar normalmente, no es necesario activar ninguna limitación de corriente.
Solo cuando la carga del nodo exceda el rango tolerable y Shuffle IO exceda el umbral establecido, el mecanismo de limitación actual se activará para reducir la cantidad de solicitudes que las tareas anormales pueden enviar al ESS y reducir la presión actual sobre el servicio ESS. Dado que la capacidad de carga del servicio ESS ha excedido el rango tolerable en este momento, incluso si recibe estas solicitudes, no puede devolverlas normalmente, por lo que limitar las solicitudes excesivas de tareas anormales puede mejorar mejor el desempeño de estas tareas en sí.
En el caso de limitación de corriente, también se considerará la prioridad del trabajo. Para tareas de alta calidad, se permitirá un mayor tráfico.
Cuando el límite actual entre en vigor, si se descubre que el tráfico de ESS ha vuelto a la normalidad, el límite actual se eliminará rápidamente. Las aplicaciones con tráfico restringido pueden volver rápidamente a sus niveles de tráfico anteriores.

Flujo detallado de limitación de corriente.

La función de limitación actual se realiza principalmente en el servidor ESS. El indicador de latencia se escanea en el nodo cada 5 segundos. Cuando el indicador de latencia excede el umbral establecido, se determinará que la carga del nodo ha excedido la carga que puede soportar. . Luego, se evaluarán todas las aplicaciones que actualmente se encuentran en proceso de reproducción aleatoria en el nodo ESS para determinar si se habilita la limitación actual. Usando los indicadores agregados anteriormente, podemos contar el tráfico total de recuperación y IO en este nodo en los últimos 5 minutos . De acuerdo con el límite superior del tráfico total, el tráfico de cada aplicación que actualmente ejecuta Shuffle en cada nodo ESS se puede asignar razonablemente y restringido. . La distribución del tráfico también se ajusta según la prioridad de la Aplicación. Si la tasa de reproducción aleatoria o de recuperación de fragmentos acumulada de cualquier aplicación ha excedido su tráfico asignado, se limitarán y las solicitudes recién enviadas se rechazarán hasta que las solicitudes acumuladas se hayan liberado parcialmente.

También existe un sistema escalonado para la distribución de los límites actuales. Primero, la asignación se basa en la cantidad de aplicaciones que ejecutan Shuffle en el nodo actual . Cuanto mayor sea la cantidad de aplicaciones, menos tráfico se puede asignar a cada aplicación. Cuando la cantidad de aplicaciones en un nodo es relativamente pequeña, a cada aplicación se le puede asignar más tráfico. El nivel límite actual también se ajustará cada 30 segundos según la situación real del nodo.

En el caso de la limitación actual, si la latencia en el nodo no mejora y el tráfico aleatorio total no se recupera, la limitación actual se actualizará y se impondrán restricciones de tráfico más estrictas en todas las aplicaciones. Por el contrario, si la latencia mejora o el tráfico del nodo se recupera, el límite actual se reducirá o incluso se eliminará directamente. Por último, el límite actual también se ajusta adecuadamente en función de la prioridad de todos los trabajos.

Efectos y beneficios

Los problemas de apilamiento de fragmentos se alivian significativamente. Debido a la limitación actual , la acumulación de fragmentos causada por tareas anormales se reduce efectivamente, lo que reduce en gran medida la acumulación de una gran cantidad de solicitudes en algunos nodos del clúster.

Además, también se ha mejorado la situación de Latencia. Antes de activar la limitación de corriente, a menudo vemos una latencia alta en los nodos del clúster. Después de habilitar la función de limitación actual, la situación general de latencia se ha aliviado significativamente. Al reducir las solicitudes innecesarias e inválidas y limitar la cantidad de solicitudes iniciadas por varias tareas grandes o anormales a los nodos ESS, evitamos el impacto negativo de estas tareas anormalmente grandes en la carga del servicio ESS y reducimos la necesidad de realizar otras tareas de alta calidad. correr Impacto.

Función de división de desbordamiento aleatorio

Al analizar algunos trabajos aleatorios lentos , también descubrimos otro fenómeno: la cantidad de datos aleatorios escritos por cada ejecutor en un trabajo puede ser muy desigual. Dado que ESS utiliza el mecanismo de asignación dinámica, el tiempo de ejecución de cada ejecutor y la cantidad de tareas de mapa asignadas pueden ser diferentes. Esto hace que una gran cantidad de datos de Shuffle se concentren en unos pocos ejecutores durante la ejecución del trabajo, lo que hace que los datos de Shuffle se concentren en unos pocos nodos.

Por ejemplo, en la figura siguiente, encontramos que el volumen de escritura aleatoria de 5 Ejecutores supera al de otros Ejecutores en más de 10 veces. En este caso, las solicitudes de Shuffle pueden concentrarse en estos nodos, lo que hace que la carga en estos nodos ESS sea muy alta, lo que también aumenta indirectamente la posibilidad de Fetch Failure.

Para esta situación, la solución que brindamos es controlar la cantidad total de datos Shuffle escritos en el disco por cada contenedor o cada nodo. Esta función se puede lograr desde dos perspectivas. Primero, Spark controla el tamaño de escritura aleatoria del ejecutor, que es la cantidad máxima de datos escritos por cada ejecutor al ejecutar Shuffle. Cada Ejecutor calculará la cantidad de datos Shuffle que está escribiendo actualmente y reportará esta información al Spark Driver. Spark Driver puede utilizar el mecanismo Excluir en caso de falla para excluir proactivamente a los Ejecutores cuyos datos escritos hayan excedido el umbral del alcance de la programación y reciclar estos Ejecutores. Además, también mejoramos la estrategia de programación a través del programador Gödel e intentamos programar nuevos Ejecutores en otros nodos para evitar una escritura aleatoria excesiva de datos en un solo contenedor, lo que hará que el disco del nodo se llene o el conjunto de datos. en la etapa Shuffle Fetch se completará en estos nodos ESS.

Optimización nativa de la nube

Al mismo tiempo, también se han realizado algunas optimizaciones de funciones y programación de Executor en la nativación de la nube. A través de la estrategia del programador Gödel, se mejoran las capacidades de Shuffle. Al programar Ejecutores, algunos nodos con alta carga de Shuffle se pueden evitar tanto como sea posible, aliviando así la posibilidad de que estos nodos encuentren problemas de Shuffle. El programador también puede proporcionar funciones más completas para los Ejecutores, desalojar a los Ejecutores en nodos con una presión de disco particularmente alta o desalojar algunos contenedores que han escrito una gran cantidad de Shuffle en el disco cuando el espacio restante en el disco es insuficiente. El control de Spark Driver sobre Executor's Shuffle combinado con estas funciones de programación nativas de la nube puede dispersar los datos generales de Shuffle a más nodos, lo que hace que los datos de la etapa Shuffle Fetch y el volumen de solicitudes sean más equilibrados.

Efecto

Después de habilitar la optimización aleatoria en línea profundamente personalizada mencionada anteriormente, observamos efectos significativos. Los siguientes son algunos datos operativos de tres clústeres de alta calidad: el número total de tareas en estos tres clústeres de alta calidad cada día puede exceder las 300.000, pero el número promedio de trabajos que finalmente fallan debido a una falla de Shuffle Fetch es de alrededor de 20 a 30 por día Se puede decir que se ha logrado una tasa de falla de menos de 1/10000. Como se muestra en la figura anterior, se puede observar que la estabilidad de estos tres clústeres de alta calidad ha mejorado significativamente después de la optimización y los problemas encontrados por los usuarios en Shuffle también se han reducido considerablemente.

Escenario de recursos mixtos

Vale la pena señalar que , en la optimización de escenarios de clústeres de coubicación , Fetch Failure suele ser mucho más grave que en un entorno de recursos estable. El número promedio de fallas de recuperación por día es muy alto, la razón principal es que la mayoría de estos recursos provienen de la transferencia de recursos en línea inactivos, y sus capacidades de E/S de disco y espacio en disco son relativamente limitados. Además, algunos recursos se implementan combinados con HDFS u otros servicios. Dado que las IOPS y el espacio en disco pueden ser muy limitados, esto tiene un mayor impacto en el rendimiento aleatorio del clúster, por lo que la probabilidad de falla también es alta. El objetivo principal de la gestión de recursos de coubicación es reducir la tasa de fracaso de los trabajos y garantizar la estabilidad de los mismos, así como mejorar el rendimiento aleatorio de todo el clúster y reducir el desperdicio de recursos.

Para clústeres con recursos mixtos , la solución principal es el servicio Cloud Shuffle ( CSS ) de desarrollo propio , que reduce la dependencia de estos trabajos en los discos locales al proporcionar un servicio Shuffle remoto.

Introducción a las funciones CSS

El modo Push Based Shuffle es diferente del modo ESS que acabamos de presentar. En el modo Push Based Shuffle, los mismos datos de la partición reductora de diferentes Mappers se enviarán a un servicio remoto común, se fusionarán en este servicio y finalmente se escribirán en un determinado. o más archivos en el trabajador para que los datos de la partición se puedan leer a través del modo de lectura secuencial durante la etapa de reducción, lo que reduce la sobrecarga de E/S aleatoria .
Admite la función Grupo de particiones , que se utiliza para asignar datos de múltiples particiones a un Grupo de particiones reductor. De esta manera, durante la etapa de Mapa, Mapper puede transferir datos a través de Batch Push y transferir directamente los datos por lotes a los nodos de trabajo del grupo de particiones correspondiente, reduciendo así la sobrecarga de IO en modo por lotes y mejorando el rendimiento del modo por lotes.
La función rápida de copia de seguridad de doble escritura utiliza el modo de agregación y reproducción aleatoria basado en push. En realidad, todos los datos se recopilan en un trabajador. Si los datos del trabajador se pierden, todo el asignador tendrá que recalcular los datos correspondientes. Por lo tanto, para la función de agregación push, es importante utilizar una copia de seguridad de doble escritura. CSS mejora la velocidad de escritura al adoptar el modo de copia en memoria de doble escritura y realizar un vaciado de disco asincrónico , de modo que Mapper pueda continuar enviando datos posteriores sin esperar a que finalice el vaciado del disco.
Función de equilibrio de carga , CSS gestiona los nodos en todos los servicios a través de un Administrador de clústeres. Cluster Manager recopilará y recopilará periódicamente información de carga informada por los nodos trabajadores de CSS. Cuando se envíe una nueva aplicación, realizará una asignación equilibrada de recursos para garantizar que la escritura aleatoria y la lectura aleatoria se asignen a los clústeres con tasas de utilización más bajas. Equilibrio de carga aleatorio en el clúster.

Estructura general

Cluster Manager es responsable de la asignación de recursos del clúster y de mantener el estado de los trabajadores y las aplicaciones del clúster. Puede guardar esta información a través de Zookeeper o el disco local para lograr servicios con alta disponibilidad.
Worker admite dos modos de escritura, a saber, el modo de disco y el modo HDFS . Actualmente, el modo de disco se usa comúnmente y los datos de cada partición se escriben en dos nodos de trabajo diferentes para lograr la redundancia de datos.
CSS Master está ubicado en el lado del controlador Spark y es el principal responsable del contacto de los latidos con el Administrador de clústeres y el ciclo de vida de la aplicación. Cuando se inicia un trabajo, también solicitará un Trabajador del Administrador de Clúster. El proceso de Shuffle Stage también contará los metadatos y el progreso de Shuffle Stage.
Shuffle Client es un componente conectado a Spark Shuffle API, que permite que cualquier trabajo de Spark use CSS directamente sin configuración adicional. Cada Ejecutor utilizará ShuffleClient para leer y escribir. Shuffle Client es responsable de la doble escritura al escribir. Al leer, puede leer los datos de cualquier trabajador que tenga datos. Si uno de los trabajadores no puede leer, cambiará automáticamente a otro trabajador y deduplicará los datos que se han leído varias veces. .

proceso de lectura y escritura

Cuando se escribe CSS , el trabajador enviará datos directamente y el asignador enviará los datos a dos trabajadores al mismo tiempo. El trabajador no esperará hasta que se vacíe el disco y regresará al asignador, sino que devolverá el resultado al Mapper de forma asincrónica . Si encuentra una falla, se enviará al siguiente trabajador. Solicitud para notificar a Mapper. En este momento, Mapper volverá a solicitar dos nuevos trabajadores del nodo y volverá a enviar los datos fallidos. Al leer, los datos se pueden leer desde cualquier nodo y deduplicar a través de ID de mapa, ID de intento e ID de lote .

Rendimiento y evolución futura

En la prueba de rendimiento comparativa de TPC-DS de 1 TB, CSS mejoró en más de un 30 % en Query.

Como servicio Shuffle remoto, CSS en realidad es particularmente adecuado para la nativación de la nube, admite una implementación flexible o admite servicios de ahorro más remotos. En la actualidad, CSS también es de código abierto. Los amigos interesados pueden visitar el sitio web de código abierto de CSS para obtener más información. También esperamos que algunas iteraciones y optimizaciones posteriores se puedan sincronizar con la comunidad. En la evolución futura de la nube nativa, es necesario respaldar la implementación elástica, los servicios de almacenamiento remoto y otras capacidades relacionadas.

GitHub: github.com/bytedance/CloudShuffleService