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

內(nèi)容來源：Frank

出品平臺：DataFunTalk

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

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

01

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

1. 商業(yè)模型

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

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

2. 履約模型

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

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

02

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

1. 背景

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

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

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

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

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

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

3. 系統(tǒng)化

① 設(shè)計(jì)思路

② 整體架構(gòu)

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

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

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

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

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

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

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

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

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

④ 計(jì)算層關(guān)鍵點(diǎn)

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

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

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

接下來介紹下計(jì)算層的核心邏輯：

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

⑤ 階段成果

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

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

4. 規(guī)模化

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

第二階段規(guī)模化建設(shè)的背景就是推動實(shí)時(shí)特征收口。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⑥ 建設(shè)成果

規(guī)模化的建設(shè)成果主要有：

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

5. 平臺化

① 背景&策略

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

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

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

② 架構(gòu)升級

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

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

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

③ 建設(shè)成果

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

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

03

未來規(guī)劃

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

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