文章作者：李金康 美團 高級技術(shù)專家

內(nèi)容來源：Frank

出品平臺：DataFunTalk

出處:https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247520201&idx=1&sn=6c1511a1bc2882b4ac9dec99e60df86c

導(dǎo)讀： 2019年5月，美團正式推出新品牌「美團配送」，升級配送開放平臺。那你知道支撐美團配送大腦的實時特征平臺是如何建設(shè)的嗎？如何實現(xiàn)每分鐘生產(chǎn)千萬級的實時特征？如何在70w+QPS的場景下實現(xiàn)4個9響應(yīng)耗時在50毫秒的需求？本文將為大家介紹配送實時特征平臺的發(fā)展歷程，關(guān)鍵技術(shù)和實踐經(jīng)驗。

01

配送業(yè)務(wù)介紹

1. 商業(yè)模型

配送的業(yè)務(wù)最主要的就是一個履約的行為，將用戶、商家和騎手關(guān)聯(lián)起來，促進配送效率提升、用戶體驗提高、配送成本降低，從而形成一個閉環(huán)的商業(yè)模型。

即時配送平臺核心職責(zé)就是調(diào)整好用戶、商家、騎手三元的關(guān)系，用更低的成本為用戶帶來更好的體驗，為商家?guī)砀嗟膯瘟?，為騎手帶來更多的收入。

2. 履約模型

配送就是一個履約的過程，不像電商主要是線上完成，配送主要是線下完成履約。

• 物理世界中，一個運單的完成過程是從用戶下單開始到用戶收餐騎手離客為止，需經(jīng)歷一系列室內(nèi)室外的場景——用戶下單，系統(tǒng)派單，騎手室外騎行到目的地然后下車步行到商家，等待取餐駐留室內(nèi)，商家出餐，騎手取餐離店后步行上車，室外騎行到用戶目的地，下車步行上樓送餐，駐留室內(nèi)等待用戶收餐，最后用戶收餐騎手離客。
• 可以看到物理世界是比較復(fù)雜的一個過程，那就需要智能決策系統(tǒng)來做一定的調(diào)度，派給哪個騎手？何時到店取餐？同時要做一個合理的定價，針對惡劣天氣和爬樓梯等特殊情況收的費用肯定是不同的，收多少配送費？付給騎手多少配送費？最后還要給出一個合理的時間預(yù)估，配送時長是多少？商家多久可以出餐？
• 算法要做以上這些智能決策過程中，就需要做履約過程整個鏈路的數(shù)字化，通過實時特征平臺來做實時感知的數(shù)字化，通過AIoT平臺完成如騎手騎行、爬樓等行為精準(zhǔn)感知的數(shù)字化；本次主要介紹實時感知數(shù)字化的實時特征平臺。

02

實時特征平臺建設(shè)

1. 背景

2017年開始做實時特征平臺建設(shè)的背景是為了解決兩大問題：

• 千萬訂單履約過程智能化：最開始履約過程是由簡單的規(guī)則構(gòu)建的，現(xiàn)在要實現(xiàn)從規(guī)則配置化向智能化過渡，包含智能調(diào)度、ETA時間預(yù)估、配送費定價和爆單等場景；算法實時決策需要分鐘級數(shù)據(jù)的時效性。
• 現(xiàn)有開發(fā)模式無法及時響應(yīng)：當(dāng)時實時特征開發(fā)散落在4個業(yè)務(wù)團隊，進行煙囪式開發(fā)，流程長、效率低，存在一些重復(fù)建設(shè)；實時特征開發(fā)耦合在業(yè)務(wù)系統(tǒng)中，穩(wěn)定性風(fēng)險較高。

2. 目標(biāo)&規(guī)劃

基于建設(shè)背景，設(shè)定了建設(shè)目標(biāo)——建設(shè)分鐘級時效的實時特征平臺，多粒度刻畫履約過程，提升研發(fā)效率，降低研發(fā)成本。

基于建設(shè)目標(biāo)，設(shè)定了三階段的演進計劃：

• 第一階段——系統(tǒng)化：和業(yè)務(wù)系統(tǒng)劃清邊界、確定實時平臺架構(gòu)；將系統(tǒng)搭建起來，驗證是否可以支撐業(yè)務(wù)場景；將新增特征進行收口管理。
• 第二階段——規(guī)?；航ㄔO(shè)高可用的系統(tǒng)，支撐更多的實時特征，將舊特征“絞殺”進行統(tǒng)一收口管理。
• 第三階段——平臺化：將實時計算整合，進行完善的服務(wù)治理。

3. 系統(tǒng)化

① 設(shè)計思路

② 整體架構(gòu)

進行系統(tǒng)化整體架構(gòu)設(shè)計時，先制定了左側(cè)的架構(gòu)標(biāo)準(zhǔn)：

• 流程標(biāo)準(zhǔn)化：從數(shù)據(jù)輸入，加工計算到數(shù)據(jù)輸出做了一個流程的標(biāo)準(zhǔn)化。
• 數(shù)據(jù)分層，將共性沉淀下來。
• 特征兜底，降低風(fēng)險。

基于架構(gòu)標(biāo)準(zhǔn)，最終制定了右側(cè)的架構(gòu)圖，共分為6層：

• 數(shù)據(jù)源層：主要有包裹表、運單表、騎手表以及運單擴展表。
• 數(shù)據(jù)層：ODS層將數(shù)據(jù)進行清洗和轉(zhuǎn)換，在DWD進行維表建模和合流，最后形成索引數(shù)據(jù)和明細數(shù)據(jù)的寬表。
• 計算層：通過標(biāo)準(zhǔn)化的SQL對寬表數(shù)據(jù)進行計算。
• 存儲層：存儲計算層輸出的特征數(shù)據(jù)。
• 服務(wù)層：通過實時特征服務(wù)將存儲層數(shù)據(jù)統(tǒng)一輸出應(yīng)用層應(yīng)用。
• 應(yīng)用層：主要有ETA時間預(yù)估策略服務(wù)、調(diào)度策略服務(wù)、保單策略服務(wù)以及定價策略服務(wù)。
• 管理系統(tǒng)：主要就是一些元數(shù)據(jù)的管理，比如數(shù)據(jù)源、特征口徑以及存儲的管理；還包含兜底策略管理，降級模塊，可以對單特征降級，也支持批量降級的核按鈕。

③ 數(shù)據(jù)層關(guān)鍵點

做實時數(shù)據(jù)系統(tǒng)大都會碰到兩個挑戰(zhàn)：

• 流亂序問題
• 端到端的Exactly-Once語義保障

針對以上挑戰(zhàn)，結(jié)合配送的實際業(yè)務(wù)場景給出對應(yīng)的解決思路：

• 提前構(gòu)建“拼圖”模板，實時填充：結(jié)合物理世界的配送履約過程，構(gòu)建業(yè)務(wù)寬表，涵蓋下單時間、支付時間、發(fā)單時間、調(diào)度時間、接單時間、取餐時間、送達時間等，根據(jù)實時數(shù)據(jù)流填充模板寬表，避免各數(shù)據(jù)流填各自的字段，避免亂序問題。
• 上游合流保證不丟，下游解決重復(fù)問題。

④ 計算層關(guān)鍵點

2017年調(diào)研了一些行業(yè)解決方案:

• Storm開發(fā)運維成本較高、SQL化難度高。
• Flink沒有現(xiàn)在這么火，穩(wěn)定性無法保障；Spark Streaming不是公司運維的關(guān)鍵點，對于線上場景的穩(wěn)定性也是無法保障。
• 耦合在業(yè)務(wù)系統(tǒng)內(nèi)部的基于Rpc計算在公司有成熟的監(jiān)控運維體系和技術(shù)框架，但有一個問題是，該場景主要是基于關(guān)系型數(shù)據(jù)庫進行計算的，例如MySQL，是存在單點問題的，擴展較難。

因為對基于Rpc的計算是相對有把握的，所以首先升級計算框架，將原有基于關(guān)系數(shù)據(jù)庫計算升級為基于內(nèi)存計算，計算是無狀態(tài)、可擴展的；為了防止數(shù)據(jù)傾斜，基于業(yè)務(wù)特點進行提前按區(qū)域分片，采用“能者多勞”模式，計算比較快的節(jié)點就多計算一些。

接下來介紹下計算層的核心邏輯：

• 首先，數(shù)據(jù)層形成的寬表，主要存儲在外存中，例如運單包裹合流信息，那它如何和區(qū)域dim起來？就是通過索引表，將區(qū)域和運單關(guān)聯(lián)起來。
• 其次，全國有多少區(qū)域是確定的，每隔一分鐘會通過定時任務(wù)將全國的區(qū)域放到MQ中。
• 最后，就是實時特征計算服務(wù)FCS，每個計算節(jié)點有多個worker，每個worker中有task會做基于內(nèi)存數(shù)據(jù)庫H2的計算，當(dāng)收到MQ的區(qū)域信息后，會拉取對應(yīng)區(qū)域的寬表數(shù)據(jù)，在H2中計算實時特征，計算完成后會繼續(xù)計算下一批的實時特征。

⑤ 階段成果

建設(shè)系統(tǒng)化的階段成果主要有：

• 刻畫粒度：維度上主要有商家和區(qū)域；粒度上主要有訂單、運單、包裹。
• 效率：特征上線由原來的多天提升到分鐘級，收口新特征有60多個。
• 接入量：接入9個算法模型、15個算法版本。
• 穩(wěn)定性：通過特征兜底策略避免了Kafka集群故障，系統(tǒng)沒有S級事故。

4. 規(guī)模化

① 數(shù)據(jù)服務(wù)挑戰(zhàn)&思路

第二階段規(guī)?；ㄔO(shè)的背景就是推動實時特征收口。

在外賣的圖中會顯示每單的配送時長，看上去這是一個指標(biāo)，但實際上這個指標(biāo)從外賣到配送經(jīng)過的鏈路是很長的，最少有五六個節(jié)點，雖然只是一個ETA的預(yù)估時間，但是涉及到的特征可能有60個左右；另外，商家列表頁會幾百個商家，還要做排序，這樣對實時特征的壓力非常大，對實時特征的查詢性能有更高的要求，通常200毫秒的延遲用戶就會感知到。所以實時特征計算就會面臨兩個問題:

• 穩(wěn)定性要求高：交易鏈路
• 性能要求高：50ms響應(yīng)時間

解決以上問題的主要思路有：

• 定制度：“135”制度，1分鐘響應(yīng)問題，3分鐘定位問題，5分鐘恢復(fù)計算
• 保穩(wěn)定：做全鏈路的監(jiān)控和降級
• 提性能：滿足50ms的響應(yīng)時間

② 穩(wěn)定性建設(shè)框架

結(jié)合實際問題，制定了穩(wěn)定性建設(shè)的框架：

• 四層監(jiān)控體系：硬件監(jiān)控（CPU/網(wǎng)絡(luò)/磁盤/內(nèi)存）、基礎(chǔ)組件監(jiān)控（DB/MQ/ES/緩存）、服務(wù)監(jiān)控（性能/異常/超時率/QPS）以及全鏈路數(shù)據(jù)質(zhì)量監(jiān)控。
• 容災(zāi)體系：事前會做隔離、雙緩存的架構(gòu)設(shè)計，1.5倍容量規(guī)劃以及定期壓測；事中會做熔斷、限流，三層降級（計算、服務(wù)、算法各層都有各自的降級兜底策略）的容錯降級機制；事后主要是做CaseStudy的總結(jié)以及報警工具的完善，同時還要對實時索引和離線數(shù)據(jù)進行修復(fù)。
• 制度：有完善的技術(shù)方案review機制、代碼reiview機制、上線制度、巡檢制度、值班制度以及報警治理等制度，最終形成一套可監(jiān)控、可灰度、可回滾的技術(shù)體系。

③ 穩(wěn)定性建設(shè)：拆分、隔離

在規(guī)模化穩(wěn)定性建設(shè)的拆分和隔離上，主要做法如下：

• 服務(wù)鏈路：遵循按照業(yè)務(wù)場景垂直拆分、一套代碼部署隔離的服務(wù)/存儲拆分原則，將實時特征服務(wù)拆分為ETA、調(diào)度、定價、爆單四個服務(wù)，在物理環(huán)境上進行隔離，但是使用的是同一套代碼。
• 計算鏈路：通過雙機房（rz、gh）熱備、三種場景集群（監(jiān)控、運營、履約）對Storm集群進行拆分；使用美團自研的多機房Mafka集群做了MQ容災(zāi)，替換了單機房Kafka集群；對于數(shù)據(jù)收集的canal做了隔離，離線、實時、zk隔離，并做了多機房的容災(zāi)。

④ 數(shù)據(jù)質(zhì)量

在數(shù)據(jù)質(zhì)量上做了全鏈路過程質(zhì)量的監(jiān)控：

• 流計算：監(jiān)控時效性；
• FCS實時特征計算：監(jiān)控性能、延遲、完備性、準(zhǔn)確性；
• FFS實時特征服務(wù)：監(jiān)控響應(yīng)時間、可用性、容量；
• 特征結(jié)果：監(jiān)控準(zhǔn)確性、完備性。

例如：數(shù)據(jù)清洗中會關(guān)注消息處理耗時；FCS服務(wù)會關(guān)注event流入總量、sql流入總量、內(nèi)存表記錄數(shù)、空值特征比例、單批次計算耗時；寬表會關(guān)注寬表記錄數(shù)、未填充字段占比、不合理記錄占比；特征質(zhì)量會關(guān)注騎手平均負載最大值發(fā)生的時間、區(qū)域特征個數(shù)95分位數(shù)、商家平均特征個數(shù)、騎手負載中位數(shù)、眾數(shù)等；FFS服務(wù)會關(guān)注每次請求耗時、請求密度、請求成功率和QPS等。

⑤ 查詢服務(wù)性能優(yōu)化

做查詢服務(wù)性能優(yōu)化主要有三個思路：

• IO：使用批量、分組方式降低IO頻次；使用PB格式替換原JSON格式、去除無用字段等減負瘦身方式來降低IO大小；使用高速的本地緩存。
• CPU：減少Stop The World時間，使用G1替換了原來的CMS。
• 內(nèi)存：減少對象創(chuàng)建，控制對象大小。

最終成果是TP4個9的耗時穩(wěn)定在40毫秒以內(nèi)。

⑥ 建設(shè)成果

規(guī)?；慕ㄔO(shè)成果主要有：

• 接入量：接入100+算法版本，200+實時特征全部收口，調(diào)度、ETA、定價、爆單策略21個核心服務(wù)全部接入。
• 性能：60w+QPS下，4個9的響應(yīng)時間在50毫秒以內(nèi)；每分鐘生產(chǎn)1000w+特征，計算耗時小于40秒；計算、服務(wù)、存儲都支持水平擴展。
• 穩(wěn)定性：應(yīng)對了GH機房斷電故障，且沒有S級事故。

5. 平臺化

① 背景&策略

平臺化的建設(shè)背景是需要滿足更多粒度的特征需求，第一類是降雨、降雪等天氣等級等的區(qū)域維度以及騎手軌跡等的騎手維度；第二類是通過算法實時加工的特征，如預(yù)計出餐時長和預(yù)計進單量。

針對以上背景，有兩大策略來解決：

• 開放策略：事件驅(qū)動，開放履約事件，讓業(yè)務(wù)平臺可以根據(jù)開放平臺自己計算一些特征。
• 集成策略：建設(shè)數(shù)據(jù)收集通道，匯總第三方特征，業(yè)務(wù)通過收集通道將自己計算的特征上報匯總起來；將類似于騎手軌跡這種動態(tài)維度，屏蔽了計算引擎，引入了Flink進行動態(tài)維度計算。

② 架構(gòu)升級

上圖是在平臺化建設(shè)過程中升級后的架構(gòu)，藍色部分是新增的：

• 數(shù)據(jù)源層新增了采集SDK：業(yè)務(wù)平臺可以將自己算的特征通過SDK上報到MQ里面，然后通過計算引擎落到第三方特征存儲，通過服務(wù)層提供給需求方。
• 計算層引入了Flink和Storm，建設(shè)了一層引擎路由，屏蔽掉了底層的計算引擎，讓用戶使用無感知。

• 數(shù)據(jù)粒度：新增了GeoHash、AOI的維度；新增了天氣、軌跡、預(yù)測類特征的粒度。
• 接入量：實現(xiàn)了200+第三方特征自助化上報，履約事件校友對接了ADS、ETA等服務(wù)。
• 穩(wěn)定性：無S級事故。

③ 建設(shè)成果

實時特征平臺的建設(shè)成果有：

• 業(yè)務(wù)效果：計算400+實時特征，覆蓋了ETA、爆單、調(diào)度、動態(tài)定價等配送線上策略；實時特征成為配送履約的一環(huán)，對算法策略的效果提升顯著。
• 效率提升：開發(fā)周期從多天降低到分鐘級別。
• 性能和穩(wěn)定性：每分鐘處理上億條數(shù)據(jù)；在70W+的QPS場景下，實時特征服務(wù)4個9響應(yīng)時間在50毫秒；沒有S級故障。

03

未來規(guī)劃

配送數(shù)據(jù)方向的未來規(guī)劃有：

• 數(shù)據(jù)治理：除了實時特征外，還有活動類、運營類的實時數(shù)據(jù)，因此未來考慮實時特征以及其他場景的數(shù)據(jù)與實時數(shù)倉進行融合；雖然目前做了一些端到端的監(jiān)控，但大都是單節(jié)點的監(jiān)控，未來會做從數(shù)據(jù)源到最終提供服務(wù)的全鏈路的數(shù)據(jù)質(zhì)量建設(shè)。
• 降低研發(fā)成本：可以看到目前架構(gòu)中使用的計算引擎開發(fā)運維成本有點高，有FCS微批處理、Storm、Flink，未來會考慮將計算引擎整合，降低開發(fā)運維成本。