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 significativa sul rendimento della pipeline in produzione. Per aiutarti a creare un codice della pipeline che funzioni in modo corretto ed efficiente, questo documento spiega quanto segue:
- Runner della pipeline per supportare l'esecuzione del codice nelle diverse fasi di sviluppo e deployment.
- Ambienti di deployment che consentono di eseguire pipeline in fase di sviluppo, test, pre-produzione e produzione.
- Codice e modelli di pipeline open source che puoi utilizzare 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, questo documento fornisce una panoramica che include l'ambito e la relazione dei diversi tipi di test, come test delle unità, test di integrazione e test end-to-end. In secondo luogo, ogni tipo di test viene esplorato in dettaglio, compresi i metodi per 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 il codice della pipeline. L'SDK Apache Beam fornisce un Direct Runner per lo sviluppo e i test locali. Gli strumenti di automazione del rilascio possono usare Direct Runner anche per i test delle unità e di integrazione. Ad esempio, puoi utilizzare Direct Runner all'interno della pipeline di integrazione continua (CI).
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 i test di sviluppo ad hoc e per i test di pipeline end-to-end.
Sebbene questa pagina si concentri sull'esecuzione di pipeline create utilizzando l'SDK Java, Dataflow supporta anche le pipeline Apache Beam sviluppate con Python e Go. Gli SDK Apache Beam Java, Python e Go sono generalmente disponibili per Dataflow. Gli sviluppatori SQL possono anche utilizzare Apache Beam SQL per creare pipeline che utilizzano dialetti SQL familiari.
configura un ambiente di deployment
Per separare utenti, dati, codice e altre risorse in diverse fasi dello sviluppo, crea ambienti di deployment. Se possibile, per fornire ambienti isolati per le diverse fasi di sviluppo della pipeline, utilizza progetti Google Cloud separati.
Le sezioni seguenti descrivono un set tipico di ambienti di deployment.
Ambiente locale
L'ambiente locale è la workstation di uno sviluppatore. Per sviluppo e test rapidi, utilizza Direct Runner per eseguire il codice della pipeline in locale.
Le pipeline eseguite localmente utilizzando Direct Runner possono interagire con risorse Google Cloud remote, come argomenti Pub/Sub o tabelle BigQuery. Assegna ai singoli sviluppatori progetti Google Cloud separati in modo da avere una sandbox per i test ad hoc con i servizi Google Cloud.
Alcuni servizi Google Cloud, come Pub/Sub e Bigtable, forniscono emulatori per lo sviluppo locale. Puoi usare questi emulatori con Direct Runner per abilitare sviluppo e test locali end-to-end.
Ambiente sandbox
L'ambiente sandbox è un progetto Google Cloud che consente agli sviluppatori di accedere ai servizi Google Cloud durante lo sviluppo del codice. Gli sviluppatori della pipeline possono condividere un progetto Google Cloud con altri sviluppatori o utilizzare i propri progetti individuali. L'uso di singoli progetti riduce la complessità di pianificazione relativa all'uso condiviso delle risorse e alla gestione delle quote.
Gli sviluppatori utilizzano l'ambiente sandbox per eseguire l'esecuzione della pipeline ad hoc con Dataflow Runner. L'ambiente sandbox è utile per eseguire il debug e testare il codice rispetto a un runner di produzione durante la fase di sviluppo del codice. Ad esempio, l'esecuzione di pipeline ad hoc consente agli sviluppatori di:
- Osserva l'effetto delle modifiche al codice sul comportamento di scalabilità.
- Comprendi le potenziali differenze tra il comportamento di Direct Runner e di Dataflow.
- Scopri in che modo Dataflow applica le 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 dell'ambiente sandbox.
Ambiente di preproduzione
L'ambiente di preproduzione è destinato alle fasi di sviluppo che devono essere eseguite in condizioni simili alla produzione, come i test end-to-end. Utilizza un progetto separato per l'ambiente di preproduzione e configuralo in modo che sia il più simile possibile alla produzione. Analogamente, per consentire i test end-to-end con una scalabilità di tipo produzione, rendi le quote del progetto Google Cloud per Dataflow e altri servizi il più simili possibile all'ambiente di produzione.
A seconda dei requisiti, puoi separare ulteriormente la preproduzione in più ambienti. Ad esempio, un ambiente di controllo qualità può supportare il lavoro degli analisti della qualità nel testare gli obiettivi del livello del servizio (SLO), come la correttezza, l'aggiornamento e le prestazioni dei dati in diverse condizioni dei carichi di lavoro.
I test end-to-end includono l'integrazione con origini dati e sink nell'ambito del 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 vengono archiviati in un bucket Cloud Storage con i tuoi dati di input. In altri 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 eseguire test end-to-end utilizzando dati generati, ad esempio utilizzando il generatore di dati in modalità flusso di Dataflow 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 gli 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 è necessario coordinare più passaggi, ad esempio quando si eseguono pipeline parallele per evitare tempi di inattività.
Ambiente di produzione
L'ambiente di produzione è un progetto Google Cloud dedicato. La distribuzione continua copia gli artefatti di deployment nell'ambiente di produzione una volta superati tutti i test end-to-end.
Best practice per lo sviluppo
Consulta le best practice per la pipeline Dataflow.
Testa la pipeline
Nello sviluppo del software, i test delle unità, i test di integrazione e i test end-to-end sono tipi comuni di test del software. Questi tipi di test si applicano anche alle pipeline di dati.
L'SDK Apache Beam fornisce le funzionalità per abilitare questi test. Idealmente, ciascun tipo di test ha come target un ambiente di deployment diverso. Il seguente diagramma illustra come i test delle unità, i test di integrazione e i test end-to-end si applicano a diverse parti della pipeline e dei dati.
Il diagramma mostra l'ambito dei diversi test e la relativa correlazione con le trasformazioni (sottoclassi DoFn e PTransform), pipeline, origini dati e sink di dati.
Le seguenti sezioni descrivono in che modo i vari test formali del software si applicano alle pipeline di dati utilizzando Dataflow. Mentre leggi questa sezione, fai riferimento al diagramma per comprendere la correlazione tra i diversi tipi di test.
Campionamento dei dati
Per osservare i dati in ogni fase di una pipeline Dataflow, abilita il campionamento dei dati durante il test. In questo modo puoi visualizzare gli output delle trasformazioni, per assicurarti che siano corretti.
Test delle unità
I test delle unità valutano il corretto funzionamento delle sottoclassi DoFn e delle trasformazioni composte (PTransform sottoclassi) confrontando l'output di queste trasformazioni con un set verificato di input e output di dati. In genere, gli sviluppatori possono eseguire
questi test nell'ambiente locale. I test possono anche essere eseguiti automaticamente
tramite l'automazione dei test delle unità utilizzando l'integrazione continua (CI) nell'ambiente
di build.
Direct Runner esegue i test delle unità utilizzando un sottoinsieme più ridotto di dati dei test di riferimento incentrati sul test della logica di business delle trasformazioni. I dati del test devono essere sufficientemente piccoli da essere contenuti nella memoria locale sulla macchina che esegue il test.
L'SDK Apache Beam fornisce una regola JUnit denominata
TestPipeline
per il test di trasformazioni individuali (DoFn sottoclassi) per il test delle unità, trasformazioni composte
(PTransform sottoclassi) e intere pipeline. Puoi utilizzare TestPipeline su
un runner di pipeline Apache Beam come Direct Runner o
Dataflow Runner per applicare asserzioni sui contenuti degli
oggetti PCollection utilizzando
PAssert,
come mostrato nel seguente snippet di codice di una
classe di 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
Fattorizzando il codice in trasformazioni riutilizzabili, ad esempio come classi nidificate di primo livello o statiche, puoi creare test mirati per diverse parti della pipeline. Oltre ai vantaggi dei test, le trasformazioni riutilizzabili migliorano la manutenibilità e la riutilizzabilità del codice incapsulando naturalmente la logica aziendale della pipeline in componenti. Al contrario, testare singole parti della pipeline potrebbe essere difficile se la pipeline utilizza classi interne anonime per implementare le trasformazioni.
Il seguente snippet Java mostra l'implementazione delle trasformazioni come classi interne anonime, che non consentono facilmente il 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 le classi interne anonime vengono
refactoring in sottoclassi DoFn denominate. Puoi creare test delle singole unità per ogni sottoclasse DoFn concreta che compone la 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à di una pipeline batch
contenente una singola trasformazione. Utilizza la trasformazione Create per creare un oggetto PCollection di dati di test, quindi passalo all'oggetto DoFn. Utilizza PAssert per affermare che i contenuti dell'oggetto
PCollection sono corretti. Il seguente esempio di codice Java utilizza la classe PAssert per
verificare il modulo di output 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 delle trasformazioni che valuta la funzionalità integrata di tutte le trasformazioni individuali che compongono la pipeline di dati. Pensa ai test di integrazione di trasformazione come a un test delle unità per l'intera pipeline, esclusa l'integrazione con origini dati e sink esterni. L'SDK Apache Beam fornisce metodi per fornire dati di test alla pipeline di dati e per verificare i risultati dell'elaborazione. Direct Runner consente di eseguire test di integrazione delle trasformazioni.
Un test di integrazione del sistema che valuta l'integrazione della pipeline di dati con origini dati e sink. Affinché la tua pipeline possa comunicare con sistemi esterni, devi configurare i test con credenziali appropriate per accedere ai servizi esterni. Le pipeline in modalità flusso vengono eseguite a tempo indeterminato, quindi devi decidere quando e come arrestarla. Utilizzando Direct Runner per 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 il completamento.
Progetta test di trasformazione e di integrazione del sistema per fornire un rilevamento rapido dei difetti e un feedback senza rallentare la produttività degli sviluppatori. Per i test più lunghi, ad esempio quelli eseguiti come job Dataflow, è consigliabile utilizzare un test end-to-end che viene eseguito con minore frequenza.
Una pipeline di dati può essere paragonata a una o più trasformazioni correlate. Puoi creare una trasformazione composita con incapsulamento per la pipeline e utilizzare TestPipeline per eseguire un test di integrazione dell'intera pipeline. A seconda che tu voglia testare la pipeline in modalità batch o flusso, devi fornire i dati di test utilizzando le trasformazioni Create o TestStream.
Utilizza i dati dei test per i test di integrazione
Nel tuo ambiente di produzione, è probabile che la pipeline si integri con diverse origini dati e sink. Tuttavia, per i test delle unità e i test di integrazione della trasformazione, concentrati sulla verifica della logica di business del codice della pipeline fornendo input di test e verificando direttamente l'output. Oltre a semplificare i test, questo approccio ti consente di isolare i problemi specifici della pipeline da quelli che potrebbero essere causati da origini dati e sink.
Test delle pipeline in modalità batch
Per le pipeline batch, utilizza la trasformazione Create per creare un oggetto PCollection
dei dati di test di input da una raccolta in memoria standard, ad esempio un
oggetto List Java. L'utilizzo della trasformazione Create è appropriato se i dati di test
sono sufficientemente piccoli da poter essere inclusi nel codice. Puoi quindi utilizzare PAssert negli oggetti PCollection di output per determinare la correttezza del codice della pipeline.
Questo approccio è supportato da Direct Runner e da Dataflow.
Il seguente snippet di codice Java mostra le asserzioni rispetto agli oggetti PCollection di output da una trasformazione composita che include alcune o tutte le singole trasformazioni che costituiscono una pipeline (WeatherStatsPipeline). L'approccio è simile al test delle singole trasformazioni 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
elementi con timestamp, come mostrato nel seguente snippet di codice:
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 dati illimitati. Queste ipotesi riguardano spesso la tempestività dei dati in condizioni reali e hanno quindi un impatto sulla correttezza a seconda che le ipotesi si rivelino vere o false. I test di integrazione per le pipeline in modalità flusso idealmente includono test che simulano la natura non deterministica dell'arrivo dei dati in modalità flusso.
Per abilitare questi test, l'SDK Apache Beam fornisce la classe TestStream per modellare gli effetti delle tempistiche degli elementi (dati tempestivi, puntuali o in ritardo) sui risultati della pipeline di dati. Usa questi test insieme alla classe PAssert per verificare rispetto ai risultati previsti.
TestStream è supportato da Direct Runner e Dataflow. Il seguente esempio di codice crea una trasformazione TestStream:
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 maggiori informazioni su TestStream, consulta
Test di pipeline illimitate in Apache Beam.
Per ulteriori informazioni su come utilizzare l'SDK Apache Beam per i test delle unità, consulta la documentazione di Apache Beam.
Utilizza i servizi Google Cloud nei test di integrazione
Direct Runner può integrarsi con i servizi Google Cloud, in modo che i test ad hoc nell'ambiente locale e i test di integrazione del sistema possano utilizzare Pub/Sub, BigQuery e altri servizi secondo le necessità. Quando utilizzi Direct Runner, la pipeline viene eseguita come l'account utente
che hai configurato utilizzando lo strumento a riga di comando
gcloud
o come account di servizio che hai specificato utilizzando la
variabile di ambiente
GOOGLE_APPLICATION_CREDENTIALS. Pertanto, devi concedere a questo account autorizzazioni sufficienti per tutte le risorse richieste prima di eseguire la pipeline. Per ulteriori dettagli, consulta Sicurezza e autorizzazioni di Dataflow.
Per i test di integrazione completamente locali, puoi utilizzare emulatori locali per alcuni servizi Google Cloud. Gli emulatori locali sono disponibili per Pub/Sub e Bigtable.
Per i test di integrazione del sistema delle pipeline in modalità flusso, puoi utilizzare il metodo setBlockOnRun (definito nell'interfaccia DirectOptions) per fare in modo che il Direct Runner esegua la pipeline in modo asincrono.
In caso contrario, l'esecuzione della pipeline blocca il processo padre chiamante (ad esempio, uno script nella pipeline di build) fino a quando la pipeline non viene arrestata manualmente. Se esegui la pipeline in modo asincrono, puoi utilizzare l'istanza PipelineResult restituita per annullare l'esecuzione della pipeline, come mostrato nell'esempio di codice seguente:
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 eseguendo l'esecuzione sul runner Dataflow in condizioni che assomigliano alla produzione. I test verificano che la logica di business funzioni correttamente utilizzando il runner Dataflow e verificano 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 ambiente di preproduzione.
Per testare la tua pipeline su diverse scale, utilizza diversi tipi di test end-to-end, 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 nell'ambiente di preproduzione.
- Esegui test end-to-end su larga scala utilizzando un set di dati di test completo per convalidare la funzionalità della pipeline in volumi e condizioni di dati simili a quelli di produzione.
Per le pipeline in modalità flusso, consigliamo di eseguire pipeline di test in parallelo alla pipeline di produzione, se possono utilizzare gli stessi dati. Questo processo consente di confrontare i risultati e il comportamento operativo, come la scalabilità automatica e le prestazioni.
I test end-to-end aiutano a prevedere in che misura la pipeline soddisferà gli SLO di produzione. L'ambiente di preproduzione testa la pipeline in condizioni simili a quelle della produzione. All'interno dei test end-to-end, le pipeline vengono eseguite utilizzando Dataflow Runner per elaborare set di dati di riferimento completi che corrispondono o sono molto simili a set di dati in produzione.
Potrebbe non essere possibile generare dati sintetici per test che simulano in modo accurato dati reali. Per risolvere questo problema, un approccio consiste nell'utilizzare estratti puliti da origini dati di produzione per creare set di dati di riferimento, in cui tutti i dati sensibili vengono anonimizzati tramite trasformazioni appropriate. A questo scopo, ti consigliamo di utilizzare Sensitive Data Protection. Sensitive Data Protection può rilevare i dati sensibili da una serie di tipi di contenuti e origini dati e applicare una serie di tecniche di anonimizzazione, tra cui l'oscuramento, il mascheramento, la crittografia con protezione del formato e il cambio di data.
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, ti consigliamo di eseguire un test con una percentuale inferiore di dati di test (ad esempio l'1%) e verificare il comportamento previsto in un periodo di tempo inferiore. Come per i test di integrazione con Direct Runner, puoi utilizzare PAssert sugli oggetti PCollection quando esegui le pipeline utilizzando Dataflow Runner. Per ulteriori informazioni su PAssert, consulta la sezione
Test delle unità in questa pagina.
A seconda del caso d'uso, verificare output molto grandi da test end-to-end potrebbe essere poco attuabile, costoso o comunque impegnativo. In questo caso, puoi verificare campioni rappresentativi del set di risultati di output. Ad esempio, puoi utilizzare BigQuery per campionare e confrontare le righe di output con un set di dati di riferimento dei risultati previsti.
Per le pipeline in modalità flusso, la simulazione di condizioni di flusso realistiche con dati sintetici potrebbe essere impegnativa. Un modo comune per fornire dati in modalità flusso per i test end-to-end è integrare i test con origini dati di produzione. Se utilizzi Pub/Sub come origine dati, puoi abilitare uno stream di dati separato per i test end-to-end mediante sottoscrizioni aggiuntive ad argomenti esistenti. Puoi quindi confrontare i risultati di diverse pipeline che utilizzano gli stessi dati, il che è utile per verificare le pipeline candidati rispetto ad altre pipeline di pre-produzione e produzione.
Il seguente diagramma mostra in che modo questo metodo consente di eseguire in parallelo una pipeline di produzione e una pipeline di test in diversi ambienti di deployment.
Nel diagramma, entrambe le pipeline leggono dallo stesso argomento Pub/Sub, ma utilizzano sottoscrizioni separate. Questa configurazione consente alle due pipeline di elaborare gli stessi dati in modo indipendente e di confrontare i risultati. La pipeline di test utilizza un account di servizio separato dal progetto di produzione e evita pertanto di utilizzare la quota di sottoscrittore Pub/Sub per il progetto di produzione.
A differenza delle pipeline in modalità batch, le pipeline in modalità flusso continuano a essere eseguite fino a quando non vengono esplicitamente annullate. Nei test end-to-end, devi decidere se lasciare la pipeline in esecuzione, magari fino all'esecuzione del successivo test end-to-end, o annullare la pipeline in un punto che rappresenta il completamento del test, in modo da poter esaminare i risultati.
Il tipo di dati di test utilizzati influisce su questa decisione. Ad esempio, se utilizzi un set limitato di dati di test fornito alla pipeline in modalità flusso, potresti annullare la pipeline al termine dell'elaborazione di tutti gli elementi. In alternativa, se utilizzi un'origine dati reale, ad esempio un argomento Pub/Sub esistente utilizzato in produzione, o se generi dati di test continuamente, ti consigliamo di mantenere le pipeline di test in esecuzione per un periodo più lungo. Quest'ultimo consente di confrontare il comportamento nell'ambiente di produzione o anche con altre pipeline di test.