日志服务提供四种数据处理方案:处理插件、写入处理器、数据加工和消费处理器。本文通过对比分析它们的特性和适用场景,帮助您根据实际需求选择合适的数据处理方案。
背景信息
方式对比
处理插件、写入处理器、数据加工和消费处理器基本上贯穿了数据存储前(采集时)、数据存储时(写入时)、数据存储后(写入后)的完整生命周期。它们之间的能力有着一定的相似之处,例如都能够对数据进行特定的处理、都支持 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。 |
一般 |
不推荐 |
推荐 |
不推荐 |
|
需要对数据进行过滤,且原始数据可以不需要,希望能够一定程度上节约成本。 |
一般 |
推荐 |
一般 |
一般 |