flink
weixin_47894524
这个作者很懒,什么都没留下…
展开
-
flink失去时间属性特性的操作
1、对时间属性字段以外的字段进行GROUP BY(滚动窗口、滑动窗口或会话窗口中的GROUP BY除外)操作。2、双流JOIN操作。3、复杂事件处理(CEP)语句中的MATCH_RECOGNIZE操作4、OVER窗口中的PARTITION BY操作5、UNION操作。UNION = RETRACT+UNION ALL如果经过以上操作后,继续使用该时间属性字段进行窗口函数运算,会出现类似org.apache.flink.table.api.ValidationException: Wind原创 2021-07-11 21:35:09 · 464 阅读 · 2 评论 -
flink双流join的技术思考
1、A流和B流时间相隔较短,几分钟或者几小时①策略:直接使用join操作②解释:join底层走的是:A来B没来,A会缓存起来(默认1.5天),B流来去缓存查A,join成功,然后输出。③注意点:如果是A left join B ,A来B没来A会先输出一条没join上的数据,B来的时候会将之前的输出做逻辑撤回,然后将join上的最新结果重新输出(下游要做好过滤等操作,保证输出的幂等性)2、A流和B流相隔时间较长,比如订单流这种以若干天为变化周期的数据①比如要给订单实时流添加相关的维度信息原创 2021-07-11 21:06:33 · 647 阅读 · 0 评论 -
flink双流join的策略
场景:比如电商订单业务的实时流,订单和订单明细1、订单流随着订单状态的变化,不断产生新数据2、订单明细作为流水表随着订单的产生,只来一次? or 订单明细随着订单状态的变化,同步更新?策略:1、如果订单明细流随着订单的产生,只来一次,a:双流join,因为双流join数据默认缓存在状态中1.5天,那么如果订单流1.5天后果来,将会join不上明细流。b:维表join,将订单明细流实时写到维表中,订单流过来去查维表做关联,那么明细流如果延迟了,将会导致先来的订单数据join不上。c:给订单原创 2021-06-10 11:18:04 · 595 阅读 · 0 评论 -
SQL谓词下推存在的“陷阱“
谓词下推:在SQL执行优化策略时,会将where相关的过滤条件放在前面来执行,如果此时涉及和另一张表的join操作,那么就可能会踩坑场景:1、A joinB 2、将join后的A的数据执行UDF 3、UDF处理后的数据过滤谓词下推后的执行顺序: 1、A中某字段执行UDF 2、对UDF处理后的数据进行过滤 3、过滤后的A与B再进行join问题点:谓词下推的原则是:先过滤再join,但是UDF逻辑较重,效率上:(join后少量数据执行UDF的时间)<(先全量执行UDF再过滤的时间),所以自动.原创 2021-06-10 10:52:13 · 346 阅读 · 0 评论 -
flink 经常发生 remove container
将一些维表加载到内存中,因为数据量过大导致节点加载时间长,worker节点与master节点的心跳超时,导致container被remove掉解决办法:1、减少加载到内存中的数量量2、默认每个节点发送一份数据,可以将全量数据分散到不同的worker节点上,减少单节点加载数据的压力...原创 2021-06-07 18:06:10 · 283 阅读 · 0 评论 -
flink保存点
1、手动触发2、程序停止不会自动删除3、可用于系统升级、集群迁移和数据存档等原创 2021-06-07 17:50:20 · 146 阅读 · 0 评论