函式計算因為資料量過大超時的解決方案

264971589117404837發表於2018-03-06
函式
我現在做的事情是把一個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位置繼續開始處理。  


相關文章