Apache Flink流分区器剖析

这篇文章介绍Flink的分区器,在流进行转换操作后,Flink通过分区器来精确得控制数据流向。

StreamPartitioner

StreamPartitioner是Flink流分区器的基类,它只定义了一个抽象方法:

    public abstract StreamPartitioner<T> copy();

但这个方法并不是各个分区器之间互相区别的地方,定义不同的分区器的核心在于——各个分区器需要实现channel选择的接口方法:

    int[] selectChannels(T record, int numChannels);

该方法针对当前的record以及所有的channel数目,返回一个针对当前这条记录采用的output channel的索引数组。(注意这里返回的是数组,说明一个记录可能会输出到多个channel这点我们后面会谈到)。

该接口方法来自于StreamPartitioner实现的接口ChannelSelector

分区器整体类图:

GlobalPartitioner

全局分区器,其实现很简单——默认选择了索引为0的channel进行输出。

private int[] returnArray = new int[] { 0 };

@Override
public int[] selectChannels(SerializationDelegate<StreamRecord<T>> record,int numberOfOutputChannels) {
    return returnArray;
}

ForwardPartitioner

该分区器将记录转发给在本地运行的下游的(归属于subtask)的operattion。其实现跟上面的GlobalPartitioner一致,就不贴代码了。

ShufflePartitioner

混洗分区器,该分区器会在所有output channel中选择一个随机的进行输出。

private int[] returnArray = new int[1];

@Override
public int[] selectChannels(SerializationDelegate<StreamRecord<T>> record,int numberOfOutputChannels) {
    returnArray[0] = random.nextInt(numberOfOutputChannels);
    return returnArray;
}

HashPartitioner

hash分区器,该分区器对key进行hash后计算得到channel索引。它通过构造器获得KeySelector的实例(该实例用来获取当前记录的key)。

获得key后,通过其hashcodenumberOfOutputChannels取模后计算得出最终输出的channel的索引。

    public int[] selectChannels(SerializationDelegate<StreamRecord<T>> record,
            int numberOfOutputChannels) {
        Object key;
        try {
            key = keySelector.getKey(record.getInstance().getValue());
        } catch (Exception e) {
            throw new RuntimeException("Could not extract key from " + record.getInstance().getValue(), e);
        }
        returnArray[0] = MathUtils.murmurHash(key.hashCode()) % numberOfOutputChannels;

        return returnArray;
    }

BroadcastPartitioner

广播分区器,用于将该记录广播给下游的所有的subtask。这里采用了两个标记:

  • set
  • setNumber
    public int[] selectChannels(SerializationDelegate<StreamRecord<T>> record,
            int numberOfOutputChannels) {
        if (set && setNumber == numberOfOutputChannels) {
            return returnArray;
        } else {
            this.returnArray = new int[numberOfOutputChannels];
            for (int i = 0; i < numberOfOutputChannels; i++) {
                returnArray[i] = i;
            }
            set = true;
            setNumber = numberOfOutputChannels;
            return returnArray;
        }
    }

从上面的实现可见,它返回了一个跟numberOfOutputChannels相等的数组(数组的大小就是即将输出到channel的个数)。

RebalancePartitioner

重平衡分区器,用于实现类似于round-robin这样的轮转模式的分区器。通过累加、取模的形式来实现对输出channel的切换。

    public int[] selectChannels(SerializationDelegate<StreamRecord<T>> record,
            int numberOfOutputChannels) {
        this.returnArray[0] = (this.returnArray[0] + 1) % numberOfOutputChannels;
        return this.returnArray;
    }

RescalePartitioner

也是以round-robin的形式将元素分区到下游subtask的子集中。

上游操作所发送的元素被分区到下游操作的哪些子集,依赖于上游和下游操作的并行度。例如,如果上游操作的并行度为2,而下游操作的并行度为4,那么一个上游操作会分发元素给两个下游操作,同时另一个上游操作会分发给另两个下游操作。相反的,如果下游操作的并行度为2,而上游操作的并行度为4,那么两个上游操作会分发数据给一个下游操作,同时另两个上游操作会分发数据给另一个下游操作。

在上下游的并行度不是呈倍数关系的情况下,下游操作会有数量不同的来自上游操作的输入。具体的实现代码同RebalancePartitioner

CustomPartitionerWrapper

自定义分区器包装器,该包装器封装了对于自定义的分区器的实现。自定义的分区测量依赖于Partitioner接口。它提供了自定义分区器的契约。核心接口方法是:

    /**
     * Computes the partition for the given key.
     *
     * @param key The key.
     * @param numPartitions The number of partitions to partition into.
     * @return The partition index.
     */
    int partition(K key, int numPartitions);

该接口方法的描述很清晰,通过给定的key以及numPartitions返回partition的index.

CustomPartitionerWrapper通过构造器注入Partitioner的实例,然后在selectChannels方法中通过partition接口来获得最终的channel索引。

    public int[] selectChannels(SerializationDelegate<StreamRecord<T>> record, int numberOfOutputChannels) {

        K key = null;
        try {
            key = keySelector.getKey(record.getInstance().getValue());
        } catch (Exception e) {
            throw new RuntimeException("Could not extract key from " + record.getInstance(), e);
        }

        returnArray[0] = partitioner.partition(key,
                numberOfOutputChannels);

        return returnArray;
    }

小结

以上的这些分区器,最终会体现在DataStream的API中用来对数据流进行物理分区。


微信扫码关注公众号:Apache_Flink


QQ扫码关注QQ群:Apache Flink学习交流群(123414680)

时间: 2024-10-05 21:07:29

Apache Flink流分区器剖析的相关文章

Apache Flink流作业提交流程分析

提交流程调用的关键方法链 用户编写的程序逻辑需要提交给Flink才能得到执行.本文来探讨一下客户程序如何提交给Flink.鉴于用户将自己利用Flink的API编写的逻辑打成相应的应用程序包(比如Jar)然后提交到一个目标Flink集群上去运行是比较主流的使用场景,因此我们的分析也基于这一场景进行. Flink的API针对不同的执行环境有不同的Environment对象,这里我们主要基于常用的RemoteStreamEnvironment和RemoteEnvironment进行分析 在前面我们谈到

Apache Flink fault tolerance源码剖析(一)

因某些童鞋的建议,从这篇文章开始结合源码谈谈Flink Fault Tolerance相关的话题.上篇官方介绍的翻译是理解这个话题的前提,所以如果你想更深入得了解Flink Fault Tolerance的机制,推荐先读一下前篇文章理解它的实现原理.当然原理归原理,原理体现在代码实现里并不是想象中的那么直观.这里的源码剖析也是我学习以及理解的过程. 作为源码解析Flink Fault Tolerance的首篇文章,我们先暂且不谈太有深度的东西,先来了解一下:Flink哪里涉及到检查点/快照机制来

Apache Flink fault tolerance源码剖析(二)

继续Flink Fault Tolerance机制剖析.上一篇文章我们结合代码讲解了Flink中检查点是如何应用的(如何根据快照做失败恢复,以及检查点被应用的场景),这篇我们来谈谈检查点的触发机制以及基于Actor的消息驱动的协同机制.这篇涉及到一个非常关键的类--CheckpointCoordinator. org.apache.flink.runtime.checkpoint.CheckpointCoordinator 该类可以理解为检查点的协调器,用来协调operator和state的分布

Apache Flink fault tolerance源码剖析(四)

上篇文章我们探讨了Zookeeper在Flink的fault tolerance中发挥的作用(存储/恢复已完成的检查点以及检查点编号生成器). 这篇文章会谈论一种特殊的检查点,Flink将之命名为--Savepoint(保存点). 因为保存点只不过是一种特殊的检查点,所以在Flink中并没有太多代码实现.但作为一个特性,值得花费一个篇幅来介绍. 检查点VS保存点 使用数据流API编写的程序可以从保存点来恢复执行.保存点允许你在更新程序的同时还能保证Flink集群不丢失任何状态. 保存点是人工触发

Apache Flink fault tolerance源码剖析(三)

上一篇文章我们探讨了基于定时任务的周期性检查点触发机制以及基于Akka的actor模型的消息驱动协同机制.这篇文章我们将探讨Zookeeper在Flink的Fault Tolerance所起到的作用. 其实,Flink引入Zookeeper的目的主要是让JobManager实现高可用(leader选举). 因为Zookeeper在Flink里存在多种应用场景,本篇我们还是将重心放在Fault Tolerance上,即讲解Zookeeper在检查点的恢复机制上发挥的作用. 如果用一幅图表示快照机制

Apache Flink fault tolerance源码剖析(五)

上一篇文章我们谈论了保存点的相关内容,其中就谈到了保存点状态的存储.这篇文章我们来探讨用户程序状态的存储,也是在之前的文章中多次提及的state backend(中文暂译为状态终端). 基于数据流API而编写的程序经常以各种各样的形式保存着状态: 窗口收集/聚合元素(这里的元素可以看作是窗口的状态)直到它们被触发 转换函数可能会使用key/value状态接口来存储数据 转换函数可能实现Checkpointed接口来让它们的本地变量受益于fault tolerant机制 当检查点机制工作时,上面谈

Apache Flink fault tolerance源码剖析完结篇

这篇文章是对Flinkfault tolerance的一个总结.虽然还有些细节没有涉及到,但是基本的实现要点在这个系列中都已提及. 回顾这个系列,每篇文章都至少涉及一个知识点.我们来挨个总结一下. 恢复机制实现 Flink中通常需要进行状态恢复的对象是operator以及function.它们通过不同的方式来达到状态快照以及状态恢复的能力.其中function通过实现Checkpointed的接口,而operator通过实现StreamOpeator接口.这两个接口的行为是类似的. 当然对于数据

Apache Flink源码解析之stream-operator

前面我们谈论了Flink stream中的transformation.你可以将transformation看成编写Flink程序并构建流式处理程序的必要组成部分(静态表现形式):而本篇我们将探讨transformation在Flink运行时对应的动态表现形式--operator.他们之间的映射关系见下图: 具体的探讨可以查看前文:Flink中的一些核心概念 StreamOperator 所有operator的最终基类,operator的分类方式,按照输入流个数不同分为: 无输入:StreamS

Apache Flink源码解析之stream-window

window(窗口)是Flink流处理中非常重要的概念,本篇我们来对窗口相关的概念以及关联的实现进行解析.本篇的内容主要集中在package org.apache.flink.streaming.api.windowing下. Window 一个Window代表有限对象的集合.一个窗口有一个最大的时间戳,该时间戳意味着在其代表的某时间点--所有应该进入这个窗口的元素都已经到达. Flink的根窗口对象是一个抽象类,只提供了一个抽象方法: public abstract long maxTimes