Questa pagina fornisce le best practice per sviluppare e testare la pipeline Dataflow.
Panoramica
Il modo in cui il codice per la tua pipeline viene implementato ha un influenza le prestazioni della pipeline in produzione. Per aiutarti a creare che funzioni in modo corretto ed efficiente, questo documento illustra seguenti:
- Runner della pipeline per supportare l'esecuzione del codice nelle diverse fasi delle attività di sviluppo e deployment.
- Ambienti di deployment che ti consentono di eseguire pipeline durante lo sviluppo, test, preproduzione e produzione.
- Codice e modelli di pipeline open source che puoi usare così come sono o come base per nuove pipeline per accelerare lo sviluppo del codice.
- Un approccio basato sulle best practice per testare il codice della pipeline. Innanzitutto, fornisce una panoramica che include l'ambito e la relazione diversi tipi di test, come test delle unità, test di integrazione ed end-to-end test. In secondo luogo, ogni tipo di test viene analizzato in dettaglio, inclusi i metodi da creare e integrare con i dati di test e quali runner della pipeline utilizzare per ogni test.
Runner della pipeline
Durante lo sviluppo e il test, utilizzi diversi runner Apache Beam per eseguire del codice della pipeline. L'SDK Apache Beam fornisce Corsa diretta per lo sviluppo e i test locali. Gli strumenti di automazione delle release possono anche Direct Runner per i test delle unità e i test di integrazione. Ad esempio, puoi utilizzare il Direct Runner integrazione continua (CI) una pipeline o un blocco note personalizzato.
Le pipeline di cui viene eseguito il deployment in Dataflow utilizzano Dataflow Runner che esegue la pipeline in ambienti simili a quelli di produzione. Inoltre, puoi utilizzare Dataflow Runner per test di sviluppo ad hoc e per i test end-to-end della pipeline.
Anche se questa pagina è incentrata sull'esecuzione delle pipeline create utilizzando L'SDK Java Apache Beam, Dataflow supporta anche le pipeline Apache Beam che sono state sviluppate utilizzando Python e Go. Gli SDK Apache Beam Java, Python e Go generalmente disponibile per Dataflow. Gli sviluppatori SQL possono anche SQL Apache Beam per creare pipeline che usano dialetti SQL familiari.
configura un ambiente di deployment
Per separare utenti, dati, codice e altre risorse in diverse fasi e lo sviluppo di applicazioni, creare ambienti di deployment. Se possibile, per fornire ambienti isolati per le diverse fasi della pipeline di sviluppo, usa istanze Progetti Google Cloud.
Le sezioni seguenti descrivono un set tipico di ambienti di deployment.
Ambiente locale
L'ambiente locale è la workstation di uno sviluppatore. Per uno sviluppo rapido usa Direct Runner per eseguire il codice della pipeline in locale.
Le pipeline eseguite localmente utilizzando Direct Runner possono interagire da risorse Google Cloud remote, ad esempio argomenti Pub/Sub e tabelle BigQuery. Concedi ai singoli sviluppatori progetti Google Cloud, in modo da disporre di una sandbox per i test ad hoc con servizi Google Cloud.
Alcuni servizi Google Cloud, Pub/Sub e Bigtable fornire emulatori per lo sviluppo locale. Puoi usare questi emulatori Direct Runner per abilitare sviluppo e test locali end-to-end.
Ambiente sandbox
L'ambiente sandbox è un progetto Google Cloud che offre agli sviluppatori ai servizi Google Cloud durante lo sviluppo del codice. Pipeline gli sviluppatori possono condividere un progetto Google Cloud con altri sviluppatori o utilizzare singoli progetti. L'utilizzo di singoli progetti riduce la complessità della pianificazione e riguardano l'utilizzo condiviso delle risorse e la gestione delle quote.
Gli sviluppatori utilizzano l'ambiente sandbox per eseguire l'esecuzione della pipeline ad hoc con Esecutore Dataflow. L'ambiente sandbox è utile per eseguire il debug e testare il codice su un di produzione durante la fase di sviluppo del codice. Per Ad esempio, l'esecuzione di pipeline ad hoc consente agli sviluppatori di fare quanto segue:
- Osserva l'effetto delle modifiche al codice sul comportamento di scalabilità.
- Comprendere le potenziali differenze tra il comportamento dell'annuncio Runner e Dataflow Runner.
- Scopri come si applica Dataflow ottimizzazioni dei grafici.
Per i test ad hoc, gli sviluppatori possono eseguire il deployment del codice dal proprio ambiente locale per eseguire Dataflow all'interno del loro ambiente sandbox.
Ambiente di preproduzione
L'ambiente di preproduzione è destinato alle fasi di sviluppo che devono essere eseguite in in condizioni simili a quelle della produzione, come i test end-to-end. Utilizza un progetto separato per l'ambiente di preproduzione e configurarlo in modo che sia simile alla produzione il più possibile. Analogamente, per consentire test end-to-end su una scala simile a quella di produzione, creare quote di progetto Google Cloud per Dataflow e altri il più simile possibile all'ambiente di produzione.
A seconda dei tuoi requisiti, puoi separare ulteriormente la preproduzione in più ambienti. Ad esempio, un ambiente di controllo qualità può supportare Il lavoro degli analisti della qualità per testare gli obiettivi del livello di servizio (SLO) come la correttezza, l'aggiornamento e le prestazioni dei dati in diversi carichi di lavoro conditions.
Test end-to-end includere l'integrazione con origini dati e sink nell'ambito dei test. Valuta come renderli disponibili nell'ambiente di pre-produzione. Puoi archiviare i dati di test nello stesso ambiente di preproduzione. Ad esempio: i dati di test sono archiviati in un bucket Cloud Storage insieme ai dati di input. In altre casi, i dati di test potrebbero provenire al di fuori dell'ambiente di preproduzione, ad esempio un argomento Pub/Sub tramite una sottoscrizione separata nell'ambiente di produzione. Per le pipeline in modalità flusso, puoi anche test end-to-end utilizzando dati generati, ad esempio utilizzando l'API Dataflow Generatore di dati in modalità flusso per emulare caratteristiche e volumi dei dati simili a quelli di produzione.
Per le pipeline in modalità flusso, utilizza l'ambiente di preproduzione per testare aggiornamenti della pipeline prima che vengano apportate modifiche alla produzione. È importante testare e verificare le procedure di aggiornamento per le pipeline in modalità flusso, in particolare se devi coordinare più passaggi, ad esempio quando eseguendo pipeline parallele per evitare tempi di inattività.
Ambiente di produzione
L'ambiente di produzione è un progetto Google Cloud dedicato. Distribuzione continua copia gli artefatti di deployment nell'ambiente di produzione quando test superati.
Best practice per lo sviluppo
Consulta le best practice per la pipeline Dataflow.
Testa la pipeline
Per quanto riguarda lo sviluppo del software, i test delle unità, i test di integrazione e i test end-to-end sono tipi comuni di test di software. Questi tipi di test sono applicabili anche pipeline di dati.
L'SDK Apache Beam fornisce le funzionalità per abilitare questi test. L'ideale è ogni tipo di test ha come target un ambiente di deployment diverso. Le seguenti il diagramma illustra come i test delle unità, i test di integrazione e i test end-to-end si applicano a parti diverse della pipeline e dei dati.
Il diagramma mostra l'ambito dei diversi test e la loro relazione
trasformazioni (DoFn e PTransform sottoclassi), pipeline, origini dati
e data sink di dati.
Le seguenti sezioni descrivono come i vari test formali del software si applicano ai dati pipeline di dati con Dataflow. Mentre leggi questa sezione, consulta: torna al diagramma per comprendere la correlazione tra i diversi tipi di test.
Campionamento dei dati
Per osservare i dati in ogni passaggio di una pipeline Dataflow, il campionamento dei dati durante il test. Questo consente di visualizzare gli output delle trasformazioni, per garantire che siano corretti.
Test delle unità
I test delle unità valutano il corretto funzionamento di DoFn sottoclassi e
trasformazioni composte
(PTransform sottoclassi) confrontando l'output di queste trasformazioni con una
un set verificato di input e output di dati. Di solito, gli sviluppatori possono eseguire
di test nell'ambiente locale. I test possono anche essere eseguiti automaticamente
automazione dei test delle unità utilizzando l'integrazione continua (CI) nella build
completamente gestito di Google Cloud.
Direct Runner esegue i test delle unità utilizzando un sottoinsieme di riferimenti più piccolo Testare i dati incentrati sul test della logica di business delle trasformazioni. La i dati di test devono essere sufficientemente ridotti da poter essere inseriti nella memoria locale sulla macchina esegue il test.
L'SDK Apache Beam fornisce una regola JUnit denominata
TestPipeline
per le trasformazioni individuali per il test delle unità (DoFn sottoclassi), le trasformazioni composte
(PTransform sottoclassi) e intere pipeline. Puoi usare TestPipeline su un
runner pipeline Apache Beam, come Direct Runner o
Dataflow Runner per applicare le asserzioni sui contenuti di
PCollection oggetti utilizzando
PAssert,
come mostrato nel seguente snippet di codice di
Classe test 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();
}
Test delle unità per trasformazioni individuali
Considerando il codice in trasformazioni riutilizzabili, ad esempio come trasformazioni di primo livello o classi nidificate statiche, puoi creare test mirati per parti diverse della tua pipeline. Oltre ai vantaggi dei test, le trasformazioni riutilizzabili migliorano la manutenibilità e la riutilizzabilità del codice integrando naturalmente l'attività della logica della pipeline in componenti. Al contrario, il test di singole parti della pipeline potrebbero essere difficili se la pipeline utilizza query per implementare le trasformazioni.
Il seguente snippet Java mostra l'implementazione delle trasformazioni in forma anonima che non consentono facilmente test.
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());
Confronta l'esempio precedente con quello seguente, in cui l'interno anonimo
vengono trasformate in sottoclassi DoFn concrete denominate. Puoi creare
alle singole unità di misura per ogni sottoclasse DoFn concreta che costituisce
una pipeline end-to-end.
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());
Il test di ogni sottoclasse DoFn è simile al test delle unità su un batch
contenente una singola trasformazione. Usa la trasformazione Create per
crea un oggetto PCollection dei dati di test e poi passalo all'oggetto DoFn
. Utilizza PAssert per affermare che i contenuti di PCollection
sono corrette. Il seguente esempio di codice Java utilizza la classe PAssert per
verifica che il modulo di output sia corretto.
@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();
}
Test di integrazione
I test di integrazione verificano il corretto funzionamento dell'intera pipeline. Prendi in considerazione i seguenti tipi di test di integrazione:
- Un test di integrazione della trasformazione che valuta la funzionalità integrata di tutte le singole trasformazioni che compongono la pipeline di dati. Pensa ai test di integrazione come a un test delle unità l'intera pipeline, esclusa l'integrazione con origini dati e sink esterni. L'SDK Apache Beam fornisce metodi per fornire i dati di test alla pipeline di dati e verificare i risultati dell'elaborazione. Viene utilizzato il metodo Direct Runner per eseguire test di integrazione della trasformazione.
Un test di integrazione del sistema che valuta l'integrazione della pipeline di dati con origini dati e sink. Per consentire alla tua pipeline di comunicare per i sistemi esterni, devi configurare i test con per accedere a servizi esterni. Esecuzione pipeline di flusso a tempo indeterminato, quindi devi decidere quando e come interromperla una pipeline o un blocco note personalizzato. Utilizzando Direct Runner per eseguire i test di integrazione del sistema, puoi Verificare rapidamente l'integrazione tra la pipeline e altri sistemi senza dover inviare un job Dataflow e attendere per completare l'operazione.
Progettare test di trasformazione e integrazione del sistema per fornire un rilevamento rapido dei difetti e un feedback senza rallentare lo sviluppatore la produttività. Per i test più lunghi, ad esempio quelli eseguiti come nei job Dataflow, potrebbe essere utile usare un test end-to-end viene eseguita con meno frequenza.
Una pipeline di dati può essere paragonata a una o più trasformazioni correlate. Tu
puoi creare una trasformazione composita di incapsulamento per la pipeline
utilizzare
TestPipeline
per eseguire un test di integrazione dell'intera pipeline. A seconda che tu
se vuoi testare la pipeline in modalità batch o flusso, devi fornire i dati di test utilizzando
o il
Create
o
Trasformazioni TestStream.
Utilizza i dati dei test per i test di integrazione
Nel tuo ambiente di produzione, è probabile che la pipeline si integri con di origini dati e sink. Tuttavia, per i test delle unità e l'integrazione della trasformazione i test, concentrati sulla verifica della logica di business del codice della pipeline fornendo input di test e verificando direttamente l'output. Oltre a semplifichiamo i test, questo approccio ti consente di isolare i dati che potrebbero essere causati da origini dati e sink.
Test delle pipeline in modalità batch
Per le pipeline in modalità batch, utilizza la trasformazione Create per creare un PCollection
dei dati di test di input da una raccolta in memoria standard, come un
Oggetto List Java. L'utilizzo della trasformazione Create è appropriato se il tuo test
sia abbastanza piccolo da includerlo nel codice. Potrai quindi usare PAssert sulla
genera PCollection oggetti per determinare la correttezza del codice della pipeline.
Questo approccio è supportato da Direct Runner e
Esecutore Dataflow.
Il seguente snippet di codice Java mostra le asserzioni rispetto all'output PCollection
di oggetti di una trasformazione composita che include alcuni o tutti i
che costituiscono una pipeline (WeatherStatsPipeline). L'approccio è
in modo simile alle trasformazioni individuali
per i test delle unità in una 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();
}
Per testare il comportamento del windowing, puoi anche utilizzare la trasformazione Create per creare
con timestamp, come mostrato nello snippet di codice riportato di seguito:
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();
}
Testare le pipeline in modalità flusso
Le pipeline in modalità flusso contengono ipotesi che definiscono come gestire e i dati di Google Cloud. Queste ipotesi riguardano spesso la tempestività dei dati condizioni reali e hanno quindi un impatto sulla correttezza a seconda se le ipotesi si dimostrano vere o false. Test di integrazione per le pipeline in modalità flusso includono idealmente test che simulano natura non deterministica dell'arrivo dei dati in modalità flusso.
A
abilitare questi test,
l'SDK Apache Beam fornisce
TestStream
per modellare gli effetti delle tempistiche degli elementi (dati in anticipo, puntuali o in ritardo) su
i risultati della pipeline di dati. Utilizza questi test insieme
PAssert
da verificare rispetto ai risultati previsti.
TestStream è supportato da Direct Runner e
Esecutore Dataflow. Il seguente esempio di codice crea un TestStream
e trasformerai:
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();
}
Per ulteriori informazioni su TestStream, vedi
Test di pipeline illimitate in Apache Beam.
Per ulteriori informazioni su come utilizzare l'SDK Apache Beam per i test delle unità, consulta
documentazione di Apache Beam.
Utilizza i servizi Google Cloud nei test di integrazione
La
Corsa diretta
può integrarsi con i servizi Google Cloud, per cui eseguire test ad hoc nell'ambiente locale e test di integrazione del sistema
utilizzare Pub/Sub, BigQuery e altri servizi
necessaria. Quando utilizzi Direct Runner, la pipeline viene eseguita come account utente
configurato utilizzando
gcloud
a strumento a riga di comando o come account di servizio che hai specificato
GOOGLE_APPLICATION_CREDENTIALS
variabile di ambiente. Di conseguenza, devi concedere un numero sufficiente
le autorizzazioni all'account per le risorse richieste prima di eseguire
una pipeline o un blocco note personalizzato. Per ulteriori dettagli, vedi
Sicurezza e autorizzazioni di Dataflow.
Per i test di integrazione completamente locali, puoi usare emulatori locali per servizi Google Cloud. Gli emulatori locali sono disponibili Pub/Sub e Bigtable.
Per i test di integrazione del sistema di pipeline in modalità flusso, puoi utilizzare il metodo
setBlockOnRun
(definito nell'interfaccia DirectOptions) per fare in modo che il runner diretto esegua la pipeline in modo asincrono.
In caso contrario, l'esecuzione della pipeline blocca il processo principale chiamante (ad
ad esempio uno script nella pipeline di build) finché la pipeline non viene eseguita manualmente
è stata interrotta. Se esegui la pipeline in modo asincrono, puoi utilizzare
PipelineResult
per annullare l'esecuzione della pipeline, come mostrato nel codice seguente
esempio:
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();
}
Test end-to-end
I test end-to-end verificano il corretto funzionamento della pipeline end-to-end eseguirlo su Dataflow Runner in condizioni che assomigliano alla produzione. I test verificano che la logica di business funzioni correttamente utilizzando l'esecutore Dataflow e testare se la pipeline si comporta come previsto in caricamenti simili a quelli di produzione. In genere esegui test end-to-end in un progetto Google Cloud dedicato designato come nell'ambiente di preproduzione.
Per testare la tua pipeline su diverse scale, utilizza diversi tipi di end-to-end test, ad esempio:
- Esegui test end-to-end su scala ridotta utilizzando una piccola proporzione (ad esempio l'1%) del set di dati di test per convalidare rapidamente la funzionalità della pipeline dell'ambiente di preproduzione.
- Esegui test end-to-end su larga scala utilizzando un set di dati di test completo per la convalida della pipeline in condizioni e volumi di dati simili a quelli di produzione.
Per le pipeline in modalità flusso, consigliamo di eseguire pipeline di test in parallelo con la pipeline di produzione, se possono usare gli stessi dati. Questo processo consente di confrontare i risultati e il comportamento operativo, come scalabilità automatica e prestazioni.
I test end-to-end aiutano a prevedere in che misura la pipeline soddisferà le tue o SLO di produzione. L'ambiente di preproduzione testa la pipeline in in condizioni simili a quelle della produzione. All'interno dei test end-to-end, le pipeline vengono eseguite utilizzando Dataflow Runner per elaborare i set di dati di riferimento completi che corrispondono o assomigliano a set di dati molto simili in produzione.
Potrebbe non essere possibile generare dati sintetici per testare simulano accuratamente dati reali. Per risolvere questo problema, un approccio consiste nell'utilizzare estratti puliti dalle origini dati di produzione per creare set di dati di riferimento, i dati sensibili vengono anonimizzati tramite le trasformazioni appropriate. È consigliabile utilizzare Protezione dei dati sensibili a questo scopo. Sensitive Data Protection può rilevare i dati sensibili da un'ampia gamma di i tipi di contenuti e le origini dati, nonché applicare una serie di tecniche di anonimizzazione tra cui oscuramento, mascheramento, crittografia con protezione del formato e date-shifting.
Differenze nei test end-to-end per pipeline in modalità batch e flusso
Prima di eseguire un test end-to-end completo su un set di dati di test di grandi dimensioni,
potresti voler eseguire un test con una percentuale inferiore di dati di test (ad esempio
come 1%) e verifica il comportamento previsto più breve. Mi piace
con i test di integrazione con Direct Runner, puoi usare PAssert
PCollection di oggetti quando esegui pipeline utilizzando
Esecutore Dataflow. Per ulteriori informazioni su PAssert, consulta
Sezione Test delle unità di questa pagina.
A seconda del caso d'uso, verificare output molto grandi da test end-to-end potrebbe essere poco pratico, costoso o comunque impegnativo. In tal caso, puoi e verificheranno invece campioni rappresentativi del set di risultati di output. Ad esempio: puoi utilizzare BigQuery per campionare e confrontare le righe di output con set di dati di riferimento dei risultati previsti.
Per pipeline in modalità flusso, simulare condizioni di flusso realistiche con dati sintetici può essere difficile. Un modo comune per offrire per i test end-to-end i flussi di dati prevedono l'integrazione dei test con i dati di produzione fonti. Se utilizzi Pub/Sub come origine dati, puoi abilitare uno stream di dati separato per i test end-to-end tramite abbonamenti aggiuntivi argomenti esistenti. Puoi quindi confrontare i risultati di diverse pipeline consumare gli stessi dati, il che è utile per verificare le pipeline candidati rispetto a di altre pipeline di pre-produzione e produzione.
Il seguente diagramma mostra in che modo questo metodo consente una pipeline di produzione una pipeline di test per l'esecuzione in parallelo in ambienti di deployment.
Nel diagramma, entrambe le pipeline leggono dallo stesso argomento Pub/Sub, ma usano abbonamenti separati. Questa configurazione consente alle due pipeline di elaborare gli stessi dati in modo indipendente e consente di confrontare i risultati. Il test utilizza un account di servizio separato da quello del progetto di produzione, e evita quindi di utilizzare la quota di sottoscrittore Pub/Sub per progetto di produzione.
A differenza delle pipeline in modalità batch, le pipeline in modalità flusso continuano a essere eseguite fino esplicitamente annullato. Nei test end-to-end, devi decidere se abbandonare della pipeline in esecuzione, magari fino all'esecuzione del successivo test end-to-end, oppure annulla la pipeline in un punto che rappresenta il completamento del test, in modo da poter ispezionare i risultati.
Il tipo di dati di test utilizzati influisce su questa decisione. Ad esempio, se utilizzi un set limitato di dati di test forniti alla pipeline in modalità flusso, potresti annulla la pipeline quando hanno completato l'elaborazione. In alternativa, se utilizzi un'origine dati reale, ad esempio un argomento Pub/Sub esistente usato in produzione oppure se invece generi continuamente dati di test, potresti voler mantenere di pipeline in esecuzione per un periodo più lungo. Il secondo ti consente di confrontare il comportamento nell'ambiente di produzione o anche con altre pipeline di test.