超过 6 小时后，数据流作业失败并显示“工作人员与服务失去联系”？

【问题标题】：Dataflow job failed after more than 6 hours with "The worker lost contact with the service"?超过 6 小时后，数据流作业失败并显示“工作人员与服务失去联系”？
【发布时间】：2019-11-30 04:56:31
【问题描述】：

我正在使用Dataflow 从BigQuery 读取数据，然后使用python 进行NLP 预处理。我正在使用Python 3 和SDK 2.16.0。我正在使用 100 个工作人员（提供 IP、私有访问和云 NAT），工作人员位于 europe-west6 中，端点位于 europe-west1 中。 BigQuery 表位于 US 中。测试作业正常运行，但在尝试处理完整表 (32 GB) 时，作业在 6 小时 40 分钟后失败，很难完全理解潜在的错误。

首先由 Dataflow 报告以下内容： 这有点令人困惑：在一个案例中，工作项失败，另外 2 名工作人员与服务失去联系，一名工作人员被报告死亡！

现在让我们看看读取 BigQuery 数据的日志： 可疑的第一件事是在完整数据流作业期间每 3 秒出现一次消息“由于 401（尝试 1/2）而正在刷新”。我不认为这与崩溃有关，但这很奇怪。 BigQuery 问题的时间戳（16:28:07 和 16:28:15）出现在工作人员报告的问题（16:27:44）之后。

An exception was raised when trying to execute the workitem 7962803802081012962 : Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/dataflow_worker/batchworker.py", line 649, in do_work
    work_executor.execute()
  File "/usr/local/lib/python3.6/site-packages/dataflow_worker/executor.py", line 176, in execute
    op.start()
  File "dataflow_worker/native_operations.py", line 38, in dataflow_worker.native_operations.NativeReadOperation.start
  File "dataflow_worker/native_operations.py", line 39, in dataflow_worker.native_operations.NativeReadOperation.start
  File "dataflow_worker/native_operations.py", line 44, in dataflow_worker.native_operations.NativeReadOperation.start
  File "dataflow_worker/native_operations.py", line 48, in dataflow_worker.native_operations.NativeReadOperation.start
  File "/usr/local/lib/python3.6/site-packages/dataflow_worker/nativefileio.py", line 204, in __iter__
    for record in self.read_next_block():
  File "/usr/local/lib/python3.6/site-packages/dataflow_worker/nativeavroio.py", line 198, in read_next_block
    fastavro_block = next(self._block_iterator)
  File "fastavro/_read.pyx", line 738, in fastavro._read.file_reader.next
  File "fastavro/_read.pyx", line 662, in _iter_avro_blocks
  File "fastavro/_read.pyx", line 595, in fastavro._read.null_read_block
  File "fastavro/_read.pyx", line 597, in fastavro._read.null_read_block
  File "fastavro/_read.pyx", line 304, in fastavro._read.read_bytes
  File "/usr/local/lib/python3.6/site-packages/apache_beam/io/filesystemio.py", line 113, in readinto
    data = self._downloader.get_range(start, end)
  File "/usr/local/lib/python3.6/site-packages/apache_beam/io/gcp/gcsio.py", line 522, in get_range
    self._downloader.GetRange(start, end - 1)
  File "/usr/local/lib/python3.6/site-packages/apitools/base/py/transfer.py", line 486, in GetRange
    response = self.__ProcessResponse(response)
  File "/usr/local/lib/python3.6/site-packages/apitools/base/py/transfer.py", line 424, in __ProcessResponse
    raise exceptions.HttpError.FromResponse(response)
apitools.base.py.exceptions.HttpNotFoundError: HttpError accessing <https://www.googleapis.com/storage/v1/b/xxx/o/beam%2Ftemp%2Fstackoverflow-raphael-191119-084402.1574153042.687677%2F11710707918635668555%2F000000000009.avro?alt=media&generation=1574154204169350>: response: <{'x-guploader-uploadid': 'AEnB2UpgIuanY0AawrT7fRC_VW3aRfWSdrrTwT_TqQx1fPAAAUohVoL-8Z8Zw_aYUQcSMNqKIh5R2TulvgHHsoxLWo2gl6wUEA', 'content-type': 'text/html; charset=UTF-8', 'date': 'Tue, 19 Nov 2019 15:28:07 GMT', 'vary': 'Origin, X-Origin', 'expires': 'Tue, 19 Nov 2019 15:28:07 GMT', 'cache-control': 'private, max-age=0', 'content-length': '142', 'server': 'UploadServer', 'status': '404'}>, content <No such object: nlp-text-classification/beam/temp/stackoverflow-xxxx-191119-084402.1574153042.687677/11710707918635668555/000000000009.avro>

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/dataflow_worker/batchworker.py", line 649, in do_work
    work_executor.execute()
  File "/usr/local/lib/python3.6/site-packages/dataflow_worker/executor.py", line 176, in execute
    op.start()
  File "dataflow_worker/native_operations.py", line 38, in dataflow_worker.native_operations.NativeReadOperation.start
  File "dataflow_worker/native_operations.py", line 39, in dataflow_worker.native_operations.NativeReadOperation.start
  File "dataflow_worker/native_operations.py", line 44, in dataflow_worker.native_operations.NativeReadOperation.start
  File "dataflow_worker/native_operations.py", line 48, in dataflow_worker.native_operations.NativeReadOperation.start
  File "/usr/local/lib/python3.6/site-packages/dataflow_worker/nativefileio.py", line 204, in __iter__
    for record in self.read_next_block():
  File "/usr/local/lib/python3.6/site-packages/dataflow_worker/nativeavroio.py", line 198, in read_next_block
    fastavro_block = next(self._block_iterator)
  File "fastavro/_read.pyx", line 738, in fastavro._read.file_reader.next
  File "fastavro/_read.pyx", line 662, in _iter_avro_blocks
  File "fastavro/_read.pyx", line 595, in fastavro._read.null_read_block
  File "fastavro/_read.pyx", line 597, in fastavro._read.null_read_block
  File "fastavro/_read.pyx", line 304, in fastavro._read.read_bytes
  File "/usr/local/lib/python3.6/site-packages/apache_beam/io/filesystemio.py", line 113, in readinto
    data = self._downloader.get_range(start, end)
  File "/usr/local/lib/python3.6/site-packages/apache_beam/io/gcp/gcsio.py", line 522, in get_range
    self._downloader.GetRange(start, end - 1)
  File "/usr/local/lib/python3.6/site-packages/apitools/base/py/transfer.py", line 486, in GetRange
    response = self.__ProcessResponse(response)
  File "/usr/local/lib/python3.6/site-packages/apitools/base/py/transfer.py", line 424, in __ProcessResponse
    raise exceptions.HttpError.FromResponse(response)
apitools.base.py.exceptions.HttpNotFoundError: HttpError accessing <https://www.googleapis.com/storage/v1/b/xxxx/o/beam%2Ftemp%2Fstackoverflow-raphael-191119-084402.1574153042.687677%2F11710707918635668555%2F000000000009.avro?alt=media&generation=1574154204169350>: response: <{'x-guploader-uploadid': 'AEnB2UpgIuanY0AawrT7fRC_VW3aRfWSdrrTwT_TqQx1fPAAAUohVoL-8Z8Zw_aYUQcSMNqKIh5R2TulvgHHsoxLWo2gl6wUEA', 'content-type': 'text/html; charset=UTF-8', 'date': 'Tue, 19 Nov 2019 15:28:07 GMT', 'vary': 'Origin, X-Origin', 'expires': 'Tue, 19 Nov 2019 15:28:07 GMT', 'cache-control': 'private, max-age=0', 'content-length': '142', 'server': 'UploadServer', 'status': '404'}>, content <No such object: nlp-text-classification/beam/temp/stackoverflow-xxxx-191119-084402.1574153042.687677/11710707918635668555/000000000009.avro>
timestamp   
2019-11-19T15:28:07.770312309Z
logger  
root:batchworker.py:do_work
severity    
ERROR
worker  
stackoverflow-xxxx-191-11190044-7wyy-harness-2k89
step    
Read Posts from BigQuery
thread  
73:140029564072960

工人似乎在 Cloud Storage 上找不到一些 avro 文件。这可能与消息“工作人员与服务失去联系”有关

如果我查看“错误”，我会看到很多这样的问题，因此工人本身似乎遇到了问题：

查看Stack Traces 并没有给出更多提示。

我的问题如下：

  1. 我们如何确定问题与工人有关？
  2. 可能是什么原因？记忆 ？磁盘？还是暂时性问题？
  3. 如果工人死亡，是否有恢复的选项？为什么全部工作停止是 3/98 工人死亡或迷路？有那个参数吗？

我们的设置：

  • 每个 VM 50 GB 磁盘（我认为其余的都使用默认参数）
  • DISKS_TOTAL_GB：6144
  • 与 CPU 相关的其他配额，以拥有 100 名工作人员。其余都是默认的私有用户参数

我们使用 Stackdriver 监控了一些数量，但在我看来没有任何问题：

【问题讨论】：

    标签： python google-cloud-platform google-bigquery google-cloud-dataflow spacy


    【解决方案1】：

    不使用 Dataflow Shuffle 的 Batch 作业的默认值为 250GB，因此您的 50GB 设置为需要存储在工作器上的任何 shuffle 数据留下的空间非常小。

    很高兴看到您的管道形状（涉及哪些步骤），但根据日志屏幕截图，您有 4 个步骤（从 BQ 读取、预处理、写入 BQ，还写入 GCS）。我还看到了一些 GroupBy 操作。 GroupBy 操作将需要 shuffle，并且您的 50GB 磁盘可能会限制存储。

    您应该尝试以下方法： - 不要将 Workers 限制为 50GB（删除 diskGB 设置，以便 Dataflow 可以使用默认值） - 尝试数据流随机播放（--experiments=shuffle_mode=service） 见https://cloud.google.com/dataflow/docs/guides/deploying-a-pipeline#dataflow-shuffle

    当您使用 Dataflow Shuffle 时，diskGB 参数的默认值为 30GB。然后你可以使用小磁盘（我仍然建议不要自己设置diskGBSize）

    【讨论】：

    • 谢谢，是的，我会尝试使用每个 VM 250 GB。我无法尝试 Dataflow Shuffle，因为我在 europe-west6 中获得了 25 TB 磁盘的所有配额（如果我做对了）。繁重的 python 处理在第二步中完成，其中 NLP 预处理对可能非常排序或非常长的文本进行。我认为它解释了为什么我得到“在状态进程-毫秒 ub 步骤 s2 中处理超过 600 秒的暂停”。有没有办法调整这个参数？或者这不是一个好兆头。在整个 6 小时的处理过程中，我收到了很多这样的消息
    • 有没有一种方法可以将您的 bigquery 表的数据从美国复制到欧洲？根据数据的大小，这可能是一个缓慢的过程，因为大量数据将通过网络传输。我建议作为流程的一部分，将表从 BQ 导出到美国的 GCS 存储桶 --> 从 GCS US 复制到欧洲 --> 将数据上传到 BQ Europe，然后运行该作业。我们可以隔离问题，看看是网络问题还是数据流问题。
    • 对每个 VM 使用默认的 250 GB 并不能解决问题。某处有问题，现阶段我不相信这与网络有关。似乎 Dataflow 开始处理 8M 条目。然后从 8M 开始 2 小时后，它下降到 400 万，所以一半的工作没有成功或被杀死。日志中没有任何内容。只有大量同时出现的消息“Processing lull for over xxx seconds in state process-msecs in step s2”。制作更多监控图以了解问题。 SpaCy 可能非常非常慢，可能是问题
    • 问题是 Spacy 的内存泄漏。稍后我会发布更多详细信息。
    【解决方案2】：

    经过一些测试和几个监控图之后，很明显，即使文本的长度是同一时间，处理时间也开始迅速增加（右下图）

    然后很明显问题出在 SpaCy 2.1.8（内存泄漏）。

    使用 Spacy 2.2.3 解决此问题。现在 32 Gb 的数据在 4h30 处理，没有任何问题。

    【讨论】：

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-02-12
      • 2018-02-07
      • 2023-01-09
      • 1970-01-01
      • 2021-12-01
      • 2020-08-05
      相关资源
      最近更新 更多
      热门标签
      Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode