3.Flink的时间
- 事件时间(Event Time):事件创建时间。它通常由事件中的时间戳描述,例如采集的日志数据中,每一条日志都会记录自己的生成时间,Flink通过时间戳分配器访问事件时间戳。
- 采集时间(Ingestion Time):事件进入到Flink DataFlow的时间
- 处理时间(Processing Time):某个Operator对事件进行处理的本地系统时间。默认的时间属性就是Processing Time。
在Flink的流式处理中,绝大部分的业务都会使用eventTime,一般只在eventTime无法使用时,才会被迫使用ProcessingTime或者IngestionTime。
4.window操作
Window可以分成两类:
- CountWindow:按照指定的数据条数生成一个Window,与时间无关。
- TimeWindow:按照时间生成Window。
对于TimeWindow,可以根据窗口实现原理的不同分成三类:滚动窗口(Tumbling Window)、滑动窗口(Sliding Window)和会话窗口(Session Window)。
WindowAPI 都由滚动窗口和滑动窗口。
- TimeWindow是将指定时间范围内的所有数据组成一个window,一次对一个window里面的所有数据进行计算。
- CountWindow根据窗口中相同key元素的数量来触发执行,执行时只计算元素数量达到窗口大小的key对应的结果。
事件窗口EventTimeWindow API:
- TumblingEventTimeWindows 滚动窗口
- SlidingEventTimeWindows 滑动窗口
- EventTimeSessionWindows 会话窗口(Session Window)。
基本操作:
- window:创建自定义窗口
- Trigger:触发器,决定一个窗口何时被计算或清除
- evictor:驱逐者,在Trigger触发后且窗口被处理前,剔除窗口中不需要的元素(filter)
- apply:自定义window function
Flink 中窗口机制和时间类型是完全解耦的,也就是说当需要改变时间类型时不需要更改窗口逻辑相关的代码。
5.Flink反压机制
- Storm: 通过监控process bolt中接收队列负载情况来处理反压,即当超过高水位值,就将反压信息写到Zookeeper,由zookeeper的watch通知worker进入反压状态,最后spout停止发送tuple。
- Spark Streaming:设置属性“spark.streaming.backpressure.enabled”进行自动反压,即动态控制数据接收速率来适配集群数据处理能力。
- Flink:不需要设置,自动处理反压,即每个组件都有对应的分布式阻塞队列,只有队列不满的情况,上游才发数据,较慢的接收者会自动降低发送速率,如果队列满了(有界队列),发送者会阻塞。
6.Flink与Spark Streaming
- 数据模型:
- spark 采用 RDD 模型,spark streaming 的 DStream 实际上也就是一组 组小批数据 RDD 的集合
- flink 基本数据模型是数据流,以及事件(Event)序列
- 运行时架构:
- spark 是批计算,将 DAG 划分为不同的 stage,一个完成后才可以计算下一个
- flink 是标准的流执行模式,一个事件在一个节点处理完后可以直接发往下一个节点进行处理
7.Flink+Kafka实现exactly-once语义
- Flink通过checkpoint来保存数据是否处理完成的状态。
- 由JobManager协调各个TaskManager进行checkpoint存储,checkpoint保存在 StateBackend中,默认StateBackend是内存级的,也可以改为文件级的进行持久化保存。
- 执行过程实际上是一个两段式提交,每个算子执行完成,会进行“预提交”,直到执行完sink操作,会发起“确认提交”,如果执行失败,预提交会放弃掉。
- 如果宕机需要通过StateBackend进行恢复,只能恢复所有确认提交的操作。