wizard-marketing
该系统适用场景：
- 实时运营
- 实时风控
- 实时推荐
该系统属于事件驱动型系统，对时效性比较高
问题：
- 数据延迟怎么办：用户T1时刻产生的行为，T10时刻才到达，这种情况下还是要看规则的时效性，当不满足时效性要求的时候，不发送就可以了。该系统不存在数据延迟问题。
事件抽象：规则就是Rule，不需要那么复杂的命名，条件也是同样。至于为什么接收的Kafka的消息
命名为"事件"而不是"消息"，因为"事件"包含着"动作、触发"，而"消息"是"静态"的。
此外还有一个比较单元：Unit类，此类包含了"事件"和"条件"需要比较的基本属性，特将共同的属性抽取
出来，用来简化比较。（但是总是感觉比较别扭，因为"条件"中同样可能会有"事件"中的操作系统、运营商等属性，但是
好消息是含有一个基本属性properties的map对象，可以在里面包含众多冗余信息。）
Pojo和Bean的区别：
Pojo其实是比javabean更纯净的简单类或接口。Pojo严格地遵守简单对象的概念，而一些JavaBean中往往会封装一些简单逻辑。
Pojo主要用于数据的临时传递，它只能装载数据， 作为数据存储的载体，而不具有业务逻辑处理的能力。
Javabean虽然数据的获取与Pojo一样，但是javabean当中可以有其它的方法。
当只用ClickHouse的时候，会因为发往ClickHouse的数据出现延迟问题，并且因为该框架本身并发性不高， 出现并发问题，部分业务都是查询最近的一段时间，所以综上问题，不需要将所有查询都在ClickHouse中查询， 一是准确性不高，二是并发性不支持。
当前版本存在的问题： 行为序列条件目前的缺陷:
- 只支持----[.*A.*B.C.]----(意味着ABC三种行为中间发生任何事件都可以)
- 不支持----[AB.*C]---- (A事件后面紧接着发生B事件，再隔几个事件后发生C事件)
- 不支持----[A(2)B.*C]---- (A事件后面隔着两个事件发生B事件)
- 不支持----[A.!F.B]----(A和B事件中间不能发生F事件)
- 不支持----做过A后，3分钟没有做C，即做过A后，(定时)人满足某画像条件，满足某事件条件
- 不支持----同一序列条件发生多次
事件是事实，条件不是
条件递进关系：条件 -----> 组合条件 ------> 行为条件(基于业务抽象，不再基于底层含义抽象)
事件时间与处理时间
- 事件时间发生在
2021-11-25 15:34:49秒，因为延迟，处理时间为2021-11-25 15:34:53秒，延迟了4秒