Šiandienos pranešime aptarkime HBase architektūrą. Prieš įsigilindami į HBase architektūrą, patobulinkime savo HBase pagrindus.
„HBase“ - pagrindai:
„HBase“ yra atviro kodo „NoSQL“ platinama, nesusijusi, versijinė, daugialypė, į stulpelius orientuota parduotuvė, sukurta pagal „Google BigTable“, veikiančią ant HDFS. „NoSQL“ yra platus terminas, reiškiantis, kad duomenų bazė nėra RDBMS, palaikanti SQL kaip pagrindinę prieigos kalbą. Tačiau „NoSQL“ duomenų bazių yra daugybė tipų, o „Berkeley DB“ yra geras vietinės „NoSQL“ duomenų bazės pavyzdys, o „HBase“ yra labai paskirstyta duomenų bazė.
„HBase“ teikia visas „Google BigTable“ funkcijas. Tai prasidėjo kaip „Powerset“ projektas, skirtas apdoroti didžiulius duomenų kiekius natūralios kalbos paieškai. Jis buvo sukurtas kaip „Apache“ „Hadoop“ projekto dalis ir veikia kartu su HDFS („Hadoop Distributed File System“). Jame pateikiami atsparūs gedimams būdai, kaip saugoti didelį kiekį negausių duomenų. „HBase“ iš tikrųjų yra daugiau „duomenų saugykla“, o ne „duomenų bazė“, nes joje trūksta daugelio RDBMS esančių funkcijų, tokių kaip įvesti stulpeliai, antriniai indeksai, aktyvikliai ir išplėstinės užklausų kalbos ir kt.
Į stulpelius orientuotose duomenų bazėse duomenų lentelė saugoma kaip duomenų stulpelių sekcijos, o ne kaip duomenų eilutės. Į stulpelius orientuotos duomenų bazės duomenų modelį sudaro lentelės pavadinimas, eilutės raktas, stulpelių šeima, stulpeliai, laiko žyma. Kuriant lenteles „HBase“, eilutės bus unikaliai identifikuojamos eilutės klavišų ir laiko žymos pagalba. Šiame duomenų modelyje stulpelių šeima yra statiška, o stulpeliai yra dinamiški. Dabar pažvelkime į „HBase“ architektūrą.
Kada kreiptis į „HBase“?
„HBase“ yra geras pasirinkimas tik tada, kai yra šimtai milijonų ar milijardai eilučių. „HBase“ taip pat gali būti naudojamas vietose, kai ketinama pereiti iš RDBMS į „HBase“ kaip visišką pertvarkymą, o ne uostą. Kitaip tariant, „HBase“ nėra optimizuotas klasikinėms operacinėms programoms ar net reliacinei analizei. Tai taip pat nėra visiškas HDFS pakaitalas atliekant didelę „MapReduce“ partiją. Tada kodėl turėtumėte eiti į HBase? Jei jūsų programoje yra kintamoji schema, kurioje kiekviena eilutė šiek tiek skiriasi, turėtumėte pažvelgti į „HBase“.
„HBase“ architektūra:
Šis paveikslėlis aiškiai paaiškina „HBase“ architektūrą.
„HBase“ yra trys pagrindiniai komponentai: Meistras, regiono serveris ir zoologijos sodo prižiūrėtojas . Kiti komponentai yra Memstore, HFile ir WAL.
Kadangi „HBase“ veikia virš HDFS, ji naudoja „Master-Slave“ architektūrą, kurioje HMaster bus pagrindinis mazgas, o regiono serveriai yra vergo mazgai. Kai klientas siunčia rašymo užklausą, HMaster gauna šią užklausą ir persiunčia ją atitinkamam regiono serveriui.
Regiono serveris:
Tai sistema, veikianti panašiai kaip duomenų mazgas. Kai regiono serveris (RS) gauna rašymo užklausą, jis nukreipia užklausą į konkretų regioną. Kiekvienas regionas saugo eilučių rinkinį. Eilučių duomenis galima atskirti keliose stulpelių šeimose (CF). Konkretaus CF duomenys saugomi „HStore“, kurį sudaro „Memstore“ ir „HFiles“ rinkinys.
Ką veikia „Memstore“?
„Memstore“ stebi visus skaitymo ir rašymo operacijų, atliktų tame konkrečiame regiono serveryje, žurnalus. Iš to galime pasakyti, kad jis veikia panašiai kaip vardo mazgas Hadoope. „Memstore“ yra atminties atmintinė, todėl „Memstore“ naudoja kiekvieno duomenų mazgo atmintyje esančią atmintį žurnalams saugoti. Kai bus pasiektos tam tikros ribos, „Memstore“ duomenys bus perkelti į „HFile“.
Pagrindinis „Memstore“ naudojimo tikslas yra būtinybė saugoti duomenis DFS, surikiuotuose eilutės raktu. Kadangi HDFS yra skirtas nuosekliam skaitymui / rašymui be jokių failo modifikacijų, „HBase“ negali efektyviai rašyti duomenų į diską, nes jie gaunami: parašyti duomenys nebus rūšiuojami (kai įvestis nėra rūšiuojama), o tai reiškia, kad jie nėra optimizuoti ateičiai atgavimas. Norėdami išspręsti šią problemą, „HBase“ buferiai paskutinius duomenis, gautus atmintyje („Memstore“), „surūšiuoja“ juos prieš praplovimą ir tada rašo į HDFS naudodami greitus nuoseklius įrašus. Taigi HFile yra surūšiuotų eilučių sąrašas.
algoritmai ir duomenų struktūros Java
Kiekvieną kartą, kai „Memstore“ skalaujama po vieną HF failą, sukuriamą kiekvienam CF, o dažnas praplovimas gali sukelti daugybę HFile. Kadangi skaitydami „HBase“ turės pažvelgti į daugelį „HF“ failų, skaitymo greitis gali nukentėti. Siekiant užkirsti kelią per daug HFiles atidarymui ir išvengti skaitymo našumo, naudojamas HFiles sutankinimo procesas. „HBase“ periodiškai (kai bus įvykdytos tam tikros konfigūruojamos ribos) sutankins kelis mažesnius H failus į didelius. Akivaizdu, kad kuo daugiau failų, sukurtų „Memstore“, praplauna, tuo daugiau darbo (papildomos apkrovos) sistemai. Be to, nors tankinimo procesas paprastai atliekamas lygiagrečiai su kitų užklausų aptarnavimu ir kai „HBase“ negali suspėti sutankinti „HFiles“ (taip, tam taip pat yra sukonfigūruoti slenksčiai), jis vėl blokuos rašymą RS. Kaip jau aptarėme aukščiau, tai yra nepageidautina.
Mes negalime būti tikri, kad „Memstore“ duomenys išliks nuolat. Tarkime, kad tam tikras duomenų mazgas neveikia. Tada duomenys, esantys to duomenų mazgo atmintyje, bus prarasti.
Norėdami įveikti šią problemą, kai meistras pateikia užklausą, ji taip pat parašė WAL. WAL yra ne kas kita Rašyti prieš žurnalus kuri yra HDFS, nuolatinėje saugykloje. Dabar galime įsitikinti, kad net tada, kai duomenų mazgas neveikia, duomenys nebus prarasti, t. mes turime visų veiksmų, kuriuos turėtumėte atlikti WAL, kopiją. Kai duomenų mazgas bus aukštyn, jis vėl atliks visas veiklas. Kai operacija bus baigta, viskas bus pašalinta iš „Memstore“ ir WAL ir parašyta „HFile“, kad įsitikintume, jog mums netrūksta atminties.
Paimkime paprastą pavyzdį, kad noriu pridėti 10 eilutę, tada gaunama rašymo užklausa, sakoma, kad ji pateikia visus metaduomenis „Memstore“ ir „WAL“. Kai tik ši eilutė bus įrašyta į „HFile“, viskas „Memstore“ ir WAL bus ištrinta.
Zoologijos sodo prižiūrėtojas:
„HBase“ yra integruota su zoologijos sodo prižiūrėtoju. Kai paleidžiu „HBase“, taip pat paleidžiamas zoologijos sodo prižiūrėtojo egzempliorius. Priežastis ta, kad zoologijos sodo prižiūrėtojas padeda mums sekti visus regiono serverius, kurie yra HBase. Zoologijos sodo prižiūrėtojas stebi, kiek yra regiono serverių, kurie regiono serveriai laiko, iš kurio duomenų mazgo į kurį duomenų mazgą. Jis stebi mažesnius duomenų rinkinius, kur trūksta „Hadoop“. Tai sumažina viršutinę „Hadoop“ dalį, kuri stebi daugumą jūsų „Meta“ duomenų. Taigi HMaster gauna išsamią informaciją apie regiono serverius, iš tikrųjų susisiekusi su zoologijos sodo prižiūrėtoju.
Turite mums klausimą? Paminėkite juos komentarų skiltyje ir mes susisieksime su jumis.
Susijusios žinutės: