本文檔為您介紹進行數據加工時，會影響加工性能的可能的因素。幫助您解決加工性能問題。
根據加工原理，數據加工任務的總體速度取決于源Shard的數量、用戶配置的規則邏輯和規則復雜度。一般可以按照每Shard處理1MB/s（壓縮前）流量規劃，也就是大約85 GB每天每Shard規劃。例如：源Logstore的數據寫入速度是每天1 TB，那么需要分裂源Logstore的Shard數量為1024GB/85=12個。關于Shard分裂請參見分裂Shard。
數據加工性能
數據加工速率與加工規則有關，具體體現如下：
寫出輸出
與事件大小相關。寫出事件越多（事件進行了分裂），寫出事件字段越多，內容越長，寫出的數據包計算與網絡量消耗越大，則速度越慢。反之越快。
與事件分組相關。寫出目標越多，事件標簽TAG越多，輸出的數據包日志組越多，網絡交互越多，則速度越慢。反之越快。
加工邏輯
加工邏輯越復雜，搜索計算越多，頻繁進行外部資源同步，對計算與網絡消耗越大，則速度越慢。反之越快。
第三方數據源
從第三方獲取數據源進行富化，數據源的數據量越大，或存在跨域通訊，例如去抓取其他區域OSS的文件，則速度越慢。
源Logstore加工擴展
目標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個。