函数计算因为数据量过大超时的解决方案-阿里云开发者社区

开发者社区> 开发与运维> 正文

函数计算因为数据量过大超时的解决方案

简介: 我现在做的事情是把一个webtrack 的logstore 通过函数计算导入到另外一个logstore。函数计算的功能是把IP解析成地理位置和把UserAgent String解析成设备信息。 现在的问题是FunctionComputeServer有时会time out失败,但是失败后数据任然是成功插入的。
我现在做的事情是把一个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位置继续开始处理。  

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章