Développer et tester des pipelines Dataflow

Cette page présente les bonnes pratiques pour développer et tester votre pipeline Dataflow.

Présentation

La manière dont le code de votre pipeline est mis en œuvre a une incidence significative sur les performances du pipeline en production. Pour vous aider à créer un code de pipeline qui fonctionne correctement et efficacement, ce document explique les points suivants:

Les exécuteurs de pipeline acceptent l'exécution du code à différentes étapes du développement et du déploiement.
Les environnements de déploiement vous permettant d'exécuter des pipelines pendant le développement, les tests, la préproduction et la production.
Le code et les modèles de pipeline Open Source que vous pouvez utiliser tels quels ou comme base pour de nouveaux pipelines afin d'accélérer le développement du code.
Méthode recommandée pour tester le code du pipeline. Tout d'abord, ce document décrit en détail le champ d'application et la relation de différents types de test, tels que les tests unitaires, les tests d'intégration et les tests de bout en bout. Ensuite, chaque type de test est décrit en détail, y compris les méthodes pour créer et intégrer des données de test, et les exécuteurs de pipeline à utiliser pour chaque test.

Exécuteurs de pipeline

Pendant le développement et les tests, vous utilisez différents outils Apache Beam pour exécuter le code de pipeline. Le SDK Apache Beam fournit un outil d'exécution Direct Runner pour le développement et les tests locaux. Vos outils d'automatisation des versions peuvent également utiliser Direct Runner pour les tests unitaires et les tests d'intégration. Par exemple, vous pouvez utiliser Direct Runner dans votre pipeline d'intégration continue (CI).

Les pipelines déployés dans Dataflow utilisent l'outil d'exécution Dataflow, qui exécute votre pipeline dans des environnements de type production. De plus, vous pouvez utiliser l'exécuteur Dataflow pour effectuer des tests de développement ad hoc et des tests de pipeline de bout en bout.

Bien que cette page se concentre sur l'exécution de pipelines créés à l'aide du SDK Java Apache Beam, Dataflow est également compatible avec les pipelines Apache Beam développés à l'aide de Python et Go. Les SDK Apache Beam pour Java, Python et Go sont en disponibilité générale pour Dataflow. Les développeurs SQL peuvent également utiliser Apache Beam SQL pour créer des pipelines utilisant des dialectes SQL courants.

Configurer un environnement de déploiement

Pour séparer les utilisateurs, les données, le code et les autres ressources à différentes étapes de développement, créez des environnements de déploiement. Dans la mesure du possible, utilisez des projets Google Cloud distincts pour fournir des environnements isolés pour les différentes étapes de développement du pipeline.

Les sections suivantes décrivent un ensemble typique d'environnements de déploiement.

Environnement local

L'environnement local est un poste de travail de développeur. Pour le développement et les tests rapides, utilisez Direct Runner afin d'exécuter le code de pipeline localement.

Les pipelines exécutés localement à l'aide de Direct Runner peuvent interagir avec des ressources Google Cloud distantes, telles que des sujets Pub/Sub ou des tables BigQuery. Attribuez à chaque développeur des projets Google Cloud distincts, afin qu'ils disposent d'un bac à sable pour les tests ad hoc sur les services Google Cloud.

Certains services Google Cloud, tels que Pub/Sub et Bigtable, fournissent des émulateurs pour le développement local. Vous pouvez utiliser ces émulateurs avec l'outil d'exécution Direct Runner afin de permettre le développement et les tests locaux de bout en bout.

Environnement de bac à sable

L'environnement de bac à sable est un projet Google Cloud qui permet aux développeurs d'accéder aux services Google Cloud lors du développement du code. Les développeurs de pipeline peuvent partager un projet Google Cloud avec d'autres développeurs ou utiliser leurs propres projets individuels. L'utilisation de projets individuels réduit la complexité de la planification liée à l'utilisation des ressources partagées et à la gestion des quotas.

Les développeurs utilisent l'environnement de bac à sable pour exécuter des pipelines ad hoc à l'aide de l'exécuteur Dataflow. L'environnement de bac à sable est utile pour déboguer et tester le code sur un exécuteur de production pendant la phase de développement du code. Par exemple, l'exécution de pipelines ad hoc permet aux développeurs d'effectuer les opérations suivantes :

Observer l'effet des modifications du code sur le comportement du scaling.
Découvrir les différences potentielles entre le comportement des outils d'exécution Direct Runner et Dataflow Runner.
Découvrir comment Dataflow applique les optimisations de graphiques.

Pour les tests ad hoc, les développeurs peuvent déployer du code depuis leur environnement local afin d'exécuter Dataflow dans leur environnement de bac à sable.

Environnement de préproduction

L'environnement de préproduction est destiné aux phases de développement qui doivent s'exécuter dans des conditions de type production, telles que des tests de bout en bout. Utilisez un projet distinct pour l'environnement de préproduction et configurez-le afin qu'il soit aussi semblable à la production que possible. De même, pour permettre des tests de bout en bout avec un scaling de type production, définissez pour Dataflow et les autres services des quotas de projet Google Cloud aussi proches que possible de ceux de l'environnement de production.

En fonction de vos besoins, vous pouvez diviser la préproduction en plusieurs environnements. Par exemple, un environnement de contrôle qualité peut aider les analystes qualité à tester des objectifs de niveau de service (SLO), tels que l'exactitude, l'actualisation et les performances des données dans différentes conditions de charges de travail.

Les tests de bout en bout incluent l'intégration avec des sources et des récepteurs de données dans le cadre des tests. Réfléchissez à la manière de les rendre disponibles dans l'environnement de préproduction. Les données de test peuvent être stockées dans l'environnement de préproduction lui-même. Par exemple, les données de test sont stockées dans un bucket Cloud Storage avec vos données d'entrée. Dans d'autres cas, les données de test peuvent provenir de l'extérieur de l'environnement de préproduction, tel qu'un sujet Pub/Sub (via un abonnement distinct) dans l'environnement de production. Pour les pipelines de traitement par flux, vous pouvez également exécuter des tests de bout en bout à l'aide de données générées (par exemple, en utilisant le générateur de flux de données Dataflow) pour émuler des caractéristiques et des volumes semblables à ceux de production.

Pour les pipelines de traitement par flux, utilisez l'environnement de préproduction pour tester les mises à jour du pipeline avant toute modification en production. Il est important de tester et de vérifier les procédures de mise à jour des pipelines de traitement par flux, en particulier si vous devez coordonner plusieurs étapes (comme l'exécution de pipelines parallèles) pour éviter un temps d'arrêt.

Environnement de production

L'environnement de production est un projet Google Cloud dédié. La livraison continue copie les artefacts de déploiement dans l'environnement de production une fois tous les tests de bout en bout terminés.

Bonnes pratiques de développement

Consultez les bonnes pratiques pour les pipelines Dataflow.

Tester votre pipeline

Dans le développement logiciel, les tests unitaires, les tests d'intégration et les tests de bout en bout sont des types courants de tests logiciels. Ces types de tests s'appliquent également aux pipelines de données.

Le SDK Apache Beam fournit des fonctionnalités permettant ces tests. Dans l'idéal, chaque type de test cible un environnement de déploiement différent. Le schéma suivant montre comment les tests unitaires, les tests d'intégration et les tests de bout en bout s'appliquent à différentes parties de votre pipeline et de vos données.

Types de tests et leur relation avec les transformations, les pipelines, les sources de données et les récepteurs de données.

Le schéma montre le champ d'application des différents tests et leur relation avec les transformations (sous-classes DoFn et PTransform), les pipelines, les sources de données et les récepteurs de données.

Les sections suivantes expliquent comment divers tests logiciels formels s'appliquent aux pipelines de données utilisant Dataflow. Lorsque vous lisez cette section, reportez-vous au schéma pour comprendre les relations entre les différents types de tests.

Échantillonnage de données

Pour observer les données à chaque étape d'un pipeline Dataflow, activez l'échantillonnage de données pendant les tests. Cela vous permet d'afficher les sorties des transformations pour vous assurer que le résultat est correct.

Tests unitaires

Les tests unitaires évaluent le bon fonctionnement des sous-classes DoFn et des transformations composites (sous-classes PTransform) en comparant le résultat de ces transformations avec un ensemble vérifié d'entrées et de sorties de données. En règle générale, les développeurs peuvent exécuter ces tests dans l'environnement local. Les tests peuvent également s'exécuter automatiquement via l'automatisation des tests unitaires à l'aide de l'intégration continue (CI) dans l'environnement de compilation.

L'outil Direct Runner exécute des tests unitaires à l'aide d'un sous-ensemble plus petit de données de test de référence visant à tester la logique métier de vos transformations. Les données de test doivent être suffisamment petites pour rentrer dans la mémoire locale de la machine qui exécute le test.

Le SDK Apache Beam fournit une règle JUnit appelée TestPipeline pour effectuer des tests unitaires sur des transformations individuelles (sous-classes DoFn), des transformations composites (sous-classes PTransform) et des pipelines entiers. Vous pouvez utiliser TestPipeline sur un exécuteur de pipeline Apache Beam tel que Direct Runner ou Dataflow Runner pour appliquer des assertions sur le contenu des objets PCollection à l'aide de PAssert, comme indiqué dans l'extrait de code suivant issu d'une classe de 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();
}

Tests unitaires pour des transformations individuelles

En factorisant votre code dans des transformations réutilisables (par exemple, en tant que classes imbriquées de premier niveau ou statiques), vous pouvez créer des tests ciblés pour différentes parties de votre pipeline. Outre les avantages des tests, les transformations réutilisables améliorent la gestion et la réutilisation du code en encapsulant naturellement la logique métier de votre pipeline en parties composantes. En revanche, il peut être difficile de tester des parties individuelles de votre pipeline si celui-ci utilise des classes internes anonymes pour mettre en œuvre des transformations.

L'extrait de code Java suivant montre la mise en œuvre des transformations en tant que classes internes anonymes, ce qui ne permet pas de tester facilement.

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());

Comparez l'exemple précédent avec le suivant, dans lequel les classes internes anonymes ont été refactorisées en sous-classes DoFn concrètes nommées. Vous pouvez créer des tests unitaires individuels pour chaque sous-classe DoFn concrète qui compose le pipeline de bout en bout.

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());

Le test de chaque sous-classe DoFn est semblable aux tests unitaires de pipeline de traitement par lot contenant une seule transformation. Utilisez la transformation Create pour créer un objet PCollection de données de test, puis transmettez-le à l'objet DoFn. Utilisez PAssert pour indiquer que le contenu de l'objet PCollection est correct. L'exemple de code Java suivant utilise la classe PAssert pour vérifier que le formulaire de sortie est correct.

@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();
}

Tests d'intégration

Les tests d'intégration vérifient le bon fonctionnement de l'ensemble du pipeline. Envisagez d'utiliser les types de tests d'intégration suivants :

Un test d'intégration de transformation qui évalue la fonctionnalité intégrée de toutes les transformations individuelles qui composent votre pipeline de données. Considérez les tests d'intégration des transformations comme un test unitaire pour l'ensemble de votre pipeline, à l'exclusion de l'intégration avec les récepteurs et les sources de données externes. Le SDK Apache Beam offre des méthodes pour fournir des données de test à votre pipeline de données et vérifier les résultats du traitement. Direct Runner est utilisé pour exécuter des tests d'intégration de transformation.
Un test d'intégration système qui évalue l'intégration de votre pipeline de données à des sources et récepteurs de données externes en ligne. Pour que le pipeline communique avec les systèmes externes, vous devez configurer vos tests avec les identifiants appropriés afin d'accéder à des services externes. Les pipelines de traitement par flux s'exécutent indéfiniment. Vous devez donc décider quand et comment arrêter le pipeline en cours d'exécution. En utilisant Direct Runner pour exécuter des tests d'intégration système, vous pouvez vérifier rapidement l'intégration entre votre pipeline et d'autres systèmes sans avoir à soumettre une tâche Dataflow et à attendre qu'elle se termine.

Remarque : Un petit test de bout en bout est souvent exécuté à la place d'un test d'intégration de système. Le test de bout en bout utilise l'outil Dataflow Runner et un petit ensemble de données de test pour vérifier que le pipeline complet fonctionne correctement, y compris son intégration aux sources de données, aux récepteurs de données et à d'autres systèmes externes.

Concevez des tests d'intégration de système et de transformation pour permettre la rapidité de la détection des défauts et de l'envoi de commentaires sans ralentir la productivité des développeurs. Pour les tests dont l'exécution est plus longue, tels que ceux qui s'exécutent en tant que tâches Dataflow, il peut être judicieux d'utiliser un test de bout en bout dont l'exécution est moins fréquente.

Vous pouvez considérer un pipeline de données comme une ou plusieurs transformations associées. Vous pouvez créer une transformation composite d'encapsulation pour votre pipeline et utiliser TestPipeline pour effectuer un test d'intégration sur l'ensemble du pipeline. Selon que vous souhaitez tester le pipeline en mode de traitement par lot ou par flux, vous fournissez des données de test à l'aide de Create ou de TestStream.

Utiliser des données de test pour les tests d'intégration

Dans votre environnement de production, votre pipeline s'intègre probablement à différentes sources et récepteurs de données. Toutefois, dans le cas des tests unitaires et des tests d'intégration de transformation, concentrez-vous sur la vérification de la logique métier du code de pipeline en fournissant des entrées de test et en contrôlant directement la sortie. En plus de simplifier vos tests, cette approche vous permet d'isoler les problèmes spécifiques aux pipelines de ceux qui pourraient être dus aux sources et aux récepteurs de données.

Tester les pipelines de traitement par lot

Pour les pipelines par lot, utilisez la transformation Create pour créer un objet PCollection de vos données de test d'entrée à partir d'une collection en mémoire standard, telle qu'un objet Java List. L'utilisation de la transformation Create est appropriée si vos données de test sont suffisamment petites pour être incluses dans le code. Vous pouvez ensuite utiliser PAssert sur les objets de sortie PCollection pour déterminer l'exactitude du code de votre pipeline. Cette approche est acceptée par l'exécuteur Direct Runner et l'exécuteur Dataflow.

L'extrait de code Java suivant montre les assertions par rapport aux objets de sortie PCollection provenant d'une transformation composite qui inclut tout ou partie des transformations individuelles qui constituent un pipeline (WeatherStatsPipeline). Cette approche est semblable à celle permettant d'effectuer des tests unitaires sur les transformations individuelles dans un 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();
}

Pour tester le comportement de fenêtrage, vous pouvez également utiliser la transformation Create pour créer des éléments avec des horodatages, comme indiqué dans l'extrait de code suivant :

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();
}

Tester les pipelines de traitement par flux

Les pipelines de traitement par flux contiennent des hypothèses qui définissent comment gérer des données illimitées. Ces hypothèses sont souvent liées à la chronologie des données dans des conditions réelles. Elles ont donc un impact sur l'exactitude si les hypothèses s'avèrent vraies ou fausses. Les tests d'intégration pour les pipelines de traitement par flux incluent donc idéalement des tests qui simulent la nature non déterministe de l'arrivée des données en flux continu.

Afin de permettre de tels tests, le SDK Apache Beam fournit la classe TestStream pour modéliser les effets des minutages d'éléments (anticipé, à l'heure, tardif) sur les résultats de votre pipeline de données. Utilisez ces tests avec la classe PAssert pour vérifier en comparant avec les résultats attendus.

TestStream est compatible avec Direct Runner et l'exécuteur Dataflow. L'exemple de code suivant crée une transformation 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();
}

Pour plus d'informations sur TestStream, consultez la page Tester les pipelines illimités dans Apache Beam. Pour en savoir plus sur l'utilisation du SDK Apache Beam pour les tests unitaires, consultez la documentation Apache Beam.

Utiliser les services Google Cloud dans les tests d'intégration

Direct Runner peut s'intégrer aux services Google Cloud afin que les tests ad hoc dans l'environnement local et les tests d'intégration système puissent utiliser Pub/Sub, BigQuery et d'autres services si nécessaire. Lorsque vous utilisez Direct Runner, votre pipeline s'exécute en tant que compte utilisateur que vous avez configuré à l'aide de l'outil de ligne de commande gcloud ou en tant que compte de service. que vous avez spécifiée à l'aide de la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS. Par conséquent, vous devez accorder des autorisations suffisantes à ce compte pour toutes les ressources requises avant d'exécuter votre pipeline. Pour en savoir plus, consultez la section Sécurité et autorisations pour Cloud Dataflow.

Pour les tests d'intégration entièrement local, vous pouvez utiliser des émulateurs locaux pour certains services Google Cloud. Les émulateurs locaux sont disponibles pour Pub/Sub et Bigtable.

Pour les tests d'intégration de système des pipelines de traitement par flux, vous pouvez utiliser la méthode setBlockOnRun (définie dans l'interface DirectOptions) pour que l'outil Direct Runner exécute le pipeline de manière asynchrone. Sinon, l'exécution du pipeline bloque le processus parent de l'appel (par exemple, un script de votre pipeline de compilation) jusqu'à ce que le pipeline soit arrêté manuellement. Si vous exécutez le pipeline de manière asynchrone, vous pouvez utiliser l'instance PipelineResult renvoyée pour annuler l'exécution du pipeline, comme indiqué dans l'exemple de code suivant :

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();
}

Tests de bout en bout

Les tests de bout en bout vérifient le bon fonctionnement de votre pipeline de bout en bout en l'exécutant sur l'outil Dataflow Runner dans des conditions qui ressemblent beaucoup à la production. Les tests vérifient que la logique métier fonctionne correctement à l'aide de l'exécuteur Dataflow et vérifient que le pipeline fonctionne comme prévu sous des charges de type production. Vous effectuez généralement des tests de bout en bout dans un projet Google Cloud dédié qui est désigné comme environnement de préproduction.

Pour tester votre pipeline à différentes échelles, utilisez différents types de tests de bout en bout, par exemple :

Exécutez des tests de bout en bout à petite échelle à l'aide d'une petite proportion (1 %, par exemple) de votre ensemble de données de test pour valider rapidement la fonctionnalité de pipeline dans l'environnement de préproduction.
Exécutez des tests de bout en bout à grande échelle à l'aide d'un ensemble de données de test complet pour valider les fonctionnalités du pipeline selon des conditions et volumes de données de production.

Pour les pipelines de traitement par flux, nous vous recommandons d'exécuter des pipelines de test en parallèle avec le pipeline de production s'ils peuvent utiliser les mêmes données. Ce processus vous permet de comparer les résultats et le comportement opérationnel tel que l'autoscaling et les performances.

Les tests de bout en bout aident à prédire si votre pipeline atteint vos SLO de production. L'environnement de préproduction teste votre pipeline dans des conditions de production. Dans le cadre de tests de bout en bout, les pipelines s'exécutent à l'aide de l'exécuteur Dataflow pour traiter des ensembles de données complets de référence qui correspondent (ou ressemblent) à des ensembles de données en production.

Il est possible que vous ne puissiez pas générer de données synthétiques pour des tests qui simulent avec précision des données réelles. Pour résoudre ce problème, une approche consiste à utiliser des extraits nettoyés des sources de données de production pour créer des ensembles de données de référence dans lesquels toutes les données sensibles sont supprimées via des transformations appropriées. Nous vous recommandons d'utiliser la protection des données sensibles à cette fin. La protection des données sensibles peut détecter les données sensibles provenant de différents types de contenus et sources de données, et appliquer une plage de techniques de suppression de l'identification, y compris l'effacement, le masquage, le chiffrement préservant le format et le changement de date.

Différences entre les tests de bout en bout pour les pipelines de traitement par lot et par flux

Avant d'exécuter un test complet de bout en bout sur un ensemble de données de test volumineux, vous pouvez exécuter une simulation avec un pourcentage inférieur des données de test (par exemple, 1 %) et vérifier le comportement attendu dans un délai plus court. Comme pour les tests d'intégration avec Direct Runner, vous pouvez utiliser PAssert sur des objets PCollection lorsque vous exécutez des pipelines à l'aide de l'exécuteur Dataflow. Pour en savoir plus sur PAssert, consultez la section Tests unitaires de cette page.

En fonction de votre cas d'utilisation, la vérification de résultats très volumineux issus de tests de bout en bout peut s'avérer peu pratique, coûteuse ou difficile. Dans ce cas, vous pouvez valider des exemples représentatifs à partir de l'ensemble de résultats généré. Par exemple, vous pouvez utiliser BigQuery pour échantillonner et comparer des lignes de sortie avec un ensemble de données de référence des résultats attendus.

Pour les pipelines de traitement par flux, si la simulation des conditions de streaming réalistes avec des données synthétiques peut s'avérer difficile. Un moyen courant de fournir des données en flux continu pour les tests de bout en bout consiste à intégrer les tests aux sources de données de production. Si vous utilisez Pub/Sub en tant que source de données, vous pouvez activer un flux de données distinct pour les tests de bout en bout via des abonnements supplémentaires à des sujets existants. Vous pouvez ensuite comparer les résultats de différents pipelines qui consomment les mêmes données, ce qui est utile pour comparer les pipelines candidats à d'autres pipelines de préproduction et de production.

Le schéma suivant montre comment cette méthode permet à un pipeline de production et à un pipeline de test de s'exécuter en parallèle dans différents environnements de déploiement.

Exécuter un pipeline de test en parallèle d'un pipeline de production à l'aide d'une seule source de données par flux Pub/Sub

Dans le schéma, les deux pipelines lisent des données à partir du même sujet Pub/Sub, mais ils utilisent des abonnements distincts. Cette configuration permet aux deux pipelines de traiter les mêmes données indépendamment et de comparer les résultats. Le pipeline de test utilise un compte de service distinct du projet de production et évite donc d'utiliser le quota d'abonné Pub/Sub pour le projet de production.

Contrairement aux pipelines par lots, les pipelines de traitement par flux continuent de s'exécuter jusqu'à leur annulation explicite. Dans les tests de bout en bout, vous devez décider de laisser le pipeline en cours d'exécution (peut-être jusqu'au prochain test de bout en bout) ou d'annuler le pipeline à un moment qui représente la fin du test pour pouvoir inspecter les résultats.

Le type de données de test que vous utilisez influence cette décision. Par exemple, si vous utilisez un ensemble limité de données de test fournies au pipeline de traitement par flux, vous pouvez annuler le pipeline lorsque tous les éléments auront été traités. Si vous utilisez une source de données réelle (telle qu'un sujet Pub/Sub existant utilisé en production) ou si vous générez des données de test en continu, conservez des pipelines de test en cours d'exécution pendant une longue période. Cela vous permet de comparer le comportement par rapport à l'environnement de production, voire même avec d'autres pipelines de test.