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