image.png
整体 写 mapreduce 有时候也会陷入 一种思维定势，以为 hadoop 只能做mapreduce，其实当然很可笑，hadoop 还是可以做很多的，hadoop 的一些shell 命令 都提供了 java api 通过编程实现 对hdfs文件系统的操作。而且 写成的文件 打成jar包，可以像类似 mapreduce 程序jar 一样被hadoop 命令执行。
例如
hadoop jar hdfs-compress.jar com.company.center.compress /input /output
集群90T 但是 眼瞅着就要 用完了，头头 拒绝 扩容，还不允许 删除 数据，就好像 你家的房子不允许扩建，但是你家东西越来越多，眼看就快撑不下了，还不能扔家具，只能不断的压缩所有能压缩的东西 腾出地方来。
百度的老大 给了一个他用shell 写的压缩脚本 ，其实还是使用hadoop streaming 跑
mapreduce ，通过 设置输出文件为压缩，其他的什么都没有做，这种做法只限于在同一目录下为 同一类型的文件，而且 文件命名没有要求的文件，因为要这样通过mapreduce跑，如果一个目录下有多种不同文件，而且文件命名是有特殊用意和格式，那么MR则会把同一目录下的各种文件混在一起，有点类似搅拌在一起了，而且输入文件为 part-n类型，完全打乱了 文件原来的命名，所以 在老大 得意的给我演示了 他发明的脚本 是多么优异，还是被我无情的丢弃掉了。
在花了接近 三天的调研和测试，终于 跑通了 hdfs 在线压缩文件的操作，说实话不算太难，主要就是 转变思维 就是我使用 hadoop jar 照耀可以跑 非mapReduce程序来操作hdfs，甚至 可以跑普通的 java 程序 ，其实 hadoop jar 是java jar 命令行形式的hadoop 定制版。
文件有咩有 压缩成功 我们是 如何检验 的呢，当然两点 文件确实小了很多 ，我们使用gzip，压损率为4.2---10倍以上，不同文件的压缩率是不一样的。二 压缩后的文件也要保证了数据完整和可读性，通过 wc -l 比对行数，可 抽查部分末尾十行的数据来确认 文件的完整性，gzip格式需要通过 hadoop fs -text 来读取，使用hadoop fs -cat 则会乱码。
代码我是使用scala 来写的，我在使用scala 跑mapReduce时，服务器和提交任务的机器都没有安装scala 编译环境，完全是可以的，可能是 代码里 咩有什么太深的内容，但是 仅仅操作hdfs 的就不行了，不得不在提交任务的机器上【并没有在NameNode上操作】安装scala 编译环境 sdk，才解决了【Exception in thread “main” java.lang.NoSuchMethodError: scala.Predef$.refArrayOps([Lja 】
还有一个就是打包时 如果指定了主类 MAINCLASS,那么在使用hadoop jar的时候就不用指明主类 ，直接 hadoop jar jar包名 hdfs输入路径 hdfs 输出路径。
如果打包时没有指定主类，那么需要在 执行命令时指定主类
hadoop jar jar包名 含package路径.主类名 hdfs输入路径 hdfs 输出路径，
我们可以通过 命令的错误输出来确认 到底选择哪一种方式
这里可以给大家看一些压缩的效果图
image.png
image.png
image.png
大家git clone 下来后 运行中会报一个空指针异常，这个主要是 写入文件的key其实是null，为了不污染源文件 不得不这样
image.png
