Apache HBase er Hadoop-databasen og er baseret på Hadoop Distributed File System (HDFS ). HBase gør det muligt at tilfældigt få adgang til og opdatere data gemt i HDFS, men filer i HDFS kan kun føjes til og er uforanderlige efter de er oprettet. Så du kan spørge, hvordan leverer HBase læsning og skrivning med lav latency? I dette blogindlæg forklarer vi dette ved at beskrive skrivestien til HBase – hvordan data opdateres i HBase.
Skrivestien er, hvordan en HBase fuldfører put- eller sletoperationer. Denne sti begynder ved en klient, flytter til en regionsserver og slutter, når data til sidst skrives til en HBase-datafil kaldet en HFile . Inkluderet i designet af skrivestien er funktioner, som HBase bruger til at forhindre tab af data i tilfælde af en regionsserverfejl. Derfor kan en forståelse af skrivestien give indsigt i HBases oprindelige mekanisme til forebyggelse af datatab.
Hver HBase-tabel hostes og administreres af sæt servere, som falder i tre kategorier:
- Én aktiv hovedserver
- En eller flere backup-masterservere
- Mange regionsservere
Regionsservere bidrager til at håndtere HBase-tabellerne. Fordi HBase-tabeller kan være store, er de opdelt i partitioner kaldet regioner. Hver regionsserver håndterer en eller flere af disse regioner. Bemærk, at fordi regionsservere er de eneste servere, der betjener HBase-tabeldata, kan et masterservernedbrud ikke forårsage datatab.
HBase-data er organiseret på samme måde som et sorteret kort, hvor det sorterede nøglerum er opdelt i forskellige shards eller regioner. En HBase-klient opdaterer en tabel ved at påkalde put- eller delete-kommandoer. Når en klient anmoder om en ændring, bliver anmodningen som standard dirigeret til en regionsserver med det samme. Programmæssigt kan en klient dog cache ændringerne på klientsiden og tømme disse ændringer til regionsservere i en batch ved at slå autoflush fra. Hvis autoflush er slået fra, cachelagres ændringerne, indtil flush-commits aktiveres, eller bufferen er fuld afhængigt af bufferstørrelsen indstillet programmatisk eller konfigureret med parameteren "hbase.client.write.buffer".
Da rækkenøglen er sorteret, er det nemt at bestemme, hvilken regionsserver der administrerer hvilken nøgle. En ændringsanmodning er for en bestemt række. Hver rækkenøgle tilhører en bestemt region, som betjenes af en regionsserver. Så baseret på put- eller delete-nøglen kan en HBase-klient finde en korrekt regionsserver. Først finder den adressen på regionsserveren, der hoster -ROOT- regionen, fra ZooKeeper-kvorummet. Fra rodregionsserveren finder klienten ud af placeringen af regionsserveren, der hoster -META- regionen. Fra metaregionsserveren finder vi endelig den faktiske regionserver, som betjener den anmodede region. Dette er en proces i tre trin, så regionsplaceringen er cachelagret for at undgå denne dyre række af operationer. Hvis den cachelagrede placering er ugyldig (f.eks. får vi en ukendt regionundtagelse), er det tid til at genfinde regionen og opdatere cachen.
Efter anmodningen er modtaget af den rigtige regionsserver, kan ændringen ikke skrives til en HF-fil med det samme, fordi dataene i en HF-fil skal sorteres efter rækkenøglen. Dette gør det muligt at søge efter tilfældige rækker effektivt, når dataene læses. Data kan ikke indsættes tilfældigt i HF-filen. Ændringen skal i stedet skrives til en ny fil. Hvis hver opdatering blev skrevet til en fil, ville der blive oprettet mange små filer. En sådan løsning ville ikke være skalerbar eller effektiv at flette eller læse på et senere tidspunkt. Derfor skrives ændringer ikke umiddelbart til en ny HF-fil.
I stedet bliver hver ændring gemt på et sted i hukommelsen kaldet memstore , som billigt og effektivt understøtter tilfældige skrivninger. Data i memstore sorteres på samme måde som data i en HF-fil. Når memstore akkumulerer nok data, skrives hele det sorterede sæt til en ny HF-fil i HDFS. At fuldføre én stor skriveopgave er effektivt og udnytter HDFS’ styrker.
Selvom det er effektivt at skrive data til memstore, introducerer det også et element af risiko:Information gemt i memstore er lagret i flygtig hukommelse, så hvis systemet svigter, går al memstore information tabt. For at hjælpe med at mindske denne risiko gemmer HBase opdateringer i en write-ahead-log (WAL ), før du skriver oplysningerne til memstore. På denne måde, hvis en regionsserver svigter, kan information, der blev gemt i den pågældende servers memstore, gendannes fra dens WAL.
Bemærk:Som standard er WAL aktiveret, men processen med at skrive WAL-filen til disken bruger nogle ressourcer. WAL kan være deaktiveret, men dette bør kun gøres, hvis risikoen for tab af data ikke er et problem. Hvis du vælger at deaktivere WAL, kan du overveje at implementere din egen disaster recovery-løsning eller være forberedt på muligheden for datatab.
Dataene i en WAL-fil er organiseret anderledes end HFile. WAL-filer indeholder en liste over redigeringer, hvor en redigering repræsenterer en enkelt put eller sletning. Redigeringen indeholder oplysninger om ændringen og den region, som ændringen gælder for. Redigeringer skrives kronologisk, så for at blive ved med at tilføje tilføjelser til slutningen af WAL-filen, der er gemt på disken. Fordi WAL-filer er ordnet kronologisk, er der aldrig behov for at skrive til et tilfældigt sted i filen.
Efterhånden som WAL'er vokser, lukkes de til sidst, og en ny, aktiv WAL-fil oprettes for at acceptere yderligere redigeringer. Dette kaldes at "rulle" WAL-filen. Når en WAL-fil er rullet, foretages der ingen yderligere ændringer i den gamle fil.
Som standard rulles WAL-filen, når dens størrelse er omkring 95 % af HDFS-blokstørrelsen. Du kan konfigurere multiplikatoren ved hjælp af parameteren:"hbase.regionserver.logroll.multiplier", og blokstørrelsen ved hjælp af parameteren:"hbase.regionserver.hlog.blocksize". WAL-fil rulles også periodisk baseret på det konfigurerede interval "hbase.regionserver.logroll.period", en time som standard, selv WAL-filstørrelsen er mindre end den konfigurerede grænse.
Begrænsning af WAL-filstørrelsen letter effektiv filgenafspilning, hvis en gendannelse er påkrævet. Dette er især vigtigt under genafspilning af en regions WAL-fil, fordi mens en fil afspilles igen, er den tilsvarende region ikke tilgængelig. Hensigten er til sidst at skrive alle ændringer fra hver WAL-fil til disk og bevare det indhold i en HF-fil. Når dette er gjort, kan WAL-filen arkiveres, og den bliver til sidst slettet af LogCleaner-dæmontråden. Bemærk, at WAL-filer tjener som en beskyttelsesforanstaltning. WAL-filer skal kun afspilles igen for at gendanne opdateringer, der ellers ville gå tabt efter et regionsservernedbrud.
En regionsserver betjener mange regioner, men har ikke en WAL-fil for hver region. I stedet deles én aktiv WAL-fil mellem alle regioner, der betjenes af regionsserveren. Fordi WAL-filer rulles med jævne mellemrum, kan én regionsserver have mange WAL-filer. Bemærk, at der kun er én aktiv WAL pr. regionsserver på et givet tidspunkt.
Forudsat at standard-HBase-roden til "/hbase", er alle WAL-filerne for en regionsserverforekomst gemt under den samme rodmappe, som er som følger:
/hbase/.logs/<host>, <port>,<startcode>
For eksempel:
/hbase/.logs/srv.example.com,60020,1254173957298
WAL-logfiler er navngivet som følger:
/hbase/.logs/<host>, <port>,<startcode>/<host>%2C <port>%2C<startcode>.<timestamp>
For eksempel:
/hbase/.logs/srv.example.com,60020,1254173957298/srv.example.com%2C60020%2C1254173957298.1254173957495
Hver redigering i WAL-filen har et unikt sekvens-id. Dette id øges for at bevare rækkefølgen af redigeringer. Hver gang en logfil rulles, lægges det næste sekvens-id og det gamle filnavn i et kort i hukommelsen. Disse oplysninger bruges til at spore det maksimale sekvens-id for hver WAL-fil, så vi nemt kan finde ud af, om en fil kan arkiveres på et senere tidspunkt, når et memlager tømmes til disken.
Redigeringer og deres sekvens-id er unikke inden for en region. Hver gang en redigering tilføjes til WAL-loggen, registreres redigeringens sekvens-id også som det sidste sekvens-id, der er skrevet. Når memstore tømmes til disken, ryddes den sidste sekvens-id, der er skrevet for denne region. Hvis det sidste sekvens-id, der er skrevet til disken, er det samme som det maksimale sekvens-id for en WAL-fil, kan det konkluderes, at alle redigeringer i en WAL-fil for denne region er blevet skrevet til disken. Hvis alle redigeringer for alle områder i en WAL-fil er blevet skrevet til disken, er det klart, at der ikke kræves nogen opdeling eller genafspilning, og WAL-filen kan arkiveres.
WAL file rolling og memstore flush er to separate handlinger og behøver ikke at ske sammen. Vi ønsker dog ikke at beholde for mange WAL-filer pr. regionsserver for at undgå tidskrævende gendannelse i tilfælde af, at en regionsserverfejler. Derfor, når en WAL-fil rulles, tjekker HBase, om der er for mange WAL-filer, og beslutter, hvilke områder der skal tømmes, så nogle WAL-filer kan arkiveres.
I dette indlæg forklarer vi HBase skrivestien, som er hvordan data i HBase oprettes og/eller opdateres. Nogle vigtige dele af det er:
- Hvordan en klient lokaliserer en regionsserver,
- Memstore, der understøtter hurtig tilfældig skrivning,
- WAL-filer som måden at undgå datatab i tilfælde af regionsserverfejl.
Vi vil tale om HFile-formater, WAL-filopdeling og så videre i efterfølgende indlæg.