HBase-handledning: HBase-introduktion och Facebook-fallstudie



Denna HBase-handledningblogg introducerar dig till vad som är HBase och dess funktioner. Det täcker också fallstudie på Facebook Messenger för att förstå fördelarna med HBase.

Som vi nämnde i vår blogg är HBase en väsentlig del av vårt Hadoop-ekosystem. Så nu vill jag ta dig igenom HBase-handledning, där jag kommer att presentera dig för Apache HBase, och sedan kommer vi att gå igenom fallstudien på Facebook Messenger. Vi kommer att täcka följande ämnen i den här HBase-självstudiebloggen:

Apache HBase-handledning: Historia

Låt oss börja med HBase-historien och veta hur HBase har utvecklats under en tidsperiod.





HBase-historia - HBase-handledning - Edureka

  • Apache HBase är modellerad efter Googles BigTable, som används för att samla in data och betjäna begäran för olika Google-tjänster som Maps, Finance, Earth etc.
  • Apache HBase började som ett projekt av företaget Powerset för Natural Language Search, som hanterade massiva och glesa datamängder.
  • Apache HBase släpptes först i februari 2007. Senare i januari 2008 blev HBase ett delprojekt av Apache Hadoop.
  • Under 2010 blev HBase Apache-projektet på högsta nivå.

HBase-handledning | NoSQL-databaser | Edureka



Efter att ha känt till Apache HBases historia skulle du vara nyfiken på att veta vad som är Apache HBase? Låt oss gå längre och ta en titt.

Apache HBase-handledning: Introduktion till HBase

HBase är en öppen källkod, flerdimensionell, distribuerad, skalbar och en NoSQL-databas skrivet på Java. HBase körs ovanpå HDFS (Hadoop Distribuerat filsystem) och ger Bigoop-liknande funktioner till Hadoop. Den är utformad för att ge ett feltolerant sätt att lagra stora insamlingar av glesa datamängder.

twitter sentimentanalys med gnista

Eftersom HBase uppnår hög genomströmning och låg latens genom att ge snabbare läs- / skrivåtkomst på stora datamängder. Därför är HBase valet för applikationer som kräver snabb och slumpmässig åtkomst till stora mängder data.



Det ger komprimering, operationer i minnet och Bloom-filter (datastruktur som anger om ett värde finns i en uppsättning eller inte) för att uppfylla kravet på snabba och slumpmässiga lässkrivningar.

Låt oss förstå det genom ett exempel: En jetmotor genererar olika typer av data från olika sensorer som trycksensor, temperatursensor, hastighetssensor etc. som indikerar motorns hälsa. Detta är mycket användbart för att förstå flygets problem och status. Kontinuerlig motoroperation genererar 500 GB data per flygning och det finns cirka 300 tusen flygningar per dag. Så, Engine Analytics som tillämpas på sådan data i nära realtid kan användas för att proaktivt diagnostisera problem och minska oplanerad stilleståndstid. Detta kräver en distribuerad miljö för att lagra stor mängd data med snabbt slumpmässigt läser och skriver för realtidsbehandling. Här kommer HBase för att rädda. Jag kommer att prata om HBase Läs och skriv i detalj i min nästa blogg på HBase-arkitektur .

Som vi vet är HBase en NoSQL-databas. Så innan vi förstår mer om HBase, kan vi först diskutera om NoSQL-databaser och dess typer.

Apache HBase-handledning: NoSQL-databaser

NoSQL betyder Inte bara SQL . NoSQL-databaser är modellerade på ett sätt som representerar andra data än tabellformat, okulära relationsdatabaser. Den använder olika format för att representera data i databaser och det finns därför olika typer av NoSQL-databaser baserat på deras representationsformat. De flesta av NoSQL-databaser utnyttjar tillgänglighet och hastighet över konsistens. Låt oss nu gå vidare och förstå om de olika typerna av NoSQL-databaser och deras representationsformat.

Key-Value-butiker:

Det är en schemafri databas som innehåller nycklar och värden. Varje nyckel, pekar på ett värde som är en grupp med byte, kan vara en sträng, BLOB, XML, etc. t.ex. Lamborghini är en nyckel och kan peka på ett värde Gallardo, Aventador, Murciélago, Reventón, Diablo, Huracán, Veneno, Centenario etc.

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

Användningsfall

Key-value-butiker hanterar storleken bra och är bra på att bearbeta en konstant ström av läs / skrivoperationer med låg latens. Detta gör dem perfekta förAnvändarinställningar och profilbutiker,Produktrekommendationer senaste artiklar som visas på en återförsäljarwebbplats för att driva framtida kundrekommendationer,Annonstjänsternas kundvanor resulterar i anpassade annonser, kuponger etc. för varje kund i realtid.

Dokumentorienterad :

Det följer samma nyckelvärdepar, men det är halvstrukturerat som XML, JSON, BSON. Dessa strukturer betraktas som dokument.

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

Användningsfall

Eftersom dokumentet stöder flexibelt schema gör snabbläsning och partitionering det lämpligt för att skapa användardatabaser i olika tjänster som twitter, e-handelswebbplatser etc.

Kolumnorienterad:

I denna databas lagras data i celler grupperade i kolumn snarare än rader. Kolumner är logiskt grupperade i kolumnfamiljer som kan antingen skapas under schemadefinition eller vid körning.

Dessa typer av databaser lagrar alla celler som motsvarar en kolumn som kontinuerlig diskinmatning, vilket gör åtkomst och sökning mycket snabbare.

Kolumnbaserade databaser: HBase, Accumulo, Cassandra, Druid, Vertica.

Användningsfall

Den stöder det enorma lagringsutrymmet och möjliggör snabbare lässkrivåtkomst över det. Detta gör kolumnorienterade databaser lämpliga för lagring av kundbeteenden på e-handelswebbplatser, finansiella system som Google Finance och aktiemarknadsdata, Google maps etc.

Graforienterad:

Det är en perfekt flexibel grafisk representation, som används till skillnad från SQL. Dessa typer av databaser löser enkelt adress skalbarhet problem eftersom det innehåller kanter och nod som kan utökas enligt kraven.

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

exempel på instansvariabel i java

Användningsfall

Detta används i grund och botten vid upptäckt av bedrägerier, rekommendationsmotorer i realtid (i de flesta fall e-handel), masterdatahantering (MDM), nätverks- och IT-verksamhet, identitets- och åtkomsthantering (IAM), etc.

HBase och Cassandra är de två berömda kolumnorienterade databaserna. Så, nu talar vi om det till en högre nivå, låt oss jämföra och förstå de arkitektoniska och arbetsskillnaderna mellan HBase och Cassandra.

HBase-handledning: HBase VS Cassandra

  • HBase är modellerad på BigTable (Google) medan Cassandra är baserad på DynamoDB (Amazon) som ursprungligen utvecklades av Facebook.
  • HBase utnyttjar Hadoop-infrastruktur (HDFS, ZooKeeper) medan Cassandra utvecklades separat men du kan kombinera Hadoop och Cassandra enligt dina behov.
  • HBase har flera komponenter som kommunicerar tillsammans som HBase HMaster, ZooKeeper, NameNode, Region Severs. Medan Cassandra är en enda nodtyp, där alla noder är lika och utför alla funktioner. Vilken nod som helst kan vara samordnare, det tar bort en enda felpunkt.
  • HBase är optimerad för läsning och stöder enstaka skrivningar, vilket leder till strikt konsistens. HBase stöder Range-baserade skanningar, vilket gör skanningsprocessen snabbare. Medan Cassandra stöder en radläsningar som bibehåller eventuell konsistens.
  • Cassandra stöder inte intervallbaserade radskanningar, vilket saktar igenom skanningsprocessen jämfört med HBase.
  • HBase stöder beställd partitionering, där rader i en kolumnfamilj lagras i RowKey-ordning, medan i Casandra är beställt partitionering en utmaning. På grund av RowKey är partitionering snabbare i HBase jämfört med Cassandra.
  • HBase stöder inte läsbelastningsbalansering, en regionserver serverar läsförfrågan och replikerna används bara vid misslyckande. Medan Cassandra stöder läsbalansering och kan läsa samma data från olika noder. Detta kan äventyra konsistensen.
  • I CAP (konsistens, tillgänglighet och partitionstolerans) upprätthåller sats HBase konsistens och tillgänglighet medan Cassandra fokuserar på tillgänglighet och partitionstolerans.


Låt oss nu ta ett djupt dyk och förstå funktionerna i Apache HBase som gör den så populär.

Apache HBase-handledning: Funktioner i HBase

  • Atomic läser och skriver: På radnivå tillhandahåller HBase atom- läsning och skrivning. Det kan förklaras som, under en läs- eller skrivprocess, att alla andra processer förhindras från att utföra några läs- eller skrivoperationer.
  • Konsekvent läser och skriver: HBase ger konsekvent läsning och skrivning på grund av ovanstående funktion.
  • Linjär och modulär skalbarhet: Eftersom datamängder distribueras över HDFS, så är den linjärt skalbar över olika noder, såväl som modulärt skalbar, eftersom den är uppdelad över olika noder.
  • Automatisk och konfigurerbar skärning av tabeller: HBase-tabeller är fördelade över kluster och dessa kluster är fördelade över regioner. Dessa regioner och kluster splittras och distribueras när data växer.
  • Lätt att använda Java API för klientåtkomst: Det ger enkel att använda Java API för programmatisk åtkomst.
  • Sparsam gateway och en REST-full webbtjänster: Det stöder också Thrift och REST API för icke-Java-gränssnitt.
  • Blockera cache- och blomfilter: HBase stöder Block Cache och Bloom-filter för optimering av förfrågningsoptimering med hög volym.
  • Stöd för automatiskt fel: HBase med HDFS tillhandahåller WAL (Write Ahead Log) över kluster som ger automatisk felsupport.
  • Sorterade radnycklar: Eftersom sökning sker på radintervall lagrar HBase radnycklar i en lexikografisk ordning. Med hjälp av dessa sorterade radnycklar och tidsstämpel kan vi skapa en optimerad begäran.

Nu går vi vidare i denna HBase-handledning, låt mig berätta vad som är användningsfall och scenarier där HBase kan användas och sedan ska jag jämföra HDFS och HBase.

Jag vill uppmärksamma de scenarier där HBase passar bäst.

HBase-handledning: Var kan vi använda HBase?

  • Vi bör använda HBase där vi har stora datamängder (miljoner eller miljarder eller rader och kolumner) och vi kräver snabb, slumpmässig och realtid, läs- och skrivåtkomst över data.
  • Datauppsättningarna är fördelade över olika kluster och vi behöver hög skalbarhet för att hantera data.
  • Uppgifterna samlas in från olika datakällor och det är antingen halvstrukturerad eller ostrukturerad data eller en kombination av alla. Det kan hanteras enkelt med HBase.
  • Du vill lagra kolumnorienterad data.
  • Du har många versioner av datamängderna och du måste lagra dem alla.

Innan jag hoppar till Facebook messenger case study,låt mig berätta vad som är skillnaderna mellan HBase och HDFS.

HBase-handledning: HBase VS HDFS

HDFS är ett Java-baserat distribuerat filsystem som låter dig lagra stora data över flera noder i ett Hadoop-kluster. Så, HDFS är ett underliggande lagringssystem för lagring av data i den distribuerade miljön. HDFS är ett filsystem, medan HBase är en databas (liknande NTFS och MySQL).

Eftersom både HDFS och HBase lagrar alla typer av data (dvs. strukturerade, halvstrukturerade och ostrukturerade) i en distribuerad miljö så kan vi titta på skillnaderna mellan HDFS-filsystem och HBase, en NoSQL-databas.

  • HBase ger låg latensåtkomst till små datamängder i stora datamängder medan HDFS ger operationer med hög latens.
  • HBase stöder slumpmässig läsning och skriver medan HDFS stöder WORM (Skriv en gång Läs många eller flera gånger).
  • HDFS nås i princip eller huvudsakligen via MapReduce-jobb medan HBase nås via skalkommandon, Java API, REST, Avro eller Thrift API.

HDFS lagrar stora datamängder i en distribuerad miljö och använder batchbearbetning på dessa data. T.ex. det skulle hjälpa en e-handelswebbplats att lagra miljontals kunddata i en distribuerad miljö som växte över en lång tidsperiod (kan vara 4-5 år eller mer). Sedan utnyttjar den batchbearbetning över den informationen och analyserar kundbeteenden, mönster, krav. Då kunde företaget ta reda på vilken typ av produkt, kundköp under vilka månader. Det hjälper till att lagra arkiverad data och utföra batchbehandling över den.

Medan HBase lagrar data på ett kolumnorienterat sätt där varje kolumn lagras tillsammans så att läsning blir snabbare med realtidsbehandling. T.ex. i en liknande e-handelsmiljö lagrar den miljontals produktdata. Så om du söker efter en produkt bland miljontals produkter optimerar den begäran och sökprocessen, vilket ger resultatet direkt (eller du kan säga i realtid). Det detaljerade HBase arkitektonisk förklaring , Kommer jag att täcka i min nästa blogg.

Som vi vet HBase distribueras över HDFS, så ger en kombination av båda oss en fantastisk möjlighet att använda fördelarna med båda, i en skräddarsydd lösning, vilket vi kommer att se i fallstudien om Facebook messenger nedan.

HBase-handledning: Fallstudie på Facebook Messenger

Facebook-meddelandeplattform flyttade från Apache Cassandra till HBase i november 2010.

Facebook Messenger kombinerar meddelanden, e-post, chatt och SMS i en konversation i realtid. Facebook försökte bygga en skalbar och robust infrastruktur för att hantera uppsättningen av dessa tjänster.

Vid den tiden hanterade meddelandeinfrastrukturen över 350 miljoner användare som skickade över 15 miljarder person-till-person-meddelanden per månad. Chattjänsten stöder över 300 miljoner användare som skickar över 120 miljarder meddelanden per månad.

Genom att övervaka användningen upptäckte de att två allmänna datamönster framkom:

  • En kort uppsättning tidsdata som tenderar att vara flyktiga
  • En ständigt växande uppsättning data som sällan får åtkomst

Facebook ville hitta en lagringslösning för dessa två användningsmönster och de började undersöka för att hitta en ersättning för den befintliga Messages-infrastrukturen.

Tidigare 2008 använde de öppen källkodsdatabas, det vill säga Cassandra, som är en eventuell nyckel-värdebutik som redan fanns i produktion som betjänar trafik för Inbox Search. Deras team hade stor kunskap om att använda och hantera en MySQL-databas, så att byta någon av teknikerna var ett allvarligt bekymmer för dem.

De tillbringade några veckor på att testa olika ramar för att utvärdera kluster av MySQL, Apache Cassandra, Apache HBase och andra system. De valde slutligen HBase.

Eftersom MySQL misslyckades med att hantera de stora datamängderna effektivt, eftersom index och datamängder växte stora, led prestandan. De fann att Cassandra inte kunde hantera svåra mönster för att förena sin nya meddelandeinfrastruktur.

De största problemen var:

  • Lagra de stora uppsättningarna av kontinuerligt växande data från olika Facebook-tjänster.
  • Kräver databas som kan utnyttja hög bearbetning på den.
  • Hög prestanda behövs för att betjäna miljoner förfrågningar.
  • Att upprätthålla enhetlighet i lagring och prestanda.

Figur: Utmaningar som Facebook messenger står inför

För alla dessa problem kom Facebook med en lösning, dvs HBase. Facebook antog HBase för att betjäna Facebook-messenger, chatt, e-post etc. på grund av dess olika funktioner.

HBase har mycket bra skalbarhet och prestanda för denna arbetsbelastning med en enklare konsistensmodell än Cassandra. Medan de tyckte att HBase var den mest lämpliga när det gäller deras krav som automatisk belastningsbalansering och failover, komprimeringsstöd, flera skärvor per server etc.

HDFS, som är det underliggande filsystemet som används av HBase, gav dem också flera nödvändiga funktioner som end-to-end-kontrollsummor, replikering och automatisk återbalansering av belastning.

pop-up-meddelande i Java-skript

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

När de antog HBase fokuserade de också på att överföra resultaten till HBase själv och började arbeta nära med Apache-communityn.

Eftersom meddelanden accepterar data från olika källor som SMS, chattar och e-postmeddelanden, skrev de en applikationsserver för att hantera alla beslutsfattande för en användares meddelande. Det gränssnitt med ett stort antal andra tjänster. Bilagorna lagras i en höstack (som fungerar på HBase). De skrev också en användarupptäcktjänst ovanpå Apache ZooKeeper som pratar med andra infrastrukturtjänster för vänförhållanden, verifiering av e-postkonton, leveransbeslut och integritetsbeslut.

Facebook-teamet spenderade mycket tid på att bekräfta att var och en av dessa tjänster är robust, pålitlig och ger bra prestanda för att hantera ett meddelandesystem i realtid.

Jag hoppas att den här HBase-handledningsbloggen är informativ och att du gillade den. I den här bloggen lärde du dig grunderna i HBase och dess funktioner.I min nästa blogg av , Jag kommer att förklara HBase-arkitektur och bearbetning av HBase vilket gör den populär för snabb och slumpmässig läsning / skrivning.

Nu när du har förstått grunderna i HBase, kolla in av Edureka, ett pålitligt inlärningsföretag online med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen. Edureka-kursen Big Data Hadoop-certifiering hjälper eleverna att bli experter på HDFS, Garn, MapReduce, Pig, Hive, HBase, Oozie, Flume och Sqoop med realtidsanvändningsfall på Retail, Social Media, Aviation, Tourism, Finance.

Har du en fråga till oss? Vänligen nämna det i kommentarfältet så återkommer vi till dig.