Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Standa Blábol 22. 09. 2021, 16:59:19

Název: Agregace velkého množství streamovaných dat
Přispěvatel: Standa Blábol 22. 09. 2021, 16:59:19
Dotaz do think tanku na moznosti zpracovani velkeho mnozstvi stream dat.

Kafka mi posila stream metric dat v JSON formatu.
Dat je hodne, 90 mil ruznych typu metrik, kazda prijde s periodou 5 minut, tedy za hodinu 90*12=1.08 miliardy zprav.
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"
},
"counters": {
"MP_TOTAL_TRANS_AUDIO_SESSIONS": 0,
"MP_PEAK_TRANS_VIDEO_SESSIONS": 0,
"MP_ACTIVE_TRANS_DTMF_SESSION": 0,
"MP_ACTIVE_AUDIO_SESSIONS": 3,
"MP_PEAK_SRTP_SESSIONS": 0,
"MP_PEAK_TRANS_AUDIO_SESSIONS": 0,
"MP_TOTAL_SRTP_SESSIONS": 0,
"MP_PEAK_TRANS_DTMF_SESSION": 0,
"MP_TOTAL_AUDIO_SESSIONS": 18215,
"MP_TOTAL_VIDEO_SESSIONS": 6,
"MP_PEAK_AUDIO_SESSIONS": 14,
"MP_PEAK_VIDEO_SESSIONS": 2,
"MP_ACTIVE_TRANS_AUDIO_SESSIONS": 0,
"MP_ACTIVE_SRTP_SESSIONS": 0,
"MP_TOTAL_ROGUE_SESSIONS": 0,
"MP_ACTIVE_VIDEO_SESSIONS": 0,
"MP_ACTIVE_TRANS_VIDEO_SESSIONS": 0,
"MP_TOTAL_TRANS_VIDEO_SESSIONS": 0
}
}


Mam existujici (muj) Java programek, ktery se napoji na kafku, nacita zpravy, mirne transformuje a posila na soket k dalsimu zpracovani. Load to zvlada bez problemu.

Nyni potrebuju nad temito daty provadet hodinove agregace, pricemz dale potrebuju agregovat podle subsetu metadat.
Pro priklad dat vyse, potrebuju agregovat countery (min/max/avg) pro kombinaci metadat nodeid,cardid,portid - hodnota lvidid se muze menit, potrebuju zachovat hodnotu lviid z posledni prijate zpravy pro kombinaci nodeid,cardid,portid.
Vysledkem ma byt obdobny JSON, kde blok metadat bude obsahovat metadata z posledni zpracovane zpravy a blok agregovanych counteru bude pro kazdy counter obsahovat sadu agregovanych dat sum/count/min/max - (avg=sum/count). Nejak takhle:

Kód: [Vybrat]
{
"metric": "metric1"
"metadata": {
"nodeid": "node1",
"cardid": "card1",
"portid": "port1",
"lvidid": "lvid23"  # hodnota metadat z posledni zpravy
},
"counters": {
"MP_TOTAL_TRANS_AUDIO_SESSIONS": [120, 20, 0, 30], # sum/count/min/max
"MP_PEAK_TRANS_VIDEO_SESSIONS": [130, 25, 0, 32],
.
.
.
}
}

Muj prvni naivni navrh je:
- pustim kafka replay od hodiny X do X+1
- v mym Java programku na cteni kafka streamu si udelam HashMapu, kde key bude kombinace nodeid,cardid,portid a value bude bean se string metadata (raw JSON) a HashMapa <countername, aggvalues array>
- pro kazdou prichozi zpravu si sestavim key (nodeid,cardid,portid) a v HashMape pro dany key vytvorim/updatuju bean (metadata string se preplacne, agregovane hodnoty prepocitaji)
- az probehnu cely kafla replay - vysmahnu ven HashMapu v JSONu

Problem je s velikosti dat. Vyse popsanou agregaci se dostanu na cca 70 milionu keys v HashMape. Pokud pocitam, ze jeden value v HashMape zabere cca 2kB RAM, celkem ta HashMapa zabere 130GB RAM - nesmysl.

Muj druhy naivni navrh, jako HashMapu pouziju Postgresa, ve kterym bude jedna tabulka reprezentujici vyse popsanou HashMapu ve formatu
Kód: [Vybrat]
(
  key varchar(255),
  aggdata jsonb
)
A na postgresu bude pro insertovani PLSQL procedura, ktera provede potrebne vytvoreni/update pole "aggdata jsonb"

Velikost dat by postgres zvladnout mel, jak to bude s rychlosti, netusim.


Prosim, budu vdecen za jakekoliv hinty, jak toto resit, dik.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 17:18:49
kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse

ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 17:31:35
treba takove sloupce, stovky miliard zaznamu by nemel byt problem na terabitovem disku, agregacni dotazy v radu par sekund
Kód: [Vybrat]
datetime
metric
metadata_nodeid
metadata_cardid
metadata_portid
metadata_lvidid
counters_MP_TOTAL_TRANS_AUDIO_SESSIONS
counters_MP_PEAK_TRANS_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_DTMF_SESSION
counters_MP_ACTIVE_AUDIO_SESSIONS
counters_MP_PEAK_SRTP_SESSIONS
counters_MP_PEAK_TRANS_AUDIO_SESSIONS
counters_MP_TOTAL_SRTP_SESSIONS
counters_MP_PEAK_TRANS_DTMF_SESSION
counters_MP_TOTAL_AUDIO_SESSIONS
counters_MP_TOTAL_VIDEO_SESSIONS
counters_MP_PEAK_AUDIO_SESSIONS
counters_MP_PEAK_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_AUDIO_SESSIONS
counters_MP_ACTIVE_SRTP_SESSIONS
counters_MP_TOTAL_ROGUE_SESSIONS
counters_MP_ACTIVE_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_VIDEO_SESSIONS
counters_MP_TOTAL_TRANS_VIDEO_SESSIONS
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 17:32:09
kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse

ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese

Ja to nepotrebuju ukladat, jenom zpracovat agregaci a poslat dal do sveta
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 17:35:21
treba takove sloupce, stovky miliard zaznamu by nemel byt problem na terabitovem disku, agregacni dotazy v radu par sekund
Kód: [Vybrat]
datetime
metric
metadata_nodeid
metadata_cardid
metadata_portid
metadata_lvidid
counters_MP_TOTAL_TRANS_AUDIO_SESSIONS
counters_MP_PEAK_TRANS_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_DTMF_SESSION
counters_MP_ACTIVE_AUDIO_SESSIONS
counters_MP_PEAK_SRTP_SESSIONS
counters_MP_PEAK_TRANS_AUDIO_SESSIONS
counters_MP_TOTAL_SRTP_SESSIONS
counters_MP_PEAK_TRANS_DTMF_SESSION
counters_MP_TOTAL_AUDIO_SESSIONS
counters_MP_TOTAL_VIDEO_SESSIONS
counters_MP_PEAK_AUDIO_SESSIONS
counters_MP_PEAK_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_AUDIO_SESSIONS
counters_MP_ACTIVE_SRTP_SESSIONS
counters_MP_TOTAL_ROGUE_SESSIONS
counters_MP_ACTIVE_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_VIDEO_SESSIONS
counters_MP_TOTAL_TRANS_VIDEO_SESSIONS
To vubec neznam, jak to funguje? Jak k sobe spojim countery co nalezi k urcite metrice?
Je to rozvoj nazvu sloupce?
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 17:37:33
kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse

ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese

Ja to nepotrebuju ukladat, jenom zpracovat agregaci a poslat dal do sveta

ok, mozna bezpecnejsi to ukladat (alespon par dnu zpet) a agregovat ta data offline
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 17:38:29
treba takove sloupce, stovky miliard zaznamu by nemel byt problem na terabitovem disku, agregacni dotazy v radu par sekund
Kód: [Vybrat]
datetime
metric
metadata_nodeid
metadata_cardid
metadata_portid
metadata_lvidid
counters_MP_TOTAL_TRANS_AUDIO_SESSIONS
counters_MP_PEAK_TRANS_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_DTMF_SESSION
counters_MP_ACTIVE_AUDIO_SESSIONS
counters_MP_PEAK_SRTP_SESSIONS
counters_MP_PEAK_TRANS_AUDIO_SESSIONS
counters_MP_TOTAL_SRTP_SESSIONS
counters_MP_PEAK_TRANS_DTMF_SESSION
counters_MP_TOTAL_AUDIO_SESSIONS
counters_MP_TOTAL_VIDEO_SESSIONS
counters_MP_PEAK_AUDIO_SESSIONS
counters_MP_PEAK_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_AUDIO_SESSIONS
counters_MP_ACTIVE_SRTP_SESSIONS
counters_MP_TOTAL_ROGUE_SESSIONS
counters_MP_ACTIVE_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_VIDEO_SESSIONS
counters_MP_TOTAL_TRANS_VIDEO_SESSIONS
To vubec neznam, jak to funguje? Jak k sobe spojim countery co nalezi k urcite metrice?
Je to rozvoj nazvu sloupce?

nazev metriky mate v sloupci metric
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Logik 22. 09. 2021, 17:39:37
Převeď si to do nějakýho rozumnýho binárního formátu. 90 milionů metrik popíšeš místo stringem o velikosti desítek bajtů jedním integerem, čímž se Ti velikost zprávy smrskne skoro desetkrát a vejde se Ti to do paměti.....
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 17:43:54
treba takove sloupce, stovky miliard zaznamu by nemel byt problem na terabitovem disku, agregacni dotazy v radu par sekund
Kód: [Vybrat]
datetime
metric
metadata_nodeid
metadata_cardid
metadata_portid
metadata_lvidid
counters_MP_TOTAL_TRANS_AUDIO_SESSIONS
counters_MP_PEAK_TRANS_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_DTMF_SESSION
counters_MP_ACTIVE_AUDIO_SESSIONS
counters_MP_PEAK_SRTP_SESSIONS
counters_MP_PEAK_TRANS_AUDIO_SESSIONS
counters_MP_TOTAL_SRTP_SESSIONS
counters_MP_PEAK_TRANS_DTMF_SESSION
counters_MP_TOTAL_AUDIO_SESSIONS
counters_MP_TOTAL_VIDEO_SESSIONS
counters_MP_PEAK_AUDIO_SESSIONS
counters_MP_PEAK_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_AUDIO_SESSIONS
counters_MP_ACTIVE_SRTP_SESSIONS
counters_MP_TOTAL_ROGUE_SESSIONS
counters_MP_ACTIVE_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_VIDEO_SESSIONS
counters_MP_TOTAL_TRANS_VIDEO_SESSIONS
To vubec neznam, jak to funguje? Jak k sobe spojim countery co nalezi k urcite metrice?
Je to rozvoj nazvu sloupce?

nazev metriky mate v sloupci metric

To jsou nazvy sloupcu, uz chapu.
Ten seznam nazvu counteru ale neni uplny ani finalni, muze se celkem dynamicky menit. Kazdy typ metriky mue mit jiny set counteru
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 17:46:05
kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse

ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese

Ja to nepotrebuju ukladat, jenom zpracovat agregaci a poslat dal do sveta

ok, mozna bezpecnejsi to ukladat (alespon par dnu zpet) a agregovat ta data offline

Ok, diky za hint, ulozene by to melo byt v kafce, co neni v kafce, to neexistuje. Melo by stacit si do sloupcove DB ulozit pouze tu jednu aktualne zpracovavanou hodinu.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 17:49:18
kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse

ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese

Ja to nepotrebuju ukladat, jenom zpracovat agregaci a poslat dal do sveta

ok, mozna bezpecnejsi to ukladat (alespon par dnu zpet) a agregovat ta data offline

Ok, diky za hint, ulozene by to melo byt v kafce, co neni v kafce, to neexistuje. Melo by stacit si do sloupcove DB ulozit pouze tu jednu aktualne zpracovavanou hodinu.

ok, ale ta kafka zbytecne plytva mistem, v sloupcove DB neni problem ulozit nekolik dnu do cca desitek GB. Miliarda radku za hodinu nejsou pro sloupcove databaze velka data.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 17:49:48
Převeď si to do nějakýho rozumnýho binárního formátu. 90 milionů metrik popíšeš místo stringem o velikosti desítek bajtů jedním integerem, čímž se Ti velikost zprávy smrskne skoro desetkrát a vejde se Ti to do paměti.....

Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 17:52:07
kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse

ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese

Ja to nepotrebuju ukladat, jenom zpracovat agregaci a poslat dal do sveta

ok, mozna bezpecnejsi to ukladat (alespon par dnu zpet) a agregovat ta data offline

Ok, diky za hint, ulozene by to melo byt v kafce, co neni v kafce, to neexistuje. Melo by stacit si do sloupcove DB ulozit pouze tu jednu aktualne zpracovavanou hodinu.

ok, ale ta kafka zbytecne plytva mistem, v sloupcove DB neni problem ulozit nekolik dnu do cca desitek GB. Miliarda radku za hodinu nejsou pro sloupcove databaze velka data.

To je pravda, ale to neni muj boj. Na danem projektu jsem ciste v pozici precerpavace kejdy z kafky dale do sveta.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 17:54:09
To je pravda, ale to neni muj boj. Na danem projektu jsem ciste v pozici precerpavace kejdy z kafky dale do sveta.

ok, ale podle me ta agregovana data v JSONu budou na disku vetsi nez by byla "splostela" data v tabulce
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Ondrej Nemecek 22. 09. 2021, 17:54:29
Ještě je možnost kouknout po nějaké off-memory hashmapě pro javu, něco jako https://github.com/jankotek/MapDB nebo podobně.  Nemám s tím zkušenost, ale bylo by to něco mezi řešením v paměti a řešením pomocí externí databáze.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 17:57:57
Ještě je možnost kouknout po nějaké off-memory hashmapě pro javu, něco jako https://github.com/jankotek/MapDB nebo podobně.  Nemám s tím zkušenost, ale bylo by to něco mezi řešením v paměti a řešením pomocí externí databáze.

do toho moc dat neulozite, zadna komprese
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: RDa 22. 09. 2021, 18:06:24
Převeď si to do nějakýho rozumnýho binárního formátu. 90 milionů metrik popíšeš místo stringem o velikosti desítek bajtů jedním integerem, čímž se Ti velikost zprávy smrskne skoro desetkrát a vejde se Ti to do paměti.....

Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.

Tak holt prijde ke kazdemu sloupcovemu streamu i bitmapa jestli je field used. Bitmapa bude obsahovat indikaci zda je to null/nenull, coz je 1 Gbit/hodinu * pocet sloupcu. A pro expandovani random N-teho zaznamu se holt musi spocitat kolik jich bylo prazdnych predtim, ale pokud delas exapanzi jako replay dat od pocatku, tak to je v podstate takova "dekomprese" on the fly :)

Pokud by ale celkovy pocet sloupcu byl hodne velky a kazdy record mel velice nahodny subset poli, bych spis uvazoval o klasickem binarnim DB formatu s indexem pro indikaci jaky je to sloupec - jako:  byte cc (column count), byte field_lookup[cc], unsigned data[cc] ... a pripadne to zarovnaval na nejake 1MB boundary nebo ukladal index kde ktery record zacina.

Btw podle jakych podklicu to chcete agregovat? Na beznou celkovou agregaci nepotrebujete lookup prece. A pokud by podklice nasledovali za sebou (napr. casova osa), tak staci flushnout agregaci a zacit s nulou pro dalsi cast.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 18:10:36
Ještě je možnost kouknout po nějaké off-memory hashmapě pro javu, něco jako https://github.com/jankotek/MapDB nebo podobně.  Nemám s tím zkušenost, ale bylo by to něco mezi řešením v paměti a řešením pomocí externí databáze.

To vypada opravdu zajimave, diky
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 18:13:59
To jsou nazvy sloupcu, uz chapu.
Ten seznam nazvu counteru ale neni uplny ani finalni, muze se celkem dynamicky menit. Kazdy typ metriky mue mit jiny set counteru

muzete mit sloupce nazev_counteru, hodnota
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 18:18:16
Převeď si to do nějakýho rozumnýho binárního formátu. 90 milionů metrik popíšeš místo stringem o velikosti desítek bajtů jedním integerem, čímž se Ti velikost zprávy smrskne skoro desetkrát a vejde se Ti to do paměti.....

Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.

Tak holt prijde ke kazdemu sloupcovemu streamu i bitmapa jestli je field used. Bitmapa bude obsahovat indikaci zda je to null/nenull, coz je 1 Gbit/hodinu * pocet sloupcu. A pro expandovani random N-teho zaznamu se holt musi spocitat kolik jich bylo prazdnych predtim, ale pokud delas exapanzi jako replay dat od pocatku, tak to je v podstate takova "dekomprese" on the fly :)

Pokud by ale celkovy pocet sloupcu byl hodne velky a kazdy record mel velice nahodny subset poli, bych spis uvazoval o klasickem binarnim DB formatu s indexem pro indikaci jaky je to sloupec - jako:  byte cc (column count), byte field_lookup[cc], unsigned data[cc] ... a pripadne to zarovnaval na nejake 1MB boundary nebo ukladal index kde ktery record zacina.

Btw podle jakych podklicu to chcete agregovat? Na beznou celkovou agregaci nepotrebujete lookup prece. A pokud by podklice nasledovali za sebou (napr. casova osa), tak staci flushnout agregaci a zacit s nulou pro dalsi cast.

Pocet sloupcu (counteru), je velice variabilni. Agregovat chci pouze podle kombinace metadat.

Tady mam jiny priklad pro jiny typ zpravy

Kód: [Vybrat]
"counters": {
"MP_PINHOLE_MEDIA_BUNDLE_CH_PEAK": 0,
"MP_PINHOLE_WORST_MOS_ACTIVE": 10,
"MP_PINHOLE_TOTAL_RTP_RX": 35562640,
"MP_PINHOLE_CH_MULTIPLEXED_PEAK": 0,
"MP_PINHOLE_EVS_MODE_CHANGE_UE_INIT": 0,
"MP_PINHOLE_RTCP_APP_AMR_IO_SWITCH_SENT": 0,
"MP_PINHOLE_DSP_ALLOC_ATTEMPTS_AMR": 0,
"MP_PINHOLE_WITH_CODEC_G722": 0,
"MP_PINHOLE_DSP_ABORMAL_REL_EVS": 0,
"MP_PINHOLE_DSP_ALLOC_ATTEMPTS_OTHERS": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_CONGESTION_AMRWB": 0,
"MP_PINHOLE_DSP_ALLOC_ATTEMPTS_AMRWB": 1987,
"MP_PINHOLE_VIDEO_TRANSCODING_CH_PEAK": 0,
"MP_PINHOLE_DSP_NORMAL_REL_EVS": 1009,
"MP_PINHOLE_WITH_CODEC_G729": 0,
"MP_PINHOLE_CRYPTO_CHANNEL_PEAK": 0,
"MP_PINHOLE_WORST_R_FACTOR_ACTIVE": 7,
"MP_PINHOLE_VIDEO_TRANSCODING": 0,
"MP_PINHOLE_CH_MULTIPLEXED": 0,
"MP_PINHOLE_DSP_ABORMAL_REL_OTHERS": 0,
"MP_PINHOLE_AUDIO_TRANSCODING_CH_PEAK": 6700274,
"MP_PINHOLE_EVS_SWITCH_TO_AMR_WB_IO": 0,
"MP_PINHOLE_EVS_MODE_CHANGE_UAG_INIT": 0,
"MP_PINHOLE_RTCP_APP_AMR_IO_SWITCH_RCVD": 0,
"MP_PINHOLE_WITH_CODEC_EVS_AMR_WB_IO": 0,
"MP_PINHOLE_DSP_ALLOC_SUCCESS_AMRWB": 1986,
"MP_PINHOLE_MEAN_MOS_ACTIVE": 44,
"MP_PINHOLE_DSP_ALLOC_ATTEMPTS_EVS": 1018,
"MP_PINHOLE_WITH_CODEC_EVS_PRIMARY": 0,
"MP_PINHOLE_TOTAL_OUT_OF_SEQ": 0,
"MP_PINHOLE_WITH_CODEC_G711": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_ERROR_OTHERS": 0,
"MP_PINHOLE_FAX_TRANSCODING_CH_PEAK": 0,
"MP_PINHOLE_RTCP_APP_BANDWIDTH_SENT": 0,
"MP_PINHOLE_RTCP_APP_CHNL_AWARE_SENT": 0,
"MP_PINHOLE_DSP_ABORMAL_REL_AMR": 0,
"MP_PINHOLE_FAX_TRANSCODING_CH": 0,
"MP_PINHOLE_CODEC_MODE_CHANGE_UAG_INIT": 0,
"MP_PINHOLE_DSP_NORMAL_REL_AMR": 0,
"MP_PINHOLE_RTCP_APP_CHNL_AWARE_RCVD": 0,
"MP_PINHOLE_TOTAL_PACKET_LOSS": 978004,
"MP_PINHOLE_TOTAL_UDPTL_RX": 0,
"MP_PINHOLE_TIMESTAMP": 1632318300,
"MP_PINHOLE_AVG_PKT_LATENCY": 13,
"MP_PINHOLE_AVG_PKT_SIZE": 84,
"MP_PINHOLE_RTCP_APP_REDUNDNACY_SENT": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_ERROR_AMR": 0,
"MP_PINHOLE_RTCP_APP_CMR_SENT": 0,
"MP_PINHOLE_RTCP_APP_PRI_SWITCH_SENT": 0,
"MP_PINHOLE_DSP_ALLOC_SUCCESS_AMR": 0,
"MP_PINHOLE_RTCP_APP_BANDWIDTH_RCVD": 0,
"MP_PINHOLE_RTCP_APP_FRAME_AGG_RCVD": 0,
"MP_PINHOLE_CODEC_WITH_T38_UDPTL": 0,
"MP_PINHOLE_RTCP_APP_CMR_RCVD": 0,
"MP_PINHOLE_RTCP_APP_PRI_SWITCH_RCVD": 0,
"MP_PINHOLE_BEST_R_FACTOR_ACTIVE": 98,
"MP_PINHOLE_RTCP_APP_FRAME_AGG_SENT": 0,
"MP_PINHOLE_WITH_CODEC_AMR_WB": 6427,
"MP_PINHOLE_CRYPTO_CHANNEL": 0,
"MP_PINHOLE_CODEC_WITH_T38_RTP": 0,
"MP_PINHOLE_MAX_PKT_LATENCY": 65535,
"MP_PINHOLE_RTCP_APP_PRIMARY_RATE_SENT": 0,
"MP_PINHOLE_BEST_MOS_ACTIVE": 45,
"MP_PINHOLE_DSP_ABORMAL_REL_AMRWB": 0,
"MP_PINHOLE_EVS_SWITCH_TO_PRIMARY": 0,
"MP_PINHOLE_RTCP_APP_PRIMARY_RATE_RCVD": 0,
"MP_PINHOLE_RTCP_APP_REDUNDNACY_RCVD": 0,
"MP_PINHOLE_DSP_ALLOC_SUCCESS_EVS": 1018,
"MP_PINHOLE_DSP_ALLOC_FAIL_ERROR_AMRWB": 0,
"MP_PINHOLE_MEAN_R_FACTOR_ACTIVE": 95,
"MP_PINHOLE_DSP_ALLOC_FAIL_ERROR_EVS": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_CONGESTION_AMR": 0,
"MP_PINHOLE_WITH_CODEC_AUDIO_OTHERS": 8,
"MP_PINHOLE_WITH_DTMF_TRANSCODING": 0,
"MP_PINHOLE_AUDIO_TRANSCODING_CH": 1125,
"MP_PINHOLE_CODEC_MODE_CHANGE_UE_INIT": 0,
"MP_PINHOLE_MEDIA_BUNDLE_CH": 0,
"MP_PINHOLE_AVG_JITTER": 3867,
"MP_PINHOLE_DSP_ALLOC_FAIL_CONGESTION_OTHERS": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_CONGESTION_EVS": 0,
"MP_PINHOLE_DSP_NORMAL_REL_AMRWB": 1979,
"MP_PINHOLE_WITH_CODEC_AMR_NB": 446,
"MP_PINHOLE_DSP_NORMAL_REL_OTHERS": 0,
"MP_PINHOLE_CODEC_WITH_G_711_FAX": 0,
"MP_PINHOLE_DSP_ALLOC_SUCCESS_OTHERS": 0,
"MP_PINHOLE_MAX_JITTER": 475028227
},

Tam muze opravdu byt libovolny bordel a v libovolnem poradi
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Logik 22. 09. 2021, 18:22:34
Citace
Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.
A co Ti brání si držet tabulku: "id metriky":"metrika"? S 90 milionama metrik to dělá řádově 4GB.....
To, co je tady problém je opačná otázka, jak dostatečně rychle zjistit ID z metriky, tak aby bylo rozumně spojitý (neděravý) a tedy to zabralo rozumně paměti. A tady mi to zní jako perfektní úloha na nějakou formu "perfektního hashování".

Anebo, ono umístění řetězce v paměti je ideální "perfektní hash", navíc zadarmo a reversibilní :-). Takže se opravdu úloha redukuje na perfektní zahašování stringu. Stačí si uvědomit, že klíč k redukci paměťové náročnosti je v tom, držet řetězec s názvem metriky v paměti pouze jednou a vždy na něj pouze odkazovat.
Pravda, v takto jednoduchém modelu má hashovací klíč 8 bytů, ale to furt není nic, co by se do rozumnýho stroje do paměti nevešlo. A popř. jde pak ještě perfektně hashovat ten 64bit pointer do nějakého 32bit čísla, kdybys na tom chtěl pálit programátorskej čas (jakože kdyžtak dokoupit paměť by vyšlo levnějc :-)).

EDIT: A nebo zůstat u indexace 4bit integerem, a název metriky držet v datové struktuře spolu s agregovanými hodnotami, to je vlastně ještě přirozenější, než mít "extra slovník".
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 18:35:41
Citace
Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.
A co Ti brání si držet tabulku: "id metriky":"metrika"? S 90 milionama metrik to dělá řádově 4GB.....
To, co je tady problém je opačná otázka, jak dostatečně rychle zjistit ID z metriky, tak aby bylo rozumně spojitý (neděravý) a tedy to zabralo rozumně paměti. A tady mi to zní jako perfektní úloha na nějakou formu "perfektního hashování".

Anebo, ono umístění řetězce v paměti je ideální "perfektní hash", navíc zadarmo a reversibilní :-). Takže se opravdu úloha redukuje na perfektní zahašování stringu. Stačí si uvědomit, že klíč k redukci paměťové náročnosti je v tom, držet řetězec s názvem metriky v paměti pouze jednou a vždy na něj pouze odkazovat.
Pravda, v takto jednoduchém modelu má hashovací klíč 8 bytů, ale to furt není nic, co by se do rozumnýho stroje do paměti nevešlo. A popř. jde pak ještě perfektně hashovat ten 64bit pointer do nějakého 32bit čísla, kdybys na tom chtěl pálit programátorskej čas (jakože kdyžtak dokoupit paměť by vyšlo levnějc :-)).

EDIT: A nebo zůstat u indexace 4bit integerem, a název metriky držet v datové struktuře spolu s agregovanými hodnotami, to je vlastně ještě přirozenější, než mít "extra slovník".

To je pekny hint.
Jenom bych to zevseobecnil na obousmernou mapu (dve mapy) id_retezce/retezec,to by mohlo pomoct. A pouzit to pro vsecky nazvy metrik, metadat, counteru.
Ale to bude imho porad moc, i kdybych to zdrcnul na 100B per agregovany zaznam (coz je v pripade Java Collections IMHO nemozne), porad je to 7GB RAM
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Death Walker 22. 09. 2021, 19:18:35
Ked uz tam mas niekde postgres tak ta asi bude zaujimat toto: https://www.timescale.com/

Robi to presne to co pozadujes. Naviac ti to poskytne efektivnejsie a bezpecnejsie ulozisko ako kafka...
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Logik 22. 09. 2021, 19:27:10
Pokud bys šel tímdle směrem, tak to holt je úloha spíš na C/C++, byť i v Javě se asi dá psát úsporně (např. si předalokovat bytový vektor a z něho pak "alokovat" stringy sám, ale pak je trochu otázka, proč to psát v JAVĚ.... - ale jinak ohledně toho mě neber moc vážně, Javu znam z rychlíku).
Na C++ existuje Kafka klient:https://docs.confluent.io/clients-librdkafka/current/overview.html
A ohledně 7GB paměti - to je hodně? 8GB modul stojí litr, pokud ten stroj, kde to má běžet, by to fakt nezvlád.... Oproti ceně, za "kterou to napíšeš", to jsou drobný.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Death Walker 22. 09. 2021, 19:29:07
Pripadne ak chces predasa len programovat, tak by som nevymyslal koleso, ale pouzil RRD tool. Ten by mal mat implementaciu hadam v kazdom jazyku.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 19:32:37
Ked uz tam mas niekde postgres tak ta asi bude zaujimat toto: https://www.timescale.com/

Robi to presne to co pozadujes. Naviac ti to poskytne efektivnejsie a bezpecnejsie ulozisko ako kafka...

Timescale bezne pouzivam, ale ja resim jiny problem.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 19:37:27
Ked uz tam mas niekde postgres tak ta asi bude zaujimat toto: https://www.timescale.com/

Robi to presne to co pozadujes. Naviac ti to poskytne efektivnejsie a bezpecnejsie ulozisko ako kafka...

timescale zrovna moc efektivni ve vyuziti mista na disku neni, ma spatnou kompresi, pokud nepotrebujete delat nejake fancy dotazy, tak bych se mu vyhnul.

a nemusi stihat zapis, 1 mld za hodinu je celkem dost dat.

tady jsou nejake benchmarky

https://altinity.com/blog/clickhouse-for-time-series

https://github.com/timescale/tsbs

rozdil celkem vyrazny 26GB timescale vs 0.5GB influx vs 1.2GB clickhouse
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 19:39:29
Pokud bys šel tímdle směrem, tak to holt je úloha spíš na C/C++, byť i v Javě se asi dá psát úsporně (např. si předalokovat bytový vektor a z něho pak "alokovat" stringy sám, ale pak je trochu otázka, proč to psát v JAVĚ.... - ale jinak ohledně toho mě neber moc vážně, Javu znam z rychlíku).
Na C++ existuje Kafka klient:https://docs.confluent.io/clients-librdkafka/current/overview.html
A ohledně 7GB paměti - to je hodně? 8GB modul stojí litr, pokud ten stroj, kde to má běžet, by to fakt nezvlád.... Oproti ceně, za "kterou to napíšeš", to jsou drobný.

Javu preferuju, protoze se v ni dela mnohem snaz, nez v C++, snazsi DevOps, navic ma jit o rozvoj existujiciho programu.
Navic konfigurace memory heapu pro JVM v takovych velikostech uz neni zadek, aby ta RAM byla vyuzivana aspon trochu efektivne.
Nez C++, to bych to pro tento ucel radsi delal v GO. Ale jako prvni pokus zkusim ten MapDB projekt.
To by mohlo fungovat bez excesivniho usili at uz programatorskeho, nebo DevOps.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Death Walker 22. 09. 2021, 19:46:58
Jj, ze mas velky pocet dopredu neurcenych klucov, ktorych hodnoty chces agregovat... To by malo ist aj v timescale.

Alternativou by bola PipelineDB, ta bola tiez ako extension pre postgres, nieco ako rrdtool pre velke objemy dat. Neviem ako je to s nimi teraz, po tom co ich kupila confluent tak pre aktualny postgres asi nebude.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 19:50:28
Ale jako prvni pokus zkusim ten MapDB projekt.

nejhorsi mozna volba, kdyz uz chcete ukladat json, tak je efektivnejsi Mongo.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Standa Blábol 22. 09. 2021, 19:54:44
Ale jako prvni pokus zkusim ten MapDB projekt.

nejhorsi mozna volba, kdyz uz chcete ukladat json, tak je efektivnejsi Mongo.

Ok, na ten se taky podivam.
Popravde me efektivita ukladani moc nezajima, chci do toho nacpat hodinu metric dat, pak to poslu do sveta, pak to cely smazu a dalsi hodinu dat.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Death Walker 22. 09. 2021, 20:58:22
Ked uz tam mas niekde postgres tak ta asi bude zaujimat toto: https://www.timescale.com/

Robi to presne to co pozadujes. Naviac ti to poskytne efektivnejsie a bezpecnejsie ulozisko ako kafka...

timescale zrovna moc efektivni ve vyuziti mista na disku neni, ma spatnou kompresi, pokud nepotrebujete delat nejake fancy dotazy, tak bych se mu vyhnul.

a nemusi stihat zapis, 1 mld za hodinu je celkem dost dat.

tady jsou nejake benchmarky

https://altinity.com/blog/clickhouse-for-time-series

https://github.com/timescale/tsbs

rozdil celkem vyrazny 26GB timescale vs 0.5GB influx vs 1.2GB clickhouse

neverte vsetkemu co citate na internete... Podla tohoto vychadza Timescale proti Influx vyrazne lepsie: https://blog.timescale.com/blog/how-to-benchmark-iot-time-series-workloads-in-a-production-environment/

Co sa tyka velkosti. Postgres tam uklada aj data, nie len medzivysledky. Naviac by bolo zaujimave kolko by ostalo z tych 26gb po vacuum, pripadne pri zapnutom autovacuum.

Co sa tyka "fancy" dotazov, tak je fajn ze funkcie mozete pisat aj v R, pripadne v pythone a vyuzit numpy. Priklad: https://docs.timescale.com/timescaledb/latest/tutorials/time-series-forecast/#seasonal-arima-with-r

Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: A.P.Hacker 22. 09. 2021, 21:33:19
Ked uz tam mas niekde postgres tak ta asi bude zaujimat toto: https://www.timescale.com/

Robi to presne to co pozadujes. Naviac ti to poskytne efektivnejsie a bezpecnejsie ulozisko ako kafka...

timescale zrovna moc efektivni ve vyuziti mista na disku neni, ma spatnou kompresi, pokud nepotrebujete delat nejake fancy dotazy, tak bych se mu vyhnul.

a nemusi stihat zapis, 1 mld za hodinu je celkem dost dat.

tady jsou nejake benchmarky

https://altinity.com/blog/clickhouse-for-time-series

https://github.com/timescale/tsbs

rozdil celkem vyrazny 26GB timescale vs 0.5GB influx vs 1.2GB clickhouse

neverte vsetkemu co citate na internete... Podla tohoto vychadza Timescale proti Influx vyrazne lepsie: https://blog.timescale.com/blog/how-to-benchmark-iot-time-series-workloads-in-a-production-environment/

Co sa tyka velkosti. Postgres tam uklada aj data, nie len medzivysledky. Naviac by bolo zaujimave kolko by ostalo z tych 26gb po vacuum, pripadne pri zapnutom autovacuum.

Co sa tyka "fancy" dotazov, tak je fajn ze funkcie mozete pisat aj v R, pripadne v pythone a vyuzit numpy. Priklad: https://docs.timescale.com/timescaledb/latest/tutorials/time-series-forecast/#seasonal-arima-with-r

ten vami odkazovany clanek je z blogu timescale, srovnava pouze s influx, nesrovnavaji spotrebu mista na disku, metrika ve ktere timescale prohrava na cele care. 
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Death Walker 22. 09. 2021, 21:45:17
Ale jako prvni pokus zkusim ten MapDB projekt.

nejhorsi mozna volba, kdyz uz chcete ukladat json, tak je efektivnejsi Mongo.

Ok, na ten se taky podivam.
Popravde me efektivita ukladani moc nezajima, chci do toho nacpat hodinu metric dat, pak to poslu do sveta, pak to cely smazu a dalsi hodinu dat.

Tak pozrite este na https://github.com/rrd4j/rrd4j

je to v jave, ak by nestacila pamat tak si ako backend mozete dat subor na disku, mongodb a funguje to ako klasicke rrdtool.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Death Walker 22. 09. 2021, 21:56:16
ten vami odkazovany clanek je z blogu timescale, srovnava pouze s influx, nesrovnavaji spotrebu mista na disku, metrika ve ktere timescale prohrava na cele care.

https://severalnines.com/database-blog/which-time-series-database-better-timescaledb-vs-influxdb chcete dalsie ale si vygooglite sam?

A ak si to neviete najst tak:

Ad miesto na disku, timescaledb je OLAP pre postgres, podporuje transakcie, referencnu integritu a podobne. Influx je nosql, len tak volne pohodena halda dat.
Název: Re:Agregace velkeho mnzstvi stream dat
Přispěvatel: Idris 22. 09. 2021, 23:32:10
Nez C++, to bych to pro tento ucel radsi delal v GO.
Go bude mít sice menší memory footprint, ale v případě spousty malých objektů na haldě člověk pak stejně musí dělat stejné opičárny jako v Javě. Pokud přes C++ nejede vlak, tak se v tomto případě nabízí Rust.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: sofa_king 23. 09. 2021, 04:03:51
Use case je pullnout každou hodinu data z kafky, agregovat je, zapsat jinam a zdroj zahodit. A tak dokola.

Pattern zní mini-batching. Ie. batch job jednou za hodinu.

Pokud máš metrik jenom pár, bez žádného group by, streamneš to jedním loopem v několika paralelních procesech třeba v pythonu nebo javě a metriky za běhu sečteš pomocí hashmapy a na konci vyplivneš.

V tvým případě není problém spousta metrik (counters), ale počet dimenzí (metadata), kvůli kterým ti vzroste náročnost na paměť pro hashmapu, do kterých ukládáš mezivýsledky. Kardinalita dimenzí a metrik ti přímo určí, kolik paměti potřebuješ. Pronásob si kardinalitu všech dimenzí a metrik a když se ti to vejde do paměti, tak to akorát loopni skrz hashmapu a hotovo.

Pokud ne, dumpni všechny hodnoty za hodinu do csv souboru, seřaď vše podle dimenzí pomocí externího sort algoritmu (řazení mimo RAM), např. pomocí standardního GNU sort. Pak to loopni v javě podobně jako v prvním případě, ale vyhazuj položky z hashmapy tak, jak je navštěvuješ.

Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: honzanovak555 23. 09. 2021, 09:05:38
Spravne riesenie je pouzit Kafka Spark streaming, je to presne robene na to co tazatel potrebuje.

Zakladna idea je ze sa Spark pripoji na Kafku ako consumer a pravidelne taha z Kafky data do Dstreamu nad RDD a nad tym si spravis agregacie absolutne jednoducho. Ono je to uplne usite namieru tomuto problemu.

Tym padom nemusis vobec drzat nikde tie data, staci to on-the-fly agregovat a pamatat si posledny event.

https://spark.apache.org/docs/latest/streaming-kafka-0-10-integration.html

https://spark.apache.org/docs/latest/streaming-programming-guide.html
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: _Tomáš_ 23. 09. 2021, 09:07:26
a Kafka Streams a inkrementální agregace ti nestačí?

Základem je co nejvíce metrik převést na inkrementální (stejný problém řeší např. GoodData), poté počítání v paměti je snadné. Ne vše držet v paměti jednoho procesu, lepší je využít nějakou databázi, např. redis v tomhle poslouží dobře.

Tenhle problém v enterprise často řešíme buď různými obskurně dranými Oracle/SAP nástroji nebo to kluci programují přes spark streams.

Clickhouse není vhodný na příliš mnoho insertů a potřebuje data v bulku, jinak moc dobře s tím nepracuje.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: M_D 23. 09. 2021, 10:07:04
Také bych viděl toto jako "typickou" úlohu pro Apache Spark.

AoK: Redis bych do tohoto netahal. To už možná spíše pak Apache Ignite - umí se sám napojit na Kafku a na příchozí data, co strká do sebe, volat transformační funkce (případně i ten Spark). A na druhé straně to umí i plivat ven dále. A pokud by těch metrik bylo opravud hodně, tak Ignite umí udělat rozumnou distribuci mezi víc serverů nebo ho místo RAM only DB můžu použít s disk backendem, což bych si u Redisu musel řešit svépomocí.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: honzanovak555 23. 09. 2021, 11:52:31
Doplnim ze Ignite ma IgniteRDD na ktore je mozne zavesit Spark a spracovat to ale naopak to nefuguje - Spark nevie spravit z Ignite sink.

Kafka ako source pre Ignite a tam to spracovat je urcite zaujimave ale pride mi to ako kanon na vrabce. Zaroven Ignite sa mi zda nema tie time window funkcie take pohodlne ako Spark.

Ja som pouzival raz Ignite ako write through cache pre Cassandru a potom sa nad Ignitom v cachi da volat normalne (distribuovane) sql s joinami co sa v Cassandre neda.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: František Ryšánek 24. 09. 2021, 05:30:42
Kód: [Vybrat]
{
"metric": "metric1"
"metadata": {
"nodeid": "node1",
"cardid": "card1",
"portid": "port1",
"lvidid": "lvid1"
},
"counters": {
"MP_TOTAL_TRANS_AUDIO_SESSIONS": 0,
"MP_PEAK_TRANS_VIDEO_SESSIONS": 0,
"MP_ACTIVE_TRANS_DTMF_SESSION": 0,
...

...Tam muze opravdu byt libovolny bordel a v libovolnem poradi...

Tenhle konkrétní datový formát jsem nepotkal, přece jenom už mnoho let "dělám do včel". Řekl bych, že jde o nějakou telemetrii ze skupiny nějakých "aktivních prvků" (A/V komunikačních zařízení). Jiní zde asi vidí na první pohled, o co přesně jde a znají hotová řešení.

Spíš pro svou zábavu a pro zajímavost bych se rád zeptal na upřesnění "metamodelu" těch dat (a taky protože jsem možná natvrdlej):

Vypadá to na nějaký polymorfní objekt zvaný "metric", kde "metadata" je stálá/společná množina čtyř atributů, ale polymorfní je množina atributů "counters". Mám pravdu? A množina objektů "counters" je stabilní alespoň pro konkrétní "detailní třídu metriky", tzn. pro konkrétní hodnotu klíčového atributu "metric" ? Tzn. pokud byste si vedl mapu klíčovanou polem "metric", tak jednotlivé uzly (záznamy v mapě) už budou mít každý svou stálou množinu atributů "counters"? Nebo i pak jsou přípustné prázdné hodnoty? (pořadí counterů neřeším.)
Různých typů objektu "metric" je cca kolik? Chápu že 90 milionů je jich *kusů* (úhrnem instancí).

Protože držím v ruce kladivo, problém mi připomíná hřebík: v C++ bych na to použil dvě patra indexu s použitím třídy "std::map", možná se substitucí klíčových stringů integerem, pokud bych usoudil, že to přináší nějakou výkonovou výhodu.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: František Ryšánek 24. 09. 2021, 05:37:09
cat input | grep metric | sort | uniq | wc -l

Jo a agregace podle zařízení / karty / portu by přidala další zábavné patro indexu.
Taky by se dala udělat jediná plochá mapa, tříděná podle třeba pěti kritérií ;-)
Nebo ten model nějak setřepat/optimalizovat.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Ladislav Jech 24. 09. 2021, 06:34:33
Spark standalone mode, single worker bych zkusil jako poc
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Standa Blábol 24. 09. 2021, 10:28:19
Kód: [Vybrat]
{
"metric": "metric1"
"metadata": {
"nodeid": "node1",
"cardid": "card1",
"portid": "port1",
"lvidid": "lvid1"
},
"counters": {
"MP_TOTAL_TRANS_AUDIO_SESSIONS": 0,
"MP_PEAK_TRANS_VIDEO_SESSIONS": 0,
"MP_ACTIVE_TRANS_DTMF_SESSION": 0,
...

...Tam muze opravdu byt libovolny bordel a v libovolnem poradi...

Tenhle konkrétní datový formát jsem nepotkal, přece jenom už mnoho let "dělám do včel". Řekl bych, že jde o nějakou telemetrii ze skupiny nějakých "aktivních prvků" (A/V komunikačních zařízení). Jiní zde asi vidí na první pohled, o co přesně jde a znají hotová řešení.

Spíš pro svou zábavu a pro zajímavost bych se rád zeptal na upřesnění "metamodelu" těch dat (a taky protože jsem možná natvrdlej):

Vypadá to na nějaký polymorfní objekt zvaný "metric", kde "metadata" je stálá/společná množina čtyř atributů, ale polymorfní je množina atributů "counters". Mám pravdu? A množina objektů "counters" je stabilní alespoň pro konkrétní "detailní třídu metriky", tzn. pro konkrétní hodnotu klíčového atributu "metric" ? Tzn. pokud byste si vedl mapu klíčovanou polem "metric", tak jednotlivé uzly (záznamy v mapě) už budou mít každý svou stálou množinu atributů "counters"? Nebo i pak jsou přípustné prázdné hodnoty? (pořadí counterů neřeším.)
Různých typů objektu "metric" je cca kolik? Chápu že 90 milionů je jich *kusů* (úhrnem instancí).

Protože držím v ruce kladivo, problém mi připomíná hřebík: v C++ bych na to použil dvě patra indexu s použitím třídy "std::map", možná se substitucí klíčových stringů integerem, pokud bych usoudil, že to přináší nějakou výkonovou výhodu.

Vicemene ano, jenom tech metadat je v realu mnohem vic. Pro agregaci je nepotrebuju, ale potrebuju znat vsecha metadata z posledni zpravy, co odpovida agregacni kombinaci.

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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Ondrej Nemecek 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í.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Standa Blábol 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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: František Ryšánek 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?
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Standa Blábol 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
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: František Ryšánek 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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: honzanovak555 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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: RDa 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 :-)
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: A.P.Hacker 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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Ondrej Nemecek 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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Idris 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...
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: honzanovak555 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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Death Walker 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...
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: František Ryšánek 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 (https://github.com/nlohmann/json#readme). Resp. aby si toto nechala vhodnou formou rozmluvit.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: honzanovak555 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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Ondrej Nemecek 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.
Název: Re:Agregace velkého množství streamovaných dat
Přispěvatel: Mirek Prýmek 01. 10. 2021, 11:29:31
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.
Těžko říct. Je fakt, že jsem téma prolítl rychle, ale zadání mi nepřišlo popsané dost přesně na to, aby se z toho dalo něco pořádně vyvodit... Popis typu "hodinove agregace" nebo "podle subsetu metadat" neříká to nejpodstatnější.

Jak tady psal někdo výš, začal bych tím, že bych si ujasnil, jaké agregace chci teď a jaké budu potenciálně chtít v budoucnu. Je opravdu zásadní rozdíl počítat na streamu průměr a medián. Pokud to jenom trochu jde, jako první věc se snažit problém natlačit do něčeho, co se dá agregovat inkrementálně. Tj. - programátorsky řečeno - agregát je oproti velikosti vstupních dat malý a dá se updatovat po jednotlivých položkách (takže nemusím držet v paměti v jednu chvíli celý dataset). Matematicky se to taky dá popsat tak, že mě zajímá, jestli se peru aspoň s pologrupou nebo monoidem, z toho pak plyne, jak dobře (či jestli vůbec) na to půjde aplikovat map-reduce model... ale hádám, že tohle asi tazatele nebude zajímat, bude předpokládám stačit zůstat u té programátorské terminologie, to není problém.

Hned jako druhý krok bych si ujasnil tu kardinalitu "sloupcových subsetů". Dejme tomu, že to jsou třeba data z nějakých hardwarových krabiček různých modelů, takže každá měří trochu jiné metriky - jedna má jeden větráček, jiná dva, jedna má jeden teploměr, jiná deset. Zásadní ale je, kolik těch různých kombinací v datasetu reálně je. Může být, že krabiček mám deset tisíc, ale jejich modelů je jenom sto. Takže není pravda, že "každá kombinace je jiná". Těch možný kombinací je jenom sto. ...no a už zase máme nějaký hint, jak výpočet zjednodušit, že jo :)

Přístupem "vlítni na to Sparkem (Flinkem)" se určitě dá jít. Ale některé z těch úvah, které jsem naznačil, budou potřeba i pro to zpracování ve Sparku. Takže bych fakt začal dobrou explorací těch dat a analýzou jejich struktury.

Pokud by ta "reálná kardinalita" byla "rozumná" a počet metrik "ne astronomický", tak se to dá v pohodě řešit i na koleně. Nebo to nalít do InfluxDB, protože to mi krásně zachová metadata (názvy metrik) a zároveň sám, out-of-the-box využije nižší kardinality. Oproti samodomo řešení by byla výhoda v tom, že by se pak daly počítat i "problematické" agregace (třeba ten medián). Ale jsou tam prostě nějaké podmínky kladené na strukturu těch dat, takže prvně si prostě člověk musí ujasnit, jestli je schopen je splnit nebo ne...