背景
隨著整個中國互聯網下半場的到來，用戶紅利所剩無幾，原來粗放式的發展模式已經行不通，企業的發展越來越趨向於精耕細作。美團的價值觀提倡以客戶為中心，面對海量的用戶行為數據，如何利用好這些數據，並通過技術手段發揮出數據的價值，提高用戶的使用體驗，是我們技術團隊未來工作的重點。
大眾點評在精細化運營層面進行了很多深度的思考，我們根據用戶在App內的操作行為的頻次和週期等數據，給用戶劃分了不同的生命週期，並且針對用戶所處生命週期，制定了不同的運營策略，比如針對成長期的用戶，主要運營方向是讓其瞭解平臺的核心功能，提高認知，比如寫點評、分享、收藏等。同時，我們還需要為新激活用戶提供即時激勵，這對時效性的要求很高，從用戶的行為發生到激勵的下發，需要在毫秒級別完成，才能有效提升新用戶的留存率。
所以，針對這些精細化的運營場景，我們需要能夠實時感知用戶的行為，構建用戶的實時畫像。此外，面對大眾點評超大數據流量的衝擊，我們還要保證時效性和穩定性，這對系統也提出了非常高的要求。在這樣的背景下，我們搭建了一套用戶行為系統（User Action System，以下簡稱UAS）。
面臨的問題
如何實時加工處理海量的用戶行為數據，我們面臨以下幾個問題：
- 上報不規範 ：點評平臺業務繁多，用戶在業務上產生的行為分散在四處，格式不統一，有些行為消息是基於自研消息中間件Mafka/Swallow，有些行為消息是基於流量打點的Kafka消息，還有一些行為沒有對應的業務消息，收集處理工作是一個難點。
- 上報時效性差 ：目前大部分行為，我們通過後臺業務消息方式進行收集，但是部分行為我們通過公司統一的流量打點體系進行收集，但是流量打點收集在一些場景下，無法滿足我們的時效性要求，如何保證收集處理的時效性，我們需要格外關注。
- 查詢多樣化 ：收集好行為數據之後，各個業務對用戶行為的查詢存在差異化，比如對行為次數的統計，不同業務有自己的統計邏輯。無法滿足現有業務系統的查詢需求，如何讓系統既統一又靈活？這對我們的業務架構能力提出了新要求。
針對問題模型，方案思考
格式統一
面對繁雜的格式，我們如何進行統一？在這裡我們參考了5W1H模型，將用戶的行為抽象為以下幾大要素：
其中行為作用的地方，這裡一般都是作用對象的ID，比如商戶ID，評論ID等等。行為的屬性，代表的是行為發生的一些額外屬性，比如瀏覽商戶的商戶品類、簽到商家的城市等。
上報統一
對於用戶行為的上報，之前的狀態基本只有基於流量打點的上報，雖然上報的格式較為標準化，但是存在上報延時，數據丟失的情況，不能作為主要的上報渠道，因此我們自建了其他的上報渠道，通過維護一個通用的MAPI上報通道，直接從客戶端通過專有的長連接通道進行上報，保證數據的時效性，上報後的數據處理之後，進行了標準化，再以消息的形式傳播出去，並且按照一定的維度，進行了TOPIC的拆分。目前我們是兩個上報通道在不同場景使用，對外是無感知的。
服務統一
不同場景下，對用戶行為處理的數據規模要求，時效性要求也是不一樣的，比如有些場景需要在用戶行為上報之後，立刻做相關的查詢，因此寫入和查詢的性能要求很高，有些場景下，只需要進行行為的寫入，就可以採取異步的方式寫入，針對這樣不同的場景，我們有不同的解決方案，但是我們統一對外提供的還是UAS服務。
架構統一
從數據的收集上報，到處理分發，到業務加工，到持久化，UAS系統架構需要做到有機的統一，既要能滿足日益增長的數據需求，同時也要能夠給業務充分的靈活性，起到數據中臺的作用，方便各個業務基於現有的架構上，進行快速靈活的開發，滿足高速發展的業務。
系統整體架構
針對這樣的一些想法，開始搭建我們的UAS系統，下圖是UAS系統目前的整體架構：
數據源簡介
我們處理的數據源分為實時數據源和離線數據源：
- 實時數據源主要分兩塊，一塊是基於客戶端打點上報，另外一塊是我們的後臺消息，這兩部分是基於公司的消息中間件Mafka和開源消息中間件Kafka，以消息的形式上報上來，方便我們後續的處理，MQ的方式能夠讓系統更好的解耦，並且具備更高的吞吐量，還可以指定消費的起始時間點，做到消息的回溯。
- 歷史數據的來源主要是我們的Hive和HDFS，可以方便的做到大數據量的存儲和並行計算。
離線計算簡介
在離線處理這塊，主要包含了MR模塊和Spark模塊，我們的一些ETL操作，就是基於MR模塊的，一些用戶行為數據的深度分析，會基於Spark去做，其中我們還有一個XT平臺，是美團點評內部基於Hive搭建的ETL平臺，它主要用來開發數據處理任務和數據傳輸任務，並且配置相關的任務調度信息。
實時計算簡介
對於用戶行為的實時數據處理，我們使用的是Storm實時大數據處理框架，Storm中的Spout可以方便的對接我們的實時消息隊列，在Bolt中處理我們的業務邏輯，通過流的形式，可以方便的做到業務數據的分流、處理、匯聚，並且保持它的時效性。而且Storm也有比較好的心跳檢測機制，在Worker掛了之後，可以做到自動重啟，保證任務不掛，同時Storm的Acker機制，可以保持我們實時處理的可靠性。
接下來，我們按照用戶行為數據的處理和存儲來詳細介紹我們的系統。
數據的處理
離線處理
離線數據的處理，主要依賴的是我們的數據開發同學，在構建用戶行為的數據倉庫時，我們會遵循一套美團點評的數據倉庫分層體系。
同時我們會出一些比較通用的數據，方便線上用戶使用，比如我們會根據用戶的行為，發放勳章獎勵，其中一個勳章的發放條件是用戶過去30天的瀏覽商戶數量，我們不會直接出一個30天的聚合數據，而是以天為週期，做一次聚合，然後再把30天的數據聚合，這樣比較通用靈活一些，上層應用可以按照自己的業務需求，進行一些其他時間段的聚合。
在數據的導入中，我們也有不同的策略：
- 比如用戶的行為路徑分析中，我們在Hive中計算好的結果，數據量是非常龐大的，但是Hive本身的設計無法滿足我們的查詢時效性要求，為了後臺系統有比較好的體驗，我們會把數據導入到ES中，這裡我們無需全量導入，只要抽樣導入即可，這樣在滿足我們的查詢要求的同時也能提高我們的查詢效率。
- 在導入到一些其他存儲介質中，傳輸的效率有時候會成為我們的瓶頸，比如我們導入到Cellar中，數據量大，寫入效率也不高，針對這種情況，我們會採用增量導入的方式，每次導入的數據都是有發生變化的，這樣我們的導入數據量會減少，從而減小我們的傳輸耗時。
實時處理
實時處理這塊，我們構建了基於點評全網的流量網關，所有用戶產生的行為數據，都會通過實時上報通道進行上報，並且會在我們的網關中流轉，我們在這裡對行為數據，做一些加工。
Reader
我們目前使用的是Storm的Spout組件對接我們的實時消息，基於抽象的接口，未來可以擴展更多的數據來源，比如數據庫、文件系統等。
Parser
Parser是我們的解析模塊，主要具備以下功能：
- 我們會對字段做一些兼容，不同版本的打點數據可能會有差異。
- JSON串的處理，對於多層的JSON串進行處理，使得後續可以正常解析。
- 時間解析，對於不同格式的的上報時間進行兼容統一。
Transformer
Transformer是我們的轉換模塊，它是一種更加高級的處理過程，能夠提供給業務進行靈活的行為屬性擴展：
- 比如需要根據商戶ID轉換出商戶的星級、品類等其他信息，我們可以在我們的明細擴展層配置一個Transformer。
- 或者業務有自己的轉換規則，比如他需要把一些字段進行合併、拆分、轉換，都可以通過一個Transformer模塊，解決這個問題。
Sender
Sender是我們的發送模塊，將處理好的數據，按照不同的業務數據流，進行轉發，一般我們是發送到消息隊列中，Sender模塊，可以指定發送的格式、字段名稱等。
目前我們的實時處理，基本上已經做到可視化的配置，之前需要幾人日才能做到的用戶行為數據分發和處理，現在從配置到驗證上線只需要幾分鐘左右。
近實時處理
在近線計算中，我們會把經過流量網關的數據，通過Kafka2Hive的流程，寫入到我們的Hive中，整個過程的時延不超過15分鐘，我們的算法同學，可以利用這樣一些近實時的數據，再結合其他的海量數據，進行整體的加工、存儲，主要針對的是一些時效性要求不高的場景。
通過上面三套處理方法，離線、實時、近實時，我們可以很好的滿足業務不同的時效性需求。
數據的存儲
經過實時處理之後，基本上已經是我們認為的標準化數據，我們會對這些數據進行明細存儲和聚合存儲：
明細存儲
明細的存儲，是為了保證我的數據存儲，能夠滿足業務的查詢需求，這些明細數據，主要是用戶的一些核心操作行為，比如分享、瀏覽、點擊、簽到等，這些數據我們會按照一定的粒度拆分，存儲在不同的搜索集群中，並且有有一定的過期機制。
上圖是我們的處理方式:
- 通過Transformer，業務方可以通過自己的服務，對數據的維度進行擴展，從而Sender發出的Message就是滿足業務需求的數據。
- 然後在Kafka2Hive這一步，會去更新對應的Hive表結構，支持新的擴展數據字段，同時在XT作業中，可以通過表的關聯，把新擴展的字段進行補齊。
- 重跑我們的歷史之後，全量數據就是已經擴展好的字段。同時，實時數據的寫入，也是擴展之後的字段，至此完成了字段的擴展。
NoSQL存儲
通過明細數據的存儲，我們可以解決大部分問題。雖然搜索支持的查詢方式比較靈活，但是某些情況下，查詢效率會較慢，平均響應時間在20ms左右，對一些高性能的場景，或者一些基礎的用戶行為畫像，這個響應時間顯然是偏高的。因此我們引入了NoSQL的存儲，使用公司的存儲中間件Squirrel和Cellar，其中Cellar是基於淘寶開源的Tair進行開發的，而Squirrel是基於RedisCluster進行開發的，兩者的差異就不在此贅述，簡單講一下我們的使用場景：
- 對於冷熱比較分明，單個數據不是很大（小於20KB，過大會影響查詢效率），並且value不是複雜的，我們會使用Cellar，比如一些低頻次的用戶行為數據。
- 在大併發下，對於延遲要求極為敏感，我們會使用Redis。
- 對於一些複雜的數據結構，我們會使用到Redis，比如我們會用到Redis封裝好的HyperLogLog算法，進行數據的統計處理。
系統特性
靈活性
構建系統的靈活性，可以從以下幾個方面入手：
- 對用戶的行為數據，可以通過Transformer組件進行數據擴展，從而滿足業務的需求，業務只需要開發一個擴展接口即可。
- 第二個方面就是查詢，我們支持業務方以服務註冊的方式，去編寫自己的查詢邏輯，或者以插件的形式，託管在UAS平臺，去實現自己負責的業務邏輯，比如同樣一個瀏覽商戶行為，有些業務的邏輯是需要看某批用戶最近7天看了多少家3星商戶，並且按照shopID去重，有些業務邏輯可能是需要看某批用戶最近7天瀏覽了多少個品類的商戶。因此這些業務複雜的邏輯可以直接託管在我們這裡，對外的接口吐出基本是一致的，做到服務的統一。
- 我們系統目前從實時分發/計算/統計/存儲/服務提供，是一套比較完備的系統，在不同的處理階段，都可以有不同的組件/技術選型，根據業務的需求，我們可以做到靈活的組合、搭配。
低延時
對於一些跨週期非常長，存儲非常大的數據，我們採用了Lambda架構，既保證了數據的完備性又做到了數據的時效性。其中Batch Layer為批處理層，會有固定的計算視圖，對歷史數據進行預計算，生成離線結果；Speed Layer為實時計算層，對實時數據進行計算，生成增量的結果，最終Server Layer合併兩個視圖的數據集，從而來提供服務。
可用性
數據可用性
前面提到了我們採用Lambda架構處理一些數據，但是離線數據有時候會因為上游的一些原因，處理不穩定，導致產出延遲，這個時候為了保證數據的準確性，我們在Speed Layer會多保留兩天的數據 ，保證覆蓋到全量數據。如圖所示：
服務的可用性
在服務的可用性方面，我們對接入的服務進行了鑑權，保證服務的安全可靠，部分核心行為，我們做了物理上的隔離，保證行為數據之間不會相互影響，同時接入了公司內部基於Docker的容器管理和可伸縮平臺HULK， 能做到自動擴容。對於數據使用有嚴格權限審計，並且做了相關數據脫敏工作。
監控
從用戶行為數據的產生，到收集分發，到最後的處理，我們都做到了相關的監控，比如因為代碼改動，發生處理時長變長，我們可以立馬收到相關的報警，檢查是不是代碼出問題了。或者監控到的行為產生次數和歷史基線比，發生較大變化，我們也會去追蹤定位問題，甚至可以早於業務先發現相關問題。下圖是分享商戶行為的一個監控：
結語
用戶行為系統搭建之後，目前：
- 處理的上報數據量日均在45+億。
- 核心行為的上報延遲從秒級降低到毫秒級。
- 收錄用戶行為數十項，提供用戶行為實時流。
- 提供多維度下的實時服務，日均調用量在15億左右，平均響應時間在3ms，99線在10ms。
目前系統承載的業務還在不斷增長中，相比以前的T+1服務延時，大大提升了用戶體驗。我們希望構建用戶行為的中臺系統，通過我們已經抽象出的基礎能力，解決業務80%的問題，業務可以通過插件或者接口的形式，在我們的中臺上解決自己個性化的問題。
未來展望
目前我們的實時計算視圖，比較簡單，做的是相對比較通用的聚合計算，但是業務的聚合規則可能是比較複雜且多變的，不一定是直接累加，未來我們希望在聚合計算這塊，也能直接通過配置的方式，得到業務自定義的聚合數據，快速滿足線上業務需求。
同時，用戶的實時行為會流經我們的網關，我們對用戶行為進行一些特徵處理之後，結合用戶過去的一些畫像數據，進行用戶意圖的猜測，這種猜測是可以更加貼近業務的。
朱凱，資深工程師，2014年加入大眾點評，先後從事過賬號端/商家端的開發，有著豐富的後臺開發架構經驗，同時對實時數據處理領域方法有較深入的理解。目前在點評平臺負責運營業務相關的研發工作，構建精細化運營的底層數據驅動能力，著力提升用戶運營效率。
活動推薦
《美團技術沙龍第39期·上海：新思路打造移動端高效研發體系》7月21日週六下午，大家期待已久的上海場活動來啦，美團點評上海移動研發團隊，解密移動前後端的高效研發體系。更多活動詳情請戳>>活動報名鏈接
閱讀更多 美團技術團隊 的文章
