大數據：美團酒旅實時數據規則引擎應用實踐

背景

美團點評酒旅運營需求在離線場景下，已經獲得了較爲系統化的支持，經過對離線數據收集、挖掘，可對目標用戶進行T+1觸達，經過向目標用戶發送Push等多種方式，在必定程度上提升轉化率。但T+1自己的延遲性會致使用戶在產生特定行爲時不能被實時觸達，沒法充分發揮數據的價值，取得更優的運營效果。

在此背景下，運營業務須要着手挖掘用戶行爲實時數據，如實時瀏覽、下單、退款、搜索等，對知足運營需求用戶進行實時觸達，最大化運營活動效果。

業務場景

在運營實時觸達需求中，存在以下具備表明性的業務場景：

1. 用戶在30分鐘內發生A行爲次數大於等於3次
2. 用戶爲美團酒店老客，即用戶曾購買過美團酒店產品
3. 用戶在A行爲前24小時內未發生B行爲
4. 用戶在A行爲後30分鐘內未發生B行爲（排除30分鐘內用戶自發產生B行爲的影響，下降對結果形成的誤差）

本文以該典型實時運營場景爲例，圍繞如何設計出可支撐業務需求高效、穩定運行的系統進行展開。

早期方案

運營實時觸達需求早期活動數量較少，咱們經過爲每一個需求開發一套Storm拓撲相關代碼、將運營活動規則硬編碼這一「短平快」的方式，對運營實時觸達需求進行快速支持，如圖1所示：

圖1 早期方案示意圖

早期方案的問題

早期方案是一種Case By Case的解決方式，不能造成一個完整的系統。隨着實時運營業務開展，相關運營活動數量激增，線上維護着多套類似代碼，一方面破壞了DRY（Don't Repeat Yourself）原則，另外一方面線上維護成本也呈線性增加，系統逐漸沒法支撐當前的需求。

挑戰

爲解決早期方案中出現的問題，對系統建設提出瞭如下挑戰：

• 硬編碼活動規則的方式產生了大量重複代碼，開發成本較高，需求響應時間較長。
• 業務規則修改困難，調整運營活動條件須要修改代碼並重啓線上拓撲。
• 線上Storm拓撲較多，資源利用率、系統吞吐量低，統一維護成本較高。
• 缺少完善的監控報警機制，很難早於業務發現系統及數據中存在的穩定性問題。

針對以上挑戰，結合業務規則特色，美團點評數據智能團隊調研並設計了酒旅運營實時觸達系統。

技術調研

規則引擎的必要性

提升靈活度須要從業務規則和系統代碼解耦和入手，規則和代碼耦合直接致使了重複代碼增多、業務規則修改困難等問題。那如何將業務規則和系統代碼解耦和呢？咱們想到使用規則引擎解決這一問題。

規則引擎是處理複雜規則集合的引擎。經過輸入一些基礎事件，以推演或者概括等方式，獲得最終的執行結果。規則引擎的核心做用在於將複雜、易變的規則從系統中抽離出來，由靈活可變的規則來描述業務需求。因爲不少業務場景，包括酒旅運營實時觸達場景，規則處理的輸入或觸發條件是事件，且事件間有依賴或時序的關係，因此規則引擎常常和CEP（複合事件處理）結合起來使用。

CEP經過對多個簡單事件進行組合分析、處理，利用事件的相互關係，找出有意義的事件，從而得出結論。文章最前面背景中提到的業務場景，經過屢次規則處理，將單一事件組合成具備業務含義的複合事件，進而提升該類僅瀏覽未下單的用戶的下單機率。能夠看出，規則引擎及CEP能夠知足業務場景的具體需求，將其引入能夠提升系統面對需求變化的靈活度。

規則引擎調研

在設計規則引擎前，咱們對業界已有的規則引擎，主要包括Esper和Drools，進行了調研。

Esper

Esper設計目標爲CEP的輕量級解決方案，能夠方便的嵌入服務中，提供CEP功能。

優點

• 輕量級可嵌入開發，經常使用的CEP功能簡單好用。
• EPL語法與SQL相似，學習成本較低。

劣勢

• 單機全內存方案，須要整合其餘分佈式和存儲。
• 之內存實現時間窗功能，沒法支持較長跨度的時間窗。
• 沒法有效支持定時觸達（如用戶在瀏覽發生後30分鐘觸達支付條件判斷）。

Drools

Drools開始於規則引擎，後引入Drools Fusion模塊提供CEP的功能。

優點

• 功能較爲完善，具備如系統監控、操做平臺等功能。

劣勢

• 學習曲線陡峭，其引入的DRL語言較複雜，獨立的系統很難進行二次開發。
• 之內存實現時間窗功能，沒法支持較長跨度的時間窗。
• 沒法有效支持定時觸達（如用戶在瀏覽發生後30分鐘觸達支付條件判斷）。

因爲業務規則對時間窗功能及定時觸達功能有較強的依賴，綜合以上兩種規則引擎的優劣勢，咱們選用了相對SpEL更爲輕量的表達式引擎Aviator，將流式數據處理及規則引擎集成至Storm中，由Storm保證系統在數據處理時的吞吐量，在系統處理資源出現瓶頸時，可在公司託管平臺上調整Worker及Executor數量，下降系統水平擴展所需成本。

技術方案

肯定引入規則引擎後，圍繞規則引擎的設計開發成爲了系統建設的主要着力點。經過使用實時數據倉庫中的用戶實時行爲數據，按業務運營活動規則，組合成有意義的複合事件，交由下游運營業務系統對事件的主體，也就是用戶進行觸達。將系統抽象爲如下功能模塊，如圖2所示：

圖2 系統模塊圖

整體來看，系統組成模塊及功能以下：

• 規則引擎：集成於Storm拓撲中，執行運營活動條件轉換成爲的具體規則，做出對應響應。
• 時間窗模塊：具備可選時間跨度的滑動時間窗功能，爲規則斷定提供時間窗因子。
• 定時觸達模塊：設定規則斷定的執行時間，達到設定時間後，執行後續規則。
• 自定義函數：在Aviator表達式引擎基礎函數之上，擴展規則引擎功能。
• 報警模塊：定時檢查系統處理的消息量，出現異常時爲負責人發送報警信息。
• 規則配置控制檯：提供配置頁面，經過控制檯新增場景及規則配置。
• 配置加載模塊：定時加載活動規則等配置信息，供規則引擎使用。

其中，規則引擎由核心組件構成的最小功能集及擴展組件提供的擴展功能組成。因爲規則引擎解耦了業務規則和系統代碼，使得實時數據在處理時變的抽象，對數據監控、報警提出了更高的要求。下面咱們將從規則引擎核心組件、規則引擎擴展組件、監控與報警三個方面分別進行介紹。

規則引擎核心組件

規則引擎核心組件爲構成規則引擎的最小集合，用以支持完成基礎規則判斷。

規則引擎核心流程

引入規則引擎後，業務需求被轉換爲具體場景和規則進行執行，如圖3所示：

圖3 規則引擎處理流程圖

規則引擎在執行規則過程當中，涉及如下數據模型：

• 場景：業務需求的抽象，一個業務需求對應一個場景，一個場景由若干規則組成。用不一樣的規則組成時序和依賴關係以實現完整的業務需求。
• 規則：規則由規則條件及因子組成，由路由至所屬場景的事件觸發，規則由規則條件、因子及規則響應組成。
• 規則條件：規則條件由因子構成，爲一個布爾表達式。規則條件的執行結果直接決定是否執行規則響應。
• 因子：因子是規則條件的基礎組成部分，按不一樣來源，劃分爲基礎因子、時間窗因子和第三方因子。基礎因子來源於事件，時間窗因子來源於時間窗模塊獲取的時間窗數據，第三方因子來源於第三方服務，如用戶畫像服務等。
• 規則響應：規則執行成功後的動做，如將複合事件下發給運營業務系統，或發送異步事件進行後續規則判斷等。
• 事件：事件爲系統的基礎數據單元，劃分爲同步事件和異步事件兩種類型。同步事件按規則路由後，不調用定時觸達模塊，順序執行；異步事件調用定時觸達模塊，延後執行。

時間窗模塊

時間窗模塊是酒旅運營實時觸達系統規則引擎中的重要構成部分，爲規則引擎提供時間窗因子。時間窗因子可用於統計時間窗口內瀏覽行爲發生的次數、查詢首次下單時間等，表1中列舉了在運營實時觸達活動中須要支持的時間窗因子類型：

類型	示例	因子構成
count	近X分鐘瀏覽POI大於Y次	count(timeWindow(event.id, event.userId, X * 60))
distinct count	近X分鐘瀏覽不一樣POI大於Y次	count(distinct(timeWindow(event.id, event.userId, X * 60)))
first	近X天支付的首單酒店	first(timeWindow(event.id, event.userId, X * 60))
last	近X天最後一次搜索的酒店	last(timeWindow(event.id, event.userId, X * 60))

表1 時間窗因子類型

根據時間窗因子類型能夠看出，時間窗因子有如下特色：

1. 時間窗存儲中須要以List形式保存時間窗詳情數據，以分別支持聚合及詳情需求。
2. 時間窗因子須要天粒度持久化，並支持EXPIRE。
3. 時間窗因子應用場景多，是許多規則的重要組成因子，服務承受的壓力較大，響應時間須要在ms級別。

對於以上特色，在評估使用場景和接入數據量級的基礎上，咱們選擇公司基於Tair研發的KV的存儲服務Cellar存儲時間窗數據，經測試其在20K QPS請求下，TP99能保證在2ms左右，且存儲方面性價比較高，能夠知足系統需求。

在實際運營活動中，對時間窗內用戶某種行爲次數的判斷每每在5次之內，結合此業務場景，同時爲避免Value過大影響讀寫響應時間，在更新時間窗數據時設置閾值，對超出閾值部分進行截斷。時間窗數據更新及截斷流程如圖4所示：

圖4 時間窗數據更新示意圖

文章最前面背景中提到的業務場景，在1. 用戶在30分鐘內發生A行爲次數大於等於3次、3. 用戶在A行爲前24小時內未發生B行爲、4. 用戶在A行爲後30分鐘內未發生B行爲（排除30分鐘內用戶自發產生B行爲的影響，下降對結果形成的誤差）中，均使用了時間窗模塊對滑動時間窗內的用戶行爲進行了統計，以時間窗因子做爲規則執行判斷的依據。

規則引擎擴展組件

規則引擎擴展組件在覈心組件的基礎上，加強規則引擎功能。

自定義函數

自定義函數能夠擴充Aviator功能，規則引擎可經過自定義函數執行因子及規則條件，如調用用戶畫像等第三方服務。系統內爲支持運營需求擴展的部分自定義函數如表2所示：

名稱	示例	含義
equals	equals(message.orderType, 0)	判斷訂單類型是否爲0
filter	filter(browseList, 'source', 'dp')	過濾點評側瀏覽列表數據
poiPortrait	poiPortrait(message.poiId)	根據poiId獲取商戶畫像數據，如商戶星級屬性
userPortrait	userPortrait(message.userId)	根據userId獲取用戶畫像數據，如用戶常住地城市、用戶新老客屬性
userBlackList	userBlackList(message.userId)	根據userId判斷用戶是否爲黑名單用戶

表2 自定義函數示例

文章最前面背景中提到的業務場景，在2. 用戶爲美團酒店老客，即用戶曾購買過美團酒店產品中，判斷用戶是否爲美團酒店老客，就用到了自定義函數，調用用戶畫像服務，經過用戶畫像標籤進行斷定。

定時觸達模塊

定時觸達模塊支持爲規則設定定時執行時間，延後某些規則的執行以知足運營活動規則。文章最前面背景中提到的業務場景，在4. 用戶在A行爲後30分鐘內未發生B行爲（排除30分鐘內用戶自發產生B行爲的影響，下降對結果形成的誤差）條件中，須要在A行爲發生30分鐘後，對用戶是否發生B行爲進行斷定，以排除用戶自發產生B行爲對活動效果形成的影響。

定時觸達模塊涉及的數據流圖如圖5所示：

圖5 定時觸達模塊數據流圖

早期的業務需求對延遲時間要求較短，且活動總數量較小，經過維護純內存DelayQueue的方式，支持定時觸達需求。隨着相關運營活動數量增多及定時觸達時間的延長，純內存方式對內存的佔用量愈來愈大，且在系統重啓後定時數據會所有丟失。在對解決方案進行優化時，瞭解到公司消息中間件組在Mafka消息隊列中支持消息粒度延遲，很是貼合咱們的使用場景，所以採用此特性，代替純內存方式，實現定時觸達模塊。

監控與報警

對比離線數據，實時數據在使用過程當中出現問題不易感知。因爲系統針對的運營活動直接面向C端，在出現系統異常或數據質量異常時，若是沒有及時發現，將會直接形成運營成本浪費，嚴重影響活動轉化率等活動效果評估指標。針對系統穩定性問題，咱們從監控與報警兩個角度入手解決。

監控

利用公司數據平臺現有產品，對系統處理的實時事件按其事件ID上報，以時間粒度聚合，數據上報後可實時查看各種事件量，經過消息量評估活動規則和活動效果是否正常，上報數據展現效果如圖6所示：

圖6 實時事件監控圖

報警

監控只能做爲Dashboard供展現及查看，沒法實現自動化報警。因爲用於監控所上報的聚合數據存儲於時序數據庫OpenTSDB中，咱們基於OpenTSDB開放的HTTP API，定製報警模塊，定時調度、拉取數據，對不一樣事件，按事件量級、活動重要性等指標，應用環比、絕對值等不一樣報警規則及閾值。超出設定閾值後，經過公司IM及時發送報警信息。如圖7所示，該事件環比出現數據量級降低，收到報警後相關負責人可及時跟蹤問題：

圖7 報警信息示意圖

總結與展望

酒旅運營實時觸達系統已上線穩定運行一年多時間，是運營業務中十分重要的環節，起到承上啓下的做用，在系統處理能力及對業務貢獻方面取得了較好的效果：

• 平均日處理實時消息量近10億。
• 峯值事件QPS 1.4萬。
• 幫助酒店、旅遊、大交通等業務線開展了豐富的運營活動。
• 對轉化率、GMV、拉新等指標促進顯著。

當前系統雖然已解決了業務需求，但仍存在一些實際痛點：

• 實時數據接入非自動化。
• 規則引擎能力須要推廣、泛化。
• 場景及規則註冊未對運營PM開放，只能由RD完成。

展望將來，在解決痛點方面咱們還有不少路要走，將來會繼續從技術及業務兩方面入手，將系統建設的更加易用、高效。

做者簡介

曉星，美團平臺技術部－數據中心－數據智能組系統工程師，2014年畢業於北京理工大學，從事Java後臺系統及數據服務建設。2017年加入美團點評，從事大數據處理相關工做。

偉彬，美團平臺技術部－數據中心－數據智能組系統工程師，2015年畢業於大連理工大學，同年加入美團點評，專一於大數據處理技術與高併發服務。

招聘

最後發個廣告，美團平臺技術部－數據中心－數據智能組長期招聘數據挖掘算法、大數據系統開發、Java後臺開發方面的人才，有興趣的同窗能夠發送簡歷到lishangqiang#meituan.com。

若是對咱們團隊感興趣，能夠關注咱們的專欄。