背景

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

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

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

面臨的問題

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

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

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

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

針對問題模型，方案思考

格式統(tǒng)一

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

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

上報(bào)統(tǒng)一

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

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

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

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

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

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

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

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

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

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

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

離線計(jì)算簡介

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

實(shí)時(shí)計(jì)算簡介

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

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

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

離線處理

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

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

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

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

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

實(shí)時(shí)處理

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

Reader

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

Parser

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

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

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

時(shí)間解析，對于不同格式的的上報(bào)時(shí)間進(jìn)行兼容統(tǒng)一。

Transformer

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

Sender

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

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

近實(shí)時(shí)處理

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

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

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

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

明細(xì)存儲

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

上圖是我們的處理方式:

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

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

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

NoSQL存儲

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

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

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

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

系統(tǒng)特性

靈活性

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

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

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

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

低延時(shí)

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

可用性

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

前面提到了我們采用Lambda架構(gòu)處理一些數(shù)據(jù)，但是離線數(shù)據(jù)有時(shí)候會因?yàn)樯嫌蔚囊恍┰?#xff0c;處理不穩(wěn)定，導(dǎo)致產(chǎn)出延遲，這個(gè)時(shí)候?yàn)榱吮ＷC數(shù)據(jù)的準(zhǔn)確性，我們在Speed Layer會多保留兩天的數(shù)據(jù) ，保證覆蓋到全量數(shù)據(jù)。如圖所示：

服務(wù)的可用性

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

監(jiān)控

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

結(jié)語

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

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

核心行為的上報(bào)延遲從秒級降低到毫秒級。

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

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

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

未來展望

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

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

作者簡介

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

總結(jié)

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

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