标签：split pow eve 拉取 计算 解决 本地化 级别 mapper
原文链接：
https://data-flair.training/blogs/data-locality-in-hadoop-mapreduce/
数据本地化（Data locality）是指将计算移动到数据所在的节点，而不是移动数据移动到计算所在的节点。在Hadoop中，一份数据会被切割成多个块，这些块分布在集群的多个节点。如果计算逻辑固定在某个节点，那么计算过程中会跨节点拉取大量的数据，造成网络拥塞，系统吞吐量不高等问题。
我们的系统架构需要满足以下条件，才能充分利用数据本地化的好处。
首先集群需要有一个正确的拓扑结构。Hadoop代码必须有能力读到本地（code所在节点）的数据。
其次，hadoop必须知晓运行MR任务的节点的拓扑逻辑。然后Hadoop必须要知道数据存在哪里（物理位置）。
当数据和mapper处于同一个节点时，称为本地级别的数据本地化。这种情况下，数据和计算是非常接近的的，这也是最好的场景。
我们如果要求Mapper总是和数据处于同一个节点，因为资源限制的原因，这其实是不可能的，也即是说数据搬移是不可避免的。在需要数据搬移的场景中，最好的情况是数据和计算处于同一个机架。
因为资源的限制，系统会面临着跨机架搬移数据，这是3种情况种最差的一种。
尽管本地化级别的数据本地化让mapper可能运行在它需要的数据所在的节点上。但是实际情况里并不是总能如此，一些原因，比如speculative execution，异构集群，数据的分布、布局以及Input Splitter都会让一些mapper任务不能运行在数据所在的节点上。
在大的集群里数据本地化挑战变得更加常见，因为大的集群里数据节点很多，数据也很多。数据本地化的会被弱化。
在大的集群里，一些节点是新节点然后它们会比其他节点要快，这让数据计算比率变得失衡，以此，大的集群倾向于并非由同构节点组成。In speculative execution even though the data might not be local, but it uses the computing power. The root cause also lies in the data layout/placement and the used Input Splitter. 处理非本地数据会面临网络资源的约束然后引发可扩展性的问题。
我们可以通过检测哪些job有数据本地化问题或者随时间降级来提高数据本地化。解决方案是更加复杂包括改变数据的物理位置已经数据的布局，为一个job使用一个别的scheduler或者简单地修改mapper和reducer slot。然后我们必须要检验数据计算比率是否有得到提升。
标签：split pow eve 拉取 计算 解决 本地化 级别 mapper
原文地址：https://www.cnblogs.com/ralgo/p/14894769.html
