背景

互聯(lián)網(wǎng)進(jìn)入“下半場(chǎng)”后，美團(tuán)點(diǎn)評(píng)作為全球最大的生活服務(wù)平臺(tái)，擁有海量的活躍用戶，這對(duì)技術(shù)來說，是一個(gè)巨大的寶藏。此時(shí)，我們需要一個(gè)利器，來最大程度發(fā)揮這份流量巨礦的價(jià)值，為酒旅的業(yè)務(wù)增長(zhǎng)提供源源不斷的動(dòng)力。這個(gè)利器，我們叫它“流量羅盤”。

我們首先要思考幾個(gè)問題：

流量都來自哪些入口；

本地場(chǎng)景、異地場(chǎng)景的流量差異如何運(yùn)用好；

如何挖掘出適合不同品類的流量場(chǎng)景；

是否能讓不同群體的用戶得到合理的引導(dǎo)。

所以，我們先要給流量羅盤做一個(gè)能夠快速對(duì)比和衡量流量?jī)r(jià)值的來源分析功能，來覆蓋流量的靈活細(xì)分及組合方式，繼而找到酒旅流量增長(zhǎng)的契機(jī) ，為優(yōu)化流量應(yīng)用場(chǎng)景提供建議。

從圖1可以看出，流量羅盤就是將用戶、場(chǎng)景、流量來源進(jìn)行充分組合，封裝了流量來源分析方法，這樣一來所有C端的PM（產(chǎn)品經(jīng)理）和運(yùn)營(yíng)都可以隨時(shí)隨地完成對(duì)流量來源的分析，繼而迅速落實(shí)到流量?jī)?yōu)化的實(shí)際工作中，大大提高了工作效率。

以上數(shù)據(jù)組合每個(gè)環(huán)節(jié)的需求關(guān)鍵點(diǎn)在于：

滿足豐富的場(chǎng)景組合、靈活且能夠隨時(shí)滿足酒旅業(yè)務(wù)的場(chǎng)景擴(kuò)展；

流量來源可以是任何一個(gè)頁(yè)面或控件，甚至是組合，來源的組合要高效易用。

挑戰(zhàn)

在建設(shè)流量羅盤過程中，主要面臨以下幾點(diǎn)挑戰(zhàn)：

維度種類較多且元素豐富。清洗后所到達(dá)主題層的與業(yè)務(wù)直接相關(guān)的UV流量，每天增量在千萬級(jí)別。同時(shí)數(shù)量眾多的維度和豐富的元素，使得總體數(shù)據(jù)量呈指數(shù)級(jí)別膨脹?？紤]用戶使用體驗(yàn)，分析結(jié)果反應(yīng)時(shí)間需要控制在<=3s（天粒度）和 <=5s（月粒度）。

維度的可擴(kuò)展性。現(xiàn)有基礎(chǔ)維度是12個(gè)，在此基礎(chǔ)上做維度的擴(kuò)展主要從三個(gè)方面著手。第一，添加新的正常維度；第二，新增已有維度的衍生維度，例如城市等級(jí)；第三，在已有維度中增加新元素，該元素可以與已有元素存在交集，例如酒店業(yè)務(wù)的兩種不同品類共享一部分門店，這時(shí)候流量和交易需要雙算。業(yè)務(wù)發(fā)展較快，要在不修改已有數(shù)據(jù)模型的前提下，快速迭代添加新的維度。

入口來源的靈活性。其實(shí)入口來源屬于上文中維度里面的一種，之所以在這里單獨(dú)說明，是因?yàn)樗浅Ｌ厥狻Ｋ笪覀冏龅皆诿總€(gè)版本中所有的新加入口，都可以立即分析其效果。

在查詢引擎中，我們?cè)谶x擇時(shí)間維度類型時(shí)，選擇按周或按月，各個(gè)指標(biāo)的值都是計(jì)算日均值（單日數(shù)據(jù)去重，跨天不去重），單日的指標(biāo)值數(shù)據(jù)都是針對(duì)用戶去重的，直接按周按月查詢是按周去重和按月去重的，這就不符合按周按月指標(biāo)的計(jì)算邏輯。

解決思路

建設(shè)流量羅盤的時(shí)候，我們既要滿足新的流量分析應(yīng)用需求，解決以往的短板和痛點(diǎn)，也要有一定的業(yè)務(wù)和技術(shù)前瞻性，給未來留有改進(jìn)的空間。針對(duì)前文描述的問題，有以下幾點(diǎn)思考：

在應(yīng)用接入選型Kylin的基礎(chǔ)上，考慮到其維度數(shù)量的限制，數(shù)據(jù)輸入的時(shí)候，可以提前對(duì)維度進(jìn)行剪枝。例如酒店常有的本異地場(chǎng)景，觀察角度具有多個(gè)層次，我們可以只采用最低層次粒度輸入，然后通過后臺(tái)的關(guān)系規(guī)則匹配關(guān)聯(lián)，間接得到更多豐富場(chǎng)景的計(jì)算數(shù)據(jù)。

同樣是為了解決之前低擴(kuò)展的問題，盡量將整個(gè)數(shù)據(jù)鏈條層次化，功能模塊要避免高耦合的數(shù)據(jù)邏輯。

想要滿足入口來源的靈活配置，首先埋點(diǎn)要規(guī)則統(tǒng)一，然后抽象該規(guī)則至入口維度中，最后搭配指標(biāo)的聯(lián)合計(jì)算得到。

解決方案

明確思路之后，我們開始了流量羅盤制作的實(shí)踐，包括流量日志采集和抽取、來源歸因、主題模型建設(shè)、構(gòu)建多維應(yīng)用層，以及應(yīng)用后臺(tái)和前端的開發(fā)。

體系架構(gòu)

如圖2所示：

• A層（也稱ODS層），包含美團(tuán)App的大搜日志、頁(yè)面流量日志、模塊事件日志以及描述埋點(diǎn)內(nèi)容的信息日志。
• 公共維度，其中重要的流量入口維度、頁(yè)面維度都是從具有統(tǒng)一規(guī)則的埋點(diǎn)標(biāo)記日志中，抽象形成的維度。
• B3層（酒旅基礎(chǔ)明細(xì)層），通過對(duì)A層的抽取轉(zhuǎn)換，初步形成只含酒旅業(yè)務(wù)所需的基礎(chǔ)流量日志。
• B2層（酒旅多維模型層），對(duì)已有的基礎(chǔ)層數(shù)據(jù)和公共維度的輕加工，擴(kuò)展出業(yè)務(wù)常用的維度信息，例如頁(yè)面類型、商家門店、產(chǎn)品、城市，以及平臺(tái)等。
• B1層（主題寬表層），主題寬表層主要是對(duì)多維模型層的聚合計(jì)算，包括多個(gè)復(fù)雜業(yè)務(wù)口徑的輸出、少數(shù)維度的深加工，以及來源入口的增加，保證數(shù)據(jù)的一致性。
• App層，該層是針對(duì)各自的流量應(yīng)用（流量羅盤）設(shè)計(jì)的，滿足該產(chǎn)品應(yīng)用所需且具有一定擴(kuò)展容量的聚合模型結(jié)構(gòu)。
• 視圖層，作為App層與Kylin cube的緩沖層，依靠其本身視圖的特性，能夠很好地解決頂層擴(kuò)展、查詢延時(shí)、資源分配，以及表意理解等多個(gè)問題。
• cube層，每個(gè)Kylin cube是由單個(gè)視圖與多個(gè)維度的雪花組合，輸出計(jì)算數(shù)據(jù)給羅盤后臺(tái)服務(wù)。
• 后臺(tái)服務(wù)層，包含查詢引擎和配置模塊兩部分的內(nèi)容。處理前端的查詢請(qǐng)求。
• 權(quán)限層，對(duì)各個(gè)業(yè)務(wù)線分平臺(tái)和終端控制權(quán)限。
• 前端展示層，與用戶交互并提交用戶的查詢請(qǐng)求。

具體方案

公共維度

從圖2可以了解到，公共維度從B3層一直貫穿到視圖層，最終形成頂層Cube。公共維度的主要作用是將抽象的埋點(diǎn)規(guī)則、業(yè)務(wù)規(guī)則，以及各項(xiàng)標(biāo)簽?zāi)K化，能夠被各層數(shù)據(jù)直接或間接調(diào)用，從而保證數(shù)據(jù)的一致性。

圖3舉例說明的是，頁(yè)面類型維度、頁(yè)面明細(xì)維度，以及流量入口維度的來源。

如圖3所示：

• 頁(yè)面類型維度，抽象于業(yè)務(wù)方對(duì)頁(yè)面的定義、對(duì)DAU和意向等口徑的定義（文檔日志）；
• 頁(yè)面明細(xì)維度和流量入口維度，來源于平時(shí)規(guī)范化的埋點(diǎn)方案文檔日志，明確標(biāo)示業(yè)務(wù)頁(yè)面范疇和業(yè)務(wù)入口的定義。

主題寬表層

主題寬表層的主要作用是在滿足一定就緒時(shí)效和查詢效率的前提下，盡可能地向下游輸出豐富維度、標(biāo)準(zhǔn)業(yè)務(wù)口徑、具有強(qiáng)擴(kuò)展性的數(shù)據(jù)模型。

這里舉其中一個(gè)例子來回應(yīng)下前文提出的維度擴(kuò)展性問題。

場(chǎng)景：如何在不更改主題模型結(jié)構(gòu)和讓下游無感知的前提下，滿足多品類（相互重疊）的添加和擴(kuò)展？

針對(duì)該場(chǎng)景，我們采用具有強(qiáng)擴(kuò)展性的Json串作為該維度內(nèi)容，同時(shí)封裝該復(fù)雜的口徑處理邏輯，使其具有全局復(fù)用性和擴(kuò)展性，并保證口徑的唯一。

上面的部分講解了主題層是如何設(shè)計(jì)的，接下來將具體描述下為了達(dá)到所設(shè)計(jì)的模型，我們的ETL從（酒旅）流量日志開到上層主題過程中，是如何流轉(zhuǎn)處理的。

因?yàn)榱髁慨a(chǎn)品主題和訂單產(chǎn)品主題的較為類似，故以流量產(chǎn)品主題為例，表示基礎(chǔ)層到事實(shí)層再到主題層的一般流程。

如圖5所示，數(shù)據(jù)鏈路中的各個(gè)節(jié)點(diǎn)功能之間相互獨(dú)立：

• 日志到事實(shí)是保留基礎(chǔ)流量信息的前提下，提取和分區(qū)主要流量頁(yè)面，同時(shí)附加A/B Testing策略維度；
• 用戶維度的輸入是用戶，輸出是包含但不限于新老、常駐等具有用戶標(biāo)簽屬性的擴(kuò)展維度內(nèi)容；
• 標(biāo)準(zhǔn)口徑模塊的功能是統(tǒng)一管理口徑處理邏輯、統(tǒng)一輸出口徑標(biāo)簽維度，具有全局適配性；
• 從瀏覽事實(shí)到產(chǎn)品流量主題，除了保留了原有的信息外，就是增加了很多需要二次計(jì)算的補(bǔ)充擴(kuò)展維度；
• 歸因計(jì)算模塊，包括tag標(biāo)記歸因、頁(yè)面歸因和模塊事件歸因，根據(jù)不同的場(chǎng)景匹配不同的歸因方式，得到不同的入口來源；
• 對(duì)產(chǎn)品流量主題進(jìn)行流量入口的加工，產(chǎn)出具有易于分析的入口主題，兩者的就緒時(shí)間相差較大，所以分步進(jìn)行。

數(shù)據(jù)應(yīng)用層

應(yīng)用層的功能是向系統(tǒng)后臺(tái)提供方便的、直接滿足用戶需求的查詢通道，本文采用的是Kylin cube。這樣系統(tǒng)后臺(tái)可以根據(jù)約定好的查詢邏輯，直接調(diào)用kylin接口，得到數(shù)據(jù)。

所以，本文認(rèn)為衡量應(yīng)用層和后臺(tái)系統(tǒng)對(duì)接的效果有三個(gè)方面：

• 后臺(tái)查詢數(shù)據(jù)的邏輯簡(jiǎn)單。
• 屏蔽業(yè)務(wù)邏輯。
• 業(yè)務(wù)擴(kuò)展，查詢邏輯不變或者較少更改。

如圖6所示，為了滿足業(yè)務(wù)需求、用戶查詢體驗(yàn)，以及較好地與下游對(duì)接，做了幾方面工作：

App層分為兩部分，不分來源和區(qū)分來源，因?yàn)閮烧呔途w時(shí)間不同，在數(shù)據(jù)一致性的前提下，采用先到先展示的方案；

在App層和Cube層之間，加入中間視圖層，是為了隔離業(yè)務(wù)變動(dòng)、口徑變動(dòng)，以及數(shù)據(jù)更改對(duì)下游使用者的影響，同時(shí)也整體增強(qiáng)了擴(kuò)展能力；

Cube創(chuàng)建過程中的維度優(yōu)化和參數(shù)設(shè)置，目的主要是為了提高cube查詢和cube生產(chǎn)的效率；

因?yàn)镵ylin本身的原因，Cube也與視圖一一對(duì)應(yīng)，其中曝光和點(diǎn)擊采用模糊計(jì)算，經(jīng)過研究對(duì)該類指標(biāo)采用模糊方案，性價(jià)比最大。

后臺(tái)服務(wù)層

后臺(tái)服務(wù)提供查詢引擎和配置模塊。

由于酒旅各個(gè)業(yè)務(wù)線關(guān)注的來源入口的不統(tǒng)一，各個(gè)入口支持的本異地、品類等維度的不同以及各個(gè)入口能支持的指標(biāo)不一致，造成了各業(yè)務(wù)線的差異性，流量羅盤針對(duì)這種差異性，設(shè)置了針對(duì)不同的業(yè)務(wù)線和平臺(tái)的各個(gè)入口分別進(jìn)行配置。包含入口的指標(biāo)計(jì)算都會(huì)基于來源配置的內(nèi)容生成查詢服務(wù)。來源入口的配置包含（不限于）以下幾方面的內(nèi)容：

• 來源入口對(duì)指標(biāo)的支持。
• 來源入口各個(gè)指標(biāo)對(duì)品類（其中酒店包含高星、經(jīng)濟(jì)連鎖、海外等）的支持。
• 來源入口各個(gè)指標(biāo)對(duì)本異地的支持。

配置模塊也是基于權(quán)限控制的，配置模塊是分業(yè)務(wù)線和平臺(tái)配置的，只有具有對(duì)應(yīng)權(quán)限的用戶才能增加和更改來源入口的配置。只有在配置模塊配置的入口信息才會(huì)展示在對(duì)應(yīng)業(yè)務(wù)線對(duì)應(yīng)平臺(tái)的入口維度選擇中。其中，配置模塊交互如圖7所示：

前端展示登錄用戶具有權(quán)限的業(yè)務(wù)線和平臺(tái)的入口配置信息。當(dāng)增加一條配置信息時(shí)，配置服務(wù)會(huì)從入口信息維表中讀取對(duì)應(yīng)業(yè)務(wù)線和平臺(tái)下的所有可配置的入口信息，配置完入口對(duì)應(yīng)支持的指標(biāo)及各指標(biāo)支持的基本維度信息后會(huì)將配置信息存入入口配置表。當(dāng)入口的狀態(tài)修改為在線狀態(tài)后，在查詢引擎的入口維度中才可以展示此入口維度。

查詢模塊負(fù)責(zé)根據(jù)用戶提交的查詢請(qǐng)求中的維度信息，執(zhí)行查詢，返回前端結(jié)果。用戶提交的請(qǐng)求中如果包含入口信息，會(huì)查詢配置模塊中對(duì)應(yīng)入口配置的指標(biāo)中是否支持對(duì)應(yīng)維度的查詢，若不支持將不對(duì)此維度進(jìn)行限制。如果前端提交的查詢請(qǐng)求中不包含入口信息，查詢的指標(biāo)為各業(yè)務(wù)線設(shè)定的默認(rèn)的指標(biāo)信息。

查詢引擎也會(huì)受權(quán)限的控制。此模塊根據(jù)業(yè)務(wù)線、平臺(tái)和終端三部分共同配置權(quán)限，只有具有某業(yè)務(wù)線下某個(gè)平臺(tái)和某個(gè)終端的權(quán)限時(shí)，用戶方可進(jìn)行查詢服務(wù)。其中查詢請(qǐng)求流程如圖8所示：

當(dāng)用戶選擇的時(shí)間維度是按周或按月的查詢時(shí)，各個(gè)指標(biāo)的值是計(jì)算日均值（對(duì)于單日數(shù)據(jù)去重，跨天不去重的邏輯），單日的指標(biāo)值數(shù)據(jù)都是針對(duì)用戶去重的，直接按周按月查詢是周去重和月去重的，這就不符合按周按月指標(biāo)的計(jì)算邏輯導(dǎo)致數(shù)據(jù)查詢結(jié)果存在差異性。為了解決數(shù)據(jù)準(zhǔn)確性和按周按月查詢數(shù)據(jù)量過大導(dǎo)致的查詢效率的問題，將Master-Worker的多線程的設(shè)計(jì)模式應(yīng)用于按周和按月的指標(biāo)查詢中。其中任務(wù)拆分指標(biāo)計(jì)算的過程如圖9所示：

如圖9所示：

• 用戶在選擇維度之后提交每個(gè)指標(biāo)計(jì)算的總?cè)蝿?wù)。
• Master將總?cè)蝿?wù)簡(jiǎn)單的按時(shí)間維度拆分成對(duì)每個(gè)周或是每個(gè)月為維度求日均值的查詢?nèi)蝿?wù)放到任務(wù)隊(duì)列中。
• Worker進(jìn)程隊(duì)列從任務(wù)隊(duì)列中獲取任務(wù)、執(zhí)行任務(wù)并將任務(wù)結(jié)果提交給Master的結(jié)果集。
• Master將各個(gè)子任務(wù)的指標(biāo)計(jì)算結(jié)果進(jìn)行匯總返回。

目前，涉及到的指標(biāo)都相對(duì)簡(jiǎn)單，之后如果涉及到較復(fù)雜的衍生指標(biāo)，也可以將指標(biāo)的計(jì)算拆分成對(duì)基礎(chǔ)指標(biāo)的計(jì)算，計(jì)算完成后再將基礎(chǔ)指標(biāo)的計(jì)算結(jié)果合并計(jì)算衍生指標(biāo)的值。

評(píng)價(jià)指標(biāo)

整套數(shù)倉(cāng)設(shè)計(jì)和實(shí)現(xiàn)是一個(gè)需要長(zhǎng)期持續(xù)優(yōu)化迭代的過程，所以需要一些具有客觀評(píng)價(jià)系統(tǒng)好壞的指標(biāo)。

評(píng)價(jià)指標(biāo)可以分為兩類，一類是，對(duì)業(yè)務(wù)支撐的深度、廣度，以及響應(yīng)的快慢程度。

• 業(yè)務(wù)的深度和廣度，可以從業(yè)務(wù)對(duì)模型的需求總量來側(cè)面衡量；
• 響應(yīng)的快慢，可以從需求發(fā)起到需求接受，再到需求完成的各階段時(shí)間來衡量。

另一類，需要從數(shù)據(jù)模型本身出發(fā)，考量模型的穩(wěn)定性、生產(chǎn)查詢效率、數(shù)據(jù)質(zhì)量，以及可擴(kuò)展能力。

• 數(shù)據(jù)效率（生產(chǎn)和查詢），包含數(shù)據(jù)最晚（平均）就緒時(shí)間、數(shù)據(jù)最大（平均）執(zhí)行時(shí)長(zhǎng)，以及最大（平均）多維查詢反饋時(shí)間；
• 數(shù)據(jù)質(zhì)量，包含每月平均數(shù)據(jù)問題產(chǎn)生數(shù)，細(xì)分可以有數(shù)據(jù)缺失、數(shù)據(jù)合理性問題、數(shù)據(jù)一致性問題等；
• 數(shù)據(jù)占用資源，例如整體數(shù)據(jù)占用存儲(chǔ)資源多少、每天占用計(jì)算資源多少。

總結(jié)

流量羅盤在美團(tuán)點(diǎn)評(píng)酒店旅游各業(yè)務(wù)線已經(jīng)得到了全面的應(yīng)用，并收獲了大量好評(píng)和建議。本文從底層數(shù)倉(cāng)總綱和產(chǎn)品層面對(duì)流量羅盤進(jìn)行分析，目前流量羅盤已經(jīng)在線運(yùn)營(yíng)了2個(gè)季度，后續(xù)將會(huì)持續(xù)優(yōu)化和迭代。

展望

由于魔方的查詢引擎、統(tǒng)一建模工具和起源已經(jīng)相對(duì)成熟，后面產(chǎn)品的查詢引擎方面會(huì)接入魔方（關(guān)于“魔方”的介紹可以參考之前的博客文章《大圣魔方——美團(tuán)點(diǎn)評(píng)酒旅BI報(bào)表工具平臺(tái)開發(fā)實(shí)踐》）的查詢引擎（筋斗云），配置模塊會(huì)接入魔方的統(tǒng)一建模工具，將起源應(yīng)用于統(tǒng)一指標(biāo)口徑，關(guān)于筋斗云、魔方建模工具、起源以及改版后的流量羅盤產(chǎn)品敬請(qǐng)期待！改版后流量羅盤產(chǎn)品架構(gòu)如圖10所示：

作者簡(jiǎn)介

• 冰，美團(tuán)平臺(tái)數(shù)據(jù)中心高級(jí)研發(fā)工程師，2014年畢業(yè)于北京航空航天大學(xué)，2015年加入美團(tuán)，負(fù)責(zé)酒旅事業(yè)群的數(shù)據(jù)倉(cāng)庫(kù)建設(shè)。
• 瑞芳，美團(tuán)平臺(tái)數(shù)據(jù)中心BI工具后臺(tái)開發(fā)工程師，2016年畢業(yè)于北京工業(yè)大學(xué)，2017年加入美團(tuán)點(diǎn)評(píng)數(shù)據(jù)中心，長(zhǎng)期從事BI工具開發(fā)工作。
• 夷山，美團(tuán)點(diǎn)評(píng)技術(shù)專家，現(xiàn)任TechClub-Java俱樂部主席，2006年畢業(yè)于武漢大學(xué)，先后就職于IBM、用友、風(fēng)行以及阿里。2014年加入美團(tuán)，長(zhǎng)期致力于BI工具、數(shù)據(jù)安全與數(shù)據(jù)質(zhì)量工作等方向。

招聘信息

最后插播一個(gè)招聘廣告，有對(duì)數(shù)據(jù)產(chǎn)品工具開發(fā)感興趣的可以發(fā)郵件給 fuyishan#meituan.com。我們是一群擅長(zhǎng)大數(shù)據(jù)領(lǐng)域數(shù)據(jù)工具，數(shù)據(jù)治理，智能數(shù)據(jù)應(yīng)用架構(gòu)設(shè)計(jì)及產(chǎn)品研發(fā)的工程師。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的流量运营数据产品最佳实践——美团旅行流量罗盘的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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