1、 問題：拒絕連接
解決方法：hiveserver2 連接異常，重啟（hiveserver2連接比較慢要等一會）
我這里兩個RunJar是啟動了meatestore和hiveserver2
2、 user:duoduo is not allowed impersonate hadoop100
這個duoduo,是我的登錄的用戶，hive的用戶和所屬組都是duoduo
解決方法：
在hadoop的配置文件core-site.xml增加如下配置，重啟hdfs
<property>
<name>hadoop.proxyuser.duoduo.hosts</name>
<value>*</value>
</property>
<property>
<name>hadoop.proxyuser.duoduo.groups</name>
<value>*</value>
</property>
完美解決：
其中username和password都為duoduo
不管是root，還是duoduo用戶都可以登錄，可以肯定與用戶無關
注意：
將配置換成Hadoop100或者hive
<property>
<name>hadoop.proxyuser.hive.hosts</name>
<value>*</value>
</property>
<property>
<name>hadoop.proxyuser.hive.groups</name>
<value>*</value>
</property>
無論換成什么都是duoduo用戶不不能模擬hadoop100
2.1 驗證某些博客1是hive-site.xml里面的不對：
驗證：我的hive-site.xml
這個用戶名和密碼是元數據mysql的用戶名和密碼
2.2 驗證某些博客2是主機名的不對：
驗證：我的主機名是Hadoop100
2.3 驗證要帶上庫名字不然會報錯的
驗證：毛關系沒有
3、代理用戶
在hadoop的core-site.xml中進行如下設置, 用戶“super”就可以代理主機host1和host2上屬於組group1和group2的所有用戶。
<property>
<name>hadoop.proxyuser.super.hosts</name>
<value>host1,host2</value>
</property>
<property>
<name>hadoop.proxyuser.super.groups</name>
<value>group1,group2</value>
</property>當然，也可以進行更松弛的設置。如下所示表示用戶“oozie”可以代理所有主機上的所有用戶
<property>
<name>hadoop.proxyuser.oozie.hosts</name>
<value>*</value>
</property>
<property>
<name>hadoop.proxyuser.oozie.groups</name>
<value>*</value>
</property>3.1 ProxyUser介紹和應用場景
Hadoop2.0版本開始支持ProxyUser的機制。含義是使用User A的用戶認證信息，以User B的名義去訪問hadoop集群。對於服務端來說就認為此時是User B在訪問集群，相應對訪問請求的鑒權（包括HDFS文件系統的權限，YARN提交任務隊列的權限）都以用戶User B來進行。User A被認為是superuser（這里super user並不等同於hdfs中的超級用戶，只是擁有代理某些用戶的權限，對於hdfs來說本身也是普通用戶），User B被認為是proxyuser。
在Hadoop的用戶認證機制中，如果使用的是Simple認證機制，實際上ProxyUser的使用意義並不大，因為客戶端本身就可以使用任意用 戶對服務端進行訪問，服務端並不會做認證。而在使用了安全認證機制（例如Kerberos）的情況下，ProxyUser認證機制就很有作用：
- 用戶的管理會比較繁瑣，每增加一個新的用戶，都需要維護相應的認證信息（kerberosKeyTab），使用ProxyUser的話，只需要維護少量superuser的認證信息，而新增用戶只需要添加proxyuser即可，proxyuser本身不需要認證信息。
- 通常的安全認證方式，適合場景是不同用戶在不同的客戶端上提交對集群的訪問；而實際應用中，通常有第三方用戶平台或系統會統一用戶對集群的訪問，並 且執行一系列任務調度邏輯，例如Oozie、華為的BDI系統等。此時訪問集群提交任務的實際只有一個客戶端。使用ProxyUser機制，則可以在這一 個客戶端上，實現多個用戶對集群的訪問。
使用ProxyUser訪問hadoop集群，訪問請求的UGI對象中實際包含了以下信息：
- proxyUser用戶名
- superUser用戶名
- superUser的認證信息（kerberos等安全認證模式下） 而非ProxyUser方式訪問，UGI中只包含了普通用戶及其認證信息。 通過ProxyUser方式訪問hadoop集群，認證鑒權流程如下：
- 對SuperUser進行認證，在Simple認證模式下直接通過認證，在Kerberos認證模式下，會驗證ticket的合法性。
- 代理權限認證，即認證SuperUser是否有權限代理proxyUser。這里權限認證的邏輯的實現可以通過 hadoop.security.impersonation.provider.class參數指定。在默認實現中通過一系列參數可以指定每個 SuperUser允許代理用戶的范圍。
- 訪問請求鑒權，即驗證proxyUser是否有權限對集群（hdfs文件系統訪問或者yarn提交任務到資源隊列）的訪問。這里的鑒權只是針對 proxyUser用戶而已經與SuperUser用戶無關，及時superUser用戶有權限訪問某個目錄，而proxyUser無權限訪問，此時鑒權 也會返回失敗。
3.2 ProxyUser的使用和相關配置
ProxyUser對象通過UserGroupInformation.createProxy(“proxyUser”,superUgi)來創建，訪問集群時通過proxyUser.doAs方式進行調用。
// 創建superUser用戶
UserGroupInformation superUser = UserGroupInformation.getCurrentUser();
//創建proxyUser用戶
UserGroupInformation proxyUgi = UserGroupInformation.createProxyUser(“proxyUser”, superUser);
// 使用proxyUser用戶訪問集群
proxyUgi.doAs(new PrivilegedExceptionAction<Void>() {
@Override
public Void run() throws Exception {
// 使用proxy用戶訪問hdfs
FileSystem fs = FileSystem.get(conf);
fs.mkdirs(new Path(“/proxyUserDir”));
// 使用proxy用戶提交mr作業
JobClient jc = new JobClient(conf);
jc.submitJob(conf);
return null;
}
});
服務端需要在NameNode和ResourceManager的core-site.xml中進行代理權限相關配置。 對於每一個superUser用戶，配置參數：
對於每個superUser用戶，hosts必須進行配置，而groups和users至少需要配置一個。
這幾個配置項的值都可以使用*來表示允許所有的主機/用戶組/用戶。
例如：
<property>
<name>hadoop.proxyuser.userA.hosts</name>
<value>*</value>
</property>
<property>
<name>hadoop.proxyuser.userA.users</name>
<value>user1,user2</value>
</property>表示允許用戶userA，在任意主機節點，代理用戶user1和user2
代理用戶權限相關配置的改動，需要修改core-site.xml文件中相關配置。修改后配置並不會自動更新到服務器（這與fair- scheduler.xml配置會自動更新不同）。修改配置后需要執行以下命令進行同步，分別將信息更新到namenode和 resourcemananger上。
參考1：https://www.jianshu.com/p/a27bc8651533
參考2：https://blog.csdn.net/u012948976/article/details/49904675
官網：https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/Superusers.html