I del 1 af denne serie om Apache HBase-snapshots lærte du, hvordan du bruger den nye Snapshots-funktion og lidt teori bag implementeringen. Nu er det tid til at dykke lidt dybere ned i de tekniske detaljer.
Hvad er en tabel?
En HBase-tabel omfatter et sæt metadataoplysninger og et sæt nøgle/værdi-par:
- Tabeloplysninger :En manifestfil, der beskriver tabellen "indstillinger", såsom kolonnefamilier, komprimerings- og kodningscodecs, bloom-filtertyper og så videre.
- Regioner :Tabellen "partitioner" kaldes regioner. Hver region er ansvarlig for at håndtere et sammenhængende sæt nøgle/værdier, og de er defineret af en startnøgle og en slutnøgle.
- WALs/MemStore :Før data skrives på disken, skrives puts til Write Ahead Log (WAL) og gemmes derefter i hukommelsen, indtil hukommelsestryk udløser en flush til disk. WAL giver en nem måde at gendanne puts, der ikke er skyllet til disk ved fejl.
- HFiler :På et tidspunkt skylles alle data til disken; en HFile er HBase-formatet, der indeholder den/de lagrede nøgle/værdier. HFiler er uforanderlige, men kan slettes ved komprimering eller regionsletning.
(Bemærk:For at lære mere om HBase Write Path, tag et kig på HBase Write Path blogindlægget.)
Hvad er et øjebliksbillede?
Et øjebliksbillede er et sæt metadataoplysninger, der gør det muligt for administratoren at vende tilbage til en tidligere tilstand af den tabel, den er taget på. Et øjebliksbillede er ikke en kopi af tabellen; den enkleste måde at tænke det på er som et sæt operationer for at holde styr på metadata (tabelinfo og regioner) og dataene (HF-filer, memstore, WAL'er). Ingen kopier af data er involveret under snapshot-operationen.
- Offlinesnapshots :Det enkleste tilfælde for at tage et øjebliksbillede er, når en tabel er deaktiveret. Deaktivering af en tabel betyder, at alle data tømmes på disken, og ingen skrivninger eller læsninger accepteres. I dette tilfælde er at tage et øjebliksbillede blot et spørgsmål om at gå gennem tabellens metadata og HFiles på disken og beholde en reference til dem. Masteren udfører denne operation, og den krævede tid bestemmes hovedsageligt af den tid, som HDFS-navnenoden kræver for at levere listen over filer.
- Onlinesnapshots :I de fleste situationer er tabeller dog aktiveret, og hver regionsserver håndterer put and get-anmodninger. I dette tilfælde modtager masteren snapshot-anmodningen og beder hver regionsserver om at tage et snapshot af de regioner, som den er ansvarlig for.
Kommunikationen mellem master- og regionserverne foregår via Apache ZooKeeper ved hjælp af en to-faset commit-lignende transaktion. Masteren opretter en znode, der betyder "forbered øjebliksbilledet". Hver regionsserver behandler anmodningen og forbereder et øjebliksbillede for regionerne fra den tabel, den er ansvarlig for. Når de er færdige, tilføjer de en undernode til forberedelsesanmodnings-znoden med betydningen "Jeg er færdig".
Når alle regionsservere har rapporteret deres status tilbage, opretter masteren en anden znode, der betyder "Bekræft snapshot"; hver regionsserver afslutter øjebliksbilledet og rapporterer status som før tilslutning til noden. Når alle regionsservere har rapporteret tilbage, færdiggør masteren snapshottet og markerer handlingen som afsluttet. I tilfælde af at en regionsserver rapporterer en fejl, vil masteren oprette en ny znode, der bruges til at udsende afbrydelsesmeddelelsen.
Da regionsserveren kontinuerligt behandler nye anmodninger, kan forskellige brugstilfælde kræve forskellige konsistensmodeller. For eksempel kan nogen være interesseret i et sjusket snapshot uden de nye data i MemStore, en anden vil måske have et fuldt konsistent snapshot, der kræver låsning af skrivninger i et stykke tid, og så videre.
Af denne grund kan proceduren til at tage et øjebliksbillede på regionsserveren tilsluttes. I øjeblikket er den eneste tilstedeværende implementering "Flush Snapshot", som udfører en flush, før du tager et øjebliksbillede og garanterer kun rækkekonsistens. Andre procedurer med andre konsistenspolitikker kan blive implementeret i fremtiden.
I onlinetilfældet er den tid, der kræves for at tage et snapshot, begrænset af den tid, der kræves af den langsomste regionsserver til at udføre snapshot-operationen og rapportere succes tilbage til masteren. Denne handling er normalt i størrelsesordenen nogle få sekunder.
Arkivering
Som vi har set før, er HFiles uforanderlige. Dette giver os mulighed for at undgå at kopiere dataene under snapshot- eller klonoperationerne, men under komprimering fjernes de og erstattes af en komprimeret version. I dette tilfælde, hvis du har et snapshot eller en klonet tabel, der refererer til en af disse filer, flyttes de til en "arkiv"-placering i stedet for at slette dem. Hvis du sletter et snapshot, og ingen andre refererer til filerne, som snapshottet refererer til, slettes disse filer.
Kloning og gendannelse af tabeller
Snapshots kan ses som en backup-løsning, hvor de kan bruges til at gendanne/gendanne en tabel efter en bruger- eller applikationsfejl, men snapshot-funktionen kan tillade meget mere end en simpel backup-og-gendannelse. Efter at have klonet en tabel fra et øjebliksbillede, kan du skrive et MapReduce-job eller en simpel applikation for selektivt at flette forskellene, eller hvad du synes er vigtigt, til produktion. En anden anvendelse er, at du kan teste skemaændringer eller opdateringer af dataene uden at skulle vente timer på en tabelkopi og uden at ende med en masse data duplikeret på disken.
Klon en tabel fra et øjebliksbillede
Når en administrator udfører en kloningsoperation, oprettes en ny tabel med tabelskemaet til stede i snapshottet på forhånd med start/slut nøglerne i snapshot regions info. Når tabellens metadata er oprettet, bruges det samme trick som med snapshotet i stedet for at kopiere dataene ind. Da HFiles er uforanderlige, oprettes der kun en reference til kildefilen; dette gør det muligt for handlingen at undgå datakopier og tillader, at klonen kan redigeres uden at påvirke kildetabellen eller snapshottet. Kloningsoperationen udføres af masteren.
Gendan en tabel fra et øjebliksbillede
Gendannelsesoperationen ligner klonoperationen; du kan tænke på det som at slette bordet og klone det fra øjebliksbilledet. Gendannelsesoperationen bringer de gamle data tilbage i snapshottet og fjerner alle data fra tabellen, som ikke også er i snapshottet, og også tabellens skema vendes tilbage til snapshotets. Under hætten implementeres gendannelsen ved at lave en forskel mellem tabeltilstanden og snapshottet, fjerne filer, der ikke er til stede i snapshottet og tilføje referencer til dem i snapshottet, men ikke til stede i den aktuelle tilstand. Også tabelbeskrivelsen er modificeret, så den afspejler tabellens "skema" i øjebliksbilledet. Gendannelsen udføres af masteren, og tabellen skal deaktiveres.
Futures
I øjeblikket inkluderer snapshot-implementeringen al grundlæggende påkrævet funktionalitet. Som vi har set, kan nye snapshot-konsistenspolitikker for online-snapshots give mere fleksibilitet, konsistens eller ydeevneforbedringer. Bedre filhåndtering kan reducere belastningen på HDFS-navnenoden og forbedre diskpladsstyringen. Ydermere er metrics, Web UI (Hue) og mere på to-do-listen.
Konklusion
HBase-snapshots tilføjer ny funktionalitet, såsom "procedurekoordinering", der bruges af online-snapshot, eller kopier-på-skriv-snapshot, gendannelse og kloner.
Snapshots giver et hurtigere og bedre alternativ til håndlavede "backup" og "kloning" løsninger baseret på distcp eller CopyTable. Alle snapshot-handlinger (snapshot, gendannelse, kloning) involverer ikke datakopier, hvilket resulterer i hurtigere snapshots af tabellen og besparelser på diskplads.
For mere information om, hvordan du aktiverer og bruger snapshots, henvises til HBase operational management doc.
Matteo Bertozzi er en softwareingeniør på platformsteamet og en HBase Committer.