一、背景
由于公司的老集群对于现有的开发工作者来说并不是特别的友好,数据模型也不是特别适用。所以为了让使用者更友好、数据更可靠,建立新集群、构建数仓,新集群搭建到使用,基于spark引擎自己构建ETL框架,在大量数据下,期间难免会遇到各种各样的问题。于是找几个踩过的比较经典的坑来说一下。
二、采坑过程
个人感觉单纯开发SparkStreaming的过程不叫经验,所以直接略过,来到测试环节,SparkApp进行开发测试,遇到了第一个头疼个人也感觉比较经典的问题就是消费kafka偏移量越界问题
1、OffsetOutofRangeException
越界原因以及避免思路在我前面几篇博客都有些,可以了解一下(代码并不是最优,可以自己理解思路,找出解决方案)
https://blog.csdn.net/qq_41922058/article/details/86545270
2、基本这个时候已经是到年末了,所以将所有job全部启动,回来看测试结果,由于是开发集群,结果等全部任务启动时,发现资源已经不够。有的容器已经处于待定状态此时可以查看集群确定是否yarn配置导致资源不足,还是集群本身资源已经不足,如果由于配置原因可以适量调大yarn.nodemanager.resource.memory-mb参数
3、放假回来之后发现任务已经过了大半,查看原因发现磁盘已经被写满,nodemanager由于空间原因被认为不可使用,不去进行任务调度。
解决方案:进行磁盘扩容
https://blog.csdn.net/qq_41922058/article/details/87984205
4、集群扩容之后继续启动任务,任务随机出现如下错误
java.io.IOException: No space left on device
可以看出来明显的还是磁盘空间不足
问题原因:由于是扩容磁盘导致单节点内数据不均匀
解决方案(官网):
http://hadoop.apache.org/docs/current3/hadoop-project-dist/hadoop-hdfs/HDFSDiskbalancer.html
5、还有一个比较有意思的问题(并不是错误)
我在spark ui界面观看任务执行过程时,会出现有的executor dead现象,观看executor日志报如下错误ERROR executor.CoarseGrainedExecutorBackend: RECEIVED SIGNAL TERM,通过查询发现:此问题为spark1.5之后的executor的动态管理机制spark.dynamicAllocation.executorIdleTimeout可以修改此参数,达到固定执行器,但此机制提高了集群资源的利用率,所以可以不作处理;也可以直接关闭spark.dynamicAllocation.enabled
6、此外还可能会出现hdfs小文件问题(按照业务要求是否合并)
思路:可以定时启动mapreduce进行小文件合并,具体实现方案自行查询
欢迎扫码进群,期待更优秀的你!