Flink|青训营笔记Flink被设计为可以运行在大部分环境,能够进行任何规模的计算 Flink:Exactly-onc

这是我参加参与「第四届青训营」笔记创作活动的的第2天

Flink被设计为可以运行在大部分环境,能够进行任何规模的计算

Flink:Exactly-once,checkpoint(状态容错),Dataflow编程模型 Window等高阶需求支持友好,流批一体;

大数据计算架构模式变化

批示计算:离线计算,非实时,静态数据集,小时/天等周期性计算;

流式计算:实时计算,低延迟,无限流,无边界,持续运行,流批一体;

分层架构

1.SDK层

2.执行引擎层(runtime层):提供统一的DAG,用来描述数据处理的pipeline,转化为DAG图,调度层再把DAG转化成分布式环境下Task,通过Shuffle传输数据;

3.状态存储层:负责存储算子的状态信息;

4.资源调度层:Flink可以支持部署在多种环境;

整体架构:一个Flink集群,主要包含两个核心组件

1.JM(JobManager)负责整个任务协调,包括调度,触发协调做检查点,容错恢复;
2.TM9TaskManager)负责执行一个DataFlow Gragh的task及streams的buffer和数据交换;

Dispatcher:接收作业,拉起JM来执行作业,JobMaster挂掉后恢复作业;

Jobmaster:管理一个job的整个生命周期,会向ResourceManager申请slot,并将task调度到TM上;

ResourceManager:负责slot资源的管理和调度,Task manager拉起后会向RM注册;

流批分离痛点人力成本高:两套系统需开发两遍; 数据链路冗余,产生资源浪费;数据口径不一致,两套系统,两套算子,会产生误差;

流式计算:无限数据集,低延迟,业务会感知运行情况;

批示计算:数据流有限,实时性要求不高,只关注最终结果产出时间;

Apache Flink从以下模块做流批一体: SQL层,DataStream API层,Scheduler层,Failover Recovery 层,Shuffle Service层架构统一,支持流批场景;

Shuffle有以下几种实现:

基于文件的Pull Based Shuffle:具有较高的容错性,适合较大规模的批处理作业;

基于Pipeline的Push based shuffle:低延迟&高性能.数据没有存储下来,若是批任务需要重跑恢复;

生命周期:流作业的数据和task绑定,批作业是解耦的;

存储介质:流作业生命周期短,加上实时性,通常存储在内存中,批作业因为数据量大及容错需求,存储在磁盘里;

部署方式:流作业服务和计算节点部署在一起,可以减少网络开销,从而减少latency