Večina si nas življenje deli z vsaj eno pametno napravo, ki tak ali drugačen način zbira podatke o naših aktivnostih, spalnih navadah, srčnem utripu in drugih metrikah, ki so posredno ali neposredno povezane tudi z našim zdravjem. Ker so naprave vedno z nami, je zajem takih podatkov enostaven tudi dolgoročno in v velikih količinah, s čimer pred-stavlja velik potencial za spremljanje ne le naših športnih dosežkov ampak tudi zdravstvenega stanja v daljšem obdobju, zaznavanje sprememb, spremljanje pacienta v času okrevanja. Če veliko takih podatkov naprave že beležijo in hranijo, zakaj jih ne bi izkoristili?
Za izkoriščanje takih podatkov v prvi vrsti naletimo na problem zaprtih podatkov, tipično vezanih na proizvajalca naprave ali aplikacije, ki beleži meritve. Problem ni trivialen, je pa premostljiv. Podatke torej z nekaj dela imamo. Kaj pa zdaj? Lahko jih shranjujemo, a sami po sebi brez pametne uporabe niso vredni veliko.
Za resnično obogatitev in dodano vrednost iz podatkov, bi si jih želeli zajemati, kombinirati s podatki iz drugih virov, jih imeti možnost ponovno uporabiti za drugačen namen, vse to pa početi sproti v realnem času. Tukaj pride v igro podatkovna platforma, kot enot-na točka kamor se lahko stekajo podatki z vseh naših pametnih naprav skupaj s podatki iz drugih poljubnih virov. Omogoča nam njihovo shranjevanje, procesiranje, integracijo, obogatitev za sprotno uporabo, hkrati pa spremljanje trendov v daljšem časovnem obdobju. Ob primernih varnostnih mehanizmih je z dovoljenjem posameznika to lahko osnova za zbiranje podatkov za namene znanstvenih raziskav, treniranje AI modelov v diagnostične namene, zgodnje zaznavanje sprememb v zdravstvenem stanju itd. V prispevku bo prikazan zametek takšne podatkovne platforme. Njeni ključni sestavni deli so Apache Kafka za zajem podatkov s senzorjev v realnem času, ksqlDB za njihovo sprotno procesiranje in Apache Druid za shranjevanje za takojšnjo ali kasnejšo uporabo.
Platforma podatke prejema z različnih pametnih naprav (pametna ura, merilec srčnega utripa …). Podatki se prek ustreznih vmesnikov pošiljajo na Kafko, ki deluje kot centralni živčni sistem platforme in enotna vstopna točka za podatke. Pomembno vlogo pri tem ima tudi Schema Registry, ki shranjuje in validira sheme poslanih sporočil. Na tak način lahko strukturno nepravilne podatke že ob prvem zajemu izločimo in zagotovimo prvi korak do kvalitetnejših podatkov v podatkovni platformi. Podatke, ki prestanejo prvi test, nato “v letu” prečistimo, transformiramo in poenotimo s ksqlDB. Končne (lahko pa tudi surove in neobdelane) podatke na koncu shranimo v podatkovno bazo Apache Druid. Le-ta je optimizirana za hitro transakcijsko zapisovanje in že v osnovi kompatibilna s Kafko, po drugi strani pa je prilagojena za hitro branje in odziv na poizvedbe tudi na ve-likih količinah podatkov.
S predstavljeno rešitvijo lahko relativno hitro pridemo do zametka platforme, ki v vseh fazah že uporablja ene od vodilnih gradnikov na tem področju. Tako lahko služi kot osnova in model za izgradnjo prave produkcijske podatkovne platforme za delo s podatki v realnem času.

Elektroenergetski sistem je izredno kompleksen. Kot pomemben del kritične infrastrukture države zajema veliko množico IT in OT integriranih naprav. Na teh napravah zbiramo podatke, ki so ključni za delovanje sistema, oskrbovanje odjemalcev z električno energijo in koordinacijo med deležniki na poslovnem, uporabniškem ter regulatornem nivoju. Zlasti so bistveni merilni podatki, ki pomenijo osnovo za obračun omrežnine in električne energije ter predstavljajo temeljne velepodatke sistema. Učinkovito zbiranje, shranjevanje in obdelovanje teh podatkov je velik tehnološki izziv. Še posebej se nivo zahtevnosti in kompleksnosti povečuje z uvedbo novih obračunskih pravil, ki vpeljujejo koncepte fleksibilnosti, tarifnih blokov, obračuna na osnovi 15-minutnih intervalnih vrednosti ter validacije in nadomeščanja nepopolnih podatkov. V podjetju Informatika smo zato vzpostavili napredno platformo za obdelavo merilnih podatkov (POMP), ki predstavlja centralizirano bazo za shranjevanje, validacijo in nadomeščanje časovno odvisnih (15-minutnih) podatkov. Do podatkov tako ni potrebno dostopati prek petih ločenih merilnih centrov distributerjev električne energije, temveč se iz teh centrov periodično potisnejo na osrednjo lokacijo. To omogoča naprednejšo podatkovno analitiko, boljše integracije in uvedbo novih poslovnih modelov, zlasti pa učinkovito prenovo obračunskega sistema, ki temelji na prehodu na nov tarifni sistem.
Arhitektura platforme sestoji iz več nivojev. Na najnižjem nivoju so merilni centri elektrodistribucijskih družb (Elektro Celje, Elektro Ljubljana, Elektro Maribor, Elektro Gorenjska in Elektro Primorska), ki pridobivajo merilne podatke iz merilnih naprav odjemalcev prek programabilnih logičnih kontrolnikov ali s protokoli P2P. Merilni podatki se nato po mehanizmu potiskanja (»push«) v rezinah prenesejo v centralno podatkovno bazo TimescaleDB, ki je vzpostavljena na infrastrukturi Informatike. Prenos se izvaja periodično, in sicer na dnevnem nivoju. Za vsako merilno mesto se prenašajo časovno odvisni 15-minutni podatki o merjeni moči za štiri kvadrante, ki pokrivajo prejeto, oddano, delovno in jalovo energijo ter vse tarifne skupine. Posamezna časovna značka določa konec 15-minutnega intervala in odraža količino prejete ali oddane energije v tem intervalu.
Podatkovne strukture za prenos sporočil so standardizirane po modelu CIM (Common Information Model), ki je temeljni referenčni model za področje energetike. Sporočila o meritvah so ovita s CIM ovojnico in jih potiskamo prek odprtokodne porazdeljene pretočne platforme Apache Kafka. Prednosti Kafke so hitrost, visoka pretočnost, nizka latenca in odpornost na izpade. To je osnova za masovni prenos merilnih podatkov iz merilnih centrov petih elektrodistribucijskih družb v centralno podatkovno bazo, v sklopu katerega se tokovi sporočil hranijo v ločenih temah (»topics«) za posamezne merilne centre. Vmesnik med merilnimi centri in Kafko je sistem SmenDataBox, ki temelji na mikrostoritveni arhitekturi ter tehnologijah .NET Core in Vue.js. SmenDataBox ovije podatke, ki pridejo v merilne centre, v CIM sporočila in jih odloži na platformo Kafka.
Platforma POMP hrani podatke v podatkovni bazi TimescaleDB, ki je razširitev baze PostgreSQL in je optimizirana za podatke časovnih vrst, med katere spadajo merilni podatki. Ta baza zagotavlja ustrezen nivo skalabilnosti, zanesljivosti delovanja, varnosti (»secure by design«), prepustnosti pri vnosu podatkov in zlasti podpore obdelavam večje količine podatkov v odvisnosti od časovne značke. To je ključno, saj platforma POMP obdeluje in hrani velike količine merilnih podatkov – okoli 3 milijarde zapisov na mesec. Časovne tabele imajo dvodimenzionalno (»flat«) strukturo in vključujejo stolpce za stanja vseh merilnih registrov.
S platformo POMP so integrirani trije ključni sistemi. Informacijski sistem eIS nudi podporo za obračun električne energije in poslovne procese priključevanja odjemalcev v elektroenergetski domeni. Portala Moj elektro in CEEPS (Centralni elektroenergetski portal Slovenije) pa predstavljata enotno vstopno točko (EVT) za zunanje deležnike na elektroenergetskem trgu na nivoju uporabnikov in na poslovnem nivoju. Portal Moj elektro omogoča B2C integracijo z odjemalci in proizvajalci električne energije, CEEPS pa B2B integracijo z regulatorji, agregatorji, dobavitelji in drugimi deležniki na trgu. Za integracije smo razvili ustrezne vmesnike REST API, ki jih lahko kličejo tako poslovni sistemi kot tudi končni uporabniki. Slednji pridobijo dostop do API-jev z žetonom, vezanim na enotno avtorizacijo v portal Moj elektro, ki je realizirana prek sistemov SI-PASS in Rekono. Sistemi eIS, Moj elektro in CEEPS so razviti na platformi Java EE ter poleg programskih vmesnikov za aplikativne integracije zagotavljajo tudi sodobne spletne uporabniške vmesnike za različne tipe končnih uporabnikov – zaposlene v elektrodistribucijskih družbah (eIS), porabnike in proizvajalce električne energije (Moj elektro) in poslovne subjekte (CEEPS).
Ključna funkcionalnost platforme POMP je, da poleg prenosa podatkov iz merilnih centrov na dnevnem nivoju omogoča tudi izvajanje validacije in nadomeščanja podatkov. Prav tako omogoča poizvedovanje po validiranih merilnih podatkih za potrebe interne analitike, izvozov, agregacij in drugih operacij. Dostop do validiranih in nadomeščenih podatkov je realiziran prek implementiranih vmesnikov. Na voljo je elektrodistribucijskim podjetjem, dobaviteljem za namen njihovega poslovanja in delovanja na elektroenergetskem trgu ter za potrebe pridobivanja podatkov iz sistema eIS in modula za obračun omrežnine. Metodologija validacije in nadomeščanja temelji na algoritmih, ki jih definirajo sistemska navodila, ter zajema postopke določitve upravičenosti nadomeščanja manjkajočih vrednosti, detekcije in čiščenja vrednosti izven območja značilk ter izračuna nadomestnih vrednosti. Implementiran je tudi koncept dogovorjene moči, ki se izračuna kot povprečje treh konic in omogoča realizacijo prožnosti pri trgovanju z električno energijo.
Vpeljani metodološki in tehnološki koncepti portala POMP omogočajo, da lahko Informatika kot osrednji ponudnik IT storitev na energetskem trgu izvaja vse potrebne izračune (ki so npr. vezani na inicialno dogovorjeno moč) in skrbi za celoten obračun. Prav tako zagotavljajo visoko stopnjo digitalizacije poslovnih procesov, napredne integracijske mehanizme in vpeljavo poslovnih modelov prožnosti. Predvsem pa omogoča platforma POMP z uvedbo naprednih podatkovnih in pretočnih rešitev skalabilno obdelavo in hranjenje velepodatkov, ki jih lahko na neposreden in koristen način uporabimo tudi v številnih scenarijih na osnovi napredne podatkovne analitike in strojnega učenja.

Sodobni sistemi za upravljanje velepodatkov pogosto zbirajo (vele)podatke iz več različnih virov, pri čemer se podatki razlikujejo po stopnji strukturiranosti, količini, načinu in pogostosti zajemanja, itn. Pri načrtovanju takšnih sistemov je potrebno izbrati ustrezno arhitekturo, ki zagotavlja kakovostno implementacijo in delovanje podatkovnih tokov od zajemanja do podatkovne analitike ter vizualizacije. Zraven transakcijskih podatkov o vsakdanjih aktivnostih podjetja, dandanes hranimo tudi agregirane podatke, ki nastajajo kot rezultat sprotnih in vmesnih analiz v izvirnih sistemih. To pomeni, da narašča potreba po sistemih oz. arhitekturah, ki hkrati podpirajo izvedbo OLTP (transakcijska obdelava podatkov) in OLAP (ad-hoc analitična obdelava podatkov) nalog. Posledično se podjetja pogosto odločajo za vzpostavitev dvostopenjske arhitekture sestavljene iz podatkovnega jezera kot osrednjega repozitorija za shranjevanje izvirnih (transakcijskih in surovih (angl. raw)) ter podatkovnega skladišča za shranjevanje agregiranih podatkov za namen izvajanja analiz (OLAP). Slednja so lahko klasična podatkovna skladišča z OLAP kocko ali pa široko-stolpčne podatkovne baze. V takšni arhitekturi podatkovno jezero prinaša možnost hitrega shranjevanja različno strukturiranih podatkov v surovi obliki, medtem ko se z uporabo podatkovnega skladišča zagotavljata kakovost podatkov in možnost napredne podatkovne analitike. Praktične izkušnje so pokazale, da je dvostopenjska arhitektura kompleksna s stališča vzdrževanja, kar je spodbudilo razvoj podatkovnih kolišč (angl. data lakehouse) kot eno bolj enostavnih in naravnih rešitev, ki podpirajo funkcionalnosti OLTP in OLAP sistemov znotraj le ene sistemske komponente. Kot precej nov koncept se podatkovna kolišča še vedno razvijajo, kar pomeni, da so primeri uporabe in tehnične rešitve dostopne na trgu precej omejene.
Ena pogosto uporabljanih rešitev za vzpostavitev podatkovnega kolišča na trgu je tudi odprtokodna rešitev Delta Lake, ki jo razvija podjetje Databricks. V ozadju projekt Delta Lake vključuje popolnoma drugačen format shranjevanja podatkov, ki omogoča hkrati paketno in pretočno obdelavo. V prispevku bomo podrobneje predstavili format Delta Lake ter analizirali glavne razlike v primerjavi z obstoječimi formati za učinkovito shranjevanje velepodatkov, kot so Parquet, ORC idr. Lastnosti formata Delta Lake bomo tudi vključili v razpravo o novem vzorcu obdelave podatkov Delta ter ga bomo primerjali s trenutno razširjenima vzorcema za pretočno obdelavo podatkov Lambda in Kappa, z namenom analize sprememb, ki jo uporaba takšnega formata prinaša v trenutnih sistemih. Iz tehničnega vidika bomo uporabo formata Delta Lake prikazali na praktičnem primeru implementacije podatkovne platforme za integracijo agroživilskih podatkov. V primeru bomo prikazali, kako nadgraditi obstoječe podatkovno jezero zaradi izboljšanja zanesljivosti s pomočjo formata Delta Lake. Iz tehničnega vidika bomo uporabljali format Delta Table kot implementacijo formata Delta Lake znotraj platforme Azure Databricks. Format Delta Table bomo uporabili za shranjevanje podatkov v določenih conah znotraj podatkovnega jezera Azure Data Lake Storage Gen2. Podatke shranjene v podatkovnem jezeru bomo potem obdelali s pomočjo okvira Spark, pri čemer bomo izpostavili prednosti in morebitne omejitve dela s formatom Delta Table (Lake).

Pomembna, če ne celo najpomembnejša naloga sistemske ekipe je biti pripravljen na morebiten izpad.
Izpade nam lahko neka strojna komponenta, lahko izpade celoten računalniški sistem. Te stvari so največkrat podvojene in takšna izguba ne povzroči nujno popolnega izpada sistema. Kaj pa če pride do izpada celotnega centra. Primer tega bi bile na primer naravne katastrofe: potresi, poplave, požari, cunami, raketni napad. Smo za take primere pripravljeni? Imamo ustrezne arhive? Kje jih imamo?
To lahko postane prava drama. Imeti moramo pripravljen scenarij, kako ukrepati v takih primerih. Veliko stvari moramo imeti pred pripravljenih. Dobre postavitve nam omogočajo prebroditi take izpade praktično brez bolečin.