V dnešnom príspevku poďme diskutovať o architektúre HBase. Poďme si oprášiť naše základy HBase, než sa ponoríme hlbšie do architektúry HBase.
HBase - základy:
HBase je open-source, NoSQL, distribuovaný, nerelačný, verzovaný, viacrozmerný, stĺpcovo orientovaný obchod, ktorý bol modelovaný podľa Google BigTable, ktorý beží nad HDFS. „NoSQL“ je široký pojem, čo znamená, že databáza nie je RDBMS, ktorá podporuje SQL ako primárny prístupový jazyk. Existuje však veľa typov databáz NoSQL a Berkeley DB je dobrým príkladom miestnej databázy NoSQL, zatiaľ čo HBase je veľmi distribuovaná databáza.
HBase poskytuje všetky funkcie Google BigTable. Začalo to ako projekt spoločnosti Powerset na spracovanie obrovského množstva údajov na vyhľadávanie v prirodzenom jazyku. Bol vyvinutý ako súčasť projektu Apache’s Hadoop a beží nad HDFS (Hadoop Distributed File System). Poskytuje spôsoby odolné voči chybám na ukladanie veľkého množstva riedkych údajov. HBase je skutočne viac „Data Store“ ako „Data Base“, pretože mu chýba veľa funkcií dostupných v RDBMS, ako sú typizované stĺpce, sekundárne indexy, triggery a jazyky pokročilých dotazov atď.
algoritmus triedenia v c ++
V stĺpcovo orientovaných databázach sa údajová tabuľka ukladá skôr ako úseky stĺpcov údajov ako ako riadky údajov. Dátový model stĺpcovo orientovanej databázy pozostáva z názvu tabuľky, kľúča riadku, rodiny stĺpcov, stĺpcov, časovej pečiatky. Pri vytváraní tabuliek v HBase budú riadky jedinečne identifikované pomocou klávesov riadkov a časovej pečiatky. V tomto dátovom modeli sú rodiny stĺpcov statické, zatiaľ čo stĺpce sú dynamické. Teraz sa pozrime na architektúru HBase.
Kedy ísť na HBase?
HBase je dobrá voľba, iba ak existujú stovky miliónov alebo miliardy riadkov. HBase sa dá použiť aj na miestach, keď uvažujete o prechode z RDBMS na HBase ako úplnom prepracovaní oproti portu. Inými slovami, HBase nie je optimalizovaný pre klasické transakčné aplikácie alebo dokonca pre relačné analýzy. Tiež to nie je úplná náhrada za HDFS, keď robíte veľké dávky MapReduce. Prečo by ste potom mali ísť na HBase ?? Ak má vaša aplikácia variabilnú schému, kde sa každý riadok mierne líši, mali by ste sa pozrieť na HBase.
Architektúra HBase:
Nasledujúci obrázok jasne vysvetľuje architektúru HBase.
V HBase existujú tri hlavné komponenty: Majster, server regiónu a držiteľ zoo . Ostatné komponenty sú Memstore, HFile a WAL.
Pretože HBase beží nad HDFS, využíva architektúru Master-Slave, v ktorej bude HMaster hlavným uzlom a regionálne servery sú podradenými uzlami. Keď klient pošle požiadavku na zápis, HMaster dostane túto požiadavku a preposiela ju na príslušný Region Server.
Server regiónu:
Je to systém, ktorý funguje podobne ako dátový uzol. Keď Region Server (RS) prijme požiadavku na zápis, nasmeruje ju do konkrétneho regiónu. Každý región ukladá množinu riadkov. Údaje riadkov je možné rozdeliť do viacerých skupín stĺpcov (CF). Dáta konkrétneho CF sú uložené v HStore, ktorý pozostáva z Memstore a sady súborov HF.
Čo robí Memstore?
Memstore sleduje všetky protokoly operácií čítania a zápisu, ktoré boli vykonané v danom serveri konkrétnej oblasti. Z toho môžeme povedať, že sa správa podobne ako uzol názvu v Hadoope. Memstore je pamäť uložená v pamäti, takže pamäť Memstore využíva na ukladanie protokolov pamäťovú kartu každého dátového uzla. Keď sú splnené určité prahové hodnoty, dáta Memstore sa vyprázdnia do HFile.
Kľúčovým účelom používania Memstore je potreba ukladať údaje na DFS zoradené podľa kľúča riadku. Pretože HDFS je navrhnutý pre sekvenčné čítanie / zápis, bez povolených úprav súborov, HBase nemôže efektívne zapisovať dáta na disk tak, ako je prijatý: zapísané dáta nebudú zoradené (pokiaľ nie je zoradený vstup), čo znamená, že nebudú optimalizované pre budúcnosť načítanie. Na vyriešenie tohto problému medzipamäte HBase naposledy prijali údaje do pamäte (v Memstore), pred vyprázdnením ich „roztriedia“ a potom zapisujú na HDFS pomocou rýchlych postupných zápisov. Preto HFile obsahuje zoznam zoradených riadkov.
Zakaždým, keď dôjde k vyprázdneniu Memstore, pre každý CF sa vytvorí jeden súbor HFile a časté vyplavovanie môže vytvoriť veľa súborov HF. Pretože počas čítania sa HBase bude musieť pozrieť na veľa súborov HF, rýchlosť čítania môže trpieť. Aby sa zabránilo otvoreniu príliš veľa súborov HFiles a zabránilo sa zhoršeniu výkonu čítania, používa sa proces zhutňovania súborov HFiles. HBase bude periodicky (pri dosiahnutí určitých konfigurovateľných prahových hodnôt) zhustiť viac menších súborov HF do veľkého súboru. Je zrejmé, že čím viac súborov vytvorených Memstore spláchne, tým viac práce (extra zaťaženie) pre systém. K tomu sa pridáva, že zatiaľ čo proces zhutňovania sa zvyčajne vykonáva súbežne s poskytovaním iných požiadaviek a keď HBase nedokáže držať krok s zhutňovaním súborov HFiles (áno, aj pre to sú nakonfigurované prahové hodnoty), bude blokovanie zápisov na RS znova. Ako sme už diskutovali vyššie, je to veľmi nežiaduce.
Nemôžeme si byť istí, že údaje budú v Memstore trvalé. Predpokladajme, že konkrétny datanód nefunguje. Potom sa stratia údaje, ktoré sa nachádzajú v pamäti tohto dátového uzla.
Na prekonanie tohto problému, keď požiadavka pochádza z hlavného servera, sa tiež napísala na WAL. WAL nie je nič iné ako Píšte záznamy dopredu ktorý sa nachádza na HDFS, trvalom úložisku. Teraz sa môžeme ubezpečiť, že aj keď bude dátový uzol dole, dáta sa nestratia, t.j. máme kópiu všetkých akcií, ktoré máte robiť vo WAL. Keď je dátový uzol hore, vykoná znova všetky činnosti. Akonáhle je operácia dokončená, všetko je vyprázdnené z Memstore a WAL a je zapísané do HFile, aby sme sa uistili, že nám nedochádza pamäť.
Zoberme si jednoduchý príklad, že chcem pridať riadok 10, potom príde požiadavka na zápis, hovorí, že dáva všetky meta údaje do Memstore a WAL. Akonáhle je daný riadok zapísaný do HFile, všetko v Memstore a WAL je vyprázdnené.
Ošetrovateľ v zoo:
HBase je integrovaný s držiteľom Zoo. Keď spustím HBase, spustí sa aj inštancia držiteľa zoo. Dôvod je ten, že strážca zoo nám pomáha sledovať všetky regionálne servery, ktoré sú tu pre HBase. Prevádzkovateľ zoo sleduje, koľko serverov regiónov sa nachádza, ktoré servery regiónov zadržiavajú z ktorého dátového uzla do ktorého dátového uzla. Sleduje menšie dátové súbory, kde chýba Hadoop. Znižuje réžiu nad Hadoopom, ktorý sleduje väčšinu vašich metaúdajov. Preto HMaster získa podrobnosti o regionálnych serveroch kontaktovaním správcu zoo.
Máte na nás otázku? Uveďte ich v sekcii komentárov a my sa vám ozveme.
Súvisiace príspevky: