背景
美团点评作为全球最大的生活服务平台，承接超过千万的 POI，服务于数量庞大的活跃用户。在海量数据的前提下，定位运营业务、准确找到需要数据的位置，并快速提供正确、一致、易读的数据就变得异常困难，这些困难主要体现在以下方面：
因此团队提出将运营专题数据产品化，首先分析面临的一些问题和挑战。
挑战
① 服务业务能力
数据模式是需求驱动导向，这就导致数据最初只支持了少数团队，而更多有个性化需求的业务团队就无法被支持。
② 存储、计算、研发成本
没有统一的规范标准管理，造成了重复计算的资源浪费；数据的层次和粒度不清晰，使得重复存储严重；同时，工程师需要了解研发流程的整个细节，对研发的时间和精力成本造成浪费。
③ 数据标准不统一
业务指标繁杂，即使同样的命名，但定义口径也会不一致。例如，支付用户数就有多种定义，由此带来的问题是，都是支付用户数，应该用哪个？为什么数据都不一样？
④ 业务分析响应能力
即使拥有健壮的数仓模型支撑，但最终能否快速响应多维计算，进行对比分析，同时做到数据可读，都是对产品交互和服务能力的一种挑战。
针对以上的问题和挑战，开始制定建设方案。
方案
首先，构建了一个针对境内旅游运营侧全域的公共底层数据，将不同平台促销系统的数据按业务整合到一起，同时划分不同活动主题，按事件再向上聚合，做专题的数据支撑，统一数据出口。然后通过多维预计算引擎对事实数据进行预计算，构建数仓与应用的管道，从而节省计算成本，并且提升了数据互通和消费的效率，最后建设统一的数据服务中台，搭配不同端的 Web 应用。通过丰富的可视化效果，及多样的分析对比操作，快速、全面地支撑运营业务。
以下为整个产品的功能模块图：
图 1 运营专题整体功能模块图
如图所示，运营专题数据的产品化，根据需要解决的问题划分了多个不同的层次，每一层除其需要面对的核心问题外，还有其领域内其它功能模块的抽象和扩展，下面将会按照层次划分逐一介绍各个模块。
数据仓库层
数据生产和消费的基础平台，是整个数据产品化过程中最核心的角色。数据仓库的模型建设，不但影响产品化的难易程度及可行性，更是数据一致性等关键问题的直接因素，所以为降低使用门槛、统一数据标准、支撑上层更合理的架构，模型的选取就变得尤为重要。
领域内常见的建模方法
① 3NF 模型
3NF 模型（又叫“范式模型”）是数据仓库之父 Inmon 提出的，它用实体加关系的数据模型描述业务架构，在范式理论上符合 3NF，是站在全局角度面向主题的抽象。它更多的是面向数据的一致性治理。
3NF 模型最基本的要素是实体、属性和关系：
② 维度模型
维度模型是 Kimball 提出的。维度模型多为分析和决策提供服务，因此它重点解决快速完成分析，同时提供大规模复杂查询的响应性能（预聚合），更直接地面向业务。例如熟知的星形模型，以及特殊场景的雪花模型。
维度建模最基本的要素是事实和维度：
③ DV 模型（DataVault）
DataVault 是 Dan Linstedt 发起的，是一种介于 3NF 和维度建模之间的建模方法。它的设计主要是满足灵活性、可扩展性、一致性和对需求的适应性。它强调建立一个可审计的基础数据层，主要包括 Hub（核心实体）、Link（关系）、Satellite（实体属性）三个要素。
④ Anchor 模型
Anchor 模型由 Lars. Rönnbäck 提出，是 top="3336">运营专题数据如何构建
随着促销系统不断发展，平台趋于稳定，再结合各活动类型，及对需求的整理和进一步产品化，选择了 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，通过定制化开发的可视化数据，帮助用户将数据转化为可以付诸行动的见解，在提供可视化数据的同时，又为专题数据特定模块提供特定的降维，对比等线上分析操作。
趋势对比
通过维度的筛选切换，业务不同视角的核心指标趋势一目了然，不仅提供不同时间粒度同环比的纵向比对，还提供同级指标的横向比对，努力做到多角度、全方位的数据呈现。
图 11 产品趋势对比图
降维操作
为更好的认识和理解数据，降低复杂度，缓解“信息丰富、知识贫乏”现状，提供了降维操作，让原本稀疏分布在各维度的特征聚敛，将某类特性更直接的表现出来。
图 12 产品降维操作图
指标对比
将业务人员的线下热操作简移到线上，通过将维度压扁拉伸成纵向指标，进行多维指标的对比，并提供明细。
图 13 产品指标对比图
多维查询
为支持更好的 OLAP 分析，发挥预计算层的作用，还提供了关键指标解析和多维查询的功能，是产品对常规性分析的功能补充。
图 14 产品多维查询图
总结
在运营专题数据产品化的过程中，将技术转化为价值，提炼数据内容、为业务赋能是真正的发力点，为发挥数据的最大价值以及带给用户更好的体验，投入了大量的思考与实践，最终产品的生产投入为现阶段带来了以下收益：
