美團買菜基於 Flink 的實時數倉建設

摘要： 本文整理自美團買菜實時數倉技術負責人嚴書，在 Flink Forward Asia 2022 實時湖倉專場的分享。本篇內容主要分爲四個部分：

    1. 背景介紹

    2. 技術願景和架構設計

    3. 典型場景、挑戰與應對

    4. 未來規劃

01 背景介紹

美團買菜是美團自營生鮮零售平臺，上面所有的商品都由美團親自採購，並通過供應鏈物流體系，運輸到距離用戶 3km 範圍內的服務站。用戶從美團買菜平臺下單後，商品會從服務站送到用戶手中，最快 30 分鐘內。

上圖中，左側的時間軸展示了美團買菜的發展歷程，右側展示了美團買菜豐富的商品。目前，美團買菜在北上廣深、武漢等城市均有業務覆蓋，爲人們日常的生活提供便利。在疫情場景下，起到了非常重要的保障民生作用。

接下來，介紹一下實時數倉場景。美團買菜的實時數倉場景分爲三個部分。

02 技術願景和架構設計

技術願景和架構設計。實時數倉的技術願景是在新零售場景下，建設質量可靠、運行穩定、覆蓋核心鏈路環節的實時數據體系。這裏着重強調質量可靠、運行穩定、覆蓋核心鏈路環節。

美團買菜所處的新零售行業，是一個薄毛利率賽道，對數據準確性的要求較高。由於買菜業務的正常運轉，對數據有着強依賴，所以要求數據必須運行穩定。與此同時，美團買菜是自營的全鏈條業務，業務的鏈條環節較多，我們希望能夠覆蓋核心的鏈路環節。

基於上述的技術願景，我們着重建設了質量保障體系、穩定性保障體系。這兩個體系的主要目的是，提升實時數倉基線能力，讓數據穩定生產，質量可信賴。希望質量保障體系、穩定性保障體系能夠成爲實時數倉的基石，建設好實時數倉的基本功。

在做好實時數倉基本功的基礎上，我們希望數據發揮它的最大價值。根據 DIKM 模型，從數據到信息，信息到知識，知識到智慧，價值會被不斷放大。基於 DIKM 模型的理論指導，我們建立了全域數據中心、統一資產管理中心。

其中，全域數據中心會有效組織原始事實和原始數據，讓數據轉換成信息。統一資產管理中心對信息加以提煉，提升洞察力、創造力，幫助信息更好的轉換成知識、智慧。

接下來，介紹一下實時數倉的整體架構。如上圖所示，底層模塊是數據平臺部分，包含了數據的同步、加工、質量檢測、管理權限、數據治理等環節設計的數據工具鏈。

在數據平臺工具模塊之上是全域數據中心、質量保障體系、穩定性保障體系三個模塊。其中，全域數據中心是基於數據源 ODS 層建設的數據倉庫。在數據源 ODS 層，當前主要包含買菜業務數據、美團公共數據、靈犀流量數據、外部數據四個部分。

數據倉庫主要有 DWD 層、DWS 層、APP 層和一致性的 DIM 層組成。其中，DWD 層主要還原業務的數據加工過程，包含清洗、轉換、過濾。原子指標的加工會在 DWD 層進行收口。

DWS 層是面向分析場景建設的，主要的建模方式是維度建模。在 DWS 層常見的數據加工過程包含多個業務主題的數據關聯，數據力度上的輕度彙總，衍生指標的加工。

APP 層主要面向應用場景建設寬表模型，其目的是更好地滿足應用場景的個性化需求，提升數據應用的效率和體驗。

質量保障體系主要包含流程規範、質量監控、問題處理、持續改進四個部分，形成了一個閉環的管理系統。穩定性保障體系從預防、發現、處理、規範四個角度建設。

統一資產管理中心基於全域數據管理中心質量保障體系、穩定性保障體系，其建設基礎是元數據管理。元數據包含指標、維度、實時流、畫像標籤、實時特徵、數據大盤、數據接口等等。

基於原數據之上是資產全景、資產應用、資產優化三個部分。資產全景將數據資產，通過分類檢索的形式展示出來。數據應用部分包含了應用的管理、應用的血緣。資產優化部分包含模型優化、接口優化。

03 典型場景、挑戰與應對

3.1 動態 ETA 實時特徵

實時數倉典型場景下的挑戰和應對方法。首先，介紹一下動態 ETA 實時特徵場景。

如上圖所示，展示了用戶在美團買菜下單的頁面情況。頁面中顯示的預計送達時間，涉及到了動態 ETA。動態 ETA 是動態的承諾送達時間。經過研究發現，承諾用戶送達時間不準，會影響用戶的下單意願。與此同時，當訂單預計送達時間和實際送達時間差異變大後，客訴率及取消率均有明顯攀升。

動態 ETA 的實現依賴算法模型預估履約時效。算法模型預估履約時效需要用到天氣特徵、用戶下單商品特徵、服務站內作業實時特徵、配送實時特徵。

動態 ETA 算法模型需要的實時特徵數量非常多。算法特徵生產鏈路比較複雜，任何一個實質特徵的缺失，都會影響到算法模型的準確性，從而直接影響 C 端用戶。因此實時特徵數據穩定性要求 3 個 9 以上。

那麼什麼是 3 個 9 的穩定性呢？提升穩定性的本質，是提高系統的可用性。系統的可用性等於，平均無故障時間除以，平均無故障時間 + 平均故障修復時間。想要實現 3 個 9 的穩定性，要求平均每天故障時間少於 1.44 分鐘。

接下來，講一講提升數據穩定性的方式。提升數據穩定性需要提升可用性。提升可用性的本質是，降低不確定性帶來的風險。降低不確定性帶來的風險包含發現問題、解決問題兩個部分。

在發現問題方面，需要思考如何識別風險。在實時特徵的生產中，我們會通過容量預估、性能壓測、容災演練、全鏈路監控，實時對賬的方式，更好的識別風險。

在解決問題方面，需要思考如何應對風險。一些常見應對風險的方式包含存儲計算、雙鏈路備份、實時特徵、易購存儲、降級預案、故障處理 SOP、事故覆盤、完善工具和規範等。

上圖展示了，在故障發生的不同階段，對穩定性的影響。事前階段發生故障，對穩定性的影響最小。所以實時特徵場景穩定性建設的關鍵策略是，儘可能在故障發生之前發現問題、解決問題。

穩定性保障體系全景。穩定性保障體系全景包含預防、發現、處理、規範四個部分。其中，預防部分主要包括異構存儲、雙鏈路備份、性能壓測、容量預估、容災演練、特徵分級等等。

異構存儲是指，Doris 和 ES 作爲應用層的存儲引擎。雙鏈路備份是指，存儲和計算，多機房部署兩條數據生產鏈路。這兩條數據生產鏈路互爲儲備，任何一條鏈路出現問題，都可以快速切換到另一條鏈路，從而保障數據的持續生產。在性能壓測部分，主要通過數據回放和流量控制實現。容量預估是指 Flink 的併發數和內存配置。

在發現部分，我們除了在硬件、組件、服務層建立完善的監控體系，還針對數據場景的常見風險、異常情況，着重建設了 ETL 任務監控、端到端數據延遲監控、實時離線 t+1 對賬。在風險處理部分，我們主要通過故障處理、兜底策略、降低預案來實現。

在預防、發現、處理三個部分的經驗，通過規範的形式進行沉澱。規範部分主要包含事故的覆盤規範、技術方案 review 規範、代碼 review 機制、上線發佈流程規範、巡檢機制、值班制度。

下面重點介紹一下性能壓測部分。如上圖所示，我們通過環境隔離的方式，建立了線上和測試兩條完整的數據鏈路。

在測試鏈路中，我們通過回撥 Kafka Offset，得到了非常大的數據流量。然後，通過流量控制模塊得到需要的測試流量，從而實現按需構建壓測流量。最後，我們通過記錄不同流量下的鏈路性能，得到了需要的性能壓測結果。

上圖展示了性能壓測結果的評估指標體系，其中包含了過程指標和結果指標。主要指標有任務配置、機器狀態、Source QPS、Sink QPS、瓶頸算子 QPS、最大可支撐流量倍數 N、端到端耗時。

3.2 實時數據經營分析

實時數據經營分析場景。美團買菜業務經常舉行營銷活動，提升用戶的活躍度。在營銷大促場景下，運營人員需要實時瞭解業務的經營狀態，並制定運營策略。

與此同時，買菜業務受工作日、非工作日、節假日因素的影響，數據指標波動較大。單純看指標的大小，很難判斷指標的好壞，往往需要結合周同比、年同比進行輔助判斷。在近幾年的疫情場景下，買菜業務經常出現搶單模式，流量短時間內暴漲。

美團買菜面臨的挑戰。一方面，數據質量要求十分嚴苛。實時和離線數據差異不超過萬分之三，端到端的數據差異不超過萬分之一。在百萬 QPS 流量下，需要保障無數據延遲。

另一方面，數據架構本身複雜度高。在實時、離線兩條生產鏈路下，Flink 只支持計算引擎內的 exactly-once。

在上述情況下，數據質量的保障面臨了很大挑戰。數據質量是指，數據的一組滿足固有特性（質量維度）要求的程度。

上圖中，左邊展示了數據質量問題。數據不同程度缺失，數據集成流程中的數據不等價，在數據需求期限內未獲取最新數據，數據與目標特徵值之間的差異程度、數據標識不唯一。

由於這些數據質量問題可以通過對應的指標來衡量，所以我們用數據完整性、數據一致性、數據及時性、數據準確性、數據唯一性，來衡量數據質量的好壞。

數據質量保障體系的建設思路是基於閉環管理，事前通過流程規範，減少質量問題的發生。事中通過數據質量監控系統，發現問題並處理問題。事後通過覆盤的形式，將遇到的問題總結提煉，持續對流程規範進行改進。由此可見，事前、事中、事後組成了完整的閉環。

在數據保障體系的推進策略上，我們整體上分爲三個階段。

上圖是數據質量保障體系的能力圖，數據質量保障體系包含流程規範、質量監控、問題處理、持續改進四個模塊兒。流程規範部分包含數據開發規範、工程開發流程規範、產業合作機制運營三個部分。

質量監控包含系統監控和服務監控。其中，系統監控包含存儲引擎 Kafka 流量監控、計算引擎 Flink 核心指標監控、基於數據埋點的 Raptor 異常監控。

在服務監控方面，包含了主鏈路差值監控、APP 從同環比監控、ODS 層同環比監控。在問題處理方面，主要包括影響周知，告警處理、數據修復。在持續改進方面，包含基於時間線梳理、聲音定位、問歸因、監控告警優化、作業調參優化、資源配置優化。

在實時離線數據的一致性方面，我們基於 Doris 實現了存儲一體架構。存儲一體架構是基於 Lambda 架構改進實現的。在數據源部分，數據源通過兩種數據同步的方式，分別同步到實時數倉和離線數倉。

實時數倉通過 Flink 引擎，對數據進行分層加工。離線數倉通過 Spark 引擎，對數據進行分層加工。實時數倉的數據和離線數倉的數據，最終會寫到 Doris 存儲引擎的同一個數據模型上。

Doris 數據模型按天進行分區，實時數倉的數據會寫到當天分區，離線數倉的數據會寫到歷史分區。當外部的數據查詢需要查詢當天或歷史數據時，只需要通過時間分區路由。從而保證數據指標、數據維度口徑完全一致。

在數據準確性方面，我們通過數據冪等和監控來實現。Kafka 只支持計算引擎內的 exactly once。爲了實現端到端的 exactly once，我們一方面使用 Doris 的約定模型，實現數據冪等。另一方面，在數據加工過程中，按照業務組件進行數據去重。數據去重通常採用 row number 或 last value 的方式實踐。

在質量的監控上，監控指標體系包含窗口統計指標、波動監控窗口。窗口統計指標是指，數據量、最大值、最小值、平均值、空值、佔比、正則匹配。波動監控是指，數據的同環比。

在數據的及時性方面，我們通過性能瓶頸的定位和優化來解決。上圖展示了數據生產鏈路性能瓶頸定位的過程。我們在 Flink ETL 任務裏，植入算子處理的時間埋點。然後，將 ETL 任務輸出的 Kafka，同步一份埋點數據到 Hive 引擎裏。基於 Hive 引擎進行算子處理、性能分析，從而定位性能瓶頸。

當算子定位到性能瓶頸之後，我們採用的優化方式包含 TM JVM 性能調優、Doris 性能優化、Flink 任務優化。具體的優化方式包括調整新生代、老年代比例；Doris 導入併發數；compaction 參數調優；模型合併；RSU 數據緩存；大狀態消除；代碼邏輯優化等等。

04 未來規劃

接下來，講一講未來規劃。實時數倉的未來規劃主要包含三個部分。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XTd5KVESrZgTcmoR6upcPg

猜你喜歡