UAS-點評側用戶行爲檢索系統

背景

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

大衆點評在精細化運營層面進行了不少深度的思考，咱們根據用戶在App內的操做行爲的頻次和週期等數據，給用戶劃分了不一樣的生命週期，而且針對用戶所處生命週期，制定了不一樣的運營策略，好比針對成長期的用戶，主要運營方向是讓其瞭解平臺的核心功能，提升認知，好比寫點評、分享、收藏等。同時，咱們還須要爲新激活用戶提供即時激勵，這對時效性的要求很高，從用戶的行爲發生到激勵的下發，須要在毫秒級別完成，纔能有效提高新用戶的留存率。

因此，針對這些精細化的運營場景，咱們須要可以實時感知用戶的行爲，構建用戶的實時畫像。此外，面對大衆點評超大數據流量的衝擊，咱們還要保證時效性和穩定性，這對系統也提出了很是高的要求。在這樣的背景下，咱們搭建了一套用戶行爲系統（User Action System，如下簡稱UAS）。

面臨的問題

如何實時加工處理海量的用戶行爲數據，咱們面臨如下幾個問題：

1. 上報不規範 ：點評平臺業務繁多，用戶在業務上產生的行爲分散在四處，格式不統一，有些行爲消息是基於自研消息中間件Mafka/Swallow，有些行爲消息是基於流量打點的Kafka消息，還有一些行爲沒有對應的業務消息，收集處理工做是一個難點。

2. 上報時效性差 ：目前大部分行爲，咱們經過後臺業務消息方式進行收集，可是部分行爲咱們經過公司統一的流量打點體系進行收集，可是流量打點收集在一些場景下，沒法知足咱們的時效性要求，如何保證收集處理的時效性，咱們須要格外關注。

3. 查詢多樣化 ：收集好行爲數據以後，各個業務對用戶行爲的查詢存在差別化，好比對行爲次數的統計，不一樣業務有本身的統計邏輯。沒法知足現有業務系統的查詢需求，如何讓系統既統一又靈活？這對咱們的業務架構能力提出了新要求。

針對問題模型，方案思考

格式統一

面對繁雜的格式，咱們如何進行統一？在這裏咱們參考了5W1H模型，將用戶的行爲抽象爲如下幾大要素：

其中行爲做用的地方，這裏通常都是做用對象的ID，好比商戶ID，評論ID等等。 行爲的屬性，表明的是行爲發生的一些額外屬性，好比瀏覽商戶的商戶品類、簽到商家的城市等。

上報統一

對於用戶行爲的上報，以前的狀態基本只有基於流量打點的上報，雖然上報的格式較爲標準化，可是存在上報延時，數據丟失的狀況，不能做爲主要的上報渠道，所以咱們自建了其餘的上報渠道，經過維護一個通用的MAPI上報通道，直接從客戶端經過專有的長鏈接通道進行上報，保證數據的時效性，上報後的數據處理以後，進行了標準化，再以消息的形式傳播出去，而且按照必定的維度，進行了TOPIC的拆分。目前咱們是兩個上報通道在不一樣場景使用，對外是無感知的。

服務統一

不一樣場景下，對用戶行爲處理的數據規模要求，時效性要求也是不同的，好比有些場景須要在用戶行爲上報以後，馬上作相關的查詢，所以寫入和查詢的性能要求很高，有些場景下，只須要進行行爲的寫入，就能夠採起異步的方式寫入，針對這樣不一樣的場景，咱們有不一樣的解決方案，可是咱們統一對外提供的仍是UAS服務。

架構統一

從數據的收集上報，處處理分發，到業務加工，到持久化，UAS系統架構須要作到有機的統一，既要能知足日益增加的數據需求，同時也要可以給業務充分的靈活性，起到數據中臺的做用，方便各個業務基於現有的架構上，進行快速靈活的開發，知足高速發展的業務。

系統總體架構

針對這樣一些想法，開始搭建咱們的UAS系統，下圖是UAS系統目前的總體架構：

數據源簡介

咱們處理的數據源分爲實時數據源和離線數據源：

1. 實時數據源主要分兩塊，一塊是基於客戶端打點上報，另一塊是咱們的後臺消息，這兩部分是基於公司的消息中間件Mafka和開源消息中間件Kafka，以消息的形式上報上來，方便咱們後續的處理，MQ的方式可以讓系統更好的解耦，而且具有更高的吞吐量，還能夠指定消費的起始時間點，作到消息的回溯。

2. 歷史數據的來源主要是咱們的Hive和HDFS，能夠方便的作到大數據量的存儲和並行計算。

離線計算簡介

在離線處理這塊，主要包含了MR模塊和Spark模塊，咱們的一些ETL操做，就是基於MR模塊的，一些用戶行爲數據的深度分析，會基於Spark去作，其中咱們還有一個XT平臺，是美團點評內部基於Hive搭建的ETL平臺，它主要用來開發數據處理任務和數據傳輸任務，而且能夠配置相關的任務調度信息。

實時計算簡介

對於用戶行爲的實時數據處理，咱們使用的是Storm實時大數據處理框架，Storm中的Spout能夠方便的對接咱們的實時消息隊列，在Bolt中處理咱們的業務邏輯，經過流的形式，能夠方便的作到業務數據的分流、處理、匯聚，而且保持它的時效性。並且Storm也有比較好的心跳檢測機制，在Worker掛了以後，能夠作到自動重啓，保證任務不掛，同時Storm的Acker機制，能夠保持咱們實時處理的可靠性。

接下來，咱們按照用戶行爲數據的處理和存儲來詳細介紹咱們的系統：

數據的處理

離線處理

離線數據的處理，主要依賴的是咱們的數據開發同窗，在構建用戶行爲的數據倉庫時，咱們會遵循一套美團點評的數據倉庫分層體系。

同時咱們會出一些比較通用的數據，方便線上用戶使用，好比咱們會根據用戶的行爲，發放勳章獎勵，其中一個勳章的發放條件是用戶過去30天的瀏覽商戶數量，咱們不會直接出一個30天的聚合數據，而是以天爲週期，作一次聚合，而後再把30天的數據聚合，這樣比較通用靈活一些，上層應用能夠按照本身的業務需求，進行一些其餘時間段的聚合。

在數據的導入中，咱們也有不一樣的策略：

1. 好比用戶的行爲路徑分析中，咱們在Hive中計算好的結果，數據量是很是龐大的，可是Hive自己的設計沒法知足咱們的查詢時效性要求，爲了後臺系統有比較好的體驗，咱們會把數據導入到ES中，這裏咱們無需全量導入，只要抽樣導入便可，這樣在知足咱們的查詢要求的同時也能提升咱們的查詢效率。

2. 在導入到一些其餘存儲介質中，傳輸的效率有時候會成爲咱們的瓶頸，好比咱們導入到Cellar中，數據量大，寫入效率也不高，針對這種狀況，咱們會採用增量導入的方式，每次導入的數據都是有發生變化的，這樣咱們的導入數據量會減小，從而減少咱們的傳輸耗時。

實時處理

實時處理這塊，咱們構建了基於點評全網的流量網關，全部用戶產生的行爲數據，都會經過實時上報通道進行上報，而且會在咱們的網關中流轉，咱們在這裏對行爲數據，作一些加工。

Reader

咱們目前使用的是Storm的Spout組件對接咱們的實時消息，基於抽象的接口，將來能夠擴展更多的數據來源，好比數據庫、文件系統等。

Parser

Parser是咱們的解析模塊，主要具有如下功能：

1. 咱們會對字段作一些兼容，不一樣版本的打點數據可能會有差別。
2. JSON串的處理，對於多層的JSON串進行處理，使得後續能夠正常解析。
3. 時間解析，對於不一樣格式的的上報時間進行兼容統一。

Transformer

Transformer是咱們的轉換模塊，它是一種更加高級的處理過程，可以提供給業務進行靈活的行爲屬性擴展：

1. 好比須要根據商戶ID轉換出商戶的星級、品類等其餘信息，咱們能夠在咱們的明細擴展層配置一個Transformer。
2. 或者業務有本身的轉換規則，好比他須要把一些字段進行合併、拆分、轉換，均可以經過一個Transformer模塊，解決這個問題。

Sender

Sender是咱們的發送模塊，將處理好的數據，按照不一樣的業務數據流，進行轉發，通常咱們是發送到消息隊列中，Sender模塊，能夠指定發送的格式、字段名稱等。

目前咱們的實時處理，基本上已經作到可視化的配置，以前須要幾人日才能作到的用戶行爲數據分發和處理，如今從配置到驗證上線只須要幾分鐘左右。

近實時處理

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

經過上面三套處理方法，離線、實時、近實時，咱們能夠很好的知足業務不一樣的時效性需求。

數據的存儲

通過實時處理以後，基本上已是咱們認爲的標準化數據，咱們會對這些數據進行明細存儲和聚合存儲：

明細存儲

明細的存儲，是爲了保證咱們的數據存儲，可以知足業務的查詢需求，這些明細數據，主要是用戶的一些核心操做行爲，好比分享、瀏覽、點擊、簽到等，這些數據咱們會按照必定的粒度拆分，存儲在不一樣的搜索集羣中，而且有必定的過時機制。

上圖是咱們的處理方式:

1. 經過Transformer，業務方能夠經過本身的服務，對數據的維度進行擴展，從而Sender發出的Message就是知足業務需求的數據。
2. 而後在Kafka2Hive這一步，會去更新對應的Hive表結構，支持新的擴展數據字段，同時在XT做業中，能夠經過表的關聯，把新擴展的字段進行補齊。
3. 重跑咱們的歷史以後，咱們的全量數據就是已經擴展好的字段。同時，咱們的實時數據的寫入，也是擴展以後的字段，至此完成了字段的擴展。

NoSQL存儲

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

1. 對於冷熱比較分明，單個數據不是很大（小於20KB，過大會影響查詢效率），而且value不是複雜的，咱們會使用Cellar，好比一些低頻次的用戶行爲數據。
2. 在大併發下，對於延遲要求極爲敏感，咱們會使用Redis。
3. 對於一些複雜的數據結構，咱們會使用到Redis，好比會用到Redis封裝好的HyperLogLog算法，進行數據的統計處理。

系統特性

靈活性

構建系統的靈活性，能夠從如下幾個方面入手：

1. 對用戶的行爲數據，能夠經過Transformer組件進行數據擴展，從而知足業務的需求，業務只須要開發一個擴展接口便可。
2. 第二個方面就是查詢，咱們支持業務方以服務註冊的方式，去編寫本身的查詢邏輯，或者以插件的形式，託管在UAS平臺，去實現本身負責的業務邏輯，好比一樣一個瀏覽商戶行爲，有些業務的邏輯是須要看某批用戶最近7天看了多少家3星商戶，而且按照shopID去重，有些業務邏輯多是須要看某批用戶最近7天瀏覽了多少個品類的商戶。所以這些業務複雜的邏輯能夠直接託管在咱們這裏，對外的接口吐出基本是一致的，作到服務的統一。
3. 咱們系統目前從實時分發/計算/統計/存儲/服務提供，是一套比較完備的系統，在不一樣的處理階段，均可以有不一樣的組件/技術選型，根據業務的需求，咱們能夠作到靈活的組合、搭配。

低延時

對於一些跨週期很是長，存儲很是大的數據，咱們採用了Lambda架構，既保證了數據的完備性又作到了數據的時效性。其中Batch Layer爲批處理層，會有固定的計算視圖，對歷史數據進行預計算，生成離線結果；Speed Layer爲實時計算層，對實時數據進行計算，生成增量的結果，最終Server Layer合併兩個視圖的數據集，從而來提供服務。

可用性

數據可用性

前面提到了咱們採用Lambda架構處理一些數據，可是離線數據有時候會由於上游的一些緣由，處理不穩定，致使產出延遲，這個時候爲了保證數據的準確性，咱們在Speed Layer會多保留兩天的數據 ，保證覆蓋到全量數據。如圖所示：

服務的可用性

在服務的可用性方面，咱們對接入的服務進行了鑑權，保證服務的安全可靠，部分核心行爲，咱們作了物理上的隔離，保證行爲數據之間不會相互影響，同時接入了公司內部基於Docker的容器管理和可伸縮平臺HULK，能作到自動擴容。對於數據使用有嚴格權限審計，而且作了相關數據脫敏工做。

監控

從用戶行爲數據的產生，到收集分發，到最後的處理，咱們都作到了相關的監控，好比由於咱們的代碼改動，發生處理時長變長，咱們能夠立馬收到相關的報警，檢查是否是代碼出問題了。或者監控到的行爲產生次數和歷史基線比，發生較大變化，咱們也會去追蹤定位問題，甚至能夠早於業務先發現相關問題。下圖是分享商戶行爲的一個監控：

結語

用戶行爲系統搭建以後，目前：

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

目前系統承載的業務還在不斷增加中，相比之前的T+1服務延時，大大提高了用戶體驗。咱們但願構建用戶行爲的中臺系統，經過咱們已經抽象出的基礎能力，解決業務80%的問題，業務能夠經過插件或者接口的形式，在咱們的中臺上解決本身個性化的問題。

將來展望

目前咱們的實時計算視圖，比較簡單，作的是相對比較通用的聚合計算，可是業務的聚合規則多是比較複雜且多變的，不必定是直接累加，將來咱們但願在聚合計算這塊，也能直接經過配置的方式，獲得業務自定義的聚合數據，快速知足線上業務需求。

同時，用戶的實時行爲會流經咱們的網關，咱們對用戶行爲進行一些特徵處理以後，結合用戶過去的一些畫像數據，進行用戶意圖的猜想，這種猜想是能夠更加貼近業務的。

做者簡介

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