¿Por qué Taobao usa HBase y cómo optimizarlo?

Hbase es el principal proyecto de código abierto de Apache separado de hadoop. Debido a que utiliza Java para implementar la mayoría de las funciones del sistema bigtable de Google, es muy popular hoy en día cuando los datos aumentan rápidamente. Para Taobao, a medida que la escala del mercado se expande, los productos y las tecnologías se desarrollan y la cantidad de datos comerciales aumenta cada vez más, la inserción y lectura eficiente de datos masivos se vuelve cada vez más importante. Debido a que Taobao posee quizás el clúster de Hadoop más grande (Tianti) en China y tiene un profundo conocimiento de los productos Hadoop, es natural esperar utilizar hbase para proporcionar servicios masivos de lectura y escritura de datos. Este artículo resumirá el uso y optimización de hbase en las aplicaciones en línea de Taobao durante el año pasado.

2 razones

¿Por qué utilizar hbase?

Antes de 2011, todo el almacenamiento persistente back-end de Taobao se realizaba básicamente en mysql (sin excluir una pequeña cantidad de Oracle/BDB/Tail/MongDB, etc.). Mysql es de código abierto y tiene un buen ecosistema. , Con múltiples soluciones, como subbases de datos y subtablas, ha satisfecho durante mucho tiempo las necesidades de una gran cantidad de comerciantes en Taobao.

Sin embargo, debido al desarrollo diversificado de los negocios, los requisitos de cada vez más sistemas comerciales han comenzado a cambiar. En términos generales, existen los siguientes tipos de cambios:

a) La cantidad de datos está aumentando. De hecho, el volumen de datos de casi cualquier negocio en línea relacionado con los usuarios en Taobao es de miles de millones, y las llamadas diarias al sistema oscilan entre mil millones y mil millones, y los datos históricos no se pueden eliminar fácilmente. Esto requiere un sistema de archivos distribuido a gran escala que pueda proporcionar servicios en línea para datos a nivel de TB o incluso a nivel de PB.

b) La cantidad de datos aumenta rápidamente y es posible que no se pueda predecir con precisión. La mayoría de los sistemas de aplicaciones tienen una rápida tendencia ascendente dentro de un período de tiempo después de su puesta en línea. Por lo tanto, desde una perspectiva de costos, existe una fuerte demanda de escalabilidad horizontal del sistema sin restricciones de un solo punto.

c) Sólo se requieren lecturas simples de kv, sin requisitos de conexión complejos. Sin embargo, existen requisitos muy altos para la concurrencia, el rendimiento y el retraso de respuesta del sistema, y ​​se espera que el sistema pueda mantener una gran coherencia.

d) Por lo general, el sistema escribe con frecuencia, especialmente cuando una gran cantidad de sistemas dependen del análisis de registros en tiempo real.

e) Quiere leer datos por lotes rápidamente.

f) El esquema es flexible y las propiedades de las columnas se pueden actualizar o agregar columnas con frecuencia.

g) Espero que sea fácil de usar y tenga una buena interfaz Java con una semántica clara.

En conjunto, creemos que hbase es una opción más adecuada. En primer lugar, sus datos son naturalmente redundantes por HDFS. Tianti ha estado funcionando de manera estable durante tres años y los datos son 100% confiables. Ha demostrado la seguridad del clúster HDFS y su capacidad para servir datos masivos. En segundo lugar, los servicios de lectura y escritura de datos propios de hbase no se limitan a un solo punto. La capacidad del servicio puede crecer linealmente con el crecimiento del servidor, alcanzando una escala de docenas o cientos. El diseño del modo de árbol LSM hace que el rendimiento de escritura de hbase sea muy bueno. Por lo general, una sola escritura se puede completar en 1 a 3 ms y el rendimiento no disminuirá a medida que aumente la cantidad de datos.

Las regiones (equivalentes a subtablas de la base de datos) se pueden segmentar y mover dinámicamente a nivel de ms, asegurando el equilibrio de carga. Dado que el modelo de datos en hbase se almacena en el orden de la clave de fila, todo el bloque continuo de datos se leerá como un caché a la vez. Un buen diseño de clave de fila puede hacer que la lectura por lotes sea muy fácil, incluso solo se requiere 1 io. docenas o cientos de datos que los usuarios desean. Finalmente, la mayoría de los ingenieros de Taobao son estudiantes con experiencia en Java, por lo que la API de hbase es muy fácil de usar para ellos y el costo de capacitación es relativamente bajo.

Por supuesto, también hay que señalar que no existe una solución mágica en el contexto de big data, y el propio hbase también tiene escenarios inapropiados. Por ejemplo, el índice solo admite el índice principal (o se considera el índice compuesto principal), o el servicio es un punto único y algunos de los datos de los que es responsable no serán atendidos por la máquina principal durante el proceso de recuperación. después de que una sola máquina falla.

Esto requiere que tenga un conocimiento suficiente de su sistema de aplicación al realizar la selección.

3 Estado de la solicitud

Comenzamos a estudiar cómo se puede utilizar hbase para servicios en línea en marzo de 2011. Aunque Yitao Search ya contaba con decenas de servicios fuera de línea antes. Esto se debe a que la primera versión de hbase apuntaba a servicios fuera de línea en datos masivos. El lanzamiento de la versión 0.20.0 en septiembre de 2009 fue un hito y las aplicaciones en línea se convirtieron oficialmente en el objetivo de hbase. Entonces hbase introdujo zookeeper como la gestión de backupmaster y regionserver. La versión 2011 1.90.0 es otro hito. Básicamente, los principales sitios web que vemos hoy, como hbase utilizado para la producción en facebook/ebay/yahoo, se basan en esta versión (la estructura de la versión 0.89 utilizada por FB es similar a la versión 0.90.x). Se han agregado muchos atributos como Bloomfilter y el rendimiento ha mejorado enormemente. En base a esto, Taobao también eligió la rama 0.90.x como base para la versión en línea.

La primera solicitud en línea es la fiesta de graduación en el cubo de datos. Prom se construyó originalmente en redis. Debido al continuo aumento del volumen de datos y los cambios en la demanda, utilizamos hbase para transformar su capa de almacenamiento. Para ser precisos, prom es más adecuado para la versión 0.92 de hbase, porque no solo requiere lectura y escritura en línea de alta velocidad, sino que también requiere aplicaciones complejas como contar/agrupar. Pero como la versión 0.92 aún no estaba madura en ese momento, implementamos el coprocesador nosotros mismos. La importación de datos de Prom proviene de Tianlai, por lo que dedicamos media hora todas las noches a escribir los datos de Tianli en hdfs donde se encuentra hbase y luego realizar un reenvío del cliente en la capa web. Después de un mes de comparación de datos, se confirmó que la relación de velocidad de redis no ha disminuido significativamente, los datos son precisos y se puede iniciar con éxito.

La segunda aplicación en línea es TimeTunnel, que es una plataforma de transmisión de datos en tiempo real eficiente, confiable y escalable. Se usa ampliamente en la recopilación de registros en tiempo real, el monitoreo de datos en tiempo real y en tiempo real. comentarios sobre efectos publicitarios y sincronización de bases de datos en tiempo real y otros campos. En comparación con el baile de graduación, su característica es la adición de escritura en línea. El crecimiento dinámico de datos plantea grandes desafíos para muchas funciones, como la compresión/equilibrio/división/recuperación en hbase. TT escribe alrededor de 20 TB cada día y lee aproximadamente 1,5 veces esa cantidad. Para ello, hemos preparado 20 clústeres de servidores regionales. Por supuesto, el HDFS subyacente es público y el número es mayor (se menciona a continuación). Todos los días, TT creará diferentes tablas para diferentes servicios en hbase y luego escribirá datos en las tablas. Incluso si establecemos el tamaño máximo de zona en 1 GB, los servicios más grandes alcanzarán la escala de miles de zonas, lo que se puede decir que son varias divisiones por minuto. Durante el lanzamiento de TT, solucionamos muchos errores en hbase relacionados con la división y varias confirmaciones llegaron a la comunidad de hbase. Al mismo tiempo, también incorporamos algunos de los últimos parches de la comunidad en nuestra versión. Se debe decir que los errores relacionados con la división son uno de los mayores riesgos de pérdida de datos de hbase. Esto es algo que todo desarrollador que quiera utilizar hbase debe tener en cuenta. Dado que hbase utiliza el modelo de árbol LSM, casi no existe posibilidad de pérdida de datos en términos de principios arquitectónicos. Sin embargo, en el uso real, existe el riesgo de pérdida de datos si no se tiene cuidado. Las razones se enfatizarán por separado más adelante. Durante el proceso previo al lanzamiento de TT, se perdieron datos debido a daños en las metatablas y errores en la división, por lo que también escribimos una herramienta de recuperación de metatables separada para garantizar que no ocurran problemas similares en el futuro (hbase-0.90.5 y versiones posteriores). Se han agregado herramientas similares). Además, debido a la inestabilidad de la sala de ordenadores donde almacenamos TT, se han producido muchos accidentes de apagado e incluso animaciones suspendidas. Por lo tanto, también hemos comenzado a modificar algunos parches para mejorar el tiempo de recuperación del tiempo de inactividad y fortalecer la intensidad del monitoreo.

Los proyectos de CTU y de centros miembros son dos proyectos con altos requisitos en línea. En estos dos proyectos, estudiamos específicamente la lenta respuesta de hbase.

La lenta respuesta de hbase generalmente se divide en cuatro razones: razones de red, problemas de gc, tasa de aciertos y deserialización del cliente. Ahora hemos creado algunas soluciones para ellos (que se presentarán más adelante) para controlar mejor el problema de la respuesta lenta.

Al igual que Facebook, también utilizamos hbase como capa de almacenamiento para proyectos informáticos en tiempo real. En la actualidad, se han lanzado algunos proyectos internos en tiempo real, como el sistema de clics en páginas en tiempo real, recomendación de transacciones en tiempo real de Galaxy, sala de transmisión en vivo, etc. Los usuarios son pequeños operadores repartidos por toda la empresa. A diferencia de Puma de Facebook, Taobao utiliza muchos métodos para realizar cálculos en tiempo real. Por ejemplo, Galaxy utiliza un modelo de actor similar a AFA para procesar datos de transacciones y, al mismo tiempo, calcula la clasificación (TopN) a través de tablas de dimensiones, como tablas de productos asociados. El sistema de clics en páginas en tiempo real se desarrolla en base a la apertura de Twitter. fuente Storm y los datos de registro en tiempo real se obtienen en segundo plano a través de TT. El proceso de cálculo guarda los resultados intermedios y las tablas de dimensiones dinámicas en hbase. Por ejemplo, diseñamos la clave de fila como ID de usuario de URL, leemos datos en tiempo real y realizamos cálculos de UV en tiempo real en varias dimensiones.

Por último, me gustaría mencionar específicamente los elementos históricos de pedidos de transacciones. Este proyecto es en realidad un proyecto de transformación destinado a migrar de la solución solr bdb anterior a hbase. Debido a que está relacionado con la página de compra, los usuarios la usan con mucha frecuencia, su importancia está cerca de la aplicación principal y hay tolerancia cero con la pérdida de datos y la interrupción del servicio. Optimiza la compresión para evitar que se produzcan compresiones con grandes cantidades de datos durante el tiempo de servicio. Se agregó un filtro personalizado para implementar la consulta de paginación y la aplicación se diseñó inteligentemente en clave de fila para evitar la transmisión de datos redundantes y convertir más de 90 lecturas en lecturas secuenciales. Actualmente, el clúster almacena más de 10 mil millones de datos de pedidos y cientos de miles de millones de datos de indicadores, con una tasa de falla en línea de 0.

Con el desarrollo del negocio, nuestro clúster hbase personalizado se ha aplicado a más de 20 aplicaciones en línea y cientos de servidores. Incluyendo recomendaciones de productos en tiempo real en la página de inicio de Taobao, estadísticas cuánticas en tiempo real y otras aplicaciones ampliamente utilizadas por los vendedores, existe una tendencia a seguir aumentando y acercándose a las aplicaciones principales.

4 Implementación, operación y monitoreo

Facebook ha revelado previamente su arquitectura hbase, que se puede decir que es muy buena. Por ejemplo, dividieron el clúster hbase del servicio de mensajes en varios clústeres según los usuarios. Cada clúster tiene 65.438.000 servidores, un nodo de nombre y está dividido en cinco bastidores. Se puede decir que esta es una arquitectura excelente para servicios con grandes cantidades de datos. Para Taobao, debido a que la cantidad de datos es mucho menor y la aplicación no es tan central, adoptamos la arquitectura de clústeres públicos HDFS y ZooKeeper. Intente no exceder las 100 unidades por clúster HDFS (esto es para limitar el único punto de problema para el nodo de nombre tanto como sea posible). Configure varios clústeres de hbase arriba, cada clúster tiene un maestro y un maestro de respaldo. La ventaja del HDFS público es que puede minimizar el impacto de la compactación y distribuir el costo de los discos duros por igual, porque siempre hay clústeres con altos requisitos de espacio en disco y siempre hay clústeres con bajos requisitos de espacio en disco, y es más costoso. eficaz mezclarlos juntos. Los clústeres de Zookeeper son muy comunes y cada clúster de hbase pertenece a un nodo raíz diferente en ZooKeeper. La independencia del clúster hbase está garantizada por el mecanismo de permisos de zk. La razón común para zk es simplemente la conveniencia de operación y mantenimiento.

Al ser una aplicación online, el funcionamiento y seguimiento cobran mayor importancia. Debido a que la experiencia previa es casi nula, es difícil contratar personal dedicado a la operación y mantenimiento de hbase. Nuestro equipo de desarrollo y nuestro equipo de operaciones se han tomado muy en serio este problema desde el principio y han comenzado a cultivarse desde el principio. Hablemos de nuestra experiencia en operación y monitoreo.

Una parte importante de nuestra funcionalidad hbase personalizada es una mayor supervisión. El propio Hbase puede enviar datos de monitoreo de ganglios, pero los elementos de monitoreo están lejos de ser suficientes y el método de visualización de ganglios no es lo suficientemente intuitivo ni prominente.

Por lo tanto, por un lado, agregamos creativamente muchos puntos de monitoreo en el código, como comprimir / dividir / equilibrar / actualizar la cola y el consumo de tiempo de cada etapa, el tiempo de respuesta de cada etapa de lectura y escritura, el número de lecturas y escrituras, y los tiempos de lectura y escritura del área de encendido/apagado, a nivel de tabla y a nivel de región. Todavía se envían a ganglia a través de un socket y ganglia los registrará en el archivo rrd. La característica del archivo rrd es que la precisión de los datos históricos será cada vez menor, por lo que escribimos nuestro propio programa para leer los datos correspondientes de rrd y conservarlos en otros lugares. Luego usamos js para implementar un conjunto de interfaces de monitoreo. centrándose en Varios métodos, como gráficos de tendencias y gráficos circulares, resumen y muestran los datos que nos interesan, y cualquier dato histórico se puede ver sin perder precisión. Al mismo tiempo, algunos datos muy importantes, como el número de lecturas y escrituras, tiempo de respuesta, etc. , se escribirá en la base de datos para implementar alarmas personalizadas, como alarmas de fluctuación. A través de las medidas anteriores, nos aseguramos de que siempre podamos descubrir los problemas del clúster antes que los usuarios y solucionarlos a tiempo. Utilizamos el algoritmo de clasificación eficiente de Redis para ordenar los tiempos de lectura y escritura de cada región en tiempo real. Podemos encontrar aquellas regiones con tiempos de solicitud específicos elevados bajo una carga elevada y moverlas a servidores de regiones inactivas. En las horas punta, podemos clasificar cientos de miles de regiones en tiempo real en cientos de máquinas.

Para aislar el impacto de la aplicación, podemos verificar las conexiones de diferentes clientes a nivel de código y cortar las conexiones de algunos clientes, aislando así la falla dentro de una aplicación y no cuando ocurre la falla. Ampliar él. Las aplicaciones Mapreduce también se controlarán para que se ejecuten durante los períodos de menor actividad. Por ejemplo, desactivaremos jobtracker durante el día.

Además, para garantizar la disponibilidad del servicio a partir de los resultados, también ejecutaremos periódicamente comandos como pruebas de lectura y escritura, pruebas de creación de tablas y hbck. Hbck es una herramienta muy útil, pero también requiere mucho trabajo, así que intente reducir la cantidad de llamadas de hbck y trate de no ejecutar el servicio hbck en paralelo. Hbck anterior a 0.90.4 tendrá alguna posibilidad de cerrar hbase. Además, para garantizar la seguridad de HDFS, es necesario ejecutar fsck con regularidad para verificar el estado de HDFS, como la cantidad de copias en bloque.

Haremos un seguimiento de los registros de todos los servidores en línea todos los días, descubriremos todos los registros de errores y los enviaremos a los desarrolladores por correo electrónico para descubrir la causa y el método de reparación de cada error. hasta que el error disminuya a 0. Además, si hay un problema con cada resultado de hbck, también se enviará al desarrollador por correo electrónico para su procesamiento. Aunque no todos los errores causarán problemas, e incluso la mayoría de los errores son simplemente fenómenos normales en los sistemas distribuidos, es muy importante comprender las razones por las que causan problemas.

5 Pruebas y lanzamiento

Debido a que es un sistema desconocido, prestamos gran atención a las pruebas desde el principio. Las pruebas se dividen desde el principio en pruebas de rendimiento y pruebas funcionales. Las pruebas de rendimiento se basan principalmente en pruebas comparativas, que se dividen en muchos escenarios, como diferentes proporciones mixtas de lectura y escritura, diferentes tamaños de k/v, diferentes familias de columnas, diferentes tasas de aciertos, si se debe realizar un hash previo, etc. Cada ejecución durará varias horas para obtener resultados precisos. Entonces, escribimos un sistema automatizado para seleccionar diferentes escenarios de la web, y el fondo transferirá automáticamente los parámetros de prueba al servidor para su ejecución. Debido a que prueba un sistema distribuido, el cliente también debe estar distribuido.

Juzgamos si la prueba es precisa en función de si el mismo escenario se ejecuta varias veces y si los datos y la curva operativa se superponen en más del 99 %. Este trabajo fue muy tedioso y tomó mucho tiempo, pero luego resultó ser muy significativo. Debido a que hemos establecido una confianza del 100% en él, esto es muy importante. Por ejemplo, nuestras mejoras posteriores, incluso si solo mejoran el rendimiento en 2, se pueden capturar con precisión. Otro ejemplo es que una modificación del código provocó algunos altibajos. curva de cola compacta, que fue Lo vimos, descubrimos errores en el programa, etc.

Las pruebas funcionales son principalmente pruebas de interfaz y pruebas de excepciones. El papel general de las pruebas de interfaz no es obvio, porque las pruebas unitarias de hbase ya cubren esta parte. Sin embargo, las pruebas de excepción son muy importantes.

La mayoría de nuestras correcciones de errores se descubren durante las pruebas de excepciones, lo que nos ayuda a eliminar muchos factores inestables que pueden existir en el entorno de producción. También enviamos más de una docena de parches correspondientes a la comunidad, que recibió atención y compromiso. La dificultad y complejidad del diseño de sistemas distribuidos radica en el manejo de excepciones, que debe considerar que el sistema no es confiable en cualquier momento durante la comunicación. Para algunos problemas que son difíciles de reproducir, localizaremos aproximadamente el problema verificando el código y forzaremos una excepción a nivel de código para reproducirlo. Esto resultó útil.

Para localizar problemas de forma cómoda y rápida, hemos diseñado un conjunto de programas de recopilación y procesamiento de registros para capturar fácilmente los registros correspondientes de cada servidor y resumirlos según ciertas reglas. Esto es importante para evitar perder mucho tiempo iniciando sesión en diferentes servidores buscando pistas de errores.

Debido al desarrollo continuo de la comunidad hbase y a los nuevos errores descubiertos en línea o en el entorno de prueba, necesitamos desarrollar un patrón de lanzamiento regular. Es necesario no solo evitar la inestabilidad causada por los lanzamientos frecuentes, sino también evitar fallas de lanzamiento a largo plazo, lo que hará que la versión de producción en masa se aleje cada vez más de la versión de desarrollo o el brote de errores ocultos. Es obligatorio para nosotros lanzar una versión desde el troncal interno cada dos semanas, que debe pasar todas las pruebas, incluidas las pruebas de regresión, y ejecutarse sin parar durante 24 horas en un clúster pequeño después del lanzamiento. La última versión se publica una vez al mes y los clústeres existentes se publican en orden de importancia para garantizar que las aplicaciones importantes no se vean afectadas por posibles errores en la nueva versión. Los hechos han demostrado que desde que introdujimos este mecanismo de publicación, la inestabilidad causada por la publicación se ha reducido considerablemente y la versión en línea no puede quedarse atrás.

6 Mejora y optimización

Facebook es una empresa muy respetable. Anunciaron todas las modificaciones a hbase sin reservas y abrieron a la comunidad la versión que realmente usan internamente. Una característica importante de las aplicaciones en línea de Facebook es que desactivan la división para reducir los riesgos causados ​​por la división. A diferencia de Facebook, los datos comerciales de Taobao no son tan grandes y, debido a los ricos tipos de aplicaciones, no requerimos que los usuarios cierren la división por la fuerza, sino que intentamos modificar posibles errores en la división. Hasta ahora, aunque no se puede decir que este problema se haya resuelto por completo, muchos errores relacionados con la fragmentación y el tiempo de inactividad expuestos desde 0.90.2 se han solucionado cerca de 0 en nuestro entorno de prueba y se han enviado a la comunidad con 10 estabilidad. parches relacionados, los más importantes son los siguientes:

Mitor nos ayuda a volver a la versión 0.90. Por lo tanto, después de que la comunidad lanzó cinco versiones de corrección de errores desde 0.90.2 a 0.90.6, la versión 0.90.6 es en realidad relativamente estable. Se recomienda que los entornos de producción consideren esta versión.

Split es una transacción pesada y tiene el grave problema de que modificará la metatabla (por supuesto, también tiene este problema cuando está caído). Si ocurre una excepción durante este período, es muy probable que la metatabla, la memoria rs, la memoria principal y los archivos en HDFS sean inconsistentes, lo que provocará errores cuando el área se reasigne más adelante. Uno de los errores es que la misma región puede ser atendida por más de dos servidores regionales, y luego los datos servidos por esta región pueden escribirse aleatoriamente en varios rs y se leerán por separado durante la lectura, lo que provocará la pérdida de datos. Si desea restaurar el estado original, debe eliminar el área en una de las rs, lo que lleva a la eliminación activa de datos, lo que resulta en la pérdida de datos.

Los problemas de respuesta lenta mencionados anteriormente se pueden resumir en razones de red, problemas de gc, tasa de aciertos y deserialización del cliente. El motivo de la red generalmente se debe a la inestabilidad de la red, pero también puede ser un problema con la configuración de los parámetros TCP. Es necesario asegurarse de que el retraso del paquete se reduzca tanto como sea posible. Por ejemplo, nodelay debe establecerse en verdadero, etc. Utilizamos una serie de herramientas como tcpdump para localizar específicamente estos problemas y demostramos que los parámetros de tcp efectivamente causan conexiones lentas durante el ensamblaje de paquetes. Gc debe basarse en el tipo de aplicación. En términos generales, en aplicaciones con un volumen de lectura relativamente grande, la nueva generación no se puede configurar demasiado pequeña. La tasa de aciertos afecta en gran medida el tiempo de respuesta. Intentaremos configurar el número de versión en 1 para aumentar la capacidad de la caché.

Un buen equilibrio también ayuda a aprovechar al máximo los golpes de cada máquina. Para ello hemos diseñado una balanza de mesa.

Debido a que el servicio hbase es un punto único, es decir, si una máquina no funciona, los datos proporcionados por esta máquina no se pueden leer ni escribir antes de que se restaure. La velocidad con la que se restablece una interrupción determina la disponibilidad de nuestros servicios. Para ello se han realizado varias optimizaciones. Primero, intente acortar el tiempo de inactividad de descubrimiento de ZooKeeper a 1 minuto tanto como sea posible. En segundo lugar, el registro de recuperación del servidor principal se mejora a recuperación paralela, lo que mejora en gran medida la velocidad del registro de recuperación del servidor principal. Luego, modificamos algunas excepciones de tiempo de espera y bloqueos que pueden aparecer en openhandler y eliminamos excepciones como open...demasiado largo que pueden aparecer en el registro. Se solucionó el problema de que es posible que el hbase original no pueda reiniciarse durante varios minutos o incluso media hora cuando no funciona en 10. Además, a nivel HDFS, hemos acortado los tiempos de espera y reintento del socket para reducir el bloqueo a largo plazo causado por el tiempo de inactividad del nodo de datos.

En la actualidad, no hemos trabajado mucho para optimizar el nivel de lectura y escritura del propio hbase. La única solución es que el rendimiento de escritura se degrada gravemente a medida que crece el área. Debido al buen rendimiento del propio hbase, encontramos parámetros excelentes en varios escenarios de aplicación a través de una gran cantidad de pruebas y los aplicamos al entorno de producción, que básicamente cumple con los requisitos. Pero este es nuestro próximo trabajo importante.

7 planes futuros

Actualmente mantenemos una versión personalizada de hbase basada en la comunidad 0.90.x en Taobao. A continuación, además de seguir corrigiendo sus errores, también se mantendrá una versión basada en modificaciones 0.92.x. La razón de esto es que la compatibilidad entre 0.92.x y 0.90.x no es muy buena. 0.92.x ha modificado mucho código y un recuento aproximado excederá 30. Hay algunas características en 0.92 que valoramos mucho. .

La versión 0.92 mejora hfile a hfilev2 y presenta una revisión importante del índice y el filtro de floración para admitir un único documento hfile grande. Cuando el tamaño del archivo del HFile existente alcanza un cierto nivel, el índice ocupará mucha memoria y la velocidad de carga del archivo se reducirá considerablemente. Sin embargo, si HFile no aumenta, las regiones no se pueden expandir, lo que da como resultado una gran cantidad de regiones. Esto es algo que queremos evitar en la medida de lo posible.

La versión 0.92 mejora el protocolo de la capa de comunicación y aumenta la longitud de la capa de comunicación, lo cual es muy importante. Nos permite escribir clientes nio para que la deserialización ya no afecte el rendimiento del cliente.

La versión 0.92 agrega funciones de coprocesador para admitir una pequeña cantidad de aplicaciones que desean confiar en rs.

Hay muchas otras optimizaciones, como mejorar el algoritmo de equilibrio, mejorar el algoritmo compacto, mejorar el algoritmo de escaneo, cambiar el nivel compacto al nivel CF, hacer ddl dinámicamente, etc.

Además de la versión 0.92, la versión 0.94 y el último troncal (0.96) también tienen muchas características buenas. La 0.94 es una versión optimizada para el rendimiento. Ha realizado un gran trabajo revolucionario, como eliminar la tabla raíz, comprimir HLog, admitir múltiples clústeres esclavos en replicación, etc.

También tenemos algunas optimizaciones, como nuestro propio índice secundario y estrategia de respaldo, que se implementarán en la versión interna.

También cabe mencionar que la optimización a nivel HDFS también es muy importante. Las mejoras en hadoop-1.0.0 y cloudera-3u3 son muy útiles para hbase, como lectura localizada, mejoras en la suma de verificación, configuración de mantenimiento de actividad del nodo de datos, estrategia de alta disponibilidad del nodo de nombre, etc. Contamos con un excelente equipo de HDFS para respaldar nuestro trabajo de HDFS, como localizar y corregir algunos errores de HDFS, ayudar a brindar algunas sugerencias sobre los parámetros de HDFS y ayudar a implementar namenode HA. Las pruebas más recientes muestran que las lecturas localizadas con suma de comprobación 3u3 pueden al menos duplicar el rendimiento de lectura aleatoria.

Una de las cosas significativas que estamos haciendo es monitorear y ajustar la carga del servidor regional en tiempo real. Podemos mover dinámicamente servidores subcargados en el clúster a clústeres con mayor carga. Todo el proceso es completamente transparente. usuarios.

En general, nuestra estrategia es cooperar con la comunidad tanto como sea posible para promover el desarrollo de hbase en todo el ecosistema y la industria de Apache, de modo que pueda implementarse en más aplicaciones de manera más estable y reducir el uso. Umbrales y costes de uso.