本文档为您介绍进行数据加工时，会影响加工性能的可能的因素。帮助您解决加工性能问题。
根据加工原理，数据加工任务的总体速度取决于源Shard的数量、用户配置的规则逻辑和规则复杂度。一般可以按照每Shard处理1MB/s（压缩前）流量规划，也就是大约85 GB每天每Shard规划。例如：源Logstore的数据写入速度是每天1 TB，那么需要分裂源Logstore的Shard数量为1024GB/85=12个。关于Shard分裂请参见分裂Shard。
数据加工性能
数据加工速率与加工规则有关，具体体现如下：
写出输出
与事件大小相关。写出事件越多（事件进行了分裂），写出事件字段越多，内容越长，写出的数据包计算与网络量消耗越大，则速度越慢。反之越快。
与事件分组相关。写出目标越多，事件标签TAG越多，输出的数据包日志组越多，网络交互越多，则速度越慢。反之越快。
加工逻辑
加工逻辑越复杂，搜索计算越多，频繁进行外部资源同步，对计算与网络消耗越大，则速度越慢。反之越快。
第三方数据源
从第三方获取数据源进行富化，数据源的数据量越大，或存在跨域通讯，例如去抓取其他区域OSS的文件，则速度越慢。
源Logstore加工扩展
实时数据加工扩展。
可以通过增加shard（readwrite状态）数量来实现扩展，shard费用请参见按使用功能计费。
历史数据加工扩展。
Shard分裂仅对新写入数据有效。如果历史数据量较大且Shard数量较少，可以对源Logstore构建多个数据加工任务，分别配置无重叠的加工时间即可。例如要处理9/1到9/10的历史日志，则按照天将任务切分成9个，分别处理时间段：
[9/1, 9/2), [9/2, 9/3) .... [9/9, 9/10]。说明加工时间是日志接收时间，具体配置请参见创建数据加工任务。
目标Logstore加工扩展
目标Logstore的Shard数量主要由两方面决定：
数据加工的写入速率。Logstore单个Shard的写入速率上限是5 MB/s，因此可以根据源Logstore的Shard数量，加工的并发数来估算。
例如源Logstore有20个Shard，那么目标Logstore至少有4个Shard。
目标Logstore是否需要建立索引进行查询统计。如果目标Logstore希望建立索引并且进行统计查询，那么建议基于SQL统计每次查询的覆盖范围，每5000万条日志一个Shard的粒度来规划。
例如，每天加工并写入10 GB日志，按照每条1 KB算，每天有1千万条日志规模。每次查询和统计希望可以覆盖30天数据量，其总体日志量大约是3亿条，建议将目标Logstore的Shard数量规划为6个。