IOT/智慧裝置日誌解決方案（3）：上下游對接

元乙發表於2018-09-10

系列文章：

資料佇列

當資料從遍佈全球的裝置端以及服務端採集上來後，最先會到達資料佇列。佇列承載所有資料的入口和出口，必須具備的兩大能力是：

  • 豐富的上下游對接能力：資料要能從各種方式接入上來，也能夠非常容易的對接各個系統。
  • 彈性伸縮能力：當服務量級上升後，如何快速的擴容；同時如何面對未知的流量激增，防止系統突然打爆。
    下面將從這兩個方面介紹日誌服務LogHub的相關能力：

上下游生態對接

image.png | left | 827x314

為了能降低使用者使用負擔，與生態更好結合，我們也在積極擴充LogHub上下游的生態，包括：

  • 採集端：Logstash、Beats、Log4J等
  • 實時消費端（流計算）：Flink/Blink、Storm、Samza等
  • 儲存端（數倉）：Hadoop、Spark、Presto、Hive等

截止5月已支援30+ 資料接入方案（包括最完整K8S方案）、以及對主流流計算、資料倉儲等引擎支援。

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

彈性伸縮

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

image.png | left | 827x363

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

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

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

image.png | left | 827x315

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


相關文章