【零基础学flink】flink的分布式运行环境

版权声明:转载请保留文末二维码 https://blog.csdn.net/liewen_/article/details/89673351
  • 任务和转换链 (tasks andtransformations chains)
  • Job Managers, Task Managers, Clients
  • 任务槽和资源(Task Slots and Resources)
  • State Backends
  • 保存点(savepoint)

任务和转换链 (tasks andtransformations chains)

对于分布式执行,flink的转换链会将任务进行切分。每个任务由一个线程执行。切分后的任务执行完后会进行合并,这是一项很好的优化:它可以减少线程到线程切换和缓冲的开销,并在降低延迟的同时提高整体吞吐量。可以配置链接行为; 有关详细信息,请参阅链接文档

下图中的示例数据流由五个子任务执行,因此具有五个并行线程。

Job Managers, Task Managers, Clients

Flink运行时包含两种过程:

  • JobManagers(也称为master):主要是协调分布式执行。他们安排任务,协调检查点,协调故障恢复等。

    总是至少有一个Job Manager。高可用性配置一般通过配置JobManagers集群,其中一个始终是leader(主机),其他人处于standby(从机)

  • TaskManagers(也叫worker):主要是执行数据流处理任务(或者更具体地说,执行子任务),以及缓冲器、数据交换。

注:必须始终至少有一个TaskManager。

JobManagers和TaskManagers可以通过多种方式启动:作为独立集群直接在机器上启动,在容器中启动,或由YARNMesos等资源框架管理。TaskManagers连接到JobManagers,并告知JobManagers自己可用,可以执行任务。

client不是运行时环境和程序执行的一部分,它主要是用来执行准备工作和向JobManager发送的数据流。之后,client可以断开连接或保持连接以接收进度报告。client既可以是触发执行的Java / Scala程序,也可以是命令行进程中运行./bin/flink run ...

任务槽和资源(Task Slots and Resources)

每个worker(TaskManager)都是一个JVM进程,可以在不同的线程中执行一个或多个子任务。为了控制worker接受任务的数量,work有所谓的任务槽(task slots)(至少一个)。

每个task slots占用了TaskManager中的部分资源。例如,具有三个task slots的TaskManager,每个task slots将占用TaskManager 1/3的内存。资源分配给task slots也意味着子任务不之间不存在资源的竞争,每个slot具有一定量的预留托管内存。请注意,这里没有CPU隔离; slot之间只有内存的预分配,cpu没有预先分配。

通过调整任务槽(task slots)的数量,用户可以定义子任务如何相互隔离。有一个插槽的TaskManager意味着每个任务组在一个单独的JVM中运行(例如,可以在一个单独的容器(container)中启动)。拥有多个插槽意味着更多子任务共享同一个JVM。同一JVM中的任务共享TCP连接(通过多路复用)和心跳消息。它们还可以共享数据集和数据结构,从而减少每任务开销。

默认情况下,Flink允许子任务共享插槽(slots ),即使它们是不同任务的子任务,只要它们来自同一个作业就可以。这致使一个槽slots 可以持有(hold)一个作业的完整pipline。允许插槽共享有两个主要好处:

  • Flink集群只需要设置与作业中的最高并行度一样多的任务槽。无需计算程序总共包含多少任务(具有不同的并行性)。

  • 更容易获得更好的资源利用率。没有插槽共享,非计算密集型 子任务将会被阻塞,但是计算性和IO型任务将占用一样多的资源,这会造成CPU资源的浪费。通过插槽共享,将示例中的基本并行性从2增加到6可以充分利用时隙资源,同时确保繁重的子任务在TaskManagers之间公平分配。

API还包括可用于防止不期望的时隙共享的*资源组*机制。

根据经验,一个很好的默认任务槽数就是CPU核心数。使用超线程,每个插槽然后需要2个或更多硬件线程上下文。

State Backends

当检查点(checkpoint)机制启动时,状态将在检查点中持久化来应对数据丢失以及恢复。而状态在内部是如何表示的、状态是如何持久化到检查点中以及持久化到哪里都取决于选定的State Backend。

存储键/值索引的确切数据结构取决于所选的State Backends。一个State Backends将数据存储在内存中的hash map中,另一个State Backends使用RocksDB作为键/值存储。除了定义保存状态的数据结构之外,State Backends还实现逻辑以获取键/值状态的时间点快照,并将该快照存储为检查点的一部分。

保存点(savepoint)

用Data Stream API编写的程序可以从savepoint恢复执行。checkpoint允许更新程序和Flink群集,而不会丢失任何状态。

保存点手动触发的检查点(checkpoint),主要是通过快照保存当前状态,然后程序的快照并将其写入 State Backends。这依靠检查点机制。在执行期间,程序会定期在work节点上创建快照并生成检查点。对于恢复操作来说,仅需要最后一次的检查点,并且一旦完成新检查点,就可以丢弃到旧检查点。

保存点(savepoint)与这些定期检查点(checkpoint)机制类似,不同之处在于savepoint是由用户触发,并且在较新的检查点完成时savepoint不会自动过期。可以从命令行创建保存点,也可以通过REST API取消作业。


扫描下方二维码,及时获取更多互联网求职面经javapython爬虫大数据等技术,和海量资料分享
公众号**菜鸟名企梦后台发送“csdn”即可免费领取【csdn】和【百度文库】下载服务;
公众号
菜鸟名企梦后台发送“资料”:即可领取5T精品学习资料**、java面试考点java面经总结,以及几十个java、大数据项目资料很全,你想找的几乎都有
扫码关注,及时获取更多精彩内容。(博主今日头条大数据工程师)

猜你喜欢

转载自blog.csdn.net/liewen_/article/details/89673351