UAS：大眾點評用戶行為系統

背景

隨著整個中國互聯網下半場的到來，用戶紅利所剩無幾，原來粗放式的發展模式已經行不通，企業的發展越來越趨向于精耕細作。美團的價值觀提倡以客戶為中心，面對海量的用戶行為數據，如何利用好這些數據，并通過技術手段發揮出數據的價值，提高用戶的使用體驗，是我們技術團隊未來工作的重點。

大眾點評在精細化運營層面進行了很多深度的思考，我們根據用戶在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是我們的解析模塊，主要具備以下功能：
1. 我們會對字段做一些兼容，不同版本的打點數據可能會有差異。
2. JSON串的處理，對于多層的JSON串進行處理，使得后續可以正常解析。
3. 時間解析，對于不同格式的的上報時間進行兼容統一。

Transformer

Transformer是我們的轉換模塊，它是一種更加高級的處理過程，能夠提供給業務進行靈活的行為屬性擴展：
1. 比如需要根據商戶ID轉換出商戶的星級、品類等其他信息，我們可以在我們的明細擴展層配置一個Transformer。
2. 或者業務有自己的轉換規則，比如他需要把一些字段進行合并、拆分、轉換，都可以通過一個Transformer模塊，解決這個問題。

Sender

Sender是我們的發送模塊，將處理好的數據，按照不同的業務數據流，進行轉發，一般我們是發送到消息隊列中，Sender模塊，可以指定發送的格式、字段名稱等。

目前我們的實時處理，基本上已經做到可視化的配置，之前需要幾人日才能做到的用戶行為數據分發和處理，現在從配置到驗證上線只需要幾分鐘左右。

近實時處理

在近線計算中，我們會把經過流量網關的數據，通過Kafka2Hive的流程，寫入到我們的Hive中，整個過程的時延不超過15分鐘，我們的算法同學，可以利用這樣一些近實時的數據，再結合其他的海量數據，進行整體的加工、存儲，主要針對的是一些時效性要求不高的場景。

通過上面三套處理方法，離線、實時、近實時，我們可以很好的滿足業務不同的時效性需求。

數據的存儲

經過實時處理之后，基本上已經是我們認為的標準化數據，我們會對這些數據進行明細存儲和聚合存儲：

明細存儲

明細的存儲，是為了保證我們的數據存儲，能夠滿足業務的查詢需求，這些明細數據，主要是用戶的一些核心操作行為，比如分享、瀏覽、點擊、簽到等，這些數據我們會按照一定的粒度拆分，存儲在不同的搜索集群中，并且有一定的過期機制。

上圖是我們的處理方式:

通過Transformer，業務方可以通過自己的服務，對數據的維度進行擴展，從而Sender發出的Message就是滿足業務需求的數據。

然后在Kafka2Hive這一步，會去更新對應的Hive表結構，支持新的擴展數據字段，同時在XT作業中，可以通過表的關聯，把新擴展的字段進行補齊。

重跑我們的歷史之后，我們的全量數據就是已經擴展好的字段。同時，我們的實時數據的寫入，也是擴展之后的字段，至此完成了字段的擴展。

NoSQL存儲

通過明細數據的存儲，我們可以解決大部分問題。雖然搜索支持的查詢方式比較靈活，但是某些情況下，查詢效率會較慢，平均響應時間在20ms左右，對一些高性能的場景，或者一些基礎的用戶行為畫像，這個響應時間顯然是偏高的。因此我們引入了NoSQL的存儲，使用公司的存儲中間件Squirrel和Cellar，其中Cellar是基于淘寶開源的Tair進行開發的，而Squirrel是基于Redis-cluster進行開發的，兩者的差異就不在此贅述，簡單講一下我們的使用場景：

對于冷熱比較分明，單個數據不是很大（小于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，能做到自動擴容。對于數據使用有嚴格權限審計，并且做了相關數據脫敏工作。

監控

從用戶行為數據的產生，到收集分發，到最后的處理，我們都做到了相關的監控，比如因為我們的代碼改動，發生處理時長變長，我們可以立馬收到相關的報警，檢查是不是代碼出問題了?；蛘弑O控到的行為產生次數和歷史基線比，發生較大變化，我們也會去追蹤定位問題，甚至可以早于業務先發現相關問題。下圖是分享商戶行為的一個監控：

結語

用戶行為系統搭建之后，目前：
1. 處理的上報數據量日均在45+億。
2. 核心行為的上報延遲從秒級降低到毫秒級。
3. 收錄用戶行為數十項，提供用戶行為實時流。
5. 提供多維度下的實時服務，日均調用量在15億左右，平均響應時間在3ms，99線在10ms。

目前系統承載的業務還在不斷增長中，相比以前的T+1服務延時，大大提升了用戶體驗。我們希望構建用戶行為的中臺系統，通過我們已經抽象出的基礎能力，解決業務80%的問題，業務可以通過插件或者接口的形式，在我們的中臺上解決自己個性化的問題。

未來展望

目前我們的實時計算視圖，比較簡單，做的是相對比較通用的聚合計算，但是業務的聚合規則可能是比較復雜且多變的，不一定是直接累加，未來我們希望在聚合計算這塊，也能直接通過配置的方式，得到業務自定義的聚合數據，快速滿足線上業務需求。

同時，用戶的實時行為會流經我們的網關，我們對用戶行為進行一些特征處理之后，結合用戶過去的一些畫像數據，進行用戶意圖的猜測，這種猜測是可以更加貼近業務的。

作者簡介

朱凱，資深工程師，2014年加入大眾點評，先后從事過賬號端/商家端的開發，有著豐富的后臺開發架構經驗，同時對實時數據處理領域方法有較深入的理解，目前在點評平臺負責運營業務相關的研發工作，構建精細化運營的底層數據驅動能力，著力提升用戶運營效率。重點打造點評平臺數據中臺產品——燈塔。