You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@flink.apache.org by 郑 致远 <ze...@hotmail.com> on 2022/09/09 11:04:27 UTC
flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 设计的考虑是啥?
各位大佬好
请教下,
flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 这么设计的考虑是啥呢?
Re: flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 设计的考虑是啥?
Posted by yidan zhao <hi...@gmail.com>.
其实可以和kafka的pull模型对比下，kafka消费是不断轮训pull。我的认知中flink应该不是吧？
flink应该仅仅是请求 result partition 的时候下游主动去上游请求？ 建立之后应该就是类似一条连接不断读取数据？
yanfei lei <fr...@gmail.com> 于2022年9月22日周四 11:31写道：
>
> Hi,
> Flink社区有一篇关于Credit-based Flow Control的blog post
> <https://flink.apache.org/2019/06/05/flink-network-stack.html#credit-based-flow-control>
> ，里面介绍了反压机制的原理和优劣势，希望有帮助。
>
> Shammon FY <zj...@gmail.com> 于2022年9月21日周三 11:43写道：
>
> > Hi
> > 我个人觉得简单的说flink数据传输是pull模型可能会有歧义，一般来讲大家理解的两个模型的执行流程如下
> > 1. push模型
> > 上下游计算任务将初始化网络连接后，上游计算任务直接通过连接不断向下游"push"数据
> > 2. pull模型
> > 上下游计算任务初始化网络连接后，下游计算任务根据自己的计算进度，轮询向上游发送请求“pull”数据，执行下一轮计算
> >
> > 在flink里，上下游交互流程主要分为几个步骤
> > 1. 上游计算任务所在的TM创建一个Netty Server
> > 2. 下游计算任务启动时通过Netty Client跟上游创建连接
> > 3. 下游计算任务向上游发送一个partition
> > request请求，上游根据request请求创建数据reader，通过reader不断读取数据并通过连接发送数据
> > 4. 上下游计算任务分别有自己的内存池子，用于流控，大概流程如下
> > a) 下游计算任务根据数据消费内存池子情况，不定期向上游计算任务更新授信(credit)
> > b) 上游计算任务根据接收到的credit消息，更新本地管理的授信大小
> > c) 上游计算任务根据本地授信大小不断向下游计算任务发送数据
> >
> > 通过这种方式，在资源足够的情况下，可以保证数据传输是完全流式的，这跟传统的pull模型不同，可能更像是支持授信流控机制的push模型
> >
> > On Wed, Sep 21, 2022 at 9:43 AM yh z <zh...@gmail.com> wrote:
> >
> > > 你好。 Flink 采用的是 pull 模型。pull 模型的优点在于：1.
> > > 其具有更好的扩展性（下游的消费者可以根据需求增加，只需要获取到上游的消费位点）； 2. 下游的消费者可以根据需求来调整消费速率；
> > > 3.网络传输，flink 以前也尝试使用过push模型，且为了节约开销，进程间是复用 TCP连接，一个 task
> > 线程的性能瓶颈将导致整条链路的所有
> > > task 线程不能接收数据，影响整体的数据消费速率。 push模型的优点：消耗较小，不需要设计机制来一直轮训观察上游节点的数据情况。
> > >
> > > Xuyang <xy...@163.com> 于2022年9月9日周五 20:35写道：
> > >
> > > > Hi，主要是pull模型：下游主动拉取上游的数据。可以在下游的消费能力达到极限时，通过反压机制，让上游减少生产的数据。
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Best！
> > > > Xuyang
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 在 2022-09-09 19:04:27，"郑 致远" <ze...@hotmail.com> 写道：
> > > > >各位大佬好
> > > > >请教下,
> > > > >flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 这么设计的考虑是啥呢?
> > > >
> > >
> >
Re: flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 设计的考虑是啥?
Posted by yanfei lei <fr...@gmail.com>.
Hi,
Flink社区有一篇关于Credit-based Flow Control的blog post
<https://flink.apache.org/2019/06/05/flink-network-stack.html#credit-based-flow-control>
，里面介绍了反压机制的原理和优劣势，希望有帮助。
Shammon FY <zj...@gmail.com> 于2022年9月21日周三 11:43写道：
> Hi
> 我个人觉得简单的说flink数据传输是pull模型可能会有歧义，一般来讲大家理解的两个模型的执行流程如下
> 1. push模型
> 上下游计算任务将初始化网络连接后，上游计算任务直接通过连接不断向下游"push"数据
> 2. pull模型
> 上下游计算任务初始化网络连接后，下游计算任务根据自己的计算进度，轮询向上游发送请求“pull”数据，执行下一轮计算
>
> 在flink里，上下游交互流程主要分为几个步骤
> 1. 上游计算任务所在的TM创建一个Netty Server
> 2. 下游计算任务启动时通过Netty Client跟上游创建连接
> 3. 下游计算任务向上游发送一个partition
> request请求，上游根据request请求创建数据reader，通过reader不断读取数据并通过连接发送数据
> 4. 上下游计算任务分别有自己的内存池子，用于流控，大概流程如下
> a) 下游计算任务根据数据消费内存池子情况，不定期向上游计算任务更新授信(credit)
> b) 上游计算任务根据接收到的credit消息，更新本地管理的授信大小
> c) 上游计算任务根据本地授信大小不断向下游计算任务发送数据
>
> 通过这种方式，在资源足够的情况下，可以保证数据传输是完全流式的，这跟传统的pull模型不同，可能更像是支持授信流控机制的push模型
>
> On Wed, Sep 21, 2022 at 9:43 AM yh z <zh...@gmail.com> wrote:
>
> > 你好。 Flink 采用的是 pull 模型。pull 模型的优点在于：1.
> > 其具有更好的扩展性（下游的消费者可以根据需求增加，只需要获取到上游的消费位点）； 2. 下游的消费者可以根据需求来调整消费速率；
> > 3.网络传输，flink 以前也尝试使用过push模型，且为了节约开销，进程间是复用 TCP连接，一个 task
> 线程的性能瓶颈将导致整条链路的所有
> > task 线程不能接收数据，影响整体的数据消费速率。 push模型的优点：消耗较小，不需要设计机制来一直轮训观察上游节点的数据情况。
> >
> > Xuyang <xy...@163.com> 于2022年9月9日周五 20:35写道：
> >
> > > Hi，主要是pull模型：下游主动拉取上游的数据。可以在下游的消费能力达到极限时，通过反压机制，让上游减少生产的数据。
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Best！
> > > Xuyang
> > >
> > >
> > >
> > >
> > >
> > > 在 2022-09-09 19:04:27，"郑 致远" <ze...@hotmail.com> 写道：
> > > >各位大佬好
> > > >请教下,
> > > >flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 这么设计的考虑是啥呢?
> > >
> >
>
Re: flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 设计的考虑是啥?
Posted by Shammon FY <zj...@gmail.com>.
Hi
我个人觉得简单的说flink数据传输是pull模型可能会有歧义，一般来讲大家理解的两个模型的执行流程如下
1. push模型
上下游计算任务将初始化网络连接后，上游计算任务直接通过连接不断向下游"push"数据
2. pull模型
上下游计算任务初始化网络连接后，下游计算任务根据自己的计算进度，轮询向上游发送请求“pull”数据，执行下一轮计算
在flink里，上下游交互流程主要分为几个步骤
1. 上游计算任务所在的TM创建一个Netty Server
2. 下游计算任务启动时通过Netty Client跟上游创建连接
3. 下游计算任务向上游发送一个partition
request请求，上游根据request请求创建数据reader，通过reader不断读取数据并通过连接发送数据
4. 上下游计算任务分别有自己的内存池子，用于流控，大概流程如下
a) 下游计算任务根据数据消费内存池子情况，不定期向上游计算任务更新授信(credit)
b) 上游计算任务根据接收到的credit消息，更新本地管理的授信大小
c) 上游计算任务根据本地授信大小不断向下游计算任务发送数据
通过这种方式，在资源足够的情况下，可以保证数据传输是完全流式的，这跟传统的pull模型不同，可能更像是支持授信流控机制的push模型
On Wed, Sep 21, 2022 at 9:43 AM yh z <zh...@gmail.com> wrote:
> 你好。 Flink 采用的是 pull 模型。pull 模型的优点在于：1.
> 其具有更好的扩展性（下游的消费者可以根据需求增加，只需要获取到上游的消费位点）； 2. 下游的消费者可以根据需求来调整消费速率；
> 3.网络传输，flink 以前也尝试使用过push模型，且为了节约开销，进程间是复用 TCP连接，一个 task 线程的性能瓶颈将导致整条链路的所有
> task 线程不能接收数据，影响整体的数据消费速率。 push模型的优点：消耗较小，不需要设计机制来一直轮训观察上游节点的数据情况。
>
> Xuyang <xy...@163.com> 于2022年9月9日周五 20:35写道：
>
> > Hi，主要是pull模型：下游主动拉取上游的数据。可以在下游的消费能力达到极限时，通过反压机制，让上游减少生产的数据。
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Best！
> > Xuyang
> >
> >
> >
> >
> >
> > 在 2022-09-09 19:04:27，"郑 致远" <ze...@hotmail.com> 写道：
> > >各位大佬好
> > >请教下,
> > >flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 这么设计的考虑是啥呢?
> >
>
Re: flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 设计的考虑是啥?
Posted by yh z <zh...@gmail.com>.
你好。 Flink 采用的是 pull 模型。pull 模型的优点在于：1.
其具有更好的扩展性（下游的消费者可以根据需求增加，只需要获取到上游的消费位点）； 2. 下游的消费者可以根据需求来调整消费速率；
3.网络传输，flink 以前也尝试使用过push模型，且为了节约开销，进程间是复用 TCP连接，一个 task 线程的性能瓶颈将导致整条链路的所有
task 线程不能接收数据，影响整体的数据消费速率。 push模型的优点：消耗较小，不需要设计机制来一直轮训观察上游节点的数据情况。
Xuyang <xy...@163.com> 于2022年9月9日周五 20:35写道：
> Hi，主要是pull模型：下游主动拉取上游的数据。可以在下游的消费能力达到极限时，通过反压机制，让上游减少生产的数据。
>
>
>
>
>
>
>
> --
>
> Best！
> Xuyang
>
>
>
>
>
> 在 2022-09-09 19:04:27，"郑 致远" <ze...@hotmail.com> 写道：
> >各位大佬好
> >请教下,
> >flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 这么设计的考虑是啥呢?
>
Re:flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 设计的考虑是啥?
Posted by Xuyang <xy...@163.com>.
Hi，主要是pull模型：下游主动拉取上游的数据。可以在下游的消费能力达到极限时，通过反压机制，让上游减少生产的数据。
--
Best！
Xuyang
在 2022-09-09 19:04:27，"郑 致远" <ze...@hotmail.com> 写道：
>各位大佬好
>请教下,
>flink 的数据传输,是上游算子推给下游, 还是下游算子拉取上游, 这么设计的考虑是啥呢?