en enkel introduksjon til datavitenskap
La oss i dagens innlegg diskutere om HBase Architecture. La oss pusse opp det grunnleggende om HBase før vi går dypere inn i HBase-arkitekturen.
HBase - det grunnleggende:
HBase er en åpen kildekode, NoSQL, distribuert, ikke-relasjonell, versjonert, flerdimensjonal, kolonneorientert butikk som er modellert etter Google BigTable som kjører på toppen av HDFS. '' NoSQL 'er et bredt begrep som betyr at databasen ikke er en RDBMS som støtter SQL som sitt primære tilgangsspråk. Men det finnes mange typer NoSQL-databaser, og Berkeley DB er et godt eksempel på en lokal NoSQL-database, mens HBase er veldig mye en distribuert database.
HBase tilbyr alle funksjonene i Google BigTable. Det begynte som et prosjekt av Powerset for å behandle store mengder data for naturlig språksøk. Den ble utviklet som en del av Apache’s Hadoop-prosjekt og kjører på toppen av HDFS (Hadoop Distributed File System). Det gir feiltolerante måter å lagre store mengder sparsomme data på. HBase er egentlig mer en 'Data Store' enn 'Data Base' fordi den mangler mange av funksjonene som er tilgjengelige i RDBMS, for eksempel maskinskrevne kolonner, sekundære indekser, utløsere og avanserte spørrespråk, etc.
I kolonneorienterte databaser lagres datatabellen som seksjoner av kolonner med data i stedet for som datarader. Datamodellen for kolonneorientert database består av tabellnavn, radnøkkel, kolonnefamilie, kolonner, tidsstempel. Mens du oppretter tabeller i HBase, blir radene unikt identifisert ved hjelp av radnøkler og tidsstempel. I denne datamodellen er kolonnefamilien statisk, mens kolonnene er dynamiske. La oss nå se på HBase Architecture.
Når skal jeg gå for HBase?
HBase er bare et godt alternativ når det er hundrevis av millioner eller milliarder rader. HBase kan også brukes steder når man vurderer å flytte fra en RDBMS til HBase som et komplett redesign i motsetning til en port. Med andre ord er HBase ikke optimalisert for klassiske transaksjonsapplikasjoner eller til og med relasjonsanalyse. Det er heller ikke en fullstendig erstatning for HDFS når du gjør stor batch MapReduce. Så hvorfor skal du gå for HBase ?? Hvis søknaden din har et variabelt skjema der hver rad er litt annerledes, bør du se på HBase.
HBase-arkitektur:
Følgende figur forklarer klart HBase Architecture.
hva som er forbigående i java
I HBase er det tre hovedkomponenter: Master, Region server og Zoo keeper . De andre komponentene er Memstore, HFile og WAL.
Ettersom HBase kjører på toppen av HDFS, benytter den Master-Slave-arkitekturen der HMaster vil være masternoden og Region-serverne er slaveknutepunktene. Når klienten sender en skriveforespørsel, mottar HMaster den forespørselen og videresender den til den respektive Region Server.
Region Server:
Det er et system som fungerer på samme måte som en datanode. Når Region Server (RS) mottar skriveforespørsel, retter den forespørselen til spesifikk region. Hver region lagrer sett med rader. Raddata kan skilles i flere kolonnefamilier (CF). Data om bestemt CF lagres i HStore som består av Memstore og et sett med HFiles.
Hva gjør Memstore?
Memstore holder oversikt over alle loggene for lese- og skriveoperasjonene som er utført innenfor den aktuelle regionserveren. Fra dette kan vi si at det virker som en navne node i Hadoop. Memstore er en lagring i minnet, derfor bruker Memstore lagring i minnet til hver datanode for å lagre loggene. Når visse terskler blir oppfylt, skylles Memstore-dataene inn i HFile.
Hovedformålet med bruk av Memstore er behovet for å lagre data på DFS bestilt etter radnøkkel. Ettersom HDFS er designet for sekvensiell lesing / skriving, uten at filendringer er tillatt, kan HBase ikke effektivt skrive data til disken mens de mottas: de skriftlige dataene blir ikke sortert (når inngangen ikke er sortert), noe som betyr at den ikke er optimalisert for fremtiden gjenfinning. For å løse dette problemet mottok HBase-buffere sist data i minnet (i Memstore), 'sorterer' det før de skylles, og skriver deretter til HDFS ved hjelp av raske sekvensielle skrivinger. Derfor inneholder HFile en liste over sorterte rader.
Hver gang Memstore flush skjer, blir det opprettet en HFile for hver CF, og hyppige spylinger kan skape tonnevis av HFiles. Siden HBase under lesing må se på mange HFiler, kan lesehastigheten lide. For å forhindre åpning av for mange HFiles og unngå forverring av leseytelse, brukes HFiles komprimeringsprosess. HBase vil med jevne mellomrom (når visse konfigurerbare terskler oppfylles) komprimere flere mindre HFiles til en stor. Jo flere filer opprettet av Memstore skyller, jo mer arbeid (ekstra belastning) for systemet. Lagt til det, mens komprimeringsprosessen vanligvis utføres parallelt med å betjene andre forespørsler, og når HBase ikke kan følge med på komprimering av HFiles (ja, det er konfigurerte terskler for det også), vil den blokkere skriver på RS igjen. Som vi diskuterte ovenfor, er dette svært uønsket.
Vi kan ikke være sikre på at dataene vil være vedvarende i Memstore. Anta at en bestemt datanode er nede. Da vil dataene som ligger i minnet til datanoden gå tapt.
For å løse dette problemet, når forespørselen kommer fra mesteren, skrev den også til WAL. WAL er ingenting annet enn Skriv frem logger som ligger på HDFS, en permanent lagring. Nå kan vi sørge for at dataene ikke vil gå tapt, selv om datanoden er nede. vi har kopien av alle handlingene du skal gjøre i WAL. Når datanoden er oppe, vil den utføre alle aktivitetene igjen. Når operasjonen er fullført, skylles alt ut fra Memstore og WAL og skrives i HFile for å sikre at vi ikke går tom for minne.
La oss ta et enkelt eksempel på at jeg vil legge til rad 10 så kommer skriveforespørselen inn, det står at den gir alle metadataene til Memstore og WAL. Når den aktuelle raden er skrevet inn i HFile, skylles alt i Memstore og WAL ut.
Dyrepasser:
HBase leveres integrert med Zoo keeper. Når jeg starter HBase, blir også Zoo keeper instans startet. Årsaken er at dyrehageholderen hjelper oss med å holde oversikt over alle regionserverne som er der for HBase. Zoo keeper holder oversikt over hvor mange regionservere som er der, hvilke regionservere som holder fra hvilken datanode til hvilken datanode. Den holder rede på mindre datasett der Hadoop går glipp av. Det reduserer overhead på toppen av Hadoop som holder oversikt over de fleste Meta-dataene dine. Derfor får HMaster detaljene til regionserverne ved å kontakte Zoo keeper.
Har du spørsmål til oss? Nevn dem i kommentarfeltet, så kommer vi tilbake til deg.
avslutter et program i java
Relaterte innlegg: