互联网进入“下半场”后，美团点评作为全球最大的生活服务平台，拥有海量的活跃用户，这对技术来说，是一个巨大的宝藏。此时，我们需要一个利器，来最大程度发挥这份流量巨矿的价值，为酒旅的业务增长提供源源不断的动力。这个利器，我们叫它“流量罗盘”。
我们首先要思考几个问题：
所以，我们先要给流量罗盘做一个能够快速对比和衡量流量价值的来源分析功能，来覆盖流量的灵活细分及组合方式，继而找到酒旅流量增长的契机 ，为优化流量应用场景提供建议。
从图1可以看出，流量罗盘就是将用户、场景、流量来源进行充分组合，封装了流量来源分析方法，这样一来所有C端的PM（产品经理）和运营都可以随时随地完成对流量来源的分析，继而迅速落实到流量优化的实际工作中，大大提高了工作效率。
以上数据组合每个环节的需求关键点在于：
在建设流量罗盘过程中，主要面临以下几点挑战：
建设流量罗盘的时候，我们既要满足新的流量分析应用需求，解决以往的短板和痛点，也要有一定的业务和技术前瞻性，给未来留有改进的空间。针对前文描述的问题，有以下几点思考：
明确思路之后，我们开始了流量罗盘制作的实践，包括流量日志采集和抽取、来源归因、主题模型建设、构建多维应用层，以及应用后台和前端的开发。
如图2所示：
从图2可以了解到，公共维度从B3层一直贯穿到视图层，最终形成顶层Cube。公共维度的主要作用是将抽象的埋点规则、业务规则，以及各项标签模块化，能够被各层数据直接或间接调用，从而保证数据的一致性。
图3举例说明的是，页面类型维度、页面明细维度，以及流量入口维度的来源。
如图3所示：
主题宽表层的主要作用是在满足一定就绪时效和查询效率的前提下，尽可能地向下游输出丰富维度、标准业务口径、具有强扩展性的数据模型。
这里举其中一个例子来回应下前文提出的维度扩展性问题。
场景：如何在不更改主题模型结构和让下游无感知的前提下，满足多品类（相互重叠）的添加和扩展？
针对该场景，我们采用具有强扩展性的Json串作为该维度内容，同时封装该复杂的口径处理逻辑，使其具有全局复用性和扩展性，并保证口径的唯一。
上面的部分讲解了主题层是如何设计的，接下来将具体描述下为了达到所设计的模型，我们的ETL从（酒旅）流量日志开到上层主题过程中，是如何流转处理的。
因为流量产品主题和订单产品主题的较为类似，故以流量产品主题为例，表示基础层到事实层再到主题层的一般流程。
如图5所示，数据链路中的各个节点功能之间相互独立：
应用层的功能是向系统后台提供方便的、直接满足用户需求的查询通道，本文采用的是Kylin cube。这样系统后台可以根据约定好的查询逻辑，直接调用kylin接口，得到数据。
所以，本文认为衡量应用层和后台系统对接的效果有三个方面：
如图6所示，为了满足业务需求、用户查询体验，以及较好地与下游对接，做了几方面工作：
后台服务提供查询引擎和配置模块。
由于酒旅各个业务线关注的来源入口的不统一，各个入口支持的本异地、品类等维度的不同以及各个入口能支持的指标不一致，造成了各业务线的差异性，流量罗盘针对这种差异性，设置了针对不同的业务线和平台的各个入口分别进行配置。包含入口的指标计算都会基于来源配置的内容生成查询服务。来源入口的配置包含（不限于）以下几方面的内容：
配置模块也是基于权限控制的，配置模块是分业务线和平台配置的，只有具有对应权限的用户才能增加和更改来源入口的配置。只有在配置模块配置的入口信息才会展示在对应业务线对应平台的入口维度选择中。其中，配置模块交互如图7所示：
前端展示登录用户具有权限的业务线和平台的入口配置信息。当增加一条配置信息时，配置服务会从入口信息维表中读取对应业务线和平台下的所有可配置的入口信息，配置完入口对应支持的指标及各指标支持的基本维度信息后会将配置信息存入入口配置表。当入口的状态修改为在线状态后，在查询引擎的入口维度中才可以展示此入口维度。
查询模块负责根据用户提交的查询请求中的维度信息，执行查询，返回前端结果。用户提交的请求中如果包含入口信息，会查询配置模块中对应入口配置的指标中是否支持对应维度的查询，若不支持将不对此维度进行限制。如果前端提交的查询请求中不包含入口信息，查询的指标为各业务线设定的默认的指标信息。
查询引擎也会受权限的控制。此模块根据业务线、平台和终端三部分共同配置权限，只有具有某业务线下某个平台和某个终端的权限时，用户方可进行查询服务。其中查询请求流程如图8所示：
当用户选择的时间维度是按周或按月的查询时，各个指标的值是计算日均值（对于单日数据去重，跨天不去重的逻辑），单日的指标值数据都是针对用户去重的，直接按周按月查询是周去重和月去重的，这就不符合按周按月指标的计算逻辑导致数据查询结果存在差异性。为了解决数据准确性和按周按月查询数据量过大导致的查询效率的问题，将Master-Worker的多线程的设计模式应用于按周和按月的指标查询中。其中任务拆分指标计算的过程如图9所示：
如图9所示：
目前，涉及到的指标都相对简单，之后如果涉及到较复杂的衍生指标，也可以将指标的计算拆分成对基础指标的计算，计算完成后再将基础指标的计算结果合并计算衍生指标的值。
整套数仓设计和实现是一个需要长期持续优化迭代的过程，所以需要一些具有客观评价系统好坏的指标。
评价指标可以分为两类，一类是，对业务支撑的深度、广度，以及响应的快慢程度。
另一类，需要从数据模型本身出发，考量模型的稳定性、生产查询效率、数据质量，以及可扩展能力。
流量罗盘在美团点评酒店旅游各业务线已经得到了全面的应用，并收获了大量好评和建议。本文从底层数仓总纲和产品层面对流量罗盘进行分析，目前流量罗盘已经在线运营了2个季度，后续将会持续优化和迭代。
由于魔方的查询引擎、统一建模工具和起源已经相对成熟，后面产品的查询引擎方面会接入魔方（关于“魔方”的介绍可以参考之前的博客文章《大圣魔方——美团点评酒旅BI报表工具平台开发实践》）的查询引擎（筋斗云），配置模块会接入魔方的统一建模工具，将起源应用于统一指标口径，关于筋斗云、魔方建模工具、起源以及改版后的流量罗盘产品敬请期待！改版后流量罗盘产品架构如图10所示：
最后插播一个招聘广告，有对数据产品工具开发感兴趣的可以发邮件给 fuyishan#meituan.com。我们是一群擅长大数据领域数据工具，数据治理，智能数据应用架构设计及产品研发的工程师。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。