Flink的流批一体（上） | 青训营笔记

小小农农
148 阅读8分钟

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

1 Flink 概述

引子：大数据结构体系是什么样的？有哪些计算架构？为什么需要流式计算？
大数据：无法在一定时间内用常规软件工具对其进行获取、储存、管理和处理的数据集合。
大数据具有以下特点：
海量化（Volumes）：数据量规模大
多样化（Variety）：来源丰富，包含结构化和半结构化的数据，如即时消息，音视频流等。
快速化（Velocity）：数据产生速度快。
价值化（Value）：数据密度小，但是总体价值大。

1.1 Flink 诞生背景

计算框架发展历史 image.png 大数据技术起源于Google在2004年前后发表的三篇文章，也就是 “三驾马车”，分别是：
分布式文件系统GFS；
大数据分布式计算框架MapReduce；
NoSQL数据库系统BigTable；
一个是文件系统，一个是计算框架，一个是数据库系统。MapReduce某些情况下处理数据性能较差，spark采用了内存迭代计算来进一步优化引擎。此外MapReduce的接口比较原始，spark内置了SOL高阶API，可以表达更多语义。Spark的批处理速度比Hadoop MapRecue快近10倍，内存中的数据分析速度则快近100倍。

1）Hadoop MapRedue 的表达能力有限。
所有计算都需要转换成 Map 和 Reduce 两个操作，不能适用于所有场景，对于复杂的数据处理过程难以描述。
2）Hadoop MapRedue 磁盘 I/O 开销大。
Hadoop MapReduce 要求每个步骤间的数据序列化到磁盘，所以 I/O 成本很高，导致交互分析和迭代算法开销很大，而几乎所有的最优化和机器学习都是迭代的。所以，Hadoop MapReduce 不适合于交互分析和机器学习。
3）Hadoop MapRedue 计算延迟高。
如果想要完成比较复杂的工作，就必须将一系列的 MapReduce 作业串联起来然后顺序执行这些作业。每一个作业都是高时延的，而且只有在前一个作业完成之后下一个作业才能开始启动。因此，Hadoop MapReduce 不能胜任比较复杂的、多阶段的计算服务。
4）Spark 是基于内存的迭代计算框架，适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多，所需读取的数据量越大，受益越大；数据量小但是计算密集度较大的场合，受益就相对较小。
5）Spark 适用于数据量不是特别大，但是要求实时统计分析的场景。

1.2 Flink脱颖而出的特点

对于数据处理实时性要求的提高催生了Flink流式计算框架。

流式计算的适用背景：
1.监控场景：实时监控业务系统运行状态，保持系统健康运行，提前避免业务障碍。
2.金融风控：检测异常交易，阻断风险发生。
3.实时推荐：根据用户行为对其兴趣偏向或爱好进行相关内容推荐。

批式计算和流式计算特点 image.png

流式计算框架对比 image.png

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

1.3 Flink 的开源生态

image.png

2 Flink整体架构

1 分层架构

  • SDK层：SQL/Table、DataStream、Python；

  • 执行引擎层：提供了统一的 DAG，用来描述数据处理的 Pipelin，调度层再把 DAG 转化成分布式环境下的 Task，Task 之间通过 Shuffle 传输数据

  • 状态存储层：存储算子的状态信息

  • 资源调度层：YARN/K8S

2 总体架构

  • JobManager：负责整个任务的协调工作调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等，核心有下面三个组件：Dispatcher、JobMaster、ResourceManager。

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

image.png

3 作业示范
实现Wordcount功能。

image.png

4 流批一体

  • 为何需要流批一体？
    某些业务场景，除了实时的数据统计需求，为了确认运营或产品的效果，同时还需要和历史数据做比较。如直播和销售数据统计等等。

image.png 采用流式处理和批式处理分开的方式有以下缺点:
1. 人力成本比较高：批、流两套系统，相同逻辑需要开发两遍；
2. 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
3. 数据口径不一致：两套系统、两套算子、两套 UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。

  • 流批一体的挑战
    流式处理和批式处理特点比较： image.png 核心区别： 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。

    • 流批一体的Scheduler层
      Scheduler 主要负责将作业的 DAG 转化为在分布式环境中可以执行的 Task；
      1.12 之前的 Flink 版本，Flink 支持两种调度模式：Everything is Streams，可以把批式计算当成是流式计算的特例。无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流、一种特殊的数据流；Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。 image.png EAGER：必须先调度好所有的task，作业才会开始。 LAZY：至少调度一个task就可以运行。

      目前的Flink调度机制： 提出了Pipeline Region Scheduler 机制，对流与批计算模型的抽象，在一个调度器内可以实现对流和批不同的调度。 image.png

    • 流批一体的 Shuffle Service 层
      Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle。实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle；基于不同的分布式计算框架，shuffle又有不同的实现。
      1、 基于文件的 Pull Based Shuffle，如 Spark 或 MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；
      2、 基于 Pipeline 的 Push Based Shuffle，如 Flink、Storm、Presto 等，它的特点是低延迟和高性能，但是因为 shuffle 数据没有存储下来，如果是 batch 任务的话，就需要进行重跑恢复；

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

Flink 流批一体总结

经过相应的改造和优化之后，Flink 在架构设计上，针对 DataStream 层、调度层、Shuffle Service 层，均完成了对流和批的支持。业务已经可以非常方便地使用 Flink 解决流和批场景的问题了。

avatar
文章
阅读
粉丝