技术资讯 | Apache Kafka携手MQTT 的IoT思路

Posted 2021-04-20 天津美腾科技有限公司

文章来源于网络

一提到物联网，许多研发人员首先想到的是微控制器，集成主板，单片机，传感器和各种各样的电子器件。当然设备的信号采集毋庸置疑是物联网系统的基础，然而这些连接带来的核心价值是依靠这些设备所采集到的数据。

设备层也只是物联网领域的冰山一角，它的下一环节数据平台要承受着瀑布一般的数据流量。目前一个关键的健壮的技术支撑是Apache Kafka，一个开源的用来处理巨量数据收纳工具。它在一个数据处理中心是充当数据流水线的网关角色，从而提供给Apache Storm，Apache Spark和Apache Hadoop集群去处理。

如果你是一个打算以物联网为职业规划的研发人员，现在是时候开始钻研Apache Kafka了。这篇文章带您探索Apache Kafka在构建可伸缩的物联网平台的方案。

Kafka: 一个高性能的传感器数据收纳层

IoT设备包含有各种各样的传感器，可以产生多种数据点，并且被高频采集。一个简单的恒温器每分钟可能产生几字节的数据，而联网汽车或风力涡轮机在几秒钟就会产生几GB的数据量。这些巨量的数据集会被收集到数据处理流水线，从而进行存储，转换，处理，查询和分析。

每个数据集由多种数据点组成，表示特定的指标集。例如：一个联网的供热，通风设备和空调系统 将会报告环境温度，期望温度，湿度，空气质量，风速，负载和能源消耗 等等指标。

以一个大商场的复杂度，这些数据点会频繁的从上百台通风设备上采集。但是这些设备可能没有能力运行完整的TCP的协议，它们使用的协议一般如 Z-Wave 和 ZigBee 把数据发送到一个中心网关，这个网关有能力把数据点收集到系统内。

然后这个网关把数据推送到 Apache Kafka集群，使数据被多路消费。需要实时监控的数据点分流到Hot Path，在我们的通风系统场景，比如要追踪温度，湿度和空气质量这些实时指标。 这些数据点可以流转到Apache Storm 和 Apache Spark集群做接近实时的处理。

一些指标比如：负载和能源消耗是针对一段时间的数据进行分析。这些数据的分析是典型的Cold Path流水线做的批处理分析。利用Hapoop 的MapReduce 定时任务可以来分析这些设备能源消耗情况。

无论数据被分流到哪个路径，首要的是先得被收集到系统。Apache Kafka 扮演着高性能的数据收集器的角色来暂存巨量的数据集。Hot Path 与 Code Path 的处理流水线模块作为Apache Kafka的订阅者。 

Kafka vs. MQTT 

Apache Kafka 不是用来代替MQTT的，MQTT是用来机器与机器(M2M)通信的消息代理。 而Kafka的设计与MQTT的目标有很大的不同。

在物联网领域，设备可以分为传感器和驱动器2大类。传感器产生数据点，而驱动器是一种机器组件可以被命令控制。比如：环境照明设备可以用来调节室内的LEB灯泡的亮度。在这个场景中，光感应器需要与LEB灯泡通信，这就是一个典型的M2M通信。MQTT是为M2M应用场景作了优化的协议。

正因为MQTT是为低功耗设备设计的，所以它无法收集巨量的数据集。另一方面，Apache Kafka可以处理高速率数据收集而不依赖M2M 。

可扩展的IoT方案是仍用MQTT作设备间通信，而依靠Kafka作传感器数据收集。可以桥接Kafka 和 MQTT 作收集和M2M。但是推荐的是保持它俩独立配置，即设备或者设备网关作为Kafka的消息生产者， MQTT消息代理仍然处理M2M的通信。 

Kafka vs. HTTP/REST 

Apache Kafka 暴露了TCP端口基于二进制协议。客户端在推送消息前，会初始化一个socket连接，然后顺序的写请求消息并读回相应的响应消息。这个协议在建议、断开连接时不需要握手。

因为Kafka 不使用HTTP作收集，使它可以具有高性能和弹性。客户端可以连接到任意一个Kafka集群中的实例去收集数据。这个架构利用原生TCP socket连接来提供最大化的伸缩性和吞吐量。 

尽管是有可能用HTTP Proxy来和Kafka集群通信，但是推荐的做法是用本地客户端库。因为Kafka是用Java写的，所以用Java的客户端库开发可以得到最佳的性能。社区也开发了Golang，Python甚至 Node.js的优化客户端库。 Shopify贡献了它的Golang Kafka客户端库名叫：Sarama。 Mailgun团队在Rackspace开发了Kafka-Pixy，它是一个Kafka的一个HTTP代理。 另外还有多个库供给Python, C#, Ruby和其它语言使用。

大多数IoT网关都有足够的能力运行Java, Go和Python。为了获得最佳性能和吞吐量，推荐使用为Kafka协议专门设计的本地客户端库。

性能初探

引用别人的实验过程（http://www.landoop.com/blog/2017/01/mqtt-kafka-connect-with-ais-data/）， 为使消息可靠，把MQTT的QoS设置成了1，即确保发送一次。 即设备发送消息到MQTT，MQTT推送消息到Kafka，一旦发回ACK到源设备，它就继续处理下一条消息。下图说明了消息路径： 

在笔记本（Intel i7-3630QM, 16GB RAM）上运行这个示例 结果是 30,000 msg/秒。 在Kafka服务器集群（3台相当好的服务器128GB RAM, 2× Intel Xeon E5-2620 ），可以在很长时间内维持平均65,000 msg / 秒 (约 6.55MiB / 秒)  的速率。 可以参考下图：

如果我们用Golang直接向broker写数据我们可以得到更大量的数据（约60w/秒），所以延迟时间并不是来自broker的解码与序列化。

另一类测试是各种组合的集群配置（变化的分区数，连接数，副本数），并没有看到明显的性能变化：

像刚才指出的，我们采用了QoS为1的MQTT质量要求，意味着数据加压端会等待每一条的确认反馈信息再发下一条，这是最健壮的也是最推荐的方式。 所以加压端会有一定的等待时间使用压力不足，所以我们有理由相信通过增加MQTT broker节点数，可以线性的提高吞吐量到至少50w/秒。并且在IoT场景里，这也是非常可能出现的场景：多个MQTT网关位于不同的地区。

综上所述，当我们面对的场景是设备很多，并且频度数据量很大，又要与云端有交互又多租户，那么使用Apache Kafka + MQTT 是值得深入研究的一个方向。