18年项目总结
- 如果在运行spark的时候,有时候环境的问题需要引入其他的jar包,那么我们可以使用--driver-class-path $HBASE_HOME/lib/*:classpath也可以以在脚本前面执行export ****生成当前需要的环境
- 当前我们集群使用的版本 jdk1.8 spark2.11 hive2.1.1 hbase1.3.0 hadoop2.7.3 zookeeper3.4.10
- spark提交任务的时候,需要根据当前的资源来调试core和memory ,如果出现org.apache.spark.shuffle.FetchFailedException:Failed to connect to 异常,由于execute的可用资源太少,shuffle执行时间变长,内存使用过多导致无响应心跳,超过默认的超时时间Executor被移出后,任务丢失。当spark的DAGSchedule尝试提交失败的task到其他的Executor,但是由于其他的Executor也是相同的配置资源,所以最终的任务还是会失败。那么需要我们调整如下配置减少shuffle的操作来减少使用内存、增大spark.network.timeout的时间、增加spark.executor.cores,从而减少创建的Executor的数量,减少内存使用、增大spark.executor.memory保证每个Executor有足够的内存
- 如果数据量不是很大的话,没必要设置分区太大,不然的话每个分区上的数据都很小,某一个分区上的数据发生倾斜时候,其他的分区就会关闭,导致连接失败,然后某个分区的数据就会发生OOM,这时候一、减少运行cores;二、增加每个core的memory,三、减少partition。
- 遇到spark任务报错,Container killed by YARN for exceeding memory limits. 16.9 GB of 16 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead,首先要做的是增加'spark.yarn.executor.memoryOverhead',到4096,但还是报错。要考虑的第二件事是,您的数据是否在分区之间保持平衡,三、尝试减少cores在内存中保留较少的任务,增加memory,但是还是会报错,查看了磁盘的适合用情况是没有问题的,代码也是都没有问题的,然后看数据量也不是很大,四、考虑分区:通常如果分区太多,输出文件很小,这是正常的,但问题出现在元数据HDFS中必须保持住,这会给HDFS带来压力并降低其性能。因此,找到分区数量的最佳位置非常重要,最后查看因为这批任务的数据小,竟然给了3000分区,减少到500 (也可以直接删除默认200)问题解决,详细可以看CSDN
19年项目总结
- 需要时常查看集群的状态,特别是自热人订单大表落地的时候,在新数据跟新的时候,应该删除原来的数据,不然会导致部分数据偏移的话, 某个磁盘满了不健康,要是数据没有落完就会被kill掉。所以落地前需要保证所有几点的磁盘空间可用
- 在执行MR作业的时候,需要查看当前的集群状态是否健康,各个节点存储状态。程序莫名被kill掉,然后重启:TaskAttempt killed because it ran on unusable node ip 10-0-1-17.cn-northwest ...Container released on a *lost* node 这个时候,是由于集群的数据存储偏移,导致某个节点存储超过90%不健康,就会被kill掉,这个时候,MR还是会重新运行,将数据存储到健康的节点上,所以需要手动平衡节点的存储。
- 我们是使用的是Hbase数据的批量生成hfile,要是全量数据的话,一个表的数据4.5T左右,然后再集群的数据落地的时候,就会发生平衡速度小于数据的落地速度,导致某个服务器的磁盘占满,然后任务重启。默认的hbase集群的平衡机制是1M,我们手动执行hdfs dfsadmin -setBalancerBandwidth 52428800 ,将默认的平衡带宽设置到50M,集群数据可以实现自动平衡。但是非常重要的一个问题,就是它会影响服务器的服务,所以,要是在线上用的话,一定记得不要太大,以前100M导致线上服务无法提供。
- 提交到yarn上的任务,当某个磁盘被占满时候,当前节点就会不健康,然后这个job就被kill掉重启,所以大任务一定要保证当前的磁盘空间充足。(在浏览器上的查看的50070端口,页面的服务器状态或者磁盘存储可能不准,需要去对应的服务器下查看)
- 我们提交的job的数据量大或者计算任务复杂的时候,可能会出现异常,sparkException:Task failed while writing rows, Caused by :suffle.FetchFailedException:Connection from *** closed,可以通过调整分区数和数据源减少shuffle来处理,当分区小的时候,每个task处理的数据量就非常大,导致JVM crash,从而导致shuffle失败,丢失,连接不了的情况 :解决:1.减少shuffle的数量,使用map side join 或者broadcast join 来减少shuffle;2.提高默认的spark.sql.default.parallelism分区数量;3.通过spark.default.parallelism控制shuffle read 与redeuce处理的分区数,建议是cored 2-3倍;4.提供executor的内存;5.查看是否是数据倾斜,空值过滤,异常值(某个key单处处理)。***我们是因为集群从每个节点10T切换到2T导致数据无法落地,部分任务执行过慢:调整磁盘空间大小解决这个问题。
- 在执行job的时候,如果存在多个join操作后,然后没有生成表直接union的时候,会发生OOM,如果数据量大,执行语句复杂也会OOM,需要落地表后在执行就OK.
- 在执行MR操作生成Hfiles的时候,主要时间是用来执行reduce,这个时候,虽然集群式FIFO,但是,要是启动某个spar shell或者job没有限制资源的时候,它就会占用剩余的资源,这样就导致MR失败,某个节点失联。
- 1.需要时常查看集群的状态,特别是自热人订单大表落地的时候,在新数据跟新的时候,应该删除原来的数据,不然会导致部分数据偏移的话, 某个磁盘满了不健康,要是数据没有落完就会被kill掉。所以落地前需要保证所有几点的磁盘空间可用
- 在执行MR作业的时候,需要查看当前的集群状态是否健康,各个节点存储状态。程序莫名被kill掉,然后重启:TaskAttempt killed because it ran on unusable node ip 10-0-1-17.cn-northwest ...Container released on a *lost* node 这个时候,是由于集群的数据存储偏移,导致某个节点存储超过80%不健康,就会被kill掉,这个时候,MR还是会运行,但是如果节点存储不了,到99%还是会被kill 掉,所以需要手动平衡节点的存储。
- 我们是使用的是Hbase数据的批量生成hfile,要是全量数据的话,一个表的数据4.5T左右,然后再集群的数据落地的时候,就会发生平衡速度小于数据的落地速度,导致某个服务器的磁盘占满,然后任务重启。默认的hbase集群的平衡机制是1M,我们手动执行hdfs dfsadmin -setBalancerBandwidth 52428800 ,将默认的平衡带宽设置到50M,集群数据可以实现自动平衡。
- 提交到yarn上的任务,当某个磁盘被占满时候,当前节点就会不健康,然后这个job就被kill掉重启,所以大任务一定要保证当前的磁盘空间充足。(在浏览器上的查看的50070端口,页面的服务器状态或者磁盘存储可能不准,需要去对应的服务器下查看)
- job提交的时候,如果类名和之前提交脚本名相同的时候,在同一个环境下,会执行另外一个脚本,所以需要修改不同的类名。
- 在执行spark任务的时候,如果资源的磁盘过小的情况,可能导致数据无法落地,或者任务执行慢。
- 在mr执行批量生成Hfiles的时候,就算资源是使用的FIFO模式,要是资源被占用完了也是报错,执行长时间的话,导致某个节点失联。
- 在MR作业的时候,部分参数是我们提前配置的,例如:mapreduce.reduce.memory.mb=4006 这个时候,有时候数据量大的时候,会导致Container Killed on request Exit code is 143
- 集群出现Name node is in safe mode ,导致所有资源都挂掉了,是因为主节点服务器磁盘被突然占用完了,剩余空间显示0导致的。
- hbase集群,由MasterProcWals状态日志过多导致的HBase Master宕机,系统一直无法加载数据,所以需要定时清楚这些日志。
- spark任务分区,在执行小任务的时候,要是分区设置太多会在每一个job的时候,就是sql任务的时候都会按这个分区去执行,最后导致大多数的分区里是没有数据的,在调用百度的经纬度的时候,因为每天是限量的,而且每次的并发有上限,所以for循环执行语句,将经纬度转换成功的失败的插入到不同的表,但是分区数没有改,6000,每次插入的时候,会复制6000个分区文件,然后导致有几十万个文件,任务虽然执行完了,但是数据还是没有合并完,还在慢慢copy。
- hbase集群调用并发情况下突然出现响应慢的问题,经过排查发现是磁盘的IO降低了,性能出现问题。
- 在执行小数据的时候,落地表的时候也会生成默认的partition,多个分区文件。sparkSQL每次执行要想让他生成hive表后的文件少,可以在RDD上进行repartition()指定个数
- hbase使用./zkStart.sh status无法查看状态,当启动的时候报已经启动。原因是因为zookeeper只有一个节点,但是主节点曾经发生磁盘溢满,进入安全模式,所以出现问题。删除对应位置的snapshot快照文件就可以了。
- 执行MR的时候,task报错,Container is running beyond physical memory limits Current usage :8.2G of 8G physical memory used ;13.5GB of 40GB virtual memory used.Killing container.(Container killed on request. Exit code is 143),首先看看你的MR程序中 conf.set("mapreduce.map.memory.mb", "4096");conf.set("mapreduce.reduce.memory.mb", "8192"); 这两个参数设置的是不是太小了,然后看是不是底层数据的问题。
- 在MR执行的时候报错,OOM,Java heap space,mapreduce.task.reduce.Shuffle$ShuffleError:error in shuffle in fetcher,这个是由于数据大,刚开始的时候map阶段内存不够,
然后增加后导致reduce阶段不够,所以得对称调整。conf.set("mapreduce.map.memory.mb", "3072");conf.set("mapreduce.reduce.memory.mb", "10240");
调整配置conf.set("mapreduce.reduce.shuffle.memory.limit.percent", "0.08"); - 亚马逊服务器访问百度经纬度接口的时候,百度DNS解析到了香港,导致web访问太慢了,接口就无法访问到.
- 亚马逊的服务在19.8月才出来了高可用服务,之前都是一个集群一个master节点,曾经的我们36个节点的spark集群就是应为主节点宕机,这个服务不可用。
- Hbase集群也是有主节点宕机一次,但是这个regionServer上的数据都已经备份到其他的服务器节点上,但是客户在调用的时候还是会访问到,然后就获取不到数据。
- 自建Hadoop集群,是否可以很好的使用S3,1.默认支持把S3作为外表,对S3上的数据做查询;
- 可以使用类似emrfs的开源组件是s3guard集成: https://hadoop.apache.org/docs/r3.1.1/hadoop-aws/tools/hadoop-aws/s3guard.html
- HBASE表disable的时候,cat't get the loacation for replica 0,这个是因为我们进入的不是HBASE用户,然后操作数据就会有这个情况,然后呢如果强行给删掉一些文件后,如果表比较大的话,会有问题,残留文件导致集群假死,然后可以重新启动master节点。查看/var/log/hbase/habse**.log发现有些请求不到,然后重启Hmaster ,使用sudo stop hbase-master后sudo start hbase-master,然后进入shell也是用sudo -u hbase hbase shell 先到hbase用户下使用。
- a