我现在做的事情是把一个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位置继续开始处理。
