Vlákno názorů k článku
Posledních pět znaků z každého řádku
od RE: - Chtel bych mit tolik casu.
-
. . (neregistrovaný)
offloading je drahý na podobné typy úloh, tj. hlavně filtrování. Musíš totiž ty data do gpu dostat a použiješ je jen jednou. GPU získává na síle pokud nad jedněma datama potřebuji provést spousty operací, ne pokud potřebuji rychle něco filtrovat v dočasných datech.
awk je v tomhle šílená věc, snad můj neoblíbínejší nástroj na linuxu, používám často na podobnou úlohu, odstranit carriage return z desítek GB velkých csv souborů, člověk by ani nevěřil jak často takovýhle soubory vypadnou z db.
Nikdy jsem nezkoumal podrobně co awk dělá interně, ale právě na zpracování řádků od konce je o řád lepší než jakýkoliv nástroj, který jsem kdy zkoušel, často jsem nebyl schopný ani vlastním C kódem mít lepší časy. Vítě někdo v čem to vězí?
-
Jenda (neregistrovaný)
Ne, protože pokud je to rozumně napsané (e.g. nespouštíš nový proces pro každý řádek), tak je to limitované rychlostí čtení dat, případně když jsou v RAM, tak klidně rychlostí čtení z RAM. Poslat to do GPU a zpět by bylo dražší.
A rychlost čtení dat u opravdu velkých datasetů řeší mapreduce.
-
Ondra Satai NekolaZlatý podporovatelMR už není to jediné, co je, ale YARN navazuje na to, jak původně čistě MR Hadoop začínal...
-
. . (neregistrovaný)
paradigma, které MR začal má svoje následovníky, ale sám MR umírá. Největší slabina MR je, že na dokončení map se čeká a až poté může započít další fáze, během té doby se musí alokovat obrovské množství prostředků a ty se drží. Při zpracování desítek, stovek PB dat je to slabě použitelné a už jsme dávno přešli na jiná řešení. I v malém českém prostředí jsem za posledních několik let ani na jednom projektu MR nepooužil.
Map a fold tady byly před MR a také tady zůstanou, o nich jsem nemluvil.
-
kimec (neregistrovaný)
Aha, tak o MR tu pisete iba vy. Autor prispevku, na ktory ste reagovali, napisal "mapreduce" a vobec neni jasne, aku technologiu myslel.
Vy pod MR asi myslite konkretne Hadoopovske technologie HDFS, YARN, MR1, MR2 a spol. To ste mohli napisat hned.
Ozaj ma niekto v cesku dataset v stovkach PB? Aj ste ho videli alebo len tak placate? -
. . (neregistrovaný)
mapreduce je snad MR, ne? Zkracuje se takhle i v jiných projektech než jen v hadoopu. Mluvím i o původní c++ implementaci, nebo třeba té v couchdb či v riaku, celý algoritmus je založený na jednotlivých fázích (stage), kdy musím mít předchozí dokončenou než začnu další a to je obrovská slabina.
Proč bych pod MR myslel YARN nebo HDFS? To je trochu něco jiného myslím.
V ČR vím jen o projektech většinou ve stovkách TB, vyjímečně v jednotkách PB pro zpracování dat (se Seznamem již nejsem v kontaktu, ti třeba už mají také hodně). Víc jsem viděl pouze v zahraničí, jinde se nedají získávat zkušenosti, ČR je na to hodně malá.
-
kimec (neregistrovaný)
'Proč bych pod MR myslel YARN nebo HDFS? To je trochu něco jiného myslím.'
No preto, ze ta javovska implementacia, ktoru ste na zaciatku oznacili za umierajucu, je umierajuca preto, ze YARN mozno nie je az taky dobry scheduler a preto, ze asi nie je az tamy dobry napad jednotlive stage ukladat na fs (HDFS) lebo ste zvisli na IO. To je presne to, co robi MR2 implementacia z Hadoopu. Alebo ste mysleli nejku inu javovsku implementaciu?
Nikde nie je predsa napisane, ze nemozete mat PB cisto v in-memory gride a robit si mapreduce bez toho, aby ste boli zavisli na ukladani medzivysledkov na fs.
Apropo poslednych 5 znaku z kazdeho radku sa zaobide aj bez redukcnej fazy, ci?
-
. . (neregistrovaný)
Ano, získat posledních 5 znaků z každého řádku je přesně use case pro MR a může na to stačit pouze map. V současnosti se ale nad velkými daty MR pro tyhle úlohy nepoužívá, v téhle exceluje, ale to není běžná úloha.
Jak jsem psal, MR je na ústupu, vidím to na projektech. Nejde o rychlost uložení mezivýsledků, jde o neschopnost pokračovat dokud nebyla předchozí fáze dokončena, Palo psal, že reduce může začít dřív než se dokončí map, to ale neplatí vždy, neplatí to dál než do další fáze a liší se to podle implemtace, v praxi to je nepříjemná brzda, desítky minut čekám než doběhne map fáze a CPU se zatím nudí a za chvilku znovu a znovu, shodné chování napříč různými implementacemi.
Nechci tady rozvíjet offtopic, pokud si o tom chceš více pohovořit, napiš SZ.
-
S tymto suhlas. Nemusi ist o absolutne najrychlejsie riesenie v zmysle efektivity vyuzitia procesoroveho casu, ale skript, ktory schrume 5GB dat za 5 minut a napisem a odladim ho za dalsich 30 (to sa bavime o trocha komplikovanejsich veciach nez toto) je na hony uzitocnejsi, ako program v C-cku, ktory tie iste data schrume za 30 sekund, ale budem ho pisat a ladit tyzden.
Ja v praci realne z casu na cas nejaky taky skript zosmolim (a to som riadny C++ programator, nie admin pri ktorom by to bolo ocakavanejsie). Vnutro je mozno tak trocha na zvracanie, ale plni to svoj ucel, je to dane dokopy v kratkom case a dovoli to ziskat data, ktore su inac prevazne v stadiu "prilis komplikovane na ziskanie" alebo dokonca az "nevieme ako tieto data ziskat". V oboch pripadoch su samozrejme data velmi chcene a pomaly az strategicky dolezite.
-
Kromě zmíněného problému, že jen přesun dat na GPU a zpět je časově náročný (to by neplatilo, kdyby to bylo součástí delšího zpracování, které by probíhalo celé na GPU), tu vidím problém, jak to vhodně paralelizovat na GPU. (Předpokládám, že nemáme žádné zjednodušení jako třeba konstantní délka řádku.):
1. Hledání konců řádků paralelizovat půjde, ale na GPU se budou těžko zapisovat výsledky. Dostanu různě dlouhé seznamy konců řádků.
2. Potom bude potřeba dát výsledky dohromady. To už těžko paralelizujete. A bez toho bude GPU krutě pomalá. (Ještě by se to dalo celé odeslat CPU a nechat to na něm, ale to má samozřejmě nároky na přenos dat atd.)
3. Kód bude nejspíš plný větvení, což GPU nemá ráda. Když se různá vlákna vydají různými směry (jakože se to bude asi dít celkem často), Musejí vlákna, která nejdou touto cestou, čekat na ostatní (a naopak).
