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

用户9125081449100
132 阅读7分钟

流/批/OLAP 一体的 Flink

Flink概述

1. Apache Flink诞生背景

  • 什么是大数据： 大数据指无法在一定时间内用常规软件工具对其进行获取，存储，管理和处理集合（4v）

image.png

  • 大数据架构发展史：

image.png

  • 为什么需要流式计算： 大数据实时性带来价值更大比如：
  1. 监控场景：实时发现业务系统的健康状态，能提前避免业务障碍

  2. 金融风控：实时监测异常交易行为，能及时阻断新风险

  3. 实时推荐：像淘宝，抖音等根据数据挖掘用户的种种实时推荐内容

大数据实时性带来了架构模式改变

image.png

2. 为什么 Apache Flink脱颖而出

  • 引擎发展历程

image.png

  • 流式计算引擎对比 流式计算框架对比：

image.png

  • why Flink
  1. Exactly-Once  精确一次的计算语义

  2. 状态容错 Checkpoint

  3. Dataflow编程模式  Window等高阶需求支持友好

  4. 流批一体

3. Apache Flink开源生态

image.png

整体架构

image.png

  • 分层架构
  1. SDK层：Flink 的SDK目前主要有三类：SQL/Table，DataStream，Python

  2. 执行引擎层：执行引擎层提供了统一的DAG，用来描述数据处理的PIpeline，不论流批，都转化为DAG图，调度层再把DAG转化为分布式环境下的Task，Task之间通过Shuffle传输数据

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

  4. 资源调度层：目前Flink可以支持部署在多种环境
  • 总体架构 一个Flink集群，主要包含一下两个核心组件
  1. JObManager（JM）：负责任务协调，调度task，触发task做Checkpoint，协调容错恢复

  2. TaskManager（TM）：执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换
    JobManager职责 image.png
  3. Dispatcher：接收作业，拉起JobManager来执行作业，并在JobMaster挂掉后回复作业
  4. JobMaster：管理严格job的整个生命周期，会向ResourceManager申请slot，并将task调度到对应TM上、
  5. ResourManager：负责slot资源的管理和调度，Task manager拉起之后向RM注册
  • 作业演示

image.png

image.png

image.png

image.png

image.png

  • 如何流批一体 1. 为什么需要流批一体 （下图是流处理和批处理分开进行） image.png 图上架构的缺点：
  •     成本高：两套系统，逻辑相同但是需要开发两次

  •     数据链冗余：计算内容一致，但是都是两条链路，相同逻辑运行两次浪费资源

  •     数据口径不一致：两套系统，两套算子，两套udf，通常会产生不同程度的误差给业务带来非常大的困扰

2. 流批一体的挑战

两者处理业务的反应时间不同从而导致处理的业务也有所不同：

  • 流处理实时性采用实时处理，通常反应时间在0·1s内，所接触的业务为广告推荐，金融风控。数据流为无限数据流，可以随时处理数据
  • 批处理离线计算，处理时间以分钟到小时级别，甚至天级别，接触的业务为搜索引擎构建索引，批式数据分析等，数据流为有限数据流，根据数据流的大小决定处理时间，实时性要求不高只关注最终结果产出时间 3. Flink如何做到流批一体

批式处理是流式计算的特例，Everything is Streams，有界数据集也是一种特殊的数据流，所以可以用一套引擎来解决流批处理，只不过需要对不同的场景支持相应的扩展性，并允许不同的优化策略

image.png 在Flink的角度，Everything is Streams，无边界数据集是一种数据流，按时间切片成一个个有边界的数据集，所以有界数据集也是数据流。所以批和流式Flink都是天然支持的，并且从API到底层处理机制都统一的，是真正意义的流批一体

Apache Flink 主要从一下几个模块来做流批一体：

  1. Sql层
  2. DataStream API层统一，批流处理都可以使用DataStream API来开发
  3. Scheduler层架构统一，支持流批场景
  4. Failover Recovery层 架构统一，支持流批场景
  5. Shuffle Service 层 架构统一，流批场景选择不同的Shuffle Service

4. 流批一体的Scheduler层 Scheduler主要负责将作业的DAG转化为分布式环境可执行的Task

image.png 1.12之前的Flink支持Evger和LAZY调度 image.png

image.png

image.png

  • 由Pipeline的数据交换方式连接的Task构成为一个Pipeline Region
  • 本质上不论流批，都按照Pipeline Region粒度来申请资源和调度任务
  • ALL_EDGES_BLOCKING:所有task数据交换都是BLOCKING模式，分为12个pipeline region
  • ALL_EDGES_PIPELINED:所有task数据交换都是PIPELINE模式，分为1个pipeline region

5. 流批一体的Shuffle Service层

针对不同的分布式计算框架shuffle通常几种不同的实现：

  1. 基于文件的Pull Based Shuffle，比如spark或MR，特点是容错性高，适合较大规模的处理作业，由于是基于文件的，他容错性和稳定性会更好一点
  2. 基于Pipeline的Push Based Shuffle，比如Flink，Storm，Presto等，她的特点是低延迟和高性能，但是因为Shuffle数据梅村粗下来，如果是batch任务的话，就需要进行重跑恢复

流和批 Shuffle之间的差异

  1. Shuffle数据的生命周期：流作业的Shuffle数据与Tas是绑定的，而批作业的Shuffle数据与Task是解耦的
  2. Shuffle数据存储介质：流作业生命周期较短，而且流作业为了实时性，Shuffle通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般存在磁盘里面
  3. Shuffle的部署方式：流作业Shuffle服务和计算节点都部署在一起，可以减少网络开销没从而减少latency，而批作业不同

image.png

image.png 对于Shuffle Service，Flink开源社区已经支持：

  1. Netty Shuffle Service：既支持Pipeline又支持blocking，Flink默认的Shuffle Service策略
  2. Remot Shuffle Service：既支持Pipeline 又支持blocking，不过对于pipeline模式，走remote反而性能下降，主要是有用在batch的blocking场景，字节内部是基于Css来实现RSS

image.png

架构优化

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

image.png

image.png 为什么三种场景可以用一套引擎解决

image.png

image.png Flink如何支持OLAP场景

  1. Flink做OLAP的优势

image.png 2. FlinkOLAP场景的挑战

image.png 3. Flink架构现状

  • Client：提交SQl Query
  • Gateway：接收Client提交的SQL Query，对SQL进行语法解析和查询优化，生成Flink作业执行计划，提交给Session集群
  • Session Cluster：执行调度及计算，并返回结果 image.png
  1. Flink在OLAP架构的问题和设想
  • 架构功能模块
  1. JobManager与ResourceManager在一个进程内启动，无法对JobManager进行水平扩展
  2. Gateway与Flink Session Cluster互相独立，无法进行统一管理
  • 作业管理及部署模块
  1. JobManager处理和调度作业时，负责的功能比较多，导致单作业处理时间长，并占用了过多内存
  2. TaskManager部署计算任务时，任务初始化部分耗时严重，消耗大量CPU
  • 资源管理及计算任务调度
  1. 资源申请及资源释放流程链路过长
  2. Slot作为资源管理单位，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager
  • 其他
  1. 作业心跳与Failover机制，并不适合Ap这种秒级计算场景
  2. AP目前使用Batch算子进行计算，这些算子初始化比较耗时
  • 总结

image.png

案例

image.png

image.png

avatar
文章
阅读
粉丝