En esta página, se proporcionan prácticas recomendadas para desarrollar y probar tu canalización de Dataflow.
Descripción general
La forma en que se implementa el código de la canalización tiene una influencia significativa en su rendimiento en producción. Para ayudarte a crear un código de canalización que funcione de forma correcta y eficiente, en este documento se explica lo siguiente:
- Ejecutores de canalización para admitir la ejecución de código en las diferentes etapas del desarrollo y la implementación.
- Entornos de implementación que te permiten ejecutar canalizaciones durante el desarrollo, las pruebas, la producción previa y la producción.
- Plantillas y código de canalización de código abierto que puedes usar sin modificaciones o como base para que las canalizaciones nuevas aceleren el desarrollo del código.
- Un enfoque de prácticas recomendadas para probar el código de canalización. En primer lugar, en este documento, se proporciona una descripción general que incluye el alcance y la relación de los diferentes tipos de prueba, como las pruebas de unidades, las de integración y las de extremo a extremo. En segundo lugar, cada tipo de prueba se explora en detalle, incluidos los métodos para crear e integrar con datos de prueba, y qué ejecutores de canalización usar en cada prueba.
Ejecutores de canalizaciones
Durante el desarrollo y las pruebas, usas diferentes ejecutores de Apache Beam para ejecutar código de canalización. El SDK de Apache Beam proporciona un ejecutor directo para el desarrollo y las pruebas locales. Las herramientas de automatización de versiones también pueden usar el Ejecutor directo para pruebas de unidades y de integración. Por ejemplo, puedes usar el Ejecutor directo dentro de tu canalización de integración continua (CI).
Las canalizaciones que se implementan en Dataflow usan el ejecutor de Dataflow, que ejecuta la canalización en entornos similares a la producción. Además, puedes usar el ejecutor de Dataflow para las pruebas de desarrollo ad hoc y las pruebas de canalización de extremo a extremo.
Aunque esta página se centra en la ejecución de canalizaciones compiladas con el SDK de Java de Apache Beam, Dataflow también admite canalizaciones de Apache Beam que se desarrollaron con Python y Go. Los SDK de Java, Python y Go para Apache Beam tienen disponibilidad general para Dataflow. Los desarrolladores de SQL también pueden usar SQL de Apache Beam para crear canalizaciones que usen dialectos de SQL familiares.
Configura un entorno de implementación
Para separar usuarios, datos, código y otros recursos en diferentes etapas del desarrollo, crea entornos de implementación. Cuando sea posible, usa proyectos de Google Cloud separados para proporcionar entornos aislados para las diferentes etapas del desarrollo de la canalización.
En las siguientes secciones, se describe un conjunto típico de entornos de implementación.
Entorno local
El entorno local es una estación de trabajo para desarrolladores. Para el desarrollo y las pruebas rápidas, usa el Ejecutor directo para ejecutar el código de canalización de manera local.
Las canalizaciones que se ejecutan de manera local mediante el ejecutor directo pueden interactuar con recursos remotos de Google Cloud, como temas de Pub/Sub o tablas de BigQuery. Proporciona a los desarrolladores individuales proyectos de Google Cloud diferentes a fin de que tengan una zona de pruebas para pruebas ad hoc con los servicios de Google Cloud.
Algunos servicios de Google Cloud, como Pub/Sub y Bigtable, proporcionan emuladores para el desarrollo local. Puedes usar estos emuladores con el ejecutor directo para habilitar el desarrollo y las pruebas locales de extremo a extremo.
Entorno de zona de pruebas
El entorno de la zona de pruebas es un proyecto de Google Cloud que brinda a los desarrolladores acceso a los servicios de Google Cloud durante el desarrollo del código. Los desarrolladores de canalizaciones pueden compartir un proyecto de Google Cloud con otros desarrolladores o usar sus propios proyectos individuales. Usar proyectos individuales reduce la complejidad de la planificación relacionada con el uso compartido de recursos y la administración de cuotas.
Los desarrolladores usan el entorno de la zona de pruebas para ejecutar la canalización ad hoc mediante el ejecutor de Dataflow. El entorno de zona de pruebas es útil para depurar y probar código en un ejecutor de producción durante la fase de desarrollo del código. Por ejemplo, la ejecución de la canalización ad hoc permite a los desarrolladores hacer lo siguiente:
- Observa el efecto de los cambios de código en el comportamiento del escalamiento.
- Comprende las posibles diferencias entre el comportamiento del ejecutor directo y el ejecutor de Dataflow.
- Comprende cómo Dataflow aplica optimizaciones de gráficos.
Para la prueba ad hoc, los desarrolladores pueden implementar código desde su entorno local a fin de ejecutar Dataflow dentro del entorno de zona de pruebas.
Entorno de producción previa
El entorno de producción previa es para las fases de desarrollo que deben ejecutarse en condiciones similares a la producción, como pruebas de extremo a extremo. Usa un proyecto separado para el entorno de producción previa y configúralo de la manera más similar posible. Del mismo modo, a fin de permitir pruebas de extremo a extremo con escalamiento similar a la producción, haz que las cuotas del proyecto de Google Cloud para Dataflow y otros servicios sean lo más similares posible al entorno de producción.
Según tus requisitos, puedes separar la producción previa en varios entornos. Por ejemplo, un entorno de control de calidad puede admitir el trabajo de analistas de calidad para probar los objetivos de nivel de servicio (SLO), como la precisión de los datos, la actualización y el rendimiento en diferentes condiciones de carga de trabajo.
Las pruebas de extremo a extremo incluyen integración en las fuentes de datos y los receptores dentro del alcance de las pruebas. Ten en cuenta cómo puedes hacer que estén disponibles en el entorno de producción previa. Puedes almacenar los datos de prueba en el entorno de producción previa. Por ejemplo, los datos de prueba se almacenan en un bucket de Cloud Storage con tus datos de entrada. En otros casos, los datos de prueba pueden originarse fuera del entorno de producción previa, como en un tema de Pub/Sub (a través de una suscripción separada) que está en el entorno de producción. Para las canalizaciones de transmisión, también puedes ejecutar pruebas de extremo a extremo mediante datos generados (por ejemplo, mediante el Generador de datos de transmisión de Dataflow) a fin de emular las características y los volúmenes de datos similares a los de producción.
En las canalizaciones de transmisión, usa el entorno de producción previa para probar las actualizaciones de canalización antes de que se realicen cambios en la producción. Es importante probar y verificar los procedimientos de actualización de las canalizaciones de transmisión, en especial si necesitas coordinar varios pasos, como cuando ejecutas canalizaciones paralelas para evitar el tiempo de inactividad.
Entorno de producción
El entorno de producción es un proyecto dedicado de Google Cloud. La entrega continua copia los artefactos de implementación en el entorno de producción cuando se pasaron todas las pruebas de extremo a extremo.
Prácticas recomendadas de desarrollo
Consulta las prácticas recomendadas para canalizaciones de Dataflow.
Prueba tu canalización
En el desarrollo de software, las pruebas de unidades, las pruebas de integración y las pruebas de extremo a extremo son tipos comunes de pruebas de software. Estos tipos de pruebas también se aplican a las canalizaciones de datos.
El SDK de Apache Beam proporciona funcionalidad para habilitar estas pruebas. Lo ideal es que cada tipo de prueba se oriente a un entorno de implementación diferente. En el siguiente diagrama, se ilustra cómo las pruebas de unidades, las pruebas de integración y las pruebas de extremo a extremo se aplican a diferentes partes de la canalización y los datos.
En el diagrama, se muestra el alcance de las diferentes pruebas y cómo se relacionan con las transformaciones (subclases DoFn y PTransform), las canalizaciones, las fuentes de datos y los receptores de datos.
En las siguientes secciones, se describe cómo se aplican varias pruebas formales de software a las canalizaciones de datos mediante Dataflow. A medida que leas esta sección, consulta este diagrama para comprender cómo se relacionan los diferentes tipos de pruebas.
Muestreo de datos
Para observar los datos en cada paso de una canalización de Dataflow, habilita el muestreo de datos durante las pruebas. Esto te permite ver los resultados de las transformaciones para asegurarte de que sean correctos.
Pruebas de unidades
Las pruebas de unidades evalúan el funcionamiento correcto de las subclases DoFn y las transformaciones compuestas (subclases PTransform) mediante la comparación del resultado de esas transformaciones con un conjunto de datos de entradas y salidas verificado. Por lo general, los desarrolladores pueden ejecutar estas pruebas en el entorno local. Las pruebas también pueden ejecutarse de forma automática a través de la automatización de pruebas de unidades mediante la integración continua (CI) en el entorno de compilación.
El Ejecutor directo ejecuta pruebas de unidades mediante un subconjunto más pequeño de datos de prueba de referencia que se enfoca en probar la lógica empresarial de las transformaciones. Los datos de prueba deben ser los suficientemente pequeños para caber la memoria local en la máquina que ejecuta la prueba.
El SDK de Apache Beam proporciona una regla JUnit llamada TestPipeline para transformaciones individuales de prueba de unidades (subclases DoFn), transformaciones compuestas (PTransform subclases) y canalizaciones completas. Puedes usar TestPipeline en un ejecutor de canalización de Apache Beam, como el ejecutor directo o el ejecutor de Dataflow para aplicar aserciones sobre el contenido de objetos PCollection mediante PAssert, como se muestra en el siguiente fragmento de código de una clase de prueba 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();
}
Pruebas de unidades para transformaciones individuales
Si factorizas el código en transformaciones reutilizables, por ejemplo, como clases anidadas estáticas o de nivel superior, puedes crear pruebas orientadas para diferentes partes de la canalización. Además de las ventajas que ofrecen las pruebas, las transformaciones reutilizables mejoran la capacidad de mantener y de reutilizar el código mediante el encapsulamiento de la lógica empresarial de la canalización en partes de componentes. En cambio, probar partes individuales de la canalización puede ser difícil si la canalización usa clases internas anónimas para implementar transformaciones.
En el siguiente fragmento de Java, se muestra la implementación de transformaciones como clases internas anónimas, que no permiten una prueba sencilla.
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());
Compara el ejemplo anterior con el siguiente, en el que las clases internas anónimas se refactorizaron en subclases DoFn concretas con nombre. Puedes crear pruebas de unidades individuales para cada subclase DoFn concreta que forma la canalización de extremo a extremo.
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());
Probar cada subclase DoFn es similar a la prueba de unidades de una canalización por lotes que contiene una sola transformación. Usa la transformación Create para crear un objeto PCollection de datos de prueba y, luego, pásalo al objeto DoFn. Usa PAssert para confirmar que el contenido del objeto PCollection es correcto. En la siguiente muestra de código de Java, se usa la clase PAssert para verificar el formato de salida correcto.
@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();
}
Pruebas de integración
Las pruebas de integración verifican el funcionamiento correcto de toda la canalización. Considera los siguientes tipos de pruebas de integración:
- Una prueba de integración de transformación que evalúa la funcionalidad integrada de todas las transformaciones individuales que conforman la canalización de datos. Piensa en las pruebas de integración de transformación como una prueba de unidades para toda la canalización, sin incluir la integración con receptores y fuentes de datos externos. El SDK de Apache Beam proporciona métodos para suministrar datos de prueba a la canalización de datos y verificar los resultados de procesamiento. El ejecutor directo se usa para ejecutar pruebas de integración de transformaciones.
Una prueba de integración del sistema que evalúa la integración de la canalización de datos con receptores y fuentes de datos en vivo. Para que la canalización se comunique con sistemas externos, debes configurar las pruebas con las credenciales adecuadas a fin de acceder a servicios externos. Las canalizaciones de transmisión se ejecutan de forma indefinida, por lo que debes decidir cuándo y cómo detener la canalización en ejecución. Cuando usas el ejecutor directo para ejecutar pruebas de integración del sistema, puedes verificar con rapidez la integración entre la canalización y otros sistemas sin necesidad de enviar un trabajo de Dataflow y esperar a que termine.
Diseña pruebas de integración de sistemas y de transformación para proporcionar una detección rápida de defectos y comentarios sin ralentizar la productividad del desarrollador. Para las pruebas más prolongadas, como las que se ejecutan como trabajos de Dataflow, te recomendamos que uses una prueba de extremo a extremo que se ejecute con menos frecuencia.
Piensa en una canalización de datos como una o más transformaciones relacionadas. Puedes crear una transformación compuesta de encapsulamiento para la canalización y usar TestPipeline a fin de realizar una prueba de integración de toda la canalización. Según si deseas probar la canalización en el modo por lotes o de transmisión, debes proporcionar datos de prueba mediante las transformaciones Create o TestStream.
Usa datos de prueba para las pruebas de integración
En el entorno de producción, es probable que la canalización se integre a diferentes receptores y fuentes de datos. Sin embargo, para las pruebas de unidades y las de integración de transformación, enfócate en verificar la lógica empresarial del código de la canalización mediante entradas de prueba y la verificación directa del resultado. Además de simplificar las pruebas, este enfoque te permite aislar los problemas específicos de la canalización de aquellos que pueden causarse por receptores y fuentes de datos.
Prueba las canalizaciones por lotes
Para las canalizaciones por lotes, usa la transformación Create a fin de crear un objeto PCollection de los datos de prueba de entrada a partir de una colección en memoria estándar, como un objeto List de Java. El uso de la transformación Create es adecuado si los datos de prueba son demasiado pequeños como para incluirlos en el código. Luego, puedes usar PAssert en los objetos PCollection de salida para determinar la precisión del código de canalización.
Este enfoque es compatible con el ejecutor directo y el ejecutor de Dataflow.
El siguiente fragmento de código de Java muestra aserciones en objetos PCollection de salida de una transformación compuesta que incluye algunas o todas las transformaciones individuales que constituyen una canalización (WeatherStatsPipeline). El enfoque es similar a realizar pruebas de unidades de transformaciones individuales en una canalización.
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 probar el comportamiento del sistema de ventanas, también puedes usar la transformación Create a fin de crear elementos con marcas de tiempo, como se muestra en el siguiente 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();
}
Prueba las canalizaciones de transmisión
Las canalizaciones de transmisión contienen suposiciones que definen cómo manejar los datos no delimitados. Estas suposiciones suelen tener en cuenta la puntualidad de los datos en condiciones reales y, por lo tanto, afectan la precisión en función de si las suposiciones son verdaderas o falsas. Idealmente, las pruebas de integración para las canalizaciones de transmisión incluyen pruebas que simulan la naturaleza no determinista de la llegada de datos de transmisión.
Para habilitar esas pruebas, el SDK de Apache Beam proporciona la clase TestStream a fin de modelar los efectos de los tiempos de los elementos (temprano, a tiempo, o tardíos) en los resultados de la canalización de datos. Usa estas pruebas junto con la clase PAssert para verificar los resultados esperados.
TestStream es compatible con el ejecutor directo y el ejecutor de Dataflow. En la siguiente muestra de código, se crea una transformación 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();
}
Para obtener más información sobre TestStream, consulta Prueba canalizaciones no delimitadas en Apache Beam.
Si deseas obtener más información sobre cómo usar el SDK de Apache Beam para realizar pruebas de unidades, consulta la documentación de Apache Beam.
Usa los servicios de Google Cloud en las pruebas de integración
El ejecutor directo puede integrarse con los servicios de Google Cloud, por lo que las pruebas ad hoc en el entorno local y las pruebas de integración del sistema pueden usar Pub/Sub, BigQuery y otros servicios según sea necesario. Cuando usas el ejecutor directo, la canalización se ejecuta como la cuenta de usuario que configuraste con la herramienta de línea de comandos de gcloud o como una cuenta de servicio que especificaste con la variable de entorno GOOGLE_APPLICATION_CREDENTIALS. Por lo tanto, debes otorgar los permisos suficientes a esta cuenta para cualquier recurso necesario antes de ejecutar la canalización. Para obtener más detalles, consulta Seguridad y permisos de Dataflow.
A fin de realizar pruebas de integración locales por completo, puedes usar emuladores locales para algunos servicios de Google Cloud. Los emuladores locales están disponibles para Pub/Sub y Bigtable.
Para las pruebas de integración del sistema de las canalizaciones de transmisión, puedes usar el método setBlockOnRun (definido en la interfaz DirectOptions) a fin de que el ejecutor directo ejecute la canalización de manera asíncrona.
De lo contrario, la ejecución de la canalización bloqueará el proceso superior que realiza la llamada (por ejemplo, una secuencia de comandos en la canalización de compilación) hasta que la canalización se detenga de forma manual. Si ejecutas la canalización de manera asíncrona, puedes usar la instancia de PipelineResult que se muestra para cancelar la ejecución de la canalización, como se observa en la siguiente muestra 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();
}
Pruebas de extremo a extremo
Las pruebas de extremo a extremo verifican la operación correcta de la canalización de extremo a extremo mediante su ejecución en el ejecutor de Dataflow en condiciones muy similares a la producción. Las pruebas verifican que la lógica empresarial funcione de forma correcta con el ejecutor de Dataflow y prueban si la canalización funciona como se espera en cargas similares a la producción. En general, ejecutas pruebas de extremo a extremo en un proyecto de Google Cloud dedicado que se designó como el entorno de preproducción.
Para probar la canalización a diferentes escalas, usa diferentes tipos de pruebas de extremo a extremo, por ejemplo:
- Ejecuta pruebas de extremo a extremo a pequeña escala con una proporción pequeña (como el 1%) del conjunto de datos de prueba para validar con rapidez la funcionalidad de canalización en el entorno de producción previa.
- Ejecuta pruebas de extremo a extremo a gran escala con un conjunto de datos de prueba completo para validar la funcionalidad de canalización con volúmenes de datos y condiciones similares a los de producción.
Para las canalizaciones de transmisión, recomendamos que ejecutes canalizaciones de prueba en paralelo con la canalización de producción si pueden usar los mismos datos. Este proceso te permite comparar resultados y comportamientos operativos como el ajuste de escala automático y el rendimiento.
Las pruebas de extremo a extremo ayudan a predecir qué tan bien la canalización cumplirá con los SLOs de producción. El entorno de producción previa prueba tu canalización en condiciones similares a la producción. Dentro de las pruebas de extremo a extremo, las canalizaciones se ejecutan mediante el ejecutor de Dataflow para procesar conjuntos de datos de referencia completos que coincidan o sean muy similares con conjuntos de datos en producción.
Quizás no sea posible generar datos sintéticos para pruebas que simulan datos reales con exactitud. Para abordar este problema, un enfoque consiste en usar extractos limpios de fuentes de datos de producción con el fin de crear conjuntos de datos de referencia, en los que todos los datos sensibles se desidentifican mediante transformaciones adecuadas. Te recomendamos que uses la Sensitive Data Protection para este propósito. Sensitive Data Protection puede detectar datos sensibles de un rango de tipos de contenido y fuentes de datos, y aplicar una variedad de técnicas de desidentificación, que incluyen el ocultamiento, el enmascaramiento, la encriptación para preservar el formato y el cambio de fecha.
Diferencias en las pruebas de extremo a extremo para las canalizaciones por lotes y de transmisión
Antes de ejecutar una prueba completa de extremo a extremo en un conjunto de datos de prueba grande, te recomendamos llevar a cabo una prueba con un porcentaje menor de datos de prueba (como un uno por ciento) y verificar el comportamiento esperado en menos tiempo. Al igual que con las pruebas de integración en el ejecutor directo, puedes usar PAssert en objetos PCollection cuando ejecutas canalizaciones mediante el ejecutor de Dataflow. Para obtener más información sobre PAssert, consulta la sección Pruebas de unidades en esta página.
Según tu caso de uso, verificar los resultados muy grandes de pruebas de extremo a extremo puede ser poco práctico, costoso o difícil. En ese caso, puedes verificar muestras representativas desde el conjunto de resultados de salida. Por ejemplo, puedes usar BigQuery para realizar muestras y comparar filas de salida con un conjunto de datos de referencia de los resultados esperados.
Para las canalizaciones de transmisión, simular condiciones de transmisión realistas con datos sintéticos puede ser difícil. Una forma común de proporcionar datos de transmisión para pruebas de extremo a extremo es integrar las pruebas a las fuentes de datos de producción. Si usas Pub/Sub como una fuente de datos, puedes habilitar un flujo de datos por separado para pruebas de extremo a extremo a través de suscripciones adicionales a temas existentes. Luego, puedes comparar los resultados de diferentes canalizaciones que consumen los mismos datos, lo que es útil para verificar canalizaciones candidatas en otras canalizaciones de producción y producción previa.
En el siguiente diagrama, se muestra cómo este método permite que una canalización de producción y una canalización de prueba se ejecuten en paralelo en diferentes entornos de implementación.
En el diagrama, ambas canalizaciones leen desde el mismo tema de Pub/Sub, pero usan suscripciones separadas. Esta configuración permite que las dos canalizaciones procesen los mismos datos de forma independiente y te permite comparar los resultados. La canalización de prueba usa una cuenta de servicio independiente del proyecto de producción y, por lo tanto, evita usar la cuota de suscriptor de Pub/Sub para el proyecto de producción.
A diferencia de las canalizaciones por lotes, las canalizaciones de transmisión continúan en ejecución hasta que se cancelan de forma explícita. En las pruebas de extremo a extremo, debes decidir si quieres dejar la canalización en ejecución, tal vez hasta que se ejecute la siguiente prueba de extremo a extremo, o cancelar la canalización en un punto que represente la finalización de la prueba para inspeccionar los resultados.
El tipo de datos de prueba que usas influye en esta decisión. Por ejemplo, si usas un conjunto limitado de datos de prueba que se proporciona a la canalización de transmisión, es posible que canceles la canalización cuando todos los elementos finalizan su procesamiento. Como alternativa, si usas una fuente de datos real, como un tema de Pub/Sub existente que se usa en la producción, o si generas datos de prueba de forma continua, recomendamos mantener las canalizaciones de prueba en ejecución por un período más largo. Esto te permite comparar el comportamiento con el entorno de producción o incluso con otras canalizaciones de prueba.