Migrer les pipelines de données

Ce document décrit comment migrer vos pipelines de données en amont afin de charger des données dans votre entrepôt de données. Ce document vous aide à mieux comprendre ce qu'est un pipeline de données, et à connaître les procédures et modèles qu'un pipeline peut employer. Il vous permet aussi d'identifier les options et technologies de migration disponibles pour la migration d'un entrepôt de données.

Qu'est-ce qu'un pipeline de données ?

En informatique, un pipeline de données est un type d'application qui traite des données via une séquence d'étapes de traitement connectées. De façon générale, des pipelines de données peuvent être appliqués, par exemple, au transfert de données entre des systèmes d'information, à une procédure d'extraction, de transformation et de chargement (ETL), à l'enrichissement de données et à l'analyse de données en temps réel. Les pipelines de données sont habituellement exploités en tant que processus de traitement par lot qui exécutent et traitent les données lors de leur exécution, ou en tant que processus de traitement en flux continu qui s'exécutent en continu et traitent les données à mesure qu'elles deviennent disponibles pour le pipeline.

Dans le contexte de l'entreposage de données, les pipelines de données sont couramment utilisés pour lire des données à partir de systèmes transactionnels, appliquer des transformations, puis écrire les données dans l'entrepôt de données. Chacune des transformations est décrite par une fonction, et la valeur saisie pour une fonction donnée est le résultat de la ou des fonctions précédentes. Ces fonctions connectées sont décrites comme un graphe, lequel est souvent désigné sous le nom de graphe orienté acyclique (DAG, Directed Acyclic Graph). Cela signifie que le graphe suit une direction (de la source vers la destination) et est acyclique. La valeur saisie pour toute fonction ne peut pas dépendre du résultat d'une autre fonction située en aval dans le DAG. En d'autres termes, les boucles ne sont pas autorisées. Chaque nœud du graphe est une fonction, et chaque arête représente les données circulant d'une fonction à la suivante. Les fonctions initiales sont des sources, ou connexions aux systèmes de données sources. Les fonctions finales sont des récepteurs, ou connexions aux systèmes de données de destination.

Dans le contexte des pipelines de données, les sources sont généralement des systèmes transactionnels (par exemple, un SGBDR), et le récepteur se connecte à un entrepôt de données. Ce type de graphe est appelé DAG de flux de données. Vous pouvez également utiliser des DAG pour orchestrer le transfert de données entre des pipelines de données et d'autres systèmes. Dans ce cas, on parle de DAG de flux de contrôle ou d'orchestration.

Quand migrer les pipelines de données

Lorsque vous migrez un cas d'utilisation vers BigQuery, deux possibilités s'offrent à vous : le déchargement ou la migration complète.

D'un côté, lorsque vous déchargez un cas d'utilisation, vous n'avez pas besoin de migrer à l'avance ses pipelines de données en amont. Vous migrez d'abord le schéma et les données du cas d'utilisation depuis votre entrepôt de données existant vers BigQuery. Pour que les données restent synchronisées, vous établissez ensuite une copie incrémentielle de l'ancien entrepôt de données vers le nouveau. Enfin, vous migrez et validez les processus en aval tels que les scripts, les requêtes, les tableaux de bord et les applications métier.

À ce stade, vos pipelines de données en amont sont inchangés et continuent d'écrire des données dans votre entrepôt de données existant. Vous pouvez inclure à nouveau les cas d'utilisation déchargés dans le backlog de migration en vue d'une migration complète lors d'une itération ultérieure.

D'un autre côté, lorsque vous migrez complètement un cas d'utilisation, les pipelines de données en amont requis sont migrés vers Google Cloud. Pour pouvoir effectuer une migration complète d'un cas d'utilisation, vous devez d'abord le décharger. Après la migration complète, vous pouvez abandonner les anciennes tables correspondantes dans l'entrepôt de données sur site, car les données sont directement ingérées dans BigQuery.

Au cours d'une itération, vous pouvez choisir l'une des options suivantes :

• Seulement décharger votre cas d'utilisation
• Migrer complètement un cas d'utilisation déchargé au préalable
• Migrer complètement un cas d'utilisation à partir de zéro en le déchargeant d'abord dans la même itération

Une fois tous vos cas d'utilisation complètement migrés, vous pouvez choisir de désactiver l'ancien entrepôt, ce qui constitue une étape importante pour réduire les frais généraux et les coûts.

Migrer les pipelines de données

Le reste de ce document indique comment migrer vos pipelines de données, y compris l'approche, les procédures et les technologies à mettre en œuvre. Les options vont de la réaffectation des pipelines de données existants (en les redirigeant pour charger BigQuery) à la réécriture des pipelines de données afin d'exploiter les services gérés par Google Cloud.

Procédures et modèles pour les pipelines de données

Vous pouvez exécuter un certain nombre de procédures et de modèles à l'aide de pipelines de données. Ces derniers sont le plus souvent utilisés dans l'entreposage de données. Vous pouvez avoir des pipelines de données par lot ou des pipelines de données par flux. Les pipelines de données par lot s'exécutent sur des données collectées pendant une période donnée (par exemple, une fois par jour). Les pipelines de données par flux traitent les événements en temps réel générés par vos systèmes opérationnels, par exemple, dans les modifications de lignes CDC générées par vos bases de données de traitement transactionnel en ligne (OLTP, Online Transaction Processing).

Extraction, transformation et chargement (ETL)

Dans le contexte de l'entreposage de données, les pipelines de données exécutent souvent une procédure d'extraction, de transformation et de chargement (ETL, Extract-Transform-Load). Les technologies ETL s'exécutent en dehors de l'entrepôt de données, ce qui signifie que les ressources de ce dernier peuvent servir principalement à l'interrogation simultanée, plutôt qu'à la préparation et à la transformation des données. L'exécution de la transformation en dehors de l'entrepôt de données présente un inconvénient, à savoir que vous devez apprendre à utiliser des outils et des langages supplémentaires (autres que SQL) pour exprimer les transformations.

Le schéma suivant présente une procédure ETL type.

Figure 1. Procédure ETL type.

Remarque : Les flèches indiquent la direction du flux de données. Les sources présentes dans le DAG extraient généralement leurs données des systèmes sources

.

Un pipeline de données ETL type extrait les données d'un ou de plusieurs systèmes sources (de préférence du moins de systèmes possible afin d'éviter les pannes, par exemple en cas d'indisponibilité d'un système). Le pipeline effectue ensuite une série de transformations, comme le nettoyage des données, l'application de règles métier à celles-ci, la vérification de l'intégrité des données et la création d'agrégats ou de désagrégats. Pour en savoir plus, consultez la section Real-life ETL cycle.

Il est fréquent d'avoir plusieurs pipelines de données. Le premier pipeline se concentre sur la copie de données du système source vers l'entrepôt de données. Les pipelines suivants appliquent la logique métier et transforment les données en vue de leur utilisation dans divers magasins de données, qui sont des sous-ensembles de l'entrepôt de données axés sur une unité commerciale ou un objectif commercial spécifique.

Lorsque vous disposez de plusieurs pipelines de données, vous devez les orchestrer. Le schéma suivant montre à quoi ce processus d'orchestration peut ressembler.

Figure 2. Processus d'orchestration pour plusieurs pipelines de données.

Dans ce schéma, chaque pipeline de données est considéré comme un sous-DAG du DAG d'orchestration. Chaque DAG d'orchestration comprend plusieurs pipelines de données afin de répondre à un objectif plus large, par exemple la préparation des données pour une unité commerciale afin que les analystes métier puissent exécuter leurs tableaux de bord ou leurs rapports.

Extraction, chargement et transformation (ELT)

La procédure d'extraction, de chargement et de transformation (ELT, Extract-Load-Transform) est une alternative à l'ETL. Avec l'ELT, le pipeline de données est divisé en deux parties. Tout d'abord, une technologie ETL extrait les données du système source et les charge dans l'entrepôt de données. Ensuite, les scripts SQL exécutés en complément de l'entrepôt de données effectuent les transformations. L'avantage de cette approche est que vous pouvez exprimer les transformations à l'aide du langage SQL. Son inconvénient est qu'elle peut consommer des ressources de l'entrepôt de données nécessaires à l'interrogation simultanée. Pour cette raison, les lots ELT sont souvent exécutés pendant la nuit (ou en période creuse) lorsque les ressources système de l'entrepôt de données sont moins sollicitées.

Le schéma suivant présente une procédure ELT type.

Figure 3. Procédure ELT type.

Lorsque vous adoptez une approche ELT, il est courant de séparer l'extraction et le chargement dans un DAG, et les transformations dans leurs propres DAG. Les données sont chargées une seule fois dans l'entrepôt de données, puis transformées plusieurs fois pour créer les différentes tables utilisées en aval dans les rapports, etc. Ces DAG deviennent à leur tour des sous-DAG d'un DAG d'orchestration plus large (comme indiqué dans la section Extraction, transformation et chargement [ETL]).

Lorsque vous migrez des pipelines de données depuis un entrepôt de données sur site encombré vers le cloud, il est important de garder à l'esprit que les systèmes d'entreposage de données cloud tels que BigQuery sont des technologies de traitement de données massivement parallèles. En fait, dans le cas de BigQuery, vous pouvez acheter plus de ressources de façon à répondre aux demandes croissantes en matière d'ELT et d'interrogation simultanée. Pour en savoir plus, consultez la section Présentation de l'optimisation des performances des requêtes.

Extraction et chargement (EL)

Vous pouvez appliquer la procédure d'extraction et de chargement (EL, Extract-Load) seule ou la faire suivre de transformations, auquel cas elle devient une ELT. La procédure EL est abordée séparément, car plusieurs services automatisés sont disponibles pour effectuer cette tâche, ce qui vous évite de créer votre propre pipeline de données d'ingestion. Pour en savoir plus, consultez la page Service de transfert de données BigQuery.

Capture de données modifiées (CDC)

La capture de données modifiées (CDC, Change Data Capture) est l'un des modèles de conception logicielle permettant de suivre les modifications de données. Elle est souvent utilisée dans l'entreposage de données, car l'entrepôt sert à classer et à suivre les données et leurs modifications provenant de divers systèmes sources au fil du temps.

Le schéma suivant montre un exemple de fonctionnement de la CDC avec l'ELT.

Figure 4. Fonctionnement de la CDC avec l'ELT.

La CDC fonctionne bien avec l'ELT, car vous souhaitez stocker l'enregistrement d'origine avant d'effectuer toute modification en aval.

Pour que la partie EL se produise, vous pouvez traiter les journaux de base de données en utilisant un logiciel de CDC tel que Datastream ou des outils Open Source tels que Debezium et en écrivant les enregistrements dans BigQuery à l'aide de Dataflow. Vous pouvez ensuite exécuter une requête SQL pour déterminer la dernière version avant d'appliquer d'autres transformations. Exemple :

WITH ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY RECORD KEY
      ORDER BY EVENT TIMESTAMP DESC
    ) AS rank
  FROM TABLE NAME
)
SELECT *
FROM ranked
WHERE rank = 1

Lorsque vous procédez à une refactorisation ou créez des pipelines de données, envisagez d'appliquer le modèle CDC dans le cadre d'une procédure ELT. Cette approche garantit que vous disposez d'un historique complet des modifications de données en amont, et permet une bonne séparation des responsabilités, par exemple :

• Les équipes chargées des systèmes sources s'assurent de la disponibilité de leurs journaux et de la publication de leurs événements de données.
• L'équipe chargée de la plate-forme de données veille à ce que le classement par ingestion des enregistrements d'origine inclue des horodatages dans l'entrepôt de données.
• Les équipes d'analystes et d'ingénieurs des données planifient une série de transformations pour remplir leurs magasins de données.

Boucles de rétroaction avec pipelines de données opérationnels

Les pipelines de données opérationnels sont des pipelines de traitement des données qui extraient des données de l'entrepôt de données, les transforment si nécessaire et écrivent le résultat dans des systèmes opérationnels.

Les systèmes opérationnels font référence aux systèmes qui traitent les transactions quotidiennes de l'organisation, par exemple les bases de données OLTP, les systèmes de gestion de la relation client (CRM, Customer Relationship Management), les systèmes de gestion du catalogue de produits (PCM, Product Catalog Management), etc. Étant donné que ces systèmes servent souvent de source de données, les pipelines de données opérationnels mettent en œuvre un modèle de boucle de rétroaction.

Le schéma suivant présente le modèle de pipeline de données opérationnel.

Figure 5. Modèle de pipeline de données opérationnel.

L'exemple suivant décrit un pipeline de données opérationnel qui écrit les prix des produits dans un système PCM. Un système PCM est le système faisant autorité pour les informations produit liées aux ventes, telles que les couleurs, les canaux de ventes, les prix et la saisonnalité. Voici le flux de données de bout en bout :

• Des données liées aux prix sont disponibles dans plusieurs sources. Vous pouvez par exemple obtenir le prix actuel par région auprès du système PCM, les tarifs appliqués par les concurrents auprès d'un service tiers, des données sur la prévision de la demande et la fiabilité des fournisseurs auprès de systèmes internes, etc.
• Un pipeline ETL extrait les données des sources, les transforme et écrit le résultat dans l'entrepôt de données. Dans ce cas, la transformation est un calcul complexe impliquant toutes les sources et qui a pour but de produire un prix de base optimal pour chaque produit figurant dans le système PCM.
• Pour finir, le pipeline opérationnel extrait les prix de base de l'entrepôt de données, effectue de légères transformations pour ajuster les prix en fonction d'événements saisonniers et réécrit les prix finaux dans le système PCM.

Figure 6. Pipeline de données opérationnel qui écrit le prix des produits dans un système PCM.

Un pipeline de données opérationnel est un type de processus en aval, tandis que les pipelines de données mettant en œuvre l'ETL, l'ELT ou la CDC sont des processus en amont. Néanmoins, les outils servant à mettre en œuvre ces deux types de pipelines peuvent se chevaucher. Par exemple, vous pouvez recourir à Dataflow pour définir et exécuter tous les DAG de traitement des données, à GoogleSQL pour définir les transformations pour l'exécution dans BigQuery et à Cloud Composer pour orchestrer le flux de données de bout en bout.

Choisir une approche de migration

Cette section décrit différentes approches que vous pouvez adopter pour migrer vos pipelines de données.

Rediriger les pipelines de données afin d'écrire dans BigQuery

Dans les conditions suivantes, vous pouvez déterminer si une technologie que vous utilisez offre un récepteur BigQuery intégré (connecteur d'écriture) :

• L'ancien entrepôt de données est alimenté par des pipelines de données exécutant une procédure ETL.
• La logique de transformation est exécutée avant le stockage des données dans l'entrepôt de données.

Des éditeurs de logiciels indépendants proposent des technologies de traitement des données dotées de connecteurs BigQuery, par exemple :

• Informatica : BigQuery connector guide
• Talend : Writing data in BigQuery

Remarque : Il est important de vérifier que le logiciel de traitement des données utilise les mécanismes d'ingestion à grande échelle de BigQuery tels que les insertions en flux continu ou les chargements par lot à partir de Cloud Storage. Une approche exploitant les pilotes Magnitude Simba, JDBC ou ODBC de BigQuery ne convient pas aux opérations d'ingestion à grande échelle, car ces pilotes mettent en œuvre l'interface de requête. Bien qu'ils puissent effectuer des insertions, cette interface est conçue pour les requêtes et les instructions de langage de manipulation de données (LMD) sur BigQuery, et non pour les insertions ou les mises à jour à grande échelle.

Si la technologie de pipeline de données n'est pas compatible avec l'ingestion de données dans BigQuery, envisagez d'adopter une variante de cette approche où les données sont temporairement écrites dans des fichiers, qui sont ensuite importés par BigQuery.

Figure 7. Réécriture, ou reconfiguration, de la dernière fonction d'un pipeline de données afin d'écrire des données dans BigQuery.

De manière générale, les tâches à exécuter pour pouvoir écrire des données dans BigQuery concernent la réécriture, ou la reconfiguration, de la dernière fonction du pipeline de données. Cependant, un certain nombre d'options peuvent nécessiter l'apport de modifications supplémentaires ou l'exécution de nouvelles tâches, par exemple :

Au niveau fonctionnel

• Mappages de données : étant donné que le schéma de la table de la base de données cible peut changer, vous devrez peut-être reconfigurer ces mappages.
• Validation des métriques : vous devez valider les rapports nouveaux et historiques, car le schéma et les requêtes peuvent changer.

Au niveau non fonctionnel

• Il peut être nécessaire de configurer des pare-feu afin d'autoriser le transfert de données sortantes depuis un environnement sur site vers BigQuery.
• Il peut être nécessaire de modifier le réseau afin de dégager de la bande passante supplémentaire, pour pouvoir gérer le transfert de données sortantes.

Rediriger les pipelines de données en se servant de fichiers comme intermédiaires

Lorsque la technologie de pipeline de données sur site existante n'est pas compatible avec les API Google, ou si vous n'êtes pas autorisé à utiliser ces dernières, vous pouvez vous servir de fichiers comme intermédiaires pour que vos données puissent atteindre BigQuery.

Cette approche est analogue à la redirection, mais au lieu d'utiliser un récepteur natif capable d'écrire dans BigQuery, vous en utilisez un qui peut écrire dans un système de fichiers sur site. Lorsque vos données se trouvent dans votre système de fichiers, vous copiez les fichiers sur Cloud Storage. Pour en savoir plus, consultez la présentation des options d'ingestion pour Cloud Storage et les critères impliqués dans la sélection d'une option d'ingestion.

La dernière étape consiste à charger les données depuis Cloud Storage dans BigQuery en suivant les instructions de la section Charger des données par lot.

Le schéma suivant illustre l'approche décrite dans cette section.

Figure 8. Redirection des pipelines de données en se servant de fichiers comme intermédiaires.

En ce qui concerne l'orchestration du pipeline ETL, vous devez effectuer deux étapes distinctes :

1. Réutilisez votre orchestration de pipeline sur site existante pour écrire les données transformées dans le système de fichiers. Étendez cette orchestration afin de copier les fichiers de votre système de fichiers sur site dans Cloud Storage, ou créez un script supplémentaire qui s'exécute régulièrement pour effectuer l'étape de copie.
2. Lorsque les données se trouvent dans Cloud Storage, utilisez un transfert Cloud Storage pour planifier des chargements récurrents de Cloud Storage vers BigQuery. Les déclencheurs Cloud Storage et Cloud Composer constituent des alternatives aux transferts Cloud Storage.

Dans la figure 8, notez que l'orchestration sur Google Cloud peut également utiliser un modèle d'extraction en récupérant les fichiers à l'aide d'un protocole tel que SFTP.

Migrer les pipelines ELT existants vers BigQuery

Les pipelines ELT comprennent deux parties : celle qui charge les données dans votre entrepôt de données, et celle qui les transforme à l'aide de SQL afin qu'elles puissent être consommées en aval. Lorsque vous migrez des pipelines ELT, chacune de ces parties a sa propre approche de migration.

Pour la partie qui charge les données dans l'entrepôt de données (la partie EL), vous pouvez suivre les instructions figurant dans la section sur la redirection des pipelines de données, en ignorant les conseils concernant les transformations, qui n'entrent pas dans le cadre d'un pipeline EL.

Si vos sources de données sont compatibles avec le service de transfert de données BigQuery, que ce soit directement ou via des intégrations tierces, vous pouvez remplacer votre pipeline EL par ce service.

Migrer les pipelines de données OSS existants vers Dataproc

Lors de la migration de votre pipeline de données vers Google Cloud, vous pouvez avoir besoin de migrer certaines anciennes tâches écrites avec un framework logiciel Open Source comme Apache Hadoop, Apache Spark ou Apache Flink.

Dataproc vous permet de déployer des clusters Hadoop et Spark rapides, faciles à utiliser et entièrement gérés, de manière simple et économique. Dataproc s'intègre au connecteur BigQuery, une bibliothèque Java qui permet à Hadoop et à Spark d'écrire des données dans BigQuery à l'aide de versions simplifiées des classes InputFormat et OutputFormat d'Apache Hadoop.

Dataproc facilite la création et la suppression de clusters. Ainsi, au lieu d'utiliser un cluster monolithique, vous pouvez utiliser de nombreux clusters éphémères. Cette approche présente plusieurs avantages :

• Vous pouvez utiliser différentes configurations de cluster pour des tâches individuelles, éliminant ainsi la charge administrative liée à la gestion des outils entre les tâches.
• Vous pouvez adapter les clusters à des tâches individuelles ou à des groupes de tâches.
• Vous ne payez les ressources que lorsque vos tâches les utilisent.
• Vous n'avez pas besoin de gérer les clusters au fil du temps, car ils sont reconfigurés à chaque utilisation.
• Vous n'avez pas besoin de gérer une infrastructure séparée pour le développement, les tests et la production. Vous pouvez utiliser les mêmes définitions pour créer autant de versions différentes d'un cluster que nécessaire, en fonction de vos besoins.

Lorsque vous migrez vos tâches, nous vous recommandons d'adopter une approche incrémentielle. Avec ce type de migration, vous pouvez effectuer les opérations suivantes :

• Isoler les tâches individuelles de votre infrastructure Hadoop existante de la complexité inhérente à un environnement mature
• Examiner chaque tâche séparément pour évaluer ses besoins et déterminer le meilleur chemin d'accès pour la migration
• Résoudre les problèmes inattendus dès leur apparition sans retarder les tâches dépendantes
• Réaliser une démonstration de faisabilité pour chaque processus complexe sans affecter votre environnement de production
• Déplacer vos tâches vers le modèle éphémère recommandé de manière délibérée et réfléchie

Lorsque vous migrez les tâches Hadoop et Spark existantes vers Dataproc, vous pouvez vérifier que leurs dépendances sont bien prises en compte par les versions Dataproc compatibles. Si vous avez besoin d'installer un logiciel personnalisé, vous pouvez envisager de créer votre propre image Dataproc, d'exécuter certaines des actions d'initialisation disponibles (par exemple, pour Apache Flink), d'écrire votre propre action d'initialisation ou de spécifier des exigences personnalisées pour les packages Python.

Pour commencer, consultez les guides de démarrage rapidede Dataproc et les exemples de code de connecteur BigQuery. Consultez également la section Migrer des tâches Hadoop sur site vers Dataproc.

Réhéberger des pipelines de données tiers en vue de leur exécution sur Google Cloud

Un scénario courant lors de la création de pipelines de données sur site consiste à gérer l'exécution des pipelines et l'allocation des ressources de calcul à l'aide d'un logiciel tiers.

Pour déplacer ces pipelines vers le cloud, vous disposez de plusieurs alternatives, en fonction des capacités du logiciel que vous utilisez, ainsi que de vos conditions de licence, d'assistance et de maintenance.

Les sections suivantes présentent certaines de ces alternatives.

De manière générale, voici les alternatives qui s'offrent à vous pour exécuter votre logiciel tiers dans Google Cloud, par ordre croissant de complexité :

• Votre éditeur de logiciels s'est associé à Google Cloud afin de proposer ses logiciels dans Google Cloud Marketplace.
• Votre éditeur de logiciels tiers peut exécuter ses logiciels sur Kubernetes.
• Votre logiciel tiers s'exécute sur une ou plusieurs machines virtuelles (VM).

Si votre éditeur de logiciels tiers fournit une solution Cloud Marketplace, vous devez procéder comme suit :

• Déployez votre logiciel tiers à partir de la console Google Cloud Marketplace.
• Sélectionnez et migrez vos cas d'utilisation en suivant l'approche itérative expliquée dans la section Effectuer la migration selon une approche itérative.

Cette alternative est la plus simple, car vous intégrez vos pipelines de données dans le cloud à l'aide de la plate-forme familière fournie par votre éditeur. Vous pourrez également vous servir des outils propriétaires de votre éditeur pour faciliter la migration entre votre environnement d'origine et votre nouvel environnement sur Google Cloud.

Si votre éditeur ne fournit pas de solution Cloud Marketplace mais que son produit peut s'exécuter sur Kubernetes, vous pouvez utiliser Google Kubernetes Engine (GKE) pour héberger vos pipelines. Vous devez alors procéder comme suit :

• Créez un cluster GKE conformément aux recommandations de votre éditeur pour vous assurer que le produit tiers peut tirer parti de l'exécution en parallèle des tâches proposée par Kubernetes.
• Installez le logiciel tiers sur votre cluster GKE conformément aux recommandations de l'éditeur.
• Sélectionnez et migrez vos cas d'utilisation en suivant l'approche itérative expliquée dans la section Migrer des entrepôts de données vers BigQuery : Présentation.

Cette alternative est d'une complexité intermédiaire. Elle tire parti de la compatibilité native de votre éditeur avec Kubernetes afin de procéder au scaling et à l'exécution en parallèle de vos pipelines. Cependant, vous devez créer et gérer un cluster GKE.

Si votre fournisseur n'est pas compatible avec Kubernetes, vous devez installer son logiciel sur un pool de VM pour permettre le scaling horizontal et l'exécution en parallèle des tâches. Si le logiciel de votre éditeur offre une compatibilité native avec la répartition des tâches entre plusieurs VM, utilisez les installations fournies, en rassemblant éventuellement les instances de VM dans un groupe d'instances géré (MIG, Managed Instance Group) pour procéder à un scaling vertical et horizontal si besoin.

Gérer l'exécution en parallèle des tâches n'est pas une mince affaire. Si votre éditeur ne fournit pas de fonctionnalités permettant de répartir les tâches entre différentes VM, nous vous recommandons d'utiliser un modèle de ferme de tâches pour les répartir entre les VM d'un MIG. Le schéma suivant illustre cette approche.

Figure 9. Groupe d'instances géré (MIG) comprenant trois VM.

Dans ce schéma, chaque VM du MIG exécute le logiciel de pipeline tiers. Vous pouvez déclencher l'exécution d'un pipeline de plusieurs manières :

• Automatiquement, en utilisant Cloud Scheduler, Cloud Composer ou un déclencheur Cloud Storage lorsque de nouvelles données arrivent dans un bucket Cloud Storage.
• Par programmation, en appelant Cloud Endpoints ou Cloud Functions, ou en utilisant l'API Pub/Sub.
• Manuellement, en plaçant un nouveau message dans un sujet Pub/Sub avec Google Cloud CLI.

En substance, toutes ces méthodes envoient un message à un sujet Pub/Sub prédéfini. Vous créez un agent simple à installer sur chaque VM. L'agent écoute un ou plusieurs sujets Pub/Sub. À chaque fois qu'un message arrive dans le sujet, l'agent l'extrait de ce dernier, démarre un pipeline dans votre logiciel tiers et suit sa progression. Une fois le pipeline terminé, l'agent récupère le message suivant dans les sujets qu'il écoute.

Dans tous les scénarios, nous vous recommandons de collaborer avec votre éditeur afin de respecter les conditions de licence appropriées pour que vos pipelines fonctionnent sur Google Cloud.

Réécrire les pipelines de données pour utiliser les services gérés par Google Cloud

Dans certains cas, vous pouvez choisir de réécrire certains de vos pipelines de données existants afin d'utiliser de nouveaux frameworks et services entièrement gérés sur Google Cloud. Cette option fonctionne bien si les pipelines existants ont été mis en œuvre initialement avec des technologies qui sont maintenant obsolètes, ou si vous estimez que le portage et la conservation de ces pipelines non modifiés dans le cloud seraient trop compliqués ou d'un coût prohibitif.

Les sections suivantes présentent Cloud Data Fusion et Dataflow, des services Google Cloud entièrement gérés vous permettant d'effectuer des transformations de données avancées à grande échelle.

Cloud Data Fusion

Cloud Data Fusion, qui repose sur le projet CDAP Open Source, est un service d'intégration de données entièrement géré permettant de créer et de gérer des pipelines de données via une interface graphique.

Vous développez les pipelines de données dans l'interface utilisateur de Cloud Data Fusion en connectant des sources à des transformations, des récepteurs et d'autres nœuds pour former un DAG. Lorsque vous déployez votre pipeline de données, le planificateur Cloud Data Fusion transforme ce DAG en une série de calculs parallèles qui seront exécutés en tant que tâche Apache Spark sur Dataproc.

Lorsque vous utilisez Cloud Data Fusion, vous pouvez vous connecter à la base de données d'un système source en vous servant des pilotes JDBC (Java Database Connectivity) pour lire les données, les transformer et les charger dans la destination de votre choix (par exemple, BigQuery), sans avoir à écrire de code. Pour ce faire, vous devez importer un pilote JDBC sur votre instance Cloud Data Fusion et le configurer afin de pouvoir l'utiliser dans vos pipelines de données. Pour en savoir plus, consultez le guide sur l'utilisation des pilotes JDBC avec Cloud Data Fusion.

Cloud Data Fusion expose des plug-ins pour les sources, les transformations, les agrégats, les récepteurs, les collecteurs d'erreurs, les éditeurs d'alerte, les actions et les actions post-exécution en tant que composants personnalisables. Les plug-ins prédéfinis permettent d'accéder à un large éventail de sources de données. Si un plug-in n'existe pas, vous pouvez créer le vôtre à l'aide des API de plug-in Cloud Data Fusion. Pour plus d'informations, consultez la présentation du plug-in.

Avec les pipelines Cloud Data Fusion, vous pouvez créer des pipelines de données par lot et par flux. En fournissant un accès aux journaux et aux métriques, les pipelines de données permettent également aux administrateurs d'opérationnaliser leurs workflows de traitement des données sans qu'ils n'aient besoin d'outils personnalisés.

Pour commencer, consultez la présentation des concepts de Cloud Data Fusion. Pour obtenir des exemples pratiques, consultez le guide de démarrage rapide et le tutoriel sur la création d'un pipeline de campagne de ciblage.

Dataflow

Dataflow est un service entièrement géré permettant d'exécuter des tâches Apache Beam à grande échelle. Apache Beam est un framework Open Source qui fournit de nombreuses primitives de fenêtrage et d'analyse de sessions, ainsi qu'un écosystème de connecteurs de sources et de récepteurs, parmi lesquels un connecteur pour BigQuery. Apache Beam permet de transformer et d'enrichir des données en mode flux (temps réel) et lot (historique) avec un niveau identique de fiabilité et d'expressivité.

L'approche sans serveur de Dataflow vous permet d'éliminer certains coûts opérationnels en raison de la gestion automatisée des performances, du scaling, de la disponibilité, de la sécurité et de la conformité. Vous pouvez ainsi vous concentrer sur la planification plutôt que sur la gestion des clusters de serveurs.

Pour envoyer des tâches Dataflow, vous pouvez utiliser l'interface de ligne de commande, le SDK Java ou le SDK Python. De plus, nous développons un framework de portabilité assurant une interopérabilité totale entre tous les SDK et les exécuteurs.

Si vous souhaitez migrer vos requêtes et pipelines de données depuis d'autres frameworks vers Apache Beam et Dataflow, consultez la section sur le modèle de programmation Apache Beam et la documentation Dataflow officielle.

Pour obtenir des exemples pratiques, consultez les guides de démarrage rapide et les tutoriels Dataflow.

Orchestration et programmation

De manière générale, l'orchestration est la coordination automatisée de plusieurs systèmes, tandis que la planification fait référence au déclenchement automatique des tâches d'orchestration.

• Zoom avant : un pipeline de données est en soi une orchestration des transformations de données décrites par un DAG, qui est un DAG de traitement des données.
• Zoom arrière : lorsqu'un pipeline de données dépend du résultat d'autres pipelines de données, vous avez besoin d'orchestrer plusieurs pipelines. Chaque pipeline constitue un sous-DAG d'un DAG plus large, qui est un DAG d'orchestration.

Cette configuration est typique de l'entreposage de données. La figure 1 de la section Extraction, transformation et chargement (ETL) présente un exemple de configuration. Les sections suivantes se concentrent sur l'orchestration de plusieurs pipelines de données.

Dépendances

Les dépendances peuvent avoir une distribution unique (où plusieurs pipelines de données fusionnent pour constituer un sommet d'un DAG d'orchestration) ou une distribution ramifiée (lorsqu'un seul pipeline de données en déclenche plusieurs autres), mais elles ont souvent les deux, comme présenté dans le schéma suivant.

Figure 10. Dépendances à distribution unique et à distribution ramifiée utilisées en combinaison.

Dans les environnements non optimaux, certaines dépendances résultent de limites en matière de quantité de ressources disponibles. Par exemple, un pipeline de données s'exécute et génère des données communes en tant que produit secondaire. D'autres pipelines de données dépendent de ces données communes simplement pour éviter de les recalculer, mais n'ont aucun lien avec le pipeline de données qui les a créées. Si ce premier pipeline rencontre des problèmes fonctionnels ou non fonctionnels, les défaillances se répercutent sur ses pipelines de données dépendants, au mieux les obligeant à attendre ou au pire, empêchant leur exécution comme dans le schéma suivant.

Figure 11. Les défaillances d'un pipeline de données se répercutent sur les pipelines dépendants et empêchent leur exécution.

Dans Google Cloud, vous disposez d'une multitude de ressources de calcul et d'outils spécialisés pour optimiser l'exécution de vos pipelines et leur orchestration. Les sections qui suivent traitent de ces ressources et outils.

Tâches de migration à exécuter

Nous vous recommandons de simplifier vos besoins d'orchestration. La complexité de votre orchestration augmente avec le nombre de dépendances entre vos pipelines de données. La migration vers Google Cloud vous offre l'occasion d'examiner vos DAG d'orchestration, d'identifier vos dépendances et de déterminer comment les optimiser.

Nous vous recommandons d'optimiser vos dépendances de manière incrémentielle, comme suit :

1. Dans une première itération, déplacez votre orchestration telle quelle vers Google Cloud.
2. Dans les itérations suivantes, analysez vos dépendances et exécutez-les en parallèle si possible.
3. Enfin, réorganisez votre orchestration en extrayant les tâches courantes dans leurs propres DAG.

La section suivante explique cette méthode au moyen d'un exemple pratique.

Exemple pratique

Supposons qu'une organisation ait deux pipelines associés :

• Le premier pipeline calcule les pertes et profits (P&L, Profits and Losses) de l'ensemble de l'organisation. Il s'agit d'un pipeline complexe impliquant de nombreuses transformations. Une partie du pipeline consiste à calculer les ventes mensuelles, qui sont utilisées dans les étapes de transformation suivantes et sont à terme écrites dans une table.
• Le second pipeline calcule la croissance des ventes d'une année à l'autre et d'un mois à l'autre pour différents produits, de sorte que le service marketing puisse ajuster ses efforts en matière de campagne publicitaire. Ce pipeline a besoin des données sur les ventes mensuelles précédemment calculées par le pipeline de données de P&L.

L'organisation considère que le pipeline de données de P&L a une priorité plus élevée que le pipeline de marketing. Malheureusement, comme le pipeline de P&L est complexe, il consomme une grande quantité de ressources, empêchant ainsi l'exécution simultanée d'autres pipelines. En outre, en cas de défaillance du pipeline de P&L, le pipeline de marketing et les autres pipelines dépendants ne disposent pas des données nécessaires à leur exécution et doivent attendre une nouvelle tentative du pipeline de P&L. Le schéma suivant illustre ce cas de figure.

Figure 12. Des pipelines de données complexes peuvent empêcher l'exécution de pipelines de priorité inférieure.

L'organisation migre vers BigQuery. Elle a identifié les deux cas d'utilisation, soit les P&L et la croissance des ventes pour le marketing, et les a inclus dans le backlog de migration. Lors de la planification de l'itération suivante, l'organisation donne la priorité au cas d'utilisation des P&L et inclut celui-ci dans le backlog d'itération, car il est fortement limité par les ressources sur site actuelles et provoque régulièrement des retards. Certains de ses cas d'utilisation dépendants sont également inclus, parmi lesquels le cas d'utilisation du marketing.

L'équipe chargée de la migration exécute la première itération. Elle choisit de migrer les cas d'utilisation des P&L et du marketing vers Google Cloud en adoptant une approche de redirection. Elle n'apporte aucune modification aux étapes des pipelines ou à l'orchestration. Une différence importante réside dans le fait que le pipeline de P&L peut désormais disposer d'une puissance de calcul presque illimitée et s'exécute donc beaucoup plus rapidement que sur site. Le pipeline écrit les données mensuelles sur les ventes dans une table BigQuery utilisée par le pipeline de croissance marketing. Le schéma suivant illustre ces modifications.

Figure 13. Accélération d'un pipeline de données complexe grâce à une approche de redirection.

Bien que la migration vers Google Cloud ait contribué à résoudre les problèmes non fonctionnels du pipeline de P&L, des problèmes fonctionnels subsistent. Certaines tâches non liées précédant le calcul des ventes mensuelles entraînent souvent des erreurs qui empêchent la réalisation de ce calcul et le démarrage des pipelines dépendants.

Dans une deuxième itération, l'équipe espère améliorer les performances en incluant les deux cas d'utilisation dans le backlog d'itération. Elle identifie les étapes du pipeline de P&L qui permettent de calculer les ventes mensuelles. Ces étapes constituent un sous-DAG, comme indiqué dans le schéma suivant. L'équipe chargée de la migration copie le sous-DAG dans le pipeline de marketing afin que celui-ci puisse s'exécuter indépendamment du pipeline de P&L. La puissance de calcul étant suffisante dans GCP, les deux pipelines peuvent s'exécuter simultanément.

Figure 14. Pipelines s'exécutant simultanément à l'aide d'un sous-DAG.

L'inconvénient est que la duplication de la logique de sous-DAG génère des frais de gestion du code, car l'équipe doit maintenant garder synchronisées les deux copies de la logique de sous-DAG.

Dans une troisième itération, l'équipe réexamine les cas d'utilisation et extrait le sous-DAG des ventes mensuelles dans un pipeline indépendant. Une fois le nouveau pipeline de ventes mensuelles terminé, il se déclenche ou se ramifie dans le pipeline de P&L, le pipeline de croissance marketing et d'autres pipelines dépendants. Cette configuration crée un DAG d'orchestration global, chacun des pipelines constituant l'un de ses sous-DAG.

Figure 15. DAG d'orchestration global où chaque pipeline se trouve dans son propre sous-DAG.

Dans les itérations suivantes, l'équipe chargée de la migration peut résoudre les problèmes fonctionnels restants et migrer les pipelines pour utiliser des services gérés par Google Cloud, parmi lesquels :

• Dataflow : permet de définir chaque pipeline de données en tant que DAG autonome à l'aide du modèle Beam.
• Cloud Composer : permet de définir une orchestration plus large, sous la forme d'un ou de plusieurs DAG Airflow.

Même si Airflow offre une compatibilité native avec les sous-DAG, cette fonctionnalité peut limiter les performances et est donc déconseillée. À la place, utilisez des DAG indépendants avec l'opérateur TriggerDagRunOperator.

Étape suivante

Découvrez les étapes suivantes de la migration d'entrepôts de données :

• Présentation de la migration
• Évaluation de la migration
• Présentation du transfert de schéma et de données
• Traduction SQL par lot
• Traduction SQL interactive
• Sécurité et gouvernance des données
• Outil de validation des données

Vous pouvez également en savoir plus sur le passage de technologies d'entrepôt de données spécifiques à BigQuery :

• Migrer depuis Netezza
• Migrer depuis Oracle
• Migrer depuis Amazon Redshift
• Migrer depuis Teradata
• Migrer depuis Snowflake