HBase architektúra: HBase adatmodell és HBase olvasási / írási mechanizmus

HBase építészet

Az előző blogomban HBase bemutató , Elmagyaráztam, mi a HBase és annak jellemzői. Említettem a Facebook Messenger esettanulmányát is, hogy segítsen a jobb kapcsolódásban. Most tovább haladva a mi , Elmagyarázom Önnek a HBase és a HBase Architecture adatmodelljét.Mielőtt továbblépne, azt is tudnia kell, hogy a HBase egy fontos fogalom, amely a a Big Data Hadoop tanúsításhoz.

A HBase architektúra blogon áttekintem a következő fontos témákat:

• HBase adatmodell
• A HBase Architecture és alkatrészei
• HBase írási mechanizmus
• HBase olvasási mechanizmus
• HBase teljesítmény-optimalizálási mechanizmusok

Először értsük meg a HBase adatmodelljét. Segíti a HBase-t a gyorsabb olvasásban / írásban és keresésben.

HBase architektúra: HBase adatmodell

Mint tudjuk, a HBase egy oszloporientált NoSQL adatbázis. Bár hasonlít egy relációs adatbázishoz, amely sorokat és oszlopokat tartalmaz, de nem relációs adatbázis. A relációs adatbázisok sororientáltak, míg a HBase oszloporientáltak. Tehát először értsük meg az oszloporientált és a sororientált adatbázisok közötti különbséget:

Sororientált vs oszloporientált adatbázisok:

• Sororientált adatbázisok a táblázatrekordokat sorok sorrendjében tárolják. Míg oszloporientált adatbázisoktárolja a táblázatrekordokat oszlopok sorrendjében, vagyis az oszlop bejegyzéseit a lemezek összefüggő helyeiben tárolják.

Hogy jobban megértsük, vegyünk egy példát, és vegyük figyelembe az alábbi táblázatot.

Ha ez a tábla sororientált adatbázisban van tárolva. A rekordokat az alábbiak szerint tárolja:

egy,Paul Walker,MINKET,231,Bátor,

2, Vin Diesel,Brazília,520,Musztáng

A sororientált adatbázisokban az adatok sorok vagy tömbök alapján kerülnek tárolásra, amint az fent látható.

Míg az oszloporientált adatbázisok ezeket az adatokat a következőképpen tárolják:

egy,2, Paul Walker,Vin Diesel, MINKET,Brazília, 231,520, Bátor,Musztáng

Oszloporientált adatbázisokban az összes oszlopérték együtt tárolódik, mint az első oszlopértékek együtt, majd a második oszlopértékek együtt, a többi oszlopban lévő adatok pedig hasonló módon kerülnek tárolásra.

• Ha az adatmennyiség nagyon nagy, például a petabájt vagy az exabájt esetében, akkor oszloporientált megközelítést alkalmazunk, mivel egyetlen oszlop adatait együtt tárolják és gyorsabban elérhetik.
• Míg a sororientált megközelítés viszonylag kevesebb sor és oszlop számát kezeli hatékonyan, a sororientált adatbázis-tárolás strukturált formátum.
• Amikor félig strukturált vagy strukturálatlan adatok nagy sorozatát kell feldolgoznunk és elemeznünk, oszloporientált megközelítést alkalmazunk. Ilyenek például a Online elemző feldolgozás mint adatbányászat, adattárház, alkalmazások, beleértve az elemzéseket stb.
• Mivel, Online tranzakciós feldolgozás mint például a strukturált adatokat kezelő banki és pénzügyi területek, amelyek tranzakciós tulajdonságokat (ACID tulajdonságokat) igényelnek, sororientált megközelítést alkalmaznak.

A HBase táblák az alábbi képen látható komponenseket tartalmazzák:

• Táblázatok : Az adatokat táblázat formátumban tároljuk a HBase-ben. De itt a táblázatok oszloporientált formátumban vannak.
• Sor Kulcs : A sorgombok olyan rekordok keresésére szolgálnak, amelyek gyors keresést eredményeznek. Kíváncsi lennél, hogyan? Meg fogom magyarázni az ebben a blogban haladó építészeti részben.
• Oszlop Családok : Különböző oszlopok vannak kombinálva egy oszlopcsaládban. Ezeket az oszlopcsaládokat együtt tárolják, ami gyorsabbá teszi a keresési folyamatot, mert az azonos oszlopcsaládhoz tartozó adatok egyetlen keresés során együtt érhetők el.
• Oszlop Minősítők : Minden oszlop neve oszlopminősítő néven ismert.
• Sejt : Az adatokat cellákban tároljuk. Az adatok olyan cellákba kerülnek, amelyeket kifejezetten sor- és oszlopminősítők azonosítanak.
• Időbélyeg : Az időbélyeg a dátum és az idő kombinációja. Az adatok tárolásakor az időbélyegével együtt tárolódnak. Ez megkönnyíti az adatok egy adott verziójának keresését.

Egyszerűbb és megértőbb módon azt mondhatjuk, hogy a HBase a következőkből áll:

• Táblázatkészlet
• Minden táblázat oszlopcsaládokkal és sorokkal
• A sor kulcs elsődleges kulcsként működik a HBase-ben.
• A HBase táblákhoz való bármely hozzáférés ezt az elsődleges kulcsot használja
• A HBase-ben található minden oszlopminősítő a cellában található objektumnak megfelelő attribútumot jelöl.

Most, hogy tud a HBase adatmodellről, nézze meg, hogy ez az adatmodell összhangban áll-e a HBase architektúrájával, és alkalmassá teszi-e nagy tárolásra és gyorsabb feldolgozásra.

HBase Architecture: A HBase Architecture elemei

A HBase-nek három fő összetevője van, azaz HMaster Server , HBase Region Server, régiók és Állatgondozó .

Az alábbi ábra elmagyarázza a HBase architektúra hierarchiáját. Mindegyikről külön-külön fogunk beszélni.

java osztály példányadatai

Mielőtt a HMasterbe megyünk, megértjük a Régiókat, mivel ezek a szerverek (HMaster, Region Server, Zookeeper) a régiók koordinálásához és kezeléséhez, valamint a régiókon belüli különféle műveletek végrehajtásához vannak elhelyezve. Szóval kíváncsi lennél arra, hogy mik a régiók és miért olyan fontosak?

HBase architektúra: Vidék

Egy régió tartalmazza az összes sort az induló kulcs és az adott régióhoz rendelt befejező kulcs között. A HBase táblák számos régióra oszthatók úgy, hogy egy oszlopcsalád összes oszlopa egy régióban legyen tárolva. Minden régió rendezett sorrendben tartalmazza a sorokat.

Sok régió van hozzárendelve a Region Server , amely az olvasási és írási műveletek kezeléséért, kezeléséért, végrehajtásáért felel az adott régióban.

Tehát, egyszerűbb következtetéssel:

• A táblázat felosztható számos régióra. A Régió egy sorba rendezett sor, amely adatokat tárol a kezdőkulcs és a befejező kulcs között.
• Egy régió alapértelmezett mérete 256 MB, amelyet az igényeknek megfelelően lehet konfigurálni.
• A régiók csoportját egy régiókiszolgáló szolgálja ki az ügyfelek számára.
• A Region Server körülbelül 1000 régiót tud kiszolgálni az ügyfél számára.

Most a hierarchia tetejétől kezdve szeretném először elmagyarázni Önnek a HMaster Server-t, amely hasonlóan működik HDFS . Ezután a hierarchiában lefelé haladva a ZooKeeper és a Region Server segítségével vezetlek át.

HBase architektúra: HMaster

Az alábbi képhez hasonlóan láthatja, hogy a HMaster kezeli a Region Server szerver gyűjteményét, amely a DataNode-on található. Értsük meg, hogyan teszi ezt a HMaster.

• HBase A HMaster DDL műveleteket hajt végre (táblákat hoz létre és töröl), és hozzárendeli a régiókat a Region kiszolgálókhoz, amint az a fenti képen látható.
• Koordinálja és kezeli a régiókiszolgálót (hasonlóan, mint a NameNode kezeli a DataNode-ot HDFS-ben).
• Az indításkor hozzárendel egy régiót a régiókiszolgálókhoz, és a helyreállítás és a terheléselosztás során a régiókhoz hozzárendeli a régiókat.
• Figyeli a fürt összes Region Server példányát (a Zookeeper segítségével), és helyreállítási tevékenységeket végez, amikor bármelyik Region Server leáll.
• Felületet biztosít a táblák létrehozásához, törléséhez és frissítéséhez.

A HBase elosztott és hatalmas környezettel rendelkezik, ahol a HMaster önmagában nem elegendő minden kezeléséhez. Tehát kíváncsi lenne, mi segíti a HMastert ennek a hatalmas környezetnek a kezelésében? Itt jön a képbe a ZooKeeper. Miután megértettük, hogy a HMaster hogyan kezeli a HBase környezetet, megértjük, hogy a Zookeeper hogyan segíti a HMastert a környezet kezelésében.

HBase architektúra: ZooKeeper - A koordinátor

Ez az alábbi kép elmagyarázza a ZooKeeper koordinációs mechanizmusát.

• A Zookeeper koordinátorként működik a HBase elosztott környezetben. Munkameneteken keresztüli kommunikációval segít fenntartani a kiszolgáló állapotát a fürtön belül.
• Minden Region Server és a HMaster Server együttes rendszeres időközönként folyamatos szívverést küld a Zookeeper-nek, és ellenőrzi, melyik szerver él és elérhető, amint azt a fenti kép is említi. Szerverhiba-értesítéseket is nyújt, így helyreállítási intézkedéseket lehet végrehajtani.
• A fenti képen látható módon van egy inaktív szerver, amely az aktív szerver biztonsági másolataként működik. Ha az aktív szerver meghibásodik, akkor a mentés jön.
• Az aktív HMaster szívdobbanásokat küld a Zookeepernek, míg az inaktív HMaster az aktív HMaster által küldött értesítéseket hallgatja. Ha az aktív HMaster nem küld szívdobbanást, a munkamenet törlődik, és az inaktív HMaster aktívvá válik.
• Míg ha a Region Server nem küld szívdobbanást, a munkamenet lejárt, és erről minden hallgatót értesítenek. Ezután a HMaster elvégzi a megfelelő helyreállítási műveleteket, amelyeket később a blogban tárgyalunk.
• A Zookeeper fenntartja a .META Server útvonalát is, amely minden ügyfélnek segítséget nyújt bármely régió keresésében. Az ügyfélnek először meg kell vizsgálnia a .META szerverrel, hogy melyik régiószerverhez tartozik egy régió, és megkapja az adott régiókiszolgáló elérési útját.

Ahogy a .META szerverről beszéltem, hadd magyarázzam el először, mi az a .META szerver? Tehát könnyen összekapcsolhatja a ZooKeeper és a .META Server munkáját. Később, amikor elmagyarázom neked a HBase keresési mechanizmusát ebben a blogban, elmagyarázom, hogy ez a kettő hogyan működik együtt.

HBase architektúra: Meta táblázat

• A META táblázat egy speciális HBase katalógus táblázat. Fenntartja az összes régiós kiszolgáló listáját a HBase tárolórendszerben, amint azt a fenti képen láthatja.
• A látható ábrát nézve, .META a fájl kulcsok és értékek formájában tartja fenn a táblázatot. A kulcs a régió kezdőkulcsa és azonosítója, míg az érték a Region Server elérési útját tartalmazza.

Amint már említettem, a Region Server és annak funkciói, miközben elmagyaráztam Önöknek a Régiókat, most a hierarchián haladunk lefelé, és a Region Server összetevőjére és azok funkcióira fogok összpontosítani. Később megvitatom a keresés, az olvasás, az írás mechanizmusát és megértem, hogy ezek az összetevők hogyan működnek együtt.

HBase architektúra: A Region Server elemei

Ez az alábbi kép a Region Server összetevőit mutatja. Most külön megvitatom őket.

A Region Server különféle régiókat tart fenn a tetején . A Region Server összetevői a következők:

• WAL: Amint a fenti képből következtethetünk, az Write Ahead Log (WAL) egy fájl, amely minden elosztott környezetben lévő Region Server kiszolgálóhoz van csatolva. A WAL tárolja azokat az új adatokat, amelyeket nem tartottak fenn, vagy nem köteleztek el az állandó tárolás céljából. Adatkészletek helyreállításának sikertelensége esetén használják.
• Cache blokkolása: A fenti képből jól látható, hogy a Block Cache a Region Server tetején található. A gyakran olvasott adatokat a memóriában tárolja. Ha a BlockCache-ben szereplő adatokat a legutóbb használták, akkor ezeket az adatokat eltávolítja a BlockCache-ből.
• MemStore: Ez az írási gyorsítótár. Az összes bejövő adatot tárolja, mielőtt a lemezre vagy az állandó memóriába továbbítaná. A régió minden oszlopcsaládjához egy MemStore tartozik. Amint a képen látható, több MemStores van egy régióhoz, mert minden régió több oszlopcsaládot tartalmaz. Az adatokat lexikográfiai sorrendbe rendezzük, mielőtt a lemezre továbbítanánk.
• HFile: A fenti ábrán látható, hogy a HFile a HDFS-en van tárolva. Így tárolja a tényleges cellákat a lemezen. A MemStore átadja az adatokat a HFile-nek, amikor a MemStore mérete meghaladja.

Most, hogy ismerjük a HBase Architecture főbb és kisebb alkotóelemeit, elmagyarázom ebben a mechanizmust és együttműködésük erőfeszítéseit. Legyen szó olvasásról vagy írásról, először azt kell keresnünk, hogy hol olvassunk, vagy hová írjunk egy fájlt. Szóval, értsük meg ezt a keresési folyamatot, mivel ez az egyik mechanizmus, amely a HBase-t nagyon népszerűvé teszi.

HBase architektúra: Hogyan inicializálódik a keresés a HBase-ben?

Mint tudják, a Zookeeper tárolja a META táblázat helyét. Amikor egy ügyfél olvasással fordul, vagy kéréseket ír a HBase-hez, a következő művelet történik:

1. Az ügyfél lekéri a META tábla helyét a ZooKeeper alkalmazásból.
2. Ezután az ügyfél a megfelelő sorkulcs régiószerverének helyét kéri a META táblából annak eléréséhez. Az ügyfél tárolja ezeket az információkat a META táblázat helyével.
3. Ezután megkapja a sor helyét, ha a megfelelő Region Server-től kéri.

A jövőbeni hivatkozásokhoz az ügyfél a gyorsítótárát használja a META-tábla helyének lekérésére és a sorkulcs régiókiszolgálójának korábban történő olvasására. Ekkor az ügyfél nem hivatkozik a META táblára, amíg nem történik hiányzás, mert a régió eltolódott vagy elmozdult. Ezután újra kérni fogja a META szervert, és frissíti a gyorsítótárat.

Mint minden alkalommal, az ügyfelek sem pazarolnak időt a Region Server helyének lekérésére a META Server szerverről, így ez időt takarít meg és gyorsabbá teszi a keresési folyamatot. Most hadd mondjam el, hogyan zajlik az írás a HBase-ben. Melyek az alkatrészek és hogyan vesznek részt benne?

hogyan lehet kettősből int java

HBase architektúra: HBase Write Gépezet

Ez az alábbi kép elmagyarázza a HBase írási mechanizmusát.

Az írási mechanizmus a következő folyamaton megy keresztül egymás után (lásd a fenti képet):

1. lépés: Amikor az ügyfélnek írási kérelme van, az ügyfél beírja az adatokat a WAL-ba (Write Ahead Log).

• A szerkesztéseket ezután a WAL fájl végén csatolják.
• Ezt a WAL fájlt minden régiókiszolgáló karbantartja, és a régiókiszolgáló a lemezen nem lekötött adatok helyreállítására használja.

2. lépés: Miután az adatokat beírta a WAL-ba, akkor azokat a MemStore-ba másolja.

3. lépés: Miután az adatok a MemStore-ba kerültek, az ügyfél megkapja a nyugtázást.

4. lépés: Amikor a MemStore eléri a küszöbértéket, kiírja vagy elküldi az adatokat egy HFile-be.

Most merüljünk el mélyen, és értsük meg, hogy a MemStore hogyan járul hozzá az írás folyamatához és milyen funkciói vannak?

HBase Write Gépezet- MemStore

• A MemStore mindig frissíti a benne tárolt adatokat lexikográfiai sorrendben (szekvenciálisan szótári módon) rendezett KeyValues ​​néven. Minden oszlopcsaládhoz tartozik egy MemStore, és így a frissítéseket minden oszlopcsaládhoz rendezve tároljuk.
• Amikor a MemStore eléri a küszöböt, az összes adatot rendezetten átdobja egy új HFile-be. Ez a HFile HDFS-ben van tárolva. A HBase minden oszlopcsaládhoz több HF fájlt tartalmaz.
• Idővel a HFile száma növekszik, ahogy a MemStore kiírja az adatokat.
• A MemStore elmenti az utolsó írott sorszámot is, így a Master Server és a MemStore is tudja, hogy mi az, amit eddig elköteleztek, és honnan induljon ki. Amikor a régió elindul, az utolsó sorszám beolvasásra kerül, és ettől a számtól kezdődnek az új szerkesztések.

Amint már többször tárgyaltam, hogy a HFile a fő tartós tároló a HBase architektúrában. Végül az összes adatot a HFile-hez kötjük, amely a HBase állandó tárolója. Ezért nézzük meg a HFile tulajdonságait, ami gyorsabbá teszi a keresést olvasás és írás közben.

HBase architektúra: HBase Write Gépezet- HFile

• Az írásokat egymás után helyezzük el a lemezen. Ezért a lemez író-fej mozgása nagyon kevés. Ez nagyon gyorsá teszi az írási és keresési mechanizmust.
• A HFile indexek a memóriába kerülnek, amikor egy HFile megnyílik. Ez segít megtalálni a rekordot egyetlen keresés során.
• A trailer egy mutató, amely a HFile metablokkjára mutat. A lekötött fájl végén van írva. Információt tartalmaz az időbélyeg és a virágzás szűrőkről.
• A Bloom Filter segít a kulcsértékpárok keresésében, kihagyja azt a fájlt, amely nem tartalmazza a szükséges sort. Az Időbélyegző a fájl verziójának keresésében, az adatok kihagyásában is segítséget nyújt.

Miután ismerte az írási mechanizmust és a különféle összetevők szerepét az írás és a keresés gyorsabbá tételében. Elmagyarázom neked, hogyan működik az olvasási mechanizmus egy HBase architektúrán belül? Ezután áttérünk azokra a mechanizmusokra, amelyek növelik a HBase teljesítményét, mint a tömörítés, a régió felosztása és a helyreállítás.

HBase architektúra: Olvassa el a Mechanizmust

A keresési mechanizmusunkban leírtak szerint az ügyfél először a .META szerverről tölti le a Region Server helyét, ha az ügyfél nem rendelkezik a cache memóriájában. Ezután a következő lépéseken megy keresztül:

• Az adatok beolvasásához a szkenner először a Blokk gyorsítótárában található Sor cellát keresi. Itt tárolódik az összes nemrégiben olvasott kulcsérték pár.
• Ha a Scanner nem találja meg a kívánt eredményt, akkor a MemStore-ba költözik, mivel tudjuk, hogy ez az írási gyorsítótár. Ott keresi a legutóbb írt fájlokat, amelyeket még nem dobtak ki a HFile-be.
• Végül a virágszűrőkkel és a gyorsítótár blokkolásával tölti be az adatokat a HFile-ból.

Eddig a HBase keresési, olvasási és írási mechanizmusát vitattam meg. Most megvizsgáljuk a HBase mechanizmust, amely gyors keresést, olvasást és írást tesz lehetővé a HBase-ben. Először is meg fogjuk érteni Tömörítés , amely egyike azoknak a mechanizmusoknak.

HBase architektúra: Tömörítés

HBase a HFile-eket egyesíti a tárhely csökkentése és az olvasáshoz szükséges lemezkeresések számának csökkentése érdekében. Ezt a folyamatot hívják tömörítés . A tömörítés kiválaszt egy HF fájlt egy régióból, és egyesíti azokat. Kétféle tömörítés létezik, amint az a fenti képen látható.

1. Kisebb tömörítés : A HBase automatikusan kiválasztja a kisebb HF fájlokat, és újra ajánlja őket a nagyobb HF fájlokhoz, amint az a fenti képen látható. Ezt hívják Kisebb tömörítésnek. Összevonási rendezést hajt végre kisebb HF fájlok nagyobb HF fájlokhoz való elkötelezéséhez. Ez segít a tárhely optimalizálásában.
2. Fő tömörítés: Amint azt a fenti kép szemlélteti, a Major tömörítésnél a HBase egyesíti és új régiónak ajánlja a régió kisebb H-fájljait. Ebben a folyamatban ugyanazok az oszlopcsaládok kerülnek együtt az új HFile-be. Ebbe a folyamatba dobja a törölt és lejárt cellákat. Növeli az olvasási teljesítményt.

hogyan állítsd be a java napfogyatkozását

Ennek során azonban a bemeneti-kimeneti lemezek és a hálózati forgalom torlódhat. Ezt nevezik írási erősítés . Tehát általában alacsony csúcsterhelés idején ütemezik.

Most egy másik teljesítmény-optimalizálási folyamatról beszélek Split régió . Ez nagyon fontos a terheléselosztás szempontjából.

HBase architektúra: Split régió

Az alábbi ábra a Region Split mechanizmust szemlélteti.

Amikor egy régió nagy lesz, két gyermekrégióra oszlik, amint azt a fenti ábra mutatja. Minden régió a szülő régiónak pontosan a felét képviseli. Ezután ezt a felosztást jelentik a HMaster-nek. Ezt ugyanaz a Region Server kezeli, amíg a HMaster nem hozzárendeli őket egy új Region Server kiszolgálóhoz a terheléselosztás érdekében.

Végül, de nem utolsósorban lefelé haladva elmagyarázom, hogy a HBase hogyan tudja helyreállítani az adatokat hiba után. Ahogy tudjuk Hiba helyreállítása a HBase nagyon fontos jellemzője, így tudassa velünk, hogy a HBase miként állítja helyre az adatokat egy hiba után.

HBase architektúra: HBase összeomlás és adat-helyreállítás

• Amikor egy regionális kiszolgáló meghibásodik, a ZooKeeper értesíti a HMaster-t a hibáról.
• Ezután a HMaster kiosztja és lefoglalja az összeomlott Region Server régiókat számos aktív Region Server kiszolgáló számára. A meghibásodott Region Server kiszolgáló MemStore adatainak helyreállításához a HMaster elosztja a WAL-t az összes Region Server kiszolgálónak.
• Minden régiókiszolgáló újra végrehajtja a WAL-ot, hogy felépítse a MemStore-ot az adott sikertelen régió oszlopcsaládjához.
• Az adatokat időrendi sorrendben (megfelelő sorrendben) írjuk WAL-ba. Ezért a WAL újbóli végrehajtása azt jelenti, hogy elvégezzük a MemStore fájlban végrehajtott és tárolt összes változtatást.
• Tehát, miután az összes regionális kiszolgáló végrehajtotta a WAL-ot, az összes oszlopcsalád MemStore-adatai helyreállnak.

Remélem, hogy ez a blog segített Önnek a HBase adatmodell és a HBase architektúra lebecsülésében. Remélem élvezted. Most kapcsolódhat a HBase szolgáltatásaihoz (amelyeket az előzőben ismertettem HBase bemutató blog) a HBase Architecture-szel, és megérteni, hogyan működik belsőleg. Most, hogy ismeri a HBase elméleti részét, át kell térnie a gyakorlati részre. Ezt szem előtt tartva a következő blogunk mintát fog magyarázni HBase POC .

Most, hogy megértette a HBase architektúrát, nézze meg a az Edureka, egy megbízható online tanulási vállalat, amelynek több mint 250 000 elégedett tanulóval rendelkező hálózata elterjedt az egész világon. Az Edureka Big Data Hadoop tanúsító tanfolyam segít a tanulóknak a HDFS, a fonal, a MapReduce, a Pig, a Hive, a HBase, az Oozie, a Flume és a Sqoop szakértőivé válni, valós idejű felhasználási esetek felhasználásával a kiskereskedelem, a szociális média, a repülés, az idegenforgalom és a pénzügy területén.

Van egy kérdésünk? Kérjük, említse meg a megjegyzések részben, és kapcsolatba lépünk Önnel.