Log Service提供四種資料處理方案：處理外掛程式、寫入處理器、資料加工和消費處理器。本文通過對比分析它們的特性和適用情境，協助您根據實際需求選擇合適的資料處理方案。
背景資訊
方式對比
處理外掛程式、寫入處理器、資料加工和消費處理器基本上貫穿了資料存放區前（採集時）、資料存放區時（寫入時）、資料存放區後（寫入後）的完整生命週期。它們之間的能力有著一定的相似之處，例如都能夠對資料進行特定的處理、都支援 SPL 語言。不過在具體的使用情境和能力上，這幾種資料處理方式之間其實仍然存在著一些差異。
比較維度 | 處理外掛程式 | 寫入處理器 | 資料加工 | 消費處理器 |
資料處理階段 | 儲存前（採集時）。 | 儲存時。 | 儲存後。 | 儲存後 |
寫到多個 Logstore | 單個採集配置不支援，但是可以用多個採集配置結合處理外掛程式。 | 不支援。 | 支援。 | 不支援 |
SPL | 支援。 | 支援。 | 支援。 | 支援 |
支援的SPL指令 | 支援處理單行資料的指令，即輸入一行資料，輸出為0行或1行結果。 | 支援處理單行資料的指令，即輸入一行資料，輸出為0行或1行結果。 | 支援完整的 SPL 指令。 | 支援完整的 SPL 指令。 |
敏感性資料不落盤 | 支援。 | 支援。 | 不支援，資料會經過源Logstore。 | 不支援，資料會經過源 LogStore。 |
資源佔用 | 需要消耗一定的用戶端資源。 | 服務端自動調整，使用者不感知。 | 服務端自動調整，使用者不感知。 | 服務端自動調整，使用者不感知。 |
效能影響 | 根據外掛程式個數和配置的複雜程度對採集效能有少許影響，但不影響資料寫入時的效能。 | 根據資料複雜度和 SPL 語句複雜程度，對寫入效能有少許影響（根據請求的資料包大小及SPL語句的複雜度，單次請求延遲會增加數毫秒到數十毫秒。） | 源Logstore寫入效能不受影響。 | 源 LogStore 寫入效能不受影響。 |
需求情境覆蓋 | 較多。 | 正常。 | 多。 | 多 |
成本 | 無 SLS 資料處理費用，但是會佔用一定的用戶端資源。 | 資料處理費用。在資料過濾情境下，該項費用一般會低於所減少的資料的流量和儲存費用。 | 源Logstore費用 + 資料處理費用。可以通過設定源Logstore資料儲存1天以及關閉索引，來減少源Logstore的成本。 | 源 LogStore 費用 + 資料處理費用。可以通過設定源 LogStore 資料儲存1天以及關閉索引，來減少源 LogStore 的成本。 |
容錯性 | 外掛程式中可以配置處理失敗時是否保留原始欄位。 | 可配置處理失敗後是否保留未經處理資料。 | 由於來源資料已經儲存，加工規則失敗情況可以選擇重新加工。同時，可以建立多個加工任務分別加工。 | 由於來源資料已經儲存，Flink/Dataworks/SDK消費組整合SPL消費規則對於錯誤自動重試。 |
根據能力的差異，以下列舉了在典型情境下寫入處理器、Logtail處理配置及資料加工的方案對比：
情境 | Logtail處理配置 | 寫入處理器 | 資料加工 | 消費處理器 |
簡單資料處理，例如只是簡單的單行資料處理，且不涉及複雜計算邏輯。 | 推薦 | 推薦 | 推薦 | 推薦 |
複雜資料處理，例如涉及複雜的計算邏輯，或者需要多種條件判斷、視窗彙總、維表富化等。 | 一般 | 一般 | 推薦 | 推薦 |
用戶端資源受限，例如Logtail能夠使用的計算資源比較有限。 | 一般 | 推薦 | 推薦 | 推薦 |
用戶端管控受限，例如無許可權修改採集側的 Logtail 配置或 SDK 寫入邏輯。 | 不推薦 | 推薦 | 推薦 | 推薦 |
服務端管控受限，例如無許可權修改 Logstore或加工配置。 | 推薦 | 不推薦 | 不推薦 | 不推薦 |
對資料寫入延遲和效能比較敏感，例如希望未經處理資料儘可能快地採集。 | 一般 | 一般 | 推薦 | 推薦 |
資料脫敏，且敏感性資料可以落盤。 | 推薦 | 推薦 | 推薦 | 推薦 |
資料脫敏，且敏感性資料不可以落盤。 | 推薦 | 推薦 | 不推薦 | 不推薦 |
資料富化（不依賴外部資料源），例如增加一個新的欄位，內容為固定值或者從已有欄位中提取出來。 | 一般 | 推薦 | 推薦 | 推薦 |
資料富化（依賴外部資料源），例如根據日誌欄位去 MySQL 表中查出其它富化資料。 | 不推薦 | 不推薦 | 推薦 | 推薦 |
資料分發，將資料根據不同的條件寫入到不同的Logstore。 | 一般 | 不推薦 | 推薦 | 不推薦 |
需要對資料進行過濾，且未經處理資料可以不需要，希望能夠一定程度上節約成本。 | 一般 | 推薦 | 一般 | 一般 |