转载

业务赋能利器之外卖特征档案

应用背景及现状

美团外卖业务自2013年9月启动至今已运营三年时间。截至2016年12月，美团点评整个外卖平台的日订单超过900万，日在线商家100多万。从发展速度和体量上看，外卖业务仍处在迅猛发展的上升期。与早期飞速增长的状态相比，随着规模的不断扩大，业务发展需要更健康、高效。这就对业务对象、业务环节的整体业务运营管理提出更高的要求。从运营管理上按照业务维度拆分，会衍生出针对用户、商户、运营人员效率等方面的运营需求。

其中 用户是最为重要的业务对象 。如何接触到更广泛的用户群体，吸引潜在用户使用外卖平台，提供个性化的优质用户服务，是推动其他业务对象及业务环节进行联动优化运营的核心目标。另一方面， 商户是外卖业务的营销主体 ，如何精准的定位到特定类型的商家，并作针对性的投放营销策略，是业务运营的核心内容。 运营人员作为运营策略实施操作的主体 ，操作效率、流程优化、决策优化、成本控制等也对运营效果有重大的影响。

特征档案平台为各业务提供了用户/商户筛选和档案管理服务，并提供了数据查询、存储、生成、导出等数据管理功能，极大的提高了运营人员的工作效率。当前用户特征档案平台覆盖全部的外卖交易用户，有特征标签近200个，商户特征档案平台覆盖全部的外卖商户，有特征标签400多个。

特征档案平台用于提供对外卖用户或商户进行即时的标签化查询功能，系统主要面向外卖事业部的运营和业务拓展人员，他们希望通过平台能及时的获取到满足筛选条件的结果集，并通过平台的管理功能保存固定的筛选逻辑，实现个人定制化的特征筛选。主要有以下几个核心诉求：

便捷的筛选方式。通过点击页面可视化的标签，进行便捷的查询。
即时自助查询。不同的使用者可随时执行各种各样的标签查询。
查询结果全量获取。对满足查询条件的结果全集进行全量获取。

面对上面的需求，开发人员需要解决以下几个核心问题：

将海量数据处理加工成标签，并实现完善的标签体系。
使用合适的存储查询引擎实现即时查询海量数据。
使用合适的存储查询引擎实现查询结果的全量获取，并提供接口服务。

特征档案的标签生产在外卖数据仓库中完成，针对主题加工出需要的标签，围绕用户以及商户建立完善的标签体系，支撑上层应用。在初期架构中，我们使用Hive客户端直接查询Hive，获取结果数据。但通过一段时间的使用发现，Hive客户端的查询需要很长时间才能完成，用户体验较差。

在后期的架构中，我们使用了ES（Elasticsearch）存储单天的特征数据，极大的改善了系统的查询性能，实现了即时查询海量数据。对于特征档案查询结果的存储与查询，我们可以借助于HBase的非结构化存储和强大的存储能力，将数据服务进行包装，提供统一的服务客户端进行数据交互，业务系统根据需求调用相应的服务，解耦与业务系统的逻辑。

目前特征档案平台主要提供以下服务：

通过特征标签筛选目标用户/商户，提供任意标签组合逻辑的即时查询服务；
将筛选条件保存成为档案，支持档案的保存、修改、删除等操作；
通过档案生成当前满足条件的数据实例，支持实例的查看、导出、离线上传等操作；
提供服务化接口，支持通过Thrift接口调用的方式查询用户/商户特征，或通过档案、实例获取用户/商户集合。

系统介绍

系统架构

特征档案服务的系统架构如下图所示。主要分为三个部分：数据加工层（数据仓库）、数据服务层（waimai_data_feature_service服务）、数据应用层。

业务赋能利器之外卖特征档案

在数据加工层中，特征档案的数据源主要分为两部分：离线数据和实时数据。离线数据源存储在Hive中，主要收集了外卖数据仓库中的用户、商户相关的基础数据、外卖流量数据、外卖用户画像数据、美团点评商户数据。离线数据在数据开放平台进行加工处理，分四个维度（用户特征、UUID特征、外卖商户、美团点评商户）写入线上ES集群中。实时数据源使用了外卖商家端的线上业务MySQL从库，通过一个准实时同步系统，将数据同步至线上的商户特征档案ES索引中。数据质检中心对离线数据的加工进行监控，主要监控项为数据唯一性、数据就绪时间、核心指标的阈值等，在离线数据写入线上ES集群的过程中，进行了数据去重处理（唯一性检验），保证了线上筛选结果的唯一性。

在数据仓库之上，我们建立了数据服务层，并针对不同的应用选择了差异化的数据存储和查询引擎。数据服务层中，使用ES作为特征存储和查询引擎，使用HBase存储用户/商户实例（这里的实例是指为业务方通过特征档案服务勾选出筛选条件并生成的数据结果集）。数据服务层还使用了MySQL数据库存储特征档案平台相关的档案、实例、标签管理、平台操作日志等信息。

waimai_data_feature_service是数据服务层的核心，使用了公司提供的分布式服务通信框架及服务治理系统框架，对外提供Thrift接口。它提供的主要服务包括：特征筛选的预览查询，档案创建及管理，实例生成及管理，实例导出，离线上传实例，标签管理。

最上层是数据产品和应用，基于外卖数据平台的特征档案平台提供了可视化的功能，并针对不同的业务需求方提供不同的数据应用服务，主要分为三大类：

精准营销：提供用户和商户的营销策略支持，如外卖的精准营销Push系统、团购推荐商家等应用。
运营管理：提供商户的管理支持，如商家服务质量管理、商家活动配置等应用。
业务拓展：提供商户的业务拓展支持，如城市端的CRM智能作战平台。

服务架构

waimai_data_feature_service服务架构如下图所示，整体上分为六个部分：服务配置、MySQL服务、HBase服务、ES服务、AOP（Aspect Oriented Programming）、标签管理。

业务赋能利器之外卖特征档案

服务配置：服务使用了美团统一配置中心（MCC）实现了服务配置管理。针对开关功能的配置，可在服务治理平台上通过修改MCC配置，MCC的client端会感知到此变化，并实时更新服务状态。例如AOP中的服务开关切面通过读取MCC中的相关配置实现切面逻辑。

MySQL服务：将特征档案平台所有的MySQL表封装成Model，通过Java反射机制，动态解析Model并生成所需的执行SQL语句，通过JdbcTemplate执行。简化了MyBatis中配置sql xml文件的开发工作量。

HBase服务：使用HBase实现实例的存储和查询。

ES服务：提供两种ES查询方式。FromToQuery即传统的分页查询，适合小数据量的浅分页查询，它的典型使用场景是特征档案平台中通过勾选某些筛选条件来预览数据结果（预览查询）。ScrollQuery即深分页查询，用于一次性查询大量的数据甚至是全部数据，它的典型使用场景是通过筛选条件获取到全部数据结果集（实例生成）。

AOP服务：提供了两种切面，日志上报和服务开关。日志上报即日志收集（埋点），适用于方法级别，将方法的访问日志上传到数据开放平台的日志中心。服务开关实现了对不同服务的开关管理。

标签管理：标签管理模块将标签分成了7大类型，不同的类型实现了不同的标签管理方法（这里的标签管理方法是指标签实现页面展示逻辑的方法，标签的筛选逻辑转换成可供ES查询的过滤器方法，通过关联标签维表将标签的查询结果转换成适合的结果形式方法）。FeatureShow提供了特征档案平台中的特征标签展示服务，GenESFilter实现了将标签查询语言解析成ESFilter的功能，ParseQueryResult则实现了将ES查询结果解析成最终可展示的友好的结果形式。

特征标签

标签体系，标签的生产、存储与查询，是我们在系统开发过程中最核心的技术问题，也直接影响着整个特征档案平台的性能和用户体验。在本文前面提到的几个核心问题，就是我们需要解决的：

海量数据处理加工成标签，并实现完善的标签体系；
使用合适的存储查询引擎实现即时查询海量数据；
使用合适的存储查询引擎实现查询结果的全量获取，并提供接口服务。

标签体系

特征档案平台的标签体系如下图所示。标签分为两大类：商户特征标签和用户特征标签。每一大类标签中，我们又继续划分了维度。商户特征包含美团点评商户和外卖商户两个维度。用户特征包含外卖用户和外卖设备两个维度。

业务赋能利器之外卖特征档案

在维度划分的基础上，继续按照标签的属性进行分组。商户特征属性包含：基本属性、经营能力、服务能力、合作深度、城市策略、活动策略、人工商户标签、商户画像标签。用户特征属性包含：用户自然属性、用户粘度属性、用户交易属性、用户画像标签、用户优惠属性、用户偏好属性、用户信誉属性、用户生命周期。

在各个属性内部是具体的特征标签，特征标签是一个或多个具有相似业务含义的初级标签的聚合形式，特征档案平台中的标签管理如下图所示。初级标签是指在数据仓库中最先生产出来的细粒度的标签。标签的全部行为由标签管理方法决定，标签的行为包含：标签的展示样式（新增、更改、删除等）、标签的使用逻辑等。

业务赋能利器之外卖特征档案

标签体系为特征档案平台提供了可靠、稳定、规范的标签管理服务，通过标签体系我们可以规范数据开发流程、简化和统一标签的生产方式。我们使用ES搜索引擎来实现面向应用的标签数据存储，ES自身有很强大的实时搜索和分析性能。标签管理服务便于开发人员灵活的配置平台中的可用标签，未来可以支持定制化的标签管理，也可以结合其他服务深入分析挖掘特征档案平台的标签。

标签生产

特征档案标签的生产在外卖数据仓库中完成，标签生产数据流如下图所示。数据流主要包括三大部分，数据源、Hive数据仓库、数据应用。其中Hive仓库中又分为四个部分，ODS表群、基础表群（FACT表、DIM表、维度快照表）、集市层表群（AGGR表)、应用层表群（TOPIC表）。数据应用层分为两个部分，应用缓冲层和应用层。标签生产过程分六步：源数据获取（Extract）、ODS层表群向基础层表群转换（Transform）、基础层向集市层的数据汇总、集市层向主题层的数据集成、主题层向应用层的缓冲、最终形成应用数据。

业务赋能利器之外卖特征档案

数据源当前主要包含外卖各个业务线的业务库和外卖日志。我们将这一部分数据同步到Hive数据仓库中，形成ODS层表群（和源系统同构的表群）。从ODS层向基础层表群转换，得到我们的基础数据层，其中包含事实表、维度表、快照表。基础数据层中的表是我们生产标签数据的核心基础表，也是我们形成初级数据聚合表的直接数据源。基础数据层包含的数据例如订单事实、商户事实、行为事实等。

聚合层是我们形成初级数据聚合的地方，也是初级标签生成的地方。在聚合层，我们将初级标签划分成了不同的属性，依据标签属性分组，不同的分组对应不同的聚合表。

初级标签生成后，我们将初级标签集成到主题层。主题层分为两大类，统计类主题表和非统计类主题表。主题层是我们数据仓库产出的可面向应用的最终结果表群。Hive数据仓库的加工过程对数据使用了按天分区存储，可追溯全部标签的历史数据。

数据应用部分我们首先进行了一层缓冲，即主题层过度到最终线上应用数据的应用缓冲层。在这一层，我们将初级标签聚合成终极标签，存储结构选用了Hive的Map结构存储。这样的好处是将一个或多个具有相似业务含义的初级标签统一管理，并在标签体系中具有相同的标签行为。应用缓冲层仅存储了最新一天的数据。

最后的应用层，我们将缓冲好的数据写入线上的ES集群中，每天都会进行重建索引的流程。

标签存储与查询

我们在Hive中完成特征数据的加工与存储，整体特征档案系统几乎涵盖了外卖业务的所有指标。我们首先将指标按照主题归类，针对主题加工出需要的标签，然后建立层次准确清晰的数据底层模型，将不同主题的数据进行集成，围绕用户以及商家建立完善的标签体系，支撑上层应用。

在数据仓库之上的数据服务层，并针对不同的应用选择了差异化的数据存储和查询引擎。数据服务层中，我们决定使用ES作为特征存储和查询引擎，主要有四个理由：

我们每日需要重刷全量的标签数据，而对于Kylin来说，无法使用其提供的自动增量cube机制，重建数据代价较大，同时ES在同样的维度上，空间膨胀度上比Kylin少近一半；
ES整个系统设计和架构非常简洁，运维方案简单，也有专门的工具支持，对于没有专职运维的开发团队来说是一个捷径；
ES具有强大的实时搜索和分析性能，当前外卖的累计用户已超过1亿，ES在这个数量级上提供了依然优秀的查询性能（秒级查询）；
ES便捷的数据交互方式（Restful API）配合上完善的标签管理体系，使特征档案的标签扩展性很强（通过JSON格式可以灵活变更标签的存储逻辑）。

ES中仅存储最新一天的标签数据，历史数据则存储在Hive中。通过使用ES，我们解决了即时查询场景。特征档案平台中提供的预览查询就是一种即时浅分页查询，ES查询结果返回当前页的数据和总命中个数。在预览查询中，我们限制了最大的分页数，因为这种场景下，并不需要查询页数较靠后的深分页查询。并且对于ES，深分页将带来极大的性能损耗从而造成结果返回超时。

另一种常见的查询场景是获取全量的查询数据，即深分页查询。针对这一类的查询场景，我们使用离线作业，通过ES的scrollQuery方式获取到满足条件的全量数据，并存储于HBase中。这些全量的结果数据我们称之为“实例”，“档案”则是一批筛选条件的集合。更形象的描述则是，“档案”类比于SQL语句，“实例”类比于SQL语句的查询结果。我们使用了HBase存储用户/商户实例，HBase的非结构化存储和强大的存储能力非常适合特征档案的实例存储，并且HBase的rowkey有序性也为我们实现分页查询提供了技术保障。业务方可通过HBase中存储的实例追溯数据历史，进行营销效果分析等深入的数据分析工作。

HBase的rowkey设计方式为“实例id_其他维度_用户/商户id”，这样便于针对某一特定生成实例的数据进行scan操作。同时为了实现分页获取这一批的实例数据，我们额外记录了一份rowkey的序号索引表，这样对使用者来说，大量的数据查询也可以通过分页获取到了。通过使用ES和HBase，我们实现了用户无感知的浅分页和深分页查询。

标签的存储与查询架构如下图所示。对外提供的API将查询传递给查询引擎，而后根据查询特性进行查询路径区分。对于浅分页且针对最新数据的查询，我们直接通过ES集群获得结果，而对于深分页或者是针对历史数据的查询，我们通过HBase获得结果。不同的查询路径对应用方来说是透明的。ES中存储的JSON格式的数据可以通过标签管理系统便捷的转换成非结构化的数据存入HBase，这一过程是离线的作业方式。

业务赋能利器之外卖特征档案

标签查询语言

特征档案平台支持的查询语言是在标签上定义的 一阶谓词逻辑标签查询语言 。传统意义上的标签通常仅具有“是否”逻辑，如：“成熟用户、北京市”。特征档案中的标签突破了传统意义上标签的定义，自身支持多种查询逻辑：大于、小于、是、否。在标签自身的查询逻辑基础上，标签与标签之间也支持与、或、非及组合逻辑。

举例来说，特征档案支持如下的查询语言：

“(物理城市名称：淮北)与((是否有营业执照：是)或(是否有餐饮许可证：是))与(交易额：大于80))”。

当前的标签查询语言，极大的丰富了标签之间的查询可能组合。以用户成熟度标签举例说明，包含三种传统标签：初级用户、成长用户、成熟用户。特征档案平台支持对这三种传统标签进行直接筛选查询，也支持通过对历史订单数的范围自定义完成用户成熟度标签的自定义筛选查询。

标签查询语言可在特征档案平台中通过档案创建页面生成，通过标签管理中的GenESFilter服务将标签查询语言解析成ESFilter，并实现对ES的查询。

应用案例

精准营销Push系统

精准营销Push系统是用户特征档案平台最典型的下游产品。通过输入实例或档案ID，创建目标用户集合，并精准推送消息或红包实现营销策略。

运营人员使用特征档案平台提供的即时查询服务，能迅速的锁定目标人群，并可便捷的调整筛选策略。在确定了筛选策略之后，运营人员可将策略保存为档案，并通过档案平台提供的实例生成服务来生成筛选结果集。Push系统所需的用户筛选结果集通常比较大（几百万至几千万），特征档案平台提供的全量获取数据服务会将结果集直接对接到Push系统中。

每天精准营销Push系统都会通过用户特征档案平台，查询某档案ID的结果数据（每天会发生变化），或直接通过实例ID获取固定的目标数据。截至当前，精准营销Push系统通过用户特征档案平台累计推送红包和营销消息已达上亿人次。

CRM智能作战平台

CRM智能作战平台是给管理者制定营销策略、完成业务拓展的一个工具。城市端管理者可以针对目标商户制定标准动作，下发任务给BD。其中最重要的一个环节是筛选目标商户，主要是通过特征档案平台来筛选的。商户作为外卖业务的营销主体，具有非常多的特征标签。城市端管理者通过商户特征档案的即时标签组合筛选，可迅速筛选出目标商户，并且这个结果集通常较小。通过特征档案平台提供的分页预览服务，就可获取到目标商户的全集，并且可直观的获得所需的商户信息。

智能作战平台使用商户特征档案平台作为筛选工具，筛选完成后将生成商户清单，并将目标商户制定成任务进行下发。截至当前，智能作战平台通过针对性和策略性的筛选商户，辅助BD更有效的完成商户任务，解决了上万个业务问题。

总结与展望

特征档案平台从上线至今经历了一年多的时间，主要的使用场景是精准营销、运营管理、业务拓展—大数据落地的最佳场景。随着美团外卖业务的发展，特征档案平台持续的遇到新的问题和挑战。总结这近一年的开发经验，我们归纳出以下数据系统设计的要点：

数据仓库
特征档案系统，几乎涵盖了外卖业务的所有指标，为了整合这一系列的指标，我们首先将指标按照主题归类，针对主题加工出需要的标签，然后建立层次准确清晰的数据底层模型，将不同主题的数据进行集成，围绕用户以及商家建立完善的标签体系，支撑上层应用。
数据存储
针对不同场景，需要合理地选择存储组件。对于特征档案实例的存储，由于数据量巨大，同时需要通过追溯历史来进行营销效果分析等深入的数据分析工作，我们借助于HBase的非结构化存储和强大的存储能力。对于特征档案的生成和查询，我们使用ES来存储，借助于ES的索引机制，我们可以快速的查询和提取符合条件的用户或者商户。对于系统的管理以及效果报表的展示数据等结构化的数据，我们选择了结构化的MySQL。
数据服务
在数据服务上，借助于分层和SOA的思想，我们针对不同的存储来源提供不同的服务组件，实现数据查询和数据提取。同时，我们将数据服务进行包装，提供统一的服务客户端进行数据交互，业务系统根据需求调用相应的服务，解耦与业务系统的逻辑。

未来，外卖特征档案平台将持续为外卖运营系统提供数据支持，将从以下几个方面进行优化：

接入第三方标签
未来我们的应用将不仅仅满足于从外卖的业务中提取特征，依托于公司整体的数据，我们可以更大范围、更加准确的获取用户/商户的特征。
支持个性化的定制标签使用
当前系统的标签还仅仅局限于事先预计算的用户特征，未来我们将支持用户自定义标签，然后从我们的数据集中筛选出用户，更加灵活、自由的提取满足特征的群体。
接入实时标签
目前，系统对于实时的标签还不够强大，越来越多的应用场景需要我们使用用户或者商户的实时状态来定向的提取群体。
数据挖掘
未来我们将特征档案筛选的结果会进行深入的挖掘分析，分析该群体的行为特征，更加准确的定位满足需求的用户。