Esta página fornece práticas recomendadas para desenvolver e testar o pipeline do Dataflow.
Vista geral
A forma como o código do seu pipeline é implementado tem uma influência significativa no desempenho do pipeline em produção. Para ajudar a criar código de pipeline que funcione corretamente e de forma eficiente, este documento explica o seguinte:
- Executores de pipelines para suportar a execução de código nas diferentes fases de desenvolvimento e implementação.
- Ambientes de implementação que lhe permitem executar pipelines durante o desenvolvimento, os testes, a pré-produção e a produção.
- Código e modelos de pipeline de código aberto que pode usar tal como estão ou como base para novos pipelines para acelerar o desenvolvimento de código.
- Uma abordagem de práticas recomendadas para testar o código do pipeline. Primeiro, este documento fornece uma vista geral que inclui o âmbito e a relação dos diferentes tipos de testes, como testes unitários, testes de integração e testes completos. Em segundo lugar, cada tipo de teste é explorado em detalhe, incluindo métodos para criar e integrar com dados de teste, e que executores de pipeline usar para cada teste.
Corredores de pipelines
Durante o desenvolvimento e os testes, usa diferentes executores do Apache Beam para executar o código do pipeline. O SDK do Apache Beam oferece um Direct Runner para testes e desenvolvimento locais. As suas ferramentas de automatização de lançamentos também podem usar o Direct Runner para testes unitários e testes de integração. Por exemplo, pode usar o Direct Runner no seu pipeline de integração contínua (CI).
Os pipelines implementados no Dataflow usam o Dataflow Runner, que executa o pipeline em ambientes semelhantes aos de produção. Além disso, pode usar o Dataflow Runner para testes de desenvolvimento ad hoc e para testes de pipeline ponto a ponto.
Embora esta página se foque na execução de pipelines criados com o SDK Java do Apache Beam, o Dataflow também suporta pipelines do Apache Beam que foram desenvolvidos com Python e Go. Os SDKs Java, Python e Go do Apache Beam estão geralmente disponíveis para o Dataflow. Os programadores de SQL também podem usar o SQL do Apache Beam para criar pipelines que usam dialetos SQL familiares.
Configure um ambiente de implementação
Para separar utilizadores, dados, código e outros recursos em diferentes fases de desenvolvimento, crie ambientes de implementação. Sempre que possível, para fornecer ambientes isolados para os diferentes estágios do desenvolvimento do pipeline, use Google Cloud projetos separados.
As secções seguintes descrevem um conjunto típico de ambientes de implementação.
Ambiente local
O ambiente local é a estação de trabalho de um programador. Para o desenvolvimento e os testes rápidos, use o Direct Runner para executar o código do pipeline localmente.
Os pipelines executados localmente através do Direct Runner podem interagir com recursos remotos da Google Cloud Platform, como tópicos do Pub/Sub ou tabelas do BigQuery. Atribua aos programadores individuais Google Cloud projetos separados para que tenham uma área de testes para testes ad hoc com serviços da Google Cloud Platform.
Alguns Google Cloud serviços, como o Pub/Sub e o Bigtable, oferecem emuladores para desenvolvimento local. Pode usar estes emuladores com o Direct Runner para ativar o desenvolvimento e os testes locais ponto a ponto.
Ambiente de sandbox
O ambiente de sandbox é um Google Cloud projeto que oferece aos programadores acesso aos Google Cloud serviços durante o desenvolvimento de código. Os programadores de pipelines podem partilhar um Google Cloud projeto com outros programadores ou usar os seus próprios projetos individuais. A utilização de projetos individuais reduz a complexidade do planeamento relacionada com a utilização de recursos partilhados e a gestão de quotas.
Os programadores usam o ambiente de sandbox para executar pipelines ad hoc com o Dataflow Runner. O ambiente de sandbox é útil para depurar e testar código em relação a um executor de produção durante a fase de desenvolvimento de código. Por exemplo, a execução de pipelines ad hoc permite aos programadores fazer o seguinte:
- Observe o efeito das alterações ao código no comportamento de escalabilidade.
- Compreenda as potenciais diferenças entre o comportamento do DirectRunner e do DataflowRunner.
- Compreenda como o Dataflow aplica otimizações de grafos.
Para testes ad hoc, os programadores podem implementar código a partir do respetivo ambiente local para executar o Dataflow no ambiente de sandbox.
Ambiente de pré-produção
O ambiente de pré-produção destina-se a fases de desenvolvimento que precisam de ser executadas em condições semelhantes às de produção, como testes completos. Use um projeto separado para o ambiente de pré-produção e configure-o de forma a ser o mais semelhante possível ao ambiente de produção. Da mesma forma, para permitir testes ponto a ponto com uma escala semelhante à de produção, torne as Google Cloud quotas de projetos para o Dataflow e outros serviços o mais semelhantes possível ao ambiente de produção.
Consoante os seus requisitos, pode separar ainda mais a pré-produção em vários ambientes. Por exemplo, um ambiente de controlo de qualidade pode apoiar o trabalho dos analistas de qualidade para testar os objetivos de nível de serviço (SLOs), como a correção, a atualidade e o desempenho dos dados em diferentes condições de carga de trabalho.
Os testes ponto a ponto incluem a integração com origens e destinos de dados no âmbito dos testes. Considere como disponibilizá-los no ambiente de pré-produção. Pode armazenar dados de teste no próprio ambiente de pré-produção. Por exemplo, os dados de teste são armazenados num contentor do Cloud Storage com os seus dados de entrada. Noutros casos, os dados de teste podem ter origem fora do ambiente de pré-produção, como um tópico do Pub/Sub através de uma subscrição separada que se encontra no ambiente de produção. Para pipelines de streaming, também pode executar testes completos usando dados gerados, por exemplo, usando o gerador de dados de streaming do Dataflow para emular volumes e características de dados semelhantes aos de produção.
Para pipelines de streaming, use o ambiente de pré-produção para testar atualizações de pipelines antes de fazer alterações à produção. É importante testar e validar os procedimentos de atualização para pipelines de streaming, especialmente se precisar de coordenar vários passos, como quando executar pipelines paralelos para evitar o tempo de inatividade.
Ambiente de produção
O ambiente de produção é um projeto Google Cloud dedicado. A entrega contínua copia os artefactos de implementação para o ambiente de produção quando todos os testes ponto a ponto tiverem sido aprovados.
Práticas recomendadas de desenvolvimento
Consulte as práticas recomendadas para pipelines do Dataflow.
Teste o seu pipeline
No desenvolvimento de software, os testes de unidades, os testes de integração e os testes ponto a ponto são tipos comuns de testes de software. Estes tipos de testes também são aplicáveis a pipelines de dados.
O SDK Apache Beam oferece funcionalidades para ativar estes testes. Idealmente, cada tipo de teste segmenta um ambiente de implementação diferente. O diagrama seguinte ilustra como os testes unitários, os testes de integração e os testes ponto a ponto se aplicam a diferentes partes do seu pipeline e dados.
O diagrama mostra o âmbito de diferentes testes e a respetiva relação com as transformações (subclasses DoFn e PTransform), os pipelines, as origens de dados e os destinos de dados.
As secções seguintes descrevem como vários testes de software formais se aplicam a pipelines de dados que usam o Dataflow. À medida que lê esta secção, consulte o diagrama para compreender a relação entre os diferentes tipos de testes.
Amostragem de dados
Para observar os dados em cada passo de um pipeline do Dataflow, ative a amostragem de dados durante os testes. Isto permite-lhe ver os resultados das transformações para garantir que o resultado está correto.
Testes de unidades
Os testes unitários avaliam o funcionamento correto das subclasses DoFn e das
transformações compostas
(subclasses PTransform) comparando o resultado dessas transformações com um
conjunto verificado de entradas e saídas de dados. Normalmente, os programadores podem executar estes testes no ambiente local. Os testes também podem ser executados automaticamente através da automatização de testes unitários com a integração contínua (IC) no ambiente de criação.
O Direct Runner executa testes de unidades com um subconjunto mais pequeno de dados de teste de referência que se focam em testar a lógica empresarial das suas transformações. Os dados de teste têm de ser suficientemente pequenos para caberem na memória local da máquina que executa o teste.
O SDK do Apache Beam fornece uma regra JUnit denominada
TestPipeline
para testes unitários de transformações individuais (subclasses DoFn), transformações compostas (subclasses PTransform) e pipelines completos. Pode usar TestPipeline num
executador de pipeline do Apache Beam, como o executador direto ou o
executador do Dataflow, para aplicar afirmações sobre o conteúdo de objetos PCollection usando
PAssert, conforme mostrado no seguinte fragmento de código de uma
classe de teste JUnit:
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void myPipelineTest() throws Exception {
final PCollection<String> pcol = p.apply(...)
PAssert.that(pcol).containsInAnyOrder(...);
p.run();
}
Testes de unidades para transformações individuais
Ao fatorizar o código em transformações reutilizáveis, por exemplo, como classes aninhadas estáticas ou de nível superior, pode criar testes direcionados para diferentes partes do pipeline. Além das vantagens dos testes, as transformações reutilizáveis melhoram a capacidade de manutenção e a reutilização do código, encapsulando naturalmente a lógica empresarial do seu pipeline em partes componentes. Por outro lado, testar partes individuais do seu pipeline pode ser difícil se o pipeline usar classes internas anónimas para implementar transformações.
O fragmento de código Java seguinte mostra a implementação de transformações como classes internas anónimas, o que não permite testar facilmente.
PipelineOptions options = PipelineOptionsFactory.create();
Pipeline p = Pipeline.create(options)
PCollection<Integer> output =
p.apply("Read from text", TextIO.Read.from(...))
.apply("Split words", ParDo.of(new DoFn() {
// Untestable anonymous transform 1
}))
.apply("Generate anagrams", ParDo.of(new DoFn() {
// Untestable anonymous transform 2
}))
.apply("Count words", Count.perElement());
Compare o exemplo anterior com o seguinte, em que as classes internas anónimas são refatoradas em subclasses concretas DoFn com nome. Pode criar testes unitários individuais para cada subclasse DoFn concreta que compõe o pipeline ponto a ponto.
PipelineOptions options = PipelineOptionsFactory.create();
Pipeline p = Pipeline.create(options)
PCollection<Integer> output =
p.apply("Read from text", TextIO.Read.from(...))
.apply("Split words", ParDo.of(new SplitIntoWordsFn()))
.apply("Generate anagrams", ParDo.of(new GenerateAnagramsFn()))
.apply("Count words", Count.perElement());
Testar cada subclasse DoFn é semelhante a testar uma conduta de processamento em lote
que contém uma única transformação. Use a transformação Create para criar um objeto PCollection de dados de teste e, em seguida, transmita-o para o objeto DoFn. Use PAssert para afirmar que o conteúdo do objeto PCollection está correto. O exemplo de código Java seguinte usa a classe PAssert para verificar se o formulário de saída está correto.
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testGenerateAnagramsFn() {
// Create the test input
PCollection<String> words = p.apply(Create.of("friend"));
// Test a single DoFn using the test input
PCollection<String> anagrams =
words.apply("Generate anagrams", ParDo.of(new GenerateAnagramsFn()));
// Assert correct output from
PAssert.that(anagrams).containsInAnyOrder(
"finder", "friend", "redfin", "refind");
p.run();
}
Testes de integração
Os testes de integração validam o funcionamento correto de todo o seu pipeline. Considere os seguintes tipos de testes de integração:
- Um teste de integração de transformação que avalia a funcionalidade integrada de todas as transformações individuais que compõem o seu pipeline de dados. Pense nos testes de integração de transformações como um teste de unidade para toda a sua pipeline, excluindo a integração com origens de dados e destinos externos. O SDK do Apache Beam fornece métodos para fornecer dados de teste ao seu pipeline de dados e para validar os resultados do processamento. O Direct Runner é usado para executar testes de integração de transformações.
Um teste de integração do sistema que avalia a integração do seu pipeline de dados com origens e destinos de dados em direto. Para que o seu pipeline comunique com sistemas externos, tem de configurar os testes com as credenciais adequadas para aceder a serviços externos. Os pipelines de streaming são executados indefinidamente, pelo que tem de decidir quando e como parar o pipeline em execução. Ao usar o Direct Runner para executar testes de integração de sistemas, pode validar rapidamente a integração entre o seu pipeline e outros sistemas sem ter de enviar uma tarefa do Dataflow e esperar que termine.
Conceber testes de transformação e integração de sistemas para fornecer deteção e feedback rápidos de defeitos sem diminuir a produtividade dos programadores. Para testes de execução mais longa, como os que são executados como tarefas do Dataflow, recomendamos que use um teste completo que seja executado com menos frequência.
Pense numa pipeline de dados como uma ou mais transformações relacionadas. Pode criar uma transformação composta de encapsulamento para o seu pipeline e usar TestPipeline para fazer um teste de integração de todo o pipeline. Consoante queira testar o pipeline no modo de lote ou de streaming, fornece dados de teste através das transformações Create ou TestStream.
Use dados de teste para testes de integração
No ambiente de produção, o pipeline é provavelmente integrado com diferentes origens e destinos de dados. No entanto, para testes unitários e testes de integração de transformação, concentre-se na validação da lógica empresarial do código do pipeline, fornecendo entradas de teste e validando o resultado diretamente. Além de simplificar os testes, esta abordagem permite-lhe isolar problemas específicos do pipeline daqueles que podem ser causados por origens e destinos de dados.
Testar pipelines de processamento em lote
Para pipelines em lote, use a transformação Create para criar um objeto dos seus dados de teste de entrada a partir de uma coleção na memória padrão, como um objeto List Java.PCollection A utilização da transformação Create é adequada se os dados de teste forem suficientemente pequenos para serem incluídos no código. Em seguida, pode usar PAssert nos objetos de
saída PCollection para determinar a correção do código do pipeline.
Esta abordagem é suportada pelo Direct Runner e pelo Dataflow Runner.
O seguinte fragmento de código Java mostra asserções em objetos PCollection
de saída de uma transformação composta que inclui algumas ou todas as transformações
individuais que constituem um pipeline (WeatherStatsPipeline). A abordagem é
semelhante aos testes unitários de transformações individuais num pipeline.
private class WeatherStatsPipeline extends
PTransform<PCollection<Integer>, PCollection<WeatherSummary>> {
@Override
public PCollection<WeatherSummary> expand(PCollection<Integer> input) {
// Pipeline transforms …
}
}
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testWeatherPipeline() {
// Create test input consisting of temperature readings
PCollection<Integer> tempCelsius =
p.apply(Create.of(24, 22, 20, 22, 21, 21, 20));
// CalculateWeatherStats calculates the min, max, and average temperature
PCollection<WeatherSummary> result =
tempCelsius.apply("Calculate weather statistics", new WeatherStatsPipeline());
// Assert correct output from CalculateWeatherStats
PAssert.thatSingleton(result).isEqualTo(new WeatherSummary.Builder()
.withAverageTemp(21)
.withMaxTemp(24)
.withMinTemp(20)
.build());
p.run();
}
Para testar o comportamento de janelas, também pode usar a transformação Create para criar elementos com indicações de tempo, como mostrado no seguinte fragmento de código:
private static final Duration WINDOW_DURATION = Duration.standardMinutes(3);
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testWindowedData() {
PCollection<String> input =
p.apply(
Create.timestamped(
TimestampedValue.of("a", new Instant(0L)),
TimestampedValue.of("a", new Instant(0L)),
TimestampedValue.of("b", new Instant(0L)),
TimestampedValue.of("c", new Instant(0L)),
TimestampedValue.of("c", new Instant(0L).plus(WINDOW_DURATION)))
.withCoder(StringUtf8Coder.of()));
PCollection<KV<String, Long>> windowedCount =
input
.apply(Window.into(FixedWindows.of(WINDOW_DURATION)))
.apply(Count.perElement());
PAssert.that(windowedCount)
.containsInAnyOrder(
// Output from first window
KV.of("a", 2L),
KV.of("b", 1L),
KV.of("c", 1L),
// Output from second window
KV.of("c", 1L));
p.run();
}
Testar pipelines de streaming
Os pipelines de streaming contêm pressupostos que definem como processar dados ilimitados. Estas suposições referem-se frequentemente à oportunidade dos dados em condições do mundo real e, por isso, têm um impacto na exatidão, consoante as suposições se revelarem verdadeiras ou falsas. Os testes de integração para pipelines de streaming incluem, idealmente, testes que simulam a natureza não determinística da chegada de dados de streaming.
Para
ativar esses testes,
o SDK Apache Beam fornece a classe
TestStream
para modelar os efeitos das sincronizações de elementos (dados antecipados, dentro do prazo ou atrasados) nos
resultados do seu pipeline de dados. Use estes testes juntamente com a classe PAssert para validar os resultados esperados.
TestStream é suportado pelo Direct Runner e pelo Dataflow Runner. O exemplo de código seguinte cria uma TestStream
transform:
final Duration WINDOW_DURATION = Duration.standardMinutes(3);
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testDroppedLateData() {
TestStream<String> input = TestStream.create(StringUtf8Coder.of())
// Add elements arriving before the watermark
.addElements(
TimestampedValue.of("a", new Instant(0L)),
TimestampedValue.of("a", new Instant(0L)),
TimestampedValue.of("b", new Instant(0L)),
TimestampedValue.of("c", new Instant(0L).plus(Duration.standardMinutes(3))))
// Advance the watermark past the end of the window
.advanceWatermarkTo(new Instant(0L).plus(WINDOW_DURATION).plus(Duration.standardMinutes(1)))
// Add elements which will be dropped due to lateness
.addElements(
TimestampedValue.of("c", new Instant(0L)))
// Advance the watermark to infinity which will close all windows
.advanceWatermarkToInfinity();
PCollection<KV<String, Long>> windowedCount =
p.apply(input)
.apply(Window.into(FixedWindows.of(WINDOW_DURATION)))
.apply(Count.perElement());
PAssert.that(windowedCount)
.containsInAnyOrder(
// Output from first window
KV.of("a", 2L),
KV.of("b", 1L),
KV.of("c", 1L));
p.run();
}
Para mais informações sobre TestStream, consulte o artigo
Testar pipelines ilimitados no Apache Beam.
Para mais informações sobre como usar o SDK do Apache Beam para testes unitários, consulte a documentação do Apache Beam.
Use Google Cloud serviços em testes de integração
O Direct Runner pode integrar-se com os serviços Google Cloud , para que os testes ad hoc no ambiente local e os testes de integração do sistema possam usar o Pub/Sub, o BigQuery e outros serviços, conforme necessário. Quando usa o Direct Runner, o seu pipeline usa as credenciais padrão da aplicação (ADC) para obter credenciais. A forma como configura a ADC depende de onde o seu pipeline está a ser executado. Para mais informações, consulte o artigo Configure as Credenciais padrão da aplicação.
Tem de conceder autorizações suficientes à conta que a pipeline está a usar para quaisquer recursos necessários antes de executar a pipeline. Para ver mais detalhes, consulte o artigo Segurança e autorizações do Dataflow.
Para testes de integração totalmente locais, pode usar emuladores locais para algunsGoogle Cloud serviços. Os emuladores locais estão disponíveis para o Pub/Sub e o Bigtable.
Para testes de integração de sistemas de pipelines de streaming, pode usar o método setBlockOnRun (definido na interface DirectOptions) para que o Direct Runner execute o pipeline de forma assíncrona.
Caso contrário, a execução do pipeline bloqueia o processo principal de chamadas (por exemplo, um script no pipeline de compilação) até que o pipeline seja parado manualmente. Se executar o pipeline de forma assíncrona, pode usar a instância
PipelineResult devolvida para cancelar a execução do pipeline, conforme mostrado no seguinte exemplo de código:
public interface StreamingIntegrationTestOptions extends
DirectOptions, StreamingOptions, MyOtherPipelineOptions {
...
}
@Rule
public final transient TestPipeline p = TestPipeline.create();
@Test
@Category(NeedsRunner.class)
public void testNonBlockingPipeline() {
StreamingIntegrationTestOptions options =
p.getOptions().as(StreamingIntegrationOptions.class);
options.setBlockOnRun(false); // Set non-blocking pipeline execution
options.setStreaming(true); // Set streaming mode
p.apply(...); // Apply pipeline transformations
PipelineResult result = p.run(); // Run the pipeline
// Generate input, verify output, etc
...
// Later on, cancel the pipeline using the previously returned
result.cancel();
}
Testes ponto a ponto
Os testes ponto a ponto verificam o funcionamento correto do pipeline ponto a ponto executando-o no Dataflow Runner em condições que se assemelham muito à produção. Os testes verificam se a lógica empresarial funciona corretamente com o Dataflow Runner e testam se o pipeline tem o desempenho esperado em cargas semelhantes às de produção. Normalmente, executa testes completos num Google Cloud projeto dedicado designado como o ambiente de pré-produção.
Para testar o seu pipeline a diferentes escalas, use diferentes tipos de testes completos, por exemplo:
- Execute testes ponto a ponto em pequena escala com uma pequena proporção (como um por cento) do conjunto de dados de teste para validar rapidamente a funcionalidade do pipeline no ambiente de pré-produção.
- Execute testes ponto a ponto em grande escala com um conjunto de dados de teste completo para validar a funcionalidade do pipeline em condições e volumes de dados semelhantes aos de produção.
Para pipelines de streaming, recomendamos que execute pipelines de teste em paralelo com o pipeline de produção se puderem usar os mesmos dados. Este processo permite-lhe comparar os resultados e o comportamento operacional, como o dimensionamento automático e o desempenho.
Os testes completos ajudam a prever o desempenho do seu pipeline em relação aos SLOs de produção. O ambiente de pré-produção testa o seu pipeline em condições semelhantes às de produção. Nos testes completos, os pipelines são executados através do Dataflow Runner para processar conjuntos de dados de referência completos que correspondem ou se assemelham muito a conjuntos de dados em produção.
Pode não ser possível gerar dados sintéticos para testes que simulem com precisão dados reais. Para resolver este problema, uma abordagem consiste em usar extratos limpos de origens de dados de produção para criar conjuntos de dados de referência, nos quais todos os dados confidenciais são desidentificados através de transformações adequadas. Recomendamos que use a proteção de dados confidenciais para este fim. A proteção de dados confidenciais pode detetar dados confidenciais a partir de uma variedade de tipos de conteúdo e origens de dados, e aplicar uma variedade de técnicas de desidentificação, incluindo ocultação, mascaramento, encriptação de preservação de formato e alteração de datas.
Diferenças nos testes ponto a ponto para pipelines de streaming e em lote
Antes de executar um teste completo de extremo a extremo num grande conjunto de dados de teste, pode querer executar um teste com uma percentagem menor dos dados de teste (como um por cento) e verificar o comportamento esperado num período mais curto. Tal como
nos testes de integração com o Direct Runner, pode usar PAssert em
PCollection objetos quando executa pipelines com o
Dataflow Runner. Para mais informações sobre PAssert, consulte a secção
Testes unitários nesta página.
Consoante o seu exemplo de utilização, a validação de resultados muito grandes de testes completos pode ser impraticável, dispendiosa ou, de outra forma, desafiante. Nesse caso, pode validar amostras representativas do conjunto de resultados de saída. Por exemplo, pode usar o BigQuery para fazer uma amostragem e comparar linhas de saída com um conjunto de dados de referência de resultados esperados.
Para pipelines de streaming, a simulação de condições de streaming realistas com dados sintéticos pode ser desafiante. Uma forma comum de fornecer dados de streaming para testes ponto a ponto é integrar os testes com origens de dados de produção. Se estiver a usar o Pub/Sub como origem de dados, pode ativar um fluxo de dados separado para testes completos através de subscrições adicionais a tópicos existentes. Em seguida, pode comparar os resultados de diferentes pipelines que consomem os mesmos dados, o que é útil para validar pipelines candidatos em relação a outros pipelines de pré-produção e produção.
O diagrama seguinte mostra como este método permite que um pipeline de produção e um pipeline de teste sejam executados em paralelo em diferentes ambientes de implementação.
No diagrama, ambos os pipelines leem a partir do mesmo tópico do Pub/Sub, mas usam subscrições separadas. Esta configuração permite que os dois pipelines processem os mesmos dados de forma independente e permite-lhe comparar os resultados. O pipeline de teste usa uma conta de serviço separada do projeto de produção e, por isso, evita usar a quota de subscritores do Pub/Sub para o projeto de produção.
Ao contrário dos pipelines em lote, os pipelines de streaming continuam a ser executados até serem cancelados explicitamente. Nos testes ponto a ponto, tem de decidir se quer deixar o pipeline em execução, talvez até à execução do teste ponto a ponto seguinte, ou cancelar o pipeline num ponto que represente a conclusão do teste para poder inspecionar os resultados.
O tipo de dados de teste que usa influencia esta decisão. Por exemplo, se usar um conjunto limitado de dados de teste fornecidos ao pipeline de streaming, pode cancelar o pipeline quando todos os elementos tiverem concluído o processamento. Em alternativa, se usar uma origem de dados real, como um tópico do Pub/Sub existente que é usado na produção, ou se gerar dados de teste continuamente, pode querer manter os pipelines de teste em execução durante um período mais longo. Esta última opção permite-lhe comparar o comportamento com o ambiente de produção ou até com outros pipelines de teste.