最新最全的游戏资讯新闻内容分享。
您的位置:主页 > 电竞 > 内容:error是什么错误,authentication error怎么解决

error是什么错误,authentication error怎么解决

时间:2021-06-04 06:05:51来源:https://www.fangfengyichenwang.com.cn

导读 : 一.SparkSQL相关执行insert语句时报告错误,堆栈信息为:文件系统已关闭。经常出现在ThriftSer...

一.SparkSQL相关

执行insert语句时报告错误,堆栈信息为:文件系统已关闭。经常出现在ThriftServer中。原因:因为hadoop FileSystem.get获得的FIless将从缓存中加载,如果一个线程是多线程的,closedFileSystem将导致BUG解决方案:hdfs有一个不从缓存中加载的解决方案。spark fs . HDFS . impl . disable . cache=true in HDFS-site . XML to throw:failed to bigdata 01010833603381,原因:Java . nio . channels . unresolved daddersexception原因:这是因为没有配置主机。无法识别的解决方案:修改相应机器的主机以抛出:Java . lang . indexout of bound sexception或Java . lang . NullPointRexception在执行Sparksql操作或类型表时。原因:分区或表下有一个空的orc文件。该BUG在Spark2.3.0之后被修复。解决方法:规避。将ORC的默认分区策略修改为:hive . exec . ORC . split . strategy=bi。Orc拆分有三种策略(ETL、BI、HYBIRD)。默认为HYBIRD(混合模式,根据文件大小和编号自动选择ETL或BI模式),BI模式根据文件编号进行拆分。spark 2.1.0不支持永久函数,因为它不支持在Spark2.2.0之前读取hdfs上的jar包,使用spark-sql和ThriftServer: Java时报错。net . sockettimeoutexception : read time out原因:hivemetastore太忙或gc导致连接超时。解决方案:spark-SQL解决方案:hive . metastore . client . socket . time out .请增加此参数。ThriftServer解决方案:add: drivermanager。在获得连接之前设置logittime out(100)。操作nimper压缩表时引发:Java . lang . runtimeexception :本机nimper库不可用:此版本的libHadoop是在没有nimper支持的情况下构建的。原因:原因是没有给java.library.path:修改spark-default.conf配置文件并添加:spark . executor . extra library path/data/install/Hadoop/lib/native或spark . executor . extra javaoptions-djava . library . path=/data/install

/hadoop/lib/native
  • Spark-sql在执行时将一个很小的文件拆分成了20个task进行运行,导致运行速度太慢。
    • 原因:是由于HaddopRDD生成过程中partitions是会拿参数mapreduce.job.maps ,或mapred.map.tasks(20)和spark默认分区数(2)做最大值比较,所以导致默认为20
    • 解决方法:修改该参数就可以将task降下来。
  • ThriftServer登录异常:javax.security.sasl.AuthenticationException: Error validating LDAP user
    • 原因:是由于密码错误或者LDAP服务异常
    • 解决方法:解决密码和验证问题
  • 使用jdbc的方式连接到ThriftServer,可以执行类似与show tabls的等操作,但是不能执行select相关的操作:java.io.IOException: Failed to create local dir in /tmp/blockmgr-adb70127-0a28-4256-a205-c575acc74f9d/06.
    • 原因:用户很久没使用ThriftServer导致系统清理了该上级目录或者用户根本就对该目录没有写权限
    • 解决方法:重启ThriftServer和设置目录权限:spark.local.dir
  • 在Spark SQL中运行的SQL语句过于复杂的话,会出现 java.lang.StackOverflowError 异常
    • 原因:这是因为程序运行的时候 Stack 大小大于 JVM 的设置大小
    • 解决方法:通过在启动 Spark-sql 的时候加上 --driver-java-options “-Xss10m” 选项解决这个问题
  • INSERT INTO重复执行出现:Unable to move source hdfs://bigdata05/tmp/hive-hduser1101_hive_2017-09-11_14-50-56_038_2358196375683362770-82/-ext-10000/part-00000 to destination hdfs://bigdata05/user/hive
    • 原因:该问题是2.1.0的Bug,在Spark2.1.1中已经解决2.1.0。
    • 解决方法:2.1.0规避办法INSERT OVERWRITE不带分区重复执行不会出现问题
  • 执行大数据量的join等操作时出现:1.Missing an output location for shuffle;2.Failed to connect to bigdata030015/100.103.131.13:38742; 3.FileNotFoundException……(not such file or directory)。4.Container killed on request. Exit code is 143



    • 原因:shuffle分为shuffle write和shuffle read两部分。shuffle write的分区数由上一阶段的RDD分区数控制,shuffle read的分区数则是由Spark提供的一些参数控制。shuffle write可以简单理解为类似于saveAsLocalDiskFile的操作,将计算的中间结果按某种规则临时放到各个executor所在的本地磁盘上。
      • shuffle read的时候数据的分区数则是由spark提供的一些参数控制。可以想到的是,如果这个参数值设置的很小,同时shuffle read的量很大,那么将会导致一个task需要处理的数据非常大。结果导致JVM crash(OOM),从而导致取shuffle数据失败,同时executor也丢失了,看到Failed to connect to host的错误,也就是executor lost的意思。有时候即使不会导致JVM crash也会造成长时间的gc
    • 解决方法:1. 调优sql。
      • 2.SparkSQL和DataFrame的join,group by等操作通过spark.sql.shuffle.partitions控制分区数,默认为200,根据shuffle的量以及计算的复杂度提高这个值。
      • 3.Rdd的join,groupBy,reduceByKey等操作,通过spark.default.parallelism控制shuffle read与reduce处理的分区数,设置大一点。
      • 4.通过提高executor的内存设置spark.executor.memory适当提高executor的memory值。
      • 5.判断join过程中是否存在数据倾斜的问题:可以参考链接:https://tech.meituan.com/spark-tuning-pro.html
  • Sparksql使用过程中Executor端抛出:java.lang.OutOfMemoryError: GC overhead limit exceeded



    • 原因:这是由于大部分事件都在GC,导致OOM。
    • 解决方法:加大执行器内存,修改GC策略spark.executor.extraJavaOptions -XX:+UseG1GC



  • hiveserver2和SparkThriftServer使用操作orc表的时候报错A用户无法访问B用户的目录。
    • 原因:这是由于orc 在进行Split过冲中会进行用户缓存。ORC在hive1.2.1时的BUG,在hive2.X和Spark2.3.X版本后进行了解决
    • 解决方法:暂时规避方法比较暴力,1、先使用超级用户进行第一次查询,导致缓存的用户为超级用户。2、设置hive.fetch.task.conversion=none不进行缓存
  • spark-sql在使用过程中小数据量查询很慢,查看sparkUI显示每个Task处理都很快,但是都隔了3秒进行调度导致整体很慢。
    • 原因:这是由于数据本地性导致的,默认spark.locality.wait为3秒
    • 解决方法:设置该参数为0即可加快速度,只有在数据量较小的情况下才建议这样设置。

二.Spark core相关


  • on yarn启动spark-sql 和spark-submit时出现:java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig
    • 原因:和yarn相关Jersey包冲突
    • 解决方法:配置上–conf spark.hadoop.yarn.timeline-service.enabled=false
  • 在使用Spark过程中出现:java.io.IOException: No space left on device
    • 原因:一般是由于Spark的tmp目录满了导致
    • 解决方法:可以将该目录空间设置大点,支持按逗号分割多个目录:spark.local.dir
  • 超出最大结果集:is bigger than spark.driver.maxResultSize (2.0GB)
    • 原因:spark.driver.maxResultSize默认配置为1G
    • 解决方法:调大该参数即可
  • 常见OOM:java.lang.OutOfMemoryError: Java heap space
    • 原因:1、数据量太大,申请的Executor资源不足以支撑。2.单分区的数据量过大,和分区数过多导致执行task和job存储的信息过多导致Driver OutOfMemoryError
    • 解决方法:1、尽量不要使用collect操作。2、查看数据是否有倾斜,增加shuffle的并行度,加大Executor内存
  • 由Executor的FullGC引起Executor lost,task失败,各种超时:Futures timed out after【120S】
    • 原因:一般是由于Executor处理数据量过大如倾斜导致,从而使Executor full gc导致时间超时,Executor 和 task 的lost
    • 解决方法:1、如果通过查看Executor的日志是full GC导致,适当调优SQL,加大Executor内存。2、如果没有fullGC考虑提高:spark.network.timeout
  • jar包版本冲突时:java.lang.ClassNotFoundException: XXX
    • 原因:一般可能是用户jar和Spark jar冲突
    • 解决方法:1、最好和Spark相关的jar进行适配。2、如果不行可以使用参数:spark.driver.userClassPathFirst和spark.executor.userClassPathFirst 设置为true
  • 进行shuffle抛出:Shuffle Fetch Failed: OOM
    • 原因:Shuffle fetch阶段开启的fetch数据量过大导致
    • 解决方法:1、加大Executor内存。2、将参数spark.reduce.maxSizeInFlight调小,默认48M
  • shuffle报org.apache.spark.shuffle.FetchFailedException: Direct buffer memory
    • 原因:堆外内存不够导致,直接内存
    • 解决方法:增大JVM 参数-XX:MaxDirectMemorySize(如:spark.executor.extraJavaOptions = -XX:MaxDirectMemorySize=xxxm)
  • 集群节点异常导致Spark job失败,如磁盘只读。
    • 原因:Spark 是一个高性能、容错的分布式计算框架,一旦它知道某个计算所在的机器出现问题会依据之前生成的 lineage 重新在这台机器上调度这个 Task,如果超过失败次数就会导致job失败。
    • 解决方法:Spark有黑名单机制,在超出一定次数的失败后不会往该节点或者Executor调度Task。设置相应Black参数:spark.blacklist.enabled=true



三.Pyspark相关


  • driver python和Executor Python版本不一致问题
    • 原因:pyspark要求所有的Executor运行的python版本一致
    • 解决方法:指定python的运行路径:spark.pyspark.python /data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/python 或者 env配置上:export PYSPARK_PYTHON=/data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/python;export PYSPARK_DRIVER_PYTHON=/data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/python
  • Pyspark使用过程中出现:RDD时出现序列化pickle.load(obj)报错,EOFError。有时可以,在local也可以。
    • 原因:在on yarn时,机器上也有安装相关的Spark。导致包冲突
    • 解决方法:删除nodeManager上的Spark安装路径就可以解决
  • 运行RDD操作时报Randomness of hash of string should be disabled via PYTHONHASHSEED mean in pyspark
    • 原因:这是由于各个Executor的Hash随机值不一样导致。
    • 解决方法:只需要指定各Executor的PYTHONHASHSEED环境变量即可如:–conf spark.executorEnv.PYTHONHASHSEED=321



四.Streaming相关


  • 消费kafka时,第一个job读取了现有所有的消息,导致第一个Job处理过久甚至失败
    • 原因:auto.offset.reset设置为了earliest 从最早的offset开始进行消费,也没有设置spark.streaming.kafka.maxRatePerPartition参数
    • 解决方法:指定从之前开始消费的数据开始:设置offsetRange。并将参数设置为:auto.offset.reset=latest 设置Spark每个分区的速率。
  • 尽量使用高性能算子
    • 使用reduceByKey/aggregateByKey替代groupByKey
    • 使用mapPartitions替代普通map
    • 使用foreachPartitions替代foreach
    • 使用filter之后进行coalesce操作
    • 使用repartitionAndSortWithinPartitions替代repartition与sort类操作
  • Streaming如果存在多个Batch延迟时,消费不过来。有时会报出:Hbase相关的异常如:RegionTooBusyException
    • 原因:Streaming在进行处理时如果单个Batch读取的数据多,会导致计算延迟甚至导致存储组件性能压力
    • 解决方法:1、如果是计算延迟试着调整读取速率如:spark.streaming.kafka.maxRatePerPartition参数 2、调优存储组件的性能 3、开启Spark的反压机制:spark.streaming.backpressure.enabled,该参数会自动调优读取速率。但是如果设置了spark.streaming.receiver.maxRate 或 spark.streaming.kafka.maxRatePerPartition,那么最后到底接收多少数据取决于三者的最小值
  • 消费kafka时,读取消息报错:OffsetOutOfRangeException
    • 原因:读取的offsetRange超出了Kafka的消息范围,如果是小于也就是kafka保存的消息已经被处理掉了(log.retention.hours)。或者超出Kafka现有的offset
    • 解决方法:在读取offset时先进行校正,拿到offset的earliestOffset 和lastestOffset
  • Kafka抖动导致No leader found
    • kafka变更或者其他原因导致
    • 解决方法:设置 spark.streaming.kafka.maxRetries 大于1

未完待续。


相关推荐:
最新阅览: