项目总结记录

18年项目总结

1. 如果在运行spark的时候，有时候环境的问题需要引入其他的jar包，那么我们可以使用--driver-class-path $HBASE_HOME/lib/*:classpath也可以以在脚本前面执行export ****生成当前需要的环境

1. 当前我们集群使用的版本 jdk1.8 spark2.11 hive2.1.1 hbase1.3.0 hadoop2.7.3 zookeeper3.4.10
2. 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有足够的内存
3. 如果数据量不是很大的话，没必要设置分区太大，不然的话每个分区上的数据都很小，某一个分区上的数据发生倾斜时候，其他的分区就会关闭，导致连接失败，然后某个分区的数据就会发生OOM，这时候一、减少运行cores；二、增加每个core的memory，三、减少partition。
4. 遇到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年项目总结

1. 需要时常查看集群的状态，特别是自热人订单大表落地的时候，在新数据跟新的时候，应该删除原来的数据，不然会导致部分数据偏移的话， 某个磁盘满了不健康，要是数据没有落完就会被kill掉。所以落地前需要保证所有几点的磁盘空间可用
2. 在执行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还是会重新运行，将数据存储到健康的节点上，所以需要手动平衡节点的存储。
3. 我们是使用的是Hbase数据的批量生成hfile，要是全量数据的话，一个表的数据4.5T左右，然后再集群的数据落地的时候，就会发生平衡速度小于数据的落地速度，导致某个服务器的磁盘占满，然后任务重启。默认的hbase集群的平衡机制是1M，我们手动执行hdfs dfsadmin -setBalancerBandwidth 52428800 ，将默认的平衡带宽设置到50M，集群数据可以实现自动平衡。但是非常重要的一个问题，就是它会影响服务器的服务，所以，要是在线上用的话，一定记得不要太大，以前100M导致线上服务无法提供。
4. 提交到yarn上的任务，当某个磁盘被占满时候，当前节点就会不健康，然后这个job就被kill掉重启，所以大任务一定要保证当前的磁盘空间充足。（在浏览器上的查看的50070端口，页面的服务器状态或者磁盘存储可能不准，需要去对应的服务器下查看）
5. 我们提交的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导致数据无法落地，部分任务执行过慢：调整磁盘空间大小解决这个问题。
6. 在执行job的时候，如果存在多个join操作后，然后没有生成表直接union的时候，会发生OOM,如果数据量大，执行语句复杂也会OOM,需要落地表后在执行就OK.
7. 在执行MR操作生成Hfiles的时候，主要时间是用来执行reduce，这个时候，虽然集群式FIFO，但是，要是启动某个spar shell或者job没有限制资源的时候，它就会占用剩余的资源，这样就导致MR失败，某个节点失联。
8. 1.需要时常查看集群的状态，特别是自热人订单大表落地的时候，在新数据跟新的时候，应该删除原来的数据，不然会导致部分数据偏移的话， 某个磁盘满了不健康，要是数据没有落完就会被kill掉。所以落地前需要保证所有几点的磁盘空间可用
9. 在执行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 掉，所以需要手动平衡节点的存储。
10. 我们是使用的是Hbase数据的批量生成hfile，要是全量数据的话，一个表的数据4.5T左右，然后再集群的数据落地的时候，就会发生平衡速度小于数据的落地速度，导致某个服务器的磁盘占满，然后任务重启。默认的hbase集群的平衡机制是1M，我们手动执行hdfs dfsadmin -setBalancerBandwidth 52428800 ，将默认的平衡带宽设置到50M，集群数据可以实现自动平衡。
11. 提交到yarn上的任务，当某个磁盘被占满时候，当前节点就会不健康，然后这个job就被kill掉重启，所以大任务一定要保证当前的磁盘空间充足。（在浏览器上的查看的50070端口，页面的服务器状态或者磁盘存储可能不准，需要去对应的服务器下查看）
12. job提交的时候，如果类名和之前提交脚本名相同的时候，在同一个环境下，会执行另外一个脚本，所以需要修改不同的类名。
13. 在执行spark任务的时候，如果资源的磁盘过小的情况，可能导致数据无法落地，或者任务执行慢。
14. 在mr执行批量生成Hfiles的时候，就算资源是使用的FIFO模式，要是资源被占用完了也是报错，执行长时间的话，导致某个节点失联。
15. 在MR作业的时候，部分参数是我们提前配置的，例如：mapreduce.reduce.memory.mb=4006 这个时候，有时候数据量大的时候，会导致Container Killed on request Exit code is 143
16. 集群出现Name node is in safe mode ，导致所有资源都挂掉了，是因为主节点服务器磁盘被突然占用完了，剩余空间显示0导致的。
17. hbase集群，由MasterProcWals状态日志过多导致的HBase Master宕机，系统一直无法加载数据，所以需要定时清楚这些日志。
18. spark任务分区，在执行小任务的时候，要是分区设置太多会在每一个job的时候，就是sql任务的时候都会按这个分区去执行，最后导致大多数的分区里是没有数据的，在调用百度的经纬度的时候，因为每天是限量的，而且每次的并发有上限，所以for循环执行语句，将经纬度转换成功的失败的插入到不同的表，但是分区数没有改，6000，每次插入的时候，会复制6000个分区文件，然后导致有几十万个文件，任务虽然执行完了，但是数据还是没有合并完，还在慢慢copy。
19. hbase集群调用并发情况下突然出现响应慢的问题，经过排查发现是磁盘的IO降低了，性能出现问题。
20. 在执行小数据的时候，落地表的时候也会生成默认的partition，多个分区文件。sparkSQL每次执行要想让他生成hive表后的文件少，可以在RDD上进行repartition（）指定个数
21. hbase使用./zkStart.sh status无法查看状态，当启动的时候报已经启动。原因是因为zookeeper只有一个节点，但是主节点曾经发生磁盘溢满，进入安全模式，所以出现问题。删除对应位置的snapshot快照文件就可以了。
22. 执行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"); 这两个参数设置的是不是太小了，然后看是不是底层数据的问题。
23. 在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");
24. 亚马逊服务器访问百度经纬度接口的时候，百度DNS解析到了香港，导致web访问太慢了，接口就无法访问到.
25. 亚马逊的服务在19.8月才出来了高可用服务，之前都是一个集群一个master节点，曾经的我们36个节点的spark集群就是应为主节点宕机，这个服务不可用。
26. Hbase集群也是有主节点宕机一次，但是这个regionServer上的数据都已经备份到其他的服务器节点上，但是客户在调用的时候还是会访问到，然后就获取不到数据。
27. 自建Hadoop集群，是否可以很好的使用S3，1.默认支持把S3作为外表，对S3上的数据做查询；
28. 可以使用类似emrfs的开源组件是s3guard集成： https://hadoop.apache.org/docs/r3.1.1/hadoop-aws/tools/hadoop-aws/s3guard.html 
29. 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用户下使用。
30. a