Questa pagina fornisce le best practice per lo sviluppo e il test della pipeline Dataflow.
Panoramica
Il modo in cui viene implementato il codice della pipeline ha un'influenza significativa sul suo rendimento in produzione. Per aiutarti a creare un codice della pipeline che funzioni correttamente ed efficientemente, questo documento spiega quanto segue:
- Esecutori di pipeline per supportare l'esecuzione del codice nelle diverse fasi di sviluppo e deployment.
- Ambienti di deployment che ti consentono di eseguire pipeline durante lo sviluppo, i test, la preproduzione e la produzione.
- Modelli e codice della 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 tra diversi tipi di test, come test unitari, test di integrazione e test end-to-end. In secondo luogo, ogni tipo di test viene esaminato in dettaglio, inclusi i metodi per creare e integrare i dati di test e i runner della pipeline da utilizzare per ogni test.
Runner della pipeline
Durante lo sviluppo e il test, utilizzi runner Apache Beam diversi 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 anche utilizzare Direct Runner per i test unitari e di integrazione. Ad esempio, puoi utilizzare Direct Runner all'interno della pipeline di integrazione continua (CI).
Le pipeline di cui è stato 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 test della pipeline end-to-end.
Sebbene questa pagina si concentri sull'esecuzione di pipeline create utilizzando l'SDK Apache Beam Java, Dataflow supporta anche le pipeline Apache Beam sviluppate utilizzando Python e Go. Gli SDK Apache Beam Java, Python e Go sono disponibili a livello generale 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 nelle diverse fasi di sviluppo, crea ambienti di deployment. Se possibile, per fornire ambienti isolati per le diverse fasi di sviluppo della pipeline, utilizza Google Cloud progetti separati.
Le sezioni seguenti descrivono un insieme tipico di ambienti di deployment.
Ambiente locale
L'ambiente locale è la workstation di uno sviluppatore. Per lo sviluppo e il test rapido, utilizza Direct Runner per eseguire il codice della pipeline localmente.
Le pipeline eseguite localmente utilizzando Direct Runner possono interagire con risorse remote, come argomenti Pub/Sub o tabelle BigQuery. Google Cloud Assegna a ogni sviluppatore progetti Google Cloud separati in modo che disponga di una sandbox per i test ad hoc con Google Cloud servizi.
Alcuni Google Cloud servizi, come Pub/Sub e Bigtable, forniscono emulatori per lo sviluppo locale. Puoi utilizzare questi emulatori con Direct Runner per abilitare lo sviluppo e il test locali end-to-end.
Ambiente sandbox
L'ambiente sandbox è un Google Cloud progetto che fornisce agli sviluppatori l'accesso ai servizi Google Cloud durante lo sviluppo del codice. Gli sviluppatori di pipeline possono condividere un progetto Google Cloud con altri sviluppatori o utilizzare i propri progetti individuali. L'utilizzo di singoli progetti riduce la complessità della pianificazione relativa all'utilizzo delle risorse condivise e alla gestione delle quote.
Gli sviluppatori utilizzano l'ambiente sandbox per eseguire pipeline ad hoc con Dataflow Runner. L'ambiente sandbox è utile per il debug e il test del 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 Dataflow Runner.
- Scopri in che modo Dataflow applica le ottimizzazioni del grafico.
Per i test ad hoc, gli sviluppatori possono eseguire il deployment del codice dal proprio ambiente locale per eseguire Dataflow all'interno del proprio ambiente sandbox.
Ambiente di preproduzione
L'ambiente di preproduzione è destinato alle fasi di sviluppo che devono essere eseguite in condizioni simili a quelle di produzione, ad esempio i test end-to-end. Utilizza un progetto separato per l'ambiente di preproduzione e configurarlo in modo che sia il più simile possibile alla produzione. Allo stesso modo, per consentire test end-to-end con una scalabilità simile a quella di produzione, rendi le quote di 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à per testare gli obiettivi del livello di servizio (SLO) come la correttezza, l'aggiornamento e le prestazioni dei dati in diverse condizioni di carico di lavoro.
I test end-to-end includono l'integrazione con origini e sink di dati nell'ambito del test. Valuta come renderli disponibili nell'ambiente di pre-produzione. Puoi archiviare i dati di test nell'ambiente di preproduzione stesso. Ad esempio, i dati di test vengono archiviati in un bucket Cloud Storage insieme ai dati di input. In altri casi, i dati di test potrebbero provenire dall'esterno dell'ambiente di preproduzione, ad esempio da un argomento Pub/Sub tramite un abbonamento separato nell'ambiente di produzione. Per le pipeline di streaming, puoi anche eseguire test end-to-end utilizzando i dati generati, ad esempio utilizzando lo Streaming Data Generator di Dataflow per emulare le caratteristiche e i volumi dei dati di produzione.
Per le pipeline di streaming, utilizza l'ambiente di pre-produzione per testare gli aggiornamenti della pipeline prima di apportare modifiche alla produzione. È importante testare e verificare le procedure di aggiornamento per le pipeline di streaming, in particolare se devi coordinare più passaggi, ad esempio quando esegui 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 quando tutti i test end-to-end sono stati superati.
Best practice per lo sviluppo
Consulta le best practice per le pipeline Dataflow.
Testare la pipeline
Nello sviluppo di 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 sono applicabili anche alle pipeline di dati.
L'SDK Apache Beam fornisce funzionalità per abilitare questi test. Idealmente, ogni tipo di test ha come target un ambiente di deployment diverso. Il seguente diagramma illustra come i test unitari, 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 di diversi test e la loro relazione con
le trasformazioni (sottoclassi DoFn e PTransform), le pipeline, le origini dati e
i sink di dati.
Le seguenti sezioni descrivono come vari test formali del software vengono applicati alle pipeline di dati utilizzando Dataflow. Mentre leggi questa sezione, fai riferimento al diagramma per capire la relazione tra i diversi tipi di test.
Campionamento dei dati
Per osservare i dati in ogni passaggio di una pipeline Dataflow, attiva 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 unitari valutano il corretto funzionamento delle sottoclassi DoFn e delle
trasformazioni composite
(sottoclassi PTransform) confrontando l'output di queste trasformazioni con un
insieme verificato di input e output di dati. In genere, gli sviluppatori possono eseguire questi test nell'ambiente locale. I test possono essere eseguiti automaticamente anche tramite l'automazione dei test unitari utilizzando l'integrazione continua (CI) nell'ambiente di build.
Direct Runner esegue test unitari utilizzando un sottoinsieme più piccolo di dati di test di riferimento che si concentra sul test della logica di business delle trasformazioni. I dati di test devono essere sufficientemente piccoli da poter essere memorizzati nella memoria locale del computer che esegue il test.
L'SDK Apache Beam fornisce una regola JUnit chiamata
TestPipeline
per il test delle singole trasformazioni (sottoclassi DoFn), delle trasformazioni composite
(sottoclassi PTransform) e delle intere pipeline. Puoi utilizzare TestPipeline in un
runner della pipeline Apache Beam come Direct Runner o
Dataflow Runner per applicare asserzioni ai 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 singole trasformazioni
Se fattorizzi il codice in trasformazioni riutilizzabili, ad esempio come classi nidificate statiche o di primo livello, puoi creare test mirati per diverse parti della pipeline. Oltre ai vantaggi dei test, le trasformazioni riutilizzabili migliorano la manutenibilità e il riutilizzo del codice incapsulando naturalmente la logica di business della pipeline in parti 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, il che non consente facilmente i 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 il seguente, in cui le classi interne anonime vengono sottoposte a refactoring in sottoclassi DoFn concrete denominate. Puoi creare
test delle unità individuali 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
che contiene una singola trasformazione. Utilizza la trasformazione Create per
creare un oggetto PCollection di dati di test e poi passarlo all'oggetto DoFn. Utilizza PAssert per dichiarare che i contenuti dell'oggetto PCollection
sono corretti. Il seguente esempio di codice Java utilizza la classe PAssert per
verificare la correttezza del modulo di output.
@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. Considera i test di integrazione della trasformazione come un test unitario per l'intera pipeline, escludendo l'integrazione con origini e sink di dati 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 viene utilizzato per eseguire test di integrazione della trasformazione.
Un test di integrazione del sistema che valuta l'integrazione della pipeline di dati con origini e sink di dati attivi. Affinché la pipeline possa comunicare con sistemi esterni, devi configurare i test con le credenziali appropriate per accedere ai servizi esterni. Le pipeline di streaming vengono eseguite indefinitamente, quindi devi decidere quando e come interrompere l'esecuzione della pipeline. Utilizzando Direct Runner per eseguire 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 suo completamento.
Progetta test di trasformazione e integrazione del sistema per fornire rilevamento e feedback rapidi sui difetti senza rallentare la produttività degli sviluppatori. Per i test di durata più lunga, ad esempio quelli eseguiti come job Dataflow, potresti voler utilizzare un test end-to-end che venga eseguito meno frequentemente.
Pensa a una pipeline di dati come a una o più trasformazioni correlate. Puoi
creare una trasformazione composita di 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 streaming, fornisci i dati di test utilizzando le trasformazioni
Create o
TestStream.
Utilizzare dati di test per i test di integrazione
Nell'ambiente di produzione, la pipeline probabilmente si integra con diverse origini e sink di dati. Tuttavia, per i test delle unità e 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 consente di isolare i problemi specifici della pipeline da quelli che potrebbero essere causati da origini e sink di dati.
Testare le pipeline batch
Per le pipeline batch, utilizza la trasformazione Create per creare un oggetto PCollection
dei dati di test di input da una raccolta standard in memoria, ad esempio un oggetto
Java List. L'utilizzo della trasformazione Create è appropriato se i dati di test sono sufficientemente piccoli da essere inclusi nel codice. Puoi quindi utilizzare PAssert sugli oggetti
di output PCollection per determinare la correttezza del codice della pipeline.
Questo approccio è supportato da Direct Runner e da
Dataflow Runner.
Il seguente snippet di codice Java mostra le asserzioni sugli oggetti di output PCollection
di una trasformazione composita che include alcune o tutte le trasformazioni
individuali che costituiscono una pipeline (WeatherStatsPipeline). L'approccio è
simile al test delle unità 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 di 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 di streaming
Le pipeline di streaming contengono ipotesi che definiscono come gestire i dati illimitati. Questi presupposti riguardano spesso la tempestività dei dati in condizioni reali e, pertanto, hanno un impatto sulla correttezza a seconda che i presupposti si rivelino veri o falsi. I test di integrazione per le pipeline di streaming includono idealmente test che simulano la natura non deterministica dell'arrivo dei dati di streaming.
Per attivare questi test, l'SDK Apache Beam fornisce la classe TestStream per modellare gli effetti delle tempistiche degli elementi (dati in anticipo, puntuali o in ritardo) sui risultati della pipeline di dati. Utilizza questi test insieme alla classe
PAssert per verificare i risultati previsti.
TestStream è supportato da Direct Runner e da
Dataflow Runner. 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 saperne di più su TestStream, consulta
Testare le pipeline senza limiti in Apache Beam.
Per saperne di più su come utilizzare l'SDK Apache Beam per i test unitari, consulta la
documentazione di Apache Beam.
Utilizzare 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 in base alle esigenze. Quando utilizzi Direct Runner, la pipeline utilizza le credenziali predefinite dell'applicazione (ADC) per ottenere le credenziali. La configurazione di ADC dipende da dove viene eseguita la pipeline. Per maggiori informazioni, vedi Configurare le credenziali predefinite dell'applicazione.
Prima di eseguire la pipeline, devi concedere autorizzazioni sufficienti all'account utilizzato dalla pipeline per qualsiasi risorsa richiesta. Per maggiori dettagli, vedi Sicurezza e autorizzazioni di Dataflow.
Per i test di integrazione completamente locali, puoi utilizzare emulatori locali per alcuni serviziGoogle Cloud . Sono disponibili emulatori locali per Pub/Sub e Bigtable.
Per il test di integrazione del sistema delle pipeline di streaming, puoi utilizzare il metodo
setBlockOnRun (definito nell'interfaccia DirectOptions) per fare in modo che 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) finché la pipeline non viene interrotta 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 eseguendola su Dataflow Runner in condizioni che assomigliano molto a quelle di produzione. I test verificano che la logica di business funzioni correttamente utilizzando Dataflow Runner e verificano se la pipeline funziona come previsto con carichi 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 pipeline su scale diverse, utilizza diversi tipi di test end-to-end, ad esempio:
- Esegui test end-to-end su piccola scala utilizzando una piccola percentuale (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 condizioni e volumi di dati simili a quelli di produzione.
Per le pipeline di streaming, ti consigliamo di eseguire le pipeline di test in parallelo con la pipeline di produzione se possono utilizzare gli stessi dati. Questo processo ti consente di confrontare i risultati e il comportamento operativo, ad esempio la scalabilità automatica e il rendimento.
I test end-to-end aiutano a prevedere in che modo la pipeline soddisferà gli SLO di produzione. L'ambiente di preproduzione testa la pipeline in condizioni simili a quelle di produzione. Nei test end-to-end, le pipeline vengono eseguite utilizzando Dataflow Runner per elaborare set di dati di riferimento completi che corrispondono o assomigliano molto ai set di dati in produzione.
Potrebbe non essere possibile generare dati sintetici per testare che simulino accuratamente i 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, in cui tutti i dati sensibili vengono resi anonimi tramite trasformazioni appropriate. A questo scopo, ti consigliamo di utilizzare Sensitive Data Protection. Sensitive Data Protection può rilevare dati sensibili da una serie di tipi di contenuti e origini dati e applicare una serie di tecniche di anonimizzazione, tra cui oscuramento, mascheramento, crittografia con protezione del formato e spostamento della data.
Differenze nei test end-to-end per le pipeline batch e di streaming
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 più breve. Come
con i test di integrazione che utilizzano Direct Runner, puoi utilizzare PAssert sugli
oggetti PCollection quando esegui pipeline utilizzando
Dataflow Runner. Per saperne di più su PAssert, consulta la sezione
Test unitari di questa pagina.
A seconda del caso d'uso, la verifica di output molto grandi dei test end-to-end potrebbe essere impraticabile, costosa o altrimenti difficile. In questo caso, puoi verificare invece campioni rappresentativi dal set di risultati dell'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 di streaming, la simulazione di condizioni di streaming realistiche con dati sintetici potrebbe essere difficile. Un modo comune per fornire dati di streaming per i test end-to-end è integrare i test con le origini dati di produzione. Se utilizzi Pub/Sub come origine dati, puoi attivare un datastream separato per i test end-to-end tramite sottoscrizioni aggiuntive agli argomenti esistenti. Puoi quindi confrontare i risultati di diverse pipeline che utilizzano gli stessi dati, il che è utile per verificare le pipeline candidate rispetto ad altre pipeline di preproduzione e produzione.
Il seguente diagramma mostra come questo metodo consente l'esecuzione parallela di una pipeline di produzione e di 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 pertanto evita di utilizzare la quota di sottoscrittori Pub/Sub per il progetto di produzione.
A differenza delle pipeline batch, le pipeline di streaming continuano a essere eseguite finché non vengono annullate esplicitamente. Nei test end-to-end, devi decidere se lasciare la pipeline in esecuzione, magari fino al 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 che utilizzi influisce su questa decisione. Ad esempio, se utilizzi un insieme limitato di dati di test forniti alla pipeline di streaming, puoi annullare la pipeline quando tutti gli elementi hanno completato l'elaborazione. In alternativa, se utilizzi un'origine dati reale, ad esempio un argomento Pub/Sub esistente utilizzato in produzione, o se generi continuamente dati di test, potresti voler mantenere in esecuzione le pipeline di test per un periodo di tempo più lungo. Quest'ultimo ti consente di confrontare il comportamento con l'ambiente di produzione o anche con altre pipeline di test.