背景
美團點評酒旅運營需求在離線場景下，已經得到了較為系統化的支持，通過對離線數據收集、挖掘，可對目標用戶進行T+1觸達，通過向目標用戶發送Push等多種方式，在一定程度上提高轉化率。但T+1本身的延遲性會導致用戶在產生特定行為時不能被實時觸達，無法充分發揮數據的價值，取得更優的運營效果。
在此背景下，運營業務需要著手挖掘用戶行為實時數據，如實時瀏覽、下單、退款、搜索等，對滿足運營需求用戶進行實時觸達，最大化運營活動效果。
業務場景
在運營實時觸達需求中，存在如下具有代表性的業務場景：
用戶在30分鐘內發生A行為次數大於等於3次
用戶為美團酒店老客，即用戶曾購買過美團酒店產品
用戶在A行為前24小時內未發生B行為
用戶在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 時間窗因子類型
根據時間窗因子類型可以看出，時間窗因子有以下特點：
時間窗存儲中需要以List形式保存時間窗詳情數據，以分別支持聚合及詳情需求。
時間窗因子需要天粒度持久化，並支持EXPIRE。
時間窗因子應用場景多，是許多規則的重要組成因子，服務承受的壓力較大，響應時間需要在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。閱讀更多 美團技術團隊 的文章
