Práctica de Hadoop de escala de cien PB de Qutoutiao
Zhu Qi pasado gran memoria de datos
con el rápido desarrollo de titulares de negocios divertidos, titulares interesantes y sus productos subsidiarios como lectura de contadores, etc., y matriz de productos innotech de la empresa matriz del Grupo, la cantidad total de volumen de datos de almacenamiento ha alcanzado alrededor de cien PB, incluido HDFS Los datos calientes de Alibaba Cloud y los datos fríos de Alibaba Cloud OSS. El número medio diario de tareas informáticas alcanza las 200.000 y la escala del clúster de Hadoop es de aproximadamente 2.000. El clúster Hadoop es compatible con varias plataformas de datos y negocios de Qu Toutiao y la empresa matriz Innotech Group. Ha pasado por varias etapas durante el año pasado. Hasta ahora, ha formado una sólida capacidad de autoinvestigación del código fuente y varias enfermedades intratables Posicionamiento de capacidades de análisis y resolución. A continuación, se presentan principalmente algunas optimizaciones de QuTouTiao durante los últimos años para los clústeres de Hadoop, con la esperanza de ayudar a otras empresas.
Problemas de escalabilidad y carga de NameNode
Desmantelar el puerto RPC y desmantelar NameSpace para formar la Federación
En respuesta al cuello de botella de un solo punto de NameNode, la arquitectura de federación HDFS se promovió después de que NameNode se dividió en el puerto RPC del cliente y el puerto RPC del servicio. La razón es que el punto único de NameNode tiene el problema de un aumento en los metadatos y el problema de un aumento en la carga del NameNode RPC.
Introduzca FastCopy para la migración de datos entre federaciones: como se muestra en la siguiente figura:
Para la copia entre los distintos NameSpaces de la Federación con una gran cantidad de datos, la eficiencia es aproximadamente 3 veces mayor que la de Distcp.
Balanceador de transferencia de carga y optimización de reubicación
Después de dividirse en la arquitectura de Federación, la operación HDFS Balancer causó mucha carga en el Active NameNode. Por esta razón, transferimos la carga de la operación Balancer al modo de espera, reduciendo así la carga RPC del Active NameNode. Específicamente, la idea de transferir la carga del equilibrador a Standby NameNode es coherente con la última idea de separación de lectura y escritura de HDFS de la comunidad. El problema específico de la comunidad de HDFS de separación de lectura y escritura es HDFS-12943, y el equilibrador correspondiente se transfiere a la Parche ObserverNode: HDFS-14162. Nuestra versión aún no admite la función de separación de lecturas y escrituras. Para reducir rápidamente la carga, lanzamos de manera proactiva excepciones para el RPC del Balancer al Nodo de nombre activo al Nodo de nombre en espera, y dejamos que el Nodo de nombre en espera libere el Equilibrador . Ignore los bloques pequeños al reubicar y aumente la velocidad de reubicación en orden descendente de mayor a menor. Los detalles son los siguientes:
Dividir NameSpace relacionado con el registro para reducir la carga
Con la arquitectura HDFS Federation, el registro seguirá afectando el NameSpace de la empresa de cada uno, por lo que modificamos las F por defecto a un NameSpace separado del sistema. También contribuimos a la comunidad Hadoop YARN para el directorio de envío, el directorio de agregación de registros se puede equilibrar con las diversas ideas de NameSpace. Para problemas específicos, consulte: YARN-9634.
Control de congestión para usuarios de NameNode
La comunidad propuso FairCallQueue. Como se muestra en la figura anterior, la estructura FIFO RPC original se ha cambiado a la estructura Fair para facilitar y limitar las cuentas únicas de alta frecuencia. Para obtener información detallada, consulte HADOOP-10282. Después de la aplicación, aísla efectivamente el impacto de Presto y otros servicios en línea en HDFS incluso cuando se reúne la concurrencia de los usuarios de consultas.
Actualmente utilizamos FairCallQueue + RPC Backoff, que puede satisfacer nuestras necesidades de control de congestión. Limite de forma eficaz el impacto de los usuarios con una carga anormalmente alta en la disponibilidad general de RPC.
Para NameSpace, que tiene una gran cantidad de usuarios, nos estamos preparando para dividir las prioridades de los usuarios en más niveles y llevar a cabo la garantía Qos multicapa.
Asincronice varias operaciones para mejorar el rendimiento de NameNode
Asincronización de editlog y auditlog
El comportamiento del registro de edición y el comportamiento del registro de auditoría de la versión original del NameNode se bloquean sincrónicamente, lo que tiene un gran impacto en el rendimiento del NameNode. Por esta razón, cambiamos los comportamientos del registro de edición y el registro de auditoría a asincrónico.
Optimización de informes de bloques
Después de que la cantidad de datos aumenta cada vez más, después de las estadísticas de la información de pila de NameNode, se descubre que la presión de los informes de bloques tiene un mayor impacto en los usuarios. Por esta razón, hemos considerado optimizar los informes de bloques. Primero, agregue sal cuando informe el bloque completo para dispersar la presión sobre el NameNode para el informe general. Luego, realice las siguientes optimizaciones durante los informes incrementales:
Primero, los informes de bloque en el lado de NameNode se agregan de forma asincrónica, lo que alivia efectivamente la presión de RPC. El problema correspondiente es: HDFS-9198.
Luego, los informes de bloque correspondientes en el lado de DataNode también se agregan en lotes, y el problema correspondiente es: HDFS-9710.
Seguimiento del tiempo de bloqueo de NameNode
HDFS-10872 agrega las métricas correspondientes al tiempo de bloqueo del NameNode. Cuando la longitud de la cola de bloqueos de NameNode se acumula demasiado, aumentamos el tiempo de bloqueo correspondiente al bloqueo global y analizamos la situación de que algunos bloqueos tardan demasiado en optimizar los detalles de muchos bloqueos.
Mejora de la puesta fuera de servicio
Las operaciones de desmantelamiento en grandes clústeres son muy comunes, como la migración de máquinas y fuera de línea, fallas de máquinas que requieren fuera de línea, etc. El antiguo código de Descomposición tiene los siguientes problemas:
• Atraviesa cada nodo y atraviesa cada disco, la carga está concentrada y no se distribuye a cada nodo y a cada disco, lo que hará que el disco de impacto esté muy caliente.
• A través del seguimiento del tiempo de bloqueo de NameNode mencionado anteriormente, se descubre que agregar un DataNode para desconectarse llevará mucho tiempo para escribir el bloqueo.
• El problema de la acumulación de colas de réplicas.
• Esperar a que la cola de replicación determine si es una réplica varias veces ocupará repetidamente el tiempo del bloqueo de escritura.
La comunidad también ha logrado recientemente una implementación más completa: HDFS-14854.
Garantía de calidad, control empresarial, límite actual y seguimiento de trabajos
Límites suaves y seguimiento de trabajos
Para los usuarios con alto acceso, la auditoría se mejora. El registro de auditoría actual no puede obtener la información del trabajo del usuario. Las visitas locas a algunas mesas grandes con un gobierno inadecuado debido a ciertas operaciones anormales tendrán un gran impacto en la estabilidad y el rendimiento del clúster. Con este fin, hemos introducido mejoras de auditoría. Esta parte debe cambiarse más, incluido el motor de cálculo, así como YARN, HDFS necesita cambiar algunos parches dependientes, principalmente:
• Relacionado con HDFS: HDFS-9184.
• Relacionado con YARN: YARN-4349.
• Relacionado con HIVE: HIVE-12254.
• Relacionado con SPARK: SPARK-15857.
Flink aún no tiene un CallerContext integrado, hemos mencionado un problema que debe mejorarse: FLINK-16809.
El almacenamiento de Flink ejerce una gran presión sobre HDFS Además del abuso comercial, existen serios problemas de archivos pequeños, consulte FLINK-11937.
De esta manera, hay información clave del trabajo en el registro de auditoría y, luego, al llamar a Kafka y Flink para un análisis en tiempo real, puede ubicar fácilmente los trabajos de alta carga de HDFS.
Límite estricto: cambios en el código fuente de NameNode
Otra forma difícil, no haga análisis post-mortem, haga fuertes restricciones antes del evento: el control de congestión mencionado anteriormente es el control de congestión correspondiente del usuario, aquí hay un límite estricto en el directorio, porque además del acceso irrazonable de alta frecuencia por usuarios, también hay tablas grandes o catálogos o tablas de biblioteca con una gobernanza muy imperfecta que pueden ser restringidas por QPS. Para operaciones como crear y eliminar, realice estadísticas de ventana en el RPC correspondiente al catálogo relevante en el código NameNode. Si el QPS es mayor que el umbral, el cliente El terminal devuelve un mensaje de reintento para limitar la corriente.
Experiencia del usuario y conveniencia de operación y mantenimiento.
Proxy HDFS de desarrollo propio
Debido a razones históricas, muchos algoritmos y otros servicios deben ser administrados por clientes independientes, y el rápido aumento de los servicios ha llevado a actualizaciones frecuentes de las configuraciones de los clientes, lo que ha generado una gran cantidad de costos de operación y mantenimiento humanos. Y hay demasiados tipos de clientes, como clientes de programación, clientes de programación en contenedores, pasarelas ordinarias, etc. Para transferir la configuración al servidor para su control, desarrollamos HDFS Proxy, no es necesario configurar el cliente y el cliente Hdfs reenvía la solicitud al servidor HDFS Proxy correspondiente. El proxy se puede escalar horizontalmente y se cuelga una capa de equilibrador de carga. Es muy liviano y se ha utilizado durante casi medio año. Debido a que el método de mantenimiento del cliente viewFs no es propicio para la gestión de operación y mantenimiento, y nuestra versión actual es relativamente antigua, y el enrutador no es lo suficientemente maduro, se usa principalmente para transición con el enrutador. La estructura específica se muestra en la siguiente figura:
Mejora del enrutador HDFS y desarrollo secundario
A medida que el enrutador madura y hemos realizado algunas mejoras personalizadas en el enrutador, estamos cambiando lentamente de nuestro ligero HDFS Proxy al enrutador. Después de todo, el poder del código abierto es excelente y tenemos que apoyarnos en los hombros de gigantes. .
Mejora del registro de auditoría del enrutador y el seguimiento de trabajos
El enrutador en sí es compatible con AuditLog. Por esta razón, hemos agregado un par personalizado de AuditLog y planeamos continuar rastreando las tareas en la capa del enrutador. Implemente límites suaves y seguimiento de trabajos en la capa del enrutador.
Refactorización de la basura del enrutador y optimización de RPC
Para optimizar el costo de los datos, hemos realizado un proyecto de ciclo de vida de Hive y hay una gran cantidad de operaciones de basura todos los días. El soporte del enrutador para la Papelera no es bueno. La comunidad tiene esquemas de modificación del lado del cliente similares, pero es muy poco amigable. Por esta razón, refactorizamos la operación de la Papelera y agregamos nuevas llamadas RPC. Después de la refactorización, no solo resuelve la eliminación de múltiples NameSpaces en el enrutador. También redujo la carga RPC de la Papelera anterior en el NameNode en un 50%, y el cliente cambió de (mkdir renombrar) -> basura. Esta pieza también se aporta a la comunidad, para ser mejorada: HDFS-15083.
El enrutador admite el control de cuota global
Si se montan varios NameSpaces en un solo directorio, el enrutador actualmente también admite el control de cuotas global, pero todavía hay algunos detalles que deben perfeccionarse.
Cambio de nombre del enrutador en la federación
La FastCopy entre los distintos NameSpaces de la Federación se ha introducido anteriormente. El enrutador tiene una función que puede lograr una función similar a FastMove. Para los directorios montados en NameSpace, se puede cambiar el nombre a otros NameSpaces.
Análisis en tiempo real del directorio HDFS
El análisis de la información del directorio HDFS debe analizarse desde FSImage. Una vez que el clúster es grande, nuestro FSImage alcanza decenas o cientos de gigabytes. El proceso de análisis es bastante lento y solo se puede analizar en modo T + 1. Para ello, hemos desarrollado un proyecto de análisis casi en tiempo real para tratar, por ejemplo: un directorio con un gran aumento de almacenamiento en un corto período de tiempo, un directorio con un fuerte aumento en el número de archivos pequeños.
Estrategia de agregación: use el código de operación de EditLog para usar Tidb o Durid para realizar agregaciones casi en tiempo real a través de la transmisión en tiempo real.
Hay muchos tipos de operandos, las principales operaciones de seguimiento son: OP_DELETE, OP_MKDIR, OP_ADD, OP_UPDATE_BLOCKS, OP_CLOSE, OP_RENAME_OLD.
Estabilidad y rendimiento del servicio
Debido a que el NameSpace de los 8 grupos comerciales de la Federación comparten el mismo servicio DataNode subyacente, y nuestro modelo tiene muchos bloques de disco, y la complejidad y diversidad del acceso comercial al DataNode, la presión sobre el NameNode se ha trasladado al DataNode.
DataNode DU causa IO pesado y reinicia un problema sin caché
El almacenamiento cambió de DU al cálculo de la memoria
De forma predeterminada, DataNode usa DU para resumir la cantidad total de almacenamiento en NameNode. La operación de DU ejerce mucha presión sobre el IO de DataNode, y el IO de DataNode no está separado del bloqueo global, y IO también ocupará el tiempo de bloqueo. Hay muchas soluciones para la fuerte presión de E / S de DU. Dispersar el tiempo de DU y agregar un número aleatorio a cada nodo para ralentizar el IO general, pero es inevitable que la operación de DU siga siendo necesaria.
Para el DU del disco, colocamos el cálculo del almacenamiento total en la memoria, porque la memoria en sí contiene la información del bloque del disco y se calcula regularmente en función de los resultados de los datos de la memoria. Última edición específica: HDFS-9710.
Resuelve el problema de reiniciar Uncached
Cuando el DataNode está en marcha, a menudo habrá un apagado desagradable, lo que hará que la caché de almacenamiento no se almacene en caché localmente, por lo que el cálculo se repetirá cuando se inicie, y el escenario de DU hará que el tiempo de reinicio sea muy largo. Por esta razón, con la adición de un hilo de tiempo para actualizar la caché, no hay necesidad de volver a calcular la cantidad total de almacenamiento al reiniciar. Para problemas específicos, consulte: HDFS-15171.
Nodo lento y optimización de cola larga de lectura y escritura
Cuando los nodos del clúster crecen día a día, es fácil causar otros problemas, como el envejecimiento de los nodos DataNode, lo que resulta en discos lentos o E / S de red lentas, lo que provocará problemas como largas colas de lectura y escritura de los usuarios.
Recopilación de métricas en DataNode: HDFS-10917 monitoreo de nodo lento e informe de latidos a NameNode: HDFS-11194.
Además del monitoreo de nodo lento del DataNode y el resumen de NameNode de la información del nodo lento, el cliente también puede monitorear la velocidad de lectura y escritura y leer y escribir nodos de DataNode de cola larga. Esta comunidad también tiene una implementación correspondiente que necesita mejorarse: HDFS-12861.
Habilitar lectura simultánea del cliente: para lecturas lentas, inicie otro hilo para leer simultáneamente. El tamaño del grupo de hilos es dfs.client.hedged.read.threadpool.size y el umbral para lecturas lentas dfs.client.hedged.read.threshold. millis (el valor predeterminado es 500)
Escriba un nodo lento: cuando escriba un nodo lento, realice una recuperación rápida de PipeLine de acuerdo con la situación del nodo lento.
Viaje de optimización de bloqueo de DataNode
El aumento en el volumen de negocios provocó que la carga de los 8 grupos de NameNodes llegara al DataNode. De repente, el tiempo de latido del DataNode aumentó repentinamente a unos pocos minutos, lo que provocó que el latido no se recibiera de inmediato. El DataNode a menudo moría en lotes durante períodos pico, lo que tuvo un grave impacto en el negocio. Por esta razón, analizamos la situación de la pila del DataNode y descubrimos que el bloqueo global del latido del DataNode estaba ocupado por otras operaciones de lectura y escritura simultáneamente altas, lo que provocó el bloqueo del subproceso de latido clave.
Bloqueo injusto sincronizado cambiado a bloqueo justo ReentrantLock
Primero, cambiamos el bloqueo injusto sincronizado del DataNode a un bloqueo justo por defecto.
ReentrantLock fair lock se desmonta en fair read-write lock
Para ReentrantLock reentrante global, se desmantela en un bloqueo de lectura y escritura, lo que tiene un buen efecto y alivia muchos bloqueos de miles de subprocesos.
Dividir en bloqueos de lectura y escritura de grano fino con BlockPool como unidad
Continúe rompiendo los bloqueos y divídalos en bloqueos de lectura y escritura con BlockPool como unidad. Esto significa que si tiene 8 conjuntos de NameSpace, un bloqueo global de DataNode se puede dividir en 8 bloqueos. Mencioné un problema en la comunidad: HDFS-15180. Desde la perspectiva de los nodos de escala de grises, la división adicional del bloqueo produce el efecto esperado. Antes de dividir, la operación de escaneo de Directory Scan tomará un tiempo de bloqueo prolongado, a menudo de hasta 10 segundos, o incluso decenas de segundos:
Después del desplazamiento, debido a que cada BlockPool se escanea por separado, el tiempo de bloqueo se reduce a 2 s, 1 s o incluso menos.
Cálculo de la capacidad de almacenamiento HDFS, después de cambiar de DU a cálculo de memoria, la parte de copia profunda de la memoria en sí tomará un tiempo de bloqueo prolongado de más de 300 ms. Después de dividir en bloqueos BlockPool, no hay más de 300 ms. Hay muchos casos en los que supera los 300 ms antes de dividirse:
El objetivo final, la unidad de cerradura más pequeña
El objetivo final es desmontar la unidad BlockPool correspondiente en un volumen en una cerradura. Como se muestra en la figura siguiente, si la Federación HDFS tiene 4 NameSpaces, cada DataNode tiene 3 bloques de disco. Luego corresponde a 4 BlockPool (BP) y 3 Volúmenes. El bloqueo global nativo de DataNode es un bloqueo. Idealmente, en este ejemplo, se puede dividir en 4 * 3 = 12 bloqueos de lectura-escritura., El rango bloqueado correspondiente es el parte superpuesta de las dos elipses. En la actualidad, hemos desmantelado BlockPool como una unidad.Correspondiente a este ejemplo, hay 4 bloqueos de lectura y escritura, que tienen un buen efecto en la mejora del rendimiento.
DataNode acepta instrucciones de forma asincrónica
Cuando revisamos el registro, encontramos que cuando el DataNode recibía una instrucción, bloquearía el subproceso de latido. Por esta razón, el subproceso bloqueado se cambió a un grupo de subprocesos asíncronos para procesar la operación de instrucción, de modo que el subproceso de latido no ser bloqueado. Como se muestra en la figura siguiente, antes de la modificación, el tiempo de bloqueo de los latidos del corazón puede alcanzar decenas de segundos.
DataNode IO y separación de bloqueo
Las operaciones de E / S de DataNode a veces tardan mucho en bloquearse. Por esta razón, nos estamos preparando para separar E / S y bloqueos.
Planificación continua y futura
• Hemos probado las nuevas funciones de Hadoop3 en el entorno de prueba y estamos listos para usarlo cuando se migre el nuevo clúster para completar la actualización de Hadoop2 a Hadoop3.
• El enrutador todavía tiene muchas funciones que se mejoran constantemente.
• Para resolver el problema de la gran proporción de lecturas de NameNode, vamos a probar la función de separación lectura-escritura en Hadoop3 y transferir las lecturas a Standby NameNode.
• Continuar con el seguimiento de las nuevas funciones:
• Bloqueo de segmento de NameNode: HDFS-14703, para resolver el problema del rendimiento del bloqueo de NameNode.
• Ozono, para resolver los problemas de archivos pequeños y la escalabilidad de NameNode, la capa inferior de almacenamiento de datos también es DataNode. Después de leer parte del código de Ozone en desarrollo, existe una función de almacenamiento de cambios en el lugar que aún está en desarrollo. Los datos de DataNode se convierten directamente de HDFS a Ozone. Es una función muy buena y puede haber otras sorpresas.
• Comparación de costo y rendimiento entre el almacenamiento en frío EC y el almacenamiento en frío OSS en la nube pública.
• El funcionamiento de HDFS es totalmente asíncrono: HDFS-9924.
• Tiempo de inicio optimizado de NameNode.
Este artículo fue aportado por un colega relacionado con Qutoutiao.
Sobre el autor: Zhu Qi, el grupo fuera de línea del departamento de big data de Qutoutiao es responsable del componente Hadoop. En 2018, se graduó de la Universidad de Correos y Telecomunicaciones de Nanjing con una maestría. Colaborador de Apache Hadoop HDFS && YARN. Como pasante, participó en trabajos relacionados con la virtualización en Citrix y en trabajos relacionados con el almacenamiento distribuido en el departamento de infraestructura de Morgan Stanley. Desde su graduación, ha estado involucrado en trabajos relacionados con Hadoop en el departamento de infraestructura de big data de China Telecom. Actualmente responsable de trabajos relacionados como Hadoop HDFS y Hadoop YARN en Qutoutiao.
Además, Li Fuqiang, jefe del grupo fuera de línea del departamento de big data de Qutoutiao, dio muchas sugerencias a este artículo.