Som vi nevnte i vår HBase er en viktig del av Hadoop-økosystemet. Så nå vil jeg ta deg gjennom HBase-opplæringen, hvor jeg vil introdusere deg for Apache HBase, og deretter vil vi gå gjennom Facebook Messenger-saksstudien. Vi skal dekke følgende emner i denne HBase-opplæringsbloggen:
forklar mvc-arkitektur i java med eksempel
- Historien om Apache HBase
- Introduksjon av Apache HBase
- NoSQL-databaser og dens typer
- HBase vs Cassandra
- Apache HBase-funksjoner
- HBase vs HDFS
- Facebook Messenger casestudie
Apache HBase-opplæring: Historie
La oss starte med historien til HBase og vite hvordan HBase har utviklet seg over en periode.
- Apache HBase er modellert etter Googles BigTable, som brukes til å samle inn data og servere forespørsel om forskjellige Google-tjenester som Maps, Finance, Earth etc.
- Apache HBase startet som et prosjekt av selskapet Powerset for Natural Language Search, som håndterte massive og sparsomme datasett.
- Apache HBase ble først utgitt i februar 2007. Senere i januar 2008 ble HBase et delprosjekt av Apache Hadoop.
- I 2010 ble HBase Apache sitt toppnivåprosjekt.
HBase-veiledning | NoSQL-databaser | Edureka
Etter å ha kjent om historien til Apache HBase, ville du være nysgjerrig på å vite hva som er Apache HBase? La oss gå videre og ta en titt.
Apache HBase Tutorial: Introduksjon til HBase
HBase er en åpen kildekode, flerdimensjonal, distribuert, skalerbar og en NoSQL-database skrevet på Java. HBase løper på toppen av HDFS (Hadoop Distribuert Filsystem) og gir BigTable-lignende funksjoner til Hadoop. Den er designet for å gi en feiltolerant måte å lagre stor samling av sparsomme datasett på.
Siden oppnår HBase høy gjennomstrømning og lav ventetid ved å gi raskere lese- / skrivetilgang på store datasett. Derfor er HBase valget for applikasjoner som krever rask og tilfeldig tilgang til store mengder data.
Det gir komprimering, operasjoner i minnet og Bloom-filtre (datastruktur som forteller om en verdi er tilstede i et sett eller ikke) for å oppfylle kravet til raske og tilfeldige lese-skrivinger.
La oss forstå det gjennom et eksempel: En jetmotor genererer forskjellige typer data fra forskjellige sensorer som trykksensor, temperatursensor, hastighetssensor osv. Som indikerer motorens helse. Dette er veldig nyttig for å forstå problemene og statusen til flyet. Kontinuerlig motoroperasjon genererer 500 GB data per flytur, og det er omtrent 300 tusen flyreiser per dag. Så, Engine Analytics som brukes på slike data i nær sanntid, kan brukes til å proaktivt diagnostisere problemer og redusere uplanlagt nedetid. Dette krever et distribuert miljø å lagre store mengder data med raskt tilfeldig leser og skriver for sanntidsbehandling. Her kommer HBase for redning. Jeg vil snakke om HBase Les og skriv i detalj i min neste blogg på HBase Arkitektur .
Som vi vet er HBase en NoSQL-database. Så før vi forstår mer om HBase, kan vi først diskutere om NoSQL-databasene og dens typer.
Apache HBase-veiledning: NoSQL-databaser
NoSQL betyr Ikke bare SQL . NoSQL-databaser er modellert på en måte som kan representere andre data enn tabellformater, ukjente relasjonsdatabaser. Den bruker forskjellige formater for å representere data i databaser, og det er derfor forskjellige typer NoSQL-databaser basert på deres representasjonsformat. De fleste av NoSQL-databaser utnytter tilgjengelighet og hastighet over konsistens. La oss nå gå videre og forstå om de forskjellige typene NoSQL-databaser og deres representasjonsformater.
Key-Value butikker:
Det er en skjemafri database som inneholder nøkler og verdier. Hver nøkkel, peker på en verdi som er en rekke byte, kan være en streng, BLOB, XML, etc. f.eks. Lamborghini er en nøkkel og kan peke på en verdi Gallardo, Aventador, Murciélago, Reventón, Diablo, Huracán, Veneno, Centenario etc.
Key-Value lagrer databaser: Aerospike, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB.
Brukstilfelle
Nøkkelverdilagre håndterer størrelse godt og er gode til å behandle en konstant strøm av lese / skrive-operasjoner med lav ventetid. Dette gjør dem perfekte forBrukerpreferanse og profilbutikker,Produktanbefalinger de siste artiklene som vises på forhandlerens nettsted for å fremme fremtidige kundeproduktanbefalinger,Annonseservicering av kundens shoppingvaner resulterer i tilpassede annonser, kuponger osv. For hver kunde i sanntid.
Dokumentorientert :
Den følger det samme nøkkelverdiparet, men det er semi-strukturert som XML, JSON, BSON. Disse strukturene betraktes som dokumenter.
Dokumentbaserte databaser: Apache CouchDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB.
Brukssak
Siden dokumentet støtter fleksibelt skjema, gjør hurtiglesing og partisjonering det egnet for å opprette brukerdatabaser i forskjellige tjenester som twitter, e-handelsnettsteder etc.
Kolonneorientert:
I denne databasen lagres data i celle gruppert i kolonne i stedet for rader. Kolonner er logisk gruppert i kolonnefamilier som enten kan opprettes under skjemadefinisjon eller ved kjøretid.
Disse typer databaser lagrer all cellen som tilsvarer en kolonne som kontinuerlig diskoppføring, og gjør tilgang og søk mye raskere.
Kolonnebaserte databaser: HBase, Accumulo, Cassandra, Druid, Vertica.
Brukssak
Den støtter den enorme lagringsplassen og gir raskere lesetilgangstilgang over den. Dette gjør kolonneorienterte databaser egnet for lagring av kundeatferd på e-handelsnettsted, finansielle systemer som Google Finance og aksjemarkedsdata, Google maps etc.
Graforientert:
Det er en perfekt fleksibel grafisk fremstilling, brukt i motsetning til SQL. Disse typer databaser løser enkelt adresserbarhetsproblemer, da den inneholder kanter og knuter som kan utvides i henhold til kravene.
Grafbaserte databaser: AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso, Stardog.
Brukstilfelle
Dette brukes i utgangspunktet i svindeloppdagelse, sanntidsanbefalingsmotorer (i de fleste tilfeller e-handel), hoveddatahåndtering (MDM), nettverks- og IT-drift, identitets- og tilgangsstyring (IAM), etc.
HBase og Cassandra er de to berømte kolonneorienterte databasene. Så snakk det nå til et høyere nivå, la oss sammenligne og forstå de arkitektoniske og arbeidsforskjellene mellom HBase og Cassandra.
HBase Tutorial: HBase VS Cassandra
- HBase er modellert på BigTable (Google) mens Cassandra er basert på DynamoDB (Amazon) som opprinnelig ble utviklet av Facebook.
- HBase utnytter Hadoop-infrastruktur (HDFS, ZooKeeper) mens Cassandra utviklet seg separat, men du kan kombinere Hadoop og Cassandra i henhold til dine behov.
- HBase har flere komponenter som kommuniserer sammen som HBase HMaster, ZooKeeper, NameNode, Region Severs. Mens Cassandra er en enkelt nodetype, der alle noder er like og utfører alle funksjoner. Enhver node kan være koordinator dette fjerner enkelt feilpunkt.
- HBase er optimalisert for lesing og støtter enkel skriving, noe som fører til streng konsistens. HBase støtter Range-baserte skanninger, noe som gjør skanneprosessen raskere. Mens Cassandra støtter enkel radavlesning som opprettholder eventuell konsistens.
- Cassandra støtter ikke rekkebaserte radskanninger, noe som reduserer skanneprosessen sammenlignet med HBase.
- HBase støtter bestilt partisjonering, der rader i en kolonnefamilie er lagret i RowKey-rekkefølge, mens bestilt partisjonering i Casandra er en utfordring. På grunn av RowKey er partisjonering skanningsprosessen raskere i HBase sammenlignet med Cassandra.
- HBase støtter ikke lese belastningsbalansering, en regionserver serverer leseforespørselen, og replikaene brukes bare i tilfelle feil. Mens Cassandra støtter lese belastningsbalansering og kan lese de samme dataene fra forskjellige noder. Dette kan kompromittere konsistensen.
- I CAP (konsistens, tilgjengelighet og partisjonstoleranse) opprettholder setning HBase konsistens og tilgjengelighet mens Cassandra fokuserer på tilgjengelighet og partisjonstoleranse.
La oss nå ta et dypdykk og forstå funksjonene til Apache HBase som gjør det så populært.
Apache HBase Tutorial: Funksjoner av HBase
- Atomic lese og skrive: På radnivå gir HBase atom- lesing og skriving. Det kan forklares som, under en lese- eller skriveprosess, er alle andre prosesser forhindret i å utføre noen lese- eller skriveoperasjoner.
- Konsekvent leser og skriver: HBase gir jevnlig lesing og skriving på grunn av funksjonen ovenfor.
- Lineær og modulær skalerbarhet: Ettersom datasett er distribuert over HDFS, er det således skalerbart lineært på tvers av forskjellige noder, så vel som modulært skalerbart, da det er delt på tvers av forskjellige noder.
- Automatisk og konfigurerbar skjæring av tabeller: HBase-tabeller er fordelt på klynger, og disse klyngene er fordelt på regioner. Disse regionene og klyngene splittes, og fordeles om etter hvert som dataene vokser.
- Enkel å bruke Java API for klienttilgang: Det gir brukervennlig Java API for programmatisk tilgang.
- Nyttig gateway og en REST-full nettjeneste: Den støtter også Thrift og REST API for ikke-Java-grensesnitt.
- Blokker cache- og blomstringsfiltre: HBase støtter en Block Cache og Bloom Filters for optimalisering av spørringsoppgaver med høyt volum.
- Automatisk feilstøtte: HBase med HDFS gir WAL (Write Ahead Log) på tvers av klynger som gir automatisk feilstøtte.
- Sorterte radtaster: Ettersom det blir søkt på radrekke, lagrer HBase radetaster i leksikografisk rekkefølge. Ved å bruke disse sorterte råtastene og tidsstempelet kan vi lage en optimalisert forespørsel.
Nå går vi videre i denne HBase-opplæringen, la meg fortelle deg hva som er brukstilfellene og scenariene der HBase kan brukes, og deretter vil jeg sammenligne HDFS og HBase.
Jeg ønsker å rette oppmerksomheten mot scenariene der HBase passer best.
HBase Tutorial: Hvor kan vi bruke HBase?
- Vi bør bruke HBase der vi har store datasett (millioner eller milliarder eller rader og kolonner) og vi krever rask, tilfeldig og sanntid, lese- og skrivetilgang over dataene.
- Datasettene er fordelt på forskjellige klynger, og vi trenger høy skalerbarhet for å håndtere data.
- Dataene er samlet fra forskjellige datakilder, og det er enten semistrukturerte eller ustrukturerte data eller en kombinasjon av alle. Det kan håndteres enkelt med HBase.
- Du vil lagre kolonneorientert data.
- Du har mange versjoner av datasettene, og du må lagre dem alle.
Før jeg hopper til Facebook messenger case study,la meg fortelle deg hva som er forskjellene mellom HBase og HDFS.
HBase Tutorial: HBase VS HDFS
HDFS er et Java-basert distribuert filsystem som lar deg lagre store data på tvers av flere noder i en Hadoop-klynge. Så, HDFS er et underliggende lagringssystem for lagring av dataene i det distribuerte miljøet. HDFS er et filsystem, mens HBase er en database (ligner på NTFS og MySQL).
Ettersom både HDFS og HBase lagrer alle slags data (dvs. strukturert, semi-strukturert og ustrukturert) i et distribuert miljø, kan vi se på forskjellene mellom HDFS-filsystem og HBase, en NoSQL-database.
- HBase gir lav latens tilgang til små datamengder i store datasett mens HDFS gir operasjoner med høy latens.
- HBase støtter tilfeldig lesing og skriver mens HDFS støtter WORM (Skriv en gang Les mange eller flere ganger).
- HDFS er i utgangspunktet eller primært tilgjengelig via MapReduce-jobber mens HBase er tilgjengelig via skallkommandoer, Java API, REST, Avro eller Thrift API.
HDFS lagrer store datasett i et distribuert miljø og utnytter batchbehandling på disse dataene. F.eks. det vil hjelpe et e-handelsnettsted å lagre millioner av kundedata i et distribuert miljø som vokste over lang tid (kan være 4-5 år eller mer). Deretter utnytter den batchbehandling over disse dataene og analyserer kundeatferd, mønster, krav. Da kunne selskapet finne ut hvilken type produkt, kundekjøp i hvilke måneder. Det hjelper å lagre arkiverte data og utføre batchbehandling over dem.
Mens HBase lagrer data på en kolonneorientert måte der hver kolonne lagres sammen slik at lesing blir raskere ved å utnytte sanntidsbehandling. F.eks. i et lignende e-handelsmiljø lagrer den millioner av produktdata. Så hvis du søker etter et produkt blant millioner av produkter, optimaliserer det forespørselen og søkeprosessen, og produserer resultatet umiddelbart (eller du kan si det i sanntid). Detaljert HBase arkitektoniske forklaring , Vil jeg dekke i neste blogg.
Som vi vet er HBase distribuert over HDFS, så en kombinasjon av begge gir oss en flott mulighet til å bruke fordelene med begge deler, i en skreddersydd løsning, som vi kommer til å se i casestudien nedenfor om Facebook messenger.
HBase Tutorial: Facebook Messenger Case Study
Facebook Meldingsplattform flyttet fra Apache Cassandra til HBase i november 2010.
Facebook Messenger kombinerer meldinger, e-post, chat og SMS i en sanntidssamtale. Facebook prøvde å bygge en skalerbar og robust infrastruktur for å håndtere settet med disse tjenestene.
På den tiden håndterte meldingsinfrastrukturen over 350 millioner brukere som sendte over 15 milliarder person-til-person-meldinger per måned. Chat-tjenesten støtter over 300 millioner brukere som sender over 120 milliarder meldinger per måned.
Ved å overvåke bruken fant de ut at to generelle datamønstre dukket opp:
servicenow tutorial for nybegynnere pdf
- Et kort sett med tidsdata som har en tendens til å være ustabilt
- Et stadig voksende datasett som sjelden får tilgang til
Facebook ønsket å finne en lagringsløsning for disse to bruksmønstrene, og de begynte å undersøke for å finne en erstatning for eksisterende Messages-infrastruktur.
Tidligere i 2008 brukte de åpen kildekode-database, dvs. Cassandra, som er en eventuell konsistens nøkkelverdilager som allerede var i produksjon som serverte trafikk for Inbox Search. Teamene deres hadde stor kunnskap om bruk og administrering av en MySQL-database, så bytte av en av teknologiene var en alvorlig bekymring for dem.
De brukte noen uker på å teste forskjellige rammer for å evaluere klyngene til MySQL, Apache Cassandra, Apache HBase og andre systemer. De valgte til slutt HBase.
Da MySQL ikke klarte å håndtere de store datasettene effektivt, ettersom indeksene og datasettene ble store, led ytelsen. De fant Cassandra ikke i stand til å håndtere vanskelige mønstre for å forene deres nye Messages-infrastruktur.
De største problemene var:
- Lagring av store sett med kontinuerlig voksende data fra forskjellige Facebook-tjenester.
- Krever database som kan utnytte høy prosessering på den.
- Høy ytelse er nødvendig for å betjene millioner av forespørsler.
- Opprettholde konsistens i lagring og ytelse.
Figur: Utfordringer Facebook messenger står overfor
For alle disse problemene kom Facebook med en løsning, dvs. HBase. Facebook vedtok HBase for å betjene Facebook messenger, chat, e-post, etc. på grunn av dets forskjellige funksjoner.
HBase kommer med veldig god skalerbarhet og ytelse for denne arbeidsmengden med en enklere konsistensmodell enn Cassandra. Mens de fant HBase å være den mest passende når det gjelder deres krav som automatisk belastningsbalansering og failover, komprimeringsstøtte, flere skjær per server, etc.
HDFS, som er det underliggende filsystemet som brukes av HBase, ga dem også flere nødvendige funksjoner som end-to-end-kontrollsummer, replikering og automatisk belastningsrebalansering.
Figur: HBase som en løsning på Facebook messenger
Da de adopterte HBase, fokuserte de også på å overføre resultatene til HBase selv og begynte å jobbe tett med Apache-samfunnet.
Siden meldinger godtar data fra forskjellige kilder, for eksempel SMS, chatter og e-post, skrev de en applikasjonsserver for å håndtere all beslutningstaking for brukerens melding. Det grensesnitt med et stort antall andre tjenester. Vedleggene lagres i en Haystack (som fungerer på HBase). De skrev også en brukeroppdagelsestjeneste på toppen av Apache ZooKeeper som snakket med andre infrastrukturtjenester for venneforhold, bekreftelse av e-postkontoer, leveringsbeslutninger og personvernbeslutninger.
Facebook-teamet brukte mye tid på å bekrefte at hver av disse tjenestene er robuste, pålitelige og gir god ytelse for å håndtere et sanntids meldingssystem.
Jeg håper denne HBase-opplæringsbloggen er informativ og du likte den. I denne bloggen ble du kjent med det grunnleggende om HBase og dets funksjoner.I min neste blogg av , Jeg skal forklare arkitekturen til HBase og bearbeiding av HBase som gjør den populær for rask og tilfeldig lese / skrive.
Nå som du har forstått det grunnleggende om HBase, sjekk ut av Edureka, et pålitelig online læringsfirma med et nettverk av mer enn 250 000 fornøyde elever spredt over hele verden. Edureka Big Data Hadoop-sertifiseringstreningskurs hjelper elever å bli eksperter på HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved å bruke sanntidsbruk på Retail, Social Media, Aviation, Tourism, Finance.
Har du et spørsmål til oss? Vennligst nevn det i kommentarfeltet, så kommer vi tilbake til deg.