Agregace velkého množství streamovaných dat

Re:Agregace velkého množství streamovaných dat
« Odpověď #45 kdy: 24. 09. 2021, 10:55:40 »
Vysvetleno v SQL, potrebuju select sum,count,min,max from table where timestamp between x,x+1 group by some_metadata. A pak jeste kompletni metadata (ne jenom ty v group by klauzuli) casove posledniho radku pro kazdou group by grupu.

C++ pristup pres Hashmapy vybehne z RAM.

Ale z RAM vyběhnou jen ty metadata, ne? Takže jde imho jen o to si ty metadata někam odložit?

Mapdb jsem navrhoval, protože to je drop-in replacement za java kolekce, takže pokud už existuje ta naivní implementace, lze vyzkoušet s minimem úsilí.


Re:Agregace velkého množství streamovaných dat
« Odpověď #46 kdy: 24. 09. 2021, 11:59:26 »
Vysvetleno v SQL, potrebuju select sum,count,min,max from table where timestamp between x,x+1 group by some_metadata. A pak jeste kompletni metadata (ne jenom ty v group by klauzuli) casove posledniho radku pro kazdou group by grupu.

C++ pristup pres Hashmapy vybehne z RAM.

Ale z RAM vyběhnou jen ty metadata, ne? Takže jde imho jen o to si ty metadata někam odložit?

Mapdb jsem navrhoval, protože to je drop-in replacement za java kolekce, takže pokud už existuje ta naivní implementace, lze vyzkoušet s minimem úsilí.

Jeste neexistuje nic, ale urcite od odzkousim jako prvni pokus. Diky.

Re:Agregace velkého množství streamovaných dat
« Odpověď #47 kdy: 24. 09. 2021, 13:19:37 »
C++ pristup pres Hashmapy vybehne z RAM.

Tyjo. Indexy vyběhnou z RAM, přestože nedržíte v indexu jednotlivé zprávy, ale jenom třídící kombinace + poslední zprávu v každé agregované kategorii?

Re:Agregace velkého množství streamovaných dat
« Odpověď #48 kdy: 24. 09. 2021, 16:37:56 »
C++ pristup pres Hashmapy vybehne z RAM.

Tyjo. Indexy vyběhnou z RAM, přestože nedržíte v indexu jednotlivé zprávy, ale jenom třídící kombinace + poslední zprávu v každé agregované kategorii?

Ano, anzto tech agregovanych kategorii je cca 70 mega

Re:Agregace velkého množství streamovaných dat
« Odpověď #49 kdy: 24. 09. 2021, 21:02:41 »
...80 MB textových dat, nebo 80 milionů těch kategorií? :-)
To je fuk...
Na hotová řešení typu "škálovatelný buldozer" jsou tu jiní odborníci.
Pokud bych to chtěl řešit v C++ na koleně, tak bych šel na dva průchody. V prvním průchodu bych data rozházel z původního jediného balíku do více souborů, podle "názvu metriky" - podle palce řádově tak, aby se mi vešly do RAMky. Následné dožužlání (agregace) by pak šlo podle toho i primitivně paralelizovat.
A možný zádrhel: ukládání do sekvenčních souborů vypadá napohled jako nenáročné na IOps, ale pokud by se zapisoval větší počet streamů naráz, mohlo by to dát ještě "zajímavý" seek pattern.


Re:Agregace velkého množství streamovaných dat
« Odpověď #50 kdy: 26. 09. 2021, 09:15:23 »
Nechapem, preco tu existuje potreba bastlit nieco custom ked v Sparku si staci precitat dokumentaciu a po skonceni projektu budem o technologiu mudrejsi. Namiesto toho sa to tu navrhuje "davat do suborov a potom paralelizovat na dva priechody" lol ..., Da sa v tom programovat aj v Java API, Scala nie je treba.

RDa

  • *****
  • 1 566
    • Zobrazit profil
    • E-mail
Re:Agregace velkého množství streamovaných dat
« Odpověď #51 kdy: 26. 09. 2021, 21:11:28 »
Nechapem, preco tu existuje potreba bastlit nieco custom ked v Sparku si staci precitat dokumentaciu a po skonceni projektu budem o technologiu mudrejsi. Namiesto toho sa to tu navrhuje "davat do suborov a potom paralelizovat na dva priechody" lol ..., Da sa v tom programovat aj v Java API, Scala nie je treba.

Tak se predvedte, jak bude vypadat onen Spark query, a jakou to bude mit casovou a pametovou narocnost? Tazatel objem dat i ukol uz dostatecne popsal na peti strankach.

Osobne mam pocit, ze custom bastl prosazuje "stara skola", tj ti co si umi predstavit data a pametovy/souborovy format a vi jak efektivne napsat praci s daty.

Pak je zde tapajici "stredni" trida, kdo se to snazi lepit skrze knihovny nebo jazykove konstrukty, ale netusi uz jak to je ve skutecnosti narocne (casove/pametove).

A pak tady dobehnou decka jako vy, ktery vytasi zazracny frikulinsky jazyk/framework, ktery by to mel udelat, ale o pocitaci vedi snad jenom tolik, ze to bez internetu neudela ani tuk :-)

Re:Agregace velkého množství streamovaných dat
« Odpověď #52 kdy: 26. 09. 2021, 21:31:53 »
Osobne mam pocit, ze custom bastl prosazuje "stara skola", tj ti co si umi predstavit data a pametovy/souborovy format a vi jak efektivne napsat praci s daty.

to jsou ti co radi znovuvynalezaji kolo.

Re:Agregace velkého množství streamovaných dat
« Odpověď #53 kdy: 26. 09. 2021, 22:02:34 »
Nejlepší je udělat si hrubý odhad a test na vzorku dat - vyzkoušet různé přístupy. Ono všechno má nějakou režii a předpoklady a to si každý musí zhodnotit sám. Spark je jistě vhodná technologie, pokud se budou podobné požadavky opakovat, protože pak se investice do ovládnutí té technologie jednoduše vyplatí. Naopak budou případy, kdy je zcela legitimní to naprogramovat na koleně. Za tazatele bych se to každopádně neodvažoval hodnotit.

Idris

  • *****
  • 1 660
    • Zobrazit profil
    • E-mail
Re:Agregace velkého množství streamovaných dat
« Odpověď #54 kdy: 26. 09. 2021, 22:40:10 »
Osobne mam pocit, ze custom bastl prosazuje "stara skola", tj ti co si umi predstavit data a pametovy/souborovy format a vi jak efektivne napsat praci s daty.

Pak je zde tapajici "stredni" trida, kdo se to snazi lepit skrze knihovny nebo jazykove konstrukty, ale netusi uz jak to je ve skutecnosti narocne (casove/pametove).

A pak tady dobehnou decka jako vy, ktery vytasi zazracny frikulinsky jazyk/framework, ktery by to mel udelat, ale o pocitaci vedi snad jenom tolik, ze to bez internetu neudela ani tuk :-)
Tak žádný učený z nebe nespadl...

Re:Agregace velkého množství streamovaných dat
« Odpověď #55 kdy: 27. 09. 2021, 00:40:32 »

Pak je zde tapajici "stredni" trida, kdo se to snazi lepit skrze knihovny nebo jazykove konstrukty, ale netusi uz jak to je ve skutecnosti narocne (casove/pametove).

A pak tady dobehnou decka jako vy, ktery vytasi zazracny frikulinsky jazyk/framework, ktery by to mel udelat, ale o pocitaci vedi snad jenom tolik, ze to bez internetu neudela ani tuk :-)

omnoho rozumnejsie hlavy s Phd atd vymysleli "frikulinsky framework" ktory pouziva cely svet od rana do vecera a je to alfa a omega big data a nejaky Standa Blabol z Dolnej to ide pisat po svojom lebo ved to kurva da! :D

Jeho nabastleny bazmek bude unikat ktoremu bude rozumiet len on, bude bud omnoho menej efektivny alebo lepsi o 2% a zabije s tym radovo viac casu lebo bude zacinat od nuly.

Ale ukaze tym mladym cucakom!

A to chces.

Re:Agregace velkého množství streamovaných dat
« Odpověď #56 kdy: 27. 09. 2021, 02:59:06 »
Osobne mam pocit, ze custom bastl prosazuje "stara skola", tj ti co si umi predstavit data a pametovy/souborovy format a vi jak efektivne napsat praci s daty.
to jsou ti co radi znovuvynalezaji kolo.
A tiez su tu ti, ktori sa snazia pouzit koleso z v3s na trojkolku, je jedno ci preto ze nemaju vhodne koleso alebo preto ze maju s kolesom z v3s takmer intimny vztah...

Re:Agregace velkého množství streamovaných dat
« Odpověď #57 kdy: 29. 09. 2021, 12:27:58 »
Ještě sry za resuscitaci - téma mě zajímá, protože o něm dohromady nic nevím...


Format (zjednoduseny) je takovyto, realna jedna zprava ma cca 1.5kB dat.

Kód: [Vybrat]
{
"metric": "metric1",
"metadata": {
"nodeid": "node1",
"cardid": "card1",
"portid": "port1",
"lvidid": "lvid1"
// "metadata atributů" je víc, množina je stabilní
},
"counters": {
"MP_TOTAL_TRANS_AUDIO_SESSIONS": 0,
"MP_PEAK_TRANS_VIDEO_SESSIONS": 0,
// "čítačových proměnných" je mnoho, množina je stabilní pro danou metriku
}
}

Spark vypadá, že má v zásadě "ROLAPový" interní metamodel.
Chápu, že umí brát data z předávacího formátu JSON.
Výše načrtnutá struktura není takto sešněrována obecným JSONem. Řekněme, že se tady jedná o JSON s nějakým "dodatečným schématem" (pravidly). Tzn. ten již zmíněný "polymorfismus" není vlastností JSONu, ale specialitou předloženého zadání. A mám pocit, že moc nesedí ani na "relační paradigma" - dá se na něj naroubovat na bázi velkého počtu pojmenovaných sloupců, které budou mít v mnoha případech prázdné hodnoty...

Protože Spark neznám, připadá mi, že polymorfní zadání na relační přístup moc nepasuje :-)

Kdybych to mastil v C++, tak na první pohled by tu stabilní množinu "metadata atributů" šlo zadat natvrdo jako membery nějaké C++ třídy ("class metric"), a "polymorfní" množinu proměnných řešit asociativním polem (std::map apod.) které by bylo memberem třídy. Ovšem pokud těch metadata atributů je větší počet, bude možná míň tupé coderské práce, nasypat je *taky* do asociativního pole, a s těmi čtyřmi, co nás zajímají, halt zacházet ve vstupním kroku o úroveň abstrakce výš...

Najít řetězec v asociativním kontejneru (btree s nějakou porovnávací funkcí) a data na vstupu příslušně zatřídit možná není o tolik výpočetně náročnější, než mít názvy jednotlivých atributů natvrdo jako stringové literály ve zdrojáku. Důležité je, aby tohle třídění a řetězcové porovnávání běželo pokud možno rychleji, než přístup k diskům :-)

Modulo nějaké knihovní funkce na chroupání JSONu, které by na ten vstup šly použít = přebíral bych rovnou strom JSONových objektů. Tady spíš vidím jako potenciální zádrhel, aby třeba šlo iterovat na vstupu po top-level objektech = aby se knihovna nesnažila, požrat vstupní mnoha-GB soubor najednou do RAMky. Resp. aby si toto nechala vhodnou formou rozmluvit.

Re:Agregace velkého množství streamovaných dat
« Odpověď #58 kdy: 29. 09. 2021, 19:00:05 »
Ještě sry za resuscitaci - téma mě zajímá, protože o něm dohromady nic nevím...


Format (zjednoduseny) je takovyto, realna jedna zprava ma cca 1.5kB dat.

Kód: [Vybrat]
{
"metric": "metric1",
"metadata": {
"nodeid": "node1",
"cardid": "card1",
"portid": "port1",
"lvidid": "lvid1"
// "metadata atributů" je víc, množina je stabilní
},
"counters": {
"MP_TOTAL_TRANS_AUDIO_SESSIONS": 0,
"MP_PEAK_TRANS_VIDEO_SESSIONS": 0,
// "čítačových proměnných" je mnoho, množina je stabilní pro danou metriku
}
}

Spark vypadá, že má v zásadě "ROLAPový" interní metamodel.
Chápu, že umí brát data z předávacího formátu JSON.
Výše načrtnutá struktura není takto sešněrována obecným JSONem. Řekněme, že se tady jedná o JSON s nějakým "dodatečným schématem" (pravidly). Tzn. ten již zmíněný "polymorfismus" není vlastností JSONu, ale specialitou předloženého zadání. A mám pocit, že moc nesedí ani na "relační paradigma" - dá se na něj naroubovat na bázi velkého počtu pojmenovaných sloupců, které budou mít v mnoha případech prázdné hodnoty...

Protože Spark neznám, připadá mi, že polymorfní zadání na relační přístup moc nepasuje :-)

Nevidim kde tu je problem ... ved ako to taha z Kafky, tak si na to mozes napisat uplne hocijaky map a reducer

https://spark.apache.org/docs/latest/streaming-programming-guide.html#transformations-on-dstreams

Tak by si mal jednu dalsiu classu ktora by bola usita namieru tomu co potrebujes a ako tie data taha tak si to reducenes ..

https://spark.apache.org/docs/latest/streaming-programming-guide.html#window-operations checkni "reduceBy*" methody.

Proste ako tie data prichadzaju, tak len vzdy updatenes a reducenes to.

Re:Agregace velkého množství streamovaných dat
« Odpověď #59 kdy: 01. 10. 2021, 10:00:52 »

Nevidim kde tu je problem ... ved ako to taha z Kafky, tak si na to mozes napisat uplne hocijaky map a reducer

https://spark.apache.org/docs/latest/streaming-programming-guide.html#transformations-on-dstreams

Tak by si mal jednu dalsiu classu ktora by bola usita namieru tomu co potrebujes a ako tie data taha tak si to reducenes ..

https://spark.apache.org/docs/latest/streaming-programming-guide.html#window-operations checkni "reduceBy*" methody.

Proste ako tie data prichadzaju, tak len vzdy updatenes a reducenes to.

Pokud jsem to dobře pochopil, tak problém je, že ten map-reducer bude operovat nejen nad streamem záznam po záznamu ale současně i nad daty která se nevejdou do ram.