如果说互联网上半场是粗暴操作，因为有流量红利，细节就不用考虑了。那么下半年，精细化运营将是一个长期主题，只有具备数据分析能力，用户才能获得更好的体验。目前典型的分析方法是构建用户标签体系，精准生成用户画像，提升用户体验。今天分享的话题是网易严选DMP标签系统的建设实践，主要围绕以下五点展开：平台概况标签生产：标签圈选择&生产环节标签存储：存储方式&存储架构演进高性能查询未来规划01平台概况DMP作为网易精心挑选的数据中台，向下连接数据，向上赋能业务，起到非常重要的基石作用。DMP的数据来源主要包括三部分：自营平台APP、小程序、PC端的业务日志。网易集团内部共建的一些基础数据。将上述数据收集、清洗、存入数据资产。DMP基于数据资产，形成了一套自己的标签输出、群体选择和用户画像分析体系，为业务提供支撑，包括：智能选品、精准触达、用户洞察。总的来说，DMP系统就是构建以数据为中心的标签系统和画像系统，从而辅助业务进行一系列的精细化运营。要了解DMP系统，请从以下概念开始。Label：对实体（用户、设备、手机号码等）特征的描述，是一种面向业务的数据组织形式，如使用：年龄段、地址、偏好类别等来描述用户实体。人群选择：通过组合条件从所有用户中选出一组用户。具体来说就是指定一组用户标签及其对应的标签值，得到符合条件的用户群体。人像分析：对于群体选择结果，查看群体的行为和标签分布。比如在严选APP上查看用户【所在城市为杭州，性别为女性】的行为路径和消费模式。严选标签系统主要提供两大核心能力：（1）标签查询：能够查询特定实体的指定标签，常用于显示基本信息。(2)圈子选择：分为实时圈子选择和离线圈子选择。圈子选择结果主要用于：群体判断：判断用户是否属于一个或多个指定群体，常用于资源投放、人脉营销等场景。结果集拉取：将指定人群数据拉取到业务方系统中进行定制化开发。画像分析：分析特定人群的行为数据和消费模式，进行更精细化的运营。整体业务流程如下：首先定义标签和人群选择规则；定义好描述业务的DSL后，即可将任务提交给Spark进行计算；计算完成后，将计算结果存入HIVE和DORIS；之后，业务可以根据实际业务需要，方便的从HIVE或者DORIS中查询使用数据。DMP平台整体分为计算存储层、调度层、服务层、元数据管理四个模块。所有标签元信息都存储在源数据表中；调度层对整个业务流程进行任务调度：将数据处理和聚合转化为基础标签，将基础标签和源表中的数据通过DSL规则SQL语义转化为可用的数据查询，调度层将任务调度到Spark在计算存储层进行计算，并将计算结果存储在Hive和Doris中。服务层由标签服务、实体分组服务、标签基础数据服务、画像分析服务四部分组成。标签的生命周期包括5个阶段：（1）标签需求：在这个阶段，运营提出标签需求和价值期望，产品评估需求的合理性和紧迫性。（2）排产：这个阶段需要进行数据开发，对数据进行梳理，利用ods到dwd到dm层的整个链路，建立基于数据的模型。同时，需要很好地监控数据开发的质量。(3)人群选择：标签制作完成后进行应用，选择标签对应的人群。(4)精准营销：对3中圈子中选出??的人群进行精准营销。(5)效果评估：最后由产品、数据开发、运营评估标签使用率和使用效果，以确定后续改进或降级标签。总的来说，就是以业务增长为目标，围绕标签的生命周期进行合理的资源投入，最大化运营效果。02标签制作接下来介绍一下标签制作的全过程。标签的数据分层：最底层是ods层，包括用户登录日志、埋点记录日志、交易数据、各种数据库的binlog数据。ods层处理的数据到达dwd明细层，包括用户登录表、用户活跃度表、订单信息表等，dwd层数据聚合到dm层，tags均基于dm层实现数据。目前我们已经实现了从原始数据库到ods层的数据输出全自动化，实现了ods层到dwd层的部分自动化，dwd到dm层的部分自动化操作，但是自动化程度还不高高的。这部分自动化操作是我们接下来工作的重点。标签按时效性分为：离线标签、近实时标签、实时标签。根据聚合的粒度，分为：聚合标签和明细标签。标签通过品类维度可以分为：账户属性标签、消费行为标签、活跃行为标签、用户偏好标签、资产信息标签等。直接使用dm层的数据不方便，因为基础数据比较原始，缺乏抽象层次，使用起来比较麻烦。通过将基础数据与AND、OR、NOT结合，形成业务标签供业务方使用，可以降低理解操作的成本，降低使用难度。标签组合后，需要将标签应用到具体的业务场景中，比如组选。配置如上图左侧所示，支持离线人群包和实时行为（需要单独配置）。配置后，生成如上图右侧所示的DSL规则，以json格式表示，对前端更友好，也可以转化为存储引擎的查询语句。标签是部分自动化的。人群圈子选择的自动化程度比较高。比如分组刷新，每天定时刷新；高级计算，例如组间的交集/合并/差异；数据清理，及时清理过期和失效的实体集。03标签存储下面介绍我们在标签存储方面的做法。严选DMP标签系统需要承载比较大的C端流量，对实时性要求比较高。我们对存储的需求包括：支持高性能查询，应对大规模C端流量支持SQL，轻松应对数据分析场景支持数据更新机制，存储海量数据支持扩展功能，处理自定义数据结构和大数据生态紧密结合目前还没有完全满足要求的存储。我们第一版的存储架构如下图所示：离线数据大部分存储在hive中，一小部分存储在hbase中（主要用于查询基础标签）。实时数据一部分存储在hbase中用于基础标签查询，一部分双写到KUDU和ES中用于实时选组和数据查询。离线选择的数据由impala计算并缓存在redis中。这个版本的缺点包括：存储引擎太多。双写存在数据质量隐患，可能一方成功，另一方失败，造成数据不一致。项目复杂，可维护性差。为了减少引擎和存储的使用，提高项目的可维护性，版本2在版本1的基础上进行了改进和实现。存储架构版本2引入了ApacheDoris。离线数据主要存储在HIVE中。同时将基础标签导入Doris，实时数据也存储在Doris。基于Spark进行HIVE和Doris的联合查询，计算结果存储在redis中。中间。该版本改进后，统一了实时离线引擎存储，性能损失在可承受范围内（Hbase的查询性能优于doris，可以控制在10ms以内。Doris目前是1.0版本，p99，查询性能可以控制在20ms以内，p999，可以控制在50ms以内）；简化了工程，降低了运维成本。在大数据领域，各种存储和计算引擎都有各自的适用场景，如下表所示：04高性能查询分组存在性判断：判断用户是在指定的分组中还是在多个分组中。由两部分组成：第一部分是静态人群包，预先计算好存储在redis中（key是实体的id，value是结果集的id），使用lua脚本用于批量判断以提高性能；第二部分是实时的Behavior组需要从context、API和ApacheDoris中抽取数据进行规则判断。性能提升方案包括异步查询、快速短路、查询优化、控制连接表数量等。另一种场景是人群分析：人群分析需要多表联合查询人群包数据，分析行为路径。目前doris不支持路径分析功能，所以我们开发了dorisUDF来支持这个业务。doris的计算模型对于自定义函数的开发还是很友好的，可以更好的满足我们的性能需求。ApacheDoris已在网易严选应用，用于查询、批量查询、路径分析、人群选择等场景。在实践中有以下优势：(1)抽查和少量表联合查询性能超过10000QPS，RT99<50MS。(2)横向扩展能力很强，运维成本相对较低。(3)离线数据和实时数据统一，降低标签模型的复杂度。缺点是大量小数据的导入任务占用资源较多，性能有待优化。05未来规划(1)提升存储计算性能HIVE和Spark逐渐转向ApacheDoris。（2）优化标签体系建立丰富准确的标签评价体系提高标签质量和输出速度提高标签覆盖率（3）更精准的运营建立丰富的用户分析模型，从使用频率和用户价值两个方面提升用户洞察模型评估系统建立广义画像分析能力，辅助运营智能决策。今天的分享就到这里，谢谢大家。
