Cloudera CDH Impala本地通过Parcel安装配置详解及什么是Parcel

本地通过Parcel安装过程与本地通过Package安装过程完全一致，不同的是两者的本地源的配置。

区别如下：

Package本地源：软件包是rpm格式的，数量通常较多，下载的时候比较麻烦。通过"createrepo "的命令创建源，并要放到存放源文件主机的web服务器的根目录下，详见创建本地yum软件源，为本地Package安装Cloudera Manager、Cloudera Hadoop及Impala做准备

Parcel本地源：软件包是以parcel结尾，相当于压缩包格式的，一个系统版本对应一个，下载的时候方便。如centos 6x使用的CDH版本为CDH-430-1cdh430p022-el6parcel，而centos 5x使用的CDH版本为CDH-430-1cdh430p022-el5parcel。

加密是使用数字密钥对各种组件进行编码的过程，因此只有适当的实体才能进行解码，然后查看，修改或添加到数据中。

CDH提供了加密机制来保护持久保存在磁盘或其他存储介质上的数据（以及在网络上移动时的数据）。

保护静止数据通常意味着对存储在磁盘上的数据进行加密，并允许授权用户和进程在手头的应用程序或任务需要时解密数据。对于静态数据加密，必须分发和管理加密密钥，应定期旋转或更改密钥，并且许多其他因素使该过程复杂化。

Cloudera Navigator Key Trustee Server

使用的企业级密钥存储和管理系统，它将加密密钥与数据分离，从而确保即使未经授权的用户访问存储介质，数据也受到保护。它使您的集群能够满足最严格的数据安全规定。此外，Navigator密钥托管服务器可以与硬件安全模块(HSM)集成，为密钥提供最高级别的安全性。

Navigator HSM KMS backed by Thales HSM

Navigator HSM KMS backed by Luna HSM

(上面三个需要认证证书，我不用)

基于文件且受密码保护的 Java KeyStore

使用Java keytool库进行加密

！！！注意：这里特别说明一下

这部分最好使用ip，不要使用hostname，之前使用的是hostname，导致后面有一步认证过不去，注意一下。

输入密码：EXAMPLECOM

进入后输入

添加管理账号

查看账号

进入KDC

添加管理员账号

查看是否添加成功

进入主页 --> 管理 --> 安全

启用 Kerberos

对应修改配置 ---> 继续

开始配置

两个月前写过一篇文章，HDFS和Yarn经常出现dataNode和NameNode之间, nodeManager与resourceManager之间 连接不良的现象，开始怀疑是service Monitor监控内存失败的问题，于是更换了JDK版本，当时认为问题解决，然而没过多久，假死和连接不良现象又出现了。重新将nameNode日志阈值改成debug，发现依然存在如下异常：

但网上查了一些资料，也有人说这是CDH版HDFS的一个bug。本身并不影响服务。考虑到CDH本身也将该异常认定为debug级别，觉得是有可能的。个人感觉这个问题除了让日志增长比较快，也就这样了。决定先把这个问题放一放。

由于疫情和工作原因，一直没功夫去看这个问题，一气之下把主节点升到16G内存，惊喜发现部署在主节点的DataNode和nodeManager几乎一直是良好状态，而从节点经常出现问题。

比如这个很可怜，除了主节点之外的nodeManager其余都挂了。

所以现在解决问题的思路无非是

1 升级从节点的资源配置，和主节点配置保持一致。

2 通过系统优化和调优解决问题。

本着对技术的探(mei)究(qian)之心，我决定采用第二条方案。

先把服务器上的HDFS nameNode/yarn nodeManager堆栈日志dump下来(因为这两个组件内存占用较大)，看看究竟。发现其中70%的都是不可达对象（也就是图中的灰色部分）。

于是到服务器上去一探究竟。

通过jmap 命令，发现两个现象：

1 新生代内存比较小，并且频繁进行minor gc，几乎每分钟都有。

2 老年代内存一直在增长并且没有释放的迹象。

感觉新生代内存过小可能会导致：

1  频繁的minor gc，很多新生对象没有经过充分gc而进入老年代。（比如新生对象存活时间是五分钟，而频繁的minor gc导致3分钟这个对象就被当成老人放入老年代）

2  频繁的minor gc，可能导致对cpu资源的争夺或其它未知的原因导致nodeManager或者dataNode不良。

而老年代内存回收过慢则导致系统内存一直处于高位。

于是尝试设置两个参数：

-XX:NewRatio=2 -XX:CMSInitiatingOccupancyFraction=45

第一个XX:NewRatio是指扩大新生代内存的比例，降低minor gc的频率，而第二个则是降低触发老年代full gc内存回收的阈值，使得老年代不至于保存大量已不可达的对象。如果但这个值如果设太低，则又会频繁触发full gc和major gc，所以也不敢设置太低，设成45。

通过设置，HDFS的dataNode连接不良的问题得以解决，但yarn的nodeManager还是频繁出现不良。

继续百度+谷歌，发现JDK18有更好的垃圾收集器，G1回收器，感兴趣的同学请移步：

深入理解JVM（5）——GC垃圾回收（3）——8大垃圾收集器

G1回收器比之前用的新生代并行垃圾收集器无论是吞吐量优先(让单位时间内，STW 的时间最短)还是对响应时间优先(尽可能让单次 STW 的时间最短)的处理都比并行垃圾处理器(useParNewGC）优雅不少。

我们可以通过以下参数设置，其中XX:MaxGCPauseMillis为单次最大gc停顿时间。这是一个软目标，G1会尽量保证单次停顿低于该值。

-XX:+UseG1GC -XX:MaxGCPauseMillis=200

设置完之后，集群稳定的一批。跑了一些任务，也没有问题。收工。

最后又是安利追剧时间，今天安利的是精英律师，老干部嘴皮子简直6得不行了，栗娜真的超好看。

在采用Cloudera-Manager安装cdh时，通常使用内嵌的PostgreSQL数据库。

Cloudera-Manager除了保存CDH集群的配置元数据的scm数据库外，还为Activity Monitor（活动监控）、Service Monitor（服务监控）、Report Manager（报告管理）、Host Monitor（主机监控）、Cloudera Navigator（Cloudera导航）等信息分别创建数据amon、smon、rmon、hmon、nav相应的数据。

这是一个很容易出现的问题，网上很多内容将mysql驱动包上传到不对的路径导致出现问题。

cloudera manager添加hive时报错找不到jdbc driver

报错

JDBC driver cannot be found Unable to find the JDBC database jar on host

把包放入这个目录，注意文件名要保持一致 网上又很多需要把这个驱动包放到

cp /root/mysql-connector-java-5133-binjar /opt/cloudera/parcels/CDH-540-1cdh540p027/lib/hive/lib/

/opt/cloudera/parcels/CDH/lib/hive/lib或者

/opt/cloudera/parcels/CDH-540-1cdh540p027/lib/hive/lib

以上其实是同一个位置

*** 作后问题依旧出现。

解决方法：

后来在网上找到需要将这个包放到这个路径下就通过了（名字需要修改下）

/usr/share/java/mysql-connector-javajar

我从cloudera官网看到都说是hsqldbjar的问题 我移除了这个jar包 仍然重启失败 然后我又把jar放回来 从Stderr中查到日志，bind 8005 address already in use 因为我的tomcat端口有8005 然后我把tomcat改了 sqoop2正常启动了 但是我不知道sqoop2哪里用到了8005

以上就是关于Cloudera CDH Impala本地通过Parcel安装配置详解及什么是Parcel全部的内容，包括:Cloudera CDH Impala本地通过Parcel安装配置详解及什么是Parcel、CDH设置HDFS静态数据加密、CDH集群假死问题排查之后续等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！