Spark实战经验

一、背景

由于公司的老集群对于现有的开发工作者来说并不是特别的友好，数据模型也不是特别适用。所以为了让使用者更友好、数据更可靠，建立新集群、构建数仓，新集群搭建到使用，基于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进行小文件合并，具体实现方案自行查询

欢迎扫码进群，期待更优秀的你！