快手實時數倉保障體系研發(fā)實踐
摘要：本文整理自快手實時計算數據團隊技術專家李天朔在 Flink Forward Asia 2021 實時數倉專場的演講。主要內容包括：
- 業(yè)務特點及實時數倉保障痛點
- 快手實時數倉保障體系架構
- 春節(jié)活動實時保障實踐
- 未來規(guī)劃?
01業(yè)務特點及實時數倉保障痛點
快手最大的業(yè)務特點就是數據量大。每天入口流量為萬億級別。對于這么大的流量入口，需要做合理的模型設計，防止重復讀取的過度消耗。另外還要在數據源讀取和標準化過程中，極致壓榨性能保障入口流量的穩(wěn)定執(zhí)行。
第二個特點是訴求多樣化。快手業(yè)務的需求包括活動大屏的場景、2B 和 2C 的業(yè)務應用、內部核心看板以及搜索實時的支撐，不同的場景對于保障的要求都不一樣。如果不做鏈路分級，會存在高低優(yōu)先級混亂應用的現象，對于鏈路的穩(wěn)定性會產生很大的影響。此外，由于快手業(yè)務場景的核心是做內容和創(chuàng)作者的 IP，這就要求我們構建通用維度和通用模型，防止重復煙囪建設，并且通過通用模型快速支撐應用場景。
第三個特點是活動場景頻繁，且活動本身有很高的訴求。核心訴求主要為三個方面：能夠體現對公司大盤指標的牽引能力、能夠對實時參與度進行分析以及活動開始之后進行玩法策略的調整，比如通過對紅包成本的實時監(jiān)控快速感知活動效果。活動一般都會有上百個指標，但只有 2-3 周的開發(fā)時間，這對于穩(wěn)定性的要求就很高。
最后一個特點是快手的核心場景。一個是提供給高管的核心實時指標，另外一個是提供給 C 端的實時數據應用，比如快手小店、創(chuàng)作者中心等。這對數據精度的要求極其高，出現問題需要第一時間感知并介入處理。
以上要素構成了快手實時數倉建設和保障場景的必要性。
在實時數倉保障的起始階段，我們借鑒了離線側的保障流程和規(guī)范，按照生命周期劃分了三個階段：研發(fā)階段、生產階段和服務階段。
- 研發(fā)階段構建了模型設計規(guī)范、模型開發(fā)規(guī)范以及發(fā)布的 checklist。
- 生產階段主要構建底層監(jiān)控能力，對于時效性、穩(wěn)定性、準確性幾個方面進行監(jiān)控，并且依照監(jiān)控能力進行 SLA 優(yōu)化和治理提升。
- 服務階段明確了上游對接的服務標準和保障級別，以及對于整個服務的價值評估。
但是相比于離線，實時的學習成本頗高，完成以上建設后，各個結算依然存在幾個問題：
- 研發(fā)階段：Flink SQL 的學習曲線相比于 Hive SQL 更高，容易在開發(fā)階段引入隱患。另外，實時計算場景下，活動出現洪峰時能否快速消費，也是一個未知數。最后，DWD 層的重復消費對于實時側的資源挑戰(zhàn)也很大，在選擇數據源和依賴關系時需要考慮資源問題。
- 生產階段：state 沒有清理機制會導致狀態(tài)變大、作業(yè)頻繁失敗。另外高優(yōu)先級和低優(yōu)先級部署需要機房隔離，因此需要在上線前就安排好，上線后再進行調整，成本會比離線高很多。
- 服務階段：對于一個實時任務，最無法接受的就是作業(yè)流程失敗、重啟，導致數據重復或者曲線掉坑的問題。為了避免這類問題，需要有標準化的方案，而離線大概率可以保證重啟后數據一致性。
抽象來看，實時數倉相比于離線，還存在幾個保障難點，具體體現在以下幾個方面：
- 高時效性。相比于離線的執(zhí)行時間，實時情況下，延遲分鐘級就要介入運維，對時效性要求很高。
- 復雜性。主要體現在兩個方面：一方面數據不是導入即可查，數據邏輯驗證的難度更高；另外一方面，實時大多是有狀態(tài)，服務發(fā)生問題的時候狀態(tài)不一定能夠被完整保存，會存在很多無法復現的 bug。
- 數據流量大。整體的 QPS 比較高，入口流量級別在億級。
- 問題隨機性。實時數倉發(fā)生問題的時間點更加隨機，沒有規(guī)律可循。
- 開發(fā)能力良莠不齊。如何保證通用場景的開發(fā)方案統(tǒng)一，防止因開發(fā)方案不同而產生不可控的問題。?
02快手實時數倉保障體系架構
基于以上保障的難度，我們設計了兩條思路來解決，主要分為兩個方面：
- 一方面是以開發(fā)生命周期為基礎的正向保障思路，確保每一個生命周期都有規(guī)范和方案指導，標準化 80% 的常規(guī)需求。
- 另一方面是以故障注入和場景模擬為基礎的反向保障思路，通過場景模擬和故障注入，確保保障措施真正落地并符合預期。
2.1 正向保障
正向保障的整體思路如下：
- 開發(fā)階段主要做需求調研，針對開發(fā)過程中基礎層如何開發(fā)、應用層如何開發(fā)進行標準化處理，可以解決 80% 的通用需求，剩余 20% 的個性化需求通過方案評審的方式來滿足，同時不斷從個性化需求中沉淀標準化方案。
- 測試階段主要做質量驗證和離線側對比以及壓測資源預估。自測階段主要通過離線實時的一致性對比、server 看板和實時結果對比來保障整體準確性。
- 上線階段主要針對重要任務上線需要準備的預案，確認上線前動作、上線中部署方式和上線后的巡檢機制。
- 服務階段主要是針對于目標做監(jiān)控和報警機制，確保服務是在 SLA 標準之內的。
- 最后是下線階段，主要做資源的回收和部署還原工作。
快手的實時數倉分為三個層次：
- 第一，DWD 層。DWD 層邏輯側比較穩(wěn)定且很少有個性化，邏輯修改分為三種不同的格式數據：客戶端、服務端和 Binlog 數據。
- 第一項操作是拆分場景，由于實時數倉沒有分區(qū)表的邏輯，所以場景拆分的目的是生成子 topic，防止重復消費大 topic 的數據。
- 第二個操作就是字段標準化，其中包括緯度字段的標準化處理、臟數據的過濾、IP 和經緯度一一映射關系的操作。
- 第三是處理邏輯的維度關聯(lián)，通用維度的關聯(lián)盡量在 DWD 層完成，防止下游過多流量依賴導致維表壓力過大，通常維表是通過 KV 存儲 + 二級緩存的方式來提供服務。
- 第二，DWS 層。這里有兩種不同的處理模式：一是以維度和分鐘級窗口聚合為基礎的 DWS 層，為下游可復用場景提供聚合層的支撐；二是單實體粒度的 DWS 層數據，比如原始日志里核心用戶和設備粒度的聚合數據，可以極大地減少 DWD 層大數據量的關聯(lián)壓力，并能夠更有效地進行復用。DWS 層數據也需要進行維度擴充，由于 DWD 層數據量過大，無法完全 cover 維度關聯(lián)的場景，因此維度關聯(lián) QPS 過高并有一定延時的需求，需要在 DWS 層完成。
- 第三，ADS 層。它的核心是依賴 DWD 層和 DWS 層的數據進行多維聚合并最終輸出結果。
基于以上設計思路，不難發(fā)現針對 DWD 和 DWS 的拆流的邏輯、字段清洗標準化和維度關聯(lián)，都是針對不同格式但邏輯相同。可以把基礎的邏輯開發(fā)成模板化 SDK，后續(xù)相同邏輯都使用相同的 SDK API 方法。這樣有兩個好處，重復的邏輯不需要再復制一遍代碼，一些優(yōu)化的經驗和教訓也沉淀在了模板里。
針對 ADS 層數據，我們通過業(yè)務需求沉淀出諸多解決方案，比如多維度的 PV/UV 如何計算、榜單如何計算、指標卡的 SQL 如何表達以及分布類存在回撤的場景如何產出。
SQL 本身上手快、效率高，能大規(guī)模簡化開發(fā)時間，但它的執(zhí)行效率相比于 API 有一定的劣勢，所以針對于基礎儲層和 DWS 層大流量場景，我們還是使用 API 進行開發(fā)，應用層通過 SQL 進行開發(fā)。
快手的大部分活動中，業(yè)務最關注的指標是某些維度下參與人數、領取金錢的累計曲線，并且希望能夠產出一個每分鐘計算 0 點到當前時刻的曲線，這類指標開發(fā)覆蓋了 60% 左右的活動側需求。那么開發(fā)過程中有哪些難點呢？
用常規(guī)的滾動窗口 + 自定義狀態(tài)的計算對數據進行去重有一個弊端：如果窗口亂序較大，會造成數據丟失嚴重，影響數據的準確性。如果希望數據更準，就要承受更大的數據延遲，而想要延遲低一些就可能存在數據不準確的情況。此外，異常情況下會存在數據從某一個時間點開始回溯的場景，回溯場景下增大吞吐量會因為取最大時間戳導致中間結果丟失。
為了解決這個問題，快手自研了漸進式窗口的解決方案，它存在兩個參數，天級別的窗口和輸出的分鐘步長。整體的計算分為兩個部分，首先產出一個天級別的窗口，讀取數據源按照 key 進行分筒，把 key 相同的數據分到同一個筒內，然后按照事件時間進行 watermark 推進，超過對應的窗口步長就會觸發(fā)窗口計算。
如上圖所示， key=1 的數據分到同一個 task，task watermark 更新到超過步長產生的小窗口之后會合并產出 bitmap 和 pv 的計算結果，并發(fā)送給下游數據，按照 servertime 落到對應的窗口，并且通過 watermark 機制進行觸發(fā)。在 global window 進行合筒操作時，會把分筒的結果進行累加和去重，最終輸出結果。這樣如果存在亂序和晚到的數據就不會丟棄數據，而是會記錄延遲之后的時間節(jié)點，更好地保證了數據的準確性，整體的數據差異從 1% 下降到 0.5%。
另外一方面，watermark 超過步長 window 窗口就觸發(fā)計算，曲線延遲可以控制在一分鐘以內完成，更好地保證了時效性。最后通過 watermark 控制步長的窗口輸出可以保障步長窗口每個點都進行輸出，輸出曲線最大程度保障了平滑性。
上圖是一個具體的 SQL 案例，內部是一個按照 deviceID 分筒，然后構建 cumulate window 的過程。window 有兩個部分，一個是按天累計的計算參數，另外一個是 watermark 劃分窗口的參數，外層會對不同分筒產生的指標進行聚合計算。
在上線階段，首先是做好時間線的保障規(guī)范，包括時間、操作人、預案內容、操作記錄和檢查點。
- 活動前，部署任務確保沒有計算熱點、check 參數是否合理、觀察作業(yè)情況以及集群情況；
- 活動中，檢查指標輸出是否正常、任務狀態(tài)巡檢以及遇到問題的故障應對和鏈路切換；
- 活動后，下線活動任務、回收活動資源、恢復鏈路部署及復盤。
這里的鏈路是從 Kafka 數據源開始導入到 ODS、DWD、DWS 層，針對 C 端用戶會導入到 KV 存儲里，針對分析類場景會導入到 ClickHouse，最后生成數據服務。我們將任務分成 4 個等級，p0 ~ p3。
- P0 任務是活動大屏，C 端應用對于 SLA 的要求是秒級延遲以及 0.5% 內誤差，但是整體保障時間比較短，一般活動周期都在 20 天左右，除夕類活動 1~2 天內完成。我們應對延遲的方案是針對于 Kafka 和 OLAP 引擎都進行了多機房容災，針對于 Flink 做了熱備雙機房部署。
- 針對 P1 級別的任務，我們對 Kafka 和 OLAP 引擎進行雙機房部署，一方面雙機房部署可以做容災逃生，另一方面在線機房的配置比較好，很少出現機器故障導致作業(yè)重啟的情況。
- 針對 P2 和 P3 級別的任務，我們在離線機房部署，如果存在一些資源空缺的情況，會先停止 P3 任務，騰挪資源給其他任務使用。
服務階段主要分成 4 個層次：
- 第一，SLA 監(jiān)控主要監(jiān)控整體產出指標的質量、時效性和穩(wěn)定性。
- 第二，鏈路任務監(jiān)控主要對任務狀態(tài)、數據源、處理過程、輸出結果以及底層任務的 IO、CPU 網絡、信息做監(jiān)控。
- 第三，服務監(jiān)控主要包括服務的可用性和延遲。
- 最后是底層的集群監(jiān)控，包括底層集群的 CPU、IO 和內存網絡信息。
準確性的目標具體包括以下三部分：離線實時指標一致性用來保障整體的數據處理邏輯是正確的，OLAP 引擎和應用接口一致性用來保證服務的處理邏輯是正確的，指標邏輯錯誤報警用來保障業(yè)務邏輯是正確的。
- 準確性報警又分成 4 個方面，準確性、波動性、一致性和完整性。準確性包括主備鏈路側的一些對比，維度下鉆是否準確；波動性是衡量持續(xù)指標的波動范圍，防止波動大產生的異常；一致性和完整性通過枚舉和指標度量保證產出一致且不存在殘缺的情況。
- 時效性的目標也有 3 個，接口延遲的報警、OLAP 引擎報警和接口表 Kafka 延遲報警。拆分到鏈路層面，又可以從 Flink 任務的輸入、處理和輸出三個方面進行分析：輸入核心關注延遲和亂序情況，防止數據丟棄；處理核心關注數據量和處理數據的性能指標；輸出則關注輸出的數據量多少，是否觸發(fā)限流等。
- 穩(wěn)定性的目標有 2 個，一個是服務和 OLAP 引擎的穩(wěn)定性、批流延遲，另一個是 Flink 作業(yè)的恢復速度。Flink 作業(yè) failover 之后能否快速恢復，對于鏈路的穩(wěn)定性也是很大的考驗。穩(wěn)定性主要關注作業(yè)執(zhí)行的負載情況，以及對應服務依賴的狀態(tài)、整體集群的負載以及單個任務的負載。我們通過目標進行報警，目標拆解的子目標進行監(jiān)控，構建整體的監(jiān)控報警體系。
2.2 反向保障
線上活動正常的開發(fā)測試很難模擬真正的線上環(huán)境和壓測進度，所以反向保障的重點是要測試活動流量預期的情況下能否扛住洪峰，以及出現故障時如何處理？
核心思路是通過壓測演練來模擬活動洪峰的真實場景。首先通過單作業(yè)壓測確定每個作業(yè)的資源分布和作業(yè)所在集群的編排方式，通過全鏈路壓測確保集群資源使用在一定水位并且平穩(wěn)消費洪峰，不會過大或過小。其次，進行容災建設，主要針對作業(yè)失敗、消費延遲、機房故障等提出了一些保障手段。然后，通過演練的方式，確保這些手段可以被正常使用并且能夠達到預期效果。最后，針對演練的預期和目標進行復盤和鏈路風險的改進。
我們構建了自己的壓測鏈路，上面是正常的鏈路，下面是壓測鏈路。首先讀取線上 topic 的數據作為壓測鏈路的初始數據源，利用 rate limit 算法進行流量控制。比如有 4 個 task，希望獲得 1 萬 QPS，那么每個 task 生成的 QPS 會限制在 2500，并且生成數據的過程中會利用人群包修改對應的 user 和生成的時間戳，模擬當天真實的用戶數。
讀取壓測的數據源 topic 并經過作業(yè)處理生成新的 topic 后，如何判斷壓測是否真正通過，有三個標準：第一，確保作業(yè)輸入讀取延遲為毫秒級，且作業(yè)本身無任何反壓。第二，CPU的利用率不超過整體資源的 60%，保障集群有空余 buffer。第三，計算結果和人群包保持一致，證明邏輯是正確的。
經過單作業(yè)壓測之后，我們可以得到很多信息用于指導后續(xù)工作。比如，可以證明活動能在預期流量下保障 SLA，可以發(fā)掘作業(yè)性能瓶頸，指導優(yōu)化達成對應標準以及場景 benchmark，方便低優(yōu)作業(yè)的資源部署。
完成單作業(yè)壓測之后，還是無法判斷所有作業(yè)是否完全啟動。對于 Flink 機房整體的 CPU、IO 還有 memory 壓力等情況，我們可以把每個作業(yè)按照壓測目標值啟動起來，觀察整體作業(yè)和集群的表現。
那么如何判斷全鏈路壓測是否通過呢？也有三個標準：
- 第一，確保作業(yè)輸入讀取延遲為毫秒級，且無反壓。
- 第二，CPU利用率整體不超過 60%。
- 第三，計算結果最終和人群包保持一致。
通過全鏈路壓測之后，可以證明活動在預期流量的峰值情況下能夠保障 SLA，確保 QPS 作用下作業(yè)的資源編排情況，提前確定每個作業(yè)所需的資源和部署參數，確保每個數據源上游最大流量信息，為后續(xù)的限流保障提供基礎。
故障演練有兩種方式：
- 一個是單作業(yè)的故障演練，包括 Kafka topic 作業(yè)故障、Flink 作業(yè)失敗以及 Flink 作業(yè) CP 失敗。
- 二是更體系化的故障，比如鏈路故障，比如單機房故障如何保障正常產出，活動流量超過預期很多如何避免雪崩效應？某個作業(yè) lag 超過一個小時，需要多久能恢復？
容災建設分為兩個部分，鏈路的故障容災和鏈路的容量保障。
鏈路的故障容災保障核心是解決單機房和單作業(yè)失敗恢復時間長的問題和服務的穩(wěn)定性問題。Kafka 本身可以做雙機房容災，生成流量會寫入到兩個機房的 Kafka，出現單機房故障時會自動把流量切換到另外一個機房，而且保證 Flink 作業(yè)無感知。另外一方面機房故障恢復之后，可以自動探測 Kafka 機房的狀態(tài)加入流量。
同樣，容災策略也適用于 OLAP 引擎。針對于 Flink 任務，我們熱備部署了雙鏈路，主備鏈路同邏輯，某個機房出現故障時可以直接將應用側 OLAP 引擎切換到另一個鏈路使用，保障應用端對于故障是無感知的。
鏈路容量的保障是為了解決兩個問題：如果活動流量超過預期很多，如何保障穩(wěn)定性？如果產生了 lag，評估需要多久能夠追趕消費延遲？
根據之前全鏈路壓測的結果，能夠得到每個任務入口的最大流量，并且將這個流量值作為作業(yè)的最大限流值，當活動流量超過了預期很高，數據源側會觸發(fā)讀取限流，Flink 作業(yè)會按照壓測最大負載執(zhí)行。這個時候作業(yè)消費雖有延遲，但是能夠保護鏈路中其他作業(yè)正常運行。并且在洪峰結束后，可以根據 lag 數據和入口流量計算出作業(yè)恢復正常需要的時間，這個是鏈路的故障容災和容量保障的核心措施。
03春節(jié)活動實時保障實踐
春節(jié)活動有以下幾個需求：
- 高穩(wěn)定性，海量數據要求鏈路整體保持穩(wěn)定或出現故障能夠快速恢復。
- 高時效性，億級別流量下，要求大屏指標卡秒級延遲、曲線 1 分鐘級別延遲。
- 高準確性，復雜鏈路情況下，離線和實時指標差異不超過 0.5%。
- 高靈活性，能夠支持活動過程中的多維分析應用場景。
春節(jié)活動的整體方案分為正向和反向的保障措施。
正向保障措施的基礎是監(jiān)控報警體系，分為兩個部分。一方面是對時效性、準確性、穩(wěn)定性做 SLA 目標報警建設。另外一方面是基于鏈路的監(jiān)控體系建設，包括鏈路監(jiān)控、鏈路依賴的服務可用性監(jiān)控以及集群資源監(jiān)控。
在監(jiān)控體系的基礎之上，正向保障措施主要是做開發(fā)階段、測試階段和上線階段的標準化。開發(fā)階段 80% 的需求通過標準化模板來解決，而 20% 的剩余需求可以通過評審的方式解決風險問題。測試階段通過對比的方式保證邏輯準確性，上線階段做分期部署和任務巡檢。
反向保障措施需要構建兩個基礎能力。第一是壓測能力，主要是通過單作業(yè)壓測確定任務性能瓶頸，從而更好地指導優(yōu)化；通過全鏈路壓測確定作業(yè)是否能夠扛過洪峰，并為容災能力提供數據基礎。容災能力主要是通過多機房部署、限流、重試、降級，確保在有故障的情況下有對應的方案。
最后通過故障演練的方式，一方面引入各個組件的故障定位，另一方面模擬流量峰值的情況，確保壓測和容災能力真正得以執(zhí)行。
最后在上線階段通過時間線預案保障活動前、中、后操作步驟都有跡可循，活動結束后對于項目進行復盤，發(fā)現問題并反饋到正反兩個方向的保障體系能力建設。
春節(jié)活動的實踐獲得了巨大的成功。時效性方面，面對上億級別的流量洪峰，大屏核心鏈路指標卡秒級延遲，曲線類一分鐘內延遲，單個任務處理數據量在萬億級別之上，在流量高峰期是秒級延遲。準確性方面，核心鏈路離線和實時任務差異 0.5% 以內，大促活動過程無數據質量問題，有效使用 FlinkSQL 漸進式窗口開發(fā)，大幅度降低窗口丟失導致的精度損失，數據差異從 1% 降到 0.5%。穩(wěn)定性方面，核心鏈路依賴組建雙機房容災、Flink 集群熱備雙鏈路部署，出現問題秒級切換，壓測和容災能力的沉淀，為以后的活動保障體系建設奠定基礎。
04未來規(guī)劃
基于對現有的方法論和應用場景的思考，我們對未來規(guī)劃也做了延伸。
- 第一，保障能力建設。針對壓測和故障注入形成標準化劇本預案，預案執(zhí)行通過平臺能力自動化操作。壓測之后，能夠對問題進行智能診斷，將過往的一些專家經驗進行沉淀。
- 第二，批流一體。過往的活動應用場景過程中，批和流是完全割裂的兩套體系，我們在一些場景下做了流批一體的實踐，并且正在推動整體平臺化建設，通過統(tǒng)一 SQL 的方式提升整體開發(fā)效率，并且機器錯峰使用可以減少作業(yè)壓力。
- 第三，實時數倉建設。通過豐富實時數倉內容層面，以及開發(fā)組件的沉淀和 SQL 化的手段，達成開發(fā)效率的提升，最終達到降本提效的目的。
