2015-01-27 5 views
8

Sto memorizzando i dati in hbase con 5 server regionali. Sto usando l'hash md5 dell'URL come i miei tasti di riga. Attualmente tutti i dati vengono memorizzati solo in un server di regioni. Pertanto, desidero suddividere le regioni in modo che i dati vengano uniformati su tutto il server della regione, in modo che i dati vengano distribuiti in modo uniforme in ciascun server di regione. Voglio dividere i dati come primo carattere del tasto di riga. Come primo carattere va da 0 a f (16 caratteri). Come i dati con rowkey a partire da 0 a 3 andranno nel 1 ° server regionale, 3-6 sul 2 °, 6-9 sul 3 °, a-d sul 4 °, d-F sul 5 °. Come posso farlo ?Come posso suddividere in hbase

risposta

8

È possibile fornire una proprietà SPLITS durante la creazione della tabella.

create 'tableName', 'cf1', {SPLITS => ['3','6','9','d']} 

I 4 punti di divisione generano 5 regioni.

Si noti che lo DefaultLoadBalancer di HBase non garantisce una distribuzione uniforme al 100% tra i server di regioni, potrebbe accadere che un server di regioni ospiti più regioni dalla stessa tabella.

Per ulteriori informazioni su come funziona dare un'occhiata a this:

public List<RegionPlan> balanceCluster(Map<ServerName,List<HRegionInfo>> clusterState) 

generare un piano di bilanciamento del carico globale secondo la mappa specificato delle informazioni sul server alle regioni più carichi di ciascun server. L'invarianza del bilanciamento del carico è che tutti i server si trovano entro 1 regione di il numero medio di regioni per server. Se la media è un numero intero , tutti i server saranno bilanciati alla media. In caso contrario, tutti i server avranno le regioni floor (media) o ceiling (media). HBASE-3609 Modellato regioniToMove utilizzando Guava MinMaxPriorityQueue in modo da che possiamo recuperare da entrambe le estremità della coda. All'inizio, abbiamo controllare se c'era un server regionale vuoto appena scoperto da Master. In tal caso, alternativamente, scegliere nuove/vecchie regioni dalla testa/coda delle regioni ToMove, rispettivamente. Questa alternanza evita di raggruppare le regioni giovani sul server regionale appena scoperto. Altrimenti, scegliamo le nuove regioni dalla testa delle regioniToMove. Un altro miglioramento da HBASE-3609 è che assegniamo le regioni da regionsToMove a sottostanti server in modalità round-robin. In precedenza un server sotto carico veniva riempito prima di passare al server sottocarico successivo, che porta al clustering di regioni giovani. Infine, mescoliamo casualmente i server con sottotarcheggio in modo che ricevano le regioni scaricate relativamente uguale a attraverso le chiamate a balanceCluster(). L'algoritmo è attualmente implementato come tale:

  1. Determinare i due numeri validi di regioni ciascun server dovrebbe avere, MIN = floor (medio) e MAX = massimale (medio).
  2. Iterare verso il basso i server più caricati, eliminando le regioni da ciascuno in modo che ogni server ospiti esattamente le regioni MAX. Interrompi una volta raggiunto il server che ha già = MAX regioni. Ordina le regioni per spostarti dalla maggior parte dei nuovi recenti.
  3. Iterare i server meno caricati, assegnando le regioni in modo che ogni server abbia esattamente MIN regioni. Interrompi una volta raggiunto un server che ha già > = MIN regioni. Le aree assegnate ai server sottoposti a sottocarico sono quelle che sono state eliminate nel passaggio precedente.È possibile che non ci fossero abbastanza capannoni di regioni per riempire ogni server sotto carico a MIN. Se è così, ci ritroviamo con un numero di regioni richiesto per fare quindi, Regioni necessarie. È anche possibile che siamo stati in grado di riempire ogni sottocarico di ma che si sono concluse con regioni che non erano state assegnate dai server in sovraccarico ma che ancora non hanno assegnazioni. Se nessuna delle due condizioni è soddisfatta (nessuna regione è necessaria per riempire i sottostanti server , nessuna regione rimasta da server sovraccaricati), abbiamo finito e restituiamo . Altrimenti gestiamo questi casi di seguito.
  4. Se necessario, le Regioni sono diverse da zero (hanno ancora server sottoposti a sottocarico), ripetiamo di nuovo i server più caricati, eliminando un singolo server da ciascuno (questo comporta che le regioni MAX abbiano regioni MIN).
  5. Ora abbiamo sicuramente più aree che richiedono l'assegnazione, dal passaggio precedente o dallo spargimento originale dai server sovraccarichi. Iterare i server meno carichi inserendo ciascuno in MIN. Se abbiamo abbiamo ancora più regioni che necessitano di assegnamento, ancora una volta iterate i server caricati meno , questa volta dando a ciascuno (riempiendoli a MAX) fino allo finiamo.
  6. Tutti i server ora ospitano le regioni MIN o MAX. Inoltre, qualsiasi server che ospita> = MAX regioni è garantito per finire con MAX regioni alla fine del bilanciamento. Ciò garantisce che il numero minimo delle regioni possibili venga spostato.

TODO: Possiamo at-più riassegnare il numero di regioni di distanza da un determinato server di essere quanti segnalano come più caricato. Dovremmo mantenere tutti i compiti in memoria? Eventuali obiezioni? Questo significa che abbiamo necessario HeapSize su HMaster? O solo un attento monitoraggio? (Pensiero attuale è terremo tutte le assegnazioni in memoria)

+0

Ma se mi pre-split, mentre la creazione di tavolo, è garantito che si creerà 5 regioni ciascuno in diversi server di regione. destra ? –

+1

Creerà 5 regioni, ma LoadBalancer le assegnerà in base al carico (numero di regioni assegnate) di ciascun regionerver, può succedere che un regionerver ottenga due regioni, o addirittura 3. In ogni caso, non mi preoccuperò troppo a tale proposito, è possibile spostare manualmente le regioni tra i server delle regioni se necessario (ma il LoadBalancer può sovrascriverle se necessario) o persino implementare un servizio di bilanciamento del carico personalizzato. IMHO, creerò solo 10 regioni invece di 5 e consentirò a DefaultLoadBalancer di funzionare come al solito. –

4

Se si dispone di tutti i dati sono già stati memorizzati, vi consiglio di spostare solo alcune regioni in un'altra regione server manualmente utilizzando hbase shell.

hbase> move ‘ENCODED_REGIONNAME’, ‘SERVER_NAME’ 

spostare una regione. Opzionalmente specificare il server delle regioni di destinazione altrimenti scegliamo uno a caso. NOTA: si passa il nome della regione codificata, non il nome della regione , quindi questo comando è leggermente diverso dagli altri. Il nome della regione codificata è il suffisso dell'hash sui nomi delle regioni: ad es. se il nome della regione era TestTable, 0094429456,1289497600452.527db22f95c8a9e0116f0cc13c680396. quindi la parte del nome della regione codificata è 527db22f95c8a9e0116f0cc13c680396 Il nome del server è l'host, la porta più il codice di avviamento . Ad esempio: host187.example.com, 60020,1289493121758

0

Nel caso in cui si utilizza Apache Phoenix per la creazione di tabelle in HBase, è possibile specificare SALT_BUCKETS nell'istruzione CREATE. La tabella si dividerà in tutte le regioni menzionate nel bucket. Phoenix calcola l'hash della riga di comando (molto probabilmente un hash numerico% SALT_BUCKETS) e assegna la cella della colonna all'area appropriata.

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; 

Ciò pre-dividere la tabella in 3 regioni

In alternativa, l'interfaccia utente di default HBase, permette di dividere le regioni di conseguenza. enter image description here