背景

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

大眾點評在精細化運營層面進行了很多深度的思考，我們根據(jù)用戶在App內(nèi)的操作行為的頻次和周期等數(shù)據(jù)，給用戶劃分了不同的生命周期，并且針對用戶所處生命周期，制定了不同的運營策略，比如針對成長期的用戶，主要運營方向是讓其了解平臺的核心功能，提高認知，比如寫點評、分享、收藏等。同時，我們還需要為新激活用戶提供即時激勵，這對時效性的要求很高，從用戶的行為發(fā)生到激勵的下發(fā)，需要在毫秒級別完成，才能有效提升新用戶的留存率。

所以，針對這些精細化的運營場景，我們需要能夠?qū)崟r感知用戶的行為，構(gòu)建用戶的實時畫像。此外，面對大眾點評超大數(shù)據(jù)流量的沖擊，我們還要保證時效性和穩(wěn)定性，這對系統(tǒng)也提出了非常高的要求。在這樣的背景下，我們搭建了一套用戶行為系統(tǒng)（User Action System，以下簡稱UAS）。

面臨的問題

如何實時加工處理海量的用戶行為數(shù)據(jù)，我們面臨以下幾個問題：

上報不規(guī)范 ：點評平臺業(yè)務(wù)繁多，用戶在業(yè)務(wù)上產(chǎn)生的行為分散在四處，格式不統(tǒng)一，有些行為消息是基于自研消息中間件Mafka/Swallow，有些行為消息是基于流量打點的Kafka消息，還有一些行為沒有對應(yīng)的業(yè)務(wù)消息，收集處理工作是一個難點。

上報時效性差 ：目前大部分行為，我們通過后臺業(yè)務(wù)消息方式進行收集，但是部分行為我們通過公司統(tǒng)一的流量打點體系進行收集，但是流量打點收集在一些場景下，無法滿足我們的時效性要求，如何保證收集處理的時效性，我們需要格外關(guān)注。

查詢多樣化 ：收集好行為數(shù)據(jù)之后，各個業(yè)務(wù)對用戶行為的查詢存在差異化，比如對行為次數(shù)的統(tǒng)計，不同業(yè)務(wù)有自己的統(tǒng)計邏輯。無法滿足現(xiàn)有業(yè)務(wù)系統(tǒng)的查詢需求，如何讓系統(tǒng)既統(tǒng)一又靈活？這對我們的業(yè)務(wù)架構(gòu)能力提出了新要求。

針對問題模型，方案思考

格式統(tǒng)一

面對繁雜的格式，我們?nèi)绾芜M行統(tǒng)一？在這里我們參考了5W1H模型，將用戶的行為抽象為以下幾大要素：

其中行為作用的地方，這里一般都是作用對象的ID，比如商戶ID，評論ID等等。 行為的屬性，代表的是行為發(fā)生的一些額外屬性，比如瀏覽商戶的商戶品類、簽到商家的城市等。

上報統(tǒng)一

對于用戶行為的上報，之前的狀態(tài)基本只有基于流量打點的上報，雖然上報的格式較為標準化，但是存在上報延時，數(shù)據(jù)丟失的情況，不能作為主要的上報渠道，因此我們自建了其他的上報渠道，通過維護一個通用的MAPI上報通道，直接從客戶端通過專有的長連接通道進行上報，保證數(shù)據(jù)的時效性，上報后的數(shù)據(jù)處理之后，進行了標準化，再以消息的形式傳播出去，并且按照一定的維度，進行了TOPIC的拆分。目前我們是兩個上報通道在不同場景使用，對外是無感知的。

服務(wù)統(tǒng)一

不同場景下，對用戶行為處理的數(shù)據(jù)規(guī)模要求，時效性要求也是不一樣的，比如有些場景需要在用戶行為上報之后，立刻做相關(guān)的查詢，因此寫入和查詢的性能要求很高，有些場景下，只需要進行行為的寫入，就可以采取異步的方式寫入，針對這樣不同的場景，我們有不同的解決方案，但是我們統(tǒng)一對外提供的還是UAS服務(wù)。

架構(gòu)統(tǒng)一

從數(shù)據(jù)的收集上報，到處理分發(fā)，到業(yè)務(wù)加工，到持久化，UAS系統(tǒng)架構(gòu)需要做到有機的統(tǒng)一，既要能滿足日益增長的數(shù)據(jù)需求，同時也要能夠給業(yè)務(wù)充分的靈活性，起到數(shù)據(jù)中臺的作用，方便各個業(yè)務(wù)基于現(xiàn)有的架構(gòu)上，進行快速靈活的開發(fā)，滿足高速發(fā)展的業(yè)務(wù)。

系統(tǒng)整體架構(gòu)

針對這樣一些想法，開始搭建我們的UAS系統(tǒng)，下圖是UAS系統(tǒng)目前的整體架構(gòu)：

數(shù)據(jù)源簡介

我們處理的數(shù)據(jù)源分為實時數(shù)據(jù)源和離線數(shù)據(jù)源：

實時數(shù)據(jù)源主要分兩塊，一塊是基于客戶端打點上報，另外一塊是我們的后臺消息，這兩部分是基于公司的消息中間件Mafka和開源消息中間件Kafka，以消息的形式上報上來，方便我們后續(xù)的處理，MQ的方式能夠讓系統(tǒng)更好的解耦，并且具備更高的吞吐量，還可以指定消費的起始時間點，做到消息的回溯。

歷史數(shù)據(jù)的來源主要是我們的Hive和HDFS，可以方便的做到大數(shù)據(jù)量的存儲和并行計算。

離線計算簡介

在離線處理這塊，主要包含了MR模塊和Spark模塊，我們的一些ETL操作，就是基于MR模塊的，一些用戶行為數(shù)據(jù)的深度分析，會基于Spark去做，其中我們還有一個XT平臺，是美團點評內(nèi)部基于Hive搭建的ETL平臺，它主要用來開發(fā)數(shù)據(jù)處理任務(wù)和數(shù)據(jù)傳輸任務(wù)，并且可以配置相關(guān)的任務(wù)調(diào)度信息。

實時計算簡介

對于用戶行為的實時數(shù)據(jù)處理，我們使用的是Storm實時大數(shù)據(jù)處理框架，Storm中的Spout可以方便的對接我們的實時消息隊列，在Bolt中處理我們的業(yè)務(wù)邏輯，通過流的形式，可以方便的做到業(yè)務(wù)數(shù)據(jù)的分流、處理、匯聚，并且保持它的時效性。而且Storm也有比較好的心跳檢測機制，在Worker掛了之后，可以做到自動重啟，保證任務(wù)不掛，同時Storm的Acker機制，可以保持我們實時處理的可靠性。

接下來，我們按照用戶行為數(shù)據(jù)的處理和存儲來詳細介紹我們的系統(tǒng)。

數(shù)據(jù)的處理

離線處理

離線數(shù)據(jù)的處理，主要依賴的是我們的數(shù)據(jù)開發(fā)同學(xué)，在構(gòu)建用戶行為的數(shù)據(jù)倉庫時，我們會遵循一套美團點評的數(shù)據(jù)倉庫分層體系。

同時我們會出一些比較通用的數(shù)據(jù)，方便線上用戶使用，比如我們會根據(jù)用戶的行為，發(fā)放勛章獎勵，其中一個勛章的發(fā)放條件是用戶過去30天的瀏覽商戶數(shù)量，我們不會直接出一個30天的聚合數(shù)據(jù)，而是以天為周期，做一次聚合，然后再把30天的數(shù)據(jù)聚合，這樣比較通用靈活一些，上層應(yīng)用可以按照自己的業(yè)務(wù)需求，進行一些其他時間段的聚合。

在數(shù)據(jù)的導(dǎo)入中，我們也有不同的策略：

比如用戶的行為路徑分析中，我們在Hive中計算好的結(jié)果，數(shù)據(jù)量是非常龐大的，但是Hive本身的設(shè)計無法滿足我們的查詢時效性要求，為了后臺系統(tǒng)有比較好的體驗，我們會把數(shù)據(jù)導(dǎo)入到ES中，這里我們無需全量導(dǎo)入，只要抽樣導(dǎo)入即可，這樣在滿足我們的查詢要求的同時也能提高我們的查詢效率。

在導(dǎo)入到一些其他存儲介質(zhì)中，傳輸?shù)男视袝r候會成為我們的瓶頸，比如我們導(dǎo)入到Cellar中，數(shù)據(jù)量大，寫入效率也不高，針對這種情況，我們會采用增量導(dǎo)入的方式，每次導(dǎo)入的數(shù)據(jù)都是有發(fā)生變化的，這樣我們的導(dǎo)入數(shù)據(jù)量會減少，從而減小我們的傳輸耗時。

實時處理

實時處理這塊，我們構(gòu)建了基于點評全網(wǎng)的流量網(wǎng)關(guān)，所有用戶產(chǎn)生的行為數(shù)據(jù)，都會通過實時上報通道進行上報，并且會在我們的網(wǎng)關(guān)中流轉(zhuǎn)，我們在這里對行為數(shù)據(jù)，做一些加工。

Reader

我們目前使用的是Storm的Spout組件對接我們的實時消息，基于抽象的接口，未來可以擴展更多的數(shù)據(jù)來源，比如數(shù)據(jù)庫、文件系統(tǒng)等。

Parser

Parser是我們的解析模塊，主要具備以下功能：

我們會對字段做一些兼容，不同版本的打點數(shù)據(jù)可能會有差異。

JSON串的處理，對于多層的JSON串進行處理，使得后續(xù)可以正常解析。

時間解析，對于不同格式的的上報時間進行兼容統(tǒng)一。

Transformer

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

Sender

Sender是我們的發(fā)送模塊，將處理好的數(shù)據(jù)，按照不同的業(yè)務(wù)數(shù)據(jù)流，進行轉(zhuǎn)發(fā)，一般我們是發(fā)送到消息隊列中，Sender模塊，可以指定發(fā)送的格式、字段名稱等。

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

近實時處理

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

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

數(shù)據(jù)的存儲

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

明細存儲

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

上圖是我們的處理方式:

通過Transformer，業(yè)務(wù)方可以通過自己的服務(wù)，對數(shù)據(jù)的維度進行擴展，從而Sender發(fā)出的Message就是滿足業(yè)務(wù)需求的數(shù)據(jù)。

然后在Kafka2Hive這一步，會去更新對應(yīng)的Hive表結(jié)構(gòu)，支持新的擴展數(shù)據(jù)字段，同時在XT作業(yè)中，可以通過表的關(guān)聯(lián)，把新擴展的字段進行補齊。

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

NoSQL存儲

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

對于冷熱比較分明，單個數(shù)據(jù)不是很大（小于20KB，過大會影響查詢效率），并且value不是復(fù)雜的，我們會使用Cellar，比如一些低頻次的用戶行為數(shù)據(jù)。

在大并發(fā)下，對于延遲要求極為敏感，我們會使用Redis。

對于一些復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，我們會使用到Redis，比如會用到Redis封裝好的HyperLogLog算法，進行數(shù)據(jù)的統(tǒng)計處理。

系統(tǒng)特性

靈活性

構(gòu)建系統(tǒng)的靈活性，可以從以下幾個方面入手：

對用戶的行為數(shù)據(jù)，可以通過Transformer組件進行數(shù)據(jù)擴展，從而滿足業(yè)務(wù)的需求，業(yè)務(wù)只需要開發(fā)一個擴展接口即可。

第二個方面就是查詢，我們支持業(yè)務(wù)方以服務(wù)注冊的方式，去編寫自己的查詢邏輯，或者以插件的形式，托管在UAS平臺，去實現(xiàn)自己負責(zé)的業(yè)務(wù)邏輯，比如同樣一個瀏覽商戶行為，有些業(yè)務(wù)的邏輯是需要看某批用戶最近7天看了多少家3星商戶，并且按照shopID去重，有些業(yè)務(wù)邏輯可能是需要看某批用戶最近7天瀏覽了多少個品類的商戶。因此這些業(yè)務(wù)復(fù)雜的邏輯可以直接托管在我們這里，對外的接口吐出基本是一致的，做到服務(wù)的統(tǒng)一。

我們系統(tǒng)目前從實時分發(fā)/計算/統(tǒng)計/存儲/服務(wù)提供，是一套比較完備的系統(tǒng)，在不同的處理階段，都可以有不同的組件/技術(shù)選型，根據(jù)業(yè)務(wù)的需求，我們可以做到靈活的組合、搭配。

低延時

對于一些跨周期非常長，存儲非常大的數(shù)據(jù)，我們采用了Lambda架構(gòu)，既保證了數(shù)據(jù)的完備性又做到了數(shù)據(jù)的時效性。其中Batch Layer為批處理層，會有固定的計算視圖，對歷史數(shù)據(jù)進行預(yù)計算，生成離線結(jié)果；Speed Layer為實時計算層，對實時數(shù)據(jù)進行計算，生成增量的結(jié)果，最終Server Layer合并兩個視圖的數(shù)據(jù)集，從而來提供服務(wù)。

可用性

數(shù)據(jù)可用性

前面提到了我們采用Lambda架構(gòu)處理一些數(shù)據(jù)，但是離線數(shù)據(jù)有時候會因為上游的一些原因，處理不穩(wěn)定，導(dǎo)致產(chǎn)出延遲，這個時候為了保證數(shù)據(jù)的準確性，我們在Speed Layer會多保留兩天的數(shù)據(jù) ，保證覆蓋到全量數(shù)據(jù)。如圖所示：

服務(wù)的可用性

在服務(wù)的可用性方面，我們對接入的服務(wù)進行了鑒權(quán)，保證服務(wù)的安全可靠，部分核心行為，我們做了物理上的隔離，保證行為數(shù)據(jù)之間不會相互影響，同時接入了公司內(nèi)部基于Docker的容器管理和可伸縮平臺HULK，能做到自動擴容。對于數(shù)據(jù)使用有嚴格權(quán)限審計，并且做了相關(guān)數(shù)據(jù)脫敏工作。

監(jiān)控

從用戶行為數(shù)據(jù)的產(chǎn)生，到收集分發(fā)，到最后的處理，我們都做到了相關(guān)的監(jiān)控，比如因為我們的代碼改動，發(fā)生處理時長變長，我們可以立馬收到相關(guān)的報警，檢查是不是代碼出問題了。或者監(jiān)控到的行為產(chǎn)生次數(shù)和歷史基線比，發(fā)生較大變化，我們也會去追蹤定位問題，甚至可以早于業(yè)務(wù)先發(fā)現(xiàn)相關(guān)問題。下圖是分享商戶行為的一個監(jiān)控：

結(jié)語

用戶行為系統(tǒng)搭建之后，目前：

處理的上報數(shù)據(jù)量日均在45+億。

核心行為的上報延遲從秒級降低到毫秒級。

收錄用戶行為數(shù)十項，提供用戶行為實時流。

提供多維度下的實時服務(wù)，日均調(diào)用量在15億左右，平均響應(yīng)時間在3ms，99線在10ms。

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

未來展望

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

同時，用戶的實時行為會流經(jīng)我們的網(wǎng)關(guān)，我們對用戶行為進行一些特征處理之后，結(jié)合用戶過去的一些畫像數(shù)據(jù)，進行用戶意圖的猜測，這種猜測是可以更加貼近業(yè)務(wù)的。

作者簡介

• 朱凱，資深工程師，2014年加入大眾點評，先后從事過賬號端/商家端的開發(fā)，有著豐富的后臺開發(fā)架構(gòu)經(jīng)驗，同時對實時數(shù)據(jù)處理領(lǐng)域方法有較深入的理解，目前在點評平臺負責(zé)運營業(yè)務(wù)相關(guān)的研發(fā)工作，構(gòu)建精細化運營的底層數(shù)據(jù)驅(qū)動能力，著力提升用戶運營效率。重點打造點評平臺數(shù)據(jù)中臺產(chǎn)品——燈塔。

總結(jié)

以上是生活随笔為你收集整理的UAS-点评侧用户行为检索系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。