gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

Hbase由于网络或操作系统故障引起的找不到hbase:meta异常

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  
  • 作者: east
  • ( 页面63 )
bug清单 2月 28,2021

Hbase由于网络或操作系统故障引起的找不到hbase:meta异常

由于网络或操作系统故障引起的找不到hbase:meta异常

现象描述

在执行MapReduce或者Spark等程序时,可能出现如下异常导致的任务执行失败:

Caused by: java.net.SocketTimeoutException: callTimeout=60000, callDuration=60304: row '' 
on table 'hbase:meta' at region=hbase:meta,,1.1588230740, hostname=host1,21302,1448886113294, seqNum=0
at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:159)
at org.apache.hadoop.hbase.client.ResultBoundedCompletionService$QueueingFuture.run(ResultBoundedCompletionService.java:64)
... 3 more

可能原因

  • HDFS服务不可用。
  • ZooKeeper上存储的meta region位置数据和实际不符。

定位思路

无。

处理步骤

  1. 确认HDFS服务是否可用,如果HDFS服务不可用,请先排除HDFS故障。
  2. 如果HDFS服务无故障,从HBase原生网页中找到hbase:meta表所在节点,重启该节点的RegionServer。
作者 east
bug清单 2月 28,2021

运行Spark Streaming应用时出现内存不足的问题

运行Spark Streaming应用时出现内存不足的问题

现象描述

某Spark Streaming应用对每个批次不大于3000M的数据进行wordcount,即使每个executor给予30G内存,执行一段时间后还是会发生内存不足。

日志信息如下:

2016-02-04 20:19:43,458 | ERROR | [Thread-29] | Uncaught exception in thread Thread[Thread-29,5,main] | org.apache.spark.Logging$class.logError(Logging.scala:96)
java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:3236)
        at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
        at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
        at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
        at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877)
        at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1786)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1189)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
        at org.apache.spark.serializer.JavaSerializationStream.writeObject(JavaSerializer.scala:43)
        at org.apache.spark.serializer.SerializationStream.writeAll(Serializer.scala:153)
        at org.apache.spark.storage.BlockManager.dataSerializeStream(BlockManager.scala:1190)
        at org.apache.spark.storage.BlockManager.dataSerialize(BlockManager.scala:1199)
        at org.apache.spark.streaming.receiver.WriteAheadLogBasedBlockHandler.storeBlock(ReceivedBlockHandler.scala:173)

可能原因

Spark Streaming从Kafka接收数据的方式有两种:

  • Receiver-based Approach
  • Direct Approach (No Receivers)

上述问题只有Receiver-based的方式会出现,Direct的方式不会出现该问题。

在Spark Streaming应用中,每一个批次会生成一个job。如果job的处理时间大于批次的时间间隔(批次时间间隔在Spark Streaming应用中定义),则从数据源(即Kafka)接收的数据就会累积,最后造成任务的不断积压,导致executor端内存溢出。

定位思路

无。

处理步骤

当出现如上问题时,建议可采用如下两种方法进行调整,两种方法可同时使用:

  • 适当缩短批次的时间,使得接收到的数据量不要太大。
  • 根据任务量增大内存,使得job的处理时间加快,保证job的处理时间比批次的时间短。
作者 east
bug清单 2月 28,2021

行Spark SQL语句时,出现joinedRow.isNullAt的空指针异常

执行Spark SQL语句时,出现joinedRow.isNullAt的空指针异常

现象描述

在执行Spark SQL语句时,出现“joinedRow.isNullAt”的空指针异常,异常信息如下所示。

6/09/08 11:04:11 WARN TaskSetManager: Lost task 1.0 in stage 7.0 (TID 10, vm1, 1): java.lang.NullPointerException
        at org.apache.spark.sql.catalyst.expressions.JoinedRow.isNullAt(JoinedRow.scala:70)
        at org.apache.spark.sql.catalyst.expressions.GeneratedClass$SpecificMutableProjection.apply(Unknown Source)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator$$anonfun$generateProcessRow$1.apply(TungstenAggregationIterator.scala:194)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator$$anonfun$generateProcessRow$1.apply(TungstenAggregationIterator.scala:192)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.processInputs(TungstenAggregationIterator.scala:372)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.start(TungstenAggregationIterator.scala:626)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1.org$apache$spark$sql$execution$aggregate$TungstenAggregate$$anonfun$$executePartition$1(TungstenAggregate.scala:135)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$3.apply(TungstenAggregate.scala:144)
        at org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$3.apply(TungstenAggregate.scala:144)
        at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:64)
        at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
        at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
        at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
        at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:75)
        at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:42)
        at org.apache.spark.scheduler.Task.run(Task.scala:90)
        at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:253)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

可能原因

由如下日志信息可知,该错误是由于内存不足,导致buffer在申请内存时申请失败返回为null,对null进行操作就返回了空指针异常。

当集群中内存相关的关键配置项的值设置的比较小时,例如设置为如下所示的值:

spark.executor.cores = 8

spark.executor.memory = 512M

spark.buffer.pageSize = 16M

此时,执行任务会出现内存申请失败返回null的异常,关键日志如下:

6/09/08 11:04:11 WARN TaskSetManager: Lost task 1.0 in stage 7.0 (TID 10, vm1, 1): java.lang.NullPointerException
        at org.apache.spark.sql.catalyst.expressions.JoinedRow.isNullAt(JoinedRow.scala:70)

定位思路

在使用Spark SQL时,需要满足如下条件:

spark.executor.memory * spark.shuffle.memoryFraction *spark.shuffle.safetyFraction / (num * spark.executor.cores) > spark.buffer.pageSize

“spark.shuffle.memoryFraction”默认值为“0.2”。“spark.shuffle.safetyFraction”默认值为“0.8”。“spark.buffer.pageSize”默认值为“16M”。

常数num的经验取值为8,根据不同的SQL语句取值不同,每个task最多可以去申请16次pageSize,所以num的最大值为16。将公式中的参数num设置为16时,即可满足Spark SQL出现问题的所有场景。但通常情况下8即能满足绝大多数的场景要求。

处理步骤

根据executor日志提示信息,您可以通过调整如下两个参数解决此问题。在客户端的“spark-defaults.conf”配置文件中调整如下参数。

  • spark.executor.memory:增加executor的内存,即根据实际业务量,适当增大“spark.executor.memory”的参数值。需满足公式:spark.executor.memory > spark.buffer.pageSize * (num * spark.executor.cores) / spark.shuffle.memoryFraction / spark.shuffle.safetyFraction
  • spark.executor.cores:减小executor的核数,即减小executor-cores的参数值。需满足公式:spark.executor.cores < spark.executor.memory / spark.buffer.pageSize / num * spark.shuffle.memoryFraction * spark.shuffle.memoryFraction。

在调整这两个参数时,需满足spark.executor.memory * spark.shuffle.memoryFraction *spark.shuffle.safetyFraction / (num * spark.executor.cores) > spark.buffer.pageSize公式,在内存充足的情况下,建议直接将常数num设置为16,可解决所有场景遇到的内存问题。

作者 east
bug清单 2月 28,2021

Spark出现Unable to acquire异常

出现Unable to acquire异常

现象描述

执行Spark SQL语句时,出现java.io.IOException: Unable to acquire […] bytes of memory异常,如下:

WARN TaskSetManager: Lost task 578.2 in stage 30.0 (TID 228063, 8-5-203-1, 244): java.io.IOException: Unable to acquire 16777216 bytes of memory
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.acquireNewPage(UnsafeExternalSorter.java:354)
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.<init>(UnsafeExternalSorter.java:141)
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.create(UnsafeExternalSorter.java:109)
    at org.apache.spark.sql.execution.UnsafeExternalRowSorter.<init>(UnsafeExternalRowSorter.java:68)
    at org.apache.spark.sql.execution.TungstenSort.org$apache$spark$sql$execution$TungstenSort$$preparePartition$1(sort.scala:146)
    at org.apache.spark.sql.execution.TungstenSort$$anonfun$doExecute$3.apply(sort.scala:169)
    at org.apache.spark.sql.execution.TungstenSort$$anonfun$doExecute$3.apply(sort.scala:169)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.prepare(MapPartitionsWithPreparationRDD.scala:50)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD$$anonfun$tryPrepareParents$1.applyOrElse(ZippedPartitionsRDD.scala:83)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD$$anonfun$tryPrepareParents$1.applyOrElse(ZippedPartitionsRDD.scala:82)
    at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33)
    at scala.collection.TraversableLike$$anonfun$collect$1.apply(TraversableLike.scala:278)
    at scala.collection.immutable.List.foreach(List.scala:318)
    at scala.collection.TraversableLike$class.collect(TraversableLike.scala:278)
    at scala.collection.AbstractTraversable.collect(Traversable.scala:105)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD.tryPrepareParents(ZippedPartitionsRDD.scala:82)
    at org.apache.spark.rdd.ZippedPartitionsRDD2.compute(ZippedPartitionsRDD.scala:97)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.ZippedPartitionsRDD2.compute(ZippedPartitionsRDD.scala:99)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:75)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:42)
    at org.apache.spark.scheduler.Task.run(Task.scala:90)
    at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:253)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745).

一定概率下,当以上WARN连续导致同一个Task失败4次后,会导致Job级别的失败,如下:

org.apache.spark.SparkException: Job aborted due to stage failure: Task 537 in stage 30.0 failed 4 times, most recent failure: Lost task 537.3 in stage 30.0 (TID 228865, 8-5-202-7, 650): java.io.IOException: Unable to acquire 16777216 bytes of memory
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.acquireNewPage(UnsafeExternalSorter.java:354)
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.<init>(UnsafeExternalSorter.java:141)
    at org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter.create(UnsafeExternalSorter.java:109)
    at org.apache.spark.sql.execution.UnsafeExternalRowSorter.<init>(UnsafeExternalRowSorter.java:68)
    at org.apache.spark.sql.execution.TungstenSort.org$apache$spark$sql$execution$TungstenSort$$preparePartition$1(sort.scala:146)
    at org.apache.spark.sql.execution.TungstenSort$$anonfun$doExecute$3.apply(sort.scala:169)
    at org.apache.spark.sql.execution.TungstenSort$$anonfun$doExecute$3.apply(sort.scala:169)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.prepare(MapPartitionsWithPreparationRDD.scala:50)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD$$anonfun$tryPrepareParents$1.applyOrElse(ZippedPartitionsRDD.scala:83)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD$$anonfun$tryPrepareParents$1.applyOrElse(ZippedPartitionsRDD.scala:82)
    at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33)
    at scala.collection.TraversableLike$$anonfun$collect$1.apply(TraversableLike.scala:278)
    at scala.collection.immutable.List.foreach(List.scala:318)
    at scala.collection.TraversableLike$class.collect(TraversableLike.scala:278)
    at scala.collection.AbstractTraversable.collect(Traversable.scala:105)
    at org.apache.spark.rdd.ZippedPartitionsBaseRDD.tryPrepareParents(ZippedPartitionsRDD.scala:82)
    at org.apache.spark.rdd.ZippedPartitionsRDD2.compute(ZippedPartitionsRDD.scala:97)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsWithPreparationRDD.compute(MapPartitionsWithPreparationRDD.scala:63)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.ZippedPartitionsRDD2.compute(ZippedPartitionsRDD.scala:99)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
    at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:334)
    at org.apache.spark.rdd.RDD.iterator(RDD.scala:267)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:75)
    at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:42)
    at org.apache.spark.scheduler.Task.run(Task.scala:90)
    at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:253)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)               

可能原因

目前Spark Shuffle内存管理存在缺陷:原理上讲,ShuffleMemoryManger给Task分配内存时,根据运行时的Task个数去动态切分可分配的总内存,当一个Task结束后,运行时的Task个数相应减少,此时ShuffleMemoryManger会根据减少后的Task个数重新切分可分配的内存。在某些情况下,在新的Task起来之前,已运行的Task将内存全部占走。

在该场景下,新的Task会申请不到内存,然后触发溢出逻辑溢出当前UnsafeExternalSorter所占的内存,并重试申请动作,但由于其本身所占内存为0,溢出后还是分配不到内存,抛出上述异常,表示Task失败。

失败的Task会进行重试,若其他的Task及时地释放了内存,则Task会重试成功,Job不会失败。如果此时其他Task未及时释放内存,则Task重试失败。当该Task连续4次失败后导致Job失败。

定位思路

无。

处理步骤

进入Spark客户端的“$Spark_Client/conf/spark-defaults.conf”配置文件修改对应配置以规避此问题。

  • 方法一:设置spark.executor.cores=1,将单个Executor内的并行度将为1可规避此问题。
  • 方法二:增大spark.sql.shuffle.partitions,可降低该异常出现的概率。
  • 方法三:减小spark.buffer.pageSize,可降低该异常出现的概率
作者 east
bug清单 2月 28,2021

Spark 手动删除创建分区时指定的location目录导致使用select查询时提示文件不存在

手动删除创建分区时指定的location目录导致使用select查询时提示文件不存在

现象描述

手动删除创建分区时指定的location目录后,导致在使用select语句查询时提示文件不存在的错误,报错信息如下:

0: jdbc:hive2://192.168.169.84:22550/default> select * from tba;
Error: java.io.FileNotFoundException: File hdfs://hacluster/test does not exist. (state=,code=0)

可能原因

手动将HDFS上创建分区时指定的location目录删除后,并没有删除元数据中的分区信息,使用select语句查询时如果此目录不存在就会上报文件不存在的错误。

定位思路

通过show partitions tba;查看tba表的分区信息,发现目录删除后分区的元数据信息依然存在。

0: jdbc:hive2://192.168.169.84:22550/default> show partitions tba;
+----------------------+--+
|        result        |
+----------------------+--+
| date_str=2017-01-12  |
+----------------------+--+

处理步骤

由于HDFS上创建分区时指定的location目录已经删除,此分区下的所有数据信息已经无法恢复,但为了不影响其他分区的正常查询,有以下两个方法:

  • 使用如下命令手动添加报错信息中不存在的location目录: hdfs dfs -mkdir partition_location; 例如:hdfs dfs -mkdir hdfs://hacluster/test;
  • 在用户知道报错信息中location目录所对应的分区的前提下,可以使用如下命令删除数据表中关于此分区的元数据信息: alter table tablename drop partition_desc; 例如:alter table tba drop partition(date_str=’2017-01-12′);

说明:

若存在大量分区,使用mkdir或者drop partition命令会使操作过于繁琐,此时可通过设置参数“spark.sql.hive.verifyPartitionPath”为“true”,对分区路径不存在的分区进行过滤,使得手动删除创建分区时指定的location目录后,使用select语句查询时不会提示文件不存在,但每次会话(session)时都需要重新设置。

作者 east
bug清单 2月 28,2021

在Spark SQL中执行delete和drop操作时,出现数据删除失败异常

在Spark SQL中执行delete和drop操作时,出现数据删除失败异常

现象描述

安全模式下,在Spark SQL中执行delete和drop操作时,出现HDFS数据删除失败异常。

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
        at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211)
        at org.apache.hadoop.security.SaslRpcClient.saslConnect(SaslRpcClient.java:418)
        at org.apache.hadoop.ipc.Client$Connection.setupSaslConnection(Client.java:581)
        at org.apache.hadoop.ipc.Client$Connection.access$1900(Client.java:394)
        at org.apache.hadoop.ipc.Client$Connection$2.run(Client.java:764)
        at org.apache.hadoop.ipc.Client$Connection$2.run(Client.java:760)

可能原因

HDFS认证凭证过期。

定位思路

无。

处理步骤

HDFS中用户指定路径文件的数据需要用户手工删除。

登录HDFS,利用hdfs dfs -rm <path>或者hadoop fs -rm <path>

命令删除HDFS中指定路径文件的数据。

说明:

当HDFS服务不可用或者网络中断时,在Spark SQL中执行delete和drop操作时,需要确认下HDFS中用户指定路径文件的数据是否删除成功,若删除失败需要用如上的HDFS命令删除。

作者 east
bug清单 2月 27,2021

Job运行过程中,出现BlockNotFoundException异常,并出现stage重试

Job运行过程中,出现BlockNotFoundException异常,并出现stage重试

现象描述

Job运行过程中,出现下图中BlockNotFoundException异常,并出现stage重试。

Job运行过程中,出现BlockNotFoundException异常,并出现stage重试

可能原因

Executor上BlockManager的内存不足导致相应的block数据会从内存中drop掉,导致当前stage的任务获取不到block数据,进而使上一个stage重试,重新生成相应block数据,即出现stage重试的现象。

定位思路

无。

处理步骤

  • 根据客户端的配置文件“spark-defaults.conf”中“spark.memory.useLegacyMode”设置的值进行处理:
    • false:即启用统一内存管理模式,无需进行其他操作,系统会自行进行优化。
    • true:即不启用统一内存管理模式,此时需要手动修改内存比例。 在“spark-defaults.conf”文件中增大配置项“spark.storage.memoryFraction”的参数值,提高BlockManager内存占有Executor内存的比例。
  • 增加集群相应的Executor内存。
作者 east
bug清单 2月 27,2021

Spark任务运行失败,ApplicationMaster出现物理内存溢出异常

Spark任务运行失败,ApplicationMaster出现物理内存溢出异常

现象描述

在YARN上运行Spark任务失败,ApplicationMaster出现物理内存溢出异常。报错内容如下:

2016-05-12 19:27:18,078 | WARN  | Container Monitor | Container [pid=205193,containerID=container_1462240697997_3649_01_000001] is running beyond physical memory limits. Current usage: 4.5 GB of 4.5 GB physical memory used; 6.8 GB of 22.5 GB virtual memory used. Killing container.

可能原因

日志中显示“Killing container”,直接原因是物理内存使用超过了限定值,YARN的NodeManager监控到内存使用超过阈值,强制终止该container进程。

定位思路

无。

处理步骤

在Spark客户端“spark-defaults.conf”配置文件中增加如下参数,或者在提交命令时添加–conf指定如下参数,来增大memoryOverhead。

  • spark.yarn.driver.memoryOverhead:设置堆外内存大小(cluster模式使用)。
  • spark.yarn.am.memoryOverhead:设置堆外内存大小(client模式使用)。
作者 east
bug清单 2月 27,2021

Spark大数据计算时出现“Channel空闲超时”

大数据计算时出现“Channel空闲超时”

现象描述

在10节点集群,30T数据量下,执行tpcds测试时,出现如下错误。

Connection to 10.10.10.1 has been quiet for 123450 ms while there are still 5 outstanding requests. Assuming connection is dead; please adjust spark.network.timeout if this is wrong.

可能原因

当Map Server繁忙时,Reduce Client发出请求,得不到响应。当等待时间超过一个阈值时,出现错误。默认的时间为120秒。

定位思路

无。

处理步骤

上述问题是在request个数很大时发生的,属于正常现象。解决措施有两种:

  • 将spark.shuffle.io.connectionTimeout参数调大。10节点、30T数据的TPCDS测试中设置为2000s,运行正常。此参数与spark.network.timeout配合使用,优先使用spark.shuffle.io.connectionTimeout参数设置的值。如果spark.shuffle.io.connectionTimeout未设置,则使用spark.network.timeout的参数值。
  • 调大spark.shuffle.io.serverThreads来解决,将此参数的值设置为core个数的两倍。
作者 east
bug清单 2月 27,2021

Executor日志中显示物理内存超限

Executor日志中显示物理内存超限

现象描述

在如下场景下,会导致Executor日志中显示物理内存超限:

  • 在100T数据下,执行TPC-H 21号测试用例时,出现如下错误信息。 Spark Executor的日志信息如下2016-03-07 15:17:10,221 | ERROR | [SIGTERM handler] | RECEIVED SIGNAL 15: SIGTERM | org.apache.spark.util.SignalLoggerHandler.handle(SignalLogger.scala:57) YARN NodeManger的日志信息如下ERROR | [dispatcher-event-loop-28] | Lost executor 471 on 10-196-33-3: Yarn deallocated the executor 471 (container container_e04_1456978747173_0063_01_000473) | org.apache.spark.Logging$class.logError(Logging.scala:75) 2016-03-07 15:05:24,704 | WARN | [Reporter] | Container killed by YARN for exceeding memory limits. 22.0 GB of 22 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. | org.apache.spark.Logging$class.logWarning(Logging.scala:71)
  • 在100T数据下,执行TPC-H 22号测试用例时,出现如下错误信息。 Spark Driver日志信息如下:org.apache.spark.shuffle.FetchFailedException: java.lang.OutOfMemoryError: Direct buffer memory at org.apache.spark.storage.ShuffleBlockFetcherIterator.throwFetchFailedException(ShuffleBlockFetcherIterator.scala:339) at org.apache.spark.storage.ShuffleBlockFetcherIterator.next(ShuffleBlockFetcherIterator.scala:324) at org.apache.spark.storage.ShuffleBlockFetcherIterator.next(ShuffleBlockFetcherIterator.scala:52) at scala.collection.Iterator$$anon$14.hasNext(Iterator.scala:389) at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:327) at scala.collection.Iterator$$anon$13.hasNext(Iterator.scala:371) at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:327) at org.apache.spark.util.CompletionIterator.hasNext(CompletionIterator.scala:32) at org.apache.spark.InterruptibleIterator.hasNext(InterruptibleIterator.scala:39) at org.apache.spark.util.collection.ExternalSorter.insertAll(ExternalSorter.scala:217) at org.apache.spark.shuffle.hash.HashShuffleReader.read(HashShuffleReader.scala:110) at org.apache.spark.rdd.ShuffledRDD.compute(ShuffledRDD.scala:90) at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:301) at org.apache.spark.rdd.RDD.iterator(RDD.scala:265) at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38) at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:301) at org.apache.spark.rdd.RDD.iterator(RDD.scala:265) at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38) at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:301) at org.apache.spark.rdd.RDD.iterator(RDD.scala:265) at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:75) at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:42) at org.apache.spark.scheduler.Task.run(Task.scala:90) at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: io.netty.handler.codec.DecoderException: java.lang.OutOfMemoryError: Direct buffer memory at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:234) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111) … 1 more Caused by: java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:645) at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:228) at io.netty.buffer.PoolArena.allocate(PoolArena.java:212) at io.netty.buffer.PoolArena.reallocate(PoolArena.java:358) at io.netty.buffer.PooledByteBuf.capacity(PooledByteBuf.java:121) at io.netty.buffer.AbstractByteBuf.ensureWritable(AbstractByteBuf.java:251) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:849) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:841) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:831) at io.netty.handler.codec.ByteToMessageDecoder$1.cumulate(ByteToMessageDecoder.java:92) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:228) … 10 more

可能原因

由于Executor使用的堆外内存超限,导致被NodeManager终止任务或者报“申请不到堆外内存”错误。

作者 east
bug清单 2月 27,2021

Spark当Collect超大结果集到Driver时出现异常

当Collect超大结果集到Driver时出现异常

现象描述

当Collect超大的结果集到Driver端时会出现如下两种错误:

  • 出现OOM错误。日志信息如下:java.lang.OutOfMemoryError: GC overhead limit exceeded 16/01/25 12:08:56 WARN AkkaRpcEndpointRef: Error sending message [message = RemoveBroadcast(69,true)] in 1 attempts org.apache.spark.rpc.RpcTimeoutException: Recipient[Actor[akka://sparkDriver/user/BlockManagerMaster#366390194]] had already been terminated.. This timeout is controlled by spark.rpc.askTimeout at org.apache.spark.rpc.RpcTimeout.org$apache$spark$rpc$RpcTimeout$$createRpcTimeoutException(RpcEnv.scala:214) at org.apache.spark.rpc.RpcTimeout$$anonfun$addMessageIfTimeout$1.applyOrElse(RpcEnv.scala:229) at org.apache.spark.rpc.RpcTimeout$$anonfun$addMessageIfTimeout$1.applyOrElse(RpcEnv.scala:225) at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33) at scala.util.Failure$$anonfun$recover$1.apply(Try.scala:185) at scala.util.Try$.apply(Try.scala:161) at scala.util.Failure.recover(Try.scala:185) at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324) at scala.concurrent.Future$$anonfun$recover$1.apply(Future.scala:324) at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32) at org.spark-project.guava.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293) at scala.concurrent.impl.ExecutionContextImpl$$anon$1.execute(ExecutionContextImpl.scala:133) at scala.concurrent.impl.CallbackRunnable.executeWithValue(Promise.scala:40) at scala.concurrent.impl.Promise$DefaultPromise.scala$concurrent$impl$Promise$DefaultPromise$$dispatchOrAddCallback(Promise.scala:280) at scala.concurrent.impl.Promise$DefaultPromise.onComplete(Promise.scala:270) at scala.concurrent.Future$class.recover(Future.scala:324) at scala.concurrent.impl.Promise$DefaultPromise.recover(Promise.scala:153) at org.apache.spark.rpc.akka.AkkaRpcEndpointRef.ask(AkkaRpcEnv.scala:319) at org.apache.spark.rpc.RpcEndpointRef.askWithRetry(RpcEndpointRef.scala:100) at org.apache.spark.rpc.RpcEndpointRef.askWithRetry(RpcEndpointRef.scala:77)
  • 当结果集出现数据倾斜,有些数据块大于2G时,同时使用kryo进行序列化时会报NegativeArraySizeException错误。日志信息如下:16/02/16 16:55:13 WARN TaskSetManager: Lost task 750.0 in stage 66.0 (TID 33887, datasight-192): com.esotericsoftware.kryo.KryoException: java.lang.NegativeArraySizeException Serialization trace: values (org.apache.spark.sql.catalyst.expressions.GenericRowWithSchema) at com.esotericsoftware.kryo.serializers.FieldSerializer$ObjectField.write(FieldSerializer.java:585) at com.esotericsoftware.kryo.serializers.FieldSerializer.write(FieldSerializer.java:213) at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:568) at com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.write(DefaultArraySerializers.java:318) at com.esotericsoftware.kryo.serializers.DefaultArraySerializers$ObjectArraySerializer.write(DefaultArraySerializers.java:293) at com.esotericsoftware.kryo.Kryo.writeClassAndObject(Kryo.java:568) at org.apache.spark.serializer.KryoSerializerInstance.serialize(KryoSerializer.scala:260) at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:240) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NegativeArraySizeException at com.esotericsoftware.kryo.util.IdentityObjectIntMap.resize(IdentityObjectIntMap.java:409) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.putStash(IdentityObjectIntMap.java:227) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.push(IdentityObjectIntMap.java:221) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.put(IdentityObjectIntMap.java:117) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.putStash(IdentityObjectIntMap.java:228) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.push(IdentityObjectIntMap.java:221) at com.esotericsoftware.kryo.util.IdentityObjectIntMap.put(IdentityObjectIntMap.java:117) at com.esotericsoftware.kryo.util.MapReferenceResolver.addWrittenObject(MapReferenceResolver.java:23) at com.esotericsoftware.kryo.Kryo.writeReferenceOrNull(Kryo.java:598)

可能原因

  • Driver端OOM 把结果收集到Driver端并打印主要有两步,第一步:使用一个数组存储从各节点收集过来的结果,第二步转换成可打印的格式再打印到屏幕上。结果集在内存中是以java对象形式存在的,内存占用比较大,在转化格式的过程中还会生成很多中间数组,使得driver的内存耗费非常大,很容易出现OOM错误。
  • kryo序列化报NegativeArraySizeException错误 Spark对kryo一次序列化的数据大小进行了限制,最多一次序列化2G数据,超过这个限制就会报如上错误。

定位思路

无。

处理步骤

当出现如上问题时,建议可采用如下方法进行调整。

  • 结果集很大时,不要把结果集拿到driver端,建议将结果集落到磁盘中,避免出现OOM错误。
  • 如果已通过上述操作规避OOM错误,那么NegativeArraySizeException错误也不会出现。如果用户不执行上述建议规避错误,您也可以在Spark客户端配置文件“spark-defaults.conf”中设置序列化器spark.serializer = org.apache.spark.serializer.JavaSerializer,来规避出现NegativeArraySizeException错误。
作者 east
bug清单 2月 27,2021

Driver端返回大量结果数据时出现内存不足错误

Driver端返回大量结果数据时出现内存不足错误

现象描述

利用JDBCServer应用,在客户端执行SQL语句。Driver异常退出,在JDBCServer日志中报错信息如下:

2015-11-24 18:29:33,393 ERROR [org.apache.spark.util.Utils] Uncaught exception in thread task-result-getter-3
java.lang.OutOfMemoryError: Java heap space
    at java.io.ObjectInputStream$HandleTable.grow(ObjectInputStream.java:3469)
    at java.io.ObjectInputStream$HandleTable.assign(ObjectInputStream.java:3275)
    at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1674)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1345)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1993)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1918)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
    at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1707)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1345)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
    at org.apache.spark.serializer.JavaDeserializationStream.readObject(JavaSerializer.scala:72)
    at org.apache.spark.serializer.JavaSerializerInstance.deserialize(JavaSerializer.scala:92)
    at org.apache.spark.scheduler.DirectTaskResult.value(TaskResult.scala:97)
    at org.apache.spark.scheduler.TaskResultGetter$$anon$2$$anonfun$run$1.apply$mcV$sp(TaskResultGetter.scala:60)
    at org.apache.spark.scheduler.TaskResultGetter$$anon$2$$anonfun$run$1.apply(TaskResultGetter.scala:51)
    at org.apache.spark.scheduler.TaskResultGetter$$anon$2$$anonfun$run$1.apply(TaskResultGetter.scala:51)
    at org.apache.spark.util.Utils$.logUncaughtExceptions(Utils.scala:1701)
    at org.apache.spark.scheduler.TaskResultGetter$$anon$2.run(TaskResultGetter.scala:50)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

客户端的错误信息如图1:

图1 客户端报的错误


可能原因

分析日志可知,当运行“task-result-getter-3”线程时出现“Out-of-Memory”错误,即表示Driver端获取数据时出现内存不足,导致JDBCServer服务异常。

由于SQL查询的结果数据会返回Driver端,当查询结果数据较大时,会有大量数据返回到Driver。

返回数据的大小的上限由“spark.driver.maxResultSize”配置项控制,当返回结果数据量超过spark.driver.maxResultSize时,Job会抛出异常终止,但不会导致JDBCServer服务异常。在这个问题中,通过查看配置项可知,Driver端的内存为1GB,“spark.driver.maxResultSize”也是1GB,由于Driver进程中还有其他对象占用部分内存,所以在获取的数据量还没有达到“spark.driver.maxResultSize”时,Driver进程内存已经超过1GB从而发生内存溢出,导致JDBCServer服务异常退出。

定位思路

无。

处理步骤

出现该问题,可以通过两种方法修改:增加driver端的内存;控制返回driver端数据的大小。

  1. 根据具体的应用,修改driver端的内存大小,设置方法有如下两种:
    • 在CLASSPATH的“spark-defaults.conf”文件中添加spark.driver.memory 20g。
    • 在启动Spark应用时,命令行中添加:–driver-memory 20g。
  2. 为了减少Driver端出现out-of-memory的错误,您可以适当限制driver端的数据量使其在客户端即报错。 spark.driver.maxResultSize=256m 说明: 建议该配置项的值小于driver端的内存。
  3. 重新运行Spark应用,如上配置即生效。

参考信息

参考官网http://spark.apache.org/docs/latest/configuration.html,对“spark.driver.maxResultSize”配置项的介绍。

作者 east

上一 1 … 62 63 64 … 92 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?
  • 嵌入式电机:如何在低速和高负载状态下保持FOC(Field-Oriented Control)算法的电流控制稳定?
  • C++如何在插件式架构中使用反射实现模块隔离?
  • C++如何追踪内存泄漏(valgrind/ASan等)并定位到业务代码?
  • C++大型系统中如何组织头文件和依赖树?
  • 如何进行AUTOSAR模块的持续集成(CI)部署与版本控制?

文章归档

  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (42)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (4)
  • 大数据开发 (484)
    • CDH (6)
    • datax (4)
    • doris (28)
    • Elasticsearch (15)
    • Flink (78)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (40)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (99)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (9)
    • 运维 (33)
      • Docker (2)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (70)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (6)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.