Un dels problemes que tenim els usuaris de Hadoop és que estem treballant amb uns volums de dades considerables. En cas contrari seria millor utilitzar Python o Erlang o una base de dades relacional (insisteixo una vegada més, Hadoop si i només si s'ha de treballar amb moltes dades). Com ja he explicat en altres posts un dels sub-projectes de Hadoop és el sistema de fitxers, fet a inspiració del Google File System (GFS). És un sistema redundant i distribuït, per tant cada fitxer està fragmentat per la xarxa i n'hi ha diverses còpies. Això implica que sigui molt difícil perdre un fitxer (ja que n'hi ha 3 còpies diferents), però al mateix moment es fa més complicat poder accedir a aquest fitxer, ja que qualsevol manipulació que se li vulgui aplicar (sense un treball map/reduce de Hadoop) força que s'hagi de baixar del clúster, i aquests fitxers poden arribar a ser molt grans (molt molt grans).
Això a efectes pràctics significa que no es pot fer de forma senzilla un 'grep' per buscar continguts. El fitxer està repartit pel clúster per tant, s'ha de fer un treball map-reduce per fer el grep. El codi de hadoop ja porta implementada aquesta utilitat, però igualment és incòmode i poc potent.
En principi no hauria de ser un problema, ja que normalment interessa processar una entrada i un cop tenim la sortida a punt la baixem tota del clúster per servir-la a la pàgina web, per inserir-la a la base de dades o el que sigui. El problema ve quan necessites saber (urgentment) una certa línia d'un fitxer de 200 Gb que està fragmentat dins el clúster.
Potser això és una mica difícil d'entendre, un exemple:
Com sabeu fa poc es va morir Michael Jackson, doncs bé, quan la noticia es va escampar la gent va començar a escoltar la seva música. A last.fm vam començar a rebre scrobbles de Michael Jackson, aquests scrobbles, que basicament hi ha l'identificador d'usuari i la cançó que aquest ha escoltat es guarden al sistema de fitxers distribuït per a ser processats per Hadoop. No ens volíem esperar a que fos al vespre per saber quanta gent de més havia escoltat al difunt rei del pop. La solució era fer un programa (en Java o bé en Dumbo) per agafar aquestes dades i fer un grep per veure quants usuaris era, una cosa que utilitzant bash senzillament seria:
bash $> grep michaeljackonid fitxer_scrobbles | sort -k columna_usuari -u | wc -l
és en Java molt més pesat i complicat d'escriure.
Els de l'equip de dades ja havíem tingut diverses peticions d'aquestes anteriorment, i ja tenim una sèrie de programes (mal fets, a base de copy and paste, ràpids) per fer consultes. El principal problema és que d'aquesta manera s'acaba tinguent una bateria d'scripts de consulta que són impossibles de reutilitzar, totalment específics i que serveixen tant sols una vegada.
Però aquesta vegada va ser diferent, perquè des de feia uns dies estàvem jugant amb Hive!
Segons la seva pàgina, Hive és una infraestructura de 'warehouse' (magatzem de dades) que corre sobre Hadoop i permet la consulta de dades. Per tant, és en certa manera. Una infraestructura per córrer SQL sobre directoris de DFS.
Convé tenir en consideració els següent punt, molt important:
- Hive no és una base de dades.
El que fa Hive és tenir en uns fitxers propis del DFS de Hadoop una sèrie de dades que en certa manera descriuen les estructures de directoris dels directoris normals del DFS. Un cop tenim això, la línia de comandaments de Hive permet fer consultes amb SQL. S'ha elegit aquest llenguatge de consulta perquè (desgraciadament?) és el que sap tothom i realment no fa falta crear-ne cap altre.
Aquesta consulta SQL és convertida per Hive en diversos passos, com podem veure en el document d'arquitectura en una sèrie de tasques Map Reduce que corren de forma normal al clúster.
Aquestes tasques senzillament agrupen les dades i les filtren tal com hem dit a la consulta, i en cas que sigui necessari les ordenen (order by), treuen duplicats (distinct)...
Per tant, amb Hive podem córrer una consulta sobre totes les dades del sistema de fitxers distribuït, de forma senzilla i sense haver de carregar totes les dades en una base de dades relacional.
A mi personalment, m'estalviarà moltes hores, ah, i per cert, l'augment d'oients de Michael Jackson el podeu trobar aquí.
No hay comentarios:
Publicar un comentario en la entrada
Comenta: