數據隊列
當數據從遍佈全球的設備端以及服務端採集上來後，最先會到達數據隊列。隊列承載所有數據的入口和出口，必須具備的兩大能力是：
- 豐富的上下游對接能力：數據要能從各種方式接入上來，也能夠非常容易的對接各個系統。
- 彈性伸縮能力：當服務量級上升後，如何快速的擴容；同時如何面對未知的流量激增，防止系統突然打爆。
- 下面將從這兩個方面介紹日誌服務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的自動分裂，時刻保障業務流量。
分享到:
閱讀更多 智能日誌分析 的文章
