• Official documentation for SGE
• Oracle's blogspot

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).

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

• da se spustit mnohem vice uloh nad 1 daty
• melo by to byt rychlejsi - data se ctou z lokalniho disku a ne z nejakeho diskoveho pole
• melo by to byt levnejsi - neni potreba zadne sofistikovane diskove pole a staci jen hloupe HDD

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

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.

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.