从零搭建精准运营系统

时间 2019-12-05

标签搭建精准运营系统繁體版

原文原文链接

2018刚过去，趁着春节放假对过去一年主导开发的项目作个梳理和总结html

项目背景

平台运营到必定阶段，必定会累积大批量的用户数据，这些用户数据是运营人员的黄金财产。而如何利用用户的数据来作运营（消息推送、触达消息、优惠券发送、广告位等），正是精准运营系统须要解决的问题。本文是基于信贷业务实践后写出来的，其它行业如保险、电商、航旅、游戏等也能够参考。前端

业务场景

先看几个具备表明性的需求mysql

用户可用额度在20000～50000元，并且有借款记录，未还本金为0，性别为“男”
用户发生了A行为且未还本金大于5000
用户在1天内发生A行为次数大于等于3次
用户在A行为前24小时内未发生B行为
用户在A行为后一个月内未发生B行为

业务上有两种消息类型sql

平常消息：由业务人员经过条件筛选锁定用户群，定时或即时给批量用户发送消息或者优惠券
触达消息：主要由用户自身的行为触发，好比登录、进件申请、还款等，知足必定筛选条件实时给用户发送消息或优惠券

对于用户筛选条件，也主要有两种类型数据库

用户状态：包括用户自身属性如性别、年龄、学历、收入等，还有用户相关联实体如进件订单、帐户信息、还款计划、优惠券等的属性，以及用户画像数据如行为偏好、进件几率等
用户行为：即用户的动做，包括登录、进件申请、还款，甚至前端点击某个按钮、在某个文本框输入都算

早期方案

早期方案存在如下痛点apache

至少两次跨部门沟通配合成本，周期被拉长
非实时消息推送，没法实现基于用户行为的实时推送场景
非实时效果验证，没法及时调整运营策略

系统搭建的目标

须要定义规则，提供可视化界面给业务人员动态配置，无需重启系统即便生效，减小沟通成本和避免重复开发，总之就是要更加 自动化 和 易配置
采集实时数据，根据实时事件作实时推送，总之就是要实时

技术选型

数据采集、转换、存储

采集：状态类的数据主要放在各个业务系统的关系型数据库中，因为历史缘由有postgres和mysql，须要实时采集表的数据变动，这里使用kafka connector读取mysql的binlog或postgres的xlog，另外还有标签系统计算出来的标签，在kafka中；而事件类数据主要来源于前端上报事件（有专门的服务接收再丢到kafka），关系型数据库里面也能够提取一些事件。
转换：采集出来的数据须要作一些格式统一等操做，用kafka connector。
存储：采用Elasticsearch存储用户数据，ES查询不像mysql或mongoDB用B-tree 或B+tree实现索引，而是使用bitset和skip list来处理联合索引，特别适合多字段的复杂查询条件。

下面重点看下kafka connector和Elasticsearch如何使用json

kafka connector

kafka connector有Source和Sink两种组件，Source的做用是读取数据到kafka，这里用开源实现debezium来采集mysql的binlog和postgres的xlog。Sink的做用是从kafka读数据写到目标系统，这里本身研发一套组件，根据配置的规则将数据格式化再同步到ES。
kafka connector有如下优势：api

提供大量开箱即用的插件，好比咱们直接用debezium就能解决读取mysql和pg数据变动的问题
伸缩性强，对于不一样的connector能够配置不一样数量的task，分配给不一样的worker，，咱们能够根据不一样topic的流量大小来调节配置。
容错性强，worker失败会把task迁移到其它worker上面
使用rest接口进行配置，咱们能够对其进行包装很方便地实现一套管理界面

Elasticsearch

对于状态数据，因为状态的写操做相对较少，咱们采起嵌套文档的方式，将同个用户的相关实体数据都同步写入到同个文档，具体实现用painless脚本作局部更新操做。效果相似这样：性能优化

{
   "id":123,
   "age":30,
   "credit_line":20000,
   "education":"bachelor",
   ...
   "last_loan_applications":{
         "loan_id":1234,
         "status":"reject",
          ...
    }
  ...
}

事件数据写入比较频繁，数据量比较多，咱们使用父子文档的方式作关联，效果相似这样：微信

{
  "e_uid":123,
  "e_name":"loan_application",
  "e_timestamp":"2019-01-01 10:10:00"
  ...
}

（e_前缀是为了防止同个index下同名字段冲突）
ES这样存储一方面是方便作统计报表，另外一方面跟用户筛选和触达有关。

规则引擎

在设计规则引擎前，咱们对业界已有的规则引擎，主要包括Esper, Drools, Flink CEP，进行了初步调研。

Esper

Esper设计目标为CEP的轻量级解决方案，能够方便的嵌入服务中，提供CEP功能。
优点:

轻量级可嵌入开发，经常使用的CEP功能简单好用。
EPL语法与SQL相似，学习成本较低。

劣势:

单机全内存方案，须要整合其余分布式和存储。
之内存实现时间窗功能，没法支持较长跨度的时间窗。
没法有效支持定时触达（如用户在浏览发生一段时间后触达条件判断）。

Drools

Drools开始于规则引擎，后引入Drools Fusion模块提供CEP的功能。
优点:

功能较为完善，具备如系统监控、操做平台等功能。
规则支持动态更新

劣势:

之内存实现时间窗功能，没法支持较长跨度的时间窗。
没法有效支持定时触达（如用户在浏览发生一段时间后触达条件判断）。

Flink

Flink 是一个流式系统，具备高吞吐低延迟的特色，Flink CEP是一套极具通用性、易于使用的实时流式事件处理方案。
优点:

继承了Flink高吞吐的特色
事件支持存储到外部，能够支持较长跨度的时间窗。
能够支持定时触达（用followedBy＋PartternTimeoutFunction实现）

劣势:

没法动态更新规则（痛点）

自定义规则

综上对比了几大开源规则引擎，发现都没法知足业务需求:

业务方要求支持长时间窗口（n天甚至n个月，好比放款一个月后若是没产生还款事件就要发消息）
动态更新规则，并且要可视化（不管用哪一个规则引擎都须要包装，须要考虑二次开发成本）

最终咱们选择本身根据业务须要，开发基于json的自定义规则，规则相似下面例子：

{
  "batchId": "xxxxxxxx", //流水号，建立每条运营规则时生成
  "type": "trigger", //usual
  "triggerEvent": "login",
  "after": "2h", //分钟m,小时h,天d,月M
  "pushRules": [//支持同时推送多条不一样类型的消息
    {
      "pushType": "sms", //wx,app,coupon
      "channel": "cl",
      "content": "hello #{userInfo.name}"
    },
    {
      "pushType": "coupon",
      "couponId": 1234
    }
  ],
  "statusConditions": [
    {
      "name": "and", //逻辑条件，支持与(and)或(or)非(not)
      "conditions": [
        {
          "name": "range",
          "field": "credit_line",
          "left": 2000,
          "right": 10000,
          "includeLeft": true,
          "includeRight": false
        },
        {
          "name":"in",
          "filed":"education",
          "values":["bachelor","master"]
        }
      ]
    }
  ],
  "eventConditions": [
    {
      "name": "or",//逻辑条件，支持与(and)或(or)非(not)
      "conditions": [
        {
          "name": "event",
          "function": "count", //聚合函数,目前只支持count
          "eventName": "xxx_button_click",
          "range": { //聚合结果作判断
            "left": 1,
            "includeLeft": true
          },
          "timeWindow": {
            "type": "fixed", //fixed为固定窗口，sliding为滑动窗口
            "start": "2019-01-01 01:01:01",
            "end": "2019-02-01 01:01:01"
          },
          "conditions": [ //event查询条件继承and逻辑条件，因此事件也能够过滤字段
            {
              "name": "equals",
              "field": "f1",
              "value": "v1"
            }
          ]
        }
      ]
    }
  ]
}

使用面向对象思惟对过滤条件作抽象后，过滤条件继承关系以下：

而后代码里加一层parser把Condition都转成ES查询语句，实现轻量级的业务规则配置功能。

总体技术方案

系统组成模块及功能以下：
mysql binlog：mysql的数据变动，由kafka connector插件读取到kafka，数据源之一
postgres xlog：pg的数据变动，由kafka connector插件读取到kafka，数据源之一
report server：事件上报服务，数据源之一
tags：用户画像系统计算出来的标签，数据源之一
触发场景路由：分实时触发和延迟触发，实时触发直接到下一步，延迟触发基于 rabbitmq的延迟队列实现
用户筛选模块：将筛选规则翻译为ES查询语句到ES查询用户数据，能够是批量的和单个用户的
变量渲染模块：对推送内容作处理
推送适配器：兼容不一样的推送方式
定时任务调度器：基于elastic-job，处理定时推送任务
规则配置控制台：提供可视化配置界面（运营规则配置、数据采集规则配置、字段元数据配置等）
报表服务：提供报表查询功能
运营位服务：提供外部接口，根据条件匹配运营位（如启动图、首页banner图片等）

总结与展望

系统基本知足了目前的业务需求，对转化率等运营指标提高显著
能够扩展其它业务，如推荐、风控、业务监控等
规则定时拉取，实时性差，能够用zk作发布订阅实现即时更新
目前事件的聚合函数只支持count，能知足业务需求可是将来可能还须要支持其它函数
系统只通过千万级用户的生产验证，再高数量级的话可能还有不少性能优化的工做,如ES并行查询（目前用scroll api批量拉取用户数据是串行的）
事件类数据愈来愈多，目前采起定时删除半年前数据的方式，防止持续增加过快不可控，因此事件类条件不可超过半年的时间窗口
虽然系统对业务无入侵，可是反过来看本系统依赖于上游数据，上游数据发生变化时如何作到影响最小？

将来会继续从技术及业务两方面入手，将系统建设的更加易用、高效。