Flink keyBy与RichParallelSourceFunction

Question

我正在学习flink，试图理解一些概念。以下是几个问题：

1. keyby对流的操作与从richparallelsourcefunction像flinkkinesisconsumer这样的儿童获取源代码有什么区别？这两个操作都分割流。
2. 还尝试实现一个非常简单的keyBy操作符来理解它，如下所示:DataStream input=env.fromelements（“1”,“2”,“3”,“4”,“5”,“6”）.keyBy（（keyselector )value->integer.parseint（value）%2）；DataStream parsed=input.map（新的MyMapper（））；DataStream parsedStr=input.map（新的MyStrMapper（））；parsed.print（）；parsedstr.print（）；Env.execute（“MyParser”）；

但我得到的输出令人困惑：

3> 1
3> 2
3> 3
3> 4
3> 5
3> 6
3> I am 1
3> I am 2
3> I am 3
3> I am 4
3> I am 5
3> I am 6

这意味着在子任务3上执行的所有内容。有人能帮忙解释一下原因吗？

Answer 1

（1）使用keyby和使用richParallelSourceFunction之间的区别？

每次使用keyby时，流记录必须经过序列化/反序列化，并且很可能通过网络发送。另一方面，源实例可以链接到后续操作，这意味着流记录只是作为java堆上的对象传递。

当你有像Kafka或Kinesis这样的多个源实例时，它们不会分割流。每个实例独立地连接到相关的代理/服务器，以处理分配给它们处理的分区/碎片的记录。因此，使用RichParallelSourceFunction，可以实现性能更好的管道，同时减少序列化/反序列化和联网的开销。

您的keyselector函数的结果是散列的，这些散列值取mod128（假设您没有重新配置键组的数量），以将每个键映射到一个键组。然后，Flink确定哪个子任务负责这些关键组。

如果您的key函数只能返回两个不同的值（0和1)，那么您只会看到一个或两个不同的子任务在使用。显然，0和1都哈希到分配给子任务3的关键组。

只要有可能，最好有一个比集群的并行性大得多的密钥空间。

null