1. Toy模板网首页
  2. > Toy博客

flink规则引擎设计思路

9月前 作者：woloqun 分类：Toy博客 阅读(37) 违法举报

这篇具有很好参考价值的文章主要介绍了flink规则引擎设计思路。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

在日常工作中我们经常收到一些诸如此类需求：“用户给点击了开屏广告，给用户下发私信”、“用户进入了推荐线，但在60秒内没有任何点击操作，弹框引导用户选择感兴趣的内容”、“用户点赞了某位作者的两篇以上的内容，但并没有关注过此作者，则弹框引导用户关注作者”、“用户点击了活动入口，进入了活动页、发生了点赞、收藏等交互操作，引导用户进入活动下一流程”。这些需求大致可以分为如下三大类：

  • 完成事件A，触发运营动作。
  • 完成时间A多次，触发运营动作。
  • 在固定时间内完成事件A，但未完成事件B，触发运营动作。
  • 依次完成事件A,B,C，触发运营动作。

这些需求从开发角度来看，代码有很高的相似性，所以我们对这些需求进行了抽象，基于flink开发了一套行为规则引擎，并在规则引擎之上将常用的运营动作模块化，真正做到十分钟上线一个运营策略，相对之前天级别的交付时间，效率大幅提升。
  
先看下规则引擎整体的架构：
flink规则引擎设计思路
一个任务上线，从“数据流输入”到“用户触达”，整个任务流程分为6个阶段：输入事件流、数据准备、规则平台、维度数据、规则引擎、用户触达系统。

输入事件流
数据主要来自于行为日志，也就是用户通过sdk上报的埋点数据以及后端埋点数据。为了后规则引擎易于处理，通常会对一些嵌套数据进行扁平化操作。

数据准备
这个阶段的主要工作就是为规则引擎准备输入数据，分为四个步骤：数据预处理、数据预过滤、数据流维度补充、数据流分区。

规则平台
规则平台面向的用户主要是运营。运营人员通过规则平台配置运营策略。规则平台会将这些规则分发给规则引擎，规则引擎将规则转换成处理逻辑。

维度数据
维度数据包含三部分：画像数据、业务库数据以及用户历史行为数据。这些数据在数据准备阶段会填充到数据流中，后续会介绍。

规则引擎
目前规则引擎支持四种规则类型，在实现上分别对应一个flink程序：

  • 完成事件A
  • 完成事件A多次
  • 完成事件A、未完成事件B
  • 依次完成事件A、B、C、D

接下来我们通过举例，从易到难的方式，介绍规则引擎的数据处理流程。

第一个例子：用户发生点赞行为（规则类型1）
输入数据流：

{
    "uid":111,
    "oid":"562asdf12",
    "action":"like",
    "time":"1672383110"
}

这条数据意思为：用户（uid:111）在时间（time:1672383110）对内容（oid:562asdf12）进行了点赞操作（action:like）,这个场景再简单不过了。
我们需要通过规则平台告诉规则引擎如何处理这个需求，例如我们先定义了一个能满足当前需求的规则串

{
    "rule_id":"00001",
    "rule_type":"1",
    "conditions":{
        "action":"like"
    }
}

稍微解释字段含义

rule_id:规则id，规则唯一标识
rule_type:规则类型，当前规则为“完成事件A”，故该值为“1”.
conditions：规则引擎需要判定条件。
在这个例子中flink规则引擎只要判断数据流中的action的值是否为“like”。

第二个例子：用户触发点赞行为2次。（规则类型2）
和第一个例子不一样的地方在于这个例子出现计数场景。先看下规则串和之前的例子有什么不同

{
    "rule_id":"000012",
    "rule_type":"2",
    "pk":"rule_id::uid",
    "conditions":{
        "action":"like",
        "eventCount":"eq:2"
    }
}

rule_type:2,告诉规则引擎这是个”完成事件A多次“的任务，并且规则串新增属性pk、eventCount。‘pk’代表分区键，对应这flink程序中keyby中的字段，“eventCount”:"eq:2"在这个例子中代表：点赞次数等于2

第三个例子：用户给同一作者文章点赞超过2次（规则类型2）
在这个例子中需要用到作者信息，但是数据流中并没有。这就需要介绍下”数据预处理“部分。

”数据预处理“阶段会干两件事：补充数据主体、数据扁平化。
数据主体什么意思？对于一款UGC产品，最核心的主体包括：用户、内容、作者等。电商产品，主体包括：用户、商家、商品、品牌等。在我们的规则引擎里，数据主体通常作为关联数据的主键id，所以在数据预处理阶段，我们需要尽可能的将数据主体梳理全，并补充到数据中。在这个例子中我们可以通过oid，把作者id补充到数据中去。

{
    "uid":111,
    "oid":"562asdf12",
    "action":"like",
    "time":"1672383110",
    "author_id":12454
}

“数据扁平化”：为了让规则引擎更好的处理数据，我们会在数据预处理阶段把嵌套的数据进行扁平化操作。

回到例子，规则串可以如下描述

{
    "rule_id":"000012",
    "rule_type":"2",
    "pk":"rule_id::uid::author_id",
    "conditions":{
        "action":"like",
        "eventCount":"gt:2"
    }
}

和第二个例子中唯一不同的是，把author_id添加到分区键pk中,flink程序会按照"rule_id::uid::author_id"进行keyby操作，这样就可以进行计数操作了。

第四个例子：用户给同一作者文章点赞超过2次，但没有关注作者。

在此例子中涉及到了主体之间的关系，而“用户”和“作者”之间的关系存在数据库中，在数据处理过程中，这些数据是怎么使用的？这里就需要介绍下”维度数据“模块。”维度数据“主要包含3中类型数据：画像数据、业务库数据和用户历史行为数据。
画像数据：这个比较好理解，主要是用户相关的属性信息，例如：性别，城市，年龄等。
业务库数据：这种数据需要通过业务库获得，在这个例子中，用户是否关注了作者属于这个范畴。
历史行为数据：在有些规则场景中我们会需要用户的一些历史数据进行计算，例如：”用户在过去一周内访问过活动页，并且进行了内容生产“。通常我们会通过离线计算的方式，将数据导入到维度数据中。

”维度数据“通常使用键值数据库存储，例如：redis，hbase等。维度数据生成的方式有两种：通过规则平台从业务库中自动同步到键值数据库，或者直接通过代码的方式。
回到这个例子中，先看下规则串有什么不一样

{
    "rule_id":"000012",
    "rule_type":"2",
    "pk":"rule_id::uid::author_id",
    "dimKey":{
        "isAttention":"uid,author_id"
    },
    "conditions":{
        "action":"like",
        "isAttention":false,
        "eventCount":"gt:2"
    }
}

dimKey:这个字段中的”isAttention“代表要新增的维度数据，在这个例子中代表”没有关注作者“，这个字段在规则平台维护。"uid,author_id"意思是flink程序需要通过数据流中的uid和author_id去”维度数据“中获得isAttention的值。

在规则串里我们只是定义了isAttention的获取方式，那数据是填充的据流程是怎么样的？这里涉及到两个模块：“数据预过滤”和“数据流维度补充”。

数据预过滤:
在该阶段“数据准备”的flink程序会根据规则平台中的规则，对数据流进行过滤（将数据流中的“action”值与规则平台维护的规则中的”action“进行比对）数据过滤后，数据流中只包含规则相关的数据。
除此之外，flink程序还会把规则填充到数据流中。例如：规则平台维护了三条规则

{
    "rule_id":"00001",
    "rule_type":"1",
    "conditions":{
        "action":"like"
    }
}

{
    "rule_id":"00002",
    "rule_type":"1",
    "conditions":{
        "action":"share"
    }
}

{
    "rule_id":"00003",
    "rule_type":"2",
    "pk":"rule_id::uid::author_id",
    "dimKey":{
        "isAttention":"uid,author_id"
    },
    "conditions":{
        "action":"like",
        "isAttention":false,
        "eventCount":"gt:2"
    }
}

有三条数据进入到flink程序，

{"uid":111, "oid":"562asdf12","action":"like", "time":"1672383110","author_id":12454}
{"uid":111, "oid":"562asdf12","action":"share", "time":"1672383412","author_id":12454}
{"uid":113, "oid":"562asdf12","action":"comment", "time":"1672383412","author_id":12454}

经过数据预过滤后，数据输出如下

{"uid":111,"oid":"562asdf12","action":"like","time":"1672383110","rule":{"rule_id":"00001","rule_type":"1","conditions":{"action":"like"}}}

{"uid":111,"oid":"562asdf12","action":"like","time":"1672383110","rule":{"rule_id":"00003","rule_type":"2","action":"like","pk":"rule_id::uid::author_id","dimKey":{"isAttention":"uid,author_id"},"conditions":{"isAttention":false,"eventCount":"gt:2"}}}

{"uid":111,"oid":"562asdf12","action":"share","time":"1672383412","rule":{"rule_id":"00002","rule_type":"1",,"conditions":{"action":"share"}}}

我们可以看到，输出了3条数据，但需要注意的是

{
    "uid":113,
    "oid":"562asdf12",
    "action":"comment",
    "time":"1672383412",
    "author_id":12454
}

这条数据的action没有和任何一条规则中的action匹配，所以这条数据被抛弃了。而

{
    "uid":111,
    "oid":"562asdf12",
    "action":"like",
    "time":"1672383110",
    "author_id":12454
}

这条数数据的action和两条规则匹配成功，为了后续程序处理方便，我们对数据进行了冗余处理，数据预过滤后，输出了两条数据。
数据流维度补充
在这个步骤中，数据准备flink会按照数据中的规则，从”维度数据“中获取需要填充的维度数据。例如

{
    "uid":111,
    "oid":"562asdf12",
    "action":"like",
    "time":"1672383110",
    "author_id":12454,
    "rule":{
        "rule_id":"00003",
        "rule_type":"2",
        "pk":"rule_id::uid::author_id",
        "dimKey":{
            "isAttention":"uid,author_id"
        },
        "conditions":{
            "action":"like",
            "isAttention":false,
            "eventCount":"gt:2"
        }
    }
}

这条数据需要填充”isAttention“属性，填充”isAttention“需要用到”uid,author_id“两个字段。数据准备flink程序，使用”isAttention::uid::author_id“从”维度数据“中获得{“isAttention”:false},并填充到数据流中

{
    "uid":111,
    "oid":"562asdf12",
    "action":"like",
    "time":"1672383110",
    "author_id":12454,
    "isAttention":false,
    "rule":{
        "rule_id":"00003",
        "rule_type":"2",
        "pk":"rule_id::uid::author_id",
        "dimKey":{
            "isAttention":"uid,author_id"
        },
        "conditions":{
            "action":"like",
            "isAttention":false,
            "eventCount":"gt:2"
        }
    }
}

flink规则引擎就可以根据”conditions“中的条件，判断当前数据是否满足条件。

第五个例子：用户点赞文章，文章包含标签“大户型”或“别墅”
这个例子和第四个例子类似，都是需要从”维度数据“中补充业务库数据。我们看下数据处理流程

原始数据

{"uid":111, "oid":"562asdf12","action":"like","time":"1672383110","author_id":12454}

规则：

{
    "rule_id":"00003",
    "rule_type":"1",
    "pk":"rule_id::uid::oid",
    "dimKey":{
        "tags":"oid"
    },
    "conditions":{
        "action":"like",
        "tags":[
            "大户型",
            "别墅"
        ]
    }
}

数据预过滤后

{
    "uid":111,
    "oid":"562asdf12",
    "action":"like",
    "time":"1672383110",
    "author_id":12454,
    "rule":{
        "rule_id":"00003",
        "rule_type":"1",
        "pk":"rule_id::uid::oid",
        "dimKey":{
            "tags":"oid"
        },
        "conditions":{
            "action":"like",
            "tags":[
                "大户型",
                "别墅"
            ]
        }
    }
}

数据维度补充后

{
    "uid":111,
    "oid":"562asdf12",
    "action":"like",
    "time":"1672383110",
    "author_id":12454,
    "tags":[
        "大户型",
        "别墅",
        "大三居"
    ],
    "rule":{
        "rule_id":"00003",
        "rule_type":"1",
        "pk":"rule_id::uid::oid",
        "dimKey":{
            "tags":"oid"
        },
        "conditions":{
            "action":"like",
            "tags":[
                "大户型",
                "别墅"
            ]
        }
    }
}

flink规则引擎只需要数据中的tags和条件中的tags进行交集计算，就可以得到结果。

第六个例子：用户进入了推荐线，但在60秒内没有任何点击操作
这个例子属于“完成A时间但未完成B”类型，我们直接看规则串是什么样的

{"rule_id":"00004","rule_type":"3","pk":"rule_id::uid","index":0,"winthTime":60,"conditions":{"action":"recommend"}}
{"rule_id":"00004","rule_type":"3","pk":"rule_id::uid","index":1,"winthTime":60",conditions":{"action":"click"}}

这个规则串有两条数据，分别对应着“事件A”、“事件B”。“事件A”对应的index为0，“事件B”的index为1。winthTime的值对应“60秒内”。数据处理流程如下图。
flink规则引擎设计思路

第七个例子：用户点击了活动入口，进入了活动页、发生了点赞、分享等交互操作，引导用户进入活动下一流程。
先看下规则串

{
    "rule_id":"00007",
    "rule_type":"4",
    "pk":"rule_id::uid",
    "index":0,
    "winthTime":60,
    "conditions":{
        "action":"activities-click"
    }
}
{
    "rule_id":"00007",
    "rule_type":"4",
    "pk":"rule_id::uid",
    "index":1,
    "winthTime":60,
    "conditions":{
        "action":"activities-pv"
    }
}

{
    "rule_id":"00007",
    "rule_type":"4",
    "pk":"rule_id::uid",
    "index":2,
    "winthTime":60,
    "conditions":{
        "action":"click,share"
    }
}

这个规则串包含3条数据，分别对应“点击活动入口”、“进入活动页”、“点赞、分享”。
通常这种复杂的事件流匹配需要用到flink cep，但是使用CEP无法解决规则动态变更，并且每一个规则需要对应一个flink任务。基于这个背景，我们对事件顺序流匹配做了一个简单的实现，具体细节可以参照这篇文章：https://blog.csdn.net/woloqun/article/details/126254055。

看到这里，你会发现，其实从技术角度没有特别复杂的逻辑。那难点是什么？难点是如何设计平台，生成规则串。最后贴几张草图，大家参考下

flink规则引擎设计思路
flink规则引擎设计思路
flink规则引擎设计思路
flink规则引擎设计思路文章来源地址https://www.toymoban.com/news/detail-449595.html

到了这里，关于flink规则引擎设计思路的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：
领支付宝红包 赞助服务器费用

相关文章

  • 日常工作中常用的抓包工具都有哪些呢？

    日常工作中常用的抓包工具都有哪些呢？

    大家好，今天我们一起来聊聊，在我们的日常工作中都有哪些抓包工具呢？你们平时工作中都在哪一款工具呢？一起学习交流。 一、Wireshark 这款抓包工具目前是使用最多的，分析网络交互非常方便 二、Fiddler，多数是使用在抓包手机的相关网络交互的网络包，目前也是非常流

    2024年01月20日
    浏览(54)
  • 【主流技术】日常工作中关于 JSON 转换的经验大全（Java）

    【主流技术】日常工作中关于 JSON 转换的经验大全（Java）

    目录 前言 一、JSON 回顾 1.1结构形式 二、其它类型 - JSON相关 2.1 JavaBean 转 JsonObject 2.2 JavaBean 转 Json 字符串 2.3 List 转 JsonArray 2.4 List 转Json 字符串 2.5Map 转 Json 字符串 三、JSON 相关 - 其它类型 3.1 Json 字符串转 JavaBean 3.2 Json 字符串转 JsonObject 3.3 Json 字符串转 List 3.4Json字符串转M

    2024年03月11日
    浏览(43)

  • redis在日常开发工作中的常见用法

    redis是一款内存型数据库，在开发工作中经常用到，功能强大； 特别开一篇文章用来记录一下它的常见用法，算是一种总结； 它最主要的特点就是高可用的，速度快，分布式；有人说速度快，能有我本地的全局静态变量快？但是在大型的项目中，多个服务器部署时，其他服务

    2024年02月09日
    浏览(37)
  • ChatGPT在日常生活与工作中的应用，以及Hulu AI 的探索之旅

    ChatGPT在日常生活与工作中的应用，以及Hulu AI 的探索之旅

    在数字化快速发展的当下，人工智能技术已经成为我们不可或缺的一部分。特别是在信息过载的时代，AI 如 ChatGPT 等工具能够帮助我们更高效地处理信息，提升生活和工作质量。本文旨在探讨 ChatGPT 在不同领域的实用性，以及介绍一个集成了多种AI工具的平台——Hulu AI，它可

    2024年04月13日
    浏览(38)
  • 程序员日常|为什么我在开发工作中偏爱这款键盘？

    程序员日常|为什么我在开发工作中偏爱这款键盘？

    最近一直不断地有粉丝朋友们私信我，问我该如何给自己挑选一款适合程序员工作的键盘，于是今天来给大家介绍下我用的键盘。 程序员作为一个需要长时间敲代码的职业，没有一个趁手的键盘是不行的，往小了说是折损工作效率，往大了说就是在损伤自己的手，是对自己的

    2024年02月02日
    浏览(51)

  • ChatGPT会对我们日常生活带来什么影响？这些技术会改变我们学习阅读工作方式吗？

    AI 这个话题很火，我也一直在关注着，很多人甚至觉得 AI 会改变世界，也许你会好奇：ChatGPT 会在三年内终结编程吗？AI有可能改变人的学习方式吗？AI 能否取代打工人？本文会对相关问题从我们可见日常问题进行解答。 希望从：AI 辅助提高了人的阅读效率吗、AI能帮助人更

    2024年02月03日
    浏览(74)

  • Sqoop【实践 01】Sqoop1最新版 MySQL与HDFS\Hive\HBase 核心导入导出案例分享+多个WRAN及Exception问题处理（一篇即可学会在日常工作中使用Sqoop）

    1️⃣ 查看所有命令【 sqoop help 】 2️⃣ 查看某条命令的具体使用方法【 sqoop help COMMAND 】 查询MySQL所有数据库，通常用于 Sqoop 与 MySQL 连通测试： 【具体参数可以使用 sqoop help list-databases 查看】实例： 结果： 【2个】WARN处理： 查询指定数据库中所有数据表，这里要注意一下

    2024年03月18日
    浏览(46)
  • 分布式规则引擎框架的设计

    分布式规则引擎框架的设计

    MirAIe 规则引擎是一个可扩展且可扩展的规则引擎框架，允许用户对多个活动进行分组和自动化。         过去几年，在开发MirAIe 物联网平台时，我们意识到需要一个可扩展、可扩展的规则引擎框架。规则引擎使您能够对各种操作进行分组、管理和自动化，并可用于各种应

    2024年02月14日
    浏览(29)

  • JWFD开源工作流-矩阵引擎设计-遍历排序算法运行测试

          JWFD开源工作流-矩阵引擎设计-遍历算法运行测试      使用下面的流程图-生成式矩阵和参数表，编写遍历排序算法，运行结果如下（test004.mtx,test004.parm） 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 1 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1

    2024年02月06日
    浏览(43)

  • Asp.net基于工作流引擎的系统框架设计开发(源代码+论文)

    工作流就是一系列相互衔接、自动进行的业务活动或任务。工作流引擎是工作流管理系统的核心，它的主要功能是通过计算机技术的支持去定义、执行和管理工作流，协调工作流执行过程中工作之间以及群体成员之间的信息交互。 论文主要讲述了工作流引擎的基本功能及设计

    2024年02月12日
    浏览(44)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包，优惠每天领

二维码1

领取红包

二维码2

领红包