背景

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

大眾點評在精細化運營層面進行了很多深度的思考，我們根據使用者在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. 收錄使用者行為數十項，提供使用者行為實時流。
5. 提供多維度下的實時服務，日均呼叫量在15億左右，平均響應時間在3ms，99線在10ms。

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

未來展望

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

同時，使用者的實時行為會流經我們的閘道器，我們對使用者行為進行一些特徵處理之後，結合使用者過去的一些畫像資料，進行使用者意圖的猜測，這種猜測是可以更加貼近業務的。

作者簡介

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