Flink架构（二）- Flink中的数据传输

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

2. Flink中的数据传输

在一个运行的application中，它的tasks在持续交换数据。TaskManager负责做数据传输。TaskManager的网络组件首先从缓冲buffer中收集records，然后再发送。也就是说，records并不是一个接一个的发送，而是先放入缓冲，然后再以batch的形式发送。这个技术可以高效使用网络资源，并达到高吞吐。类似于网络或磁盘 I/O 协议中使用的缓冲技术。

这里需要注意的是：传输缓冲buffer中的记录，隐含表示的是，Flink的处理模型是基于微批处理的。

每个TaskManager有一组网络缓冲池（默认每个buffer是32KB），用于发送与接受数据。如发送端和接收端位于不同的TaskManager进程中，则它们需要通过操作系统的网络栈进行交流。流应用需要以管道的模式进行数据交换，也就是说，每对TaskManager会维持一个永久的TCP连接用于做数据交换。在shuffle连接模式下（多个sender与多个receiver），每个sender task需要向每个receiver task，此时TaskManager需要为每个receiver task都分配一个缓冲区。下图展示了此架构：

在上图中，有四个sender 任务，对于每个sender，都需要有至少四个network buffer用于向每个receiver发送数据。每个receiver都需要有至少四个buffer用于接收数据。TaskManager之间的buffer以多路复用的方式使用同一网络连接。为了提供平滑的数据管道型的数据交换，一个TaskManager必须能提供足够的缓冲，以服务所有并行的出入连接。对于shuffle或broadcast 连接，每个发送任务和每个接受任务之间都需要一个buffer。Flink的默认网络缓冲配置足够适用与小型与中型的集群任务。对于大型的集群任务，需要对此配置进行调优。

若sender与receiver任务都运行在同一个TaskManager进程，则sender任务会将发送的条目做序列化，并存入一个字节缓冲。然后将缓冲放入一个队列，直到队列被填满。Receiver任务从队列中获取缓冲，并反序列化输入的条目。所以，在同一个TaskManager内，任务之间的数据传输并不经过网络交互。

Flink采用了不同的技术用于减少tasks之间的沟通成本。在接下来的部分中，我们会讨论基于积分的（credit-based ）流控制与任务链（task chaining）。

基于积分的（Credit-Based ）流控制

通过网络发送单独的条目是一个并不高效的方式，并且会造成大量负载。使用缓冲技术可以更好的使用网络连接的带宽。在流处理场景中，缓冲的一个缺点是：它增加了延时，因为records需要先放入缓冲，而不是被立即传输。

Flink实现了一个credit-based 流控制机制，工作方式为：一个接收任务会授权给一个发送任务一些积分（credit），用于控制预留的缓冲区个数。当一个sender接收到了积分通知，它向会receiver发送 buffers（最多不超过被授权的数量）以及它的backlog大小（已经充满了并等待被发送的buffer数量）。Receiver使用预留的buffer处理接收到的数据，并使用sender的backlog大小作为下一次授权的积分数，提供给所有与它连接的senders。

Credit-based 流控制减少了延时，因为senders可以在receiver有足够的资源接受数据时，尽快向它发送数据。它在Flink中是一个重要的部分，助力Flink达到高吞吐与低延时。

任务链（task chaining）

Flink另一个优化技术称为任务链，用于（在某些情况下）减少本地通信的过载。为了满足任务链的条件，至少两个以上的operator必须配置为同一并行度，并且使用本地向前的（local forwad）方式连接。下图的operator管道即满足这些条件。它包含3个operators，全部被配置为并行度为2，并且以local-forward的方式连接：

下图描述了管道是如何以任务链的方式执行的。Operators的函数被融合成单个任务，并由一个单独的线程执行。一个function产生的records，通过使用一个简单的方法调用，被递交给下一个function。所以，这里在方法之间的records传递中，基本没有序列化以及通信消耗。

任务链可以极大减少本地task之间的通信成本，但是有时候在执行一个管道时，不使用任务链也是合理的。例如，将一个包含多个链式任务的长管道断开，或是将一个链分成两个任务，并将较为消耗资源的function调度到另一个slot上。这些都是合理的。下图描绘了同样一个执行的管道，但未使用任务链。所有function由一个单独的task，在它自身的线程中运行。