爬出过的坑

大数据运维过程就是一个踩坑的过程。如下分享一些踩过的坑，以供参考。

Hive

* hive的udf使用全名如select mydatabase.myfun(id) from mytable
* hive.hadoop.supports.splittable.combineinputformat参数为true时在textfile的gzip压缩下可以合并文件。
* hive中export HIVE_OPTS=1G可以控制beeline的内存。 
* filesinkoperator在写bucketfile时，如果相关安装目录权限异常可能无法加载lib*.so文件从而导致写文件时抛出filesystem closed异常
java.lang.unsupporttedopeationException: Currently the writer can only accept ByteArrayWritable 通常是rc表的serde设置问题。可使用lazyBinaryCOlumnSerde或者ColumnarSerde
* 不经过回收站的删除表 drop table mytable purge.
* select count(distinct id) from mytable只有一个reduce，可以考虑改为 select count(*)from select distinct id from mytable
* beeline出现operation cancelled的的原因有： 1） 客户端full gc 2）　服务端ｆｕｌｌｇｃ　3)客户端服务端网络断开  4） 服务端县城执行耗时超过客户端的sockettimeout时间，出发客户端主动关闭
* hivesql处理完后的数据的avgsize小于16M的情况下，会触发mr的merge操作。
* hive的sql对hdfs的操作很重。单个load操作，可能触发20次的操作。对性能影响大
* 在执行beeline时添加--verbose=true参数可打印更多信息
* 执行sql时，hive.metastore.client.socketTimeout出现连接数据库timeout，如果是表分区过多，可以考虑元数据中手动删除表：
    select *from tbls where TBL_NAME="tableToDelete" (取出表的"id")
    delete from partition_key_values where part_id in select part_id from partitions where tbl_id = "id"
    delete from partition_params where partid in select part_id from partitions where tbl_id = "id"
    delete from partition where tbl_id = "id"
* 执行union all的操作可能导致stackoverflow
* 处理数据时cant be cast的异常同城是数据异常导致

Spark

* driver节点需要配置所有hbase进程的hostname和ip对应关系，否则可能出现无法解析节点导致访问异常 creating new stage failed due to exception 
* spark读取parquet表时，每个文件都需要和hdfs交互，先访问到备namenode情况下对性能影响较大
* spark或者hbasetoken的用户需要有hbase:meta表的exec权限
* hivecontext不能重复创建
* spark的beeline则需要通过spark_driver_memory来设置
* 多个字段的group by 易引发oom
* spark写hdfs的应用应保证可重入
* kafka单挑消息过大可能引发classnotfoundexception : kafka.common.failedtosendmessag或者sockettimeoutexception can't find leader offset for set 可考虑调整"socket.request.max.bytes"socket.receive.buffer.bytes, socket.send.buffer.bytes, replica.socket.receive.buffer.bytes
* spark应用打包时，不应包含除应用的包之前的jar包
* Thriftserver的默认handler线程是500
* spark的单个task不能支持2G以上的
* 值为空的配置或者boolean类型（true或者false）时，单词拼错的情况下可能导致driver启动异常
* 执行union all的操作可能导致stackoverflow
* 在eventlog指定的目录写满时(hdfs单个目录的文件数限制在104万)，可能导致spark应用无法提交
* 运行structed Streaming 抛出异常 java.lang.classNotFoundException : kafka.DefaultSource，是由于缺少jar包，spark-sql-kafka-*_*.jar导致serviceloader加载时，找不到kafkasource，从而引发异常 
* Spark应用开发需要导入import org.apache.spark.sql.functions._ 以及import spark.implicits._  否则在编译／运行时可能抛出各种异常（如： value $ is not a member of StringContext  ）
* 开源Spark在hdp的yarn集群中运行原生页面的executor页面无法打开，需要将HADOOP_CONF_DIR/YARN_CONF_DIR下的yarn-site.xml文件中的yarn.timeline-service.enabled参数设置为false，可参考https://www.jianshu.com/p/460f98111d43
* 开源Spark在hdp的yarn集群中运行找不到executorLauncher类， 可参考https://www.jianshu.com/p/de762c244663
* Spark的安全配置(principal和keytab文件)可以通过如下方式传入:
  1) --principal和--keytab的方式传入
  2)在spark-defaults.conf配置文件中配置spark.yarn.principal和spark.yarn.keytab
  3) 在提交命令行时，传入--properties-file指定配置文件，并配置spark.yarn.principal和spark.yarn.keytab
* Structed Streaming基于eventtime的消息，需要该字段是timestamp类型，格式应当是"yyyy-mm-dd HH:mm:ss" 如果设置微微“yyyymmdd HH:mm:ss” 可能导致接收到数据后无法完成后续处理，从而无法得到结果。
* Structed streaming 如果是从kafka消费数据，应用在多个writestream时，每个writestream分别从kafka获取消息
* Structed Streaming 应用在UI页面显示不连续的问题可参考(https://www.jianshu.com/p/43b43c5cd5d9)

Flink

 * flink开发过程中需要导入org.apache.flink.streaming.api.scala._ 否则可能运行时某些转换异常

Yarn

* Yarn通过配置获取集群总资源（cpu/mem／网络／io）信息（与实际无关）
* Yarn集群的资源状态(cpu/mem使用)和主机的cpu/mem消耗无直接关系(Yarn只负责分配资源给应用，不*
  管应用如何使用)
* yarn通过app申请资源，根据用户，以及剩余资源判断是否接受和运行app
*  Yarn根据配置的粒度以及app的申请分配资源
* Yarn只负责分配资源给应用，不管应用如何使用
*  yarn监控container进程的memory来判断container使用资源是否超限
* Yarn调度策略考虑vcore和不考虑vcore的策略
*  score的概念只是用来划分粒度，控制集群能启动的container数目
* Yarn只负责分配资源给应用（container），无法管控container如何使用资源（Yarn管理内存的使用，但无法直接cpu。cpu可通过cgroup控制）

Kafka

* 某些groupid的consumer无法消费数据，而其它groupid的consumer可以消费，可能是Kafka内部的consumer_offset的topic出现异常
* 消费kafka小时时，consumer端一直抛出如下异常“NetworkClient: Bootstrap broker ***:6667 disconnected”异常，此时服务端抛出异常如下：“ERROR Closing socket for *****:6667-******:53026 because of error (kafka.network.Processor)kafka.network.InvalidRequestException: Error getting request for apiKey: 3 and apiVersion: 2”，通常出现改现象端原因是消费端和kafka服务端端版本不匹配 。如客户端使用0.10.1.10服务端时0.10.0.1.
* 安全集群下消费kafka消息 Error while fetching metadata for correlation Id ** [UNKNOWN_TOPIC_OR_PARTITION] 原因可能是使用的用户没有想过topic的读取权限

HDFS

* hdfs datanode节点挂在磁盘数据或者规格不一致的情况下，hdfs的读写性能相差可能很大从而影响某些sql或者其他操作的性能
* HDFS性能可通过查看查看平均wait和processing时间来查看hdfs是否存在性能瓶颈

Zookeeper相关

* zookeeper单独挂盘或者调整-Dzookeeper.snapCount=3000减少zk写入数据时间
* rm启动异常时抛出无法加载某个app文件，需要再zk上删除该app信息
* 组件与zk连接出现异常（经常性断链），可通过增大zksessiontimeout设置来提高服务可靠性

Hbase

* hbase没有指定startkey endkey时，会全表扫描（rpc server kerberos principal name for service ***），性能较差
* rs节点的hostname和ip的一对多关系会引发rs个数的显示和真实的个数不一致
* 在处理hbase表数据时，出现如下异常“hbaserowkey can't be null error while processing *******”，说明有value为空，此时可通过select* from tablename  a where a.rowkey is null or a.rowkey=""
* 通过hive查询相关表时，出现查询失败（权限不足异常），部分region查询成功，可能是部分节点的nscd/sssd服务异常。

Others

* 应用出现读文件挂死，发消息无返回，应用运行忙，各种timeout（connect,socket,read）等，需要考虑排查网络定保，full gc，死锁，cpu异常，cpu节能，磁盘慢的硬件原因
* unknow  compression method等类型的异常通常是文件损坏导致。
* impala和hive使用不同的parquet来，二者的parquet格式的表互相读取可能引发类型转换异常
* hue需要reset操作才能使某些配置生效或者变更生效
* 出现Distributed filesyste can't be cast to filesystem的情况下，一般都是classloader加载异常。
* /usr/lib64下的so文件替换可能引发jvm启动异常
* 存储leveldb数据的磁盘异常，目录权限异常可能导致nm启动异常
* nscd服务服务异常时处理方法：
    nscd -i password 
    nscd -i group
    nscp -i services
    nscd -i hosts 
    service nscd/sssd restart
*  执行shell脚本时，抛出异常, line 73: syntax error: unexpected end of file导致脚本执行异常，在排除文件格式(dos/unix)后，需要排查脚本本身逻辑，如代码段不完备（if 语句缺少结束标志“fi”）等方向排查问题