[hadoop@master hadoop]$ hdfs dfs -put *.txt input
16/11/03 09:58:32 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
[hadoop@master hadoop]$ hdfs dfs -ls input
16/11/03 09:58:44 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Found 3 items
-rw-r--r-- 1 hadoop supergroup
84854 2016-11-03 09:58 input/LICENSE.txt
-rw-r--r-- 1 hadoop supergroup
14978 2016-11-03 09:58 input/NOTICE.txt
-rw-r--r-- 1 hadoop supergroup
1366 2016-11-03 09:58 input/README.txt
[hadoop@master hadoop]$ hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar grep input output 'SOFT[A-Z]+'
[hadoop@master hadoop]$ hdfs dfs -ls output
16/11/03 09:59:47 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Found 2 items
-rw-r--r-- 1 hadoop supergroup
0 2016-11-03 09:59 output/_SUCCESS
-rw-r--r-- 1 hadoop supergroup
12 2016-11-03 09:59 output/part-r-00000
[hadoop@master hadoop]$ ls output
ls: cannot access output: No such file or directory
[hadoop@master hadoop]$ hdfs dfs -cat output/part-r-00000
16/11/03 10:00:23 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
49
SOFTWARE
[hadoop@master hadoop]$ hdfs dfs -get output ./output # 将文件夹取回到本地文件系统 16/11/03 10:03:18 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
[hadoop@master hadoop]$ ls output/ part-r-00000 _SUCCESS [hadoop@master hadoop]$ cat output/part-r-00000 49 SOFTWARE [hadoop@master hadoop]$
注意运行 Hadoop 程序时，程序指定的输出目录（如 output）不能存在，否则会提示错误，因此运行前需要先删除输出目录
四、启动YARN
hadoop2使用了新的MapReduce框架（MapReduce V2，也称为 YARN，Yet Another Resource Negotiator），YARN是从MapReduce中分离出来的，负责资源管理与任务调度。YARN 运行于 MapReduce 之上，提供了高可用性、高扩展性。为什么要升级到YARN，可以参考这篇文章《Hadoop 新 MapReduce 框架 Yarn 详解》。这里只引用文章的一点内容，有兴趣的读者可直接打开文章查看更多内容：
原框架的问题逐渐浮出水面，主要的问题集中如下：
1、JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
2、JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
3、在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
4、在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
5、源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行，，造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
6、从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。