本文檔為您介紹進行資料加工時，會影響加工效能的可能的因素。協助您解決加工效能問題。
根據加工原理，資料加工任務的總體速度取決於源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個。