IOT/智能设备日志解决方案（3）：上下游对接

系列文章：

• IOT/智能设备日志解决方案（1）：概述
• IOT/智能设备日志解决方案（2）：全方位数据采集
• IOT/智能设备日志解决方案（3）：上下游对接
• IOT/智能设备日志解决方案（4）：计算与分析
• IOT/智能设备日志解决方案（5）：线上问题调查
• IOT/智能设备日志解决方案（6）：实时监控
• IOT/智能设备日志解决方案（7）：搭建业务大盘

数据队列

当数据从遍布全球的设备端以及服务端采集上来后，最先会到达数据队列。队列承载所有数据的入口和出口，必须具备的两大能力是：

• 丰富的上下游对接能力：数据要能从各种方式接入上来，也能够非常容易的对接各个系统。
• 弹性伸缩能力：当服务量级上升后，如何快速的扩容；同时如何面对未知的流量激增，防止系统突然打爆。
  下面将从这两个方面介绍日志服务LogHub的相关能力：

上下游生态对接

为了能降低用户使用负担，与生态更好结合，我们也在积极拓展LogHub上下游的生态，包括：

• 采集端：Logstash、Beats、Log4J等
• 实时消费端（流计算）：Flink/Blink、Storm、Samza等
• 存储端（数仓）：Hadoop、Spark、Presto、Hive等

截止5月已支持30+ 数据接入方案（包括最完整K8S方案）、以及对主流流计算、数据仓库等引擎支持。

](http://ata2-img.cn-hangzhou.img-pub.aliyun-inc.com/5b8cb23e8a6b5ad9c603d15271c465b8.png)

弹性伸缩

​在解决各类上下游对接问题后，我们把问题聚焦在服务端流量这个问题上。熟悉Kafka都知道，通过Partition策略可以将服务端处理资源标准化：例如定义一个标准的单元Partition或Shard（例如每个Shard固定5MB/S写，10MB/S读）。当业务高峰期时，可以后台Split Shard以获取2倍的吞吐量。

这种方法看起来很工程化，但在使用过程中有两个难以绕开的现实问题：

• 业务无法预测：事先无法准确预估数据量，预设多少个shard才合适呢
• 人的反应滞后：数据量随时会突增，人不一定能够及时处理，长时间超出服务端负载能力会有数据丢失风险

​ 针对以上情况，LogHub提供了全球首创Shard自动分裂功能：在用户开启该功能后，后台系统实时监控每个shard的流量，如果发现一个shard的写入在一段时间内，有连续出现超过shard处理能力的情况，会触发shard的自动分裂，时刻保障业务流量。

更多细节可以参考这篇文章: 支持Shard自动分裂