Teoría e práctica do uso de HBase

Boas tardes Chámome Danil Lipovoy, o noso equipo de Sbertech comezou a usar HBase como almacenamento de datos operativos. No transcurso de estudalo acumulouse experiencia que quixen sistematizar e describir (agardamos que sexa útil para moitos). Todos os experimentos a continuación realizáronse coas versións HBase 1.2.0-cdh5.14.2 e 2.0.0-cdh6.0.0-beta1.

1. Arquitectura xeral
2. Escribindo datos en HBASE
3. Lectura de datos de HBASE
4. Almacenamento de datos en caché
5. Procesamento de datos por lotes MultiGet/MultiPut
6. Estratexia para dividir táboas en rexións (dividir)
7. Tolerancia a fallos, compactación e localización de datos
8. Configuración e rendemento
9. Probas de estrés
10. Descubrimentos

1. Arquitectura xeral

O mestre de copia de seguridade escoita o latexo do activo no nodo ZooKeeper e, en caso de desaparición, asume as funcións do mestre.

2. Escribe datos en HBASE

Primeiro, vexamos o caso máis sinxelo: escribir un obxecto clave-valor nunha táboa usando put(rowkey). O cliente primeiro debe descubrir onde se atopa o servidor da rexión raíz (RRS), que almacena a táboa hbase:meta. Recibe esta información de ZooKeeper. Despois accede a RRS e le a táboa hbase:meta, da que extrae información sobre que RegionServer (RS) é o responsable de almacenar os datos dunha clave de fila determinada na táboa de interese. Para uso futuro, o cliente almacena a meta táboa e, polo tanto, as chamadas posteriores van máis rápido, directamente a RS.

A continuación, RS, recibindo unha solicitude, primeiro escríbea en WriteAheadLog (WAL), que é necesaria para a recuperación en caso de accidente. Despois garda os datos en MemStore. Este é un búfer na memoria que contén un conxunto ordenado de claves para unha determinada rexión. Unha táboa pódese dividir en rexións (particións), cada unha das cales contén un conxunto disxunto de claves. Isto permítelle colocar rexións en diferentes servidores para conseguir un maior rendemento. Porén, a pesar da obviedade desta afirmación, veremos máis adiante que isto non funciona en todos os casos.

Despois de colocar unha entrada na MemStore, devólvese ao cliente unha resposta de que a entrada foi gardada con éxito. Non obstante, en realidade só se almacena nun búfer e chega ao disco só despois de que transcorra un determinado período de tempo ou cando se enche con novos datos.

Ao realizar a operación "Eliminar", os datos non se eliminan fisicamente. Simplemente márcanse como eliminados e a propia destrución prodúcese no momento de chamar á función compacta principal, que se describe con máis detalle no parágrafo 7.

Os ficheiros en formato HFile acumúlanse en HDFS e de cando en vez lánzase o proceso pequeno compacto, que simplemente fusiona ficheiros pequenos noutros máis grandes sen borrar nada. Co paso do tempo, isto convértese nun problema que só aparece ao ler os datos (volveremos sobre isto un pouco máis tarde).

Ademais do proceso de carga descrito anteriormente, hai un procedemento moito máis eficaz, que quizais sexa o lado máis forte desta base de datos: BulkLoad. Está no feito de que formamos HFiles de forma independente e poñémolos en disco, o que nos permite escalar perfectamente e acadar velocidades moi decentes. De feito, a limitación aquí non é HBase, senón as capacidades do hardware. A continuación móstranse os resultados de arranque nun clúster composto por 16 RegionServers e 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), versión HBase 1.2.0-cdh5.14.2.

Aquí podes ver que ao aumentar o número de particións (rexións) na táboa, así como os executores de Spark, conseguimos un aumento da velocidade de descarga. Ademais, a velocidade depende do volume de gravación. Os bloques grandes dan un aumento en MB/s, os bloques pequenos no número de rexistros inseridos por unidade de tempo, sendo todas as demais cousas iguais.

Tamén podes comezar a cargar en dúas táboas ao mesmo tempo e conseguir o dobre de velocidade. A continuación podes ver que escribir bloques de 10 KB en dúas táboas ao mesmo tempo ocorre a unha velocidade duns 600 MB/seg en cada unha (total 1275 MB/seg), o que coincide coa velocidade de escritura nunha táboa de 623 MB/seg (ver número 11 anterior)

Pero a segunda carreira con rexistros de 50 KB mostra que a velocidade de descarga está a crecer lixeiramente, o que indica que se aproxima aos valores límite. Ao mesmo tempo, cómpre ter en conta que practicamente non hai carga creada no propio HBASE, o único que se require del é primeiro dar os datos de hbase:meta e, despois de aliñar HFiles, restablecer os datos de BlockCache e gardar o Buffer de MemStore no disco, se non está baleiro.

3. Lectura de datos de HBASE

Se asumimos que o cliente xa ten toda a información de hbase:meta (ver punto 2), entón a solicitude vai directamente ao RS onde se almacena a clave requirida. En primeiro lugar, a busca realízase en MemCache. Independentemente de se hai datos alí ou non, a busca tamén se realiza no búfer de BlockCache e, se é necesario, en HFiles. Se se atoparon datos no ficheiro, colócanse en BlockCache e devolveranse máis rápido na seguinte solicitude. A busca en HFile é relativamente rápida grazas ao uso do filtro Bloom, é dicir. despois de ler unha pequena cantidade de datos, determina inmediatamente se este ficheiro contén a clave necesaria e, se non, pasa á seguinte.

Tras recibir datos destas tres fontes, RS xera unha resposta. En particular, pode transferir varias versións atopadas dun obxecto á vez se o cliente solicitou a versión.

4. Almacenamento en caché de datos

Os búfers de MemStore e BlockCache ocupan ata o 80% da memoria RS no heap asignada (o resto resérvase para tarefas de servizo RS). Se o modo de uso típico é tal que os procesos escriben e len inmediatamente os mesmos datos, entón ten sentido reducir BlockCache e aumentar MemStore, porque Cando os datos de escritura non entran na caché para a súa lectura, BlockCache empregarase con menos frecuencia. O búfer BlockCache consta de dúas partes: LruBlockCache (sempre no montón) e BucketCache (normalmente fóra do montón ou nun SSD). BucketCache debe usarse cando hai moitas solicitudes de lectura e non encaixan en LruBlockCache, o que leva ao traballo activo de Garbage Collector. Ao mesmo tempo, non debe esperar un aumento radical no rendemento ao usar a caché de lectura, pero volveremos sobre isto no parágrafo 8.

Hai un BlockCache para todo o RS e hai un MemStore para cada táboa (un para cada familia de columnas).

Como descrito en teoría, ao escribir, os datos non entran na caché e, de feito, tales parámetros CACHE_DATA_ON_WRITE para a táboa e "DATOS da caché en escritura" para RS están configurados como falso. Non obstante, na práctica, se escribimos datos en MemStore, despois lixámolos no disco (eliminándoos así), eliminamos o ficheiro resultante e, ao executar unha solicitude de obtención, recibiremos os datos con éxito. Ademais, aínda que desactives completamente BlockCache e enches a táboa con novos datos, despois restableces o MemStore no disco, elimínaos e solicitalos doutra sesión, aínda se recuperarán dalgún lugar. Entón, HBase almacena non só datos, senón tamén misterios misteriosos.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

O parámetro "DATOS da caché na lectura" está definido como falso. Se tes algunha idea, benvido a comentala nos comentarios.

5. Procesamento de datos por lotes MultiGet/MultiPut

Procesar solicitudes individuais (Obter/Poner/Eliminar) é unha operación bastante cara, polo que, se é posible, deberías combinalas nunha Lista ou Lista, o que che permite obter un aumento significativo do rendemento. Isto é especialmente certo para a operación de escritura, pero ao ler hai a seguinte trampa. O seguinte gráfico mostra o tempo para ler 50 rexistros de MemStore. A lectura realizouse nun fío e no eixe horizontal amosa o número de claves da solicitude. Aquí podes ver que ao aumentar a mil claves nunha solicitude, o tempo de execución baixa, é dicir. aumenta a velocidade. Non obstante, co modo MSLAB activado de forma predeterminada, despois deste limiar comeza unha caída radical no rendemento e canto maior sexa a cantidade de datos no rexistro, maior será o tempo de funcionamento.

As probas realizáronse nunha máquina virtual, 8 núcleos, versión HBase 2.0.0-cdh6.0.0-beta1.

O modo MSLAB está deseñado para reducir a fragmentación do montón, que se produce debido á mestura de datos de nova xeración e antiga. Como solución alternativa, cando MSLAB está activado, os datos colócanse en celas relativamente pequenas (anacos) e procísanse en anacos. Como resultado, cando o volume do paquete de datos solicitado supera o tamaño asignado, o rendemento cae drasticamente. Por outra banda, desactivar este modo tampouco é recomendable, xa que provocará paradas por GC nos momentos de procesamento intensivo de datos. Unha boa solución é aumentar o volume da célula no caso de escribir activa via put ao mesmo tempo que a lectura. Paga a pena notar que o problema non ocorre se, despois da gravación, executa o comando de descarga, que restablece o MemStore no disco, ou se carga usando BulkLoad. A táboa seguinte mostra que as consultas de MemStore para datos máis grandes (e da mesma cantidade) provocan desaceleracións. Non obstante, ao aumentar o tamaño do fragmento devolvemos o tempo de procesamento á normalidade.

Ademais de aumentar o tamaño do fragmento, a división dos datos por rexión axuda, é dicir. división da mesa. Isto provoca que se cheguen menos solicitudes a cada rexión e, se caben nunha cela, a resposta segue sendo boa.

6. Estratexia para dividir táboas en rexións (dividir)

Dado que HBase é un almacenamento de valores clave e a partición realízase por chave, é moi importante dividir os datos de forma uniforme en todas as rexións. Por exemplo, particionar esa táboa en tres partes fará que os datos se dividan en tres rexións:

Acontece que isto leva a unha forte desaceleración se os datos cargados posteriormente semellan, por exemplo, valores longos, a maioría deles comezando polo mesmo díxito, por exemplo:

1000001
1000002
...
1100003

Dado que as claves se almacenan como unha matriz de bytes, todas comezarán igual e pertencerán á mesma rexión número 1 que almacena este rango de claves. Existen varias estratexias de partición:

HexStringSplit: converte a clave nunha cadea codificada hexadecimal no intervalo "00000000" => "FFFFFFFF" e enchendo a esquerda con ceros.

UniformSplit: converte a clave nunha matriz de bytes con codificación hexadecimal no rango "00" => "FF" e recheo á dereita con ceros.

Ademais, pode especificar calquera rango ou conxunto de claves para dividir e configurar a división automática. Non obstante, un dos enfoques máis sinxelos e efectivos é UniformSplit e o uso da concatenación hash, por exemplo o par de bytes máis significativo de executar a chave a través da función CRC32(rowkey) e a propia rowkey:

hash + rowkey

Entón, todos os datos distribuiranse uniformemente entre as rexións. Ao ler, os dous primeiros bytes simplemente descartanse e permanece a clave orixinal. RS tamén controla a cantidade de datos e claves na rexión e, se se superan os límites, divídese automaticamente en partes.

7. Tolerancia a fallos e localización dos datos

Dado que só unha rexión é responsable de cada conxunto de claves, a solución aos problemas asociados aos fallos ou a desactivación de RS é almacenar todos os datos necesarios en HDFS. Cando RS cae, o mestre detecta isto pola ausencia dun latido cardíaco no nodo ZooKeeper. A continuación, atribúe a rexión servida a outro RS ​​e dado que os HFfiles se almacenan nun sistema de ficheiros distribuído, o novo propietario leos e segue a servir os datos. Non obstante, dado que algúns dos datos poden estar na MemStore e non tiveron tempo de entrar en HFiles, WAL, que tamén se almacena en HDFS, úsase para restaurar o historial de operacións. Despois de que se apliquen os cambios, RS pode responder ás solicitudes, pero o movemento leva ao feito de que algúns dos datos e os procesos que os atenden acaban en diferentes nós, é dicir. localidade está a diminuír.

A solución ao problema é unha gran compactación: este procedemento move os ficheiros a aqueles nodos responsables deles (onde se atopan as súas rexións), polo que durante este procedemento a carga na rede e nos discos aumenta drasticamente. Non obstante, no futuro, o acceso aos datos acelerarase notablemente. Ademais, major_compaction realiza a fusión de todos os ficheiros HFile nun só ficheiro dentro dunha rexión e tamén limpa os datos dependendo da configuración da táboa. Por exemplo, pode especificar o número de versións dun obxecto que se deben conservar ou o tempo de vida despois do cal se elimina fisicamente o obxecto.

Este procedemento pode ter un efecto moi positivo no funcionamento da HBase. A imaxe de abaixo mostra como se deteriorou o rendemento como resultado da gravación de datos activa. Aquí podes ver como 40 fíos escribiron nunha táboa e 40 fíos len datos simultaneamente. Os fíos de escritura xeran cada vez máis ficheiros HF, que son lidos por outros fíos. Como resultado, cada vez hai que eliminar máis datos da memoria e, finalmente, o GC comeza a funcionar, o que practicamente paraliza todo o traballo. O lanzamento dunha gran compactación levou á limpeza dos restos resultantes e á restauración da produtividade.

A proba realizouse en 3 DataNodes e 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). Versión HBase 1.2.0-cdh5.14.2

Paga a pena sinalar que se lanzou unha compactación importante nunha táboa "en directo", na que se escribían e lirían os datos de forma activa. Houbo unha declaración en liña de que isto podería levar a unha resposta incorrecta ao ler os datos. Para comprobar, lanzouse un proceso que xerou novos datos e os escribiu nunha táboa. Despois diso, lin e comprobei inmediatamente se o valor resultante coincidía co que estaba escrito. Mentres se executaba este proceso, realizouse unha compactación importante unhas 200 veces e non se rexistrou nin un só fallo. Quizais o problema apareza raramente e só durante a carga elevada, polo que é máis seguro deter os procesos de escritura e lectura segundo o planeado e realizar a limpeza para evitar tales caídas do GC.

Ademais, a compactación maior non afecta o estado do MemStore; para vacialo no disco e compactalo, cómpre usar flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Configuración e rendemento

Como xa se mencionou, HBase amosa o seu maior éxito onde non precisa facer nada, ao executar BulkLoad. Non obstante, isto aplícase á maioría dos sistemas e persoas. Non obstante, esta ferramenta é máis axeitada para almacenar datos en bloque en grandes bloques, mentres que se o proceso require varias solicitudes de lectura e escritura en competencia, utilízanse os comandos Get e Put descritos anteriormente. Para determinar os parámetros óptimos, realizáronse os lanzamentos con varias combinacións de parámetros e configuracións da táboa:

• Lanzáronse 10 fíos simultaneamente 3 veces seguidas (chamémoslle un bloque de fíos).
• O tempo de funcionamento de todos os fíos dun bloque foi unha media e foi o resultado final da operación do bloque.
• Todos os fíos traballaron coa mesma táboa.
• Antes de cada inicio do bloque de rosca, realizouse unha compactación importante.
• Cada bloque realizou só unha das seguintes operacións:

—Pon
—Conseguir
-Obter+Pon

• Cada bloque realizou 50 iteracións do seu funcionamento.
• O tamaño do bloque dun rexistro é de 100 bytes, 1000 bytes ou 10000 bytes (aleatorios).
• Lanzáronse bloques con diferentes números de claves solicitadas (unha ou 10).
• Os bloques executáronse baixo diferentes configuracións da táboa. Parámetros modificados:

— BlockCache = activado ou desactivado
— BlockSize = 65 KB ou 16 KB
— Particións = 1, 5 ou 30
— MSLAB = activado ou desactivado

Polo tanto, o bloque ten o seguinte aspecto:

a. O modo MSLAB activouse/desactivouse.
b. Creouse unha táboa para a que se estableceron os seguintes parámetros: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Estableceuse a compresión en GZ.
d. Lanzáronse 10 fíos simultaneamente facendo 1/10 operacións put/get/get+put nesta táboa con rexistros de 100/1000/10000 bytes, realizando 50 consultas seguidas (claves aleatorias).
e. O punto d repetiuse tres veces.
f. Promediouse o tempo de funcionamento de todos os fíos.

Probáronse todas as combinacións posibles. É previsible que a velocidade caiga a medida que aumente o tamaño do rexistro ou que desactivar o almacenamento na caché provocará unha desaceleración. Non obstante, o obxectivo era comprender o grao e a significación da influencia de cada parámetro, polo que os datos recollidos foron introducidos na entrada dunha función de regresión lineal, o que permite avaliar a significación mediante estatísticas t. A continuación móstranse os resultados dos bloques que realizan operacións Put. Conxunto completo de combinacións 2*2*3*2*3 = 144 opcións + 72 tk. algúns foron feitos dúas veces. Polo tanto, hai 216 carreiras en total:

As probas realizáronse nun mini-clúster composto por 3 DataNodes e 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). Versión HBase 1.2.0-cdh5.14.2.

A velocidade de inserción máis alta de 3.7 segundos obtívose co modo MSLAB desactivado, nunha táboa cunha partición, con BlockCache activado, BlockSize = 16, rexistros de 100 bytes, 10 pezas por paquete.
A velocidade de inserción máis baixa de 82.8 segundos obtívose co modo MSLAB activado, nunha táboa cunha partición, con BlockCache activado, BlockSize = 16, rexistros de 10000 bytes, 1 cada un.

Agora vexamos o modelo. Vemos a boa calidade do modelo baseado en R2, pero está absolutamente claro que a extrapolación está contraindicada aquí. O comportamento real do sistema cando os parámetros cambian non será lineal; este modelo non é necesario para predicións, senón para comprender o que pasou dentro dos parámetros dados. Por exemplo, aquí vemos polo criterio de Student que os parámetros BlockSize e BlockCache non importan para a operación Put (que xeralmente é bastante previsible):

Pero o feito de que aumentar o número de particións leva a unha diminución do rendemento é algo inesperado (xa vimos o impacto positivo de aumentar o número de particións con BulkLoad), aínda que é comprensible. En primeiro lugar, para procesar, tes que xerar solicitudes a 30 rexións en lugar dunha, e o volume de datos non é tal que isto supoña unha ganancia. En segundo lugar, o tempo de funcionamento total está determinado polo RS máis lento e, dado que o número de DataNodes é menor que o número de RS, algunhas rexións teñen localidade cero. Ben, vexamos os cinco primeiros:

Agora imos avaliar os resultados de executar os bloques Get:

O número de particións perdeu significado, o que probablemente se explica polo feito de que os datos están ben almacenados na caché e a caché de lectura é o parámetro máis significativo (estatisticamente). Por suposto, aumentar o número de mensaxes nunha solicitude tamén é moi útil para o rendemento. Máximas puntuacións:

Ben, para rematar, vexamos o modelo do bloque que primeiro realizou get e despois puxo:

Todos os parámetros son significativos aquí. E os resultados dos líderes:

9. Probas de carga

Ben, por fin lanzaremos unha carga máis ou menos decente, pero sempre é máis interesante cando tes algo con que comparar. No sitio web de DataStax, o desenvolvedor clave de Cassandra, hai resultados NT dunha serie de almacenamentos NoSQL, incluíndo a versión HBase 0.98.6-1. A carga realizouse mediante 40 fíos, tamaño de datos 100 bytes, discos SSD. O resultado da proba das operacións de lectura-modificación-escritura mostrou os seguintes resultados.

Polo que entendo, a lectura realizouse en bloques de 100 rexistros e para os nodos HBase 16, a proba DataStax mostrou un rendemento de 10 mil operacións por segundo.

É unha sorte que o noso clúster tamén teña 16 nodos, pero non é moi “afortunado” que cada un teña 64 núcleos (threads), mentres que na proba de DataStax só hai 4. Por outra banda, teñen unidades SSD, mentres que nós temos HDD. ou máis a nova versión de HBase e a utilización da CPU durante a carga practicamente non aumentou significativamente (visualmente nun 5-10 por cento). Non obstante, intentemos comezar a usar esta configuración. Configuración predeterminada da táboa, a lectura realízase no intervalo de claves de 0 a 50 millóns de forma aleatoria (é dicir, esencialmente nova cada vez). A táboa contén 50 millóns de rexistros, divididos en 64 particións. As claves son hash usando crc32. A configuración da táboa é predeterminada, MSLAB está activado. Ao lanzar 40 fíos, cada fío le un conxunto de 100 claves aleatorias e inmediatamente escribe os 100 bytes xerados nestas chaves.

Soporte: 16 DataNode e 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 subprocesos). Versión HBase 1.2.0-cdh5.14.2.

O resultado medio está máis preto de 40 mil operacións por segundo, o que é significativamente mellor que na proba DataStax. Non obstante, para fins experimentais, pode cambiar lixeiramente as condicións. É moi improbable que todo o traballo se realice exclusivamente nunha mesa, e tamén só en claves únicas. Supoñamos que hai un determinado conxunto de claves "quentes" que xera a carga principal. Por iso, intentemos crear unha carga con rexistros máis grandes (10 KB), tamén en lotes de 100, en 4 táboas diferentes e limitando o rango de claves solicitadas a 50 mil. O gráfico de abaixo mostra o lanzamento de 40 fíos, cada fío le. un conxunto de 100 claves e inmediatamente escribe 10 KB aleatorios nestas chaves.

Soporte: 16 DataNode e 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 subprocesos). Versión HBase 1.2.0-cdh5.14.2.

Durante a carga, a compactación importante lanzouse varias veces, como se mostra arriba, sen este procedemento, o rendemento degradarase gradualmente, pero tamén se produce unha carga adicional durante a execución. As baixas son causadas por varias razóns. Ás veces, os fíos remataron de funcionar e houbo unha pausa mentres se reiniciaban, ás veces as aplicacións de terceiros creaban unha carga no clúster.

Ler e escribir inmediatamente é un dos escenarios de traballo máis difíciles para HBase. Se só fai pequenas solicitudes de entrada, por exemplo 100 bytes, combinándoas en paquetes de 10-50 mil pezas, pode obter centos de miles de operacións por segundo, e a situación é semellante coas solicitudes de só lectura. Cabe destacar que os resultados son radicalmente mellores que os obtidos por DataStax, sobre todo debido a solicitudes en bloques de 50 mil.

Soporte: 16 DataNode e 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 subprocesos). Versión HBase 1.2.0-cdh5.14.2.

10. Conclusións

Este sistema está configurado de forma bastante flexible, pero aínda se descoñece a influencia dun gran número de parámetros. Algúns deles foron probados, pero non foron incluídos no conxunto de probas resultante. Por exemplo, os experimentos preliminares mostraron un significado insignificante dun parámetro como DATA_BLOCK_ENCODING, que codifica información usando valores de celas veciñas, o que é comprensible para os datos xerados aleatoriamente. Se usas un gran número de obxectos duplicados, a ganancia pode ser significativa. En xeral, podemos dicir que HBase dá a impresión dunha base de datos bastante seria e ben pensada, que pode ser bastante produtiva cando se realizan operacións con grandes bloques de datos. Sobre todo se é posible separar no tempo os procesos de lectura e escritura.

Se hai algo na túa opinión que non se revela o suficiente, estou disposto a contarllo con máis detalle. Convidámoste a compartir a túa experiencia ou discutir se non estás de acordo con algo.

Fonte: www.habr.com