导读：如果说互联网的上半场是粗狂经营，那么在下半场，精细化经营将是短暂的主题，有数据分析能力能力让用户失去更好的体验。当下比拟典型的剖析形式是构建用户标签零碎，本文将由网易严选分享 DMP 标签零碎的建设以及 Apache Doris 在其中的利用实际。
作者 | 刘晓东 网易严选资深开发工程师
如果说互联网的上半场是粗狂经营，因为有流量红利不须要思考细节。那么在下半场，精细化经营将是短暂的主题，有数据分析能力能力让用户失去更好的体验。当下比拟典型的剖析形式是构建用户标签零碎，从而精准地生成用户画像，晋升用户体验。明天分享的主题是网易严选 DMP 标签零碎建设实际，次要围绕上面五点开展：
- 平台总览
- 标签生产：标签圈选 & 生产链路
- 标签存储：存储形式 & 存储架构演进
- 高性能查问
- 将来布局
平台总览
DMP 作为网易严选的数据中台，向下连贯数据，向上赋能业务，承当着十分重要的基石角色。
DMP 的数据起源次要包含三大部分：
- 自营平台的 APP、小程序、PC 端等各端的业务日志
- 网易团体外部共建的一些根底数据
- 京东、淘宝、抖音等第三方渠道店铺的数据
通过收集、荡涤，将以上数据造成数据资产积淀下来。DMP 在数据资产根底上造成了一套本人的标签产出、人群圈选和用户画像剖析体系，从而为业务提供撑持，包含：智能化的选品、精准触达以及用户洞察等。总的来说，DMP 零碎就是构建以数据为外围的标签体系和画像体系，从而辅助业务做一系列精细化的经营。
理解 DMP 零碎，先从以下几个概念开始。
- 标签：对于实体（用户、设施、手机号等）特色的形容，是一种面向业务的数据组织模式，比方应用：年龄段、地址、偏好类目等对用户实体进行刻画。
- 人群圈选：通过条件组合从整体用户中圈选出一部分用户，具体就是指定一组用户标签和其对应的标签值，失去符合条件的用户人群。
- 画像剖析：对于人群圈选后果，查看该人群的行为状况、标签散布。例如查看【城市为杭州，且性别为女性】的用户在严选 APP 上的行为门路、生产模型等。
严选标签零碎对外次要提供两大外围能力：
- 标签查问：查问特定实体指定标签的能力，罕用于根本信息的展现。
- 人群圈选：分为实时和离线圈选。圈选后果次要用于：
- 分组判断：判读用户是否在指定的一个或多个分组，资源投放、触点营销等场景应用较多。
- 后果集拉取：拉取指定的人群数据到业务方零碎中，进行定制化开发。
- 画像剖析：剖析特定人群的行为数据，生产模型等，进行更精密的经营。
整体的业务流程如下：
- 首先定义标签和人群圈选的规定；
- 定义出形容业务的 DSL 之后，便能够将工作提交到 Spark 进行计算；
- 计算实现之后，将计算结果存储到 Hive 和 Doris；
- 之后业务不便能够依据理论业务需要 从 Hive 或 Doris 中查问应用数据。
DMP 平台整体分为计算存储层、调度层、服务层、和元数据管理四大模块。
所有的标签元信息存储在源数据表中；调度层对业务的整个流程进行任务调度：数据处理、聚合转化为根底标签，根底标签和源表中的数据通过 DSL 规定转化为可用于数据查问的 SQL 语义，由调度层将任务调度到计算存储层的 Spark 进行计算，将计算结果存储到 Hive 和 Doris 中。服务层由标签服务、实体分组服务、根底标签数据服务、画像剖析服务四局部组成。
标签的生命周期蕴含 5 个阶段：
- 标签需要：在此阶段，经营提出标签的需要和价值预期，产品评估需要合理性以及紧迫性。
- 排期生产：此阶段须要数据开发梳理数据，从 ods 到 dwd 到 dm 层整个链路，依据数据建设模型，同时数据开发须要做好品质监控。
- 人群圈选：标签生产进去之后进行利用，圈选出标签对应的人群。
- 精准营销：对圈选进去的人群进行精准化营销。
- 成果评估：最初产品、数据开发和经营对标签使用率、应用成果进行成果评估来决定后续对标签进行改良或降级。
总的来说，就是以业务增长为指标，围绕标签的生命周期，投入正当的资源，最大化经营成果。
标签生产
接下来介绍标签生产的整个过程。
标签的数据分层：
- 最上层是 ods 层，包含用户登录日志、埋点记录日志、交易数据以及各种数据库的 Binlog 数据。
- 对 ods 层解决后的数据达到 dwd 明细层，包含用户登录表、用户流动表、订单信息表等。
- dwd 层数据聚合后到 dm 层，标签全副基于 dm 层数据实现。
目前咱们从原始数据库到 ods 层数据产出曾经齐全自动化，从 ods 层到 dwd 层实现了局部自动化，从 dwd 到 dm 层有一部分自动化操作，但自动化水平还不高，这部分的自动化操作是咱们接下来的工作重点。
标签依据时效性分为：离线标签、近实时标签和实时标签。
依据聚合粒度分为：聚合标签和明细标签。
通过类别维度可将标签分为：账号属性标签、消费行为标签、沉闷行为标签、用户偏好标签、资产信息标签等。
间接将 dm 层的数据不太不便拿来用，起因在于：
根底数据比拟原始，抽象层次有所欠缺、应用绝对繁琐。通过对根底数据进行与、或、非的组合，造成业务标签供业务方应用，能够升高经营的了解老本，升高应用难度。
标签组合之后须要对标签进行具体业务场景利用，如人群圈选。配置如上图左侧所示，反对离线人群包和实时行为（须要离开配置）。
配置完后，生成上图右侧所示的 DSL 规定，以 Json 格局表白，对前端比拟敌对，也能够转成存储引擎的查问语句。
标签有一部分实现了自动化。在人群圈选局部自动化水平比拟高。比方分组刷新，每天定时刷新；高级计算，如分组与分组间的交 / 并 / 差集；数据清理，及时清理过期生效的实体集。
标签存储
上面介绍一下咱们在标签存储方面的实际。
严选 DMP 标签零碎须要承载比拟大的 C 端流量，对实时性要求也比拟高。
咱们对存储的要求包含：
- 反对高性能查问，以应答大规模 C 端流量
- 反对 SQL，便于应答数据分析场景
- 反对数据更新机制
- 可存储大数据量
- 反对扩大函数，以便解决自定义数据结构
- 和大数据生态联合严密
目前还没有一款存储可能齐全满足要求。
咱们第一版的存储架构如下图所示：
离线数据大部分存储在 Hive 中，小局部存储在 Hbase（次要用于根底标签的查问）。实时数据一部分存储在 Hbase 中用于根底标签的查问，局部双写到 KUDU 和 ES 中，用于实时分组圈选和数据查问。离线圈选的数据通过 impala 计算出来缓存在 Redis 中。
这一版本的毛病包含：
- 存储引擎过多。
- 双写有数据品质隐患，可能一方胜利一方失败，导致数据不统一。
- 我的项目简单，可维护性较差。
为了缩小引擎和存储的使用量，进步我的项目可维护性，在版本一的根底上改良实现了版本二。
咱们第二版的存储架构如下图所示：
存储架构版本二引入了 Apache Doris，离线数据次要存储在 Hive 中，同时将根底标签导入到 Doris，实时数据也存储在 Doris，基于 Spark 做 Hive 加 Doris 的联结查问，并将计算出来的后果存储在 Redis 中。通过此版改良后，实时离线引擎存储失去了对立，性能损失在可容忍范畴内（Hbase 的查问性能比 Doris 好一些，能管制在 10ms 以内，Doris 目前是 1.0 版本，p99，查问性能能管制在 20ms 以内，p999，能管制在 50ms 以内）；我的项目简化，升高了运维老本。
在大数据畛域，各种存储计算引擎有各自的实用场景，如下表所示：
高性能查问
分组存在性判断：判断用户是否在指定的一个分组或者多个分组。包含两大部分：
- 第一部分为动态人群包，提前进行预计算，存入 Redis 中（Key 为实体的 ID，Value 为后果集 ID），采纳 Lua 脚本进行批量判断，晋升性能；
- 第二局部为实时行为人群，须要从上下文、API 和 Apache Doris 中提取数据进行规定判断。性能晋升计划包含，异步化查问、疾速短路、查问语句优化、管制 Join 表数量等。
还有一个场景是人群剖析：人群剖析须要将人群包数据同多个表进行联结查问，剖析行为门路。目前 Doris 还不反对路径分析函数，因而咱们开发了 DorisUDF 来反对此业务。Doris 的计算模型对自定义函数的开发还是很敌对的，可能比拟好地满足咱们的性能须要。
Apache Doris 在网易严选中已利用于点查、批量查问、路径分析、人群圈选等场景。在实践中具备以下劣势：
- 在点查和大量表的联结查问性能 QPS 超过万级，RT99<50MS。
- 程度扩大能力很强，运维老本绝对比拟低。
- 离线数据和实时数据相对立，升高标签模型复杂度。
不足之处在于大量小数据量的导入工作资源占用较多，待 Doris 1.1.2 版本正式公布后咱们也会及时同步降级。不过此问题曾经在 Doris 1.1 版本中进行了优化，Doris 在 1.1 中大幅加强了数据 Compaction 能力，对于新增数据可能疾速实现聚合，防止分片数据中的版本过多导致的 -235 谬误以及带来的查问效率问题。
具体能够参考：Apache Doris 1.1 个性揭秘：Flink 实时写入如何兼顾高吞吐和低延时
将来布局
晋升存储 & 计算性能：Hive 和 Spark 逐步全副转向 Apache Doris。
优化标签体系：
- 建设丰盛精确的标签评估体系
- 晋升标签品质和产出速度
- 晋升标签覆盖率
更精准的经营
- 建设丰盛的用户分析模型
- 从应用频次和用户价值两个方面晋升用户洞察模型评估体系
- 建设通用化画像剖析能力，辅助经营智能化决策
材料下载
关注公众号「SelectDB」，后盾回复【网易严选】获取本次演讲 PPT 材料！
如果你对 Apache Doris 感兴趣，请点击「浏览原文 」理解并退出 Doris！咱们也发动了 征文活动 ， 邀你讲讲与 Doris 相遇 相知 相识的故事，不仅有精美礼品相送，还可取得 SelectDB 全渠道曝光加持！
最初，欢送更多的开源技术爱好者退出 Apache Doris 社区，携手成长，共建社区生态。
SelectDB 是一家开源技术公司，致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris 研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。
相干链接：
SelectDB 官方网站：
https://selectdb.com
Apache Doris 官方网站：
http://doris.apache.org
Apache Doris Github：
https://github.com/apache/doris
Apache Doris 开发者邮件组：
dev@doris.apache.org 导读：如果说互联网的上半场是粗狂经营，那么在下半场，精细化经营将是短暂的主题，有数据分析能力能力让用户失去更好的体验。当下比拟典型的剖析形式是构建用户标签零碎，本文将由网易严选分享 DMP 标签零碎的建设以及 Apache Doris 在其中的利用实际。
作者 | 刘晓东 网易严选资深开发工程师
如果说互联网的上半场是粗狂经营，因为有流量红利不须要思考细节。那么在下半场，精细化经营将是短暂的主题，有数据分析能力能力让用户失去更好的体验。当下比拟典型的剖析形式是构建用户标签零碎，从而精准地生成用户画像，晋升用户体验。明天分享的主题是网易严选 DMP 标签零碎建设实际，次要围绕上面五点开展：
- 平台总览
- 标签生产：标签圈选 & 生产链路
- 标签存储：存储形式 & 存储架构演进
- 高性能查问
- 将来布局
平台总览
DMP 作为网易严选的数据中台，向下连贯数据，向上赋能业务，承当着十分重要的基石角色。
DMP 的数据起源次要包含三大部分：
- 自营平台的 APP、小程序、PC 端等各端的业务日志
- 网易团体外部共建的一些根底数据
- 京东、淘宝、抖音等第三方渠道店铺的数据
通过收集、荡涤，将以上数据造成数据资产积淀下来。DMP 在数据资产根底上造成了一套本人的标签产出、人群圈选和用户画像剖析体系，从而为业务提供撑持，包含：智能化的选品、精准触达以及用户洞察等。总的来说，DMP 零碎就是构建以数据为外围的标签体系和画像体系，从而辅助业务做一系列精细化的经营。
理解 DMP 零碎，先从以下几个概念开始。
- 标签：对于实体（用户、设施、手机号等）特色的形容，是一种面向业务的数据组织模式，比方应用：年龄段、地址、偏好类目等对用户实体进行刻画。
- 人群圈选：通过条件组合从整体用户中圈选出一部分用户，具体就是指定一组用户标签和其对应的标签值，失去符合条件的用户人群。
- 画像剖析：对于人群圈选后果，查看该人群的行为状况、标签散布。例如查看【城市为杭州，且性别为女性】的用户在严选 APP 上的行为门路、生产模型等。
严选标签零碎对外次要提供两大外围能力：
- 标签查问：查问特定实体指定标签的能力，罕用于根本信息的展现。
- 人群圈选：分为实时和离线圈选。圈选后果次要用于：
- 分组判断：判读用户是否在指定的一个或多个分组，资源投放、触点营销等场景应用较多。
- 后果集拉取：拉取指定的人群数据到业务方零碎中，进行定制化开发。
- 画像剖析：剖析特定人群的行为数据，生产模型等，进行更精密的经营。
整体的业务流程如下：
- 首先定义标签和人群圈选的规定；
- 定义出形容业务的 DSL 之后，便能够将工作提交到 Spark 进行计算；
- 计算实现之后，将计算结果存储到 Hive 和 Doris；
- 之后业务不便能够依据理论业务需要 从 Hive 或 Doris 中查问应用数据。
DMP 平台整体分为计算存储层、调度层、服务层、和元数据管理四大模块。
所有的标签元信息存储在源数据表中；调度层对业务的整个流程进行任务调度：数据处理、聚合转化为根底标签，根底标签和源表中的数据通过 DSL 规定转化为可用于数据查问的 SQL 语义，由调度层将任务调度到计算存储层的 Spark 进行计算，将计算结果存储到 Hive 和 Doris 中。服务层由标签服务、实体分组服务、根底标签数据服务、画像剖析服务四局部组成。
标签的生命周期蕴含 5 个阶段：
- 标签需要：在此阶段，经营提出标签的需要和价值预期，产品评估需要合理性以及紧迫性。
- 排期生产：此阶段须要数据开发梳理数据，从 ods 到 dwd 到 dm 层整个链路，依据数据建设模型，同时数据开发须要做好品质监控。
- 人群圈选：标签生产进去之后进行利用，圈选出标签对应的人群。
- 精准营销：对圈选进去的人群进行精准化营销。
- 成果评估：最初产品、数据开发和经营对标签使用率、应用成果进行成果评估来决定后续对标签进行改良或降级。
总的来说，就是以业务增长为指标，围绕标签的生命周期，投入正当的资源，最大化经营成果。
标签生产
接下来介绍标签生产的整个过程。
标签的数据分层：
- 最上层是 ods 层，包含用户登录日志、埋点记录日志、交易数据以及各种数据库的 Binlog 数据。
- 对 ods 层解决后的数据达到 dwd 明细层，包含用户登录表、用户流动表、订单信息表等。
- dwd 层数据聚合后到 dm 层，标签全副基于 dm 层数据实现。
目前咱们从原始数据库到 ods 层数据产出曾经齐全自动化，从 ods 层到 dwd 层实现了局部自动化，从 dwd 到 dm 层有一部分自动化操作，但自动化水平还不高，这部分的自动化操作是咱们接下来的工作重点。
标签依据时效性分为：离线标签、近实时标签和实时标签。
依据聚合粒度分为：聚合标签和明细标签。
通过类别维度可将标签分为：账号属性标签、消费行为标签、沉闷行为标签、用户偏好标签、资产信息标签等。
间接将 dm 层的数据不太不便拿来用，起因在于：
根底数据比拟原始，抽象层次有所欠缺、应用绝对繁琐。通过对根底数据进行与、或、非的组合，造成业务标签供业务方应用，能够升高经营的了解老本，升高应用难度。
标签组合之后须要对标签进行具体业务场景利用，如人群圈选。配置如上图左侧所示，反对离线人群包和实时行为（须要离开配置）。
配置完后，生成上图右侧所示的 DSL 规定，以 Json 格局表白，对前端比拟敌对，也能够转成存储引擎的查问语句。
标签有一部分实现了自动化。在人群圈选局部自动化水平比拟高。比方分组刷新，每天定时刷新；高级计算，如分组与分组间的交 / 并 / 差集；数据清理，及时清理过期生效的实体集。
标签存储
上面介绍一下咱们在标签存储方面的实际。
严选 DMP 标签零碎须要承载比拟大的 C 端流量，对实时性要求也比拟高。
咱们对存储的要求包含：
- 反对高性能查问，以应答大规模 C 端流量
- 反对 SQL，便于应答数据分析场景
- 反对数据更新机制
- 可存储大数据量
- 反对扩大函数，以便解决自定义数据结构
- 和大数据生态联合严密
目前还没有一款存储可能齐全满足要求。
咱们第一版的存储架构如下图所示：
离线数据大部分存储在 Hive 中，小局部存储在 Hbase（次要用于根底标签的查问）。实时数据一部分存储在 Hbase 中用于根底标签的查问，局部双写到 KUDU 和 ES 中，用于实时分组圈选和数据查问。离线圈选的数据通过 impala 计算出来缓存在 Redis 中。
这一版本的毛病包含：
- 存储引擎过多。
- 双写有数据品质隐患，可能一方胜利一方失败，导致数据不统一。
- 我的项目简单，可维护性较差。
为了缩小引擎和存储的使用量，进步我的项目可维护性，在版本一的根底上改良实现了版本二。
咱们第二版的存储架构如下图所示：
存储架构版本二引入了 Apache Doris，离线数据次要存储在 Hive 中，同时将根底标签导入到 Doris，实时数据也存储在 Doris，基于 Spark 做 Hive 加 Doris 的联结查问，并将计算出来的后果存储在 Redis 中。通过此版改良后，实时离线引擎存储失去了对立，性能损失在可容忍范畴内（Hbase 的查问性能比 Doris 好一些，能管制在 10ms 以内，Doris 目前是 1.0 版本，p99，查问性能能管制在 20ms 以内，p999，能管制在 50ms 以内）；我的项目简化，升高了运维老本。
在大数据畛域，各种存储计算引擎有各自的实用场景，如下表所示：
高性能查问
分组存在性判断：判断用户是否在指定的一个分组或者多个分组。包含两大部分：
- 第一部分为动态人群包，提前进行预计算，存入 Redis 中（Key 为实体的 ID，Value 为后果集 ID），采纳 Lua 脚本进行批量判断，晋升性能；
- 第二局部为实时行为人群，须要从上下文、API 和 Apache Doris 中提取数据进行规定判断。性能晋升计划包含，异步化查问、疾速短路、查问语句优化、管制 Join 表数量等。
还有一个场景是人群剖析：人群剖析须要将人群包数据同多个表进行联结查问，剖析行为门路。目前 Doris 还不反对路径分析函数，因而咱们开发了 DorisUDF 来反对此业务。Doris 的计算模型对自定义函数的开发还是很敌对的，可能比拟好地满足咱们的性能须要。
Apache Doris 在网易严选中已利用于点查、批量查问、路径分析、人群圈选等场景。在实践中具备以下劣势：
- 在点查和大量表的联结查问性能 QPS 超过万级，RT99<50MS。
- 程度扩大能力很强，运维老本绝对比拟低。
- 离线数据和实时数据相对立，升高标签模型复杂度。
不足之处在于大量小数据量的导入工作资源占用较多，待 Doris 1.1.2 版本正式公布后咱们也会及时同步降级。不过此问题曾经在 Doris 1.1 版本中进行了优化，Doris 在 1.1 中大幅加强了数据 Compaction 能力，对于新增数据可能疾速实现聚合，防止分片数据中的版本过多导致的 -235 谬误以及带来的查问效率问题。
具体能够参考：Apache Doris 1.1 个性揭秘：Flink 实时写入如何兼顾高吞吐和低延时
将来布局
晋升存储 & 计算性能：Hive 和 Spark 逐步全副转向 Apache Doris。
优化标签体系：
- 建设丰盛精确的标签评估体系
- 晋升标签品质和产出速度
- 晋升标签覆盖率
更精准的经营
- 建设丰盛的用户分析模型
- 从应用频次和用户价值两个方面晋升用户洞察模型评估体系
- 建设通用化画像剖析能力，辅助经营智能化决策
材料下载
关注公众号「SelectDB」，后盾回复【网易严选】获取本次演讲 PPT 材料！
如果你对 Apache Doris 感兴趣，请点击「浏览原文 」理解并退出 Doris！咱们也发动了 征文活动 ， 邀你讲讲与 Doris 相遇 相知 相识的故事，不仅有精美礼品相送，还可取得 SelectDB 全渠道曝光加持！
最初，欢送更多的开源技术爱好者退出 Apache Doris 社区，携手成长，共建社区生态。
SelectDB 是一家开源技术公司，致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris 研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。
相干链接：
SelectDB 官方网站：
https://selectdb.com
Apache Doris 官方网站：
http://doris.apache.org
Apache Doris Github：
https://github.com/apache/doris
Apache Doris 开发者邮件组：
dev@doris.apache.org