開發與維運

首次揭祕!​春晚活動下快手實時鏈路保障實踐

摘要:本文由快手開發工程師劉建剛分享,主要介紹春晚活動下快手實時鏈路保障實踐。內容主要包含以下四部分:

  1. 快手 Flink 簡介
  2. 春晚實時保障方案
  3. 春晚實時大屏
  4. 未來規劃

Tips:點擊「閱讀原文」鏈接可查看作者原版 PPT 及分享視頻~

一、快手 Flink 簡介

我們首先來看一下快手的實時計算架構圖。主要分為4個部分,包括數據接入、數據計算、數據應用和數據展示。各層職責分明、銜接順暢,方便用戶開發。

640 1.png

快手的 Flink 集群規模大概有 3000 多臺機器,日處理條目數為20萬億,峰值為38億條。主要應用場景包含以下四類:

  • 實時 SQL 平臺,這是 Flink 託管的一個產品化的 SQL 平臺。
  • 短視頻、直播等指標的實時計算,涵蓋了公司的主要業務和產品。
  • 機器學習的數據預處理,支撐著快手廣告等各種模型的訓練。
  • 快手所有的日誌拆分、同步等實時的數據流。

640 2.png

二、春晚實時保障方案

快手中標了2020年的央視春晚,春晚作為全球華人辭舊迎新的晚會,數據量之大前所未有。快手 Flink 作為公司的實時計算平臺,支持春晚超大狀態和千萬併發等複雜計算。春晚項目的挑戰主要體現在穩定性、實時性、準確性三個方面,我們為此制定了一系列方案為春晚保駕護航。

640 3.png

下面我會通過這4個方面來介紹一下我們為春晚做的努力。

  • 第一個是過載保護,主要介紹極端壓力下的技術應對方案;
  • 第二個是全系統的穩定性,確保各個方面都萬無一失;
  • 第三個是壓力測試,它是春晚的提前模擬;
  • 第四個是資源的保障,涉及到資源的管理和保障。

640 4.png

1.過載保護

Flink 在流量激增或者單點性能不足的情況下,有可能會發生卡死、雪崩或者失敗的情況。這個時候一旦我們的實時作業掛掉,整個作戰計劃就會被打亂,可能給公司帶來很大的損失。

640 5.png

我們針對這種場景設計了一種健康檢查、智能限速、源端控制相結合的柔性可用技術。為什麼要通過源端控制?首先,如果出了問題,我們可以在下游的 task 上進行控制,但是這樣的話可能帶來一個問題,它會造成反壓等阻塞行為,有可能會把整個作業卡死,所以我們通過控制數據源來從本質上解決問題。下面是我們技術實現:

  • TaskManager 作為從節點,將自己的健康信息定期彙報到 Master 節點。
  • Master 節點一旦檢測到極端壓力,立刻要求所有的 source 限速 50%。
  • 如果之後作業狀態良好,就會慢慢的提高我們的輸入 QPS,每次 10%。

640 6.jpg

然後看一下我們的測試效果圖。流量高峰到來時 QPS 為 200K。一旦 Master 節點檢測到極端壓力,直接將 QPS 限速到 100K。之後檢測到作業狀態良好,就逐步地進行恢復。經過測試(隨著逐漸恢復各項指標會有波動),我們的 CPU 使用率從最高的 100% 降到了 80%~90%,ygc 由每分鐘的10秒降到了每分鐘3秒以內,同時也避免了的 oom、心跳超時、卡死等各種問題。這種技術能夠保障我們 Flink 在極度壓力下的存活,起到了削峰保命的效果。

640 7.png

我們還設計了一種輕量級的熱更新模型,在作業不停止的情況下通過 restful 接口實時的控製作業去應對各種壓力,避免了繁瑣的修改代碼、打包、上線等耗時過程。常見功能包括關閉快照、設置採樣率、source 源鮮素,如下圖所示。

640 8.png

2.全系統穩定性

分佈式系統涉及到方方面面,任何一個環節出了問題都可能是致命的,我們為此在故障應對和項目管理上做了很多工作。故障應對包含故障排除、故障演練、故障預案,項目管理包含作業管理、集群管理、工程管理。

640 9.png

首先進行的是 Flink 的故障排除。Flink 的交互組件包括 Yarn,HDFS,Kafka,Zookeeper,我們逐一的對每個組件進行故障排除。它們各自的風險排除步驟,如下圖中的表格所示。

640 10.png

故障排除完了之後,就需要在真實的場景中進行故障演練。主要的演練方法就是在我們的集群中,隨機的注入各種異常來測試並且完善 Flink 的穩定性,確保 Flink 做到以下保障:

  • 相關組件異常不影響 Flink,比如 Yarn 和 HDFS 的主節點掛掉。
  • 作業宕機,Hawk 監測系統5秒內發現並作相關處理。
  • 作業 Failover 在30秒以內。

640 11.png

為了更好地應對各種故障,我們還制定了完善的故障預案,這是一套完整的應急指導方針。針對每一種故障,我們都有快速的問題排查和解決手段。

640 12.png

除了快速應對故障,良好的管理手段也必不可少,它可以有效的減少故障。下面介紹我們管理上的一些手段。

首先是作業管理這一塊,包含作業管理系統的穩定性和相關的運維工作。包括四個方面:

  • 作業管理系統支持高可用。一旦出問題可以快速的切換。
  • Checklist 規範用戶開發,包括快照設置和數據源對齊等實戰經驗。
  • 常見工具,包含全局日誌查詢、高負載查詢、快速遷移等。
  • 報警機制和 metric 的展示,做到問題提前發現和及時發現。

640 13.png

接下來是集群管理。集群作為我們整個系統的物理載體,一旦出現問題就是致命性的:

  • 針對高優作業搭建多套實時集群,避免離線的干擾。
  • 關鍵隊列物理隔離。針對特定集群要求的作業,通過物理隔離來保障其穩定性。
  • 機器環境的排查。確保機器環境符合我們的預期。
  • 重要作業實現多集群的部署,出現問題秒級切換。(實時大屏會詳細介紹)

640 14.png

最後一個就是工程的管理。工程管理的關鍵是時間線預案,主要是指導我們在什麼時間點該做什麼事情,貫穿整個項目開發。下面簡單描述了下春晚的事前、事中、事後的主要操作:

640 15.png

3.壓力測試

壓力測試相當於春晚的一個模擬,它能夠幫助我們發現很多問題。針對春晚,壓力測試比一般的時候要更復雜一些。面臨的最主要的兩個問題,第一個問題就是數據模型怎麼構造,比如說有哪些 topic、各 topic 的數據分佈是怎麼樣的。第二個問題是我們如何根據這些模型生成符合條件的數據。

640 16.png

數據模型的難點在於構建的數據分佈必須跟春晚保持一致。我們的解決方案是以人為參考單位,基於統計規律建立人與數據分佈的映射關係。簡單來說,計算出每個人在各個 Topic 的數據量,預估有多少人各個 Topic 的 QPS 就翻多少倍,當然實際情況會複雜許多。最終,我們根據公測和元旦當天用戶產生的數據來進行春晚模型的建立。

640 17.png

模型構建完成之後,需要根據模型生成數據。為此,我們構建了一整套完善的數據生成服務,用戶只需要進行簡單的配置就可以,而流量控制、多 task 的協作、分佈式生成等複雜的實現全部由平臺實現。主要有三種形式的數據生成:

  • 數據翻倍,基於 bytes 的流量翻倍,性能最佳。
  • 時間壓縮,在不改變數據分佈的情況下壓縮數據、提高 QPS。
  • 樣本生成,根據用戶提供樣本生成符合條件(QPS、UV等)的數據。

640 18.png

4.資源保障

春晚對數據的實時性要求比較高。只有資源保障到了才可以實現我們的實時性。

640 19.png

資源保障的關鍵策略是分級保障。我們把作業分了三個優先級:P0、P1 和 P2:

  • P0 是高優作業,跟春晚相關的一些活動。
  • P1 是重要的作業,是指業務方的一些重要作業。
  • P2 是普通的任務,一般指非核心的作業。

為了做到分級保障,我們制定了重點保障高優先級作業的降級策略:

  • 春晚之前,我們會批量的把 P2 的任務都停止掉,把資源全部都挪給 P0 和 P1。
  • 春晚中,如果有需要,降級 P1 的資源來保障 P0 作業的資源。
  • 春晚後,我們會把之前停掉的 P2 作業再重新提起來,並且從 kafka 最新的 offset 開始消費。

通過分級保障,在資源有限的情況下,優先保障了我們的重點作業,確保了高優任務的實時消費。分級保障對今後的服務治理意義重大。比如說以後的資源調度、灰度上線、作業遷移等等,都可以參考分級保障的策略。

640 20.png

資源保障的另一個體現在於快速擴容,分為實時指標監控和資源選擇兩個方面。實時指標監控包括作業吞吐,作業延時,快照信息,物理信息,通過這4個重要的部分就可以衡量一個作業是否健康。如果我們檢測到作業有性能問題需要擴容,需要按照一定順序選擇資源來補充——集群內冗餘資源,備用集群,低優任務資源。

640 21.png

三、春晚實時大屏

下面我們以實時大屏作為經典案例來介紹。快手春晚實時大屏為作戰指揮官提供最核心的活動和公司大盤實時數據,總共承接了100多個實時指標的計算,包括在線、紅包、互動等各項指標。主要的挑戰表現在三個方面:

  • 數據量大,QPS 在千萬級別;
  • 實時性要求比較高,在秒級以內;
  • 穩定性要求高,可用性為4個9。

接下來我會從技術選型、壓力測試、服務部署三個方面順序展開。

640 22.png

1.技術選型

架構組件是以 Flink 為主,Redis 為輔。Flink 適合大規模的實時計算,Redis 作為一款高效的 KV 查詢工具來輔助實時計算。

各項指標中,基於 deviceld 的 UV 計算最多、複雜度最高。一般來說,先將字符串類型的 deviceId 轉成數字類型的 id,然後存儲在位圖結構 bitmap(存儲空間小)中進行計算。這裡介紹下快手的技術方案:

  • Flink+HBase。HBase 負責將 deviceId 轉成 id,Flink 負責計算。
  • Flink+Redis。通過 Redis 判斷 deviceId 是否首次出現,如果是就下發計算。
  • Flink 自身。Flink 自建字典為快手內部實現的精準一次方案。

前面兩種方案將字典和計算解耦,適合多個作業共享一個字典。最後一種方式不再依賴外部系統,性能最佳。實時大屏根據自己需求和熟練度選擇了第二種方案。

640 23.png

2.壓力測試

壓力測試分為單作業的壓測和全鏈路的壓測。

  • 單作業壓測這一塊,我們通過增量計算、批量訪問、本地緩存、objectReuse 等優化技術,使單個作業的 QPS 達到百萬級別。
  • 全鏈路壓測這一塊,用來評估整體性能,需要協調所有數據和作業,具體操作如下所示。

640 24.png

3.服務部署

最後一步是多鏈路的服務部署。實時大屏作業的穩定性要求特別高,必須多鏈路熱備:

  • 雙機房熱備。一旦機房掛掉,立刻切到另一個機房。
  • 多鏈路熱備。針對全量鏈路和採樣鏈路,集群內物理隔離、多鏈路運行。
  • 指標故障用戶無感知。最上面視圖層屏蔽底層鏈路,底層出問題可以秒級切換。

640 25.png

四、未來規劃

上面是春晚實時大屏案例的介紹,下面也跟大家分享一下我們將來的一些規劃:

  • 推廣 SQL,探索批流統一、Table&Stream 的廣泛用途。
  • 自研 SlimBase statebackend,實現存儲計算分離。
  • 提升 Flink 故障自愈能力。
  • 建立作業診斷模型,實現問題快速定位。
  • 探索數據庫、K8s 等相關係統的組合應用。

文章不夠看?點擊「閱讀原文」可直接回顧作者現場分享的講解視頻~

Leave a Reply

Your email address will not be published. Required fields are marked *