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