A la publicació d’avui parlem sobre l’arquitectura HBase. Analitzem els nostres conceptes bàsics d’HBase abans d’aprofundir en l’arquitectura HBase.
HBase - Conceptes bàsics:
HBase és una botiga de codi obert, NoSQL, distribuïda, no relacional, versionada, multidimensional, orientada a columnes, que s’ha modelat segons Google BigTable que s’executa a la part superior d’HDFS. '' NoSQL 'és un terme ampli que significa que la base de dades no és un RDBMS que admet SQL com a llenguatge principal d'accés. Però hi ha molts tipus de bases de dades NoSQL i Berkeley DB és un bon exemple de base de dades NoSQL local, mentre que HBase és gairebé una base de dades distribuïda.
HBase proporciona totes les funcions de Google BigTable. Va començar com un projecte de Powerset per processar grans quantitats de dades per a la cerca de llenguatge natural. Es va desenvolupar com a part del projecte Hadoop d’Apache i s’executa a la part superior de HDFS (Hadoop Distributed File System). Proporciona formes d’emmagatzemar grans quantitats de dades disperses que toleren els errors. HBase és realment més un 'magatzem de dades' que una 'base de dades' perquè no disposa de moltes de les funcions disponibles en RDBMS, com ara columnes mecanografiades, índexs secundaris, activadors i llenguatges de consulta avançats, etc.
com crear fitxers de registre a Java
A les bases de dades orientades a columnes, la taula de dades s’emmagatzema com a seccions de columnes de dades en lloc de com a files de dades. El model de dades de la base de dades orientada a columnes consta de nom de taula, clau de fila, família de columnes, columnes, segell de temps. Mentre es creen taules a HBase, les files s’identificaran de manera única amb l’ajut de les claus de fila i el segell de temps. En aquest model de dades, la família de columnes és estàtica, mentre que les columnes són dinàmiques. Vegem ara l'arquitectura HBase.
Quan optar per HBase?
HBase és una bona opció només quan hi ha centenars de milions o milers de milions de files. HBase també es pot utilitzar en alguns llocs quan es vol passar d'un RDBMS a HBase com a redisseny complet en lloc d'un port, és a dir, HBase no està optimitzat per a aplicacions transaccionals clàssiques o fins i tot per a anàlisis relacionals. Tampoc no és un substitut complet de HDFS quan es fa MapReduce per lots grans. Llavors, per què heu d’anar per HBase ?? Si l'aplicació té un esquema variable en què cada fila és lleugerament diferent, hauríeu de mirar HBase.
Arquitectura HBase:
La següent figura explica clarament l’arquitectura HBase.
A HBase, hi ha tres components principals: Mestre, servidor de regió i guarda del zoo . Els altres components són Memstore, HFile i WAL.
Com que HBase s'executa a la part superior de HDFS, utilitza l'arquitectura Master-Slave en què l'HMaster serà el node principal i els servidors de regió són els nodes esclaus. Quan el client envia una sol·licitud d’escriptura, HMaster obté aquesta sol·licitud i la reenvia al servidor de regió respectiu.
Servidor de la regió:
És un sistema que actua de manera similar a un node de dades. Quan el servidor de regió (RS) rep una sol·licitud d’escriptura, la dirigeix a una regió específica. Cada regió emmagatzema un conjunt de files. Les dades de files es poden separar en diverses famílies de columnes (CF). Les dades de CF concretes s’emmagatzemen a HStore, que consta de Memstore i un conjunt de fitxers HFiles.
Què fa Memstore?
Memstore fa un seguiment de tots els registres de les operacions de lectura i escriptura que s'han dut a terme dins del servidor de regió en particular. A partir d'això podem dir que actua de manera similar a un node de nom a Hadoop. Memstore és un emmagatzematge en memòria, de manera que Memstore utilitza l’emmagatzematge en memòria de cada node de dades per emmagatzemar els registres. Quan es compleixen certs llindars, les dades de Memstore s’emmagatzemen a HFile.
El propòsit clau per utilitzar Memstore és la necessitat d’emmagatzemar dades en DFS ordenades per clau de fila. Com que HDFS està dissenyat per a lectures / escriptures seqüencials, sense que es permetin modificacions de fitxers, HBase no pot escriure dades de manera eficient al disc mentre es reben: les dades escrites no s’ordenaran (quan l’entrada no s’ordena), cosa que significa que no s’optimitza per al futur recuperació. Per solucionar aquest problema, les memòries intermèdies HBase van rebre per última vegada les dades a la memòria (a Memstore), les 'ordenen' abans de rentar-les i després escriuen a HDFS mitjançant escriptures seqüencials ràpides. Per tant, HFile conté una llista de files ordenades.
què fa un iterador a Java
Cada vegada que es produeix un buidat de Memstore, es crea un fitxer HF per a cada CF i els buits freqüents poden crear tones de fitxers HF. Com que durant la lectura, HBase haurà de mirar molts fitxers HF, la velocitat de lectura pot patir. Per evitar obrir massa fitxers HF i evitar un deteriorament del rendiment de la lectura, s’utilitza el procés de compactació HFiles. HBase periòdicament (quan es compleixin determinats llindars configurables) compactarà diversos fitxers HF més petits en un de gran. Viouslybviament, com més fitxers creats per Memstore flueix, més treball (càrrega addicional) per al sistema. A més, tot i que el procés de compactació es realitza en paral·lel al servei d’altres peticions i quan HBase no pot mantenir-se al dia amb la compactació de fitxers HF (sí, també hi ha llindars configurats), bloquejarà de nou les escriptures a RS. Com hem comentat anteriorment, això és altament indesitjable.
No podem estar segurs que les dades siguin persistents a Memstore. Suposem que un datanode concret està inactiu. Aleshores, es perdran les dades que resideixen a la memòria d’aquest node de dades.
Per superar aquest problema, quan la sol·licitud prové del mestre, també la va escriure a WAL. WAL no és res més que Escriviu registres per endavant que resideix a l’HDFS, un emmagatzematge permanent. Ara podem assegurar-nos que, fins i tot si el node de dades està baix, les dades no es perdran, és a dir. tenim la còpia de totes les accions que se suposa que heu de fer al WAL. Quan el node de dades estigui activat, tornarà a realitzar totes les activitats. Un cop finalitzada l’operació, tot s’esborra de Memstore i WAL i s’escriu a HFile per tal d’assegurar-nos que no ens quedem sense memòria.
Prenguem un exemple senzill que vull afegir la fila 10 i que aparegui la sol·licitud d'escriptura, que diu que dóna totes les meta dades al Memstore i al WAL. Un cop escrita aquesta fila en particular a HFile, tot a Memstore i WAL es buiden.
Guardià del zoo:
HBase ve integrat amb Zoo keeper. Quan inicio HBase, també s’inicia la instància del guardià del zoo. La raó és que Zoo Keeper ens ajuda a fer un seguiment de tots els servidors de la regió que hi ha per a HBase. Zoo Keeper fa un seguiment de quants servidors de regió hi ha, quins servidors de regions contenen des de quin node de dades a quin node de dades. Realitza un seguiment de conjunts de dades més petits on hi falta Hadoop. Disminueix les despeses generals a la part superior de Hadoop, que fa un seguiment de la majoria de les vostres dades Meta. Per tant, HMaster obté els detalls dels servidors de la regió contactant realment amb el responsable del zoo.
Tens alguna pregunta? Esmenta’ls a la secció de comentaris i et respondrem.
combinar matriu de tipus C ++
Articles Relacionats: