資訊專欄INFORMATION COLUMN
距離上次解決flink計算業務鏈相關指標延遲問題已經過去2個多月，當時根據解決問題的過程編寫了<<開源組件Flink性能優化之實時計算延遲填坑記>> 。
自從上次解決flink內存泄漏的問題后，2個多月時間內，在flink組件上的所有任務一直平穩運行，但最近監控日志采集入庫延遲的告警短信頻頻響起，表明問題來了。
最初以為是更新flink運行包的原因，于是比對版本和代碼，發現flink日志采集任務部分的程序沒有做任何的更改，flink環境也沒有變化，對于程序來說，如果輸出發生變化，程序和環境沒有變化，那唯一的解釋就是輸入發生了變化，日志采集數據量上升導致了日志延時。那就統計每天的日志采集數據量，但采集客戶端及服務端沒有這個處理的數據量，kafka也沒法統計每天的寫入量，而flink也是只能看到處理的總數據量。
統計不到沒關系，我們把數據量降下來不就可以看到，停一部分采集再看日志入庫還會不會延時，問題不就確定了嗎？但是經過和應用開發商溝通，每個日志都不能下線或停止采集。
怎么辦，優化唄，問題是優化哪里？首先需要先找到數據的增長對哪個環節影響最大，這時候我們就應用到奧卡姆剃刀原則，奧卡姆剃刀原則又名簡約之法則，這是一個解決問題的法則，剔除多余的不必要的環節，直到簡單到不能再簡單，此時暴露出來的地方就是問題關鍵。
flink日志采集任務經過采集客戶端，采集服務端，kafka，flink,es。經過消費中間過程的kafka，發現kafka中的日志是最新的，沒有延時，排除前面采集過程導致的延時，所以問題出在flink消費kafka數據寫入es這個環節，在這個過程中有三個步驟，flink解碼，flink分詞，flink入庫，下面我們將一個個去掉，測試哪個環節影響日志任務延時。
第一步，由于客戶在使用的過程中，并沒有用到flink的分詞去查詢，去掉flink分詞過程后經過觀察依然出現延時，說明可能是解碼和入庫過程發生了延時。
第二步，再去掉解碼，僅保留flink入庫過程，此時依然出現延時，可以確定flink入庫是延時的一個環節。既然確定flink入庫是延時的一個原因，首先我們優化flink入庫，提高寫入es的數據量，由于es的參數設置早已經經過優化設置，沒有太多回旋的余地，只能選擇關閉es副本，提高es寫入數據量。
第三步，關閉副本后，加上上面兩步關閉的解碼和分詞，在去掉解碼，分詞和關閉副本后，程序正常沒有延時，此時可以作為正常的基點。
第四步，再次開啟副本后，在解碼，分詞是關閉狀態下出現了延時，驗證了之前的開啟副本產生延時。
第五步，關閉副本，關閉分詞，僅開啟解碼，此時沒有出現延時，說明解碼對延時不產生影響。
第六步,關閉副本狀態下，開啟解碼和分詞，此時立刻出現延時，說明分詞過程也是日志采集入庫延時的一個原因。
綜上步驟測試，驗證了在數據量上升的過程中，分詞過程和開啟es副本對日志采集入庫延時的影響最大。解碼幾乎不受數據量增長的影響。
既然找到了問題是flink分詞過程和es副本，所以需要優化的地方就是這兩個：
優化es副本：
將副本開啟時間改為凌晨，凌晨將昨天寫入的數據在凌晨的空閑時間再生成副本，避免寫入的時候產生es副本；
優化flink分詞過程：
由于已經定位是flink的分詞影響，所以針對分詞處理過程和分詞處理結果入庫環節效率進一步優化。
在解決問題的過程中，發現有些地方做的不足，比如未統計每天及每小時采集數據量做基線，在出現問題時，無統計數據歷史基線對比，無法說服用戶是日志數據增長導致的延時。目前我們已經部署了腳本監控每天和每小時寫入es的數據量，確保下次出現問題時有據可查。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130119.html
摘要：在開發設計中有一些常用原則或者潛規則，根據筆者的經驗，這里稍微總結一下最最常用的，以饗讀者。是處理復雜性的一個原則。參考六大設計原則里氏替換原則奧卡姆剃刀如有問題可以通過郵件微信聯系我。 在開發設計中有一些常用原則或者潛規則，根據筆者的經驗，這里稍微總結一下最最常用的，以饗讀者。 DRY 這里的DRY是Do Not Repeat Yourself的縮寫。具體解釋參見 ,嚴謹的定義是 E...
摘要：彼得原理每個組織都是由各種不同的職位等級或階層的排列所組成，每個人都隸屬于其中的某個等級。對一個組織而言，一旦相當部分人員被推到其不稱職的級別，就會造成組織的人浮于事，效率低下，導致平庸者出人頭地，發展停滯。 1、蘑菇管理 蘑菇管理是許多組織對待初出茅廬者的一種管理方法，初學者被置于陰暗的角落(不受重視的部門，或打雜跑腿的工作)，澆上一頭大糞(無端的批評、指責、代人受過)，任其...
摘要：在移動端，愛奇藝月度總有效時長億小時，穩居中國榜第三名。愛奇藝的峰值事件數達到萬秒，在正確性容錯性能延遲吞吐量擴展性等方面均遇到不小的挑戰。從到愛奇藝主要使用的是和來進行流式計算。作者：陳越晨 整理：劉河 本文將為大家介紹Apache Flink在愛奇藝的生產與實踐過程。你可以借此了解到愛奇藝引入Apache Flink的背景與挑戰，以及平臺構建化流程。主要內容如下： 愛奇藝在實時計算方...
閱讀 1351·2023-01-11 13:20
閱讀 1696·2023-01-11 13:20
閱讀 1209·2023-01-11 13:20
閱讀 1901·2023-01-11 13:20
閱讀 4160·2023-01-11 13:20
閱讀 2739·2023-01-11 13:20
閱讀 1393·2023-01-11 13:20
閱讀 3662·2023-01-11 13:20
