本文档为您介绍进行数据加工时,会影响加工性能的可能的因素。帮助您解决加工性能问题。

根据加工原理,数据加工任务的总体速度取决于源Shard的数量、用户配置的规则逻辑和规则复杂度。一般可以按照每Shard处理1MB/s(压缩前)流量规划,也就是大约85 GB每天每Shard规划。例如:源Logstore的数据写入速度是每天1 TB,那么需要分裂源Logstore的Shard数量为1024GB/85=12个。关于Shard分裂请参见分裂Shard

数据加工性能

数据加工速率与加工规则有关,具体体现如下:
  • 写出输出
    • 与事件大小相关。写出事件越多(事件进行了分裂),写出事件字段越多,内容越长,写出的数据包计算与网络量消耗越大,则速度越慢。反之越快。
    • 与事件分组相关。写出目标越多,事件标签TAG越多,输出的数据包日志组越多,网络交互越多,则速度越慢。反之越快。
  • 加工逻辑

    加工逻辑越复杂,搜索计算越多,频繁进行外部资源同步,对计算与网络消耗越大,则速度越慢。反之越快。

  • 第三方数据源

    从第三方获取数据源进行富化,数据源的数据量越大,或存在跨域通讯,例如去抓取其他区域OSS的文件,则速度越慢。

源Logstore加工扩展

  • 实时数据加工扩展。

    可以通过增加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个。