sed*_*idw 5 python race-condition ioerror hdfs
所以我有一些代码试图在HDFS上找到一个资源...如果它不在那里它会计算该文件的内容,然后写它.下次访问时,阅读器可以查看文件.这是为了防止昂贵的重新计算某些功能
但是......我有几个进程同时在同一个集群上的不同机器上运行.我怀疑他们正在尝试访问相同的资源而且我遇到了一个竞争条件,导致很多错误我无法打开文件或文件存在但无法读取.
希望这个时间表能够证明我相信我的问题
显然,我希望进程B等待进程A完成资源X,并在A完成时简单地读取它.
我想到了信号量之类的信息,但我不知道如何在不同的python进程中使用这些信息来查看相同的HDFS位置.任何帮助将不胜感激
更新:要清楚..进程A和进程B将最终计算完全相同的输出(即相同的文件名,具有相同的内容,到同一位置).理想情况下,B不应该计算它.B将等待A计算它,然后在A完成后读取输出.从本质上讲,整个过程就像使用HDFS的"长期缓存"一样.给定函数将具有输出签名的位置.任何想要输出函数的进程都将首先确定输出签名(这基本上是一些函数参数,输入等的散列).然后它将检查HDFS以查看它是否存在.如果不是......它会写入计算并将其写入HDFS,以便其他进程也可以读取它.
(撇开听起来 HDFS 可能不是适合您的用例的正确解决方案不谈,我假设您无法切换到其他解决方案。如果可以,请看看 Redis 或 memcached。)
似乎在这种情况下,您应该有一个服务来负责计算/缓存这些结果。这样,您的所有流程必须做的就是请求创建资源(如果尚未创建)。如果尚未计算,服务将计算它;一旦计算出来(或者如果已经计算出来),就会向您的进程返回一个表示资源可用的信号,甚至只是资源本身。
如果由于某种原因你无法做到这一点,你可以尝试使用 HDFS 进行同步。例如,您可以尝试使用哨兵值创建资源,其中指示进程 A 当前正在构建此文件。同时,进程 A 可以计算该值并将其写入临时资源;一旦完成,它可以将临时资源移动到哨兵资源上。它既笨重又黑客,你应该尽量避免它,但它是一种选择。
您说您想避免昂贵的重新计算,但如果进程 B 正在等待进程 A 计算资源,为什么进程 B(以及 C 和 D)不能为自己计算资源?如果这对您来说没问题,那么如果资源尚不存在,您可以让每个进程开始计算并写入临时文件,然后将该文件移动到资源位置。希望行动是原子的,这样他们中的一个就能干净利落地获胜;如果它们都相同,那并不重要。一旦出现,将来就可以使用。这确实涉及多个进程同时向 HDFS 集群发送相同数据的可能性,因此它不是最有效的,但它有多糟糕取决于您的用例。例如,您可以通过在计算之后和上传到 HDFS 之前检查自您上次查看以来是否有其他人创建了该资源来减少效率低下;如果是这样,甚至不需要创建临时资源。
TLDR:您可以仅使用 HDFS 来完成此操作,但最好有一个服务来为您管理它,并且最好不要使用 HDFS(尽管您仍然可能需要一个服务来处理它)对于您来说,即使您使用的是 Redis 或 memcached;这再次取决于您的特定用例)。
| 归档时间: |
|
| 查看次数: |
112 次 |
| 最近记录: |