我们一直在玩Flink。到目前为止，我们一直在Hadoop2.x/YARN上使用Spark和标准M/R。
除了YARN上的Flink执行模型之外，AFAIK不像执行器在YARN中动态获取和释放虚拟核心的spark那样是动态的，问题的要点如下。
Flink似乎很神奇：对于流式传输API的，我只想说它很出色，非常棒。
Batch API的：处理图非常强大，并以独特的方式优化和并行运行，比Spark和其他产品更能利用集群可扩展性，优化共享共同处理步骤的非常复杂的DAG。
我发现的唯一缺点，我希望只是我的误解和知识的缺乏，是在计划使用HDFS上的输入的批处理作业时，它似乎不喜欢数据本地处理。
不幸的是，这不是一个小问题，因为在90%的用例中，你在HDFS上有一个大数据分区存储，通常你会做这样的事情：
- 读取和筛选（例如，只接受失败或成功）
- 聚合、减少、使用
当用简单的M/R或spark完成第一部分时，总是用"更喜欢本地处理"的成语来规划，这样数据就可以由保持数据块的同一节点处理，以更快地避免数据在网络上传输。
在我们用3个节点组成的集群进行的测试中，为了专门测试这一功能和行为，Flink似乎完美地处理了HDFS块，因此，例如，如果文件由3个块组成，Flink可以完美地处理3个输入拆分并并行调度它们。但是没有数据局部性模式。
请分享你的看法，我希望我只是错过了什么，或者它已经有了新版本。提前感谢任何花时间回答这个问题的人。
相反，Flink使用固定数量的数据源任务，即数据源任务的数量取决于运算符的配置并行度，而不是取决于输入拆分的数量。这些数据源任务在集群中的某个节点上启动，并开始从主节点（JobManager）请求输入拆分。在HDFS中文件的输入拆分的情况下，JobManager会为输入拆分指定位置首选项。因此，HDFS中存在位置感知读取。然而，如果并行任务的数量远低于HDFS节点的数量，那么许多拆分将被远程读取，因为源任务保留在启动它们的节点上，并一个接一个地获取一个拆分（首先是本地任务，然后是远程任务）。此外，如果您的拆分非常小，则可能会出现竞争条件，因为第一个数据源任务可能会在其他源任务执行第一个请求之前快速请求并处理所有拆分。
IIRC，本地和远程输入拆分分配的数量会写入JobManager日志文件，也可能显示在web面板中。这可能有助于进一步调试该问题。如果你发现了一个似乎与我上面解释的不匹配的问题，如果你能通过用户邮件列表与Flink社区联系，找出问题所在，那就太好了。