我现在做的事情是把一个webtrack 的logstore 通过函数计算导入到另外一个logstore。函数计算的功能是把IP解析成地理位置和把UserAgent String解析成设备信息。
现在的问题是FunctionComputeServer有时会time out失败,但是失败后数据任然是成功插入的。不过ETL认为任务失败,不断重试,最后导致插入大量重复的数据。
现在有一个解决方案就是减少函数的输入数据,这样就可以避免超时,不过我有一些问题。
第一个问题:唯一能影响函数的输入数据量的设置只有函数的执行频率吗?我可以准确的指定输入量吗?
阿里答复:完备的触发器角度应该是要同时支持:size-based trigger、time-based trigger两种模式,但因为日志服务没有办法从流式数据订阅接口获取准确的日志条数,所以size-based trigger目前提供不了。抱歉。
第二个问题:因为这是个webtrack logstore,每个时间点的logstore产生量是不稳定的。我如何评估产生的shard数目和大小?有没有什么地方可以查看?有没有什么办法可以提前测试函数计算的 performance这样可以帮助我觉得合适的内存和超时设置?如果靠生产环境里面的情况来做决定,我只能等出了问题在尝试修改,那个时候已经太晚了。
阿里答复: 一个shard支持5MB/s的数据写入,logstore的流量指标可以在这里看到:https://help.aliyun.com/document_detail/28971.html?spm=a2c4g.11174283.6.693.6IikRd。云监控中的指标应该可以通过sdk方式获取的,你可以基于这个值提前做shard分裂来扩容。
建议解决方案:
1. 将shard数目按照峰值情况进行预留
2. 将日志服务触发器的触发间隔设置为3秒,函数计算的超时间隔设置得高一些(比如2分钟)。我的考虑是:一般来说,函数偶尔超时,后续是可以慢慢赶上进度的(削峰填谷),我们容忍偶尔的超时(计算+IO作业,延时不太可控)。但如果一直超时,说明shard流量过高(分裂shard解决)或者是计算复杂度高(在函数端增加并发)。
3. 日志服务写数据本身是非幂等行为,例如在函数重复执行或者写入数据超时重试时可能引起数据重复。这个问题根本上难以解决,降低重复概率的一个可选方案是:在函数计算里面将本次已处理的数据saved_cursor记录到外部系统(例如表格存储),如果函数超时后再次执行,从表格存储获取上次处理进度,跳过已处理的部分数据,从saved_cursor位置继续开始处理。