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

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

Apache Flink的特点

为什么需要流式计算

1. 实时数据价值更大
2. 大数据批式处理分钟级、小时级等部分业务场景无法接受

流式计算特点

1. 实时计算、快速、低延迟
2. 无限流、动态、无边界
3. 持续运行

Flink架构

分层架构

整体架构

• JobManager(JM) 负责整个任务的协调工作，包括调度task、出发协调task做checkpoint、协调容错

  • Dispatcher: 接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业；

  • JobMaster: 管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task 调度到对应 TM 上；

  • ResourceManager：负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册

• TaskManager（TM）：负责执行一个 DataFlow Graph 的各个 task 以及 data streams 的 buffer 和数据交换。

Flink流批一体

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

• SQL 层；

• DataStream API 层统一，批和流都可以使用 DataStream API 来开发；

• Scheduler 层架构统一，支持流批场景

  • EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信；
  • LAZY（Batch 场景）：先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式。

• Failover Recovery 层 架构统一，支持流批场景；

• Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service

  • 在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle。实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle
  • Shuffle 数据的生命周期：流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的
  • Shuffle 数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里；
  • Shuffle 的部署方式：流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业则不同。

OLAP

暂时忽略

Others（个人思考，不一定对）

• Dataflow Model核心设计思想
  • ParDo，类似于一个RDD的map和flatmap算子
  • GroupByKey，类似 Spark 中的聚合算子，需要结合窗口一起使用
  • watermark
• Flink反压
  • 短时负载高峰导致系统接收数据的速率远高于它处理数据的速率————反压
  • Flink天然可以处理反压，因为 Flink 中的数据传输相当于已经提供了应对反压的机制。
  • Storm 是通过监控 Bolt 中的接收队列负载情况，如果超过高水位值就会将反压信息写到 Zookeeper ，Zookeeper 上的 watch 会通知该拓扑的所有 Worker 都进入反压状态，最后 Spout 停止发送 tuple。