Bigdata-CDH-Hadoop生态系统中的RPC性能瓶颈

RPC 是远程过程调用 (Remote Procedure Call)，即远程调用其他虚拟机中运行的 java object。
而HDFS的运行建立在RPC上，NameNode的RPC queue time指标可以显示表达这个系统当前状态。

在大规模的集群中，RPC变慢的根源在于HDFS的NameNode吞吐量和性能瓶颈。
Datanode会汇报block变化的元数据给NameNode，在一个繁忙的集群中，datanode上随时都会有写完的数据块然后汇报给namenode的情况，集群每次写请求都会产生排它锁，会强制其他任何操作必须在队列里等待完成。BlockReport类型RPC请求是串行处理，因此会非常影响其他rpc的处理和响应时间。

在一个RPC缓慢的系统中，hive等组件响应缓慢可能存在一下错误：
Unable to close file because the last block does not have enough number of replicas.

下面从以下几个方面优化此类问题：

一、数据块汇报间隔时间

增量数据上报间隔，Datanode会定期将当前该结点上所有的BLOCK信息报告给Namenode，参数dfs.blockreport.incremental.intervalMsec就是控制这个报告间隔的参数。单位毫秒，默认为0。

<property>

 <name>dfs.blockreport.incremental.intervalMsec</name>

   <value>200</value>

</property>

二、Namenode优化

HDFS文件系统的所有元数据相关操作基本上均在NameNode端完成，当数据规模的增加致内存占用变大后，元数据的增删改查性能会出现下降，且这种下降趋势会因规模效应及复杂的处理逻辑被放大，相对复杂的RPC请求（如addblock）性能下降更加明显。Full GC的风险不可控制，正常情况下，对超过100GB内存进行回收处理时，可以控制到秒级别的停顿时间，但是如果回收失败被降级到串行内存回收时，应用会卡顿上百秒，在实际生产中这对应用本身是致命的。
Namenode的优化一般从以下几个方面考虑：
1、Namenode硬件升级；
2、采取Namenode Federation模式，横向扩展Namenode，使每个Namenode管理不同的目录树结构，负载均衡，分流，也能起到隔离业务的作用，但是相应的运维成本也在增加。
3、JVM调整，其参数调整视应用环境、集群环境、业务背景的不同而不同，没有统一的适用标准，应针对不同系统测试和调整来得到最合适的参数。
4、增大block size。即：避免热点块，减少namenode压力，减少元数据的大小和tcp的连接数。
5、RPC线程数，根据内存适当调整。

三、RPC客户端优化

即对发出rpc请求的模块进行优化，从源端加以控制来减轻Namenode压力。
对于Hbase、Hive等可以从以下方面考虑：
1、减轻数据倾斜（数据模型和sql方面）；
造成数据倾斜的一般原因：
1)、key分布不均匀
2)、数据本身特性导致
3)、建表时考虑不周
4)、SQL语句造成的数据倾斜
2、组件优化，及对Hbase及Hive等的参数进行调整