Arquitectura HBase
Al meu bloc anterior a Tutorial HBase , Vaig explicar què és HBase i les seves característiques. També he esmentat l’estudi de cas de Facebook Messenger per ajudar-vos a connectar millor. Ara seguim avançant en el nostre , Us explicaré el model de dades de HBase i HBase Architecture.Abans de seguir endavant, també heu de saber que HBase és un concepte important que constitueix una part integral del per a la certificació Big Data Hadoop.
Els temes importants que us examinaré en aquest bloc d’arquitectura HBase són:
- Model de dades HBase
- HBase Architecture i els seus components
- Mecanisme d’escriptura HBase
- Mecanisme de lectura HBase
- Mecanismes d’optimització del rendiment de l’HBase
Primer entenguem el model de dades de HBase. Ajuda HBase a fer cerques i lectura / escriptura més ràpides.
Arquitectura HBase: model de dades HBase
Com sabem, HBase és una base de dades NoSQL orientada a columnes. Tot i que té un aspecte similar a una base de dades relacional que conté files i columnes, però no és una base de dades relacional. Les bases de dades relacionals estan orientades a files, mentre que HBase està orientada a columnes. Per tant, comprenguem primer la diferència entre les bases de dades orientades a columnes i les orientades a files:
Bases de dades orientades a files o orientades a columnes:
- Les bases de dades orientades a files emmagatzemen els registres de taules en una seqüència de files. Mentre que les bases de dades orientades a columnesemmagatzemar registres de taules en una seqüència de columnes, és a dir, les entrades d’una columna s’emmagatzemen en ubicacions contigües dels discs.
Per entendre-ho millor, prenem un exemple i considerem la taula següent.
Si aquesta taula s’emmagatzema en una base de dades orientada a files. Emmagatzemarà els registres com es mostra a continuació:
1,Paul Walker,NOSALTRES,231,Gallardo,
2, Vin Diesel,Brasil,520,Mustang
A les bases de dades orientades a files, les dades s’emmagatzemen sobre la base de files o tuples, tal com podeu veure més amunt.
Tot i que les bases de dades orientades a columnes emmagatzemen aquestes dades com:
1,2, Paul Walker,Vin Diesel, NOSALTRES,Brasil, 231,520, Gallardo,Mustang
En una base de dades orientada a columnes, tots els valors de les columnes s’emmagatzemen junts, de la mateixa manera que els valors de la primera columna s’emmagatzemaran junts, després els valors de la segona columna s’emmagatzemaran junts i les dades d’altres columnes s’emmagatzemaran de manera similar.
- Quan la quantitat de dades és molt gran, com en termes de petabytes o exabytes, fem servir un enfocament orientat a columnes, perquè les dades d'una sola columna s'emmagatzemen juntes i s'hi pot accedir més ràpidament.
- Tot i que l'enfocament orientat a files gestiona comparativament menys nombre de files i columnes de manera eficient, ja que les bases de dades orientades a files emmagatzemen les dades és un format estructurat.
- Quan hem de processar i analitzar un gran conjunt de dades semiestructurades o no estructurades, fem servir un enfocament orientat a columnes. Com ara aplicacions que tracten Processament analític en línia com ara mineria de dades, emmagatzematge de dades, aplicacions que inclouen analítiques, etc.
- Considerant que, Processament transaccional en línia com ara els dominis bancaris i financers que gestionen dades estructurades i que requereixen propietats transaccionals (propietats ACID) utilitzen un enfocament orientat a files.
Les taules HBase tenen els components següents, que es mostren a la imatge següent:
- Taules : Les dades s’emmagatzemen en format de taula a HBase. Però aquí les taules estan en format orientat a columnes.
- Fila Clau : Les tecles de fila s'utilitzen per cercar registres que fan que les cerques siguin ràpides. Tindria curiositat per saber com? Ho explicaré a la part d'arquitectura que avança en aquest bloc.
- Columna Famílies : Es combinen diverses columnes en una família de columnes. Aquestes famílies de columnes s'emmagatzemen juntes, cosa que fa que el procés de cerca sigui més ràpid, ja que es pot accedir junt a les dades que pertanyen a la mateixa família de columnes en una sola cerca.
- Columna Eliminatoris : El nom de cada columna es coneix com a qualificador de columna.
- Cèl·lula : Les dades s’emmagatzemen a les cel·les. Les dades s’obtenen a cel·les que s’identifiquen específicament mitjançant els classificadors de les tecles de fila i de les columnes.
- Marca de temps : La marca de temps és una combinació de data i hora. Sempre que s’emmagatzemen dades, s’emmagatzemen amb la seva marca de temps. Això facilita la cerca d'una versió concreta de les dades.
D’una manera més senzilla i entenedora, podem dir que HBase consisteix en:
- Conjunt de taules
- Cada taula amb famílies de columnes i files
- La clau de fila actua com a clau primària a HBase.
- Qualsevol accés a les taules HBase utilitza aquesta clau principal
- Cada qualificador de columna present a HBase denota l'atribut corresponent a l'objecte que resideix a la cel·la.
Ara que coneixeu el model de dades HBase, vegeu-nos com aquest model de dades s’adiu amb HBase Architecture i el fa adequat per a un gran emmagatzematge i un processament més ràpid.
Arquitectura HBase: components de l'arquitectura HBase
HBase té tres components principals, és a dir, Servidor HMaster , HBase Region Server, Regions i Guardià zoològic .
La figura següent explica la jerarquia de l'arquitectura HBase. En parlarem de cadascun d’ells de forma individual.
Ara, abans d’anar a l’HMaster, entendrem Regions ja que tots aquests servidors (HMaster, Region Server, Zookeeper) estan situats per coordinar i gestionar les Regions i realitzar diverses operacions dins de les Regions. Per tant, tindríeu curiositat per saber què són les regions i per què són tan importants?
Arquitectura HBase: Regió
Una regió conté totes les files entre la clau d'inici i la clau final assignades a aquesta regió. Les taules HBase es poden dividir en diverses regions de manera que totes les columnes d'una família de columnes s'emmagatzemin en una regió. Cada regió conté les files en un ordre ordenat.
Moltes regions estan assignades a Servidor de la regió , que s’encarrega de gestionar, gestionar, executar operacions de lectura i escriptura en aquest conjunt de regions.
Per tant, per concloure d’una manera més senzilla:
- Una taula es pot dividir en diverses regions. Una regió és un rang ordenat de files que emmagatzemen dades entre una clau d'inici i una de final.
- Una regió té una mida predeterminada de 256 MB que es pot configurar segons la necessitat.
- Un servidor de regions proporciona als clients un grup de regions.
- Un servidor de regions pot servir aproximadament 1.000 regions per al client.
Ara, començant per la part superior de la jerarquia, voldria explicar-vos primer sobre HMaster Server, que actua de manera similar com a NameNode a HDFS . A continuació, passant per la jerarquia, us guiaré per ZooKeeper i Region Server.
Arquitectura HBase: HMaster
Com a la imatge següent, podeu veure que l'HMaster gestiona una col·lecció de Region Server que resideix a DataNode. Comprenguem com ho fa HMaster.
- HBase HMaster realitza operacions DDL (crea i suprimeix taules) i assigna regions als servidors Region com podeu veure a la imatge anterior.
- Coordina i gestiona el servidor de la regió (similar a com NameNode gestiona DataNode a HDFS).
- Assigna regions als servidors de regions a l’inici i torna a assignar regions als servidors de regions durant la recuperació i l’equilibri de càrrega.
- Supervisa totes les instàncies del servidor de regió al clúster (amb l'ajuda de Zookeeper) i realitza activitats de recuperació sempre que qualsevol servidor de regió estigui inactiu.
- Proporciona una interfície per crear, suprimir i actualitzar taules.
HBase disposa d’un entorn enorme i distribuït on només HMaster no és suficient per gestionar-ho tot. Per tant, us preguntareu què ajuda HMaster a gestionar aquest enorme entorn? Aquí és on entra en escena ZooKeeper. Després d’entendre com HMaster gestiona l’entorn HBase, comprendreem com Zookeeper ajuda HMaster a gestionar l’entorn.
Arquitectura HBase: ZooKeeper: el coordinador
Aquesta imatge següent explica el mecanisme de coordinació de ZooKeeper.
- Zookeeper actua com un coordinador a l’entorn distribuït de HBase. Ajuda a mantenir l’estat del servidor dins del clúster mitjançant la comunicació a través de sessions.
- Tots els servidors de la regió juntament amb el servidor HMaster envien batecs continus a intervals regulars a Zookeeper i comprova quin servidor està viu i està disponible, tal com s’esmenta a la imatge anterior. També proporciona notificacions d'errors del servidor perquè es puguin executar mesures de recuperació.
- Referint-vos a la imatge anterior que podeu veure, hi ha un servidor inactiu que actua com a còpia de seguretat del servidor actiu. Si el servidor actiu falla, es tracta del rescat.
- L'HMaster actiu envia els batecs del cor al Zookeeper mentre l'HMaster inactiu escolta la notificació enviada per l'HMaster actiu. Si l'HMaster actiu no envia un batec del cor, la sessió s'elimina i l'HMaster inactiu es torna actiu.
- Si bé un servidor de regió no envia un batec del cor, la sessió caduca i se n’informa a tots els oients. A continuació, HMaster realitza les accions de recuperació adequades que parlarem més endavant en aquest bloc.
- Zookeeper també manté el camí del servidor .META, que ajuda qualsevol client a cercar qualsevol regió. El client primer ha de comprovar amb el servidor .META a quin servidor de regió pertany una regió i obté la ruta d’aquest servidor de regió.
Mentre parlava del servidor .META, permeteu-me explicar-vos primer què és el servidor .META? Per tant, podeu relacionar fàcilment la feina de ZooKeeper i el servidor .META. Més endavant, quan us expliqui el mecanisme de cerca de HBase en aquest bloc, explicaré com funcionen aquests dos en col·laboració.
Arquitectura HBase: Meta Taula
- La taula META és una taula especial del catàleg de HBase. Manté una llista de tots els servidors de les regions al sistema d’emmagatzematge HBase, com podeu veure a la imatge anterior.
- Mirant la figura que podeu veure, .META file manté la taula en forma de claus i valors. La clau representa la clau d'inici de la regió i el seu identificador, mentre que el valor conté la ruta del servidor de la regió.
Com ja he comentat, Region Server i les seves funcions mentre us explicava les regions, per tant, ara baixem per la jerarquia i em centraré en el component del servidor del Region i les seves funcions. Més endavant parlaré del mecanisme de cerca, lectura, escriptura i entenc com funcionen tots aquests components junts.
Arquitectura HBase: Components del servidor de regió
La imatge següent mostra els components d'un servidor de regió. Ara, els parlaré per separat.
Un servidor de regions manté diverses regions que funcionen a la part superior de . Els components d'un servidor de regió són:
java com acabar el programa
- WAL: Com podeu concloure per la imatge anterior, Write Ahead Log (WAL) és un fitxer adjunt a tots els servidors de la regió dins de l’entorn distribuït. El WAL emmagatzema les dades noves que no s’han conservat ni compromès amb l’emmagatzematge permanent. S'utilitza en cas que no es recuperin els conjunts de dades.
- Bloqueja la memòria cau: A la imatge anterior, es veu clarament que Block Cache resideix a la part superior del servidor de regió. Emmagatzema les dades de lectura freqüent a la memòria. Si les dades de BlockCache s’utilitzen menys recentment, aquestes dades s’eliminen de BlockCache.
- MemStore: És la memòria cau d'escriptura. Emmagatzema totes les dades entrants abans de lliurar-les al disc o a la memòria permanent. Hi ha un MemStore per a cada família de columnes d'una regió. Com podeu veure a la imatge, hi ha diverses botigues MemStore per a una regió perquè cada regió conté diverses famílies de columnes. Les dades s’ordenen per ordre lexicogràfic abans d’enviar-les al disc.
- Fitxer H: A la figura anterior es pot veure com HFile s’emmagatzema a HDFS. Així, emmagatzema les cel·les reals al disc. MemStore confia les dades a HFile quan la mida de MemStore supera.
Ara que coneixem els components principals i menors de l'arquitectura HBase, explicaré el mecanisme i el seu esforç col·laboratiu en això. Tant si es tracta de llegir com d’escriure, primer hem de buscar des d’on llegir o des d’on escriure un fitxer. Per tant, entenguem aquest procés de cerca, ja que aquest és un dels mecanismes que fan que HBase sigui molt popular.
Arquitectura HBase: Com s’inicialitza la cerca a HBase?
Com ja sabeu, Zookeeper emmagatzema la ubicació de la taula META. Sempre que un client s'apropa amb una petició de lectura o escriptura a HBase es produeix la següent operació:
- El client recupera la ubicació de la taula META des del ZooKeeper.
- A continuació, el client sol·licita la ubicació del servidor de regió de la clau de fila corresponent a la taula META per accedir-hi. El client emmagatzema aquesta informació amb la ubicació de la taula META.
- Llavors obtindrà la ubicació de la fila sol·licitant-ho al servidor de regió corresponent.
Per a futures referències, el client utilitza la memòria cau per recuperar la ubicació de la taula META i llegir prèviament el servidor de regió de la clau de fila. Aleshores, el client no es referirà a la taula META, fins que no es produeixi cap error perquè la regió es desplaça o es mou. Després tornarà a sol·licitar al servidor META i actualitzarà la memòria cau.
Com cada vegada, els clients no perden el temps en recuperar la ubicació del servidor regional de META Server, de manera que això estalvia temps i fa que el procés de cerca sigui més ràpid. Ara, deixeu-me explicar-vos com es fa l'escriptura a HBase. Quins són els components que hi intervenen i com intervenen?
Arquitectura HBase: HBase Write Mecanisme
Aquesta imatge següent explica el mecanisme d'escriptura a HBase.
El mecanisme d'escriptura passa pel següent procés de manera seqüencial (consulteu la imatge anterior):
Pas 1: Sempre que el client té una sol·licitud d’escriptura, el client escriu les dades al registre WAL (Write Ahead Log).
- Les modificacions s’afegeixen al final del fitxer WAL.
- Aquest fitxer WAL es manté a cada servidor de regió i el servidor de regió el fa servir per recuperar dades que no estan compromeses amb el disc.
Pas 2: Un cop les dades s’escriuen al WAL, es copien al MemStore.
Pas 3: Un cop les dades es col·loquen a MemStore, el client rebrà l'acceptació.
Pas 4: Quan MemStore arriba al llindar, aboca o confia les dades en un fitxer HFile.
Ara fem una immersió profunda i entenem com MemStore contribueix en el procés d'escriptura i quines són les seves funcions?
HBase Write Mecanisme MemStore
- El MemStore sempre actualitza les dades emmagatzemades en un ordre lexicogràfic (de manera seqüencial en diccionari) com a KeyValues ordenats. Hi ha un MemStore per a cada família de columnes i, per tant, les actualitzacions s’emmagatzemen de manera ordenada per a cada família de columnes.
- Quan MemStore arriba al llindar, bolca totes les dades en un fitxer HF nou de manera ordenada. Aquest fitxer HF s’emmagatzema a HDFS. HBase conté diversos fitxers HF per a cada família de columnes.
- Amb el pas del temps, el nombre de fitxers HF creix a mesura que MemStore aboca les dades.
- MemStore també desa l'últim número de seqüència escrit, de manera que Master Server i MemStore saben que el que s'ha compromès fins ara i d'on s'ha de començar. Quan s'inicia la regió, es llegeix l'últim número de seqüència i, a partir d'aquest número, comencen les noves modificacions.
Com he comentat diverses vegades, aquest fitxer HFile és el principal emmagatzematge persistent en una arquitectura HBase. Per fi, totes les dades es destinen a HFile, que és l’emmagatzematge permanent d’HBase. Per tant, vegem les propietats de HFile que fa que la cerca sigui més ràpida mentre es llegeix i s’escriu.
Arquitectura HBase: HBase Write Mecanisme Fitxer H
- Les escriptures es col·loquen de manera seqüencial al disc. Per tant, el moviment del capçal de lectura i escriptura del disc és molt menor. Això fa que el mecanisme d’escriptura i cerca sigui molt ràpid.
- Els índexs HFile es carreguen a la memòria sempre que s'obre un fitxer HFile. Això ajuda a trobar un registre en una sola cerca.
- El tràiler és un punter que apunta al meta bloc de l’HFile. S'escriu al final del fitxer compromès. Conté informació sobre els filtres de marca de temps i de floració.
- Bloom Filter ajuda a buscar parells de valors clau, omet el fitxer que no conté la clau de fila necessària. La marca de temps també ajuda a cercar una versió del fitxer, ajuda a ometre les dades.
Després de conèixer el mecanisme d'escriptura i el paper de diversos components a l'hora d'escriure i cercar més ràpidament. Us explicaré com funciona el mecanisme de lectura dins d’una arquitectura HBase? Després passarem als mecanismes que augmenten el rendiment de l'HBase com la compactació, la divisió de la regió i la recuperació.
Arquitectura HBase: Llegiu Mecanisme
Tal com es comenta al nostre mecanisme de cerca, primer el client recupera la ubicació del servidor de regió del servidor .META si el client no el té a la memòria cau. A continuació, passa pels passos seqüencials de la següent manera:
- Per llegir les dades, l’escàner primer cerca la cel·la de fila a la memòria cau del bloc. Aquí s’emmagatzemen tots els parells de valors de claus llegits recentment.
- Si Scanner no troba el resultat requerit, es trasllada al MemStore, ja que sabem que aquesta és la memòria cau d'escriptura. Allà, cerca els fitxers escrits més recentment, que encara no s’han enviat a HFile.
- Per fi, utilitzarà filtres Bloom i bloquejarà la memòria cau per carregar les dades des de HFile.
Fins ara he parlat del mecanisme de cerca, lectura i escriptura de HBase. Ara veurem el mecanisme HBase que fa que la cerca, la lectura i l’escriptura siguin ràpides a HBase. En primer lloc, ho entendrem Compactació , que és un d’aquests mecanismes.
Arquitectura HBase: Compactació
Base HB combina fitxers HF per reduir l'emmagatzematge i reduir el nombre de cerques de disc necessàries per a una lectura. Aquest procés s’anomena compactació . La compactació tria alguns fitxers HF d'una regió i els combina. Hi ha dos tipus de compactació com podeu veure a la imatge anterior.
- Compactació menor : HBase selecciona automàticament fitxers HF més petits i els recomana a fitxers HF més grans, tal com es mostra a la imatge anterior. Això s’anomena compactació menor. Realitza una classificació de combinació per confiar fitxers HFiles més petits a fitxers HFiles més grans. Això ajuda a l'optimització de l'espai d'emmagatzematge.
- Major compactació: Com es il·lustra a la imatge anterior, a la compactació major, HBase combina i recomana els fitxers HF més petits d'una regió a un nou fitxer HFile. En aquest procés, les mateixes famílies de columnes es col·loquen juntes al nou fitxer HFile. Deixa caure la cel·la eliminada i caducada en aquest procés. Augmenta el rendiment de la lectura.
Però durant aquest procés, els discs d’entrada-sortida i el trànsit de la xarxa es poden congestionar. Això es coneix com amplificació d’escriptura . Per tant, generalment es programa durant els temps de càrrega màxima baixos.
Ara un altre procés d’optimització del rendiment que parlaré és Regió dividida . Això és molt important per a l'equilibri de càrrega.
Arquitectura HBase: Regió dividida
La figura següent il·lustra el mecanisme de divisió de regió.
Sempre que una regió es fa gran, es divideix en dues regions fill, tal com es mostra a la figura anterior. Cada regió representa exactament la meitat de la regió pare. A continuació, aquesta divisió s'informa a l'HMaster. El mateix servidor de regió ho gestiona fins que l'HMaster els assigna a un servidor de regió nou per a l'equilibri de càrrega.
Passant per la línia, per últim, però no per això menys important, us explicaré com recupera HBase les dades després d’un error. Com ho sabem Recuperació de fallades és una característica molt important d’HBase, per tant, feu-nos saber com HBase recupera les dades després d’un error.
Arquitectura HBase: HBase Crash i recuperació de dades
- Sempre que falla un servidor de regió, ZooKeeper notifica a l'HMaster la fallada.
- A continuació, HMaster distribueix i assigna les regions del servidor de regió bloquejat a molts servidors de regió actius. Per recuperar les dades del MemStore del servidor de regió fallit, l'HMaster distribueix el WAL a tots els servidors de regions.
- Cada servidor de regió torna a executar el WAL per crear el MemStore per a la família de columnes de la regió que ha fallat.
- Les dades s’escriuen en ordre cronològic (en un ordre oportú) en WAL. Per tant, tornar a executar aquest WAL significa fer tots els canvis realitzats i emmagatzemats al fitxer MemStore.
- Per tant, després que tots els servidors de regió executin el WAL, es recuperen les dades MemStore per a tota la família de columnes.
Espero que aquest bloc us hagués ajudat a subestimar el model de dades HBase i l'arquitectura HBase. Espero que us hagi agradat. Ara podeu relacionar-vos amb les funcions de HBase (que us explicava a la meva versió anterior Tutorial HBase bloc) amb HBase Architecture i entendre com funciona internament. Ara que ja coneixeu la part teòrica de HBase, heu de passar a la part pràctica. Tenint en compte això, el nostre proper bloc de explicarà una mostra HBase POC .
Ara que heu entès l'arquitectura HBase, consulteu el fitxer per Edureka, una empresa d'aprenentatge en línia de confiança amb una xarxa de més de 250.000 estudiants satisfets repartits per tot el món. El curs de formació en certificació Edureka Big Data Hadoop ajuda els estudiants a convertir-se en experts en HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume i Sqoop mitjançant casos d’ús en temps real en dominis Retail, Social Media, Aviació, Turisme, Finances
Tens alguna pregunta? Esmenta’l a la secció de comentaris i et respondrem.