摘要：本文由快手實時計算負責人董亭亭分享，主要介紹快手基於 flink 的持續優化與實踐的介紹。內容包括：
flink 穩定性持續優化
flink 任務啟動優化
flink sql 實踐與優化
未來的工作
一、flink 穩定性持續優化
第一部分是 flink 穩定性的持續優化。該部分包括兩個方面，第乙個方面，主要介紹快手在 flink kafka connector 方面做的一些高可用，是基於內部的雙機房讀或雙機房寫和一些容錯的策略。第二部分關於 flink 任務的故障恢復。我們在加速故障恢復方面做了一些優化工作。
首先，介紹 source 方面的高可用。在公司內部比較重要的資料寫 kafka 時，kafka 層面為保障高可用一般都會建立雙集群的 topic。雙集群的 topic 共同承擔全部流量，如果單集**生故障，上游自動分流。kafka 層面通過這種方式做到雙集群的高可用。但是 flink 任務在消費雙集群 topic 時，本身是不能做到高可用的。flink 任務通過兩個 source union 方式消費，source 分別感知上游 topic 故障，單集群故障需手動將故障 source 摘除。這種方式的缺點是故障時需要人工的干預，必須手動去修改**的邏輯，程式內部本身是不能做到高可用的。這是做雙機房讀的背景。
為了解決上述問題，我們封裝了乙個 kafka 的 cluster source，它在 api 上支援讀取雙集群的 topic。同時做到，可以容忍單集群故障，集群故障恢復時也可以自動將故障集群重新加入。
接下來是關於 sink 方面的高可用。flink 寫雙集群 kafka topic，會定義不同集群 sink，邏輯內控制拆流。這種方式靈活性差，且不能容忍單機房故障。如果單集**生故障，仍需要手動摘除對應的 sink。
同樣，針對 sink 我們也定製了乙個 cluster sink，它 api 上支援寫雙集群 topic。具體寫的策略，可以支援輪詢和主從寫的方式。如果單集**生故障，邏輯內會自動將流量切到正常集群 topic。如果單集群故障恢復之後，也能感知到集群的恢復，可以自動的再把相應集群恢復回來。
另外，基於 kafka 的 connector，我們也做了一些容錯的策略，這裡提到三點。
第二部分是 flink 任務的故障恢復優化，分為兩個過程。乙個是故障發現，另外乙個是故障恢復。實際的生產環境中，一些不穩定的因素會導致故障恢復的時間特別的長，使用者的感知會比較差。同時，內部也有一些比較高優的任務，它對穩定性的要求比較高。我們希望做一些事情，把整個故障恢復的時間盡可能縮短。我們定了乙個優化目標，20 秒內做到乙個自動的恢復。
在故障發現階段的優化包括三點：
在故障恢復階段的優化包括：
二、flink 任務啟動優化
以上是針對乙個新任務啟動場景，下面介紹任務公升級的場景。以前是同步公升級，比如說，任務 a 在執行著，然後我要把任務 a 停掉，再去啟動新的任務 b。如下圖所示，不可用時間包括停任務 a 和啟動新任務 b。是否可以不用等任務 a 完全停掉之後，再啟動任務 b。針對這個想法我們做了乙個非同步公升級的策略。新任務提前啟動，初始化到 jobmaster 階段。舊任務停掉後，完成新任務後續啟動工作，這樣新舊任務無縫切換。通過內部提交平台將該步驟串聯起來，目標是非同步公升級在 20s 以內完成。
三、flink sql 實踐與優化
第三部分會介紹一下我們在使用 flink sql 的一些實踐和優化。首先介紹一下 flink sql 在快手的現狀。目前，我們內部 flink sql 的任務佔比在 30% 左右。flink sql 的任務個數是 360 多個。然後它的峰值處理的條目數還是比較高的，大約是 4億每秒。在我們內部的一些重要活動的實時大屏的場景下，目前 flink sql 也作為一條鏈路，參與了相關指標的計算。
接下來介紹一下我們在使用 flink sql 的時候遇到的一些問題，以及我們做的一些優化。首先，關於 flink sql 的傾斜問題，在 unbounded agg 場景下的傾斜問題，已經有比較全面的思路去解決，總結為三點。
所以我們解決的第乙個問題就是 bounded agg 的傾斜問題。如下圖所示，拿左邊的 sql 作為例子，group by乙個user，假定一天的視窗，然後去 select 每乙個使用者總的交易額。右邊的圖，假定有一些使用者的交易特別多，就會造成某一些 window agg 的資料量特別大。
解決思路分為兩點。
我們解決的第二個問題是 flink sql 下的 udf 函式復用的問題。如下圖所示，以左邊的 sql 為例，可以看到有兩個 udf 的函式，這兩個函式在 sql 裡面都重複出現了多次。
四、未來工作
第四部分介紹我們未來的一些規劃，分為三塊。
另外，快手資料平台部招賢納士！資料平台部主要為快手業務的飛速發展提供資料新能源，每日面向萬億級使用者資料，打造行業領先的eb級資料處理與應用平台，驅動業務創新，保持快手在使用者理解，內容分發，生態安全等領域的領先地位。各職位正在熱招中，歡迎加入：
▼ 關注「flink 中文社群」，獲取更多技術乾貨 ▼
快手基於 Flink 的持續優化與實踐
簡介 快手基於 flink 的持續優化與實踐的介紹。flink 穩定性持續優化 flink 任務啟動優化 flink sql 實踐與優化 未來的工作 第一部分是 flink 穩定性的持續優化。該部分包括兩個方面，第乙個方面，主要介紹快手在 flink kafka connector 方面做的一些高可...
快手基於 Flink 的持續優化與實踐
摘要 本文由快手實時計算負責人董亭亭分享，主要介紹快手基於 flink 的持續優化與實踐的介紹。內容包括 flink 穩定性持續優化 flink 任務啟動優化 flink sql 實踐與優化 未來的工作 一 flink 穩定性持續優化 第一部分是 flink 穩定性的持續優化。該部分包括兩個方面，第...
快手基於 Flink 的持續優化與實踐
簡介 快手基於 flink 的持續優化與實踐的介紹。flink 穩定性持續優化 flink 任務啟動優化 flink sql 實踐與優化 未來的工作 第一部分是 flink 穩定性的持續優化。該部分包括兩個方面，第乙個方面，主要介紹快手在 flink kafka connector 方面做的一些高可...