将Hadoop部署后，可以使用java api进行访问，但是并不能像安装完mysql后用python自带的mysql api连接那么简单。
Hadoop/share目录下有Hadoop所有的jar包，意义在于其所有的行为逻辑都被封装在这里面，例如class，function这些“代码”，使用maven编译hadoop的src的意义就是将*.java编译成jar，类似于c++需要编译一样，不同于py这种边运行边编译的语言。
已经启动的Hadoop服务在尝试进行读取行为逻辑的时候会去jar里面找，这些jar里面有所有的类、函数，虽然有些服务不会用到，例如本该交给client使用的copyFromLocalFile等(也可能会用到。。)，但是反正它就是有了。。
客户端进行import的时候，类似于python import的时候如果import的不是自带的库，就得下载到本地然后import路径，java的maven项目也需要使用pom.xml来定义*.java里面的import的东西的位置。
客户端import的package，并非是一个*.java文件，而是一个jar包，而且不能直接引用，需要使用maven将这个jar包打包到本地仓库，然后给一个uuId(groupId,artifactId,version，他们其实是由package和函数决定的，例如org.apache.hadoop.fs.FsDataOutPutStream，前4位是包名，最后的是这个包的function or class，它们属于Hadoop的commom区域，最后会属于hadoop-common，你会在hadoop-common.jar中找到这个流类的定义 )，客户端import的时候不仅需要写上import的东西，还需要在pom.xml里面写上uuid，这时才能指定maven项目中的引用的jar包的位置。
像org.apache.hbase这种maven自带的库，只需要写上pom.xml，然后更新maven项目，如果它不在你的本地仓库里面，就会将指定的version下载到本地仓库。
可以看出客户端和服务端并非依赖同一个物理意义上的jar包，即它们的版本可能不同，客户可能会尝试调用服务器提供的一个不存在的函数。
可以手动对一个jar包进行打包，也可以使用maven打开一个project，就会自动进行该项目的打包。
所以想更改本地Hadoop的源码，流程应该是：
更改hadoop-src代码 -> maven编译hadoop-src -> 形成新版本的jar包(存在于hadoop/share下) -> cp overwrite hadoop/share目录 (直接更换目前hadoop集群的jar包，不然重新搭建还费时间) -> 对更改过的jar包进行maven打包到本地仓库(使得客户端和服务器端的jar包同步，uuId中的version就是为了区分同一区域的jar包的不同版本) -> 更改客户端代码和pom文件中的version -> maven对客户端代码进行打包 -> hadoop jar 打包后的客户端代码(其实也有直接run的办法)