Pyspark Dataproc上的Spark流式数据管道遇到突然频繁的套接字超时

我在Google Cloud Dataproc上使用Spark streaming来执行一个框架（用Python编写），该框架由几个连续的管道组成，每个管道代表Dataproc上的一个作业，基本上从Kafka队列读取数据，并将转换后的输出写入Bigtable。所有管道通过两个集群每天处理数GB的数据，一个集群有3个工作节点，另一个集群有4个工作节点

在Dataproc上运行这个Spark streaming框架一直相当稳定，直到5月初（确切地说是5月3日）：我们开始频繁遇到套接字超时异常，终止了我们的管道。它似乎与集群上的负载无关，因为它没有显著增加。它也会在一天中随机发生，我已经检查了可能相关的代码更改，但我找不到任何更改。此外，这似乎只发生在具有4个工作节点的集群上，而具有3个节点的集群上的管道非常相似，根本没有超时。我已经两次重新创建集群，但问题仍然存在，它会影响此dataproc集群上运行的所有管道。有3个节点的集群是

n1-standard-4

机器类型，而有4个节点的麻烦集群是

n1-standard-8

机器类型，但它们的配置相同

出现问题且作业终止时管道作业执行的示例输出：

java.net.SocketTimeoutException: Accept timed out
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
    at java.net.ServerSocket.implAccept(ServerSocket.java:545)
    at java.net.ServerSocket.accept(ServerSocket.java:513)
    at org.apache.spark.api.python.PythonRDD$$anon$2.run(PythonRDD.scala:645)
16/05/23 14:45:45 ERROR org.apache.spark.streaming.scheduler.JobScheduler: Error running job streaming job 1464014740000 ms.0
org.apache.spark.SparkException: An exception was raised by Python:
Traceback (most recent call last):
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/streaming/util.py", line 65, in call
    r = self.func(t, *rdds)
  File "/tmp/b85990ba-e152-4d5b-8977-fb38915e78c4/transformfwpythonfiles.zip/transformationsframework/StreamManager.py", line 138, in process_kafka_rdd
    .foreach(lambda *args: None)
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/rdd.py", line 747, in foreach
    self.mapPartitions(processPartition).count()  # Force evaluation
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/rdd.py", line 1004, in count
    return self.mapPartitions(lambda i: [sum(1 for _ in i)]).sum()
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/rdd.py", line 995, in sum
    return self.mapPartitions(lambda x: [sum(x)]).fold(0, operator.add)
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/rdd.py", line 869, in fold
    vals = self.mapPartitions(func).collect()
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/rdd.py", line 772, in collect
    return list(_load_from_socket(port, self._jrdd_deserializer))
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/rdd.py", line 142, in _load_from_socket
    for item in serializer.load_stream(rf):
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/serializers.py", line 139, in load_stream
    yield self._read_with_length(stream)
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/serializers.py", line 156, in _read_with_length
    length = read_int(stream)
  File "/usr/lib/spark/python/lib/pyspark.zip/pyspark/serializers.py", line 543, in read_int
    length = stream.read(4)
  File "/usr/lib/python2.7/socket.py", line 380, in read
    data = self._sock.recv(left)
timeout: timed out

---

stacktrace的开始在我们的

StreamManager

模块中，方法处理\u kafka\u rdd：它处理kafka消息直接流中的单个离散rdd。我们将卡夫卡与Spark streaming相结合是基于

中所述的“直接方法”。根据我对Spark和socket错误的经验，一些执行者突然死亡。当时与它通信的其他执行器引发套接字错误

根据我的经验，遗嘱执行人意外死亡的原因是资源匮乏，通常是内存不足

（调整执行器可以使用的内存量很重要。默认值通常太低。但我怀疑您已经意识到了这一点。）

---

我猜Spark是在纱线上运行的？不幸的是，根据我的经验，Spark在报告问题发生的原因时做得很差。不幸的是，我们必须深入细纱日志，找出究竟是什么导致了执行者的突然死亡。每个执行器都在一个纱线“容器”中运行；纱线日志中的某个地方应该有一个容器掉落的记录。

发生错误时，您拥有多少消费者和分区？