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