美团点评运营数据产品化实战

KyunraWang 2018-02-08

展开全文

背景

美团点评作为全球最大的生活服务平台，承接超过千万的POI，服务于数量庞大的活跃用户。在海量数据的前提下，定位运营业务、准确找到需要数据的位置，并快速提供正确、一致、易读的数据就变得异常困难，这些困难主要体现在以下方面：

取数门槛高，找不到切合的数据，口径复杂不易计算，对运营人员有一定的技能要求，人力成本增大；
数据处理非常耗时，缺少底层离线数仓模型建设和预计算支撑，Ad-hoc平台查询缓慢；
数据不一致，不同渠道口径不一致，缺少对杂乱指标的统一管理；
数据反馈形式不友好，缺少数据可视化的形式，无法呈现趋势，继而影响业务人员对多维、降维、对比等情况的进一步分析操作。

因此团队提出将运营专题数据产品化，首先分析面临的一些问题和挑战。

挑战

① 服务业务能力

数据模式是需求驱动导向，这就导致数据最初只支持了少数团队，而更多有个性化需求的业务团队就无法被支持。

② 存储、计算、研发成本

没有统一的规范标准管理，造成了重复计算的资源浪费；数据的层次和粒度不清晰，使得重复存储严重；同时，工程师需要了解研发流程的整个细节，对研发的时间和精力成本造成浪费。

③ 数据标准不统一

业务指标繁杂，即使同样的命名，但定义口径也会不一致。例如，支付用户数就有多种定义，由此带来的问题是，都是支付用户数，应该用哪个？为什么数据都不一样？

④ 业务分析响应能力

即使拥有健壮的数仓模型支撑，但最终能否快速响应多维计算，进行对比分析，同时做到数据可读，都是对产品交互和服务能力的一种挑战。

针对以上的问题和挑战，开始制定建设方案。

方案

首先，构建了一个针对境内旅游运营侧全域的公共底层数据，将不同平台促销系统的数据按业务整合到一起，同时划分不同活动主题，按事件再向上聚合，做专题的数据支撑，统一数据出口。然后通过多维预计算引擎对事实数据进行预计算，构建数仓与应用的管道，从而节省计算成本，并且提升了数据互通和消费的效率，最后建设统一的数据服务中台，搭配不同端的Web应用。通过丰富的可视化效果，及多样的分析对比操作，快速、全面地支撑运营业务。

以下为整个产品的功能模块图：

图1 运营专题整体功能模块图

如图所示，运营专题数据的产品化，根据需要解决的问题划分了多个不同的层次，每一层除其需要面对的核心问题外，还有其领域内其它功能模块的抽象和扩展，下面将会按照层次划分逐一介绍各个模块。

数据仓库层

数据生产和消费的基础平台，是整个数据产品化过程中最核心的角色。数据仓库的模型建设，不但影响产品化的难易程度及可行性，更是数据一致性等关键问题的直接因素，所以为降低使用门槛、统一数据标准、支撑上层更合理的架构，模型的选取就变得尤为重要。

领域内常见的建模方法

① 3NF模型

3NF模型（又叫“范式模型”）是数据仓库之父Inmon提出的，它用实体加关系的数据模型描述业务架构，在范式理论上符合3NF，是站在全局角度面向主题的抽象。它更多的是面向数据的一致性治理。3NF模型最基本的要素是实体、属性和关系：

实体：相同特征和性质的属性抽象，用抽象的实体名和属性名集合共同刻画的逻辑实体；
关系：实体之间的关系；
属性：实体的某种特性，一般实体具有多个属性。

② 维度模型

维度模型是Kimball提出的。维度模型多为分析和决策提供服务，因此它重点解决快速完成分析，同时提供大规模复杂查询的响应性能（预聚合），更直接地面向业务。例如熟知的星形模型，以及特殊场景的雪花模型。维度建模最基本的要素是事实和维度：

事实表：一般由两部分组成，纬度和指标，通常理解为“某人在某时间某地点通过某手段做了什么事情”的事实记录，它体现了业务流程的核心内容；
维度表：看待事实的角度，用以描述和还原事实发生的场景，比如通过地址、时间等维度还原业务场景。

③ DV模型（DataVault）

DataVault是Dan Linstedt发起的，是一种介于3NF和维度建模之间的建模方法。它的设计主要是满足灵活性、可扩展性、一致性和对需求的适应性。它强调建立一个可审计的基础数据层，主要包括Hub（核心实体）、Link（关系）、Satellite（实体属性）三个要素。

④ Anchor模型

Anchor模型由Lars. Rönnbäck提出，是DataVault模型的进一步范式化处理，核心思想是只添加、不修改的可扩展模型，Anchor模型构建的表极窄，类似于K-V结构化模型。它主要包括Anchors（实体且只有主键），Atributes（属性），Ties（关系），Knots（公用枚举属性)）。Anchor是应用中比较少的建模方法，只有传统企业和少数几家互联网公司有应用，例如：蚂蜂窝等。

运营专题数据如何构建？

随着促销系统不断发展，平台趋于稳定，再结合各活动类型，及对需求的整理和进一步产品化，选择了3NF+维度建模为基础的模型方法论，对数据进行合理划分和整合，构建了运营专题数据体系。

① 数据规范制定

数据规范的制定也是指标字典和服务层规则引擎抽象的基础。首先同业务达成共识，制定数据一致性标准，统一口径。同时将核心指标和个性化指标进行抽象，抽取统一规范定义，例如：月初到月末的整体交易类GMV和补贴类GMV，其原子指标是GMV，其它要素都属于指标的修饰。

图2 数据规范抽象示意图

② 数仓模型架构

将数据分为ODS层、BAS层、FACT层、TOPIC层。

ODS层主要功能：从分布式消息队列中消费Binlog和Click-log，并对埋点数据进行清洗和业务库数据还原，并根据需要增量或全量同步到Hive，同时积累历史数据并保存。

BAS层主要功能：采用3NF建模方法，对整体业务进行概念抽象及适当冗余，在保证数据一致的同时将同属性实体归纳整合到同一逻辑域。BAS层主要是为了减少数据的不一致，减少存储空间，响应业务系统的变化，避免更新异常。

FACT层主要功能：采用维度建模方法，根据活动特点及事实场景，对代金券、现金券、促销等的事件进一步整合。经过对维度的预处理，在使用信息的时候，不但减少时间成本、提高数据的提取效率，又为用户在Ad-Hoc平台查询提供很好的支撑，同时它成为了上层数据应用的关键出口。

TOPIC层主要功能：该层建设不是必须的，是针对业务中个性化诉求，根据需要建设专题数据。服务小范围业务群体和用户，用来支撑核心业务指标外的某一块个性化指标和应用。

图3 数据仓库模型图

如图所示，数仓模型整体架构图。通过构建运营专题的底层数据，针对数据一致性等问题，在数仓层面上得到了很好的解决，同时在数据提取效率上有很大的提升。数仓建设为接下来的业务支撑打好了充分的基础。

多维预计算层

预计算层是连接数据和应用之间的管道，是应用层垂直模块的专项支持。它是在Fact层数据之上的预聚合，强依赖于数仓模型中事实和维度的构建以及预关联。预计算采用Kylin引擎构建Cube聚合组，来解决取数门槛和数据处理耗时等问题，同是提供多维分析的能力，不但提供了新的Ad-Hoc(Query Engine)平台，在提高查询响应的同时，又能为产品带来更流畅的交互，增强用户体验。例如：创建一个交易数据cube，它包含日期（datakey）、用户（userid）、付款方式（paytype）、购买城市（city）。为满足不同消费方式在不同城市的应用情况和查看用户在不同城市的消费行为，建立以下两个聚合组，包含的维度和方式如图所示：

图4 构建cube示例图

中台服务层

数据预计算之后，需要分别对PC和移动端提供计算和装载，并且要针对不同端的特定模块做特定的开发，为了应对多变的业务逻辑，以及未来的可扩展能力，需要提供可插拔的、统一的服务层，该层主要可以解决如下问题：

服务与预计算数据同步，数据模型的修改只影响到预计算层，同时服务层还可以完全感知预计算数据的变化，不需要对服务做开发调整，实现数据变更的同步响应；
服务与端解耦，针对不同端产品提供统一数据服务，避免重复开发，同时产品的迭代升级与服务层隔离，应对多变的业务发展和增长；
服务扩展能力增强，支持服务的横向扩展，不影响正常业务的同时提高服务能力，同时在该层实现可抽象通用操作以及规范管理。

总体架构

图5 运营专题产品架构图

整个服务由独立的Web应用端发起请求，通过权限验证后对中台发起调用，然后读取配置中心的配置，由计算引擎对数据进行并行计算，同时规则引擎按业务线和指标修饰词等生产衍生指标，然后将引擎完成的数据按周期进行快照，存入备忘录，同时关联指标字典将数据与文案返回前台，最后按功能再对数据做可视化处理。下面分别对服务中交互的几个模块做简单的介绍。

配置中心

把系统的各类资源（比如：数据库、服务地址、缓存等）以及多个环境和具体业务逻辑（比如：业务线、平台、指标类型），按功能特性抽取出公共的控制的线头，在需要调整的时候，人为的控制系统。

图6 配置中心示意图

如图所示，用户通过单独的配置入口，将系统配置、优化条件判断、业务线个性化指标配置等信息提交到Server，运行时Client会到Server拉取配置，放入缓存，并定时持久化到本地文件，方便异常中断或重启时手动或自动重新加载配置。

指标字典

公司中的很多运营部门指标定义不清晰或不尽相同，但叫法相同（文案），又或者叫法相同指标口径不同，出现一些对指标的理解不一致，含义不清等问题。基于指标字典，不但是指标命名的规范和明确，也是统一计算口径的落地，接入规则引擎后生成关联衍生指标，即可自助完成查询和分析。可见，指标字典的建立，是数据服务平台的基础。

图7 指标字典思维导图

如图所示，基于数仓中对数据规范的制定，将指标按业务线、类型、基础、衍生等划分为不同类别，并对指标名称、别名、口径等信息落地入库，进行持久化存储。

规则引擎

运营业务的特点是运营活动规则的多变，需要很多个性化配置。为解决复杂和复合的计算问题（维度和事实的交叉）并降低维护成本，将逻辑从“硬编码”中将规则抽离，然后根据不同业务线特点按修饰词进行隔离，提高应用灵活性，简化架构。

图8 规则引擎示意图

① 数据准备规则

在应用数据计算之前把外部数据引入作为规则匹配运算的算子或数据集，例如某活动针对全部用户做发红包活动，而在活动中针对新用户发x面额的红包，而针对老用户发y面值的红包。其规则条件为：红包金额，且使用地点为；

② 数据计算规则

实现对业务规则的变量和参数化，按指标字典中的指标定义，转化为计算表达式，使得规则执行的结果作为其他规则条件的计算因子，生成衍生指标。

计算引擎

计算引擎（core模块）在对数据进行处理时对数据进行了分片，分桶等优化操作，在面对多维度大范围数据查询时一定程度上提升了查询性能，计算模块的抽取实现了与业务逻辑的解耦，它只负责任务的处理和执行，可仅对性能进行维护和升级，甚至可以维护不同处理方式的多个计算引擎，无需关心业务逻辑。

图9 计算引擎示意图

如图所示，当引擎接收一个时间跨度较大，维度较多的数据时，会先按照时间进行横向切分，然后将切分的数据按维度组合进行纵向切割，每一组都交由一个线程进行处理，并对该结果数据进行tag标记，然后根据标记在前台进行整合。

备忘录

备忘录是按时间周期对数据计算完成装载后状态的快照历史，是对值和计算规则的持久化。通过备忘录可以为用户提供横向，纵向等对比分析功能，帮助用户分析趋势。简化示意图如下：

图10 备忘录示意图

数据可视化

面对冰冷的数字，如何将数据组织起来，使其既有吸引力又易于理解？
可视化是解决问题的一种高效的手段，数据是强大的，如果能真正理解其中的内容。
运营专题产品采用了开源的Echarts，通过定制化开发的可视化数据，帮助用户将数据转化为可以付诸行动的见解，在提供可视化数据的同时，又为专题数据特定模块提供特定的降维，对比等线上分析操作。