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

小叶要努力
162 阅读8分钟

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

一、本课堂重点内容

IMG_4373.PNG

二、详细知识点介绍：

本节课程主要分为四个方面：

  1. Apache Flink 概述；
  1. 流批一体的 Apache Flink 架构；
  1. Apache Flink 的 OLAP 场景面临的问题及优化思路；
  1. Flink 使用案例；

为什么 Flink 会脱颖而出

  • 流式计算引擎发展历史

    • Storm：History of Apache Storm and lessons learned - thoughts from the red planet；

      • Storm API 的 low-level 以及开发效率低下；
      • 一致性问题：Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证；

    • Spark Streaming：An Architecture for Fast and General Data Processing on Large Clusters；

      • Spark Streaming 相比于 Storm 的低阶 API 以及无法正确性语义保证，Spark 是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的 API 抽象，同时提供流式处理正确性保证。

    • Flink：从产品技术来看，Flink 作为一个最新的实时计算引擎，具备如下流计算技术特征：

      • 完全一次保证：故障后应正确恢复有状态运算符中的状态；
      • 低延迟：越低越好。许多应用程序需要亚秒级延迟；
      • 高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要；
      • 强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低；
      • 流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能；
      • 乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果；
      • 完备的流式语义：支持窗口等现代流式处理语义抽象；
      • Google Dataflow Model 的开源引擎实现。
  • 主要的流式计算引擎能力对比

Flink分层架构

1.SDK层：SQL\DataStream\Python；
2.执行引擎层（Runtime层）
3.状态存储层
4.资源调度层

image.png  

Flink整体架构

核心组件：

1.     JobManager（JM）

2.     TaskManager（TM）

  • 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 和数据交换。

2.3.  Flink作业示例

流式的WordCount 示例，从 kafka中读取一个实时数据流，每10s统计一次单词出现次数，DataStream 实现代码如下:

image.png

业务逻辑转换为一个Streaming DataFlow Graph

image.png

 

假设作业的sink算子的并发配置为1，其余算子并发为2

紧接着会将上面的Streaming DataFlow Graph转化 Parallel Dataflow(内部叫Execution Graph ) :

image.png

为了更高效地分布式执行，Flink 会尽可能地将不同的operator 链接（chain)在一起形成 Task,。

这样每个Task可以在一个线程中执行，内部叫做OperatorChain，如下图的source和map算子可以 Chain在一起。

image.png

最后将上面的Task调度到具体的TaskManager中的slot中执行，一个 Slot 只能运行同一个task的subTask

image.png

 

2.4 Flink如何做到流批一体

为什么需要流批一体？

image.png

上述架构有一些痛点:

1.     人力成本比较高:批、流两套系统，相同逻辑需要开发两遍;

2.     数据链路冗余:本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一

3.     数据口径不一致:两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差

 

批式计算相比于流式计算核心的区别如下表:

image.png

为什么可以做到流批一体呢?

1． 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流;

2． 因此，理论上我们是可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

  image.png

  Flink 如何做到流批一体

批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；

站在 Flink 的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。

  因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink支持流批一体的基础。并且Flink在流批一体上，从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。

 

image.png

 

LAZY模式

最小调度一个 task 即可，集群有1个 slot资源可以运行

image.png

  2.4.4.流批一体的Scheduler层

·由Pipeline的数据交换方式连接的Task构成为一个 Pipeline Region;

·本质上，不管是流作业还是批作业，都是按照 Pipeline Region粒度来申请资源和调度任务。

image.png

image.png  

2.4.5.流批一体的Shuffle Service层

Shuffle:在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle。

实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle.

 

针对不同的分布式计算框架，Shuffle 通常有几种不同的实现:

1． 基于文件的Pull Based Shuffle，比如 Spark 或MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些;

2． 基于 Pipeline的 Push Based Shuffle，比如 Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为shufie数据没有存储下来，如果是 batch任务的话，就需要进行重跑恢复;

 

流和批 Shuffle之间的差异:

1.     Shuffle 数据的生命周期:流作业的Shuffle数据与Task是绑定的，而批作业的Shuffie数据与Task是解耦的;

2.     Shuffle数据存储介质:流作业的生命周期比较短、而且流作业为了实时性，Shuffie通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里;

3.     Shuffle的部署方式:流作业 Shuffle服务和计算节点部署在一起，可以减少网络开销，从而减少 latency,而批作业则不同。

 

 

Flink对于流和批提供两种类型的 Shuffle，虽然 Streaming和Batch Shuffle在具体的策略上存在一定的差异，但本质上都是为了对数据进行Re-Partition，因此不同的Shuffle之间是存在一定的共性的。

所以 Flink 的目标是提供一套统一的Shuffle 架构，既可以满足不同Shuffle在策略上的定制，同时还能避免在共性需求上进行重复开发。

 

在Streaming和 OLAP场盒

·为了性能的需要,通常会使用基于Pipeline的Shuffle模式

·在Batch场景·

—般会选取 Blocking的 Shuffle模式

为了统一 Flink在 Streaming和 Batch模式下的Shuffle架构，Flink 实现了一个Pluggable的 Shuffle Service框架,抽象出一些公共模块。

image.png

OLAP场景需求

短查询作业场景：高并发支持；极致处理性能（核心需要解决的问题）

 

OLAP的优化之路

 

1.Flink做OLAP的优势

image.png

2.Flink做OLAP的挑战

1)     秒级和毫秒级的小作业

2)     Latency+QPS的要求

3)     作业频繁启停，资源碎片

三、个人总结：

  1. Dataflow Model 核心设计思想是什么？
  1. Flink 相比于 Storm、Spark Streaming 有哪些优势？
  1. 为什么 Flink 可以做到支持 流/批/OLAP 三种业务场景？三种业务场景核心差异和挑战是哪些？
  1. 流式场景中，反压一种经常遇到的 case，Flink 是如何处理反压的？你知道其他引擎是怎么处理的么？
  1. Flink JobManager 各个组件分别是做什么的？你觉得为什么要这样设计？
  1. 有兴趣的，可以参考 First steps、Intro to the DataStream API、Learn Flink Overview 几篇文档，本地跑一个 Flink Job 试下。

四、参考文献

推荐文章：

  1. 大数据十年回顾：浪潮之巅数英雄_大数据_宋词_InfoQ精选文章；
  1. 大数据技术简介 - 掘金；
  1. 大数据Hadoop之--实时计算流计算引擎Flink(Flink环境部署) - 掘金；
  1. 现代流式计算的基石：Google DataFlow；
  1. Apache Flink: What is Apache Flink? - Architecture；
  1. Streaming 101: The world beyond batch(A high-level tour of modern data-processing concepts)；
  1. Streaming 102: The world beyond batch(The what, where, when, and how of unbounded data processing)；
  2. Streaming 101: The world beyond batch(A high-level tour of modern data-processing concepts)；
avatar
文章
阅读
粉丝