流/批/OLAP 一体的 Flink 引擎介绍 | 青训营笔记

170 阅读9分钟

流/批/OLAP 一体的 Flink 引擎介绍 | 青训营笔记

一.重点内容

  1. Apache Flink概述:诞生背景、流计算的需求与特点、发展历史
  2. Flink架构原理与设计:分层架构、整体架构、流批一体
  3. Flink架构的优化:OLAP支持
  4. Flink示例

二.详细知识点介绍

1.Apache Flink概述

1.1 Apache Flink的诞生背景

  • 什么是大数据:指无法在一定时间内用常规软件工具对其进行获取存储管理和处理的数据集合
    • 海量化:数据
    • 多样化:数据种类多样
    • 快速化:数据产生流入速度快
    • 价值化:数据价值密度低、整体密度高
  • 大数据计算架构发展历史
    • 史前阶段:传统数仓、Oracle、单机、黑箱使用 (GOOGLE “三驾马车”)
    • Hadoop:分布式、Map-Reduce(双算子API)、离线计算
    • Spark:批处理、流出来、SQL高阶API(更多语义、使用简单)、内存迭代计算
    • Flink:流计算、实时/速度快、流批一体、Streaming/BatchSQL
  • 为什么需要流计算?
    • 大数据实时性带来价值更大:监控场景、金融风控、实时推荐等
    • 大数据实时性要求带来计算架构模式的变化
      • 批式计算
        • 离线计算,非实时
        • 静态数据集
        • 小时/天周期性计算
      • 流式计算
        • 实时计算、快速、低延迟
        • 无限流、动态、无边界数据源
        • 24h不断运行
        • 流批一体

1.2 Flink为何脱颖而出

1.2.1 流式计算引擎发展历程

MapReduce-Hadoop-Flume-Storm-Spark Streaming-Flink

  • Spark Streaming:流基于时间的切分

1.2.2 流计算引擎的对比

StormSpark StreamingFlink
streaming modelNativemini-batchNative
一致性保证at least/most OnceExactly-OnceExactly-Once
延迟低(毫秒级)高(秒级)低(毫秒级)
吞吐
容错ACKRDD Based CheckpointCheckpoint(Chandy-Lamport)
stateFulNoYes(DStream)Yes(Operator)
SQL支持NoYesYes

1.2.3 为何选择Flink

  • Exactly-Once 精确一次的计算语义
  • Stateful 状态容错 (Checkpoint)
  • Dataflow编程模型 Window等高阶需求支持友好
  • 流批一体

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at ant scale.

1.3 Flink开源生态

Screen Shot 2022-07-23 at 4.26.07 AM.png

  • 流批一体:支持流计算和批计算
  • OLAP:Fink支持OLAP短查询场景
  • Flink ML: pyFlink、Alink、AIFlow等生态支持Flink在ML场景的应用
  • Gelly:图计算
  • Stateful Function:支持有状态的FAAS场景

2.Flink整体架构

2.1 Flink分层架构

Screen Shot 2022-07-23 at 4.31.04 AM.png

  1. SDK层:Flink的三类SDK, SQL/Table、DataStream、Python;
  2. 执行引擎层(Runtime层):提供了统一的DAG,用来描述数据处理的pipeline,将流/批转化为DAG图,调度层再把DAG转化成分布式环境下的Task,Task之间通过Shuffle传输数据;
  3. 状态存储层:负责存储算子的状态信息;
  4. 资源调度层:目前Flink支持部署多种环境;

2.2 Flink总体架构

Screen Shot 2022-07-23 at 4.38.01 AM.png

  • Job Manager(JM):负责整个业务的协调工作
    • 调度Task;触发协调Task做Checkpoint;协调容错恢复
    • 小组件:
      • Dispatcher:接受作业,拉起JM执行作业,并在JobMaster Fail后恢复作业
      • JobMaster:管理JOB的整个生命周期,向resource manager申请slot,并将task调度到对应的TM上
      • Resource Manager: 负责slot资源的管理和调度,TM拉起后向RM注册
  • Task Manager(TM):负责执行一个Dataflow Graph的各个task以及data streams的buffer和数据交换

2.3 Flink实例

见实践练习例1。

2.4 Flink与流批一体

2.4.1 为何需要流批一体

  • 实时统计需要Flink流式处理
  • 按照时间段统计数据信息需要Flink的批式处理
  • 数据源(埋点日志、业务消息、数据库)-> 实时数仓Flink(Kafka基于流式数据进行统计)OR 离线数仓Hive/Spark
    • 人力成本高:流批两套系统,相同逻辑需要开发两遍
    • 数据链路冗余:本身计算内容一致,但两条链路需要计算两遍产生资源浪费
    • 数据口径不一致:两套系统产生不同程度的误差

2.4.2 流批一体的挑战

流式计算批式计算
实时计算离线计算
秒级内分钟 小时
0-1s10s-1h
数据流为无限数据集有限数据集
低延迟、业务会感知运行中的情况实时性要求不高只关注最终结果产出时间

2.4.3 Flink如何做到流批一体

批是流的特例,有限数据集(批)也是数据流,因此可以用一套引擎解决两种场景,但需要对不同场景支持不同扩展性、实现不同优化策略;一个无边界数据集也是数据流,可以切割成一段段有限数据集,因此可以使用同一套API。

  • SQL层:支持有无边界的输入
  • DataStream API层统一:都可以开发
  • Scheduler层架构统一
  • Failover Recovery层架构统一,支持流批场景
  • Shuffle Service层架构统一,流批场景选择不同service

2.4.4 scheduler层

Scheduler主要负责将作业的DAG转化为分布式环境中可执行的Task

  • EAGER模式:申请一个作业所需要的全部资源,然后同时调度这个作业的全部Task,所有Task之间采取pipeline进行通信 (Stream作业场景 需求资源多,源源不断计算)
    • 需要所有task所需的资源全部调度才能进行
  • LAZY模式:先调度上游,等待上游产生数据或结束后再调度下游,类似Spark的Stage (Batch作业场景 需求资源少,时间长)
    • 最小调度一个task即可,集群拥有1个slot就能运行
  • Pipeline Region:由pipeline的数据交换方式连接的task构成,本质上流批作业都按照pipeline region粒度来申请资源和调度任务
    • ALL_ENDGES_BLOCKING:(批处理)所有Task之间的数据交换都是BLOCKING模式,数据非实时传输,需要落盘 (12个Pipeline Region)
    • ALL_EDGES_PIPELINED:(流处理)所有Task都是pipeline模式,数据产出全部直接发给下游,不做落盘 (1个Pipeline Region)

2.4.5 shuffle service层

  • shuffle:在分布式计算中用于连接上下游数据交互的过程;实际上分布式计算中所有涉及上下游衔接都可以理解为shuffle。
  • 不同实现
    • 基于文件的 pull-based shuffle
      • 高容错性稳定性,适合大规模批处理
    • 基于pipeline的 push-based shuffle
      • 低延迟高性能
  • 流批shuffle差异
    • 数据的生命周期:流shuffle数据与task绑定,批shuffle数据与task解耦
    • 数据存储介质:流生命周期短,为实时性经常存储在内存;批数据量大容错高,存储磁盘
    • 部署方式:流服务计算节点在一起节省网络开销 减少latency,批作业不同
  • Flink对流批提供streaming和batch两种shuffle,为了统一shuffle实现了插拔模块
    • streaming/OLAP:pipeline
    • batch:blocking
  • Shuffle Service
    • Netty shuffle service:均支持,Flink默认策略
    • Remote shuffle service:pipeline会性能下降,主要用batch的blocking场景
      • 内部基于CSS实现RSS

3.Flink架构优化

3.1 流/批/OLAP业务场景概述

在实际生产环境中对数据处理要求不同,OLAP:处理时间秒级1-10s,用于数据分析BA报表等

模块流式计算批式计算交互式分析OLAP
SQLYYY
实时性高、毫秒级高、秒级、高并发查询
容错能力中、大作业失败代价高高、失败重试
状态YNN
准确性exactly-once,要求高,重跑需要回复之前的状态exactly-once,失败重跑即可exactly-once,失败重跑即可
扩展性YYY

3.2 Flink如何支持OLAP

  • 批是流的特例,OLAP是批的特例,对并发和实时性要求更高,因此实际是同一种计算
  • OLAP场景需求高并发和极致计算

3.2.1 Flink做OLAP优势

  • 引擎统一:降低学习成本提高开发与维护效率
  • 既有优势:内存计算、code-gen、pipeline shuffle、session
  • 生态支持:跨数据源查询支持、TCP-DS基准测试性能强

3.2.2 OLAP场景的挑战

  • 作业频繁启停,资源碎片:磁盘开销
  • 秒级、毫秒级小作业:并行性高
  • Latency+QPS要求

3.2.3 OLAP架构现状

  • Client:提交SQL Query;
  • Gateway:接受Client提交的SQL Query,对SQL进行语法解析和查询优化,生成Flink作业执行计划,提交给Session集群;
  • Session Cluster:执行作业调度及计算并返回结果

3.2.4 OLAP架构问题与设想

  • 架构与功能模块
    • JobManager与ResourceManager在一个进程内启动,无法对JobManager进行扩展
    • Gateway与Flink Session Cluster相互独立,无法统一进行管理 (SQL解析优化管理)
  • 作业管理和部署模块
    • JobManager处理调度作业时负责功能多,但作业处理时间长,占用过多内存;(高并发占用过多)
    • TaskManager部署计算任务时,初始化部分耗时严重,消耗大量CPU;
  • 资源管理及计算任务调度
    • 资源申请/释放流程链路长
    • slot作为资源管理单位,JM管理slot导致JM无法感知TM的资源分布,使得资源管理完全依赖于ResourceManager
  • 作业心跳/failover机制不适合AP的秒级毫秒级计算
  • AP使用Batch算子计算,初始化比较耗时

三.实践练习例

  1. Flink流式WordCount示例,从Kafka中读取一个实时数据流,每10s统计一次单词出现次数,DataStream实现代码如下:
//Source Operator
DataStream<String> lines = env.addSource(new FlinkKafkaConsumer<>(...));

//Transformation Operators
DataStream<Event> events = lines.map((line)->parse(line));
DataStream<Statistics> stats = events
    .keyBy(event->event.id)
    .timeWindow(Time.seconds(10))
    .apply(new myWindowAggregationFunction());

//Sink Operator
stats.addSink(new BucketingSink(path));
  • 设置并发度:将Streaming DataFlow Graph 转化为 Parallel Dataflow(Execution Graph)
  • 为了更高效地分布式执行,Flink会尽可能将不同的Operator连接(chain)在一起形成Task,这样每个Task可以在一个线程中执行。(operation chain当成1个task 同一thread减少线程切换、减少延迟提高吞吐)
  • 将该Task调度到具体的TaskManager中的slot中执行,一个slot只能运行同一个task的subtask
    • slot是单独的threads执行,内存未严格隔离
  1. 电商流批一体实例 如抖音流处理和批处理
  • 业务数据源 处理 计算均同源 实现真正的流批一体
  1. Flink OLAP实践 AP查询由Flink提供
  • 原本:用户更新到online存储引擎,传输到Hive,再利用Clickhouse计算并实现Query
  • 更新后:data->HTAP->Query,Flink直接提供数据查询分析能力

四.课后个人总结

  1. 复杂知识点
  • Flink的架构
  • Flink如何做到流批一体:把流批均看作数据流形式
  • Flink架构优化
  1. 个人总结

本节课从流计算的发展出发,详细介绍了Flink的架构,如何实现流批一体,以及Flink的架构针对不同业务场景的优化方法。课程中介绍的内容相对抽象,有很多的名词需要课后继续消化。同时,实践练习例的源码也值得学习。

五.引用参考

  1. 【大数据专场 学习资料一】第四届字节跳动青训营
  • 笔记中大量图解来源于本篇学习资料
  1. Flink Learn: Hands-On Training