зачем и когда мне нужен брокер mqtt для приложения IOT / M2M

MQTT - это протокол клиент-сервер для транспорта на основе pub-sub, который имеет сравнительно небольшие накладные расходы и, следовательно, применим к мобильным приложениям и приложениям IoT (в отличие от Flume и т. Д.). Брокер MQTT - это, по сути, сервер, который обрабатывает обмен сообщениями между клиентами MQTT и между ними. Функциональность в значительной степени ограничивается транспортным уровнем, хотя существуют различные надстройки MQTT.

Если вы хотите реализовать решение, которое могло бы надежно передавать данные с ваших IoT-устройств в серверную систему для обработки, я бы посоветовал вам взглянуть на Платформа Интернета вещей Kaa с открытым исходным кодом. Он идет намного дальше, чем MQTT, предоставляя не только транспортный уровень, подходящий для маломощных устройств IoT, но также прочный фрагмент логики уровня приложения (включая привязки объектов для структур данных уровня приложения, временное сохранение данных и т. Д. .).

Вот ссылка на веб-семинар, в котором объясняется как создать масштабируемую систему аналитики Интернета вещей с помощью Kaa и Spark. менее чем за час.

Это архитектурный выбор. Приложения IoT возможны без MQTT, но при использовании MQTT есть некоторые преимущества. Если вы новичок в MQTT, ознакомьтесь с этой подробной серией статей о MQTT: http://forkbomb-blog.de/2015/all-you-need-to-know-about-mqtt

По сути, основным архитектурным преимуществом является публикация / подписка, предназначенная для мобильной связи с низкой задержкой и высокой пропускной способностью с минимальными затратами протокола (что важно, если пропускная способность ограничена). Вы можете полностью разделить потребителей и производителей.

HDFS - это (распределенная) файловая система Hadoop, которая является основой для обработки Map / Reduce. Это не сравнимо с брокером MQTT. Брокер MQTT может писать в HDFS (в случае HiveMQ с настраиваемым плагином).

По сути, MQTT - это протокол, а упомянутые вами продукты - это продукты, которые решают совершенно разные проблемы:

Flume в основном используется для масштабной агрегации журналов. Вы не будете использовать для этого MQTT, по крайней мере, это не так много преимуществ, потому что это обычно делается в бэкэнд-приложениях.

Spark и Hadoop отлично справляются с проблемой больших данных. Они представляют собой основу, а не готовое решение. Они не совсем сопоставимы с MQTT. Часто брокеры MQTT, такие как HiveMQ, используются вместе с ними, Spark / Hadoop для обработки данных и HiveMQ для связи.

Надеюсь, это поможет вам начать работу. Лучше всего было бы прочитать о типичных случаях использования всех этих технологий, это слишком широко для одного ответа SO.

MQTT - это транспорт данных, поэтому обычно мне приходится сравнивать его с HTTP. HTTP имеет две важные характеристики: а) он переходит из одной точки в другую, б) это запрос / ответ, поэтому только один конец может начать передачу данных. MQTT соединяет множество конечных точек со многими конечными точками, и любой конец может начать передачу данных. Итак, если у вас есть только одно устройство и только одна служба или человек, который когда-либо получит к нему доступ, и только путем опроса, тогда HTTP - отличный вариант. MQTT означает, что многие устройства могут публиковать данные для множества служб или людей, И наоборот. В вашем вопросе предполагается, что ваши данные всегда будут попадать в какое-то хранилище данных, но многие взаимодействия связаны с событиями и немедленным реагированием на них, например, звонок в дверь или опускание шасси. В этих случаях вам часто нужно как записать данные, так и выполнить немедленное действие, например, ваш телефон издает дверной звонок.

Наконец, вы отправляете данные в MQTT семантически, а не по IP-адресу. Это означает, что ваши службы подписываются на / mikeshouse / doorbell, а не на опрос 192.168.22.4, что является огромным преимуществом, если у вас есть несколько устройств.