Flink规则引擎实践分享

Flink规则引擎实践分享

---

---

Java、大数据开发学习要点（持续更新中…）

---

一、实时规则引擎架构***

1. 业务系统产生的行为日志数据被日志采集服务器收集，通过Flume将数据存入Kafka指定topic，由Flink消费Kafka对应的topic来进行用户行为事件分析【通过FlinkKafkaComsumer传入参数(1)topic名称(2)反序列化模式DeserializationSchema(3)定义了Kafka集群地址和消费者组id的properties】。
2. 通过查询路由、缓存系统的优化使得系统响应时间在毫秒级(实现的是数据磁盘离线存储与计算几乎在内存完成的方案)。在Flink解析用户行为时，用户行为满足了所制定规则中的触发条件(事件驱动)，则去计算这个用户的用户属性条件(存在HBase的用户画像标签表¹)、用户行为次数条件(存在ClickHouse中的行为事件明细表和State中²)和用户行为次序条件(同上)。对满足对应规则和条件的用户，将结果输出到Kafka交付。
3. 实现Flink中规则的动态更新。通过Canal监听存储发布规则的数据库，一旦有新的规则发布就将规则写入Kafka指定topic，Flink消费到对应topic的新的规则就作为广播流connect到事件流上。Flink物理执行图如下所示：
   

---

¹用户画像为什么用Hbase存储？

答：用户数量大(每个用户对应一行)，每个用户的标签众多，这样的大数据量适合用Hbase这样的分布式数据库存储，并且Hbase是列式存储，标签扩展方便。并且本系统中是按照用户id查询Hbase对应rowkey来查找具体列的等值查询，可通过布隆过滤器进行优化，并且HFile有序存储的特征可以根据索引进行列信息的快速等值查找。而MySQL，首先超过百万行的查询性能就会急剧下降；其次标签扩展不方便，增加一个标签所有行数据都要更改(行式存储的劣势)；最后，查询需要进行索引的建立、优化、维护等工作不如HBase来的直接了当。

²用户行为明细为什么用ClickHouse？为什么存用户行为明细？用CK有什么缺点，怎么解决？

答：首先，用户行为明细的查询数据库要符合以下条件，响应速度快、支持复杂数据查询、并发查询能力强(这点CK不擅长)，综合来看CK比较符合。其次，为存储用户行为明细是因为规则是动态的无法事先确定会有怎么样的规则发布，那么当新的规则出现时，行为查询的粒度将会发生不可预知的改变，这种场景就需要OLAP的即席查询来支持临时聚合和复杂分析。最后，CK的缺点在于并发能力不高，在Flink高并行度的数据处理场景下会导致CK性能骤降，解决方案为实际行为明细查询存在冗余查询，可以使用本地查询缓存机制来减少冗余查询，从而减少对CK查询的请求数。

ps:其实也可以用Hbase一站式解决，rowkey设计为用户id，日志中其他信息k-v形式存储在列族中。查询时根据rowkey查询，与需要查询的行为事件返回数据，再写逻辑进行统计次数或者次序统计。或者直接整合Phenix。但是：
1.Hbase还是定位为海量数据存储，在数据分析的上即使整合Phenix复杂查询的时间也是秒级的，并且对于复杂的计算SQL更加容易表达。
2. 从Hbase中查询根据rowkey和指定列查询很方便，但是查询后的需要将符合的数据都加载到内存中计算，进行复杂计算逻辑的编写，后期系统拓展需要给每个规则编写对应逻辑，没有SQL维护方便(并且系统将SQL生成与引擎截耦合更加利于后期系统规则扩展和维护)。

二、规则抽象模型