摘自: 基于Apache Flink的流处理
1.dataflow编程概述
dataflow图(算子 数据源 数据汇)
数据并行和任务并行
数据交换策略:
转发策略(发送端任务和接收端任务之间一一对应进行传输)
广播策略()
基于键值的策略(根据某一键值属性对数据分区)
随机策略
2.并行流处理
延迟:表示处理一个事件所需要的的时间
吞吐:用来衡量系统处理能力(处理速率)的指标
处理速率取决于数据到来速率,因此吞吐低不意味着性能差
通过并行处理多条数据流,可以在处理更多事件的同时降低延迟
无状态:处理事件时无需依赖已经处理过的事件
有状态:维持内部状态
数据接入与输出
转换操作
滚动聚合(例如求和 最小值 最大值)
窗口操作(“桶”的有限事件集合):滚动窗口 滑动窗口 会话窗口
3.时间语义
处理时间:当前流处理算子所在机子的本地时钟时间
事件时间:数据流实际发生时间(将处理速度和内容结果彻底解耦)
问题:如何处理延迟事件
水位线:一个全局进度指标,表示我们确信不会再有延迟事件到来的某个时间点
虽然处理时间提供了很低的延迟,但是结果依赖于处理速度,具有不确定性
事件时间能保证结果的准确性.并且允许处理延迟甚至无序的事件
4.状态与一致性模型
传统的处理无限数据的通常方法:将到来的事件分成小批次,不停地在批处理系统上调度并运行作业,其结果都会写入持久化储存中,同时所有算子的状态都将不复存在
流式算子处理面临的挑战:
状态管理
状态划分
状态恢复
任务故障
任务的执行步骤
接收事件并将它们缓存在本地缓冲区
选择性地更新内部状态
产生输出记录
结果保障
关注:流处理引擎内部状态的一致性
至多一次:每个事件至多被处理一次
至少一次:不丢事件
持久化事件日志将所有事件写入永久存储,这样任务故障时就可以重放它们
记录确认,将所有事件存在缓冲区中,直到处理管道中的所有任务都确认某个事件已经处理完毕才会将时间内丢弃精确一次:不但没有事件丢失,而且每个事件对于内部状态的更新都只有一个
端到端的精确一次:整个数据处理管道上的结果都是正确的,可以通过弱保障来实现强语义