Časovne cone so strah in trepet marsikaterega programerja. Za tem je precej razlogov, najbolj očitna med njimi pa sta nekonsistenca obravnave časovnih con skozi desetletja in razlika med poletnim in zimskim časom. Pri Tom PIT trdimo, da težave s časovnimi conami ne smejo biti težave, ter za temi besedami tudi stojimo, pa čeprav imamo opravka tudi s tako kompleksno programsko rešitvijo, kot je strežnik big data.
Rešitev, ki se je najbolj pogosto poslužujemo za odpravo težave časovnih con, je čim hitrejša pretvorba trenutka v času v časovno cono UTC (Universal Coordinated Time). Ta predstavlja točko nič, na osnovi katere uravnava svoje ure celoten svet. Pretvorba iz časovne cone UTC v poljubno časovno cono je nato v zahvalo orodjem v .NET ogrodju trivialna, potrebujemo le podatek o razliki med ciljno časovno cono in cono UTC.
Standardna rešitev se odlično obnese, ko imamo opravka z enim trenutkom v času, ki ga želimo tako ali drugače obravnavati in zapisati. Situacija pa se hitro zaplete, ko želimo agregirati večjo količino podatkov, saj se ob agregaciji podatkov izgubi natančnost zapisa trenutka dogodka.
Kot primer poglejmo pogosto situacijo iz proizvodnega podjetja.
- V hali obratuje štirideset strojev.
- Vsak stroj predvidoma proizvede deset proizvodov vsako minuto.
- Vsaka skupina proizvodov predstavlja vnos v big data.
- Podjetje spremlja konsistenco proizvodnje na minutnem, petnajst minutnem, urnem, tedenskem, mesečnem in polletnem nivoju.
To pomeni, da big data vsako minuto zapiše 40 vnosov, ki vsebujejo časovno oznako, oznako stroja, oznako proizvoda in proizvedeno količino. V letu rednega obratovanja je to 21,024,000 zapisov. Večina podjetij beleži zapise proizvodnje v bistveno večji frekvenci (na sekundnem nivoju in več).
Ob pregledu grafa letne statistike je mogoče iz big data prebrati vse zapise in jih prikazati v časovnem zaporedju, vendar je to izjemno obremenjujoče za sistem, predvsem pa traja nekaj časa, da se ta ogromna količina podatkov prenese do uporabniškega vmesnika in prikaže. Razlog za to ni le programska oprema, temveč predvsem omejitev zmogljivosti omrežja in uporabnikove opreme.
Ob pregledu podatkov za leto dni je zelo verjetno, da končnega uporabnika ne zanimajo podatki za vsako zajeto minuto, temveč vsota podatkov za neko časovno obdobje, kot je mesec dni. Tako bi bilo potrebno namesto 21,024,000 zapisov prenesti le 480 zapisov, štirideset za vsak mesec v letu.
Agregacija tolikšnega števila zapisov za vsak zahtevek v realnem času bi zahtevala ob več aktivnih uporabnikih izjemno zmogljiv strežnik, pa bi uporabnik kljub temu moral čakati več sekund ob vsaki spremembi parametrov poizvedbe. Nekaj sekund se ne zdi veliko, vendar nam moderna tehnologija omogoča, da lahko tovrstne podatke prikazujemo bistveno hitreje in bolj učinkovito. Podlaga za to je agregacija podatkov le enkrat ob zapisu, namesto vsakič ob branju podatkov.
Tom PIT.connected big data strežnik omogoča, da za določeno skupino podatkov ob zapisu povemo, kaj naj s podatki stori. Najbolj osnoven je preprost zapis surovih podatkov, ki zapiše ali prepiše prejete podatke. Bolj kompleksni agregaciji sta seštevanje in povprečenje podatkov, prejetih za določen časovni interval (urni, dnevni, tedenski…).
Ta kompleksnost še dodatno naraste, ko se vpletejo časovne cone. Denimo, da želijo končni uporabniki spremljati proizvodnjo v dveh državah, Sloveniji ter Latviji. Če predpostavimo, da je poletje, to pomeni, da slovenski uporabniki uporabljajo časovni pas UTC+2, uporabniki v Latviji pa UTC+3. Z drugimi besedami, ko je polnoč v Sloveniji, je ura ena zjutraj v Latviji.
Tabeli prikazujeta petindvajset ur proizvodnje namišljenega podjetja na urnem nivoju ter nato na dnevnem nivoju, za datum 1. 4. 2022.
Kot lahko vidimo v drugi tabeli, je zaradi zamika časovne cone podatek o proizvodnji 1. 4. 2022 za uporabnike v Sloveniji drugačen kot za uporabnike v Latviji. Razlog za to je razlika v definiciji datuma 1. 4. 2022 – med državama je ura razlike. Te razlike so še večje, če je razlika med frekvenco zajema in intervalom agregacije manjša (na dnevnem nivoju je razlika precej bolj očitna kot na mesečnem ali letnem).
Kaj to pomeni za agregacijo v big data? Če želimo vsoto dnevne proizvodnje preračunati vnaprej, je potrebno v agregaciji obvezno upoštevati tudi časovno cono. Posledično to pomeni tudi, da se mora agregacija izvajati neodvisno za vsako časovno cono, časovna cona uporabnika pa postane dodaten parameter v poizvedbi podatkov.
Te posledice bi v drugi big data rešitvi predstavljale programerju ogromno dodatnega dela pri implementaciji vsakega zapisa v big data. Najprej bi moral vedeti, v kateri časovni coni se nahaja uporabnik, ter normalizirati uro v UTC čas. Nato bi potreboval seznam podprtih časovnih con, ter za vsak podatek preračunati uro v pravilni časovni coni. Končno bi moral še preračunati, v katero polje agregacije spada podatek glede na čas zajema ter popraviti polje v shrambi. Sama logika za implementacijo tu ni več trivialna, zato je nagnjena k napakam, predvsem pa jo je potrebno vedno znova podvajati, ko želimo v big data zapisovati nov model podatkov ali drugačno agregacijo.
Pri Tom PIT je učinkovitost programerja ena naših primarnih skrbi. Ker ne ponujamo le storitev, ampak tudi platformo za implementacijo novih rešitev, je izjemno pomembno, da lahko programer to naredi hitro, zanesljivo in brez ukvarjanja z detajli, za katere je lahko poskrbljeno generalno, brez dodatnega dela.
Celoten problem, opisan v tem članku, je rešen v zaledju ter tako elegantno, da niti ni nujno, da se ga programer zaveda.
Poglejmo si korake za zapis podatkov:
1. Najprej se rešitve lotimo na upravnem nivoju. V nastavitvah platformi povemo, katere časovne cone bi radi podprli v big data strežniku. Ta korak je potrebno opraviti le enkrat.
2. V modelu z atributi povemo, katera agregacija se pričakuje na poslanih podatkih. To stori programer le enkrat, ko definira model.
3. Podatke pošljemo v big data strežnik s celotnim zapisom časa dogodka v UTC, brez prirejanja podatkov o času.
Četrtega koraka ni. S pomočjo nastavitev ter pravilno definicijo modela so podatki so v tej točki zapisani in agregirani v definiranih časovnih conah, brez dodatne kode ali dodatnega dela za doseganje agregacije.
Branje podatkov je še bolj preprosto. Nabor podatkov lahko zahtevamo na enega dveh načinov:
1. Uporabnik ni znan. V tem primeru lahko kot parameter v poizvedbo pošljemo časovno cono, strežnik pa poskrbi, da podatke prebere iz pravilnih zapisov.
2. Uporabnik je znan. V koliko ne pošljemo dodatnega parametra za časovno cono, ki prevlada nad privzetim obnašanjem, strežnik iz podatkov uporabnika sam ugotovi pravilno časovno cono in jo uporabi pri branju podatkov.
V kolikor zahtevana časovna cona ni podprta, strežnik javi napako in ponudi privzet nabor podatkov (v UTC).
Kot lahko vidite, je v platformi Tom PIT.connected kompleksen problem rešen na način, ki za uporabnika predstavlja trivialno uporabo. Hitro, zanesljivo in učinkovito.
