Dette indlæg blev oprindeligt offentliggjort via blogs.apache.org, vi genudgiver det her i en let ændret form for din bekvemmelighed:
Ved første øjekast ser Apache HBase-arkitekturen ud til at følge en master/slave-model, hvor masteren modtager alle anmodningerne, men det virkelige arbejde udføres af slaverne. Dette er faktisk ikke tilfældet, og i denne artikel vil jeg beskrive, hvilke opgaver der rent faktisk varetages af mesteren og slaverne.
Regioner og regionsservere
HBase er Hadoop-lagringsadministratoren, der giver tilfældige læsninger og skrivninger med lav latens oven på HDFS, og den kan håndtere petabytes af data. En af de interessante muligheder i HBase er auto-sharding, som ganske enkelt betyder, at tabeller bliver dynamisk distribueret af systemet, når de bliver for store.
Den grundlæggende enhed for horisontal skalerbarhed i HBase kaldes en Region . Regioner er en delmængde af tabellens data, og de er i det væsentlige et sammenhængende, sorteret rækker, der er gemt sammen.
I første omgang er der kun én region til en tabel. Som vist nedenfor, når områder bliver for store efter tilføjelse af flere rækker, opdeles området i to ved den midterste tast, hvilket skaber to omtrent lige store halvdele.
I HBase kaldes slaverne Region Servers . Hver regionsserver er ansvarlig for at betjene et sæt regioner, og én region (dvs. række rækker) kan kun betjenes af én regionsserver.
HBase-arkitekturen har to hovedtjenester:HMaster der er ansvarlig for at koordinere klyngen og udføre administrative operationer og HRegionServer ansvarlig for at håndtere en delmængde af tabellens data.
HMaster, Region Assignment og Balancing
Som tidligere nævnt koordinerer HBase Master HBase Cluster og er ansvarlig for den administrative drift.
En regionsserver kan betjene en eller flere regioner. Hver region tildeles en regionsserver ved opstart, og masteren kan beslutte at flytte en region fra en regionsserver til en anden som et resultat af en belastningsbalanceoperation. Masteren håndterer også regionsserverfejl ved at tildele regionen til en anden regionsserver.
Kortlægningen af regioner og regionsservere opbevares i en systemtabel kaldet META. Ved at læse META kan du identificere, hvilken region der er ansvarlig for din nøgle. Dette betyder, at for læse- og skriveoperationer er masteren slet ikke involveret, og klienter kan gå direkte til den ansvarlige regionsserver for at betjene de anmodede data.
Sådan finder du en rækkenøgle:Hvilken regionsserver er ansvarlig?
For at sætte eller få en række behøver klienter ikke at kontakte masteren, klienter kan direkte kontakte regionsserveren, der håndterer den angivne række, eller i tilfælde af en klientscanning kan de direkte kontakte det sæt af regionsservere, der er ansvarlige for at håndtere sættet nøgler:
For at identificere regionsserveren laver klienten en forespørgsel på META-tabellen.
META er en systemtabel, der bruges til at holde styr på regioner. Den indeholder servernavnet og en regionidentifikator, der omfatter et tabelnavn og startrækketasten. Ved at se på start-nøglen og den næste region er start-key-klienter i stand til at identificere rækken af rækker indeholdt i en bestemt region.
Klienten opbevarer en cache for regionsplaceringerne. Dette undgår, at klienter rammer META-tabellen, hver gang en operation på den samme region udstedes. I tilfælde af en regionsdeling eller flytning til en anden regionsserver (på grund af balancering eller tildelingspolitikker), modtager klienten en undtagelse som svar, og cachen vil blive opdateret ved at hente de opdaterede oplysninger fra META-tabellen:
Da META er en tabel ligesom de andre, skal klienten identificere hvilken server META er placeret på. META-lokationerne gemmes i en ZooKeeper-node efter tildeling af Master, og klienten læser noden direkte for at få adressen på den regionsserver, der indeholder META.
HBases originale design var baseret på BigTable, med en anden tabel kaldet -ROOT- indeholdende META-lokationerne og Apache ZooKeeper, der pegede på den. HBase 0.96 fjernede denne ordning kun til fordel for ZooKeeper, da META ikke kan opdeles og derfor består af en enkelt region.
Client API:Master- og regionsansvar
HBase Java-klient-API'en har to hovedgrænseflader:
- HBaseAdmin tillader interaktion med "tabelskemaet" ved at oprette/slette/ændre tabeller, og det tillader interaktion med klyngen ved at tildele/fjerne tildeling af regioner, flette regioner sammen, kalde for en flush, og så videre. Denne grænseflade kommunikerer med Master.
- HTable giver klienten mulighed for at manipulere dataene i en specificeret tabel ved at bruge get, put, delete og alle andre dataoperationer. Denne grænseflade kommunikerer direkte med de regionsservere, der er ansvarlige for at håndtere det anmodede sæt nøgler.
Disse to grænseflader har separate ansvarsområder:HBaseAdmin bruges kun til at udføre admin-handlinger og kommunikere med Master, mens HTable bruges til at manipulere data og kommunikere med regionerne.
Konklusion
Som vi har set her, betyder det ikke at have en Master/Slave-arkitektur, at hver operation går gennem masteren. For at læse og skrive data går HBase-klienten faktisk direkte til den specifikke regionsserver, der er ansvarlig for at håndtere rækkenøglerne for alle dataoperationerne (HTable). Masteren bruges kun af klienten til tabeloprettelse, ændring og sletning (HBaseAdmin).
Selvom konceptet med en master eksisterer, er HBase-klienten ikke afhængig af det til dataoperationer, og klyngen kan blive ved med at betjene data, selvom masteren går ned.
Matteo Bertozzi er softwareingeniør på platformsteamet og en HBase Committer.
Hvis du er interesseret i HBase, skal du sørge for at tilmelde dig HBaseCon 2013 (13. juni, San Francisco) – fællesskabsbegivenheden for HBase-bidragydere, udviklere, administratorer og brugere. Pladsen er begrænset!