实时数仓建设第1问： 一直使用top N,为何duplicate状态和rank状态的TTL执行策略不一样？

在1.16之前 rank为了提高效率，会使用缓存降低对状态的访问。缓存就是一个普通的MAP集合，如果不适应定时器在状态过期后删除缓存数据就会导致缓存数据一直增大导致OOM。

kvSortedMap = new LRUMap<>(lruCacheSize);
public class LRUMap extends LinkedHashMap  
   public void onTimer(long timestamp, OnTimerContext ctx, Collector out)   throws Exception {      
    if (stateCleaningEnabled) {         
       // cleanup cache               
    kvSortedMap.remove(keyContext.getCurrentKey());          
         cleanupState(dataState);     
            }   
     }

1.16 之后rank的状态不再采用定时器，也采用状态定义时设置TTL，为了避免缓存无法释放问题，采用了LRU缓存。

kvSortedMap = cacheBuilder.maximumSize(lruCacheSize).build();

• rank的AbstractTopNFunction继承了KeyedProcessFunctionWithCleanupState方法。
• duplicate的 DeduplicateFunctionBase继承了 KeyedProcessFunction。

rank的ttl是通过注册一个定时器来实现的的原因是，rank为了提高性能，在state前弄一个map缓存，如果在状态上配置ttl，则状态过期了，缓存没有被清除掉。因为用定时器来手动执行状态清除策略，当时间到了则删除缓存和清空状态，问题又来了，那么状态是否就没有更新策略了，到时间就删除了，不会因为修改而更新ttl?

如果状态一直被访问，计时器到期后不会调用清除状态方法，而是重新注册一个计时器，只有当状态没有被访问了，计时器才会进行删除。所以rank的状态也是有ttl，只是策略不一样。

专栏初衷:

• 要想快速建设实时数仓，对齐离线数仓分层，首选Flink SQL，相比datastream 代码，Flink SQL可大幅提升10倍实时数仓建设落地时间。
• 作者位于大厂实时数仓团队，目前运行实时任务3000+，实时集群规模2万CU，集群checkpoint峰值5TB,单任务最大QPS峰值50W。
• 本专栏将分享作者在实时数仓建设过程中遇到的细节点，帮组大家快速建设实时数仓。

作者信息:

• 1.《深入理解Flink核心设计与实践原理》一书作者
• 2.GitHub 热门项目 fink-boot（800+） 开发者，致力于flink与spring生态集成