簡介
阿裡雲 SLS 是雲上一站式大資料處理、分析平台。SLS 資料加工功能則是一個可托管、高可用、可擴充的資料處理服務，廣泛适用于資料的規整、富化、分發、彙總、重建索引等場景。Logstash 是 ELK 資料架構中，作為資料處理的組成部件，其能夠從多個來源采集資料，轉換資料，然後将資料發送到目标“存儲庫”中。這裡，我們就對 SLS 資料加工和自建 Logstash 這二者做一個全方位的對比。
SLS 資料加工
- 易用：功能豐富，已經實作 200+ DSL 算子。開箱即用，無需部署、運維
- 實時：實時處理、秒級延遲。可以通過源 logstore 的 shard 數目實作即時擴充
- 實惠：按量付費，無需預留。成本才是 0.15元/GB
Logstash
Logstash 是開源的資料處理工具，生态非常豐富，可以嵌入到很多資料處理架構中。而且從 軟體實用角度來說，它是免費的。但是系統的計算資源，以及系統的部署、運維工作都是自理。
對比
功能
資料處理包括4個主要場景：事件操作（過濾/複制/分裂）、字段操作（過濾/解析/轉換）、資料富化、資料聚集。從這4個場景對比二者的功能。
| 場景 | 資料加工 | |
|---|---|---|
| 事件操作 （過濾/複制/分裂） | drop/keep copy split drop_field/keep_field | drop clone |
| 字段操作 （過濾/解析/轉換） | REGEX (GROK) JSON KV …… | mutate/alter GROK CSV |
| 資料富化 | GeoIP MySQL OSS檔案 IP/OSS風險掃描（即将上線） | DNS JDBC |
| 資料聚集 | 規劃中 | aggregate 支援單worker内，無法擴充 |
從以上對比表格中可以看出，前2個場景二者都很好的支援。在資料富化場景中，資料加工所支援的富化途徑更為豐富。資料加工暫時不支援資料聚集場景（在規劃中）。Logstash 的 aggregate 能夠支援部分聚集功能，但是隻能在單 worker 内部進行聚集，無法擴充到多 worker，更沒法擴充到叢集，是以 Logstash aggregate 無法應用到大資料場景。
成本
執行個體：nginx 通路日志解析
Nginx 是目前非常受歡迎的 WebService。這裡就以 nginx 的通路日志解析為例，分别看一下資料加工的Logstash 的解析代碼。
原始日志（文本）：
192.168.56.1 - - [21/Apr/2020:02:42:11 +0800] "GET /?a=1&b=2&c=3&e=11 HTTP/1.1" 200 612 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0" 解析目标：
- 通過正則比對，抽取出通路日志中的每個組成部分
- 把時間轉換為标準 ISO8601 格式
- 抽取請求 URL 中的參數
- 抽取出請求 UserAgent 的資訊
{
"os": "{\"family\": \"Mac OS X\", \"major\": \"10\", \"minor\": \"15\", \"patch\": \"3\"}",
"bytes": "612",
"client": "192.168.1.1",
"status": "200",
"http_version": "HTTP/1.1\"",
"uri": "/",
"param:e": "11",
"time": "2020-04-21 02:42:11",
"refer": "\"-\"",
"device": "{\"family\": \"Other\"}",
"user_agent": "{\"family\": \"Chrome\", \"major\": \"80\", \"minor\": \"0\", \"patch\": \"3987\"}",
"method": "GET",
"param:c": "3",
"user": "-",
"param:a": "1",
"param:b": "2"
} e_regex("message", grok("%{IPORHOST:client} - %{USER:user} \[%{HTTPDATE:time}\] %{QS:request} %{NUMBER:status} (?:%{NUMBER:bytes}|-) %{QS:refer} %{QS:user_agent}"))
e_regex("request", grok("%{WORD:method} %{URIPATH:uri}%{URIPARAM:params} %{NOTSPACE:http_version}"))
e_set("time", dt_strftime(dt_strptime(v("time"), "%d/%b/%Y:%H:%M:%S %z"), "%Y-%m-%d %H:%M:%S"))
e_kv("params", prefix="param:")
e_set("user_agent", ua_parse_all(v("user_agent")))
e_json("user_agent", depth=1, mode="overwrite")
e_drop_fields("message", "request", "params", regex=False) Logstash 規則
filter {
grok {
match => { "message" => "%{IPORHOST:client} - %{USER:user} \[%{HTTPDATE:time}\] %{QS:request} %{NUMBER:status} (?:%{NUMBER:bytes}|-) %{QS:refer} %{QS:user_agent}" }
}
grok {
match => { "request" => "%{WORD:method} %{URIPATH:uri}%{URIPARAM:params} %{NOTSPACE:http_version}" }
}
date {
match => ["time", "dd/MMM/yyyy:HH:mm:ss Z"]
target => "time"
}
kv {
source => "params"
prefix => "param:"
field_split => "?&"
}
useragent {
target => "user_agent"
source => "user_agent"
}
mutate {
remove_field => [ "message", "request", "params" ]
}
} 成本計算
以上執行個體，基于阿裡雲 ecs.g6e.xlarge 型号的 ECS 進行測試 logstash，4 CPU + 16 GB RAM + 100 GB ESSD，成本 578 元/月（包年包月）。在此場景下，logstash 的性能為 8000條/秒/Core。測試場景預設：
- 系統每天的 PV 為 10億
- 峰值 QPS 是平均值的5倍：10億/86400秒 * 5 = 57870/秒
- 平均每條通路日志 200 Bytes
資料加工：
- 每個月的資料量：10億 * 200 Bytes * 30 = 5588 GB/月
- 總成本：0.15 元/GB/月 * 7153 GB = 838 元/月
Logstash：
- 計算資源需求：57870/秒 / 8000條/秒/Core = 7.23 Core，即2台 ecs.g6e.xlarge
- 支撐業務增長需求，預留 20% 水位：578 元/月 * 2 * 120% = 1387/月
根據以上計算，在該測試場景下，SLS 資料加工的成本僅僅是自建 logstash 所需的資源成本的 60%。
綜合
| 次元 | ||
|---|---|---|
| 1. Python 文法，靈活 2. 預定義算子豐富 3. 資料富化途徑豐富 | 1. 自定義文法 2. 支援 Ruby 代碼 | |
| 實時性 | 秒級 服務端彈性伸縮保證 | 叢集資源算力保證 |
| 緩存 | 支援 無需任何配置 | Kafaka/Persistent Queues 部署、運維自理 |
| 擴充 | 源 logstore 的 shard 數目 簡單友善、即時生效 | 前置 Kafaka / LoadBalancer 額外部署 |
| 資源預留 | 不需要 按量付費 | 需要 支撐業務增長、非預期爆發 |
| 運維 | 開箱即用、免運維 | 系統部署、運維完全自理 |
| 實惠 （測試中僅為自建 logstash 所需資源成本的60%） | 除了資源成本，還需考慮系統運維成本 |
從以上對比表格中不難看出，在資料處理的業務場景中，SLS 資料加工整體比 logstash 更有優勢。Logstash 的于是在于其通用性，各種資料處理架構都可嵌入使用。
總結
通過以上的對比，我們的到 SLS 資料加工和 自建 logstash 分别适用于各自的場景。
- 在 SLS 大資料分析平台上，無運維、易擴充、成本實惠
- 适合從一般資料量、到超大型資料量的處理
自建 Logstash：
- 開源、生态豐富适，各種資料處理架構通用
- 适合一般資料量的處理（面對大型資料量場景，運維成本昂貴）