„HBase“ architektūra: „HBase“ duomenų modelis ir „HBase“ skaitymo / rašymo mechanizmas

Šiame tinklaraštyje apie „HBase Architecture“ paaiškinamas HBase duomenų modelis ir pateikiama įžvalga apie HBase architektūrą. Tai taip pat paaiškina skirtingus HBase mechanizmus.

„HBase“ architektūra

Mano ankstesniame tinklaraštyje „HBase“ mokymo programa , Paaiškinau, kas yra „HBase“ ir jo ypatybės. Taip pat paminėjau „Facebook Messenger“ atvejo tyrimą, kuris padės jums geriau susisiekti. Dabar toliau einame į priekį mūsų , Aš jums paaiškinsiu HBase ir HBase Architecture duomenų modelį.Prieš eidami toliau, taip pat turėtumėte žinoti, kad HBase yra svarbi sąvoka, sudaranti neatsiejamą jos dalį „Big Data Hadoop“ sertifikavimui.

Svarbios temos, kurias apžvelgsiu šiame „HBase“ architektūros tinklaraštyje, yra šios:



Pirmiausia supraskime HBase duomenų modelį. Tai padeda „HBase“ greičiau skaityti / rašyti ir ieškoti.



„HBase“ architektūra: „HBase“ duomenų modelis

Kaip žinome, „HBase“ yra į stulpelius orientuota „NoSQL“ duomenų bazė. Nors jis atrodo panašus į reliacinę duomenų bazę, kurioje yra eilučių ir stulpelių, tačiau tai nėra reliacinė duomenų bazė. Reliacinės duomenų bazės yra orientuotos į eilutes, o HBase - į stulpelius. Taigi, pirmiausia supraskime skirtumą tarp į stulpelius ir eilutes orientuotų duomenų bazių:

Eilučių ir stulpelių orientuotos duomenų bazės:

  • Į eilutes orientuotose duomenų bazėse lentelių įrašai saugomi eilučių seka. O kolonos orientuotos duomenų bazėssaugokite lentelės įrašus stulpelių seka, t. y. įrašai stulpelyje saugomi gretimose vietose diskuose.

Norėdami geriau suprasti, paimkime pavyzdį ir apsvarstykite toliau pateiktą lentelę.



Stalas - „HBase“ architektūra - „Edureka“

Jei ši lentelė saugoma į eilę orientuotoje duomenų bazėje. Įrašai bus saugomi taip, kaip parodyta žemiau:

vienas,Paul Walker,JAV,231,Galantiškas,

yra java

2, Vinas Dyzelis,Brazilija,520,Mustangas

Į eilutes orientuotose duomenų bazėse duomenys yra saugomi remiantis eilutėmis arba sekomis, kaip matote aukščiau.

Nors į stulpelius orientuotos duomenų bazės saugo šiuos duomenis kaip:

vienas,2, Paul Walker,Vinas Dyzelis, JAV,Brazilija, 231,520, Galantiškas,Mustangas

Į stulpelius orientuotose duomenų bazėse visos stulpelių vertės saugomos kartu, kaip ir pirmųjų stulpelių vertės, tada antrojo stulpelio vertės bus saugomos kartu, o kitų stulpelių duomenys bus saugomi panašiu būdu.

  • Kai duomenų kiekis yra labai didelis, pvz., Kalbant apie petabaitus ar egzabaitus, mes naudojame į stulpelius orientuotą metodą, nes vieno stulpelio duomenys yra saugomi kartu ir prie jų galima prisijungti greičiau.
  • Nors į eilutes orientuotas metodas palyginti efektyviai tvarko mažiau eilučių ir stulpelių, nes į eilutes orientuotos duomenų bazės saugyklos duomenys yra struktūrizuotas formatas.
  • Kai mums reikia apdoroti ir išanalizuoti didelį pusiau struktūrizuotų ar nestruktūruotų duomenų rinkinį, mes naudojame stulpelių metodą. Tokios kaip programos, susijusios su Internetinis analitinis apdorojimas kaip duomenų gavyba, duomenų saugojimas, programos, įskaitant analizę ir kt.
  • Kadangi, Operacijų apdorojimas internete pavyzdžiui, bankininkystės ir finansų srityse, kuriose tvarkomi struktūrizuoti duomenys ir reikalingos sandorio savybės (ACID savybės), naudojamas į eilę orientuotas metodas.

„HBase“ lentelėse yra šie komponentai, parodyti paveikslėlyje žemiau:

  • Lentelės : Duomenys lentelės formatu saugomi HBase. Bet čia lentelės yra orientuotos į stulpelius.
  • Eilutė Raktas : Eilių klavišai naudojami ieškant įrašų, kurie greitai atlieka paiešką. Jums būtų įdomu žinoti, kaip? Aš tai paaiškinsiu architektūros dalyje, einančioje į priekį šiame tinklaraštyje.
  • Stulpelis Šeimos : Įvairūs stulpeliai yra sujungti į stulpelių šeimą. Šios stulpelių šeimos yra saugomos kartu, todėl paieškos procesas yra greitesnis, nes vienai stulpelių šeimai priklausančius duomenis galima pasiekti vienu kartu.
  • Stulpelis Kvalifikacijos : Kiekvieno stulpelio pavadinimas žinomas kaip stulpelio kvalifikatorius.
  • Langelis : Duomenys saugomi langeliuose. Duomenys perkeliami į langelius, kuriuos konkrečiai identifikuoja eilutės ir stulpelio kvalifikatoriai.
  • Laiko žymė : Laiko žymė yra datos ir laiko derinys. Kai tik duomenys yra saugomi, jie saugomi su laiko žyme. Tai leidžia lengvai ieškoti tam tikros duomenų versijos.

Paprasčiau ir suprantamiau galime pasakyti, kad HBase susideda iš:

  • Stalų rinkinys
  • Kiekviena lentelė su stulpelių šeimomis ir eilėmis
  • Eilutės raktas veikia kaip pagrindinis raktas HBase.
  • Bet kuri prieiga prie „HBase“ lentelių naudoja šį pirminį raktą
  • Kiekvienas stulpelio kvalifikatorius, esantis HBase, reiškia atributą, atitinkantį langelyje esantį objektą.

Dabar, kai žinote apie „HBase“ duomenų modelį, pažiūrėkime, kaip šis duomenų modelis atitinka „HBase Architecture“ ir daro jį tinkamu dideliam saugojimui ir greitesniam apdorojimui.

HBase architektūra: HBase architektūros komponentai

HBase turi tris pagrindinius komponentus, t. „HMaster“ serveris , „HBase“ regiono serveris, regionai ir Zoologijos sodo prižiūrėtojas .

Žemiau pateiktame paveikslėlyje paaiškinta HBase architektūros hierarchija. Kalbėsime apie kiekvieną iš jų atskirai.


Dabar, prieš eidami į „HMaster“, suprasime „Regionus“, nes visi šie serveriai („HMaster“, „Region Server“, „Zookeeper“) yra skirti koordinuoti ir valdyti regionus bei atlikti įvairias operacijas regionuose. Taigi jums būtų įdomu sužinoti, kas yra regionai ir kodėl jie tokie svarbūs?

„HBase“ architektūra: Regionas

Regione yra visos eilutės tarp pradinio ir pabaigos rakto, priskirtų tam regionui. „HBase“ lenteles galima suskirstyti į daugelį regionų taip, kad visi stulpelių šeimos stulpeliai būtų saugomi viename regione. Kiekviename regione eilutės pateikiamos rūšiuojama tvarka.

Daugelis regionų yra priskirti a Regiono serveris , kuri yra atsakinga už skaitymo ir rašymo operacijų valdymą, valdymą, vykdymą tame regionų rinkinyje.

Taigi, baigdamas paprasčiau:

mvc taikymo pavyzdys java
  • Lentelę galima suskirstyti į daugelį regionų. Regionas yra rūšiuojamas eilučių diapazonas, kuriame saugomi duomenys tarp pradžios rakto ir pabaigos rakto.
  • Regiono numatytasis dydis yra 256 MB, kurį galima sukonfigūruoti pagal poreikį.
  • Regionų grupę klientams aptarnauja regiono serveris.
  • Regiono serveris klientui gali aptarnauti maždaug 1000 regionų.

Pradėdamas nuo hierarchijos viršaus, pirmiausia norėčiau paaiškinti apie „HMaster Server“, kuris veikia panašiai kaip „NameNode“ HDFS . Tada, žengdamas žemyn hierarchijoje, pervesiu jus per „ZooKeeper“ ir „Region Server“.

„HBase“ architektūra: HMaster

Kaip ir žemiau esančiame paveikslėlyje, galite pamatyti, kaip „HMaster“ tvarko „Region Server“ kolekciją, esančią „DataNode“. Supraskime, kaip tai daro „HMaster“.

  • „HBase HMaster“ atlieka DDL operacijas (kuria ir ištrina lenteles) ir priskiria regionus „Region“ serveriams, kaip matote aukščiau esančiame paveikslėlyje.
  • Jis koordinuoja ir valdo regiono serverį (panašiai kaip „NameNode“ valdo „DataNode“ HDFS).
  • Ji priskiria regionus regiono serveriams paleidimo metu ir iš naujo priskiria regionus serveriams atkūrimo ir apkrovos balansavimo metu.
  • Jis stebi visus regiono serverio egzempliorius grupėje (padedant „Zookeeper“) ir atlieka atkūrimo veiksmus, kai bet kuris regiono serveris neveikia.
  • Tai suteikia sąsają lentelėms kurti, ištrinti ir atnaujinti.

„HBase“ turi platų ir didžiulę aplinką, kur vien „HMaster“ nepakanka viskam valdyti. Taigi, jums būtų įdomu, kas padeda „HMaster“ valdyti šią didžiulę aplinką? Štai kur „ZooKeeper“ atsiranda. Supratę, kaip „HMaster“ valdo „HBase“ aplinką, suprasime, kaip „Zookeeper“ padeda „HMaster“ tvarkyti aplinką.

„HBase“ architektūra: „ZooKeeper“ - koordinatorius

Šis žemiau pateiktas paveikslėlis paaiškina „ZooKeeper“ koordinavimo mechanizmą.

  • „Zookeeper“ veikia kaip koordinatorius HBase paskirstytoje aplinkoje. Tai padeda palaikyti serverio būseną klasteryje, bendraujant per sesijas.
  • Kiekvienas regiono serveris kartu su „HMaster Server“ reguliariai siunčia nuolatinį širdies plakimą „Zookeeper“ ir patikrina, kuris serveris yra gyvas ir pasiekiamas, kaip minėta aukščiau esančiame paveikslėlyje. Ji taip pat teikia pranešimus apie serverio gedimus, kad būtų galima vykdyti atkūrimo priemones.
  • Remiantis aukščiau pateiktu vaizdu, kurį galite pamatyti, yra neaktyvus serveris, kuris veikia kaip aktyviojo serverio atsarginė kopija. Jei nepavyksta aktyvus serveris, jis gelbėjamas.
  • Aktyvus „HMaster“ siunčia širdies plakimus „Zookeeper“, o neaktyvus „HMaster“ klausosi aktyvaus „HMaster“ siunčiamų pranešimų. Jei aktyvus „HMaster“ nepavyksta išsiųsti širdies plakimo, sesija ištrinama, o neaktyvus „HMaster“ tampa aktyvus.
  • Jei „Region Server“ nepavyksta išsiųsti širdies plakimo, sesijos galiojimo laikas pasibaigęs ir apie tai pranešama visiems klausytojams. Tada „HMaster“ atlieka tinkamus atkūrimo veiksmus, kuriuos aptarsime vėliau šiame tinklaraštyje.
  • „Zookeeper“ taip pat palaiko .META serverio kelią, kuris padeda bet kuriam klientui ieškoti bet kurio regiono. Pirmiausia klientas turi patikrinti .META serverį, kuriam regiono serveriui priklauso regionas, ir jis gauna šio regiono serverio kelią.

Kalbėdamas apie .META serverį, leiskite man pirmiausia paaiškinti, kas yra .META serveris? Taigi, jūs galite lengvai susieti „ZooKeeper“ ir .META serverio darbą. Vėliau, kai šiame tinklaraštyje paaiškinsiu jums „HBase“ paieškos mechanizmą, paaiškinsiu, kaip šie du veikia bendradarbiaujant.

„HBase“ architektūra: Meta lentelė

  • META lentelė yra speciali HBase katalogo lentelė. Jis tvarko visų regionų serverių sąrašą HBase saugojimo sistemoje, kaip matote aukščiau esančiame paveikslėlyje.
  • Pažvelgus į paveikslą, kurį galite pamatyti, .META failas palaiko lentelę raktų ir reikšmių pavidalu. Raktas reiškia regiono pradžios raktą ir jo ID, o reikšmė nurodo regiono serverio kelią.

Kaip aš jau aptariau „Region Server“ ir jo funkcijas, kol aš jums aiškinau „Regionus“, dabar mes einame žemyn hierarchija ir aš sutelksiu dėmesį į „Region Server“ komponentą ir jų funkcijas. Vėliau aptarsiu paieškos, skaitymo, rašymo mechanizmą ir suprasiu, kaip visi šie komponentai veikia kartu.

„HBase“ architektūra: Regiono serverio komponentai

Šiame žemiau esančiame paveikslėlyje rodomi regiono serverio komponentai. Dabar aptarsiu juos atskirai.

Regiono serveris prižiūri įvairius regionus, veikiančius viršuje . Regiono serverio komponentai yra šie:

  • WAL: Kaip galite padaryti iš aukščiau pateikto paveikslėlio, „Write Ahead Log“ (WAL) yra failas, pridedamas prie kiekvieno regiono serverio paskirstytoje aplinkoje. WAL saugo naujus duomenis, kurie nebuvo išsaugoti ar skirti nuolatinei saugyklai. Jis naudojamas tuo atveju, jei nepavyksta atkurti duomenų rinkinių.
  • Blokuoti talpyklą: Iš aukščiau esančio vaizdo aiškiai matoma, kad „Blokų talpykla“ yra „Region Server“ viršuje. Dažnai skaitomus duomenis jis saugo atmintyje. Jei „BlockCache“ duomenys yra naudojami neseniai, tada šie duomenys pašalinami iš „BlockCache“.
  • „MemStore“: Tai rašymo talpykla. Jis saugo visus gaunamus duomenis prieš nukreipdamas juos į diską ar nuolatinę atmintį. Kiekvienoje regiono kolonų šeimoje yra po vieną „MemStore“. Kaip matote paveikslėlyje, regionui yra keli „MemStores“, nes kiekviename regione yra kelios stulpelių šeimos. Duomenys yra surūšiuoti leksikografine tvarka prieš juos perkeliant į diską.
  • HFailas: Iš aukščiau pateikto paveikslo matote, kad HFile yra saugoma HDFS. Taigi jis saugo faktines ląsteles diske. „MemStore“ perduoda duomenis „HFile“, kai „MemStore“ dydis viršija.

Dabar, kai žinome pagrindinius ir mažus „HBase Architecture“ komponentus, paaiškinsiu mechanizmą ir jų pastangas. Nesvarbu, ar tai skaitymas, ar rašymas, pirmiausia turime ieškoti iš kur skaityti ar kur rašyti failą. Taigi supraskime šį paieškos procesą, nes tai yra vienas iš mechanizmų, dėl kurio HBase yra labai populiari.

„HBase“ architektūra: Kaip paieška inicijuojama HBase?

Kaip žinote, „Zookeeper“ saugo META lentelės vietą. Kai klientas kreipiasi skaitydamas ar rašydamas užklausas į „HBase“, įvyksta ši operacija:

  1. META lentelės vietą klientas gauna iš „ZooKeeper“.
  2. Tada klientas prašo nurodyti atitinkamo eilutės rakto regiono serverio vietą iš lentelės META, kad galėtų ją pasiekti. Klientas talpina šią informaciją su META lentelės vieta.
  3. Tada jis gaus eilutės vietą paprašydamas iš atitinkamo regiono serverio.

Būsimoms nuorodoms klientas naudoja savo talpyklą, norėdamas nuskaityti META lentelės vietą ir anksčiau perskaityti eilutės rakto regiono serverį. Tada klientas nenurodys META lentelės, kol nebus praleista, nes regionas yra perkeltas ar perkeltas. Tada jis vėl paprašys META serverio ir atnaujins talpyklą.

Kaip ir kiekvieną kartą, klientai nešvaisto laiko gaudami Regiono serverio vietą iš META serverio, taigi tai taupo laiką ir pagreitina paieškos procesą. Leiskite man papasakoti, kaip rašymas vyksta „HBase“. Kokie yra jo komponentai ir kaip jie yra susiję?

„HBase“ architektūra: „HBase Write“ Mechanizmas

Šis žemiau pateiktas paveikslėlis paaiškina HBase rašymo mechanizmą.

Rašymo mechanizmas eina nuosekliai šį procesą (žr. Aukščiau esantį vaizdą):

1 žingsnis: Kai tik klientas turi rašymo užklausą, klientas įrašo duomenis į WAL (Write Ahead Log).

  • Tada redagavimai pridedami WAL failo pabaigoje.
  • Šis WAL failas yra palaikomas kiekviename regiono serveryje, o regiono serveris jį naudoja atkurdamas duomenis, kurie nėra priskirti diskui.

2 žingsnis: Kai duomenys įrašomi į WAL, jie nukopijuojami į „MemStore“.

3 žingsnis: Kai duomenys bus patalpinti „MemStore“, klientas gaus patvirtinimą.

4 žingsnis: Kai „MemStore“ pasiekia slenkstį, jis iškelia arba persiunčia duomenis į „HFile“.

Dabar giliai nardykime ir supraskime, kaip „MemStore“ prisideda prie rašymo proceso ir kokios yra jo funkcijos?

„HBase Write“ Mechanizmas- „MemStore“

  • „MemStore“ visada atnaujina jame saugomus duomenis leksikografine tvarka (nuosekliai žodyno būdu) kaip rūšiuojamas „KeyValues“. Kiekvienai stulpelių šeimai yra po vieną „MemStore“, todėl kiekvienos stulpelių šeimos atnaujinimai saugomi rūšiuojami.
  • Kai „MemStore“ pasiekia slenkstį, jis surūšiuoja visus duomenis į naują „HFile“. Ši HF byla saugoma HDFS. „HBase“ yra keletas HF failų kiekvienai stulpelių šeimai.
  • Laikui bėgant, „HFile“ skaičius auga, kai „MemStore“ kaupia duomenis.
  • „MemStore“ taip pat išsaugo paskutinį užrašytą eilės numerį, todėl „Master Server“ ir „MemStore“ žino, kad tai, kas padaryta iki šiol, ir nuo ko pradėti. Kai regionas paleidžiamas, nuskaitomas paskutinis eilės numeris ir nuo to skaičiaus pradedami nauji redagavimai.

Kaip jau keletą kartų aptariau, kad HFile yra pagrindinė nuolatinė HBase architektūros saugykla. Pagaliau visi duomenys yra skirti „HFile“, kuris yra nuolatinė „HBase“ saugykla. Taigi, pažvelkime į HFile savybes, kurios leidžia greičiau ieškoti skaitant ir rašant.

„HBase“ architektūra: „HBase Write“ Mechanizmas- HFailas

  • Rašymai dedami nuosekliai į diską. Todėl disko skaitymo ir rašymo galvutės judėjimas yra labai mažas. Tai labai palengvina rašymo ir paieškos mechanizmą.
  • HFile indeksai įkeliami į atmintį, kai tik atidaromas HFile failas. Tai padeda surasti įrašą vienu ieškojimu.
  • Priekaba yra rodyklė, nukreipianti į HFile meta bloką. Tai parašyta padarytos bylos pabaigoje. Jame yra informacijos apie laiko žymos ir žydėjimo filtrus.
  • „Bloom Filter“ padeda ieškoti pagrindinių reikšmių porų, praleidžia failą, kuriame nėra reikiamo eilutės. Laiko žymė taip pat padeda ieškoti failo versijos, ji padeda praleisti duomenis.

Sužinojęs rašymo mechanizmą ir įvairių komponentų vaidmenį, kad būtų galima greičiau rašyti ir ieškoti. Aš jums paaiškinsiu, kaip veikia skaitymo mechanizmas HBase architektūros viduje? Tada pereisime prie mechanizmų, kurie padidina HBase našumą, pvz., Sutankinimą, regiono padalijimą ir atkūrimą.

„HBase“ architektūra: Perskaitykite mechanizmą

Kaip aptarta mūsų paieškos mechanizme, pirmiausia klientas gauna regiono serverio vietą iš .META serverio, jei kliento jos nėra talpykloje. Tada eina nuoseklūs žingsniai taip:

  • Norėdami skaityti duomenis, skaitytuvas pirmiausia ieško eilutės langelio Blokuoti talpyklą. Čia saugomos visos neseniai perskaitytos raktų reikšmių poros.
  • Jei skaitytuvas neranda reikiamo rezultato, jis perkeliamas į „MemStore“, nes žinome, kad tai yra rašymo talpykla. Čia ji ieško naujausių parašytų failų, kurie dar nebuvo išmesti į „HFile“.
  • Pagaliau jis naudos žydėjimo filtrus ir blokuos talpyklą, kad įkeltų duomenis iš „HFile“.

Iki šiol aptariau HBase paieškos, skaitymo ir rašymo mechanizmą. Dabar mes pažvelgsime į HBase mechanizmą, kuris leidžia greitai ieškoti, skaityti ir rašyti HBase. Pirma, mes suprasime Tankinimas , kuris yra vienas iš tų mechanizmų.

„HBase“ architektūra: Tankinimas

HBase sujungia „HFiles“, kad sumažintų saugyklą ir sumažintų skaitymui reikalingų diskų skaičių. Šis procesas vadinamas sutankinimas . Tankinimas parenka keletą HF failų iš regiono ir juos sujungia. Yra du sutankinimo tipai, kaip matote aukščiau pateiktame paveikslėlyje.

  1. Nedidelis tankinimas : „HBase“ automatiškai parenka mažesnius HF failus ir rekomenduoja juos didesniems HF failams, kaip parodyta aukščiau pateiktame paveikslėlyje. Tai vadinama nedideliu tankinimu. Jis atlieka suliejimo rūšiavimą, kad mažesni HF failai būtų priskirti didesniems HF failams. Tai padeda optimizuoti saugojimo vietą.
  2. Pagrindinis tankinimas: Kaip parodyta aukščiau pateiktame paveikslėlyje, esant pagrindiniam sutankinimui, „HBase“ sujungia mažesnius regiono H failus į naują HF failą. Šiame procese tos pačios stulpelių šeimos kartu dedamos į naująjį HFile. Šiame procese ji numeta ištrintą ir pasibaigusį langelį. Tai padidina skaitymo efektyvumą.

Tačiau šio proceso metu įvesties-išvesties diskai ir tinklo srautas gali būti perpildyti. Tai žinoma kaip rašyti stiprinimą . Taigi, jis paprastai planuojamas esant žemai piko apkrovai.

Dabar atliksiu kitą efektyvumo optimizavimo procesą Splito regionas . Tai labai svarbu apkrovos balansavimui.

„HBase“ architektūra: Splito regionas

Žemiau pateiktame paveikslėlyje pavaizduotas regiono padalijimo mechanizmas.

duomenų struktūros ir algoritmai „Java“

Kai tik regionas tampa didelis, jis padalijamas į du vaikų regionus, kaip parodyta aukščiau pateiktame paveikslėlyje. Kiekvienas regionas sudaro lygiai pusę pagrindinio regiono. Tada apie šį padalijimą pranešama HMaster. Tai tvarko tas pats regiono serveris, kol HMaster paskirs juos naujam regiono serveriui apkrovos balansavimui.

Paskutinis, bet ne mažiau svarbus dalykas, paaiškinsiu, kaip „HBase“ atkuria duomenis po gedimo. Kaip mes tai žinome Nesėkmių atkūrimas yra labai svarbi „HBase“ savybė, todėl praneškite mums, kaip „HBase“ atkuria duomenis po gedimo.

„HBase“ architektūra: „HBase“ avarija ir duomenų atkūrimas

  • Kai regiono serveris sugenda, „ZooKeeper“ praneša „HMaster“ apie gedimą.
  • Tada HMaster paskirsto ir paskirsto sugedusio regiono serverio regionus daugeliui aktyvių regiono serverių. Norėdami atkurti nepavykusio regiono serverio „MemStore“ duomenis, HMaster paskirsto WAL visiems regiono serveriams.
  • Kiekvienas regiono serveris iš naujo vykdo WAL, kad sukurtų „MemStore“ to nepavykusio regiono stulpelių šeimai.
  • Duomenys rašomi chronologine tvarka (laiku) WAL. Todėl pakartotinai atlikti tą WAL reiškia atlikti visus pakeitimus, kurie buvo padaryti ir išsaugoti „MemStore“ faile.
  • Taigi, kai visi regiono serveriai įvykdo WAL, visos kolonos šeimos „MemStore“ duomenys yra atkuriami.

Tikiuosi, kad šis tinklaraštis būtų padėjęs suprasti HBase duomenų modelį ir HBase architektūrą. Tikiuosi, kad jums patiko. Dabar galite susieti su HBase funkcijomis (kurias aš paaiškinau savo ankstesnėje versijoje „HBase“ mokymo programa tinklaraštis) su „HBase Architecture“ ir suprasti, kaip ji veikia viduje. Dabar, kai žinote teorinę HBase dalį, turėtumėte pereiti prie praktinės dalies. Turint tai omenyje, kitas mūsų tinklaraštis paaiškins imtį HBase POC .

Dabar, kai supratote „HBase“ architektūrą, patikrinkite sukūrė „Edureka“ - patikima internetinė mokymosi įmonė, turinti daugiau nei 250 000 patenkintų besimokančiųjų tinklą. „Edureka Big Data Hadoop“ sertifikavimo mokymo kursai padeda besimokantiesiems tapti HDFS, verpalų, „MapReduce“, „Pig“, „Hive“, „HBase“, „Oozie“, „Flume“ ir „Sqoop“ ekspertais, naudojant realaus laiko naudojimo atvejus mažmeninės prekybos, socialinės žiniasklaidos, aviacijos, turizmo, finansų srityse.

Turite mums klausimą? Prašau paminėti tai komentarų skiltyje ir mes su jumis susisieksime.