数据处理方案对比及场景选择-日志服务-阿里云

日志服务提供四种数据处理方案：处理插件、写入处理器、数据加工和消费处理器。本文通过对比分析它们的特性和适用场景，帮助您根据实际需求选择合适的数据处理方案。

背景信息

处理插件配置：日志服务采集器提供了丰富的处理配置，不仅支持处理插件，还支持以SPL语句在客户端对数据进行处理。
写入处理器：写入处理器可以与Logstore进行关联，写入Logstore的数据会默认由写入处理器在服务端进行处理。
数据加工：数据先写入一个源Logstore，然后再根据加工规则进行处理，处理后的数据写入到目标Logstore。
消费处理器：通过配置消费处理器，支持在消费Logstore时通过SPL实时进行数据处理，消费处理器支持SDK、Flink、DataWorks等三方服务集成。

方式对比

处理插件、写入处理器、数据加工和消费处理器基本上贯穿了数据存储前（采集时）、数据存储时（写入时）、数据存储后（写入后）的完整生命周期。它们之间的能力有着一定的相似之处，例如都能够对数据进行特定的处理、都支持 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。	一般	不推荐	推荐	不推荐
需要对数据进行过滤，且原始数据可以不需要，希望能够一定程度上节约成本。	一般	推荐	一般	一般