《李天朔-快手實時數倉保障體系研發實踐.pdf》由會員分享,可在線閱讀,更多相關《李天朔-快手實時數倉保障體系研發實踐.pdf(30頁珍藏版)》請在三個皮匠報告上搜索。
1、李天朔/快手實時數據技術專家快手實時數倉保障體系研發實踐快手實時數倉保障體系研發實踐業務特點業務特點實時數倉保障痛點實時數倉保障痛點實時數倉保障實時數倉保障體系架構體系架構春節活動實時春節活動實時保障實踐保障實踐未來規劃未來規劃#1#2#3#4#1#1業務特點及實時數倉保障痛點業務特點及實時數倉保障痛點快手實時應用場景業務特點?保障訴求保障訴求保障訴求保障訴求嚴格資源管控極致壓榨性能鏈路分級機制短周期開發高穩定性保障高準確性問題及時發現防止重復造煙囪數據量大訴求多樣化活動場景頻繁核心場景快速支撐快手數倉保障方案及衍生問題?研發階段問題 flink sql語法和理解更加困難 活動實時計算資源能否
2、扛住洪峰 dwd數據源多次重復消費 作業state隨執行增大,任務頻繁失敗 任務部署無編排,鏈路依賴混亂生產階段問題服務階段問題 監控報警上線后總是有遺漏 作業失敗重啟,指標結果不符合預期作業產生13min延遲介入運維高時效性15432有狀態服務,線上問題難復現問題復雜性日均處理萬億級別數據流量大對于需求側解決方案能力有差別開發能力良莠不齊問題發生時間是隨機的問題隨機性實時數倉保障有哪些難點?#2 2快手實時數倉保障體系架構快手實時數倉保障體系架構快手實時數倉保障思路以開發生命周期為基礎的正向保障思路以故障注入與場景模擬為基礎的反向保障思路正向保障-階段劃分開發階段測試階段上線階段服務階段下線
3、階段u邏輯自測u資源預估u時間線預案u分級部署u定期巡檢u需求調研u開發標準化u方案評審u任務監控u 時效性u 穩定性u 準確性u資源回收u部署還原開發階段-開發標準化打法設計標準化開發規范標準方案標準化開發組件化開發階段-開發標準化開發標準化-場景SQL化 回溯問題 數據真實時間落窗口 Watermark推進 窗口結束后觸發 亂序問題 亂序數據不丟棄 記錄到最新累計數據 準確性 降低了數據丟棄的差異 上游數據源保序要求降低解決方案(漸進式窗口)按照watermark+event_time切分解決問題業務場景難點回溯曲線異常時效與準確平衡晚到數據丟棄容易數據傾斜開發標準化-場景SQL化 回溯問
4、題 數據真實時間落窗口 Watermark推進 窗口結束后觸發 亂序問題 亂序數據不丟棄 記錄到最新累計數據 準確性 降低了數據丟棄的差異 上游數據源保序要求降低解決方案(漸進式窗口)按照watermark+event_time切分解決問題業務場景難點回溯曲線異常時效與準確平衡晚到數據丟棄容易數據傾斜上線階段-時間線預案活動前任務重新部署check作業參數是否合理觀察作業運行正常確認部署后集群水位時間線預案 活動保障流程的“劇本”規范:時間、操作人、預案內容、操作記錄、操作檢查點活動前準備檢查指標輸出正常任務狀態巡檢故障應對與鏈路切換活動中應對下線活動任務回收活動資源恢復鏈路部署活動復盤活動后
5、上線階段-分級部署任務級別任務級別適用場景適用場景要求要求flinkflinkkafkakafkaolapolap引擎引擎P0S級活動大屏C端應用13秒級延遲0.5%誤差熱備雙鏈路部署多機房容災多機房容災P1公司核心數據核心B端應用13分鐘延遲0.5%誤差在線機房部署多機房容災多機房容災P2業務核心數據5分鐘延遲1%以內誤差離線機房高優先級任務離線機房部署單機房P3業務一般數據10分鐘延遲1%誤差離線機房部署低優先級任務離線機房部署單機房服務階段-監控報警底層集群監控Flink任務監控SLA目標監控SLA目標監控整體任務目標性能:質量、時效性、穩定性鏈路任務監控任務狀態、數據源、處理過程、輸出
6、結果任務IO、CPU、網絡信息服務監控服務可用性、服務延遲、服務容量底層資源監控集群的IO、CPU、網絡信息依賴服務監控服務階段-監控報警目標準確性主備鏈路準確性對比維度下鉆離線實時準確波動性實時同環比監控實時時序算法監控一致性通用維度枚舉值一致指標度量一致完整性標準維度枚舉值完整產出結果完整衡量指標接口產出延遲報警olap引擎延遲報警接口表kafka延遲報警任務狀態任務探活延遲監控cp失敗監控衡量指標olap引擎p99延遲報警flink作業恢復SLA報警任務讀取延遲亂序監控數據丟棄監控任務處理算子時延監控算子輸入輸出監控任務輸出限流監控數據突變監控服務狀態服務可用性報警服務延遲報警集群資源集
7、群內存、cpu、網絡集群吞吐任務負載任務資源監控網絡情況監控時效報警穩定報警衡量指標離線實時一致性olap引擎與應用接口一致指標邏輯錯誤報警準確報警準確監控時效監控穩定監控Rockdb性能指標算子間數據對齊監控快手實時數倉保障思路以開發生命周期為基礎的正向保障思路以故障注入與場景模擬為基礎的反向保障思路反向保障02030104壓測演練u單作業壓測u全鏈路壓測容災建設u多機房u限流u重試u降級u故障演練u故障恢復演練復盤u故障恢復預期u問題及改進項壓測演練-單作業壓測Topic1Source1MapSink線上作業生產者線上任務Source1MapSinkTopic2Topic2分區讀取kafk
8、a idc壓測達成標準輸入延遲CPU內存利用率計算結果 數據源在目標QPS情況下延遲為毫秒級 Flink作業CPU利用率占使用資源50%左右,不超過60%單個TM的cp大小不超過200MB 計算最終的結果與既定目標預期一致讀取最近100條數據Topic1寫入壓測生成作業單作業壓測n 目標:n 確保作業在活動預估流量峰值下保障SLA。n 作業性能瓶頸,指導優化。n 場景benchmark,方便低優作業資源部署。壓測作業壓測演練-全鏈路壓測壓測達成標準輸入延遲集群目標集群資源 數據源在目標QPS情況下延遲為毫秒級 集群整體作業CPU在50%左右 內存和磁盤Io符合預期 計算最終的結果與既定目標預期
9、一致全鏈路壓測n 確保作業在活動預估流量峰值下保障SLA。n 作業的資源使用固化,方便后續集群部署和資源編排。n 拿到當前資源下極限流量支撐,后續容災工作提供數據基礎。job1實時計算鏈路job2job3Job1Job2Job3Topic1Topic2線上源topicTopic1Topic2壓測源topicTopic3Topic4線上目標topictopic3Topic4壓測目標topic服務鏈路壓測鏈路壓測鏈路線上鏈路實時數倉保障-容災建設&故障演練故障注入uKafka topic故障uFlink作業失敗重啟uFlink作業cp失敗作業故障鏈路故障演練u單機房發生故障,如何保障正常產出?u活
10、動流量超出預期很多,如何不發生雪崩效應?u某個作業lag了1個小時,需要多久能恢復?手段作業故障演練多機房限流降級重試雙鏈路實時數倉保障-容災建設&故障演練kafka/olap雙集群高可用flink雙鏈路容災 單機房故障:自動切流 故障恢復:自動探測、加入 故障不會對flink任務產生影響 重啟可恢復作業失敗重試 重啟不可恢復單機房故障:切換作業讀取鏈路單作業故障:單表作業切換 單作業壓測確定flink任務節點峰值 全鏈路壓測確定整個集群水位 預留一定資源buffer鏈路容災保障鏈路容量保障 集群內作業限流,保障任務不掛掉 單作業超出預期,單作業限流 擴容,觀察作業情況#3 3春節活動實時保障
11、實踐春節活動實時保障實踐春節活動-實時核心挑戰海量數據挑戰要求鏈路保持穩定或者出現故障快速恢復高穩定高穩定億級別流量大屏指標秒級延遲曲線1min延遲高時效高時效實時離線邏輯一致核心鏈路差異0.5%以內高準確高準確高靈活高靈活除了大屏看板多維分析場景支撐春節活動-實時核心保障架構春節活動-實踐效果時效性1、面對上億/秒的流量洪峰,大屏核心鏈路指標卡類秒級延遲,曲線類指標1min延遲。準確性穩定性2、單個任務處理數據量在萬億級別基礎層核心鏈路活動流量高峰期毫秒級延遲。1、核心鏈路離線和實時任務整體數據差異在0.5%以內,大促活動過程無數據質量問題。2、有效使用flink sql 漸進式窗口開發,大幅度降低窗口丟數導致的精度損失,數據差異從1%降低到0.5%1、核心鏈路依賴組件雙機房容災,flink集群雙鏈路部署,出現問題切換秒級響應。2、壓測和容災能力沉淀,為以后活動保障體系建設奠定基礎。#4 4未來規劃未來規劃保障能力建設 壓測故障注入一體化 作業問題智能診斷#2#1批流一體 活動場景能力探索 活動等應用場景落地#3實時數倉建設 實時數倉豐富性提升 通過沉淀組件、SQL化手段開發效率提升。20212021-1212-0505THANKS