Table of Contents

SGE + Hadoop

Documentation

Srovnani SGE vs Hadoop

MapReduce ja zalozen na principu minimalizace sdilenych zdroju + vyuziti levneho HW, proto kazdy node v clusteru ma svoje vlastni disky (kdo + jake nody v clusteru - kazdy node minimalne 1TB disk).

Organizace ulozne kapacity

Hadoop pristup: X GB soubor se nakopiruje do HDFS → sam rozdeli se na casti a rozdistribuuje se po jednotlivych nodech → na kazdem se zpracuje ta cast dat, ktera tam lezi → vysledek
Nas pristup: nevim, jak je to zorganizovane u nas - ale rozhodne se musi “manualne” delit vstupni soubor + pak zrejme stejne lezi nekde spolecne na 1 disku → “musi” se pouzivat –jobs=10

TODO: zjistit, jak je to zorganizovane u nas

Vyhoda Hadoopu

Nevyhoda Hadoopu

  1. vyzaduje aby kazdy node mel samostatny (dostatecne velky) disk - v soucasne dobe maji nody v clusteru jen 56GB
  2. bez toho to asi nebude moc fungovat

Redundance dat

Protoze Hadoop predpoklada, ze to bezi na nespolehlivem HW, tak HDFS defaulne kazdou vec duplikuje 3x. Takze pokud by byl postup: nakopiruju tam data ⇒ spustim MapReduce ⇒ ziskam data - tak to taky nebude moc dobre fungovat.

V clanku z roku 2009, kde popisuji, jak setridit 1PB dat (rychlosti 1TB/minutu) - explicitne pisou, ze v 1. fazi snizili duplikaci na 1, protoze ty ukoly bezely jen par minut a je mala sance, ze se behem toho neco rozbije.

Distribuce uloh

Uloha, ktera:

  1. cte ze vstupu nazvy souboru
  2. na kazdem z nich provede nejakou operaci
  3. vysledek ulozi do nejakeho jineho souboru
  4. na vystup vypise nazvy novych souboru

Je podle mne “map” uloha - a je jedno, jestli se spusti pres SGE nebo pres Hadoop.

Pak existuje pokrocila sprava prav uzivatelu - uzivatel X muze spustit maximalne Y uloh (a dalsi) - ktere nevim, jestli na Hadoopu jdou udelat, ale u nas taky nefungujou ⇒ asi by to moc nevadilo.