perché e quando ho bisogno del broker mqtt per l'applicazione IOT/M2M

Question

Solo una domanda stupida, spero che qualcuno possa rispondere a questa domanda.

Sono un po 'confuso riguardo al broker MQTT. Fondamentalmente, la confusione è, ci sono così tante cose che vengono utilizzate per l'archiviazione, il trasferimento e l'elaborazione dei dati (come Flume, HDInsight, Spark, ecc.). Quindi, quando e perché devo usare un broker MQTT?

Se desidero utilizzare l'applicazione iot di Windows 10 con HiveMQ, da dove posso ottenere i dettagli? come usarlo? come ottenere ottenere beneficio da questo broker MQTT? Non posso inviare dati dalla mia applicazione IoT direttamente usando Azure o HDFS? Quindi, come si adatta il broker MQTT o mi aiuta a realizzare qualcosa?

Sono nuovo di tutti questi e ho cercato di trovare alcuni tutorial, tuttavia non sto ottenendo nulla di corretto. Si prega di spiegarlo in maggiori dettagli o di fornire alcuni tutorial per questo?

Answer 1

Questa è una scelta architettonica. Le applicazioni IoT sono possibili senza MQTT ma ci sono alcuni vantaggi quando si utilizza MQTT. Se siete completamente nuovi a MQTT, date un'occhiata a questa serie approfondita MQTT: http://forkbomb-blog.de/2015/all-you-need-to-know-about-mqtt

Fondamentalmente il vantaggio architettonico principale è publish/subscribe progettato per comunicazioni a bassa latenza e throughput (mobile) con un overhead di protocollo minimo (che è importante se la larghezza di banda è un premio). Puoi disaccoppiare completamente consumatori e produttori.

HDFS è il file system (distribuito) Hadoop ed è il fondamento per l'elaborazione Mappa/Riduzione. Non è paragonabile a un broker MQTT. Il broker MQTT potrebbe scrivere su HDFS, tuttavia (nel caso di HiveMQ con un plug-in personalizzato).

Fondamentalmente MQTT è un protocollo, mentre i prodotti che state nota sono, beh, i prodotti che risolvono completamente diversi problemi:

Flume è fondamentalmente utilizzato per l'aggregazione di registro su larga scala. Non userete MQTT per questo, almeno non c'è troppo vantaggio perché questo è tipicamente fatto nelle applicazioni di back-end.

Spark e Hadoop brillano durante lo scricchiolio dei Big Data. Sono una struttura e non una soluzione pronta per l'uso. Non sono realmente paragonabili a MQTT. Spesso i broker MQTT come HiveMQ vengono utilizzati insieme a questi, Spark/Hadoop per l'elaborazione dei dati e HiveMQ per la comunicazione.

Spero che questo ti aiuti a iniziare. La cosa migliore sarebbe leggere sui casi d'uso tipici di tutte queste tecnologie, questo è un po 'troppo ampio per una singola risposta SO.

Answer 2

MQTT è un protocollo client-server per il trasporto su base pub che ha un overhead comparativamente piccolo, e quindi applicabile alle applicazioni mobili e IoT (a differenza di Flume, ecc.). Il broker MQTT è fondamentalmente un server che gestisce la messaggistica da/verso i client MQTT e tra questi. La funzionalità si ferma praticamente sul livello di trasporto, anche se esistono vari add-on MQTT.

Se si desidera implementare una soluzione che trasferisca in modo affidabile i dati dai dispositivi IoT al sistema di back-end per l'elaborazione, suggerirei di dare un'occhiata a Kaa open-source IoT platform. Va molto oltre MQTT fornendo non solo il livello di trasporto, adatto per dispositivi IoT a basso consumo, ma anche una buona parte della logica a livello di applicazione (inclusi i binding di oggetti per le strutture dati a livello di applicazione, la persistenza dei dati temporanei, ecc. .).

Ecco un collegamento a un webinar che spiega how to build a scalable IoT analytics system with Kaa and Spark in less than an hour.

Answer 3

MQTT è un trasporto dati, quindi la cosa normale che devo confrontare è HTTP. L'HTTP ha due caratteristiche importanti, a) Passa da un punto all'altro, b) È richiesta/risposta, quindi solo un capo può avviare un trasferimento di dati. MQTT collega molti punti finali a molti endpoint e ciascuna estremità può avviare un trasferimento di dati. Quindi, se hai un solo dispositivo e solo un servizio o una persona che potrà accedervi, e solo tramite il polling, allora HTTP è ottimo. MQTT significa che molti dispositivi possono inviare dati a molti servizi o persone, e viceversa. La tua domanda presuppone che i tuoi dati finiscano sempre in una sorta di archivio dati, ma molte interazioni riguardano eventi e rispondono immediatamente a loro, come suonare un campanello o abbassare il carrello. In questi casi, spesso vorrai sia registrare i dati, sia intervenire immediatamente, come se il tuo telefono emettesse un suono campanello.

Infine, i dati vengono inviati a MQTT semanticamente, anziché tramite indirizzo IP. Ciò significa che i tuoi servizi si abbonano a/mikeshouse/campanello piuttosto che al polling 192.168.22.4, che è un enorme guadagno una volta che hai un numero di dispositivi.