Flink 状态(State)在推荐场景中的应用

导语

Flink 提供了灵活丰富的状态管理，可轻松解决数据之间的关联性。本文介绍了Flink 状态(State)管理在推荐场景中的应用，大家结合自己的应用场景与业务逻辑，选择合适的状态管理。

背景

Flink作为纯流式大数据实时计算引擎，较于Spark Streaming的微批处理引擎，不管是内存管理，多流合并，还是时间窗口，迭代处理上，Flink在实时计算场景更较适合。而Flink的State状态管理，更是让Flink在实时计算领域，更胜一筹。通过对Flink State状态的灵活妙用，可以完美实现大数据下的实时数仓，实时画像和实时数据监控等功能。

场景

最近在做推荐数据平台，其中有一个场景需求是要实时统计最近1分钟的UV、点击量、真实曝光量和下发量等热点数据，并可以在不同地域维度下做多维度查询。通过对数据的实时跟踪监控，可以精准迅速地获悉推荐算法在不同地域投放后所产生的流量变化，从而优化对不同地域下用户的精准推荐。

问题&选型

我们在做场景分析的时候，发现有两个问题需要解决。

首先是我们的数据来自于用户对App的操作行为日志，在这些埋点数据里，有个字段localId（13位数字组成），该字段记录了该用户所在的位置编号，可以精确到区，街道，甚至村委会，但是缺少上下层级关系。也就是说，通过localId我们无法得知该用户属于哪个镇，哪个市，哪个省等。所以，在对该数据做进一步操作前，需要找到localId的地域映射关系，并关联到省市县等，从而实现省市县下不同维度下的热点数据统计与分析。

另外就是对于埋点上报的真实曝光数据，存在较严重的数据延迟问题，甚至可达到数个小时的延迟，严重影响数据的准确性和时效性。这部分的原因是真实曝光的定义与App客户端的埋点上报机制所致。

结合上述问题，在构思方案的选型上：

首先想到使用Spark做数据处理引擎，不管从公司使用的人数和任务数上，还有维护上，使用Spark无疑是最稳定的选择。但是Spark是基于RDD做的micro batch处理，而Spark Streaming又只是在Spark RDD基础上增加了时间维度（时间片），其本质还是在进行Spark的RDD处理。Spark Streaming将流式计算分解成了多个Spark Job，而每一段数据的处理都会经过RDD DAG有向无环图的分解，和Spark Scheduler的调度分配，其最小的Batch Size为0.5秒~2秒钟之间。所以，Spark Streaming适用于对实时性要求不是非常高的流式准实时计算场景。而我们的数据有一部分是实时上报上来，例如点击与下发数据。我们希望对这些数据做秒级内处理，所以在处理这种延时性较低的数据上，Spark Streaming可能不是很适合。并且，一天不同时间段访问UV量参差不齐，导致一天内