About Data

zber dát, vizualizácia dát, analýza dát, time series databázy

Záznam z prednášky

Annoucements

  • zdieľanie dát z vlastných senzorov/zdrojov

Introduction

  • (slide) Začnime pohľadom na službu, o ktorej sa rozprávame od začiatku - o chytrom vývoze odpadu (waste management). Trochu preháňajme a uvažujme, že v Košiciach sa nachádza 1000 domov (súpisné čísla). Preháňajme ďalej a povedzme, že pre každý dom máme vyhradený

    • 1 kontajner pre papier,
    • 1 kontajner pre sklo,
    • 1 kontajner pre plasty, a
    • 1 kontajner pre komunálny odpad.
    Waste Management

    To máme dokopy 4000 veľkých kontajnerov v meste. Zatiaľ nič nehovoríme o verejných kontajneroch v parkoch, na zastávkach a podobne. Každý z týchto kontajnerov je v našom scenári vybavený chytrým zariadením (vecou), ktoré vie zistiť množstvo odpadu v kontajneri a v pravidelných intervaloch, ako aj v prípade potreby (množstvo odpadu presiahlo úroveň, kedy ho je potrebné vyviezť) vie odoslať údaje o svojom stave. Ak budeme preháňať ďalej, tak povedzme, že každé zariadenie bude posielať správu o aktuálnom stave každú hodinu. To znamená, že v jednom momente zaznamenáme nápor v podobe 4000 požiadaviek o zápis údajov do databázy.

  • Toto číslo samozrejme nie je extrémne veľké. Ak by sme však mali senzory, ktoré by snímali údaje napr. každú minútu alebo každých niekoľko sekúnd, množstvo údajov, ktoré je potrebné uložiť, by bolo výrazne vyššie.

  • V našom scenári sme však stále v jednom meste. Čo ak by sme svoju službu prevádzkovali v niekoľkých mestách zároveň? Čo ak by sme vyhrali nejakú štátnu zákazku a stali by sme sa výlučným poskytovateľom danej služby na Slovensku? Čo ak by sme uvažovali vo veľkom a podarilo by sa nám preraziť za hranicami a službu by sme poskytovali v niekoľkých krajinách? Množstvo údajov čakajúcich na uloženie by rástlo ďalej, vďaka čomu by sa databázový server stal veľmi rýchlo úzkym hrdlom systému.

  • (slide Hovorili sme o tom, že nápor množstva údajov vieme znížiť vhodným umiestnením vrstvy edge v našej architektúre. Tá nám pomôže znížiť nápor agregovaním údajov, prípadne ich čiastočným predspracovaním alebo aj analytikou. IoT Architecture Overview

Horizontal vs Vertical Scaling

  • (slide) Znížiť nápor množstva údajov však môžeme aj výberom vhodného databázového systému s vhodnými vlastnosťami. Databázové servery pre IoT riešenia, ktoré potrebujú spracovávať obrovské množstvá údajov v reálnom čase, by mali byť horizontálne škálovateľné. Scale Out vs Scale Up

  • Relačné databázové systémy sú tu s nami už od 70-tych rokov. S množstvom uchovávaných údajov sa môžu začať potýkať s problémom potrebného výkonu. Akonáhle sa problémy tohto typu vyskytnú, začnú ich spoločnosti riešiť vertikálnym škálovaním.

  • Vertikálne škálovať (alebo tiež scale up/down) znamená pridať ďalšie zdroje (alebo odstrániť existujúce) z jedného uzla (zariadenia). Obyčajne sa jedná o zvýšenie výkonu v podobe rýchlejšieho CPU, zvýšenie počtu CPU, zvýšenie RAM alebo zväčšenie diskového priestoru na jednom počítači.

  • Tento spôsob škálovania má však svoje limity. Tie sú dané hlavne fyzikálnymi zákonitosťami, resp. možnosťami aktuálnych technológií.

  • Horizontálne škálovať (alebo tiež scale out/in) znamená pripojiť do systému ďalšie uzly (alebo odpojiť existujúce). To docielime pripojením nového počítača do distribuovaného systému. Vlastnosťou horizontálneho škálovania je vybavená väčšina NoSQL databázových systémov.

  • (slide) Samozrejme aj jeden aj druhý prístup má svoje výhody a nevýhody: Cost difference in vertical vs horizontal scalability

    horizontálne škálovanie vertikálne škálovanie
    so zvyšovaním počtu pripojených uzlov sa zvyšuje aj dostupnosť single point of failure
    pri škálovaní nie je potrebný žiadny výpadok služby pri zmene konfigurácie je služba nedostupná
    relatívne nízke náklady lepší hardvér predstavuje zvýšené náklady
    škálovať je možné teoreticky do nekonečna obmedzené možnosti zvyšovania výkonu
    nie každý softvér a problém je možné riešiť distribuovane väčšina softvéru zvláda výhody vertikálneho škálovania
    problémy ako potreba load balancera na distribuovanie požiadaviek, synchronizácia a replikácia údajov, aktualizácia softvéru jednoduchá správa softvéru na jednom počítači/zariadení
    automatické škálovanie použitím vhodných služieb (AWS) automatizácia je možná buď vlastnými skriptami alebo inštalovanými službami

Time Series Databases

  • Údaje, ktoré zbierame v IoT aplikáciách, sú závislé na čase. Takýto typ databáz sa nazýva time series (časové rady) databázy

  • (slide) Time series databáza (TSDB) je softvérový systém, ktorý je optimalizovaný pre prácu s časovými radmi na základe párov dvojíc čas a hodnota.

  • Obecne sa teda jedná o údaje, ktoré keď vizualizujeme v podobe grafu, tak jedna z osí reprezentuje čas. Čas tu figuruje ako nezávislá premenná a cieľom je obyčajne predikovať budúcnosť.

  • Nad dátami tohto typu nás častokrát zaujímajú otázky ako:

    • aká bola teplota za poslednú hodinu?
    • aká bola teplota za posledných 24 hodín?
    • aká bola priemerná teplota za celý minulý rok?

  • (slide) Ich popularita v posledných rokoch prudko stúpla, o čom svedčí aj štatistika serveru db-engines.com na základe kategórií databáz. DB-Engines Score by DB Category

  • (slide) TSDB majú najväčšie uplatnenie v týchto troch oblastiach:

    1. IoT - senzorické dáta
    2. DevOps - monitoring
    3. dátová analytika (v reálnom čase) - metriky

  • (slide) typy grafov/údajov

    • v pravidelných intervaloch - pravidelné merania
    • v nepravidelných intervaloch - udalostt
    Regular vs Irregular Time Series

InfluxDB

  • (slide) InfluxDB is a programmable and performant time series database, with a common API across OSS, cloud and Enterprise offerings.

    InfluxDB

  • InfluxDB is designed to work with time-series data. SQL databases can handle time-series but weren’t created strictly for that purpose. In short, InfluxDB is made to store a large volume of time-series data and perform real-time analysis on those data, quickly.

  • In InfluxDB, a timestamp identifies a single point in any given data series. This is like an SQL database table where the primary key is pre-set by the system and is always time.

  • InfluxDB also recognizes that your schema preferences may change over time. In InfluxDB you don’t have to define schemas up front. Data points can have one of the fields on a measurement, all of the fields on a measurement, or any number in-between. You can add new fields to a measurement simply by writing a point for that new field.

Terminology

  • Referencing the example above, in general:
    • An InfluxDB measurement (foodships) is similar to an SQL database table.
    • InfluxDB tags ( park_id and planet) are like indexed columns in an SQL database.
    • InfluxDB fields (#_foodships) are like unindexed columns in an SQL database.
    • InfluxDB points (for example, 2015-04-16T12:00:00Z 5) are similar to SQL rows.
  • measurement
  • drzi udaje v UTC

InfluxQL

  • (slide) InfluxQL is an SQL-like query language for interacting with InfluxDB. It has been lovingly crafted to feel familiar to those coming from other SQL or SQL-like environments while also providing features specific to storing and analyzing time series data.

InfluxDB API

  • (slide) Služba poskytuje HTTP REST API pre prácu s databázou štandardne na porte 8086. Pomocou neho je možné:

    • vytvoriť databázu
    • vkladať údaje
    • získavať údaje

  • Nás bude primárne zaujímať vkladanie údajov do databázy. To je možné pomocou HTTP metódy POST. Vkladané údaje majú tieto položky:

    • measurement - názov merania (tabuľky)
    • tags - zoznam značiek s ich hodnotami (metaúdaje)
    • fields - namerané hodnoty (samotné údaje)
    • timestamp - časová značka, ktorá však nie je povinná

  • Príklad vloženia informácií do databázy mydb o meraní teploty v stupňoch Celzia v kuchyni pomocou senzora DHT22 je tu:

    $ curl -i -X POST 'http://localhost:8086/write?db=mydb&precision=s' \
--data-binary 'temperature,room=kitchen,sensor=dht22 value=21.64,unit=C 1585856323'

  • V tomto prípade bola použitá aj časová značka v podobe Unixového času. To je dobré používať napr. vtedy, keď chcete do merania (tabuľky) vložiť staršie údaje. Inak je možné údaje vkladať aj bez uvedenia časovej značky, pričom čas bude doplnený na strane databázového servera:

    $ curl -i -X POST 'http://localhost:8086/write?db=mydb' \
--data-binary 'temperature,room=kitchen,sensor=dht22 value=21.64,unit=C'

  • Keďže sa jedná o protokol HTTP, v jazyku MicroPython môžeme použiť balík urequests:

    import urequests

url = 'http://localhost:8086/write?db=mydb'
data = 'temperature,room=kitchen,sensor=dht22 value=21.64,unit=C'
response = urequests.post(url, data=data.encode())
# check result
response.close()

Visualization with Grafana

  • (slide)
  • ak influxdb drzi udaje v UTC, tak Grafana ich automaticky konvertuje vzhladom na vasu casovu zonu

Best Practices for Building Analytics Dashboards

Overview of Existing Dashboards

HTTP MQTT pypi
io.adafruit.com áno áno adafruit-io
Ubidots áno áno
IBM Watson IoT micropython-watson-iot
ThingSpeak áno áno

Conclusion

Additional Resources