背景

新美大平臺作為業內最大的O2O的平臺，以短信/push作為運營手段觸達用戶的量級巨大，每日數以千萬計。

美團點評線上存在超過千萬的POI，覆蓋超過2000城市、2.5萬個后臺商圈。在海量數據存在的前提下，實時投放的用戶在場景的選擇上存在一些困難，所以我們提供對場景的顆粒化查詢和智能建議，為用戶解決三大難題：

• 我要投放的區域在哪，實時和歷史的客流量是什么樣的？
• 在我希望投放的區域歷史和現在都發生過什么活動，效果是什么樣的？
• 這個區域是不是適合我投放，系統建議我投放哪里？

如圖1所示，整個產品致力于解決以上三大問題，能夠為運營在活動投放前期，提供有效的參考決策依據。

圖1 場景查詢器模塊效果圖

挑戰

• 場景查詢器需要展示的數據分為多種，所以數據過濾和組裝的時間，嚴重依賴于基礎數據量。但是隨著維度的下鉆，基礎數據量巨大，所以導致實時計算數據的響應時間無法忍受。
• 數據來源均是RPC服務，需要調用的服務多種多樣，每一項服務的響應時間都會影響最終的結果返回，難以提供前端接口的響應時間。
• 需要組裝的數據各種各樣，沒有統一的數據模型，造成代碼耦合度高，后期難以維護針對上面的挑戰，我們給出如下的解決方案。

總體方案

圖2 場景查詢器體系架構

如圖2所示，我們的總體架構是分層設計的，最底層都是各類服務，再上層是預計算層和數據層，預計算層的作用很明顯，是連接服務和數據的核心層，通過拉取后臺服務的各類數據然后預計算形成數據層。再往上是中臺服務層，包含有核心功能是服務熔斷降級，以及通用服務，為具體業務邏輯提供統一的服務，最上層便是具體的業務邏輯了，對應具體場景和需求。

后臺服務層

該層均是Thrift的RPC服務，提供各種投放的反饋數據。

數據組裝

后臺服務層數據特點是數據分散，結果多樣。數據組裝是對多個服務調用返回的結果，進行過濾組合。

圖3 后臺服務結果數據組裝樣例

如圖3所示，服務1、2、3分別用黃色、藍色、棕色表示，A 、B、C均是調用對應服務返回的數據，并且A、B的數據格式是列表，C是單個數據。最后一個虛線框，代表數據組裝算法，A和B的列表取交集，結果是長度為2的列表，然后再依次調用服務3，單個獲取數據C。

數據組裝痛點

• 過程繁瑣，如取交集，單個組裝等等，組裝時間受數據量影響較大。
• 組裝過程中，混合著大量的服務調用，組裝時間受服務響應時間影響較大。

后臺服務層重點在于提供數據，保證服務的可用性。但是在組裝過程中遇到以上痛點，導致出現請求響應時間長，用戶體驗差等問題。規避此類問題的主要方法是將服務調用數據提前組合計算好進行存儲，即數據預計算。

預計算層

主要作用在于提前計算數據，快速響應請求，構建過程依次為數據建模、構建計算模式。該層主要包含以下核心功能。

• 構建通用的數據模型，使上層控制和處理，更加高效。
• 保證計算速度的同時，計算大量基礎數據。
• 為了保證數據的實時性，實現高密度并行計算。

數據模型

圖4 預計算數據模型

在場景查詢器中，為前端提供的數據普遍都是上下級數據，比如頁面要展示全國匯總數據，同時會級聯展示下屬各省數據，如果展示省級匯總數據，那么同時級聯展示下屬各地級市數據。通過分析業務需求，發現需要的數據，大多是分上下級的這種級聯數據。經過抽象，數據模型設計為樹形結構，如圖4，左側為概念模型，樹的高度只有兩層，根節點為匯總數據，葉子節點為地理等級維度下鉆的數據；右側為實際使用的模型，因為底層維度的基數比較大，不利于下級數據的遍歷、篩選和分頁，所以實際使用中，下級節點數據以一個列表存儲。節點可以存儲若干指標，具體類型根據地理維度而定。該模型的特點如下：首先支持地理維度繼續下鉆，其次在后臺服務支持的情況下，可以對歷史數據做預計算。

數據存儲和獲取

有了數據模型，需要確定一個高效的數據存儲和數據定位的方式，因為結果數據大多是非半結構化數據，而且低維度的的數據量數據量較大，所以采用NoSQL來存儲數據。

圖5 數據存儲和提取方式示意圖

如圖5所示，ID表示地理維度值，level表示地理維度等級，數據節點（包含根和葉子節點）以ID+level為Key，轉化為樹形JSON格式數據存儲，通過ID+level可以唯一獲取到一個數據，在數據量不大的情況下，還可以通過級聯獲取下級模型，即圖中虛線代表級聯獲取下級數據。

計算模式

在構建的數據模型基礎上，該層最核心便是預計算模式，從業務需求出發，數據需要在地理等級這個維度不斷下鉆，從全國開始，一直下鉆到POI級別，每個級別單獨分層計算，然后存儲計算結果。

圖6 預計算模式示意圖

如圖6所示，每一個矩形代表一級維度的計算，從左到右依次進行維度下鉆，從全國的數據依次計算到商圈，計算分層每層單獨計算。

實現方式

圖7 層序計算示意圖

如圖7所示，是計算模式的兩種實現方式，上半部分是串行層序計算，下半部分是并行層序計算。每部分從上到下分不同顏色區分不同的計算層次。每個矩形對應一個具體ID的計算，t代表計算時間，這里假設所有計算單元的計算時間都相同，方便對比計算時間。

1）串行層序計算

如圖7，普通的串行計算，使用單線程計算，從上到下一層一層計算，這類計算的的痛點有兩處，第一，是時間復雜度的，每個計算單元的計算時間都會累計，如計算第一層的時間為3t，第二層為4t，第三層為6*t，總計耗時13t。第二，是空間復雜度的，因為數據均是調用后臺服務獲取，計算一層的同時，需要把下級的數據都存儲起來，在計算下層時候，再遍歷數據計算。

2）并行層序計算

依賴于Apache Storm計算框架，將數據抽象成為流，然后通過不同的Bolt，分別計算不同維度的數據。每一級Bolt首先處理數據，然后將下級數據流入下一級Bolt。同時隨著維度的下鉆，計算的數據量變得越來越大，通過增加Bolt的并發度，加速計算。在預計算的過程中，主要利用了Storm高速數據分發和高密度并行計算的特性，規避了串行計算的痛點，首先時間復雜度大幅度降低，如圖7所示，因為可以并行計算，所以每一層的時間只花費t，那么總耗時為3*t，當然這樣估算是不準確的，因為沒必要在一層所有數據都計算完，才發射數據，可以在每一個計算單元運行完畢，就發射數據。這樣就可以形成上下級數據計算流水線，進一步壓縮計算時間。其次，空間復雜度大幅度降低，在Storm中，不需要保存下級數據，因為數據是不斷流動的，計算完畢就會被發射到下級Bolt。為此，本文采用Storm做預計算。計算拓撲結構如圖8。

圖8 Storm計算拓撲示意圖

如圖8所示，數據源頭（ChinaSpout）只有一個，該Spout內首先計算全國到省的數據，包括全國匯總數據以及省一級的數據，然后立刻將所有省級數據流入下層的ProvinceBolt，這一層應該考慮增加并發度，因為省到市一級的數據量級開始擴大，設置并發度為40，在計算完省到市級數據之后，數據開始流入CityBolt，這一層到市級數據，并發度可以再擴大，目前配置為300，計算完畢之后，數據流入最后一層BareaBolt，計算商圈到POI級別的數據。各級Bolt預計算產生的結果數據，都會存入數據層。存儲時遇到一個問題，在計算商圈到POI級別的數據時候，發現POI的量級比較大，不能直接存儲。為了不影響數據模型的通用性，我們隊POI級別的做了壓縮，然后再做存儲。為了保障數據的實時性，數據源會周期性產生數據流，更新預計算數據，其實這是Storm一類計算模式-----DRPC，數據源頭就是發射的參數，Storm的各級Bolt承擔運算。

該層解決的最大問題，是計算速度慢的問題，通過高密度的并發計算，降低重復數據過濾，大量數據組合，以及批量數據獲取慢對響應時間的影響。

數據層

預計算之后的數據需要存儲，供業務邏輯使用，存儲選型需要滿足以下幾點：

• 預計算產生的數據模型是樹形結構，所以不適合關系型數據庫
• 數據具有時效性，數據過期會帶來臟數據
• 高密度并行計算，寫入并發量大，需要保證寫入速度
• 實現災備，存儲不可用時候，需要服務降級

為了滿足以上幾點要求，選用美團點評內部研發的公共KV存儲組件Squirrel和Tair分別來做存儲和災備。其中，Squirrel是基于Redis Cluster的純內存存儲，squirrel 屬于KV存儲，具有寫入、查詢速度快，并發度高，支持數據豐富，時效好的特點。而Tair支持持久化，性價比更高，適合用來做災備，當Squirrel不可用時，使用Tair提供服務。

熔斷層

預計算過程中，為了實現災備，還需要使用熔斷技術實現服務降級。熔斷雖然在上層控制，嚴格來說應該屬于數據層。

圖9 服務熔斷、降級工作原理

熔斷技術選用公共組件Rhino（美團點評自研的穩定性保障平臺，比Hystrix更加輕量、易用及可控，提供故障模擬、降級演練、服務熔斷、服務限流等功能），主要作用是：

a. 保護服務，防止服務雪崩

b. 及時熔斷，保障服務穩定

c. 提供多種降級策略，靈活適配服務場景

如圖9所示，虛線框，代表Rhino控制的區域，request1到來的時候，squirrel沒有問題，正常提供服務。request2 到來的時候，訪問squirrel發生異常（超時、異常等），請求被切換到tair。在squirrel恢復的過程中，Rhino會心跳請求squirrel，驗證服務可用性。request3請到來squirrel此刻已經恢復正常，由于Rhino會周期檢測，所以請求再次被切換到squirrel上恢復正常。

中臺服務層

數據準備好之后，還不能被業務邏輯直接使用，需要提供統一的服務，應對多變的業務邏輯。該層主要解決如下問題：

• 數據模型修改對業務邏輯有影響，數據服務需對上層具體業務邏輯透明
• 業務邏輯對數據有部分通用操作，需要抽象通用操作，防止數據業務緊耦合
• 存儲不可用的時候，需要服務熔斷和降級，降低對業務邏輯的影響
• 服務擴展增強能力，不能影響正常業務邏輯

該層對外提供RPC服務，直接處理數據模型，提供數據分頁、數據壓縮、數據解壓、數據篩選、數據批量提取以及數據原子提取 等功能，基本覆蓋了大部分對數據的操作，使得業務邏輯更加簡單。提取數據的時候，加入Rhino實現服務熔斷和降級，為業務邏輯層提供穩定可靠的服務。因為該層直接操作模型數據，所以即使數據模型有改動，也不會對業務邏輯造成影響，大大降低數據和業務的耦合。另外該層支持服務橫向擴展，在消費者大量增加的情況下，仍然能保證服務可靠運轉。

通過一系列的抽象和分層，最終業務邏輯直接使用簡單的服務接口就可以實現，客戶端的響應從最開始的十幾秒，提升到1秒以內，并且數據和代碼之間的耦合大幅度降低，對于后面的業務變化，只需要修改數據模型，增量提供若干中臺服務接口，即可滿足需求，大大降低了開發難度。

作者簡介

張騰，美團點評系統開發工程師，2016年畢業于西安電子科技大學，同年加入招銀網絡科技，從事系統開發以及數據開發工作。2017年加入美團點評數據中心，長期從事BI工具開發工作。

【本文為51CTO專欄機構“美團點評技術團隊”的原創稿件，轉載請通過微信公眾號聯系機構獲取授權】

戳這里，看該作者更多好文