Optimización del rendimiento de escritura de HBase

El artículo anterior presentó principalmente las rutinas básicas de optimización del rendimiento de lectura de HBase. Este artículo hablará sobre cómo diagnosticar anomalías de escritura de datos de HBase y optimizar el rendimiento de escritura. En comparación con la lectura, el proceso de escritura de datos en HBase es muy simple: los datos se escriben en HLog en orden y luego se escriben en el Memstore de caché correspondiente. Cuando el tamaño de los datos en Memstore alcanza un cierto umbral (128 M), el sistema se ejecuta de forma asincrónica. Actualiza los datos en Memstore en HDFS para formar un archivo pequeño.

La escritura de datos de HBase generalmente encuentra dos tipos de problemas: uno es el rendimiento de escritura deficiente y el otro es que los datos no se pueden escribir. Los puntos de entrada para estos dos tipos de problemas son diferentes, como se muestra en la siguiente figura:

Principio de optimización: el proceso de escritura de datos puede entenderse como una escritura secuencial en WAL y una caché de escritura. El tiempo de escritura del caché es muy bajo, por lo que para mejorar el rendimiento de escritura, solo puede comenzar con WAL. Por un lado, el mecanismo WAL garantiza que incluso si los datos escritos en el caché se pierden, se puedan recuperar, por otro lado, para lograr una replicación asincrónica entre clústeres; Replicación asincrónica. Primero considere si la empresa necesita escribir en WAL. Por lo general, la mayoría de las empresas activarán el mecanismo WAL (predeterminado). Sin embargo, para algunas empresas, es posible que no les importe especialmente la pérdida de algunos datos en circunstancias anormales, pero sí les importa más. Rendimiento de escritura de datos, por ejemplo, para algunas empresas recomendadas, incluso si los datos de comportamiento de algunos usuarios se pierden en dichas empresas, es posible que no tenga un impacto significativo en los resultados de la recomendación. No tendrá un gran impacto en los resultados de la recomendación, pero los requisitos de rendimiento de escritura son muy altos y la cola de datos no se puede bloquear. En este caso, puede considerar desactivar la escritura WAL y el rendimiento de escritura se puede aumentar entre 2 y 3 veces. La segunda opción es que algunas empresas no pueden aceptar no escribir WAL, pero pueden aceptar la escritura asincrónica de WAL, y también se puede considerar la optimización, que generalmente resulta en una mejora del rendimiento de 1x ~ 2x.

Sugerencia de optimización: elija entre el mecanismo WAL y el rendimiento de escritura según el enfoque comercial

Otras notas: para las empresas que utilizan operaciones de incremento, WAL se puede desactivar. Para la escritura asincrónica, el método es similar a Put. Creo que la mayoría de las operaciones de incremento pueden no ser tan sensibles a WAL ~

Principio de optimización: HBase proporciona interfaces API de colocación única y por lotes. El uso de la interfaz de colocación por lotes puede reducir la cantidad de conexiones RPC entre el cliente. y RegionServer. Esto mejora el rendimiento de escritura. También es importante que todas las solicitudes de entrega por lotes regresen exitosamente o generen una excepción.

Sugerencia de optimización: utilice la entrega por lotes para solicitudes de escritura

Principio de optimización: si la empresa puede aceptar una pequeña pérdida de datos cuando se producen excepciones, también se puede utilizar el envío por lotes asincrónico para enviar solicitudes. El envío se divide en dos etapas de ejecución: después de que el usuario envía una solicitud de escritura, los datos se escribirán en la memoria caché del cliente y se devolverán al usuario si la escritura se realiza correctamente cuando la memoria caché del cliente alcance el umbral (el valor predeterminado es 2 M); Los datos se enviarán al RegionServer en lotes. Cabe señalar que, en algunos casos, los datos almacenados en caché pueden perderse cuando el cliente no funciona correctamente.

Sugerencia de optimización: si el negocio es aceptable, habilite el envío por lotes asincrónico

Uso: setAutoFlush(false)

Principio de optimización: si la región de la tabla en el clúster actual El número es menor que el número de RegionServers, es decir, Num (Región de la tabla) lt.Num (RegionServer). Puede considerar reducir las regiones tanto como sea posible y asignarlas a diferentes RegionServers para mejorar la concurrencia de solicitudes del sistema. Si Num(Región de la tabla) gt; Num(RegionServer), si aumenta el número de regiones, el efecto no será obvio.

Sugerencia de optimización: en el caso de Num(Región de la tabla) lt; Num(RegionServer), elimine algunas regiones con alta carga de solicitudes y migre a otros RegionServers.

Principio de optimización; : Otra cuestión que debe considerarse es si las solicitudes de escritura están equilibradas. Si no lo están, provocará una reducción de la concurrencia del sistema por un lado y una reducción de la concurrencia del sistema por el otro. Por un lado, dará lugar a una baja concurrencia del sistema. Por otro lado, también puede provocar una gran carga en algunos nodos, lo que afectará a otras empresas. Los sistemas distribuidos temen especialmente una carga elevada en un nodo. Una carga elevada en un nodo puede ralentizar todo el clúster. Esto se debe a que muchas empresas utilizan Mutli para enviar solicitudes de lectura y escritura en lotes. desde el nodo, provocará que se agote el tiempo de espera de toda la solicitud por lotes. Por lo tanto, no le teme al tiempo de inactividad del nodo, ¡sino a la muerte del nodo!

Sugerencia de optimización: verifique el diseño de RowKey y la estrategia de partición previa para garantizar el equilibrio de las solicitudes de escritura.

El tamaño de KeyValue tiene un gran impacto en el rendimiento de escritura. Una vez que el rendimiento de escritura es relativamente bajo, debe considerar si los datos de KeyValue escritos son demasiado grandes. La tabla de rendimiento de escritura del tamaño de KeyValue es la siguiente:

La abscisa es el tamaño de una fila de datos (cada fila de datos tiene 10 columnas), la ordenada izquierda es el rendimiento de escritura y la coordenada derecha es el rendimiento de escritura. Rendimiento, la coordenada correcta es la latencia de escritura promedio (milisegundos). Se puede ver que a medida que aumenta el tamaño de una sola fila de datos, el rendimiento de escritura cae drásticamente, mientras que la latencia de escritura aumenta considerablemente después de 100K.

Hablando de eso, es necesario compartir con ustedes dos problemas graves causados ​​​​por KeyValue de las grandes empresas en el entorno de la línea de producción. Uno es que el rendimiento de otras empresas cae drásticamente debido a la escritura de grandes empresas. el otro es que RegionServer no funciona debido al escaneo de grandes empresas de campo.

Caso 1: la escritura de campos grandes hace que el rendimiento de otras empresas disminuya drásticamente.

Algunos comentarios comerciales escritos por el clúster se ralentizaron repentinamente y los datos comenzaron a acumularse. Al observar el monitoreo de QPS de lectura y escritura de datos en el nivel de la tabla del clúster, descubrimos que el primer punto clave del problema es que después de que el negocio A comenzó a escribir, el QPS de otras partes de todo el clúster casi cayó por un precipicio.

Por lo tanto, continuamos viendo otra información de monitoreo, primero confirmando que los recursos del sistema (principalmente IO) no han alcanzado un cuello de botella y, en segundo lugar, confirmando el saldo de escrituras hasta que veamos la siguiente figura, y luego rastreando la segundo punto clave Impacto de otros negocios escribe: Los controladores de RegionServer (configuración 150) estaban brutalmente agotados:

Compare los dos gráficos anteriores. La pregunta es, ¿por qué sucede esto? En circunstancias normales, el controlador será liberado inmediatamente después de procesar la solicitud del cliente, y la única explicación es que la demora de estas solicitudes es demasiado grande.

Supongamos que vamos a una hamburguesería y hacemos cola para comprar hamburguesas. Hay 150 ventanillas para servir. En circunstancias normales, todos terminarán su comida rápidamente, por lo que 150 ventanillas pueden requerir solo 50 servicios.

Supongamos que de repente viene un grupo de hombres grandes y quiere personalizar hamburguesas extra grandes. Entonces, todas las ventanas están funcionando y el servicio es lento porque las hamburguesas grandes no están bien cocinadas, lo que inevitablemente provocará que otros usuarios hagan cola. esperar mucho tiempo hasta que se acabe el tiempo.

Pero mirando hacia atrás, pensé que se trataba de escribir una solicitud. ¡Cómo pudo haber un retraso tan grande en la solicitud! Después de comunicarse con la parte comercial y confirmar, esta tabla almacena principalmente información del documento del corpus y el volumen de datos promedio es de aproximadamente 100 K. ¿Ha adivinado el resultado? Sí, es porque el KeyValue de la empresa es demasiado grande. demasiado grande, se escribirá el archivo HLog. Con frecuencia se activarán cambios, descargas y compactaciones frecuentes, y el rendimiento de escritura disminuirá drásticamente.

Actualmente, no existe una solución directa al problema del bajo rendimiento de escritura para KeyValues ​​tan grandes, pero la comunidad es consciente de este problema y la próxima versión principal, HBase 2.0.0, se lanzará en Lanzamiento en los próximos días, optimización en profundidad para este problema, consulte HBase MOB para obtener más detalles y optimización para que los usuarios usen HBase para almacenar documentos, imágenes y otros datos binarios. Como se mencionó en HBase MOB, la próxima versión principal de HBase (HBase 2.0.0) se optimizará profundamente para abordar este problema.

Caso 2: el escaneo de campos grandes provocó una falla en RegionServer

Sitio del caso: durante un período de tiempo, el RegionServer de un clúster 0.98 fallaba con frecuencia Después de verificar el registro, se encontró. que se debió a "java.lang.OutOfMemoryError": el tamaño de la matriz solicitada excede el límite de VM", como se muestra en la siguiente figura:

Análisis de la causa: al ver el código fuente y los documentos relacionados, se confirma que la excepción ocurrió cuando los datos del resultado del escaneo se devolvieron al cliente debido a la cantidad excesiva de datos. El tamaño de la matriz solicitada excede el máximo especificado por JVM (Interge.Max_Value-2). Las dos razones más comunes para esta excepción son:

Algunos zapatos para niños tienen esta pregunta, es decir, si el tamaño de los resultados devueltos ha sido limitado, ¿es imposible limitar las columnas cuando las columnas de la tabla son ¿Demasiado ancho? Lo que debemos tener en cuenta aquí es que si el número de columnas no está limitado, los datos siempre se devolverán en forma de filas, incluso si el tamaño de la fila es mayor que el límite establecido en el tamaño del resultado devuelto. Se devolverá una fila completa de datos. En este caso, si la fila de datos excede el umbral de tamaño de la matriz, también se activará una excepción OOM.

Solución: Actualmente hay dos formas de resolver esta excepción. Una es actualizar el clúster a 1.0, para que el problema se resuelva. La segunda es requerir que el cliente limite el tamaño de los resultados devueltos por el acceso (scan.setMaxResultSize(2 1024 1024)) y limite el número de columnas (scan.setBatch(100) Por supuesto, versión 0.98.13). También puede limitar el lado del servidor. Para limitar el tamaño de los resultados devueltos, establezca el parámetro hbase.server.scanner.max.result.size(2 1024 1024)).

tamaño

Los puntos anteriores se introducen principalmente para optimizar el rendimiento de escritura. Además, en algunos casos, pueden ocurrir excepciones de escritura. Una vez que esto ocurre, se deben considerar las dos situaciones siguientes (las excepciones causadas por GC). no se introducen) ):

Solución del problema: cuando se utiliza el vaciado del nivel de RegionServer para el análisis, HBase establece que una vez que el tamaño de memoria total ocupado por todos los Memstores en todo el RegionServer sea mayor que el límite superior en el archivo de configuración, el sistema ejecutará el vaciado a nivel de RegionServer y el algoritmo de vaciado primero ordenará según el tamaño de la región y luego vaciará secuencialmente hasta que el tamaño total de Memstore alcance el límite inferior. Este tipo de actualización generalmente se bloquea durante mucho tiempo y encontrará "Memstore está por encima del límite máximo y bloquea 7452 ms", lo que significa que esta vez Memstore está por encima del límite máximo y bloqueado durante 7452 ms.

Punto de control del problema:

Solución del problema: para clústeres con una velocidad de escritura de datos muy rápida, debe prestar especial atención a un parámetro: hbase.hstore.blockingStoreFiles, que indica que si el hstore actual La cantidad de archivos es mayor que este valor, el sistema forzará una operación de compresión para fusionar los archivos y el proceso de fusión se bloqueará. Este parámetro indica que si la cantidad de archivos en hstore es mayor que este valor, el sistema forzará una operación de compresión para fusionar los archivos y el proceso de fusión bloqueará la escritura de todo el hstore. Por lo general, esto sucede cuando los datos se escriben muy rápido y puede encontrar "Esperé 3722 ms en una compactación para limpiar 'demasiados archivos almacenados'" en el registro

Punto de verificación del problema:

Lo anterior detalla los problemas que pueden surgir al escribir datos en HBase desde los aspectos de optimización del rendimiento de escritura y diagnóstico de excepciones de escritura. El autor cree que la versión 0.98 es la mejor solución para la escritura. Sin embargo, es posible que algunas empresas todavía consideren que no es lo suficientemente rápido. Después de todo, "más rápido" es la fuerza impulsora detrás de todos los sistemas de almacenamiento. Entonces, ¿hay margen de mejora? Por supuesto, presentemos brevemente las dos mejoras principales en la optimización del rendimiento de escritura en versiones posteriores de HBase:

Esta característica significa que WAL se puede colocar por separado en el SSD, por lo que incluso de forma predeterminada (WALSync), el rendimiento de escritura También se puede mejorar mucho. Tenga en cuenta que esta función está integrada en HDFS 2.6.0 y no es compatible con versiones anteriores de HDFS. Puede consultar la jira oficial: https://issues.apache.org/jira/browse/HBASE-12848

Esta característica también es una modificación de WAL. El WAL actual está diseñado para todas las regiones. en un RegionServer * *** todas comparten un WAL. Puede imaginar que el diseño actual de WAL es que todas las regiones en un RegionServer *** comparten un WAL. En respuesta a este problema, un socio de la comunidad (maestro de Alibaba) propuso el mecanismo de WAL múltiples. El administrador puede configurar un WAL compartido para todas las tablas en cada espacio de nombres. De esta manera, el rendimiento de escritura se puede mejorar entre un 20% y un 40%. . Para obtener más información, consulte la jira oficial: https://issues.apache.org/jira/browse/HBASE-14457