ZDH-智能营销-标签模块

目录

主题

项目源码

预览地址

安装包下载地址

标签模块

什么是标签

标签场景分类

标签设计

标签按照场景做了分类，但是运营人员需要感知到吗

标签按照场景做了分类，底层的计算引擎是否需要划分？

标签模块，是否需要涉及到大数据，及大数据相关的技术栈？

标签数据结构

标签计算引擎

标签应用场景

 总结

感谢支持

---

主题

本篇文章主要介绍ZDH-智能营销-标签模块,主要包含标签模块的设计和使用场景

项目源码

zdh_web: GitHub - zhaoyachao/zdh_web: 大数据采集,抽取平台 

zdh_magic_mirror:https://github.com/zhaoyachao/zdh_magic_mirror

预览地址

后台管理-登陆

用户名：zyc
密码：123456

安装包下载地址

需要用户下载源码自行编译,源码见上方项目源码

标签模块

    标签模块-是智能营销下的一个功能模块，主要用于从海量数据中，根据指定的标签规则筛选数据，我们的场景是营销，这个标签模块对应的功能就是筛选用户

什么是标签

    一般情况可以理解为物品在某个维度上的分类，举个简单的例子，超市有很多商品，按照物品的分类可以有，电子类，食物，家居等，这里面的电子,食物，家居 就可以理解为是商品的一种标签，我们可以根据标签值筛选对应的商品

标签场景分类

    通过上方标签的解释我们大致了解了标签的含义，那么标签在我们这套经营/风控系统中扮演了什么角色呢

    标签在我们系统扮演了数据筛选的角色，通过标签，任何运营人员都可以筛选到想要的数据(前提你的标签做的足够全面，且相对合规)，且不需要任何开发人员的介入（任何事情都没有绝对，只是在使用相对合理的方案，个人认为开发人员有责任保证数据的准确性，而运营人员有责任保证数据的应用场景准确）

    从数据的时效和应用场景 当前系统将标签分为值查人(离线)和人查值(实时)2类标签，下方是2类标签的例子

    值查人：经营场景中，在生日当天，送上祝福，以1月1为例子，查询1月1日生日的用户，通过邮箱发送祝福，这里面，通过生日标签且根据标签值等于1月1的 就是值查人的场景，简单来说就是根据已知结果查询满足条件的数据

    人查值：一般在时效性高,等场景中使用，同样以生日当天，送上祝福为例，用户登录了我们网站或者app, 这里触发一个检查，检查当前用户在当天是否生日，如果生日弹出祝福语，这里面检查用户是否在当天生日，就是人查值的场景，简单来说，我目前有一个数据和一个结果，我需要验证数据和结果是否匹配

     由于标签分类太长，下方我们以离线，实时对标签做划分

标签设计

    我们已经了解了标签和标签的场景分类，那么作为一个开发人员，应该如何设计我们的标签模块呢，在设计之前，我们先抛出几个问题

    标签按照场景做了分类，但是运营人员需要感知到吗？

    标签按照场景做了分类，底层的计算引擎是否需要划分？

    标签模块，是否需要涉及到大数据，及大数据相关的技术栈？

标签按照场景做了分类，但是运营人员需要感知到吗

    标签做了分类后，必然要维护分类的数据，运营人员可以不感知底层的标签引擎，但是运营人员需要根据业务场景选择对应的标签，在理想模式下，我们的离线标签和在线标签是一一对应的，但是可能会存在外部原因，比如预算不足，没有在线场景，领导说我们就用离线标签，其他的我们不用等等问题，从而导致差异化，因此需要运营人员配合做相应的配置，运营人员需要感知

标签按照场景做了分类，底层的计算引擎是否需要划分？

    需要划分，一般来讲，离线类的计算引擎会比在线类的计算引擎便宜很多，且在线和离线对应的场景不同，对计算引擎的要求也不同，因此需要划分

标签模块，是否需要涉及到大数据，及大数据相关的技术栈？

    这个需要根据数据量级，场景来决定，但是我们的设想是构建一个轻量级的标签体系，如果涉及到大数据相关技术会变得复杂，因此我们的系统采用了历史上非常通用的引擎类(jdbc标准)，和redis, 所以我们的系统不是非常完善的，不适合超大量或者超复杂的计算(个人当前的想法是以空间换时间，对应复杂的计算采用中间数据来减少复杂量，对应超大量的数据，应当对数据进行预划分)

标签数据结构

    以当前平台的为例，标签主要包含分类，数据源，计算规则，默认值，参数

    数据源：描述标签数据的来源，计算时会使用，这里的数据源复用了etl模块的数据源能力

    计算规则：当前平台以jdbc计算为主，多数计算规则都是sql, 通过定义sql的参数用来进行筛选

    参数：对运营人员暴露标签时，运营人员可自主配置的参数值

    默认值：一般对在线标签生效，在线标签存储结构见下方图2，以k-v方式存储

标签计算引擎

    标签的计算引擎主要是jdbc和redis

    jdbc是一个标准，只要任何满足jdbc标准的服务都是可以作为标签的计算引擎（理论上都支持，但是需要扩展，因不同jdbc服务有语法差异，当前服务支持，mysql, hive, presto语法）

    redis是一个内存kv库，性能能满足多数场景，使用redis,是其生态和产品方案相对完善，用redis做在线标签的计算引擎，在redis中只对数据进行存储，存储结构为redis中的map结构，具体结构可参考上方redis数据图，以用户ID做为一级KEY, 标签code做为二级KEY, 具体的参数及值作为二级KEY对应的值

标签应用场景

    当我们有了基础的标签模块之后，我们会用标签做什么呢？其实这是一个没有答案的问题，平台提供了标签，并没有定义具体做什么，从平台能力上来讲，基于标签可以做，用户经营，风控，或者客户画像，如果基于当前标签做一个http服务，那么甚至可以通过BI系统来展示使用这些标签

     以当前平台的经营为例子，我们通过标签筛选数据之后，可以对这批数据做相应的经营动作(邮件，短信等)，当然这不仅仅是标签模块的能力了，也会涉及到其他模块，标签模块是其他模块的数据来源

 总结

    标签模块是zdh平台的重要组成部分，标签模块的功能主要是用来筛选数据，在不同的应用场景中通过使用不同的标签来满足数据筛选，标签模块是zdh中多数模块的数据源头

感谢支持

如果觉得项目有意思可以在github上给个星星和fork, 也可以分享给朋友，  zdh_web:https://github.com/zhaoyachao/zdh_web