系列文章：
- 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自動分裂