HBase Tutorial: HBase Introduktion og Facebook Case Study

Som vi nævnte i vores blog, HBase er en vigtig del af vores Hadoop-økosystem. Så nu vil jeg gerne tage dig gennem HBase-tutorial, hvor jeg vil introducere dig til Apache HBase, og derefter vil vi gennemgå Facebook Messenger-casestudiet. Vi vil dække følgende emner i denne HBase tutorial blog:

• Apache HBase historie
• Introduktion af Apache HBase
• NoSQL-databaser og dens typer
• HBase vs Cassandra
• Apache HBase-funktioner
• HBase vs HDFS
• Facebook Messenger casestudie

Apache HBase Tutorial: Historie

Lad os starte med HBase-historien og vide, hvordan HBase har udviklet sig over en periode.

• Apache HBase er modelleret efter Googles BigTable, som bruges til at indsamle data og servere anmodning om forskellige Google-tjenester som Maps, Finance, Earth osv.
• Apache HBase startede som et projekt af firmaet Powerset for Natural Language Search, der håndterede massive og sparsomme datasæt.
• Apache HBase blev først frigivet i februar 2007. Senere i januar 2008 blev HBase et delprojekt af Apache Hadoop.
• I 2010 blev HBase Apache's projekt på øverste niveau.

HBase-vejledning | NoSQL-databaser | Edureka

Efter at have kendskab til Apache HBases historie, ville du være nysgerrig efter at vide, hvad der er Apache HBase? Lad os gå videre og kigge nærmere.

Apache HBase Tutorial: Introduktion til HBase

HBase er en open source, flerdimensionel, distribueret, skalerbar og en NoSQL-database skrevet på Java. HBase løber oven på HDFS (Hadoop Distribueret Filsystem) og leverer BigTable-lignende funktioner til Hadoop. Det er designet til at give en fejltolerant måde at lagre stor samling af sparsomme datasæt på.

Da HBase opnår høj gennemstrømning og lav latenstid ved at give hurtigere læse- / skriveadgang på enorme datasæt. Derfor er HBase valget for applikationer, der kræver hurtig og tilfældig adgang til store mængder data.

Det giver kompression, operationer i hukommelsen og Bloom-filtre (datastruktur, der fortæller, om en værdi er til stede i et sæt eller ej) for at opfylde kravet til hurtige og tilfældige læseskrivninger.

Lad os forstå det gennem et eksempel: En jetmotor genererer forskellige typer data fra forskellige sensorer som trykføler, temperaturføler, hastighedsføler osv., Som indikerer motorens helbred. Dette er meget nyttigt for at forstå flyvningens problemer og status. Kontinuerlig motoroperation genererer 500 GB data pr. Flyvning, og der er cirka 300 tusind flyvninger om dagen. Så Engine Analytics anvendt på sådanne data i næsten realtid kan bruges til proaktivt at diagnosticere problemer og reducere uplanlagt nedetid. Dette kræver et distribueret miljø til at gemme store mængder data med hurtig tilfældig læser og skriver til realtidsbehandling. Her kommer HBase til redning. Jeg vil tale om HBase Læs og skriv detaljeret i min næste blog på HBase-arkitektur .

Som vi ved, er HBase en NoSQL-database. Så før vi forstår mere om HBase, kan vi først diskutere om NoSQL-databaser og dens typer.

Apache HBase-tutorial: NoSQL-databaser

NoSQL betyder Ikke kun SQL . NoSQL-databaser er modelleret på en måde, så de kan repræsentere andre data end tabelformater, ukendte relationsdatabaser. Det bruger forskellige formater til at repræsentere data i databaser, og der er således forskellige typer NoSQL-databaser baseret på deres repræsentationsformat. De fleste af NoSQL-databaser udnytter tilgængelighed og hastighed i forhold til konsistens. Lad os nu gå videre og forstå de forskellige typer NoSQL-databaser og deres repræsentationsformater.

Key-Value butikker:

Det er en skemafri database, der indeholder nøgler og værdier. Hver nøgle peger på en værdi, der er en række bytes, kan være en streng, BLOB, XML osv. F.eks. Lamborghini er en nøgle og kan pege på en værdi Gallardo, Aventador, Murciélago, Reventón, Diablo, Huracán, Veneno, Centenario osv.

Key-Value gemmer databaser: Aerospike, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB.

Brugssag

Nøgleværdilagre håndterer størrelse godt og er gode til at behandle en konstant strøm af læse / skrive-operationer med lav latenstid. Dette gør dem perfekte tilBrugerpræference og profilbutikker,Produktanbefalinger Seneste varer set på en forhandlers websted for at skabe fremtidige kundeproduktanbefalingerAnnonceservicering af kundes shoppingvaner resulterer i tilpassede annoncer, kuponer osv. For hver kunde i realtid.

Dokumentorienteret :

Det følger det samme nøgleværdipar, men det er semi-struktureret som XML, JSON, BSON. Disse strukturer betragtes som dokumenter.

Dokumentbaserede databaser: Apache CouchDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB.

Brugssag

Da dokument understøtter fleksibelt skema, gør hurtiglæsning og partitionering det velegnet til oprettelse af brugerdatabaser i forskellige tjenester som twitter, e-handelswebsider osv.

Søjleorienteret:

I denne database gemmes data i celle grupperet i kolonne i stedet for rækker. Kolonner er logisk grupperet i kolonnefamilier, som enten kan oprettes under skemadefinition eller ved kørsel.

Disse typer databaser gemmer al den celle, der svarer til en kolonne, som kontinuerlig diskindgang, hvilket gør adgangen og søgningen meget hurtigere.

Søjlebaserede databaser: HBase, Accumulo, Cassandra, Druid, Vertica.

Brugssag

Det understøtter det enorme lager og giver hurtigere læseadgang over det. Dette gør kolonneorienterede databaser egnede til lagring af kundeadfærd på e-handelswebsite, finansielle systemer som Google Finance og aktiemarkedsdata, Google maps osv.

Graforienteret:

Det er en perfekt fleksibel grafisk repræsentation, der bruges i modsætning til SQL. Disse typer databaser løser let adresser skalerbarhedsproblemer, da de indeholder kanter og knuder, som kan udvides i henhold til kravene.

Grafbaserede databaser: AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso, Stardog.

Brugssag

Dette bruges grundlæggende i svindelregistrering, realtidsanbefalingsmotorer (i de fleste tilfælde e-handel), masterdatastyring (MDM), netværks- og it-operationer, identitets- og adgangsstyring (IAM) osv.

HBase og Cassandra er de to berømte kolonneorienterede databaser. Så nu taler vi det til et højere niveau, lad os sammenligne og forstå de arkitektoniske og arbejdsforskelle mellem HBase og Cassandra.

hvad er scipy i python

HBase Tutorial: HBase VS Cassandra

• HBase er modelleret på BigTable (Google), mens Cassandra er baseret på DynamoDB (Amazon), der oprindeligt blev udviklet af Facebook.
• HBase udnytter Hadoop-infrastruktur (HDFS, ZooKeeper), mens Cassandra udviklede sig separat, men du kan kombinere Hadoop og Cassandra efter dine behov.
• HBase har flere komponenter, der kommunikerer sammen som HBase HMaster, ZooKeeper, NameNode, Region Severs. Mens Cassandra er en enkelt nodetype, hvor alle noder er ens og udfører alle funktioner. Enhver knude kan være koordinator, dette fjerner enkelt fejlpunkt.
• HBase er optimeret til læsning og understøtter enkeltskrivninger, hvilket fører til streng konsistens. HBase understøtter Range-baserede scanninger, hvilket gør scanningen hurtigere. Mens Cassandra understøtter en række række læser, der opretholder en eventuel konsistens.
• Cassandra understøtter ikke rækkebaserede række scanninger, hvilket nedsætter scanningen i forhold til HBase.
• HBase understøtter ordnet partitionering, hvor rækker i en kolonnefamilie er gemt i RowKey-rækkefølge, mens ordnet partitionering i Casandra er en udfordring. På grund af RowKey er partitionering scanningsprocessen hurtigere i HBase sammenlignet med Cassandra.
• HBase understøtter ikke læsebelastningsbalancering, en regionserver serverer læseanmodningen, og replikerne bruges kun i tilfælde af fejl. Mens Cassandra understøtter læsningsbalancering og kan læse de samme data fra forskellige noder. Dette kan kompromittere konsistensen.
• I CAP (konsistens, tilgængelighed og partitionstolerance) opretholder sætning HBase konsistens og tilgængelighed, mens Cassandra fokuserer på tilgængelighed og partitionstolerance.

Lad os nu tage et dybt dyk og forstå funktionerne i Apache HBase, der gør det så populært.

Apache HBase Tutorial: Funktioner i HBase

• Atomic læse og skrive: På række niveau giver HBase atom- læsning og skrivning. Det kan forklares, da alle andre processer under en læse- eller skriveproces forhindres i at udføre nogen læse- eller skriveoperationer.
• Konsekvent læser og skriver: HBase giver konsekvent læsning og skrivning på grund af ovenstående funktion.
• Lineær og modulær skalerbarhed: Da datasæt fordeles over HDFS, er det således skalerbart lineært på tværs af forskellige noder såvel som modulært skalerbart, da det er opdelt på tværs af forskellige noder.
• Automatisk og konfigurerbar deling af tabeller: HBase-tabeller er fordelt på klynger, og disse klynger er fordelt på regioner. Disse regioner og klynger deles og fordeles igen, når dataene vokser.
• Let at bruge Java API til klientadgang: Det giver brugervenlig Java API til programmatisk adgang.
• Genbrugsgateway og en REST-fulde webtjeneste: Det understøtter også Thrift og REST API til ikke-Java-frontendere.
• Bloker cache- og blomstringsfiltre: HBase understøtter en Block Cache- og Bloom-filtre til optimering af forespørgsler med høj lydstyrke.
• Automatisk fejlsupport: HBase med HDFS leverer WAL (Write Ahead Log) på tværs af klynger, der giver automatisk fiaskostøtte.
• Sorterede piletaster: Da søgning sker på række af rækker, gemmer HBase række nøgler i en leksikografisk rækkefølge. Ved hjælp af disse sorterede rowkeys og tidsstempel kan vi oprette en optimeret anmodning.

Lad os nu fortælle dig, hvad der er brugssager og scenarier, hvor HBase kan bruges, og derefter vil jeg sammenligne HDFS og HBase.

Jeg vil gerne henlede opmærksomheden mod de scenarier, hvor HBase passer bedst.

HBase Tutorial: Hvor kan vi bruge HBase?

• Vi skal bruge HBase, hvor vi har store datasæt (millioner eller milliarder eller rækker og kolonner), og vi kræver hurtig, tilfældig og realtid, læse- og skriveadgang over dataene.
• Datasættene er fordelt på forskellige klynger, og vi har brug for høj skalerbarhed for at håndtere data.
• Dataene indsamles fra forskellige datakilder, og det er enten semistrukturerede eller ustrukturerede data eller en kombination af alle. Det kunne håndteres let med HBase.
• Du vil gemme kolonneorienterede data.
• Du har mange versioner af datasættene, og du skal gemme dem alle.

Før jeg hopper til Facebook messenger case study,lad mig fortælle dig, hvad der er forskellene mellem HBase og HDFS.

HBase Tutorial: HBase VS HDFS

HDFS er et Java-baseret distribueret filsystem, der giver dig mulighed for at gemme store data på tværs af flere noder i en Hadoop-klynge. Så HDFS er et underliggende lagersystem til lagring af data i det distribuerede miljø. HDFS er et filsystem, mens HBase er en database (svarende til NTFS og MySQL).

Da både HDFS og HBase gemmer enhver form for data (dvs. struktureret, semi-struktureret og ustruktureret) i et distribueret miljø, så lad os se på forskellene mellem HDFS-filsystem og HBase, en NoSQL-database.

• HBase giver lav latensadgang til små datamængder inden for store datasæt, mens HDFS giver operationer med høj latens.
• HBase understøtter tilfældig læsning og skrivning, mens HDFS understøtter WORM (Skriv en gang Læs mange eller flere gange).
• Der er grundlæggende eller primært adgang til HDFS via MapReduce-job, mens HBase er adgang via shell-kommandoer, Java API, REST, Avro eller Thrift API.

HDFS gemmer store datasæt i et distribueret miljø og udnytter batchbehandling på disse data. For eksempel. det ville hjælpe et e-handelswebsted med at gemme millioner af kundedata i et distribueret miljø, der voksede over en lang periode (kan være 4-5 år eller mere). Derefter udnytter det batchbehandling over disse data og analyserer kundeadfærd, mønster, krav. Derefter kunne virksomheden finde ud af, hvilken type produkt, kundekøb i hvilke måneder. Det hjælper med at gemme arkiverede data og udføre batchbehandling over dem.

Mens HBase gemmer data på en søjleorienteret måde, hvor hver søjle lagres sammen, så bliver læsning hurtigere ved at udnytte realtidsbehandling. For eksempel. i et lignende e-handelsmiljø gemmer det millioner af produktdata. Så hvis du søger efter et produkt blandt millioner af produkter, optimerer det anmodnings- og søgningsprocessen og producerer resultatet med det samme (eller du kan sige det i realtid). Det detaljerede HBase arkitektoniske forklaring , Vil jeg dække i min næste blog.

Som vi ved, er HBase distribueret over HDFS, så en kombination af begge giver os en god mulighed for at bruge fordelene ved begge i en skræddersyet løsning, som vi vil se i nedenstående Facebook messenger case study.

HBase Tutorial: Facebook Messenger Case Study

Facebook Messaging Platform skiftede fra Apache Cassandra til HBase i november 2010.

Facebook Messenger kombinerer Beskeder, e-mail, chat og SMS i en realtidssamtale. Facebook forsøgte at opbygge en skalerbar og robust infrastruktur til at håndtere sæt af disse tjenester.

På det tidspunkt håndterede meddelelsesinfrastrukturen over 350 millioner brugere, der sendte over 15 milliarder person-til-person-beskeder om måneden. Chat-tjenesten understøtter over 300 millioner brugere, der sender over 120 milliarder beskeder om måneden.

Ved at overvåge brugen fandt de ud af, at der opstod to generelle datamønstre:

• Et kort sæt tidsdata, der har tendens til at være flygtige
• Et stadigt voksende sæt data, der sjældent får adgang til

Facebook ønskede at finde en lagerløsning til disse to brugsmønstre, og de begyndte at undersøge for at finde en erstatning for den eksisterende Messages-infrastruktur.

Tidligere i 2008 brugte de open source-database, dvs. Cassandra, som er en eventuel konsistensnøgleværdilager, der allerede var i produktion, der betjener trafik til Inbox Search. Deres teams havde stor viden om at bruge og administrere en MySQL-database, så det var en alvorlig bekymring for dem at skifte en af ​​teknologierne.

De brugte et par uger på at teste forskellige rammer for at evaluere klyngerne af MySQL, Apache Cassandra, Apache HBase og andre systemer. De valgte i sidste ende HBase.

Da MySQL ikke kunne håndtere de store datasæt effektivt, da indekserne og datasættene voksede store, blev ydeevnen lidt. De fandt Cassandra ude af stand til at håndtere vanskelige mønstre for at forene deres nye Messages-infrastruktur.

De største problemer var:

• Lagring af de store sæt kontinuerligt voksende data fra forskellige Facebook-tjenester.
• Kræver en database, der kan udnytte høj behandling på den.
• Høj ydeevne er nødvendig for at betjene millioner af anmodninger.
• Opretholdelse af konsistens i opbevaring og ydeevne.

Figur: Udfordringer, som Facebook messenger står over for

For alle disse problemer kom Facebook med en løsning, dvs. HBase. Facebook vedtog HBase til betjening af Facebook messenger, chat, e-mail osv. På grund af dets forskellige funktioner.

HBase leveres med meget god skalerbarhed og ydeevne til denne arbejdsbyrde med en enklere konsistensmodel end Cassandra. Mens de fandt HBase at være den mest egnede med hensyn til deres krav som automatisk belastningsbalancering og failover, kompressionsstøtte, flere skår pr. Server osv.

HDFS, som er det underliggende filsystem, der bruges af HBase, leverede dem også adskillige nødvendige funktioner såsom end-to-end-kontrolsummer, replikering og automatisk belastningsrebalancering.

Figur: HBase som en løsning på Facebook messenger

Da de vedtog HBase, fokuserede de også på at overføre resultaterne tilbage til HBase selv og begyndte at arbejde tæt sammen med Apache-samfundet.

Da meddelelser accepterer data fra forskellige kilder, såsom SMS, chats og e-mails, skrev de en applikationsserver til at håndtere al beslutningstagning for en brugers besked. Det grænseflader med et stort antal andre tjenester. Vedhæftede filer er gemt i en høstak (som fungerer på HBase). De skrev også en opdagelsestjeneste på toppen af ​​Apache ZooKeeper, som talte med andre infrastrukturtjenester for venskabsforhold, verifikation af e-mail-konto, beslutninger om levering og beslutninger om beskyttelse af personlige oplysninger.

Facebook-team brugte meget tid på at bekræfte, at hver af disse tjenester er robuste, pålidelige og giver god ydeevne til at håndtere et realtids messaging-system.

Jeg håber, at denne HBase tutorial blog er informativ, og du kunne lide det. I denne blog lærte du at kende det grundlæggende i HBase og dets funktioner.I min næste blog af , Vil jeg forklare arkitektur af HBase og arbejde med HBase, hvilket gør det populært til hurtig og tilfældig læsning / skrivning.

Nu hvor du har forstået det grundlæggende i HBase, skal du tjekke af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden. Edureka Big Data Hadoop-certificeringskursus hjælper elever med at blive eksperter i HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume og Sqoop ved hjælp af realtidsanvendelsessager på Retail, Social Media, Aviation, Tourism, Finance domæne.

Har du et spørgsmål til os? Nævn det i kommentarfeltet, og vi vender tilbage til dig.