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
](http://ata2-img.cn-hangzhou.img-pub.aliyun-inc.com/5b8cb23e8a6b5ad9c603d15271c465b8.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自動分裂


相關文章