日志服务提供三种数据处理方案：写入处理器、Logtail配置及数据加工。本文通过对比分析它们的特性和适用场景，帮助您根据实际需求选择合适的数据处理方案。
背景信息
Logtail处理配置：Logtail提供了丰富的处理配置，不仅支持处理插件，还支持以SPL语句在客户端对数据进行处理。
写入处理器：写入处理器可以与Logstore进行关联，写入Logstore的数据会默认经过写入处理器在服务端进行处理。
数据加工：数据先写入一个源Logstore，然后再根据加工规则进行处理，处理后的数据写入到目标Logstore。
三种方式对比
写入处理器、Logtail插件和数据加工是贯穿数据采集、存储前、存储时及存储后生命周期的三种主要数据处理方式。尽管它们都能对数据进行特定处理并支持SPL语言，但在具体使用场景和功能上存在差异。
比较维度 | Logtail处理配置 | 写入处理器 | 数据加工 |
数据处理阶段 | 存储前（采集时）。 | 存储时。 | 存储后。 |
写到多个 Logstore | 单个采集配置不支持，但是可以用多个采集配置结合处理插件。 | 不支持。 | 支持。 |
SPL | 支持。 | 支持。 | 支持。 |
支持的SPL指令 | 支持处理单行数据的指令，即输入一行数据，输出为0行或1行结果。 | 支持处理单行数据的指令，即输入一行数据，输出为0行或1行结果。 | 支持完整的 SPL 指令。 |
敏感数据不落盘 | 支持。 | 支持。 | 不支持，数据会经过源Logstore。 |
资源占用 | 需要消耗一定的客户端资源。 | 服务端自动伸缩，用户不感知。 | 服务端自动伸缩，用户不感知。 |
性能影响 | 根据插件个数和配置的复杂程度对采集性能有少许影响，不影响数据写入时的性能。 | 根据数据复杂度和 SPL 语句复杂程度，对写入性能有少许影响（根据请求的数据包大小及SPL语句的复杂度，单次请求延迟会增加数毫秒到数十毫秒。） | 源Logstore写入性能不受影响。 |
需求场景覆盖 | 较多。 | 正常。 | 多。 |
成本 | 无 SLS 数据处理费用，但是会占用一定的客户端资源。 | 数据处理费用。在数据过滤场景下，该项费用一般会低于所减少的数据的流量和存储量费用。 | 源Logstore费用 + 数据处理费用。可以通过设置源Logstore数据保存1天以及关闭索引，来减少源Logstore的成本。 |
容错性 | 插件中可以配置处理失败时是否保留原始字段。 | 可配置处理失败后是否保留原始数据。 | 由于源数据已经存储，加工规则失败情况可以选择重新加工。且可以创建多个加工任务分别加工。 |
根据能力的差异，以下列举了在典型场景下写入处理器、Logtail处理配置及数据加工的方案对比：
场景 | Logtail处理配置 | 写出处理器 | 数据加工 |
简单数据处理，例如只是简单的单行数据处理，且不涉及复杂计算逻辑。 | 推荐 | 推荐 | 推荐 |
复杂数据处理，例如涉及复杂的计算逻辑，或者需要多种条件判断、窗口聚合、维表富化等。 | 一般 | 一般 | 推荐 |
客户端资源受限，例如Logtail能够使用的计算资源比较有限。 | 一般 | 推荐 | 推荐 |
客户端管控受限，例如无权限修改采集侧的 Logtail 配置或 SDK 写入逻辑。 | 不推荐 | 推荐 | 推荐 |
服务端管控受限，例如无权限修改 Logstore或加工配置。 | 推荐 | 不推荐 | 不推荐 |
对数据写入延迟和性能比较敏感，例如希望原始数据尽可能快地采集。 | 一般 | 一般 | 推荐 |
数据脱敏，且敏感数据可以落盘。 | 推荐 | 推荐 | 推荐 |
数据脱敏，且敏感数据不可以落盘。 | 推荐 | 推荐 | 不推荐 |
数据富化（不依赖外部数据源），例如增加一个新的字段，内容为固定值或者从已有字段中提取出来。 | 一般 | 推荐 | 推荐 |
数据富化（依赖外部数据源），例如根据日志字段去 MySQL 表中查出其它富化数据。 | 不推荐 | 不推荐 | 推荐 |
数据分发，将数据根据不同的条件写入到不同的Logstore。 | 一般 | 不推荐 | 推荐 |
需要对数据进行过滤，且原始数据可以不需要，希望能够一定程度上节约成本。 | 一般 | 推荐 | 一般 |