Life is all memory.

Hadoop Streaming 是 Hadoop 提供的一个工具， 用户可以使用它来创建和运行一类特殊的 MapReduce 任务， 这些 MR 任务可以使用任何可执行文件或脚本作为 mapper 和 reducer。

比如，简单的 word count 任务可使用 Hadoop Streaming 简单写为：

Yarn Shared Cache （Yarn 共享缓存服务）是社区 Hadoop 2.9 版本之后上新增的功能，参见YARN-1492，它的目的是提供了一种安全且可扩展的方式向 HDFS 上传和管理应用程序依赖资源，降低 Yarn application 因为依赖资源的上传以及本地化带来的时间消耗。

在日常工作中，我们经常遇到一些用户反馈任务提交特别慢，有些任务从运行启动脚本到任务真正提交到 RM 上，需要十几分钟有的甚至需要一个小时以上。分析这些任务我们很容易就发现，这些任务基本上都是因为依赖的本地资源(files, libjars, archives)文件过多或者输入数据过多(split input巨慢)导致的，因此本篇文章主要就是简单分析一下 MR 任务提交过程，然后总结一下加快提交速度的方法。

在我们的工作过程中，随着业务越来越多，Hadoop 集群规模也越来越大，同时对集群的安全性也越来越高，最原始的 SIMPLE 验证方式已经无法满足需求了，因此，我们决定使用 kerberos, 开启集群的安全验证: Run Hadoop in Secure Mode。

在实践中过程中，我们发现在 Secure Mode 时，NM 必须使用 LinuxContainerExecutor，如果使用 DefaultContainerExecutor 的话，MR 任务会在 reduce shuffle 阶段失败退出，参见YARN-1432。同时，LCE 会使用任务提交用户 JobUser 来运行 Container，如果 NM 上不存在 JobUser，任务就会失败退出。

在日常维护 HDFS 集群以及为用户提供技术支持时，我们经常会遇到各种 HDFS 相关异常问题，对于一些常见的问题，我们可能知道如何去解决，所以处理起来会比较快。但是当遇到一些不常见的问题时，我们可能没办法根据异常信息直接找到解决方法，可能需要查找一些资料，或者深入源码层面查找问题所在，处理起来比较费时费力，很可能对集群的业务造成影响。

Linux CGroup 全称是 Linux Control Group，是 Linux 内核提供的一个用来限制进程资源使用的功能，支持如 CPU, 内存，磁盘 IO 等资源的使用限制。用户可以使用 CGroup 对单个进程或者一组进程进行精细化的资源限制，具体使用方式可以查看参考文档。

目前， Yarn NodeManager 能够使用 CGroup 来限制所有 containers 的资源使用，主要是 CPU 资源。如果不用 CGroup， 在 NM 端很难实现对 container 的 CPU 使用进行限制。默认状态下， container 的 CPU 使用是没有限制的，container 申请了 1 vcore ，实际上能够使用所有的 CPU 资源。所以如果 NM 上分配了一个 vcore 申请较少实际上 CPU 使用极高的任务，常常会导致节点上运行的所有的任务都延时。

在 Yarn 的架构中，将集群中的计算资源，主要是内存和 CPU ，封装抽象出了 Container 的概念， 类似于 container_001 <memory:2048, vCores:1>。 Container 由 ResourceManager 负责调度与分配，由资源所在的 NodeManager 负责启动与管理。

懒了这么久，终于还是下定决心开始写博客了。

博客的内容主要就是总结一下日常工作和学习中遇到的知识点和经验。目前而言，主要包括基于 Hadoop 生态的大数据开发相关的技术。写博客的主要目的是想将自己的技术栈以博客的形式记录沉淀下来，希望通过写博客的方式将接触到知识点梳理的更加清晰，加深自己的理解，找出自身的不足，更好的鞭策自己不断前行，进而达到提升自我的目的。 如果同时能给有想要了解相关知识的朋友们带来一点点帮助，那就更好不过了。