Question

我有一个Dataflow作业，它从pubsub读取数据，并根据时间和文件名将内容写入GCS，其中文件夹路径基于YYYY / MM / DD。这样可以根据日期在文件夹中生成文件，并使用apache Beam的FileIO和Dynamic Destinations。

大约两周前，我注意到未确认消息的异常堆积。重新启动df作业后，错误消失了，新文件正在GCS中写入。

几天后，写入再次停止，除了这次以外，出现了一些错误，声称处理卡住了。经过一些值得信赖的SO研究之后，我发现在2.90之前的Beam中出现死锁问题很可能caused，因为它使用Conscrypt库作为默认的安全提供程序。因此，我从Beam 2.8升级到Beam 2.11。

它再次起作用，直到没有起作用。我仔细查看了该错误，发现该错误与SimpleDateFormat对象有关，该对象不是线程安全的。因此，我切换为使用Java.time和DateTimeFormatter，这是线程安全的。它一直工作到没有。但是，这次，错误稍有不同，并且没有指向我的代码中的任何内容：错误在下面提供。

Processing stuck in step FileIO.Write/WriteFiles/WriteShardedBundlesToTempFiles/WriteShardsIntoTempFiles for at least 05m00s without outputting or completing in state process
  at sun.misc.Unsafe.park(Native Method)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at org.apache.beam.vendor.guava.v20_0.com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:469)
  at org.apache.beam.vendor.guava.v20_0.com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:76)
  at org.apache.beam.runners.dataflow.worker.MetricTrackingWindmillServerStub.getStateData(MetricTrackingWindmillServerStub.java:202)
  at org.apache.beam.runners.dataflow.worker.WindmillStateReader.startBatchAndBlock(WindmillStateReader.java:409)
  at org.apache.beam.runners.dataflow.worker.WindmillStateReader$WrappedFuture.get(WindmillStateReader.java:311)
  at org.apache.beam.runners.dataflow.worker.WindmillStateReader$BagPagingIterable$1.computeNext(WindmillStateReader.java:700)
  at org.apache.beam.vendor.guava.v20_0.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145)
  at org.apache.beam.vendor.guava.v20_0.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140)
  at org.apache.beam.vendor.guava.v20_0.com.google.common.collect.MultitransformedIterator.hasNext(MultitransformedIterator.java:47)
  at org.apache.beam.sdk.io.WriteFiles$WriteShardsIntoTempFilesFn.processElement(WriteFiles.java:701)
  at org.apache.beam.sdk.io.WriteFiles$WriteShardsIntoTempFilesFn$DoFnInvoker.invokeProcessElement(Unknown Source)

此错误开始于作业部署大约5小时后发生，并且随着时间的流逝而增加。 24小时内书写速度显着下降。我有60名工人，我怀疑每次出现错误都会导致一名工人失败，最终导致工作中断。

在我的作家中，我分析了某些关键字的行（可能不是最好的方法），以确定其所属的文件夹。然后，我将使用确定的文件名将文件插入GCS。这是我为写手使用的代码：

分区功能如下：

@SuppressWarnings("serial")
public static class datePartition implements SerializableFunction<String, String> {     
    private String filename;

    public datePartition(String filename) {
        this.filename = filename;
    }

    @Override
    public String apply(String input) {

        String folder_name = "NaN";             
        String date_dtf    = "NaN";     
        String date_literal = "NaN";
        try {
            Matcher foldernames = Pattern.compile("\"foldername\":\"(.*?)\"").matcher(input);
            if(foldernames.find()) {
                folder_name = foldernames.group(1);
            }
            else {
                Matcher folderid = Pattern.compile("\"folderid\":\"(.*?)\"").matcher(input);
                if(folderid.find()) {
                    folder_name = folderid.group(1);
                }   
            }

            Matcher date_long = Pattern.compile("\"timestamp\":\"(.*?)\"").matcher(input);
            if(date_long.find()) {
                date_literal = date_long.group(1);
                if(Utilities.isNumeric(date_literal)) {
                    LocalDateTime date = LocalDateTime.ofInstant(Instant.ofEpochMilli(Long.valueOf(date_literal)), ZoneId.systemDefault());
                    date_dtf = date.format(dtf);                        
                }
                else {
                    date_dtf = date_literal.split(":")[0].replace("-", "/").replace("T", "/");
                }
            }
            return folder_name + "/" + date_dtf + "h/" + filename;
        }

        catch(Exception e) {
            LOG.error("ERROR with either foldername or date");
            LOG.error("Line : " + input);
            LOG.error("folder : " + folder_name);
            LOG.error("Date : " + date_dtf);

            return folder_name + "/" + date_dtf + "h/" + filename;
        }           
    }
}

管道的实际部署和运行位置可以在下面找到：

public void streamData() {

    Pipeline pipeline = Pipeline.create(options);
    pipeline.apply("Read PubSub Events", PubsubIO.readMessagesWithAttributes().fromSubscription(options.getInputSubscription()))
            .apply(options.getWindowDuration() + " Window",
                        Window.<PubsubMessage>into(FixedWindows.of(parseDuration(options.getWindowDuration())))
                                  .triggering(AfterWatermark.pastEndOfWindow()) 
                                  .discardingFiredPanes()
                                  .withAllowedLateness(parseDuration("24h")))
                .apply(new GenericFunctions.extractMsg())
                .apply(FileIO.<String, String>writeDynamic()
                                 .by(new datePartition(options.getOutputFilenamePrefix()))
                                 .via(TextIO.sink())
                                 .withNumShards(options.getNumShards())
                                 .to(options.getOutputDirectory())
                                 .withNaming(type -> FileIO.Write.defaultNaming(type, ".txt"))
                                 .withDestinationCoder(StringUtf8Coder.of()));

    pipeline.run();
}

Answer 1

错误“正在处理卡住...”表示某些特定操作花费了超过5m的时间，而不是作业被永久卡住。但是，由于步骤FileIO.Write / WriteFiles / WriteShardedBundlesToTempFiles / WriteShardsIntoTempFiles是卡住的，并且作业被取消/杀死，因此我认为在作业写入临时文件时会遇到一个问题。

我发现了BEAM-7689问题，该问题与用于写入临时文件的第二粒度时间戳（yyyy-MM-dd_HH-mm-ss）有关。发生这种情况是因为多个并发作业可以共享同一个临时目录，并且这可能导致其中一个作业在其他作业完成之前将其删除。

根据上一个链接，为缓解此问题，请升级到SDK 2.14。并让我们知道错误是否消失。

Answer 2

自发布此问题以来，我已经优化了数据流作业以规避瓶颈并增加并行化。就像rsantiago解释的那样，处理卡住不是错误，而只是数据流传达的一种信息表示一个步骤所花的时间比其他步骤长得多，这实质上是瓶颈，而使用给定的资源则无法清除。我所做的更改似乎已经解决了它们。新代码如下：

public void streamData() {

        try {
            Pipeline pipeline = Pipeline.create(options);

            pipeline.apply("Read PubSub Events", PubsubIO.readMessagesWithAttributes().fromSubscription(options.getInputSubscription()))
            .apply(options.getWindowDuration() + " Window",
                    Window.<PubsubMessage>into(FixedWindows.of(parseDuration(options.getWindowDuration())))
                          .triggering(AfterWatermark.pastEndOfWindow()) 
                          .discardingFiredPanes()
                          .withAllowedLateness(parseDuration("24h")))
            .apply(FileIO.<String,PubsubMessage>writeDynamic()
                    .by(new datePartition(options.getOutputFilenamePrefix()))
                    .via(Contextful.fn(
                            (SerializableFunction<PubsubMessage, String>) inputMsg -> new String(inputMsg.getPayload(), StandardCharsets.UTF_8)),
                            TextIO.sink())
                    .withDestinationCoder(StringUtf8Coder.of())
                    .to(options.getOutputDirectory())
                    .withNaming(type -> new CrowdStrikeFileNaming(type))
                    .withNumShards(options.getNumShards())
                    .withTempDirectory(options.getTempLocation()));

            pipeline.run();
        }

        catch(Exception e) {

            LOG.error("Unable to deploy pipeline");
            LOG.error(e.toString(), e);
        }

    }

最大的更改涉及删除extractMsg（）函数并将分区更改为仅使用元数据。这两个步骤都强制对消息进行反序列化/反序列化，并严重影响了性能。

此外，由于我的数据集是无界的，因此我必须设置一个非零数量的分片。我想简化我的文件命名策略，因此我将其设置为1，却不知道会对性能造成多大影响。从那时起，我发现我的工作在工人/碎片/机器类型之间保持了良好的平衡（不幸的是，大多数情况下都是基于猜测和检查）。

尽管仍然有可能在数据负载足够大的情况下发现瓶颈，但尽管负载很大（每天3-5tb），但管道仍表现良好。这些更改还大大改善了自动缩放比例，但我不确定为什么。现在，数据流作业对峰值和谷值的反应更快。

数据流中动态目标的问题

2 个答案: