背景

互联网进入“下半场”后，美团点评作为全球最大的生活服务平台，拥有海量的活跃用户，这对技术来说，是一个巨大的宝藏。此时，我们需要一个利器，来最大程度发挥这份流量巨矿的价值，为酒旅的业务增长提供源源不断的动力。这个利器，我们叫它“流量罗盘”。

我们首先要思考几个问题：

流量都来自哪些入口；
本地场景、异地场景的流量差异如何运用好；
如何挖掘出适合不同品类的流量场景；
是否能让不同群体的用户得到合理的引导。

所以，我们先要给流量罗盘做一个能够快速对比和衡量流量价值的来源分析功能，来覆盖流量的灵活细分及组合方式，继而找到酒旅流量增长的契机，为优化流量应用场景提供建议。

图1 产品结构图

从图1可以看出，流量罗盘就是将用户、场景、流量来源进行充分组合，封装了流量来源分析方法，这样一来所有C端的PM（产品经理）和运营都可以随时随地完成对流量来源的分析，继而迅速落实到流量优化的实际工作中，大大提高了工作效率。

以上数据组合每个环节的需求关键点在于：

满足丰富的场景组合、灵活且能够随时满足酒旅业务的场景扩展；
流量来源可以是任何一个页面或控件，甚至是组合，来源的组合要高效易用。

挑战

在建设流量罗盘过程中，主要面临以下几点挑战：

维度种类较多且元素丰富。清洗后所到达主题层的与业务直接相关的UV流量，每天增量在千万级别。同时数量众多的维度和丰富的元素，使得总体数据量呈指数级别膨胀。考虑用户使用体验，分析结果反应时间需要控制在<=3s（天粒度）和 <=5s（月粒度）。
维度的可扩展性。现有基础维度是12个，在此基础上做维度的扩展主要从三个方面着手。第一，添加新的正常维度；第二，新增已有维度的衍生维度，例如城市等级；第三，在已有维度中增加新元素，该元素可以与已有元素存在交集，例如酒店业务的两种不同品类共享一部分门店，这时候流量和交易需要双算。业务发展较快，要在不修改已有数据模型的前提下，快速迭代添加新的维度。
入口来源的灵活性。其实入口来源属于上文中维度里面的一种，之所以在这里单独说明，是因为它非常特殊。它要求我们做到在每个版本中所有的新加入口，都可以立即分析其效果。
在查询引擎中，我们在选择时间维度类型时，选择按周或按月，各个指标的值都是计算日均值（单日数据去重，跨天不去重），单日的指标值数据都是针对用户去重的，直接按周按月查询是按周去重和按月去重的，这就不符合按周按月指标的计算逻辑。

解决思路

建设流量罗盘的时候，我们既要满足新的流量分析应用需求，解决以往的短板和痛点，也要有一定的业务和技术前瞻性，给未来留有改进的空间。针对前文描述的问题，有以下几点思考：

在应用接入选型Kylin的基础上，考虑到其维度数量的限制，数据输入的时候，可以提前对维度进行剪枝。例如酒店常有的本异地场景，观察角度具有多个层次，我们可以只采用最低层次粒度输入，然后通过后台的关系规则匹配关联，间接得到更多丰富场景的计算数据。
同样是为了解决之前低扩展的问题，尽量将整个数据链条层次化，功能模块要避免高耦合的数据逻辑。
想要满足入口来源的灵活配置，首先埋点要规则统一，然后抽象该规则至入口维度中，最后搭配指标的联合计算得到。

解决方案

明确思路之后，我们开始了流量罗盘制作的实践，包括流量日志采集和抽取、来源归因、主题模型建设、构建多维应用层，以及应用后台和前端的开发。

体系架构

图2 流量罗盘体系架构

如图2所示：

A层（也称ODS层），包含美团App的大搜日志、页面流量日志、模块事件日志以及描述埋点内容的信息日志。
公共维度，其中重要的流量入口维度、页面维度都是从具有统一规则的埋点标记日志中，抽象形成的维度。
B3层（酒旅基础明细层），通过对A层的抽取转换，初步形成只含酒旅业务所需的基础流量日志。
B2层（酒旅多维模型层），对已有的基础层数据和公共维度的轻加工，扩展出业务常用的维度信息，例如页面类型、商家门店、产品、城市，以及平台等。
B1层（主题宽表层），主题宽表层主要是对多维模型层的聚合计算，包括多个复杂业务口径的输出、少数维度的深加工，以及来源入口的增加，保证数据的一致性。
App层，该层是针对各自的流量应用（流量罗盘）设计的，满足该产品应用所需且具有一定扩展容量的聚合模型结构。
视图层，作为App层与Kylin cube的缓冲层，依靠其本身视图的特性，能够很好地解决顶层扩展、查询延时、资源分配，以及表意理解等多个问题。
cube层，每个Kylin cube是由单个视图与多个维度的雪花组合，输出计算数据给罗盘后台服务。
后台服务层，包含查询引擎和配置模块两部分的内容。处理前端的查询请求。
权限层，对各个业务线分平台和终端控制权限。
前端展示层，与用户交互并提交用户的查询请求。

具体方案

公共维度

从图2可以了解到，公共维度从B3层一直贯穿到视图层，最终形成顶层Cube。公共维度的主要作用是将抽象的埋点规则、业务规则，以及各项标签模块化，能够被各层数据直接或间接调用，从而保证数据的一致性。

图3举例说明的是，页面类型维度、页面明细维度，以及流量入口维度的来源。

图3 公共维度来源图

如图3所示：

页面类型维度，抽象于业务方对页面的定义、对DAU和意向等口径的定义（文档日志）；
页面明细维度和流量入口维度，来源于平时规范化的埋点方案文档日志，明确标示业务页面范畴和业务入口的定义。

主题宽表层

主题宽表层的主要作用是在满足一定就绪时效和查询效率的前提下，尽可能地向下游输出丰富维度、标准业务口径、具有强扩展性的数据模型。

这里举其中一个例子来回应下前文提出的维度扩展性问题。

场景：如何在不更改主题模型结构和让下游无感知的前提下，满足多品类（相互重叠）的添加和扩展？

针对该场景，我们采用具有强扩展性的Json串作为该维度内容，同时封装该复杂的口径处理逻辑，使其具有全局复用性和扩展性，并保证口径的唯一。

图4 口径处理模块

上面的部分讲解了主题层是如何设计的，接下来将具体描述下为了达到所设计的模型，我们的ETL从（酒旅）流量日志开到上层主题过程中，是如何流转处理的。

因为流量产品主题和订单产品主题的较为类似，故以流量产品主题为例，表示基础层到事实层再到主题层的一般流程。

图5 主题模型计算流程

如图5所示，数据链路中的各个节点功能之间相互独立：

日志到事实是保留基础流量信息的前提下，提取和分区主要流量页面，同时附加A/B Testing策略维度；
用户维度的输入是用户，输出是包含但不限于新老、常驻等具有用户标签属性的扩展维度内容；
标准口径模块的功能是统一管理口径处理逻辑、统一输出口径标签维度，具有全局适配性；
从浏览事实到产品流量主题，除了保留了原有的信息外，就是增加了很多需要二次计算的补充扩展维度；
归因计算模块，包括tag标记归因、页面归因和模块事件归因，根据不同的场景匹配不同的归因方式，得到不同的入口来源；
对产品流量主题进行流量入口的加工，产出具有易于分析的入口主题，两者的就绪时间相差较大，所以分步进行。

数据应用层

应用层的功能是向系统后台提供方便的、直接满足用户需求的查询通道，本文采用的是Kylin cube。这样系统后台可以根据约定好的查询逻辑，直接调用kylin接口，得到数据。

所以，本文认为衡量应用层和后台系统对接的效果有三个方面：

后台查询数据的逻辑简单。
屏蔽业务逻辑。
业务扩展，查询逻辑不变或者较少更改。

图6 应用层计算流程

如图6所示，为了满足业务需求、用户查询体验，以及较好地与下游对接，做了几方面工作：

App层分为两部分，不分来源和区分来源，因为两者就绪时间不同，在数据一致性的前提下，采用先到先展示的方案；
在App层和Cube层之间，加入中间视图层，是为了隔离业务变动、口径变动，以及数据更改对下游使用者的影响，同时也整体增强了扩展能力；
Cube创建过程中的维度优化和参数设置，目的主要是为了提高cube查询和cube生产的效率；
因为Kylin本身的原因，Cube也与视图一一对应，其中曝光和点击采用模糊计算，经过研究对该类指标采用模糊方案，性价比最大。

后台服务层

后台服务提供查询引擎和配置模块。

由于酒旅各个业务线关注的来源入口的不统一，各个入口支持的本异地、品类等维度的不同以及各个入口能支持的指标不一致，造成了各业务线的差异性，流量罗盘针对这种差异性，设置了针对不同的业务线和平台的各个入口分别进行配置。包含入口的指标计算都会基于来源配置的内容生成查询服务。来源入口的配置包含（不限于）以下几方面的内容：

来源入口对指标的支持。
来源入口各个指标对品类（其中酒店包含高星、经济连锁、海外等）的支持。
来源入口各个指标对本异地的支持。

配置模块也是基于权限控制的，配置模块是分业务线和平台配置的，只有具有对应权限的用户才能增加和更改来源入口的配置。只有在配置模块配置的入口信息才会展示在对应业务线对应平台的入口维度选择中。其中，配置模块交互如图7所示：

图7 配置模块交互

前端展示登录用户具有权限的业务线和平台的入口配置信息。当增加一条配置信息时，配置服务会从入口信息维表中读取对应业务线和平台下的所有可配置的入口信息，配置完入口对应支持的指标及各指标支持的基本维度信息后会将配置信息存入入口配置表。当入口的状态修改为在线状态后，在查询引擎的入口维度中才可以展示此入口维度。

查询模块负责根据用户提交的查询请求中的维度信息，执行查询，返回前端结果。用户提交的请求中如果包含入口信息，会查询配置模块中对应入口配置的指标中是否支持对应维度的查询，若不支持将不对此维度进行限制。如果前端提交的查询请求中不包含入口信息，查询的指标为各业务线设定的默认的指标信息。

查询引擎也会受权限的控制。此模块根据业务线、平台和终端三部分共同配置权限，只有具有某业务线下某个平台和某个终端的权限时，用户方可进行查询服务。其中查询请求流程如图8所示：

图8 查询服务流程图

当用户选择的时间维度是按周或按月的查询时，各个指标的值是计算日均值（对于单日数据去重，跨天不去重的逻辑），单日的指标值数据都是针对用户去重的，直接按周按月查询是周去重和月去重的，这就不符合按周按月指标的计算逻辑导致数据查询结果存在差异性。为了解决数据准确性和按周按月查询数据量过大导致的查询效率的问题，将Master-Worker的多线程的设计模式应用于按周和按月的指标查询中。其中任务拆分指标计算的过程如图9所示：

图9 任务拆分指标计算

如图9所示：

用户在选择维度之后提交每个指标计算的总任务。
Master将总任务简单的按时间维度拆分成对每个周或是每个月为维度求日均值的查询任务放到任务队列中。
Worker进程队列从任务队列中获取任务、执行任务并将任务结果提交给Master的结果集。
Master将各个子任务的指标计算结果进行汇总返回。

目前，涉及到的指标都相对简单，之后如果涉及到较复杂的衍生指标，也可以将指标的计算拆分成对基础指标的计算，计算完成后再将基础指标的计算结果合并计算衍生指标的值。

评价指标

整套数仓设计和实现是一个需要长期持续优化迭代的过程，所以需要一些具有客观评价系统好坏的指标。

评价指标可以分为两类，一类是，对业务支撑的深度、广度，以及响应的快慢程度。

业务的深度和广度，可以从业务对模型的需求总量来侧面衡量；
响应的快慢，可以从需求发起到需求接受，再到需求完成的各阶段时间来衡量。

另一类，需要从数据模型本身出发，考量模型的稳定性、生产查询效率、数据质量，以及可扩展能力。

数据效率（生产和查询），包含数据最晚（平均）就绪时间、数据最大（平均）执行时长，以及最大（平均）多维查询反馈时间；
数据质量，包含每月平均数据问题产生数，细分可以有数据缺失、数据合理性问题、数据一致性问题等；
数据占用资源，例如整体数据占用存储资源多少、每天占用计算资源多少。

总结

流量罗盘在美团点评酒店旅游各业务线已经得到了全面的应用，并收获了大量好评和建议。本文从底层数仓总纲和产品层面对流量罗盘进行分析，目前流量罗盘已经在线运营了2个季度，后续将会持续优化和迭代。

展望

由于魔方的查询引擎、统一建模工具和起源已经相对成熟，后面产品的查询引擎方面会接入魔方（关于“魔方”的介绍可以参考之前的博客文章《大圣魔方——美团点评酒旅BI报表工具平台开发实践》）的查询引擎（筋斗云），配置模块会接入魔方的统一建模工具，将起源应用于统一指标口径，关于筋斗云、魔方建模工具、起源以及改版后的流量罗盘产品敬请期待！改版后流量罗盘产品架构如图10所示：

图10 产品架构图

作者简介

冰，美团平台数据中心高级研发工程师，2014年毕业于北京航空航天大学，2015年加入美团，负责酒旅事业群的数据仓库建设。
瑞芳，美团平台数据中心BI工具后台开发工程师，2016年毕业于北京工业大学，2017年加入美团点评数据中心，长期从事BI工具开发工作。
夷山，美团点评技术专家，现任TechClub-Java俱乐部主席，2006年毕业于武汉大学，先后就职于IBM、用友、风行以及阿里。2014年加入美团，长期致力于BI工具、数据安全与数据质量工作等方向。

创作场景

流量运营数据产品最佳实践——美团旅行流量罗盘