我们和Flink一直在玩。到目前为止，我们一直在Hadoop 2.x / YARN上使用Spark和标准M / R.
除了YARN上的Flink执行模型之外，AFAIK不像spark那样动态，执行者在YARN中动态获取和释放虚拟核心，问题的主要内容如下：
Flink看起来真是太棒了：对于流媒体API ，我只会说它很精彩且超越顶级。
批处理API：处理图非常强大，并且以独特的方式进行优化和并行运行，比Spark和其他人更多地利用集群可扩展性，优化完全非常复杂的DAG，共享通用处理步骤
我发现的唯一缺点是，我希望只是我的误解和缺乏知识，在规划使用HDFS输入的批处理作业时似乎不喜欢数据本地处理。
不幸的是，这不是一个小问题，因为在90％的用例中你在HDFS上有一个大数据分区存储，通常你会做类似的事情：
第一部分，在简单的M / R或spark中完成时，总是按照“首选本地处理”的惯用法进行规划，以便数据由保存数据的同一节点处理-blocks，更快，以避免通过网络传输数据。
在我们使用3个节点的集群进行的测试中，设置为专门测试此功能和行为，Flink似乎完美地处理了HDFS块，例如如果文件由3个块组成，Flink完美地处理3个输入分割并并行调度它们。 但没有数据位置模式。
请分享您的意见，我希望我错过了一些东西，或者它已经在新版本中出现了。 提前感谢任何花时间回答这个问题的人。
答案 0 :(得分：8)
Flink使用与Hadoop和Spark不同的本地输入分割处理方法。 Hadoop为每个输入拆分创建一个Map任务，该任务最好安排到托管拆分所引用数据的节点。
相反，Flink使用固定数量的数据源任务，即数据源任务的数量取决于运算符的配置并行性，而不取决于输入分割的数量。这些数据源任务在集群中的某个节点上启动，并开始从主服务器（JobManager）请求输入拆分。如果HDFS中的文件输入拆分，JobManager会为输入拆分分配位置首选项。因此，HDFS具有局部感知读数。但是，如果并行任务的数量远远低于HDFS节点的数量，则会远程读取许多拆分，因为源任务仍保留在启动它们的节点上，并且一个接一个地拆分（首先是本地任务）远程的）如果您的拆分非常小，也可能发生竞争条件，因为第一个数据源任务可能会在其他源任务执行第一次请求之前快速请求并处理所有拆分。
IIRC，本地和远程输入拆分分配的数量将写入JobManager日志文件，也可能显示在Web仪表板中。这可能有助于进一步调试问题。如果你发现一个似乎与我上面解释的问题不相符的问题，如果你能通过用户邮件列表与Flink社区联系以找出问题所在，那就太棒了。