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方案）、以及對主流流計算、資料倉儲等引擎支援。

](https://i.iter01.com/images/7a1810fc7563855631f515139e8b1799e7aff750bc4fefef85a81eed863f39bc.png)

彈性伸縮

​在解決各類上下游對接問題後，我們把問題聚焦在服務端流量這個問題上。熟悉Kafka都知道，通過Partition策略可以將服務端處理資源標準化：例如定義一個標準的單元Partition或Shard（例如每個Shard固定5MB/S寫，10MB/S讀）。當業務高峰期時，可以後臺Split Shard以獲取2倍的吞吐量。

這種方法看起來很工程化，但在使用過程中有兩個難以繞開的現實問題：

• 業務無法預測：事先無法準確預估資料量，預設多少個shard才合適呢
• 人的反應滯後：資料量隨時會突增，人不一定能夠及時處理，長時間超出服務端負載能力會有資料丟失風險

​ 針對以上情況，LogHub提供了全球首創Shard自動分裂功能：在使用者開啟該功能後，後臺系統實時監控每個shard的流量，如果發現一個shard的寫入在一段時間內，有連續出現超過shard處理能力的情況，會觸發shard的自動分裂，時刻保障業務流量。

更多細節可以參考這篇文章: 支援Shard自動分裂