{"id":55302,"date":"2020-01-17T00:00:00","date_gmt":"2020-01-16T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/teoriya-i-praktika-ispolzovaniya-hbase"},"modified":"2020-02-18T14:03:24","modified_gmt":"2020-02-18T11:03:24","slug":"teoriya-i-praktika-ispolzovaniya-hbase","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teor\u00eda y pr\u00e1ctica del uso de HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Buenos d\u00edas! Me llamo Danil Lipovoy y nuestro equipo en Sbertech ha comenzado a utilizar HBase como almac\u00e9n de datos en tiempo real. A lo largo de su estudio, hemos acumulado experiencia que nos gustar\u00eda sistematizar y describir (esperamos que sea \u00fatil para muchos). Todos los experimentos mencionados a continuaci\u00f3n se realizaron con las versiones HBase 1.2.0-cdh5.14.2 y 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Arquitectura general <\/li>\n
  2. Escritura de datos en HBASE<\/li>\n
  3. Lectura de datos de HBASE<\/li>\n
  4. Cach\u00e9 de datos<\/li>\n
  5. Procesamiento por lotes de datos MultiGet\/MultiPut<\/li>\n
  6. Estrategia de partici\u00f3n de tablas en regiones (splitting)<\/li>\n
  7. Tolerancia a fallos, compactaci\u00f3n y localizaci\u00f3n de datos<\/li>\n
  8. Configuraciones y rendimiento<\/li>\n
  9. Pruebas de carga<\/li>\n
  10. Conclusiones<\/li>\n<\/ol>\n

    <\/a><\/noindex><\/p>\n

    1. Arquitectura general<\/h2>\n

    \n\"Teor\u00eda
    \nEl Master de respaldo escucha el heartbeat del activo en el nodo de ZooKeeper y, en caso de que el activo desaparezca, toma las funciones del maestro. <\/p>\n

    2. Escritura de datos en HBASE<\/h2>\n

    \nPrimero, consideremos el caso m\u00e1s simple: escribir un objeto clave-valor en una tabla utilizando put(rowkey). El cliente debe averiguar primero d\u00f3nde se encuentra el servidor de regi\u00f3n ra\u00edz (Root Region Server \u2014 RRS), que almacena la tabla hbase:meta. Esta informaci\u00f3n la obtiene de ZooKeeper. Luego, se dirige a RRS y lee la tabla hbase:meta, de la cual extrae informaci\u00f3n sobre qu\u00e9 RegionServer (RS) es responsable de almacenar los datos para la clave rowkey en la tabla de inter\u00e9s. Para un uso posterior, el cliente almacena en cach\u00e9 la meta-tabla y, por lo tanto, las solicitudes subsecuentes son m\u00e1s r\u00e1pidas, y van directamente a RS.<\/p>\n

    Luego, el RS, al recibir la solicitud, primero la escribe en el WriteAheadLog (WAL), lo que es necesario para la recuperaci\u00f3n en caso de fallo. Luego guarda los datos en MemStore. Este es un b\u00fafer en memoria que contiene un conjunto ordenado de claves de esa regi\u00f3n. La tabla puede estar dividida en regiones (particiones), cada una de las cuales contiene un conjunto de claves no superpuestas. Esto permite, al ubicar las regiones en diferentes servidores, obtener un mayor rendimiento. Sin embargo, a pesar de la obviedad de esta afirmaci\u00f3n, m\u00e1s adelante veremos que esto no funciona en todos los casos.<\/p>\n

    Despu\u00e9s de colocar el registro en MemStore, el cliente recibe una respuesta indicando que el registro se ha guardado correctamente. Sin embargo, en realidad, solo se almacena en el b\u00fafer y se almacenar\u00e1 en el disco solo despu\u00e9s de que haya transcurrido un cierto intervalo de tiempo o al llenarlo con nuevos datos. <\/p>\n

    \"Teor\u00eda
    \nAl realizar la operaci\u00f3n \u00abEliminar\u00bb, no se produce la eliminaci\u00f3n f\u00edsica de los datos. Simplemente se marcan como eliminados, y la destrucci\u00f3n real ocurre en el momento en que se llama a la funci\u00f3n major compact, sobre la cual se detalla m\u00e1s en el punto 7.<\/p>\n

    Los archivos en formato HFile se acumulan en HDFS y de vez en cuando se inicia el proceso minor compact, que simplemente une archivos peque\u00f1os en uno m\u00e1s grande, sin eliminar nada. Con el tiempo, esto se convierte en un problema que se manifiesta solo al leer los datos (volveremos a esto m\u00e1s adelante). <\/p>\n

    Adem\u00e1s del proceso de carga descrito anteriormente, hay un procedimiento mucho m\u00e1s eficiente, que representa quiz\u00e1s la mayor fortaleza de esta base de datos: BulkLoad. Consiste en que nosotros mismos formamos HFiles y los colocamos en el disco, lo que permite una excelente escalabilidad y alcanzar velocidades bastante razonables. De hecho, aqu\u00ed la limitaci\u00f3n no es HBase, sino la capacidad del hardware. A continuaci\u00f3n, se presentan los resultados de carga en un cl\u00faster compuesto por 16 RegionServers y 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hilos), versi\u00f3n HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Teor\u00eda
    \n
    \nAqu\u00ed se observa que al aumentar la cantidad de particiones (regiones) en la tabla, as\u00ed como los ejecutores de Spark, se obtiene un incremento en la velocidad de carga. Adem\u00e1s, la velocidad depende del volumen de las escrituras. Los bloques grandes dan un aumento en la medida de MB\/s, mientras que los peque\u00f1os aumentan el n\u00famero de registros insertados por unidad de tiempo, manteniendo todo lo dem\u00e1s constante. <\/p>\n

    Tambi\u00e9n se puede iniciar la carga en dos tablas simult\u00e1neamente y obtener el doble de velocidad. A continuaci\u00f3n se muestra que la escritura de bloques de 10 KB simult\u00e1neamente en dos tablas se realiza a una velocidad de alrededor de 600 MB\/s en cada una (un total de 1275 MB\/s), lo que coincide con la velocidad de escritura en una tabla de 623 MB\/s (ver n\u00ba 11 arriba).<\/p>\n

    \"Teor\u00eda
    \nPor otro lado, el segundo lanzamiento con escrituras de 50 KB muestra que la velocidad de carga ya no crece significativamente, lo que indica que se est\u00e1 acercando a los valores limites. Sin embargo, es importante tener en cuenta que la carga de trabajo en HBASE es pr\u00e1cticamente nula, todo lo que se requiere es que primero entregue los datos de hbase:meta, y despu\u00e9s, al colocar los HFiles, vac\u00ede los datos de BlockCache y guarde el buffer MemStore en disco, si no est\u00e1 vac\u00edo.<\/p>\n

    3. Lectura de datos desde HBASE<\/h2>\n

    \nSi se considera que toda la informaci\u00f3n de hbase:meta ya est\u00e1 en posesi\u00f3n del cliente (ver p.2), la solicitud se env\u00eda inmediatamente al RS que almacena la clave necesaria. Primero, la b\u00fasqueda se lleva a cabo en MemCache. Independientemente de si hay datos all\u00ed o no, la b\u00fasqueda tambi\u00e9n se realiza en el b\u00fafer BlockCache y, si es necesario, en HFiles. Si los datos se encuentran en el archivo, se colocan en BlockCache y en la siguiente solicitud se devolver\u00e1n m\u00e1s r\u00e1pido. La b\u00fasqueda en HFile se realiza relativamente r\u00e1pido gracias al uso del filtro de Bloom, es decir, al leer un peque\u00f1o volumen de datos, se determina de inmediato si este archivo contiene la clave necesaria y, si no, se pasa al siguiente.<\/p>\n

    \"Teor\u00eda
    \nAl recibir datos de estas tres fuentes, el RS forma la respuesta. En particular, puede enviar varias versiones encontradas del objeto si el cliente solicita versionado.<\/p>\n

    4. Cacheo de datos<\/h2>\n

    \nLos b\u00faferes MemStore y BlockCache ocupan hasta el 80% de la memoria on-heap asignada al RS (el resto se reserva para tareas de servicio del RS). Si el modo t\u00edpico de uso es tal que los procesos escriben y luego leen esos mismos datos, tiene sentido reducir BlockCache y aumentar MemStore, ya que al escribir los datos no entran en el cach\u00e9 de lectura, lo que har\u00e1 que el uso de BlockCache sea menos frecuente. El b\u00fafer BlockCache consta de dos partes: LruBlockCache (siempre on-heap) y BucketCache (generalmente off-heap o en SSD). Se debe utilizar BucketCache cuando hay muchas solicitudes de lectura que no caben en LruBlockCache, lo que lleva a una actividad intensa del Garbage Collector. Sin embargo, no se debe esperar un aumento radical en el rendimiento por el uso del cach\u00e9 de lectura, aunque volveremos a esto en la p. 8.<\/p>\n

    \"Teor\u00eda
    \nBlockCache es \u00fanico para todo el RS, mientras que MemStore es \u00fanico para cada tabla (uno por cada Family de Columnas).<\/p>\n

    \u00bfC\u00f3mo descrito<\/a><\/noindex> en teor\u00eda, al escribir, los datos no van al cach\u00e9 y de hecho, estos par\u00e1metros CACHE_DATA_ON_WRITE para la tabla y 'Cache DATA on Write' para el RS est\u00e1n configurados en false. Sin embargo, en la pr\u00e1ctica, si se escriben datos en MemStore, luego se vac\u00eda en disco (limpi\u00e1ndolo de esta manera), luego se elimina el archivo resultante, al ejecutar una solicitud get obtendremos los datos con \u00e9xito. Y lo que es m\u00e1s, incluso si se desactiva completamente BlockCache y se llena la tabla con nuevos datos, luego se logra el vaciado de MemStore en disco, al eliminarlos y solicitarlos desde otra sesi\u00f3n, a\u00fan se extraer\u00e1n de alguna parte. As\u00ed que HBase almacena no solo datos, sino tambi\u00e9n misterios intrigantes.<\/p>\n

    hbase(main):001:0> crear 'ns:magic', 'cf'\nTabla ns:magic creada\nTard\u00f3 1.1533 segundos\nhbase(main):002:0> poner 'ns:magic', 'key1', 'cf:c', 'intenta_borrarme'\nTard\u00f3 0.2610 segundos\nhbase(main):003:0> vaciar 'ns:magic'\nTard\u00f3 0.6161 segundos\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> obtener 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, valor=intenta_borrarme\n<\/code><\/pre>\n
    \nEl par\u00e1metro \u00abCache DATA on Read\u00bb est\u00e1 configurado en falso. Si tienes ideas, bienvenido a discutirlo en los comentarios.<\/p>\n
    5. Procesamiento en lote de datos MultiGet\/MultiPut<\/h2>\n
    \nEl procesamiento de solicitudes individuales (Get\/Put\/Delete) es una operaci\u00f3n bastante costosa, por lo que se deben agrupar siempre que sea posible en List o List, lo que permite obtener un aumento significativo en el rendimiento. Especialmente se refiere a la operaci\u00f3n de escritura, mientras que en la lectura existe una trampa. En el gr\u00e1fico a continuaci\u00f3n se muestra el tiempo de lectura de 50,000 registros desde MemStore. La lectura se realiz\u00f3 en un solo hilo y en el eje horizontal se muestra la cantidad de claves en la solicitud. Se observa que al aumentar hasta mil claves en una solicitud, el tiempo de ejecuci\u00f3n disminuye, es decir, la velocidad aumenta. Sin embargo, con el modo MSLAB habilitado por defecto, despu\u00e9s de este umbral se produce un dr\u00e1stico descenso en el rendimiento, y cuanto mayor sea el volumen de datos en el registro, mayor ser\u00e1 el tiempo de ejecuci\u00f3n. <\/p>\n
    \"Teor\u00eda
    \n
    \nLas pruebas se realizaron en una m\u00e1quina virtual, 8 n\u00facleos, versi\u00f3n HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    El modo MSLAB est\u00e1 dise\u00f1ado para reducir la fragmentaci\u00f3n del heap, que ocurre debido a la mezcla de datos de generaciones nuevas y viejas. Como soluci\u00f3n al problema, al habilitar MSLAB, los datos se colocan en celdas (chunks) relativamente peque\u00f1as y se procesan en lotes. Como resultado, cuando el volumen en el paquete de datos solicitado supera el tama\u00f1o asignado, la rendimiento disminuye dr\u00e1sticamente. Por otro lado, desactivar este modo tambi\u00e9n es indeseable, ya que conducir\u00e1 a interrupciones debido a GC en momentos de intensa actividad con datos. Una buena salida es aumentar el tama\u00f1o de la celda, en caso de escritura activa a trav\u00e9s de put al mismo tiempo que la lectura. Cabe se\u00f1alar que el problema no surge si despu\u00e9s de escribir se ejecuta el comando flush que vac\u00eda MemStore en el disco o si se realiza la carga mediante BulkLoad. En la tabla a continuaci\u00f3n se muestra que las solicitudes desde MemStore de datos de mayor volumen (y igual cantidad) conducen a un descenso en la velocidad. Sin embargo, al aumentar el chunksize, se devuelve el tiempo de procesamiento a la normalidad.<\/p>\n
    \"Teor\u00eda
    \nAdem\u00e1s de aumentar el chunksize, ayuda dividir los datos por regiones, es decir, hacer el spliteo de tablas. Esto hace que para cada regi\u00f3n lleguen menos solicitudes y, si se colocan en una celda, la respuesta se mantiene buena.<\/p>\n
    6. Estrategia de divisi\u00f3n de tablas por regiones (spliteo)<\/h2>\n
    \nDado que HBase es un almacenamiento de clave-valor y la partici\u00f3n se realiza por clave, es crucial distribuir los datos de manera uniforme entre todas las regiones. Por ejemplo, la partici\u00f3n de una tabla de este tipo en tres partes dar\u00e1 lugar a que los datos se dividan en tres regiones:<\/p>\n
    \"Teor\u00eda
    \nA veces, esto puede llevar a una ralentizaci\u00f3n dr\u00e1stica si los datos futuros cargados son, por ejemplo, valores long que en su mayor\u00eda comienzan con el mismo d\u00edgito, por ejemplo:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Dado que las claves se almacenan como un array de bytes, todas comenzar\u00e1n igual y pertenecer\u00e1n a una regi\u00f3n #1 que almacena este rango de claves. Existen varias estrategias de divisi\u00f3n:<\/p>\n
    HexStringSplit \u2013 Convierte la clave en una cadena con codificaci\u00f3n hexadecimal en el rango \u00ab00000000\u00bb => \u00abFFFFFFFF\u00bb y rellenando a la izquierda con ceros.<\/p>\n
    UniformSplit \u2013 Convierte la clave en un array de bytes con codificaci\u00f3n hexadecimal en el rango \u00ab00\u00bb => \u00abFF\u00bb y rellenando a la derecha con ceros.<\/p>\n
    Adem\u00e1s, se puede especificar cualquier rango o conjunto de claves para la divisi\u00f3n y configurar el auto-spliteo. Sin embargo, uno de los enfoques m\u00e1s simples y efectivos es UniformSplit y la concatenaci\u00f3n del hash, por ejemplo, el par de bytes m\u00e1s significativos de ejecutar la clave a trav\u00e9s de la funci\u00f3n CRC32(rowkey) y, efectivamente, la rowkey:<\/p>\n
    hash + rowkey<\/p>\n
    Entonces todos los datos se distribuir\u00e1n uniformemente entre las regiones. Al leer, simplemente se desechan los primeros dos bytes y queda la clave original. Adem\u00e1s, el RS controla la cantidad de datos y claves en la regi\u00f3n y, al superar los l\u00edmites, autom\u00e1ticamente lo divide en partes. <\/p>\n
    7. Tolerancia a fallos y localizaci\u00f3n de datos<\/h2>\n
    \nDado que cada conjunto de claves solo est\u00e1 a cargo de una regi\u00f3n, la soluci\u00f3n a los problemas relacionados con las ca\u00eddas de RS o el desmantelamiento es almacenar todos los datos necesarios en HDFS. Cuando un RS cae, el maestro lo detecta a trav\u00e9s de la falta de latidos en el nodo de ZooKeeper. Luego, asigna la regi\u00f3n afectada a otro RS y, dado que los HFiles se almacenan en un sistema de archivos distribuido, el nuevo propietario los lee y contin\u00faa administrando los datos. Sin embargo, dado que parte de los datos puede estar en MemStore y no ha tenido tiempo de ser grabada en HFiles, se utiliza el WAL para recuperar el historial de operaciones, que tambi\u00e9n se almacena en HDFS. Despu\u00e9s de aplicar los cambios, el RS puede responder a las solicitudes, sin embargo, el traslado implica que parte de los datos y los procesos que los gestionan se encuentran en diferentes nodos, es decir, se reduce la localizaci\u00f3n. <\/p>\n
    La soluci\u00f3n al problema es la compactaci\u00f3n mayor: este procedimiento mueve los archivos a los nodos que est\u00e1n a cargo de ellos (donde se encuentran sus regiones), lo que provoca un aumento brusco de la carga en la red y en los discos durante esta operaci\u00f3n. Sin embargo, el acceso a los datos se acelera notablemente posteriormente. Adem\u00e1s, la major_compaction combina todos los HFiles en un solo archivo dentro de la regi\u00f3n, y tambi\u00e9n limpia los datos seg\u00fan la configuraci\u00f3n de la tabla. Por ejemplo, se puede especificar la cantidad de versiones de un objeto que se deben conservar o el tiempo de vida, despu\u00e9s del cual el objeto se elimina f\u00edsicamente.<\/p>\n
    Este procedimiento puede tener un impacto muy positivo en el funcionamiento de HBase. En la imagen a continuaci\u00f3n se puede ver c\u00f3mo ha disminuido el rendimiento debido a la actividad intensa de escritura de datos. Se observa c\u00f3mo 40 hilos estaban escribiendo en una tabla y 40 hilos le\u00edan datos al mismo tiempo. Los hilos de escritura generan cada vez m\u00e1s HFiles, que son le\u00eddos por otros hilos. Como resultado, se necesita eliminar cada vez m\u00e1s datos de la memoria y, al final, se activa el GC, que pr\u00e1cticamente paraliza todo el trabajo. La ejecuci\u00f3n de una compactaci\u00f3n mayor condujo a la limpieza de los atascos formados y a la recuperaci\u00f3n del rendimiento.<\/p>\n
    \"Teor\u00eda
    \nLa prueba se realiz\u00f3 en 3 DataNodes y 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hilos). Versi\u00f3n de HBase 1.2.0-cdh5.14.2<\/p>\n
    Es importante destacar que la ejecuci\u00f3n de la compactaci\u00f3n mayor se realiz\u00f3 en una tabla \"viva\", en la que se estaban escribiendo y leyendo datos activamente. En la red aparec\u00eda la afirmaci\u00f3n de que esto podr\u00eda conducir a una respuesta incorrecta al leer datos. Para comprobarlo, se inici\u00f3 un proceso que generaba nuevos datos y los escrib\u00eda en la tabla. Despu\u00e9s, inmediatamente le\u00eda y verificaba si el valor obtenido coincid\u00eda con el que se hab\u00eda registrado. Durante el funcionamiento de este proceso, se ejecut\u00f3 la compactaci\u00f3n mayor aproximadamente 200 veces y no se registr\u00f3 ning\u00fan fallo. Es posible que el problema se manifieste raramente y solo durante una alta carga, por lo que es m\u00e1s seguro detener programadamente los procesos de escritura y lectura y realizar la limpieza evitando tales ca\u00eddas del GC.<\/p>\n
    Adem\u00e1s, la compactaci\u00f3n mayor no afecta al estado de MemStore; para vaciarlo en disco y compactarlo, se debe utilizar flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Configuraci\u00f3n y rendimiento<\/h2>\n
    \nComo se mencion\u00f3 anteriormente, HBase muestra el mayor \u00e9xito donde no necesita hacer nada, durante la ejecuci\u00f3n de BulkLoad. Sin embargo, esto se aplica a la mayor\u00eda de los sistemas y personas. Este instrumento es m\u00e1s adecuado para la inserci\u00f3n masiva de datos en bloques grandes, mientras que si el proceso requiere realizar muchas solicitudes concurrentes de lectura y escritura, se utilizan los comandos descritos anteriormente, Get y Put. Para determinar los par\u00e1metros \u00f3ptimos, se realizaron ejecuciones con diversas combinaciones de par\u00e1metros de tablas y configuraciones:<\/p>\n