大数据篇：这些年大数据组件的一些踩坑和优化总结

这些年除了做算法,大数据也搞得水生火热,下面是这些年的一些踩到的坑和一些经验的总结.

写入hbase提示closing socket问题

Session 0x0 for server ip-10-0-10-55.ec2.internal/10.0.10.55:2181, unexpected error, closing socket connection and attempting reconnect

问题：spark stream 往 hbase 写数据时会出现的问题，提示 zookeeper socket 连接不了。
原因：CDH中zookeeper为防止集群遭受DDos攻击，默认将 Maximum Client Connections 设置成了60，当超过这个次数时，后面的连接将会一直失败
解决：将改参数 Maximum Client Connections 修改成 0，即不做任何限制。
注意：修改成0后如何防止攻击需要做额外的一些工作。

debug spark-1.6.0 内存泄漏错误

spark-1.6.0 内存泄漏问题是spark的一个遗留问题，建议迁到spark-2.1.0.

spark 任务无法序列化问题

1. 所有的class都必须继承自 java.io.Serializable 
2. broadcast 操作若包含自定义类，则该操作最好定义在函数的外面，类的最外层，当成类的属性。

spark sortby失败问题

在spark里对dataframe或RDD进行sortby时，确保每条记录不占用太多内存，若每条记录包含长字符串或者长数组，
先分离出去再做sortby, 否则shuffle的时候或十分缓慢同时容易造成内存溢出。

kafka 跨网段无法消费问题

通常我们的内网IP都是192.168.1.X， 但是如果我们的Kafka服务和Kafka消费者是分布在不同网段，那怎么办？
比如：
Kafka集群在192.168.2.X
Kafka消费者在192.168.1.X

解决方案是修改kafka消费者的host, 让192.168.2.X 和 192.168.1.X 互通。

spark 数据库连接池序列化问题

如果在RDD外面，即driver节点上初始化连接，比如数据库连接，或者ActorSystem，那么再将其放到RDD里面时便会报错，
这种东西无法序列化是Spark弥留很久的问题。

解决方案是先对RDD做foreachPartition,在每个partition里初始化连接，再做进一步操作，而不是在每个RDD里初始化连接，
前者会极大减少初始化次数，提高代码的效率。

spark 大表关联大表计算问题

任何时候都要避免大表关联大表的计算，尽量将大表拆小，如果实在没法避免，有如下方法可供参考：

假设大表A关联大表B计算距离矩阵，

  - 1.大表A先切分为若干块，可通过设置相应字段进行过滤；
  - 2.将表B`collect`回来，再将其`broadcast`出去，对表A切分结果的小表与表B做关联计算。

kudu tablet server关停

CDH上kudu时常会有一些tablet server出现异常，当关掉该tablet server后，若要该tablet server重新正常工作，需要将
原来改tablet server的kudu data目录下的tablet data和wal删掉。

详见：
https://kudu.apache.org/docs/index.html
http://cwiki.apachecn.org/display/Kudu/Index

kudu ntp时间不同步问题

kudu在掉了一段时间或者服务器挂了一段时间后会出现：
Check failed: _s.ok() Bad status: Service unavailable: Cannot initialize clock: Error reading clock. Clock considered unsynchronized Full log file

解决方案具体操作为：
centos/rehat系统的：
sudo yum install ntp
sudo /etc/init.d/ntpd restart

ubuntu系统的：
sudo apt-get install ntp
sudo service ntp restart

查看状态：
ntptime

若是：
ntp_gettime() returns code 0 (OK)
  time de24c0cf.8d5da274  Tue, Feb  6 2018 16:03:27.552, (.552210980),
  maximum error 224455 us, estimated error 383 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 1279.543 us, frequency 2.500 ppm, interval 1 s,
  maximum error 224455 us, estimated error 383 us,
  status 0x2001 (PLL,NANO),
  time constant 10, precision 0.001 us, tolerance 500 ppm,
  
则重启KUDU table sever即可。

kudu 修改master

1. 修改kudu master信息,最后对应的为kudu新master uuid:新IP:端口, 端口一般为7051:
sudo -u kudu kudu local_replica cmeta rewrite_raft_config --fs_wal_dir=/data/kudu/master --fs_data_dirs=/data/kudu/master 00000000000000000000000000000000 610e3791d4044637a3e3484abee7796c:10.2.113.104:7051

2. CM上修改kudu configuation, 设置 master.address 为 新IP:端口

3. 在master节点上命令行进入mysql, 账号相关信息一般在 /etc/cloudera-scm-server/db.properties ,进入hive database:
UPDATE TABLE_PARAMS SET PARAM_VALUE ='10.2.113.104:7051'
WHERE PARAM_KEY = 'kudu.master_addresses'
AND PARAM_VALUE = '192.168.1.23:7051';

上述为将旧IP修改为新IP.

4. imppala更新：
INVALIDATE METADATA;

参考:
https://www.cloudera.com/documentation/enterprise/5-13-x/topics/kudu_administration_cli.html#migratingToMultipleKuduMasters.d12e306

集群swap memory(交换内存)使用过多导致服务变慢甚至挂掉问题

sysctl -w vm.swappiness=1

参考：
https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_admin_performance.html#cdh_performance__section_xpq_sdf_jq

集群yarn org.apache.hadoop.yarn.server.nodemanager.LocalDirsHandlerService: Most of the disks failed.

问题为nodemanager磁盘服务空间达到设定的最大的限度(默认90%)

解决办法：
1. 删掉或者迁移hdfs上的数据部分到别的地方
2. 修改 max-disk-utilization-per-disk-percentage 参数, 调高其比例.