Optimización del rendimiento de escritura de HBase
La escritura de datos de HBase generalmente encuentra dos problemas: uno es el bajo rendimiento de escritura y el otro es la imposibilidad de escribir datos en absoluto. Los puntos de entrada para estos dos tipos de problemas también son diferentes, como se muestra en la siguiente figura:
Principio de optimización: el proceso de escritura de datos puede entenderse como un muro de escritura secuencial y un caché de escritura. Normalmente, la latencia de la caché de escritura es muy baja, por lo que la única forma de mejorar el rendimiento de la escritura es comenzar con WAL. Por un lado, el mecanismo WAL garantiza que los datos se puedan recuperar incluso si se pierde el caché de escritura y, por otro lado, es para la replicación asincrónica entre clústeres. El mecanismo WAL predeterminado está activado y WAL se escribe utilizando el mecanismo de sincronización. Primero, considere si el servicio requiere escribir WAL. En términos generales, la mayoría de los servicios habilitarán el mecanismo WAL (predeterminado), pero para algunos servicios, es posible que no estén particularmente preocupados por cierta pérdida de datos en circunstancias anormales, pero sí más preocupados por el rendimiento de escritura de datos. Por ejemplo, para algunos servicios de recomendación, incluso si se pierden algunos datos de comportamiento del usuario, es posible que no tenga un gran impacto en los resultados de la recomendación, pero requiere un alto rendimiento de escritura y no puede causar congestión en la cola de datos. En este escenario, podemos considerar desactivar la escritura WAL y el rendimiento de escritura se puede aumentar de 2 a 3 veces. La siguiente mejor opción es que algunos servicios no pueden aceptar no escribir WAL, pero pueden aceptar la escritura asincrónica de WAL. Esto también se puede considerar para la optimización, lo que generalmente brinda una mejora de rendimiento de 1 a 2 veces.
Sugerencia de optimización: elija entre el mecanismo WAL y el rendimiento de escritura según consideraciones comerciales.
Otras notas: para las empresas que utilizan operaciones de incremento, WAL se puede configurar para cerrar o configurar para escritura asincrónica; el método es similar a Put. Creo que la mayoría de las operaciones incrementales pueden no ser tan sensibles a WAL~
Principio de optimización: HBase proporciona interfaces API para lanzamiento único y lanzamiento por lotes, respectivamente. El uso de la interfaz de transferencia por lotes puede reducir la cantidad de conexiones RPC entre el cliente y RegionServer y mejorar el rendimiento de escritura. Además, debe tenerse en cuenta que todas las solicitudes de transferencia por lotes se devolverán correctamente; de lo contrario, se generará una excepción.
Sugerencia de optimización: utilice la transferencia por lotes para solicitudes de escritura.
Principio de optimización: si la empresa puede aceptar la pérdida de una pequeña cantidad de datos en circunstancias anormales, las solicitudes también se pueden enviar mediante el envío por lotes asíncrono. El envío se realiza en dos etapas: después de que el usuario envía la solicitud de escritura, los datos se escribirán en la memoria caché del cliente y se devolverá la escritura exitosa del usuario cuando la memoria caché del cliente alcance el umbral (predeterminado 2M), se enviará a; el RegionServer en lotes. Cabe señalar que, en algunos casos, los datos almacenados en caché pueden perderse si se produce una excepción en el lado del cliente.
Sugerencia de optimización: cuando el negocio sea aceptable, inicie el envío por lotes asíncrono.
Uso: setAutoFlush(false)
Principio de optimización: si el número de regiones de la tabla en el clúster actual es menor que el número de RegionServers, es decir, Num (región de tabla): Num (servidor de región), entonces el efecto de aumentar el número de regiones no es obvio.
Sugerencia de optimización: en el escenario de Num (Región de la tabla) Principio de optimización; : Otra cuestión a considerar es si las solicitudes de escritura están equilibradas. De lo contrario, por un lado, se producirá una baja concurrencia del sistema y, por otro lado, puede provocar una carga elevada en algunos nodos, lo que afectará a otros servicios. Los sistemas distribuidos temen especialmente la carga elevada en un nodo, lo que puede ralentizar todo el clúster. Esto se debe a que muchas empresas utilizan Mutli para enviar solicitudes de lectura y escritura en lotes. Una vez que algunas de las solicitudes llegan al nodo, no recibirán una respuesta oportuna, lo que provocará que se agote el tiempo de espera de todo el lote de solicitudes. Así que no tenemos miedo de que el nodo se caiga, ¡sino que tenemos miedo de que el nodo muera! Sugerencias de optimización: verifique el diseño de la clave de fila y la estrategia de partición previa para garantizar solicitudes de escritura equilibradas. El tamaño de KeyValue tiene un gran impacto en el rendimiento de escritura. Una vez que el rendimiento de escritura es deficiente, debe considerar si se debe a que se han escrito demasiados datos KeyValue. El impacto del tamaño del valor clave en el rendimiento de escritura es el siguiente: En la figura, la abscisa es el tamaño de una fila de datos escritos (cada fila de datos tiene 10 columnas) y la ordenada en la la izquierda es la cantidad de rendimiento de escritura, la coordenada de la derecha es la latencia de escritura promedio (ms). Se puede ver que a medida que aumenta la cantidad de datos en una sola fila, el rendimiento de escritura disminuye drásticamente y la latencia de escritura aumenta considerablemente después de 100 K K. Dicho esto, es necesario compartir con ustedes dos problemas graves causados por el gran KeyValue del negocio en el entorno de la línea de producción. Una es que la escritura de grandes servicios de campo hace que el rendimiento de otros servicios disminuya drásticamente, y la otra es que el escaneo de grandes servicios de campo provoca que RegionServer falle. Caso 1: La escritura de campos grandes provoca que el rendimiento de otros servicios caiga drásticamente. Algunos servicios informan que las escrituras en el clúster se ralentizan repentinamente y los datos comienzan a acumularse. Al observar el monitoreo QPS de la lectura y escritura de datos a nivel de tabla del clúster, descubrimos el primer punto clave del problema: después de que el negocio A comenzó a escribir, la escritura QPS de otros servicios en todo el clúster casi se desplomó, e inicialmente sospechamos que el el culpable fue la empresa A La siguiente imagen es lo que la "Empresa A" escribió sobre QPS en ese momento (más tarde se descubrió que los idiotas se olvidaron de interceptar la trágica imagen de QPS cayendo por el precipicio en otras tablas) Pero la primera impresión es que el QPS no es alto, ¿por qué debería afectar a otros? Así que continué revisando otra información de monitoreo. Primero, confirmé que los recursos del sistema (principalmente IO) no tenían cuellos de botella. En segundo lugar, confirmé el saldo de mi escritura. Hasta que vi la imagen a continuación, rastreé el segundo punto clave que afectó a otros escritos comerciales: los controladores de RegionServer (configuración 150) estaban brutalmente agotados: Comparando las dos imágenes anteriores, no es sorprendentemente consistente. Básicamente se puede confirmar que el controlador de este RegionServer está agotado debido a la escritura de este servicio. Entonces otros servicios no pueden obtener el controlador, por lo que, naturalmente, no se pueden escribir. Ese es el problema. ¿Por qué? En circunstancias normales, el administrador será liberado inmediatamente después de procesar la solicitud del cliente. La única explicación es que la latencia de estas solicitudes es demasiado grande. Imagínate que vamos a una hamburguesería y hacemos cola para comprar hamburguesas, y hay 150 ventanillas para atender. Normalmente, todo el mundo compra uno rápidamente, por lo que 150 ventanas pueden requerir sólo 50 servicios. Supongamos que de repente aparece un grupo de tipos grandes y quiere personalizar hamburguesas extragrandes. Bueno, todas las ventanas funcionan y el servicio es muy lento ya que las hamburguesas grandes no son fáciles de hacer, lo que inevitablemente provocará que otros usuarios hagan cola durante mucho tiempo hasta que se agote el tiempo. Pero cuando pienso en retrospectiva, esta fue una solicitud por escrito, ¡cómo pudo haber una demora tan grande en la solicitud! Después de comunicarse con el lado comercial, se confirmó que esta tabla almacena principalmente información de documentos del corpus, con un tamaño promedio de aproximadamente 100K. ¿Adivinaste el resultado? Sí, porque el valor clave de este negocio es demasiado grande. Un KeyValue demasiado grande provocará cambios frecuentes en la escritura de archivos HLog, activaciones frecuentes de descarga y COMPACT, y una fuerte disminución en el rendimiento de escritura. Actualmente, no existe una solución directa al problema del bajo rendimiento de escritura para un KeyValue tan grande. Afortunadamente, la comunidad se ha dado cuenta de este problema y la próxima versión principal de HBase 2.0.0 que se lanzará optimizará aún más este problema. Consulte HBase MOB para obtener más detalles. Después de la optimización, los usuarios obtendrán una excelente experiencia de rendimiento al utilizar HBase para almacenar datos binarios como documentos e imágenes. Caso 2: El escaneo de campos grandes provocó que RegionServer fallara. Caso de caso: una vez, el RegionServer de un clúster 0.98 fallaba con frecuencia. El motivo para verificar el registro fue "Error de memoria insuficiente de Java . lang: el tamaño de la matriz solicitada excede el límite de VM", como se muestra en la imagen. siguiente figura: Análisis de causa: al ver el código fuente y los documentos relacionados, se confirmó que se produjo una excepción cuando los datos del resultado del escaneo se enviaron al cliente y el tamaño de la matriz aplicada superó el valor máximo. (inter.max_value-2) especificado por la JVM. Las dos razones más comunes para esta excepción son: Algunos niños quieren hacer preguntas y dicen que si el tamaño de los resultados devueltos ha sido limitado, entonces, si las columnas son demasiado anchas, el número de columnas puede aumentar. no ser limitado? Lo que hay que aclarar aquí es que si los datos de la columna no están limitados, los datos siempre se devolverán fila por fila, incluso si el tamaño de una fila de datos es mayor que el tamaño límite establecido del resultado devuelto, una fila completa de datos serán devueltos. 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, existen dos soluciones para esta excepción. Una es actualizar el clúster a 1.0 y todos los problemas se resolverán. La segunda es exigir al cliente que limite el tamaño de los resultados devueltos (scan.setmaxresultsize(2 1024 1024)) y limite el número de columnas (scan.set lote(100)). Por supuesto, también puedes regresar después de la versión 0.98.13. Los puntos anteriores se centran principalmente en la optimización del rendimiento de escritura. Además, pueden producirse excepciones de escritura en determinadas circunstancias. Una vez que esto sucede, se deben considerar las siguientes dos situaciones (no introducidas por razones de GC): Análisis del problema: use el nivel de vaciado de RegionServer para el análisis, HBase establece el tamaño de memoria ocupado por todos los Memstores en todo RegionServer Si la suma es mayor que el límite superior en el archivo de configuración, el sistema realizará un vaciado a nivel de RegionServer. El algoritmo de vaciado primero ordenará según el tamaño de la Región y luego vaciará en este orden hasta alcanzar el tamaño total de Memstore. es tan bajo como el límite inferior. Este tipo de actualización generalmente se bloquea durante mucho tiempo y el mensaje "La memoria está por encima del límite máximo, el tiempo de bloqueo es 7452 milisegundos" aparecerá en el registro, lo que indica que este tipo de actualización se bloqueará durante aproximadamente 7 segundos. /p> Punto de verificación del problema: Análisis del problema: para clústeres con velocidad de escritura de datos rápida, debemos prestar especial atención a un parámetro: h base hstore. La cantidad de archivos en el hstore actual 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 h store. Normalmente, esto sucede cuando los datos se escriben rápidamente y se pueden encontrar en los registros como "Esperé 3722 ms para borrar 'demasiados archivos de almacenamiento' mientras se comparaba". Punto de control del problema: Los posibles problemas en la escritura de datos en HBase se explican en detalle desde dos aspectos: optimización del rendimiento de escritura y diagnóstico de excepciones de escritura. Creo que es la mejor solución escrita basada en la versión 0.98. Sin embargo, es posible que algunas empresas todavía sientan que no es lo suficientemente rápido. Después de todo, "más rápido" es el motor de la supervivencia de todos los sistemas de almacenamiento. ¿Hay margen de mejora? Por supuesto, aquí hay un resumen rápido de las dos mejoras principales de las optimizaciones del rendimiento de escritura posteriores a HBase: Esta característica significa que WAL se puede colocar por separado en el SSD, de modo que incluso de forma predeterminada (WALSync), Write El rendimiento también mejorará enormemente. Cabe señalar que esta función se basa en HDFS 2.6.0 y no es compatible con versiones anteriores de HDFS. Para obtener más información, consulte https://issues.apache.org/jira/browse/HBASE-12848.Official Jira Esta función también es una modificación de WAL. Actualmente, WAL está diseñado para ser compartido por todas las regiones en RegionServer. Como puede imaginar, cuando el rendimiento de escritura es alto, se producirá contención de recursos, lo que reducirá el rendimiento general. Para resolver este problema, el socio de la comunidad (Alibaba God) propuso el mecanismo de Múltiples WAL, y el administrador puede establecer un * * * Wals para todas las tablas bajo cada espacio de nombres. De esta forma, la puntuación de escritura se puede mejorar entre 20 y 40 puntos. Para obtener más información, consulte https://issues.apache.org/jira/browse/HBASE-14457.Official Jira