Telemetrie & Streaming

Telemetrie jako krev IoT systému¶

Senzory bez spolehlivého data pipeline jsou drahý hardware. Měří, ale data nikam nedorazí. Nebo dorazí pozdě. Nebo se ztratí. Nebo přijdou ve špatném pořadí a anomaly detection vygeneruje false alarm.

Stavíme telemetrické řetězce, kde každá zpráva dorazí, kam má, kdy má, a ve správném pořadí. Od senzoru přes MQTT broker do Kafka, přes stream processing do time-series databáze a dashboardu. Každý krok monitorovaný, škálovatelný, odolný.

MQTT jako transport¶

Proč MQTT¶

MQTT (Message Queuing Telemetry Transport) je de facto standard pro IoT komunikaci. Navržený v roce 1999 pro ropné potrubí — spolehlivý přenos přes nespolehlivé satelitní spojení. Dnes na miliardách zařízení.

Vlastnosti klíčové pro IoT:

• Lightweight: 2 byte minimální header. Celá zpráva s payloadem 100B má 102B overhead. HTTP request pro stejná data: 500B+.
• Pub/sub model: Zařízení publikuje na topic, backend subscribuje. Decoupling — zařízení neví (a nepotřebuje vědět), kdo data čte.
• Persistent sessions: Broker si pamatuje subscriptions a nedelivered messages pro offline zařízení. Po reconnectu doručí vše, co zmeškalo.
• Last Will and Testament: Zařízení při připojení definuje „poslední vůli” — zprávu, kterou broker pošle, pokud zařízení nečekaně zmizí. Okamžitá detekce offline zařízení.

Quality of Service¶

Tři úrovně garanty doručení:

• QoS 0 (At most once): Fire-and-forget. Žádné potvrzení. Pro data, kde občasná ztráta nevadí (high-frequency telemetrie, kde chybějící vzorek nahradí interpolace).
• QoS 1 (At least once): Potvrzení doručení. Možné duplikáty. Pro většinu telemetrie — backend musí být idempotentní.
• QoS 2 (Exactly once): Čtyřkrokový handshake. Žádné ztráty, žádné duplikáty. Pro kritická data (transakce, alarmy, commands). Vyšší overhead — používáme jen kde je nutné.

MQTT 5.0 features¶

• Shared subscriptions: Load balancing mezi multiple consumers. Topic $share/group/sensors/+/temperature — zprávy se distribuují round-robin mezi subscribery.
• Topic aliases: Zkrácení opakujících se topic names. Redukce bandwidth o 10-30%.
• Flow control: Receiver může říct „zpomal” — ochrana proti zahlcení pomalého consumera.
• Request/response: Native request/response pattern přes correlation data a response topic.

MQTT broker¶

EMQX: Distribuovaný, cluster-capable. Miliony concurrent connections. Rule engine pro routing a transformaci. Bridge do Kafka, HTTP, databází.

Mosquitto: Lightweight, single-node. Ideální pro edge a menší nasazení. C implementace, minimální resources.

Azure IoT Hub / AWS IoT Core: Managed MQTT broker s integrovaným device managementem. Vendor lock-in, ale zero operations.

Kafka pro stream processing¶

MQTT doručí data do brokeru. Kafka je centrální nervous system — event store, stream processor, integration hub.

Proč Kafka po MQTT¶

MQTT broker je transport — doručí zprávu subscriberům a (typicky) zapomene. Kafka je durable event log — zprávy uložené na disk, retention dny až roky. Replay kdykoliv. Nový consumer zpracuje historická data od začátku.

Architecture pattern:

Device → MQTT Broker → Kafka Connect/Bridge → Kafka → Consumers

Stream processing¶

Kafka Streams nebo Apache Flink pro real-time zpracování:

• Aggregace: Průměrná teplota za posledních 5 minut, maximální vibrace za hodinu
• Windowing: Tumbling, hopping, sliding windows. Session windows pro detekci aktivity.
• Anomaly detection: Z-score, moving average, isolation forest. Alert když hodnota vybočí z baseline.
• Enrichment: Přidání kontextu — device metadata, lokace, zákazník. Join stream s referenčními daty.
• Filtering: Odfiltrování šumu, deduplikace, validace formátu.

Consumer groups¶

Paralelní zpracování přes consumer groups:

• Alerting consumer: Real-time evaluace pravidel, push notification při threshold breach
• Storage consumer: Zápis do time-series DB pro historické dotazy
• Analytics consumer: Agregace pro dashboardy a reporty
• ML consumer: Feature store pro ML modely, training data pipeline

Každý consumer nezávisle škálovatelný. Přidání nového consumera bez dopadu na existující.

Data pipeline architektura¶

Od senzoru po dashboard¶

Sensor → [Local buffer] → MQTT (QoS 1) → MQTT Broker
  → Kafka Connect → Kafka Topic (raw)
    → Stream Processing (validation, enrichment)
      → Kafka Topic (processed)
        → InfluxDB/TimescaleDB (storage)
        → Grafana (visualization)
        → Alert Engine (rules)
        → ML Pipeline (features)

Každý krok je nezávisle škálovatelný, monitorovaný a recoverable.

Dead letter queue¶

Zprávy, které neprojdou validací (špatný formát, neznámé zařízení, mimo rozsah) se neztratí. Putují do dead letter queue pro analýzu:

• Automatická notifikace na DLQ growth
• Dashboard s top error reasons
• Manuální review a reprocessing
• Root cause analýza — špatný firmware? Bug v device kódu?

Komprese a efektivita¶

• Protocol Buffers: Binární serializace, 3-10× menší než JSON. Schema evolution s backward/forward compatibility. Ideální pro high-throughput telemetrii.
• MessagePack: JSON-compatible binární formát. Jednodušší adopce než Protobuf, stále 30-50% menší než JSON.
• Batching na zařízení: Lokální buffer, odeslání po N zprávách nebo T sekundách. Redukce connection overhead.
• Adaptive sampling: Normální provoz: 1 vzorek/min. Anomálie detekována: 10 vzorků/s. Dynamická granularita podle potřeby.

Time-series storage¶

InfluxDB¶

Nativní time-series databáze. Optimalizovaná pro write-heavy workloady:

• Ingest: stovky tisíc bodů za sekundu
• Flux query jazyk pro transformace a analýzu
• Retention policies: automatická expirace starých dat
• Continuous queries pro pre-agregaci

TimescaleDB¶

PostgreSQL extension pro time-series:

• Plný SQL — JOINy s relačními daty (device metadata, zákazníci)
• Hypertables pro automatické partitioning
• Compression: 90-95% úspora místa pro starší data
• Continuous aggregates pro materialized views

Volba¶

InfluxDB pro čistě telemetrické workloady (jednodušší operace, nativní time-series UX). TimescaleDB když potřebujete SQL, JOINy, nebo už máte PostgreSQL stack.

Technologický stack¶

Transport: MQTT 5.0, AMQP, CoAP, HTTP/2.

Brokers: EMQX, Mosquitto, Azure IoT Hub, AWS IoT Core, HiveMQ.

Streaming: Apache Kafka, Kafka Streams, Apache Flink, Redpanda.

Storage: InfluxDB, TimescaleDB, QuestDB, Apache Parquet (archiv).

Serialization: Protocol Buffers, MessagePack, Avro, JSON.

Visualization: Grafana, custom dashboards.

Souvisí s