流式计算的世界观:工夫不停万物不停
- 在批量的时代,咱们只记录要害的信息,只在乎以后,不在乎状态是如何一步步变动至当状态的,所以说批时代咱们计算所面向的数据是动态的。在分布式环境中批量计算是将计算挪动到相应的数据上进行运行。
- 在流世界里,咱们在乎的是变动,咱们计算所面临的将是时时刻刻更新流动的数据。流式计算是将定义好的计算部署到分布式节点上,让数据在下面流动。
不再把数据定性为“解决某天的数据,解决某个季度的数据”,而是随着工夫的推移,零碎要捕捉到用户每分每秒产生的数据,进行计算解决后让业务报告保障最新。
流式解决中的工夫
- 事件工夫(Eventtime):事件实在产生的工夫,因为 … 起因,事件产生的工夫和达到服务端的工夫可能是相差极大的
- 达到工夫:服务端接管到事件的工夫
- 解决工夫:零碎开始前途达到事件的工夫
// 创立环境上下文
val env = StreamExecutionEnvironment.getExecutionEnvironment
// 设置在以后程序中应用 ProcessingTime
env.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime);
窗口
- 滚动窗口:依照固定的工夫片断划分数据流,将数据流宰割成固定大小的片段。
- 滑动窗口:由固定窗口长度 windows-size= 1 和窗口滑动步长 windows-slide=0.5,示意窗口长度为 1,每 0.5 个单位就向前滑动一个新窗口。滑动窗口常常被用来统计诸如“每 5 分钟统计过来 10 分钟的访问量”,windows-size=10 和 windows-slide=5
- 会话窗口:会话的窗口的大小由用户流动的事件频率决定,没有固定的窗口大小。
流式解决的设计模式
流和表的连贯 : 有时候,咱们须要在内部数据中保留一些规定后,须要时将信息完完整整的拉进流中。然而,流式解决零碎每秒能够解决 10-50W 个事件,而数据库每秒的只能解决 1W 个事件。所以,内部查找不仅会带来重大的提早性,如果数据刷新的太频繁会对数据库造成很大的压力,如果刷新不及时,那么流式解决中所用的数据就会过期。所以,咱们采纳通过 Canal 来捕捉 Mysql 数据库的变动,造成事件流,Flink 就能够监听事件流,并及时更新。
State
在 Flink 中,状态用于缓存用户数据,窗口数据,程序运行状态,数据源偏移量
Checkpoint
定期对 State 中的数据进行备份并复原的机制,正是有了 State 和 Checkpoint,Flink 能力做到:
- 备份与复原,7*24 的运行是容错
- 数据不失落不反复,Exactly one
- 低提早
- 数据间有关联,通过状态满足业务逻辑
Watermark 和 Trigger
Flink 中放弃正确性的工具是 State 和 Checkpoint,提供工夫推理能力的是 Watermark 和 Trigger。