hadoop - tutorial - ¿Cómo puedo dividirme previamente en hbase?
hbase vs hive (3)
Puede proporcionar una propiedad SPLITS al crear la tabla.
create ''tableName'', ''cf1'', {SPLITS => [''3'',''6'',''9'',''d'']}
Los 4 puntos de división generarán 5 regiones.
Tenga en cuenta que DefaultLoadBalancer de HBase no garantiza una distribución uniforme del 100% entre los servidores de regiones, podría suceder que un servidor de regiones aloje múltiples regiones de la misma tabla.
Para obtener más información acerca de cómo funciona, eche un vistazo a esto :
public List<RegionPlan> balanceCluster(Map<ServerName,List<HRegionInfo>> clusterState)
Genere un plan de equilibrio de carga global de acuerdo con el mapa especificado de información del servidor a las regiones más cargadas de cada servidor. El invariante de equilibrio de carga es que todos los servidores están dentro de 1 región del número promedio de regiones por servidor. Si el promedio es un número entero, todos los servidores estarán equilibrados al promedio. De lo contrario, todos los servidores tendrán regiones de piso (promedio) o techo (promedio). HBASE-3609 Modeled regionsToMove usando MinMaxPriorityQueue de Guava para que podamos obtener de ambos extremos de la cola. Al principio, verificamos si había un servidor de región vacío recién descubierto por el Maestro. Si es así, alternativamente elegimos regiones nuevas / antiguas de head / tail de regionsToMove, respectivamente. Esta alternancia evita agrupar regiones jóvenes en el servidor de la región recién descubierto. De lo contrario, elegimos nuevas regiones del jefe de regionsToMove. Otra mejora de HBASE-3609 es que asignamos regiones de regionsToMove a servidores subcargados en modo round-robin. Anteriormente, un servidor subcargado se llenaría antes de pasar al siguiente servidor subcargado, lo que llevaría al agrupamiento de regiones jóvenes. Finalmente, mezcla aleatoriamente los servidores subcargados para que reciban regiones descargadas de manera relativamente uniforme en todas las llamadas a balanceCluster (). El algoritmo se implementa actualmente como tal:
- Determine los dos números válidos de regiones que cada servidor debe tener, MIN = piso (promedio) y MAX = techo (promedio).
- Redireccione los servidores más cargados, eliminando las regiones de cada uno de modo que cada servidor aloje exactamente MAX regiones. Deténgase una vez que llegue a un servidor que ya tiene <= MAX regiones. Ordena las regiones para pasar de la más reciente a la menos.
- Redireccione los servidores menos cargados, asignando regiones para que cada servidor tenga exactamente regiones MIN. Deténgase una vez que llegue a un servidor que ya tiene regiones> = MIN. Las regiones que se asignan a los servidores subcargados son aquellas que se eliminaron en el paso anterior. Es posible que no haya suficientes regiones vertidas para llenar cada servidor subcargado a MIN. Si es así, terminamos con un número de regiones requeridas para hacerlo, necesitamosRegions. También es posible que pudiéramos completar cada subcarga pero terminamos con regiones que no fueron asignadas desde servidores sobrecargados pero que aún no tienen asignación. Si no se cumple ninguna de estas condiciones (no se necesitan regiones para llenar los servidores subcargados, no hay regiones sobrantes de los servidores sobrecargados), hemos terminado y regresamos. De lo contrario, manejamos estos casos a continuación.
- Si neededRegions no es cero (aún tiene servidores subcargados), iteramos los servidores más cargados de nuevo, eliminando un solo servidor de cada uno (esto hace que tengan regiones MAX para tener regiones MIN).
- Ahora definitivamente tenemos más regiones que necesitan asignación, ya sea desde el paso anterior o desde el vertimiento original de servidores sobrecargados. Iterar los servidores menos cargados llenando cada uno a MIN. Si todavía tenemos más regiones que necesitan asignación, repita de nuevo los servidores menos cargados, esta vez dando a cada uno (llenándolos a MAX) hasta que se agoten.
- Todos los servidores ahora alojarán regiones MIN o MAX. Además, se garantiza que cualquier alojamiento de servidor> = regiones MAX terminará en regiones MAX al final del balanceo. Esto asegura que se mueva la cantidad mínima de regiones posibles.
TODO: En la mayoría de los casos, podemos reasignar el número de regiones de un servidor en particular a cuántas informan como más cargadas. ¿Deberíamos mantener todas las asignaciones en la memoria? ¿Alguna objeción? ¿Esto significa que necesitamos HeapSize en HMaster? ¿O solo monitor cuidadoso? (el pensamiento actual es que mantendremos todas las asignaciones en la memoria)
Estoy almacenando datos en hbase con 5 servidores regionales. Estoy usando md5 hash de url como mis claves de fila. Actualmente, todos los datos se almacenan en un único servidor de región. Por lo tanto, quiero dividir previamente las regiones para que los datos se distribuyan de manera uniforme en todos los servidores de la región, de modo que los datos irán en cada servidor de la región de manera uniforme. Quiero dividir datos como primer carácter de la clave de fila. Como primer carácter es de 0 a f (16 caracteres). Al igual que los datos con rowkey comenzando de 0 a 3 irán en 1st 1st server, 3-6 en 2nd, 6-9 en 3rd, ad on 4th, df on 5th. Cómo puedo hacerlo ?
En caso de que esté usando Apache Phoenix para crear tablas en HBase, puede especificar SALT_BUCKETS en la declaración CREATE. La tabla se dividirá en tantas regiones como mencione el cubo. Phoenix calcula el hash de rowkey (muy probablemente un hash numérico% SALT_BUCKETS) y asigna la celda de la columna a la región apropiada.
CREATE TABLE IF NOT EXISTS us_population (
state CHAR(2) NOT NULL,
city VARCHAR NOT NULL,
population BIGINT
CONSTRAINT my_pk PRIMARY KEY (state, city)) SALT_BUCKETS=3;
Esto dividirá previamente la tabla en 3 regiones
Alternativamente, la interfaz de usuario predeterminada de HBase le permite dividir las regiones en consecuencia.
Si ya tiene todos los datos almacenados, le recomiendo que mueva manualmente algunas regiones a otros servidores regionales usando hbase shell .
hbase> move ‘ENCODED_REGIONNAME’, ‘SERVER_NAME’
Mueve una región. Opcionalmente, especifique el servidor de regiones objetivo, de lo contrario elegiremos uno al azar. NOTA: Usted pasa el nombre de la región codificada, no el nombre de la región, por lo que este comando es un poco diferente de los demás. El nombre de la región codificada es el sufijo hash en los nombres de región: por ejemplo, si el nombre de la región era TestTable, 0094429456,1289497600452.527db22f95c8a9e0116f0cc13c680396. luego, la parte del nombre de la región codificada es 527db22f95c8a9e0116f0cc13c680396. Un nombre de servidor es su host, port plus startcode. Por ejemplo: host187.example.com, 60020,1289493121758