Google Cloud pour les utilisateurs professionnels d'AWS : big data

Document mis à jour le 30 octobre 2019

Cet article compare les services de big data fournis par Amazon via Amazon Web Services (AWS) et ceux qui sont proposés par Google via Google Cloud.

Plusieurs types de services sont pris en considération :

  • Les services d'ingestion, qui permettent d'intégrer des données d'un environnement source dans un environnement ou un type de données cible offrant la fiabilité et la stabilité requises.
  • Les services de transformation et de préparation, qui permettent de filtrer, d'extraire et de transformer des données d'un type de données ou d'un modèle vers un autre.
  • Les services d'entreposage et d'analyse, qui vous permettent de stocker, d'analyser et de visualiser les données traitées ainsi que d'interagir avec elles.

Services d'ingestion

Cette section compare les méthodes d'ingestion de données mises en œuvre dans AWS et dans Google Cloud.

Connectivité

Pour certaines migrations initiales, et en particulier pour l'ingestion de données en continu, une connexion réseau à haut débit entre votre cloud de destination et un autre réseau est généralement nécessaire. Le tableau suivant récapitule les options de connectivité proposées par AWS et Google Cloud.

Fonctionnalité AWS Google Cloud
Réseau privé virtuel VPN de site à site Cloud VPN
Connectivité privée à un VPC Direct Connect Interconnexion dédiée
Interconnexion partenaire
Connectivité haut débit à d'autres services cloud Direct Connect Appairage direct
Appairage opérateur

Pour en savoir plus sur les options offertes par Google Cloud, consultez la section Connectivité privée à d'autres réseaux de la page Google Cloud pour les utilisateurs professionnels d'AWS : mise en réseau.

Ingestion en flux continu

Amazon Kinesis Data Streams et Google Pub/Sub permettent tous deux d'ingérer des flux de données dans leurs environnements cloud respectifs. Ils s'appuient cependant sur des modèles de service différents pour effectuer cette tâche.

Comparaison des modèles de service

Le tableau suivant compare les fonctionnalités d'Amazon Kinesis Data Streams et de Pub/Sub.

Fonctionnalité Amazon Kinesis Data Streams Pub/Sub
Unité de déploiement Flux Sujet
Unité de provisionnement Partition N/A (service entièrement géré)
Unité de données Enregistrement Message
Source de données Producteur Éditeur
Destination des données Consommateur Abonné
Partitionnement des données Clé de partition fournie par l'utilisateur N/A (service entièrement géré)
Durée de conservation Jusqu'à 7 jours Jusqu'à 7 jours
Ordre de diffusion des données Clé de séquence fournie par le service (de façon la plus optimale possible) Heure de publication fournie par le service (de façon la plus optimale possible)
Taille maximale des données 1 Mo 10 Mo
Niveau de déploiement Régional Mondial
Modèle de tarification Base horaire par partition, en fonction du nombre d'unités de charge PUT et selon la durée de conservation facultative des données Ingestion et diffusion des messages, et conservation facultative des messages
Amazon Kinesis Data Streams

Amazon Kinesis Data Streams ingère les données selon un modèle de traitement par flux. Dans ce modèle, les producteurs envoient des données à un flux que vous créez et dans lequel vous provisionnez des partitions. Chaque partition d'un flux peut fournir jusqu'à 1 Mio par seconde de bande passante d'entrée et 1 000 entrées de données par seconde.

Pour envoyer des données à Amazon Kinesis Data Streams, les utilisateurs peuvent utiliser l'API REST de bas niveau ou, à un niveau supérieur, la bibliothèque Kinesis Producer Library (KPL). Ces données sont stockées dans des enregistrements de données comprenant les éléments suivants :

  • Un numéro de séquence incrémentiel
  • Une clé de partition fournie par l'utilisateur
  • Un blob de données

La clé de partition permet d'équilibrer la charge des enregistrements entre les partitions disponibles. Par défaut, les enregistrements sont conservés pendant 24 heures. Les utilisateurs peuvent toutefois étendre cette période de conservation jusqu'à sept jours au maximum.

L'utilisateur configure une application consommateur qui récupère les enregistrements de données de chaque partition du flux avant de les traiter. Cette application est chargée d'assurer le multiplexage entre les partitions disponibles. L'intégration de la bibliothèque cliente Kinesis d'Amazon dans votre application simplifie ce multiplexage entre les partitions, et permet d'équilibrer la charge et de gérer les défaillances à l'échelle du cluster de nœuds de l'application consommateur.

Pub/Sub

Pub/Sub présente un service de messagerie fondé sur un modèle éditeur/abonné. Après avoir créé un sujet Pub/Sub, vous pouvez y publier des données. Chaque application abonnée à ce sujet peut alors récupérer les données ingérées par ce sujet. Cette approche vous dispense de définir une capacité spécifique telle qu'un nombre de partitions.

Chaque application enregistrée avec Pub/Sub peut récupérer des messages selon un modèle push ou pull :

  • Dans le modèle push, le serveur Pub/Sub envoie une requête à l'application d'abonné via un point de terminaison d'URL préconfiguré.
  • Dans le modèle pull, l'application d'abonné demande des messages au serveur, puis en accuse réception à leur arrivée. Les abonnés en mode pull peuvent récupérer les messages de manière asynchrone ou synchrone.

Chaque message de données publié sur un sujet doit être codé en base64 et ne doit pas dépasser 10 Mo. Au moment de l'ingestion, Pub/Sub ajoute un attribut messageId et un attribut publishTime à chaque message de données. L'attribut messageId correspond à un ID de message unique au sein du sujet, tandis que l'attribut publishTime est un horodatage ajouté par le système au moment de l'ingestion des données. Les éditeurs peuvent ajouter des attributs aux données sous la forme de paires clé-valeur.

Ordre des données

Cette section explique comment Amazon Kinesis Data Streams et Pub/Sub gèrent l'ordre des données demandées par une application consommateur ou une application d'abonné.

Amazon Kinesis Data Streams

Par défaut, Amazon Kinesis Data Streams gère l'ordre des données à l'aide de la clé de partition et du numéro de séquence. Lorsqu'un producteur ajoute un enregistrement à un flux, il fournit une clé de partition déterminant la partition de destination de cet enregistrement. La partition ajoute un numéro de séquence incrémentiel à l'enregistrement, puis stocke ce dernier de manière fiable.

Les applications consommateur demandent des enregistrements partition par partition, et reçoivent ces enregistrements dans l'ordre déterminé par leur numéro de séquence. Ce modèle facilite l'ordonnancement au sein d'une partition donnée, mais l'ordre correct n'est pas garanti lorsque l'application consommateur envoie des requêtes portant sur plusieurs partitions. De plus, un enregistrement peut être distribué plusieurs fois à un consommateur, ce qui oblige l'application à mettre en œuvre une sémantique du type "une fois et une seule". Pour en savoir plus, consultez la section Gestion des enregistrements en double dans la documentation Amazon Kinesis Data Streams.

Pub/Sub

Pub/Sub diffuse les messages au mieux, en se basant sur l'attribut publishTime fourni par le système pour les livrer dans leur ordre de publication. Pub/Sub ne garantit pas que les messages seront livrés une seule fois ni dans l'ordre : il peut arriver qu'un message soit livré à plusieurs reprises ou hors séquence. Votre abonné doit être capable d'effectuer un traitement idempotent des messages et, le cas échéant, de traiter les messages reçus dans le désordre.

Vous pouvez définir un ordonnancement plus strict en recourant à des numéros de séquence fournis par l'application et à la mise en mémoire tampon des messages consommés. Si la cible finale de vos données est un service de stockage persistant compatible avec les requêtes temporelles, telles que Firestore ou BigQuery, vous pouvez également visualiser les données dans un ordre strict en triant vos requêtes par horodatage. Si votre cible est Dataflow, vous pouvez établir un traitement exactement une fois à l'aide des ID d'enregistrement.

Opérations

Cette section examine les coûts opérationnels et de maintenance associés aux charges de travail de production de chaque service.

Amazon Kinesis Data Streams

Dans la mesure où ils doivent effectuer manuellement le scaling à la hausse ou à la baisse des partitions, les utilisateurs d'Amazon Kinesis Data Streams peuvent être obligés de surveiller leur utilisation à l'aide d'Amazon CloudWatch afin de pouvoir procéder aux ajustements requis au fur et à mesure des besoins. Ce processus de scaling, appelé repartitionnement, ne peut être effectué que partition par partition. Le repartitionnement permet deux opérations : fractionner une partition en deux partitions, ou fusionner deux partitions en une seule. Ainsi, pour doubler la capacité offerte par N partitions, il est nécessaire d'effectuer N opérations de fractionnement de partition.

La taille des partitions étant fixe, vous devez prendre en compte la capacité de chacune d'entre elles dans votre conception. Par exemple, si vous choisissez une clé de partition qui aurait pour effet de diriger un pic de trafic vers une partition unique, ce pic pourrait submerger la capacité d'ingestion de la partition désignée. Un simple repartitionnement ne sera probablement pas suffisant pour éviter ce problème à l'avenir. Dans un tel cas, la seule façon de résoudre définitivement le problème consiste à modifier la conception de l'application de façon à utiliser une autre clé de partition.

Vous pouvez vous affranchir de la gestion des partitions de Kinesis Data Streams en utilisant Kinesis Data Firehose. Kinesis Data Firehose automatise la gestion, la surveillance et la mise à l'échelle des flux Kinesis pour un cas d'utilisation spécifique : le regroupement des données d'un flux dans Amazon S3 ou Amazon Redshift. Les utilisateurs spécifient un bucket S3 ou un cluster Redshift, puis Firehose crée et gère un flux au nom de l'utilisateur, en transférant les données vers l'emplacement souhaité à des intervalles spécifiés.

Amazon Kinesis est un service régional dont les flux s'étendent à des régions spécifiques. Par conséquent, toutes les données ingérées doivent être redirigées vers la région dans laquelle le flux est défini.

Pub/Sub

Pub/Sub ne nécessite aucun provisionnement et gère le partitionnement, la réplication et le scaling à votre place.

De plus, vous n'avez pas besoin d'utiliser de clés de partition : Pub/Sub gère le partitionnement des données pour vous. Bien que ces fonctionnalités réduisent considérablement les coûts de gestion, elles limitent également les garanties offertes par Pub/Sub en ce qui concerne l'ordonnancement des messages.

Pub/Sub s'appuie sur l'équilibreur de charge HTTP(S) de Google pour assurer l'ingestion des données dans l'ensemble des régions Google Cloud. Lorsqu'un éditeur publie des données dans Pub/Sub, l'équilibreur de charge HTTP(S) de Google redirige automatiquement le trafic vers les serveurs Pub/Sub d'une région appropriée afin de minimiser la latence.

Coûts

Le modèle de tarification d'Amazon Kinesis Data Streams applique une base horaire par partition, et se base sur le volume de données ainsi que sur leur période de conservation. Par défaut, les données sont conservées pendant 24 heures. L'extension de la période de conservation entraîne des frais supplémentaires. Dans la mesure où Amazon Kinesis Data Streams utilise un modèle provisionné, vous devez payer les ressources que vous provisionnez même si vous ne les utilisez pas.

Amazon Kinesis Data Firehose est tarifé en fonction du volume de données.

Le modèle de tarification de Pub/Sub se base sur le volume de données. Comme Pub/Sub ne nécessite aucun provisionnement de ressources, vous ne payez que les ressources effectivement consommées.

Ingestion groupée

AWS Snowball et Google Transfer Appliance permettent tous deux d'ingérer des données de manière groupée dans leurs environnements cloud respectifs.

AWS Snowball est disponible en deux versions : 50 To (Amérique du Nord uniquement) et 80 To. Transfer Appliance est disponible dans une version de 100 To, nommée TA100, et dans une version de 480 To, nommée TA480.

Résumé comparatif

Le tableau suivant compare les fonctionnalités d'AWS Snowball et de Google Transfer Appliance.

Fonctionnalité AWS Snowball Transfer Appliance
Capacité par unité 50 To ou 80 To 100 To ou 480 To
Débit de transfert maximal 10 Gbit/s 20 Gbit/s pour TA100
40 Gbit/s pour TA480
Avec agrégation automatique de liens pour les deux versions
Mises à jour de l'état de la messagerie ? Non Oui
Montage en rack possible ? Non Oui pour TA100
Non pour TA480
Frais d'utilisation 200 $ pour la version 50 To
250 $ pour version 80 To
300 $ pour la version TA100
1 800 $ pour la version TA480
Frais quotidiens 15 $/jour au-delà de 10 jours 30 $/jour au-delà de 10 jours pour la version TA100
90 $/jour au-delà de 25 jours pour la version TA480
Modes de transfert Push Push ou pull
Transfert de données depuis un magasin d'objets ? Oui Non

Opérations

Les deux services reposent sur des workflows globalement similaires (réception, configuration, transfert des données, expédition retour), mais les modalités de configuration et de chargement des données diffèrent sensiblement de l'un à l'autre.

L'appareil AWS Snowball ne peut pas être monté en rack. Il est conçu pour être installé de manière autonome, à l'instar d'un boîtier PC ATX. Le modèle Transfer Appliance TA100 peut être installé en rack 2U pour une utilisation dans les centres de données. Le modèle TA480 est livré dans sa propre valise sur roulettes et ne peut pas être monté en rack.

Le contraste le plus significatif entre les solutions AWS Snowball et Transfer Appliance réside probablement dans leurs capacités de débit réseau. Les deux solutions acceptent des débits de 1 Gbit/s ou 10 Gbit/s via une connexion RJ-45 et de 10 Gbit/s via une connexion par fibre optique. Toutefois, les deux modèles Transfer Appliance proposent quatre ports Ethernet 10 Gbit/s avec agrégation de liens adaptative à équilibrage de charge, ce qui leur permet d'atteindre un débit nettement supérieur à 10 Gbit/s.

La configuration de l'appareil Snowball s'effectue au moyen d'un écran tactile E Ink. Dans le cas de Transfer Appliance, un écran VGA et un clavier USB sont nécessaires pour accéder à la console, à partir de laquelle une console Web est configurée. Vous pouvez dès lors effectuer toutes les tâches d'administration à distance via un navigateur Web.

Pour charger les données sur l'appareil, les solutions Snowball et Transfer Appliance proposent toutes deux un modèle push pour client de poste de travail. Snowball propose également une API Amazon S3 pour la transmission push. Transfert Appliance propose deux modes de transfert : NFS Pull (où il joue le rôle de client NFS) et NFS Push (où il se comporte comme serveur NFS).

Avec Snowball comme avec Transfer Appliance, vous devez retourner l'appareil via un transporteur.

Enfin, lorsque vos données sont chargées dans le stockage d'objets, il existe une différence importante entre les appareils AWS et Google. Pour Snowball, le déchiffrement des données de l'appareil est inclus dans le service. En revanche, les clients Transfer Appliance doivent déchiffrer les données de l'appareil à l'aide d'un dispositif virtuel Compute Engine de réhydratation, dont les instances sont soumises à la tarification normale des machines virtuelles Compute Engine.

Transfert de stockage d'objets

Si vous envisagez de transférer des charges de travail de big data d'AWS à Google Cloud, le service de transfert de stockage de Google peut vous être utile. Le service de transfert de stockage vous permet de créer des tâches ponctuelles ou récurrentes pour copier des données stockées dans des buckets Amazon S3 vers des buckets Google Cloud Storage. Ce service admet également d'autres sources de données.

Transformation et préparation

Une fois les données ingérées dans votre environnement cloud, vous pouvez les transformer, les filtrer et les traiter selon vos besoins.

Ce document couvre trois catégories de services permettant d'effectuer ce travail : ETL partiellement géré, ETL entièrement géré et transformation de flux.

ETL partiellement géré

Une approche courante des tâches de transformation de données consiste à utiliser des outils basés sur Apache Hadoop, qui offrent généralement un traitement par lot flexible et évolutif. Google Cloud et AWS proposent tous deux des services Hadoop gérés. Google Dataproc et Amazon Elastic MapReduce (EMR) offrent tous deux un provisionnement et une configuration automatiques, une gestion des tâches simplifiée, une surveillance avancée et une tarification flexible. Pour les données basées sur les flux, Dataproc et Amazon EMR sont tous deux compatibles avec Apache Spark Streaming.

En outre, Google Cloud propose le service Dataflow, qui est basé sur Apache Beam plutôt que sur Hadoop. Tandis qu'Apache Spark Streaming considère les flux de données comme des petites tâches par lot, Dataflow est un moteur de traitement axé sur les flux en natif.

Comparaison des modèles de service

Le tableau suivant compare les fonctionnalités d'Amazon EMR, de Dataproc et de Dataflow.

Fonctionnalité Amazon Elastic MapReduce Google Dataproc Google Dataflow
Bibliothèque Open Source Apache Hadoop et Apache Spark Apache Hadoop et Apache Spark Apache Beam
Scaling Manuel ou automatique Manuel ou automatique Manuel ou automatique
Unité de déploiement Cluster Cluster Pipeline
Unité de scaling Nœuds (maîtres, principaux et de tâche) Nœuds (maîtres et de calcul) Nœuds de calcul
Unité de travail Étape Tâche Tâche
Modèle de programmation MapReduce, Apache Hive, Pig, Flink, Spark, Spark SQL, PySpark MapReduce, Apache Hive, Pig, Flink, Spark, Spark SQL, PySpark Apache Beam
Dataproc et Amazon EMR

Dataproc et Amazon EMR proposent des modèles de service similaires. Ils offrent une plate-forme évolutive permettant de filtrer et de regrouper les données, et sont tous deux étroitement intégrés aux outils et services de big data d'Apache, y compris Apache Hadoop, Apache Spark, Apache Hive et Apache Pig.

Dans Dataproc et Amazon EMR, vous créez un cluster composé d'un certain nombre de nœuds. Le service crée un nœud maître unique et un nombre variable de nœuds de calcul. Amazon EMR va plus loin et classe les nœuds de calcul en nœuds principaux et nœuds de tâche.

Une fois le cluster provisionné, l'utilisateur soumet une application (appelée tâche dans Dataproc et dans Amazon EMR) pour qu'elle soit exécutée par le cluster. Les dépendances d'application sont généralement ajoutées aux nœuds du cluster à l'aide de scripts Bash personnalisés, appelés actions d'initialisation dans DataProc et actions d'amorçage dans Amazon EMR. En règle générale, les applications consultent les données provenant d'un espace de stockage stable (tel qu'Amazon S3, Cloud Storage ou HDFS), puis les traitent à l'aide d'un outil ou service de traitement de données Apache. Une fois cette étape effectuée, les données obtenues peuvent être traitées de façon plus approfondie ou envoyées dans un espace de stockage stable.

Dataflow

Dataflow effectue les opérations de traitement par lot et par flux selon un modèle de programmation Apache Beam. Ce modèle permet plus de flexibilité et d'expressivité que le modèle Apache Spark utilisé par Amazon EMR et Dataproc, en particulier pour le traitement des données en temps réel.

Dans Dataflow, vous spécifiez un pipeline abstrait, en vous appuyant sur une bibliothèque du SDK Dataflow pour fournir les primitives de traitement en parallèle et d'agrégation. Lors de la spécification d'un pipeline, l'utilisateur définit un ensemble de transformations, qui sont ensuite soumises à ce pipeline pour exécution. Ces transformations sont à leur tour mappées à un ensemble de nœuds de calcul qui sont configurés pour être exécutés par Dataflow. Certains nœuds permettent de lire des données à partir de Pub/Sub, tandis que d'autres peuvent effectuer des transformations en aval. Les détails sont gérés par l'environnement d'exécution Dataflow.

Le modèle Dataflow, les SDK et les outils d'exécution de pipeline ont été acceptés dans l'incubateur de projets Open Source Apache sous le nom Apache Beam. Ainsi, les applications Dataflow peuvent également être exécutées dans un cluster Flink ou Spark, ou dans un environnement de développement local.

Pour obtenir une comparaison détaillée des modèles de programmation Apache Beam et Apache Spark, consultez la page Dataflow/Beam et Spark : comparaison des modèles de programmation.

Scaling

Cette section explique comment gérer le scaling avec Amazon EMR, Dataproc et Dataflow.

Dataproc et Amazon EMR

Amazon EMR et Dataproc vous permettent d'ajuster manuellement ou automatiquement le nombre de nœuds dans un cluster une fois celui-ci démarré. Pour le scaling manuel, vous pouvez déterminer la taille du cluster, ainsi que les actions de scaling requises, en surveillant les performances et l'utilisation de ce cluster pour prendre les décisions de gestion appropriées. Dans les deux services, les utilisateurs paient pour le nombre de nœuds provisionnés.

Dataflow

Avec Dataflow, l'autoscaling est activé par défaut. Vous spécifiez le nombre maximum de nœuds et le système d'exécution de Dataflow procède à un autoscaling des nœuds, en gérant activement le provisionnement des nœuds et leur allocation aux différentes parties du pipeline selon les besoins. Vous pouvez également choisir de gérer le scaling manuellement.

Coûts

Cette section traite des modalités d'évaluation des coûts pour Amazon EMR, Dataproc et Dataflow.

Amazon EMR et Dataproc

Amazon EMR et Dataproc permettent tous deux une tarification à la demande ainsi que des remises associées à une utilisation à court et long terme. Les deux services sont facturés à la seconde. Les utilisateurs d'Amazon EMR ont la possibilité de réduire le coût des nœuds en préachetant des instances réservées. Dataproc propose automatiquement des remises proportionnelles à une utilisation soutenue.

En outre, chaque service propose des options d'achat de capacité de calcul excédentaire à prix réduit. Amazon EMR permet de provisionner des nœuds avec des instances ponctuelles Amazon EC2, où la capacité inutilisée est mise aux enchères par incréments de courte durée. Ces nœuds peuvent être récupérés par EC2, mais le cluster poursuit le traitement à mesure que des nœuds sont ajoutés ou supprimés. De même, Dataproc est compatible avec les VM préemptives, qui peuvent être récupérées à tout moment. Celles-ci ne sont pas vendues aux enchères sur un marché. Elles offrent à la place une remise horaire fixe pour chaque type de machine Compute Engine.

Pour une comparaison détaillée de la tarification du service Hadoop géré pour les environnements cloud courants (dont Google Cloud et AWS), consultez l'article Comprendre les tarifs des services cloud : moteurs de traitement big data.

Dataflow

Dataflow est facturé à l'heure en fonction du type de nœud de calcul Dataflow. Pour en savoir plus, consultez la page Tarifs de Dataflow.

ETL entièrement géré

AWS et Google Cloud proposent tous deux des offres qui simplifient la configuration de la transformation en automatisant des parties importantes du travail et en générant des pipelines de transformation.

Dans AWS, vous pouvez utiliser AWS Glue, un service AWS entièrement géré qui répond conjointement aux problématiques de catalogage et de préparation des données. AWS Glue met en œuvre des robots d'exploration définis par l'utilisateur pour automatiser le processus de remplissage du catalogue de données AWS Glue à partir de différentes sources de données. Une fois le catalogue de données rempli, vous pouvez définir une tâche AWS Glue. La création de cette tâche génère un script Python ou Scala compatible avec Apache Spark, que vous pouvez ensuite personnaliser. Les tâches AWS Glue peuvent être exécutées selon un calendrier prédéfini ou être déclenchées par des événements.

Exploité par Trifacta, Cloud Dataprep est un service entièrement géré qui s'intègre facilement à vos projets et données Cloud. Dataprep vous permet d'explorer et de nettoyer les données que vous avez identifiées en vue d'une analyse plus approfondie. Ces données peuvent être structurées ou non, et peuvent provenir de Google Cloud Storage, de BigQuery ou d'un fichier importé. Le travail est organisé en flux représentant chacun un ou plusieurs ensembles de données sources, des transformations et des ensembles de données préparés. Dataprep propose une interface graphique permettant de découvrir des informations et de planifier un processus de transformation. Ces transformations sont spécifiées dans le langage spécifique au domaine Wrangle et peuvent être définies manuellement aussi bien que via l'interface graphique. Votre flux est exécuté sur le service entièrement géré Dataflow pour effectuer des transformations.

Transformation de flux

AWS et Google Cloud proposent plusieurs services permettant de transformer des flux de données.

Dataproc et Amazon EMR

Amazon EMR applique un modèle de flux de données de façon native en acceptant Amazon Kinesis Data Streams comme méthode d'ingestion de données. Dans ce modèle, l'application lit les données disponibles stockées dans le flux jusqu'à ce qu'aucune nouvelle donnée ne soit disponible pendant une durée déterminée. Lorsque toutes les partitions sont dégagées, l'étape de réduction commence et les données sont regroupées. Amazon EMR permet également la transmission de flux de données à partir de services tiers tels qu'Apache Kafka via une mise en œuvre native d'Apache Spark Streaming.

Bien que Dataproc ne puisse pas lire les flux de données directement à partir de Pub/Sub, Apache Spark est préinstallé sur tous les clusters Dataproc. Cela vous permet d'utiliser Dataproc pour lire les flux de données provenant d'Apache Kafka. En outre, Dataflow vous permet de lire et de traiter les flux de données provenant de Pub/Sub.

Google Dataflow et Amazon Kinesis Data Firehose

Comme indiqué précédemment, Dataflow accepte aussi bien le traitement par flux que le traitement par lot. De même que pour le traitement par lot, le moteur de traitement par flux exécute Apache Beam, et vous pouvez appliquer une transformation aux sources de traitement par lot et de traitement par flux sans aucune modification du code. Pub/Sub est la seule source d'événements utilisée avec Dataflow en mode traitement par flux, et Pub/Sub peut traiter des messages d'une taille maximale de 10 Mo. Comme pour les transformations groupées, les transformations de flux Dataflow sont entièrement gérées et sont adaptées de manière automatique, avec une évolutivité indépendante pour tous les composants du pipeline de transformation.

Amazon Kinesis Data Firehose peut effectuer la transformation d'un flux en associant à celui-ci une fonction AWS Lambda. Cette fonction est capable de traiter des entrées d'une taille maximale de 6 Mo et de renvoyer jusqu'à 6 Mo de données. Vous pouvez reproduire cette approche dans Google Cloud à l'aide de Pub/Sub et de Cloud Functions.

Entreposage et analyse

Une fois les données ingérées et transformées, vous pouvez les analyser et vous en servir pour créer des visualisations. Généralement, les données prêtes à être analysées aboutissent dans l'un de ces deux emplacements :

  • Un service de stockage d'objets tel qu'Amazon S3 ou Google Cloud Storage
  • Un entrepôt de données géré tel qu'Amazon Redshift ou Google BigQuery

Entrepôts de données gérés

Cette section porte sur Amazon Redshift et le stockage natif de Google BigQuery.

Comparaison des modèles de service

Le tableau suivant compare les fonctionnalités d'Amazon Redshift et de Google BigQuery.

Fonctionnalité Amazon Redshift Google BigQuery
Unité de déploiement Cluster N/A (service entièrement géré)
Unité de provisionnement Nœud N/A (service entièrement géré)
Types de stockage des nœuds Disque dur/SSD N/A (service entièrement géré)
Scaling des ressources de calcul Manuel, jusqu'à 128 nœuds Ajustement automatique et illimité
Nombre maximal de requêtes Jusqu'à 50 requêtes simultanées sur l'ensemble des files d'attente définies par l'utilisateur Jusqu'à 1 000 requêtes simultanées
Nombre maximal de tables Jusqu'à 20 000 tables pour les grands types de nœuds Aucune limite Les performances sont optimales lorsque le nombre de tables par ensemble de données n'excède pas 50 000. Nombre illimité d'ensembles de données
Gestion des sauvegardes Instantanés N/A (service entièrement géré)
Niveau de déploiement Zonale Régional
Modèle de tarification Par heure Par volume de stockage et de requêtes
Langage de requête Compatible avec PostgreSQL Ancien SQL de BigQuery ou SQL standard
Machine learning intégré ? Non Oui
Amazon Redshift

Amazon Redshift propose une exécution SQL hautes performances à l'aide d'une architecture de traitement massivement parallèle opérant sur un cluster de nœuds provisionnés. Lorsque vous utilisez Amazon Redshift, vos informations sont stockées dans une base de données en colonnes qui est automatiquement répliquée sur les nœuds du cluster. Vos données sont stockées dans le cluster, qui doit par conséquent rester actif pour assurer leur conservation. (Vous avez toutefois la possibilité d'exporter vos données depuis Amazon Redshift vers Amazon S3 et de les recharger dans un cluster Amazon Redshift pour les interroger ultérieurement). Une extension d'Amazon Redshift nommée Spectrum propose une alternative qui vous permet d'interroger directement les données stockées dans les formats acceptés par Amazon S3.

Comme mentionné plus haut, Amazon Redshift applique un modèle provisionné, selon lequel vous sélectionnez un type d'instance, puis provisionnez un nombre spécifique de nœuds en fonction de vos besoins. Une fois le déploiement effectué, vous pouvez vous connecter au cluster, puis charger et interroger vos données à l'aide du connecteur compatible PostgreSQL de votre choix.

Amazon Redshift est un service partiellement géré. Si vous souhaitez étendre ou réduire un cluster – par exemple, pour réduire les coûts pendant les périodes de faible utilisation ou pour augmenter les ressources durant les pics d'utilisation –, vous devez le faire manuellement. En outre, Amazon Redshift vous oblige à définir et à gérer vos clés de distribution et de tri, ainsi qu'à effectuer manuellement les processus de nettoyage et de défragmentation des données.

Google BigQuery

BigQuery est entièrement géré. Vous n'avez pas besoin de provisionner des ressources : il vous suffit de transférer des données vers BigQuery, puis de les interroger. BigQuery gère les ressources requises et les adapte automatiquement selon les besoins. BigQuery accepte également les requêtes fédérées, qui peuvent inclure des données stockées sous des formats Open Source dans Cloud Storage ou Google Drive, ainsi que des données stockées nativement dans Cloud Bigtable.

En arrière-plan, BigQuery exploite les puissants services d'envergure mondiale utilisés en interne par Google.

  • Le stockage, le chiffrement et la réplication des données font appel à Colossus, le système de fichiers distribué de dernière génération de Google.
  • Le traitement des tâches s'appuie sur Borg, le système de gestion des clusters à grande échelle de Google.
  • Les requêtes sont exécutées à l'aide de Dremel, le moteur de requêtes interne de Google.

Pour en savoir plus, consultez cet article du blog Google Cloud : Les rouages de BigQuery (en anglais).

Les tables BigQuery sont des tables en mode append-only offrant des possibilités de suppression limitées pour la correction d'erreurs. Les utilisateurs peuvent effectuer des requêtes interactives ou créer et exécuter des tâches de requêtes par lot. BigQuery est compatible avec deux langages de requête :

  • l'ancien SQL, qui est un dialecte SQL spécifique à BigQuery ;
  • le langage SQL standard, qui est conforme à la norme SQL 2011 et inclut des extensions permettant d'interroger des données imbriquées et répétées.

En outre, BigQuery permet l'intégration d'un certain nombre d'outils, connecteurs tiers et services partenaires pour l'ingestion, l'analyse, la visualisation et le développement.

Machine learning

BigQuery est compatible en natif avec le machine learning. BigQuery ML propose un ensemble de modèles pour le traitement de questions métier courantes – par exemple, un modèle de régression linéaire pour les prévisions de ventes, et un modèle de régression logistique binaire pour la classification, servant en particulier à déterminer si un client est susceptible d'effectuer un achat. De nombreux ensembles de données BigQuery sont disponibles pour l'entraînement des modèles ainsi que pour la prédiction.

Scaling

Amazon Redshift peut évoluer d'un seul nœud à un maximum de 32 ou 128 nœuds selon les types de nœuds. Avec les nœuds de stockage dense, la capacité maximale de Redshift est de 2 To de données stockées, y compris les données répliquées. Les mécanismes de requête et d'ingestion d'Amazon Redshift partagent le même pool de ressources, d'où un risque de dégradation des performances des requêtes lorsque vous chargez de très grandes quantités de données.

Amazon Redshift Spectrum permet d'étendre cette capacité. Toutefois, en cas d'utilisation de Redshift Spectrum, un cluster Amazon Redshift doit être actif pour exécuter des requêtes sur ces données. Le traitement des requêtes étant partagé entre deux couches (Amazon Redshift et Redshift Spectrum), vous devez construire les requêtes de manière à utiliser chaque couche le plus efficacement possible.

En revanche, BigQuery ne pose aucune limite pratique quant à la taille d'un ensemble de données stocké. Les ressources d'ingestion évoluent rapidement et l'ingestion elle-même est extrêmement rapide. Avec l'API BigQuery, vous pouvez ingérer des millions de lignes par seconde dans BigQuery. De plus, les ressources d'ingestion sont découplées des ressources de requête, ce qui empêche la charge d'ingestion de dégrader les performances de la charge de requête. BigQuery peut également effectuer des requêtes sur les données stockées dans Google Cloud Storage. Ces requêtes fédérées ne nécessitent aucune modification de l'écriture des requêtes. Les données sont simplement affichées sous la forme d'une nouvelle table.

Opérations

Cette section compare les aspects opérationnels de l'utilisation d'Amazon Redshift et de Google BigQuery.

Amazon Redshift

En tant que service partiellement géré, Amazon Redshift se charge d'un grand nombre des détails opérationnels nécessaires à l'exploitation d'un entrepôt de données. Ceux-ci incluent les sauvegardes de données, leur réplication et la gestion des défaillances, ainsi que le déploiement et la configuration des logiciels. Cependant, plusieurs détails opérationnels restent à votre charge, parmi lesquels la gestion des performances, le scaling et la simultanéité.

Pour garantir de bonnes performances, vous devez définir des clés de distribution statiques lorsque vous créez des tables. Ces clés de distribution permettent ensuite au système de partitionner les données entre les nœuds de façon à pouvoir exécuter les requêtes en parallèle. Étant donné que les clés de distribution peuvent avoir un impact significatif sur les performances des requêtes, vous devez les choisir avec soin. Une fois que vous avez défini des clés de distribution, vous ne pouvez plus les modifier. Pour utiliser des clés différentes, vous devez créer une table dotée des nouvelles clés voulues et y copier les données de l'ancienne table.

De plus, Amazon vous recommande d'effectuer une maintenance périodique afin que les performances des requêtes restent constantes. Comme les mises à jour et les suppressions ne compactent pas automatiquement les données présentes sur le disque, elles peuvent entraîner à terme des goulots d'étranglement affectant les performances. Pour en savoir plus, consultez la page Exécution de l'opération VACUUM sur les tables dans la documentation d'Amazon Redshift.

Dans Amazon Redshift, vous devez gérer avec soin les utilisateurs et les applications. À titre d'exemple, les utilisateurs doivent ajuster le nombre de requêtes simultanées qu'ils effectuent. Par défaut, Amazon Redshift effectue jusqu'à cinq requêtes simultanées. Vous pouvez augmenter le nombre de requêtes simultanées jusqu'à 50. Toutefois, étant donné que les ressources sont provisionnées à l'avance, l'augmentation de cette limite peut avoir une incidence sur les performances et le débit. Pour plus d'informations, consultez la section Niveau de simultanéité de la page Implémentation de la gestion manuelle de la charge de travail, dans la documentation d'Amazon Redshift.

Vous devez également dimensionner votre cluster en fonction de la taille globale des données, des performances des requêtes et du nombre d'utilisateurs simultanés. Vous avez la possibilité de faire évoluer le cluster. Gardez toutefois à l'esprit que, compte tenu du modèle provisionné, vous payez pour les ressources que vous provisionnez, indépendamment de l'utilisation.

Enfin, les clusters Amazon Redshift sont limités à une seule zone par défaut. Pour créer une architecture Amazon Redshift hautement disponible et multirégionale, il vous faut créer des clusters supplémentaires dans d'autres zones, puis élaborer un mécanisme assurant la cohérence entre les clusters. Pour en savoir plus, consultez l'article Création de clusters Amazon Redshift multi-AZ ou multirégionaux du blog Amazon Big Data (en anglais).

Pour en savoir plus sur les autres quotas et limites d'Amazon Redshift, consultez la page Limites dans Amazon Redshift.

BigQuery

Dans la mesure où BigQuery est entièrement géré, les tâches opérationnelles restant à la charge de l'utilisateur sont fortement réduites, voire nulles :

  • BigQuery gère automatiquement le partitionnement. Vous n'avez pas à créer ni gérer les clés de distribution.
  • BigQuery est un service à la demande et non un service provisionné. Vous n'avez pas à vous soucier du sous-provisionnement, qui peut entraîner des goulots d'étranglement, ni du surprovisionnement, source de coûts inutiles.
  • BigQuery propose une réplication de données globale et gérée. Vous n'avez pas besoin de configurer et de gérer plusieurs déploiements.
  • BigQuery gère jusqu'à 50 requêtes interactives simultanées sans aucun impact sur les performances ni le débit.

Pour en savoir plus sur les quotas et les limites de BigQuery, consultez la page Quotas et limites dans la documentation BigQuery.

Coûts

Amazon Redshift propose deux types de tarification : la tarification à la demande et la tarification des instances réservées. La tarification est basée sur le nombre d'instances provisionnées et leur type. Vous pouvez bénéficier de tarifs réduits en achetant d'emblée des instances réservées. Amazon propose des durées de réserve d'un an et de trois ans. Pour en savoir plus, consultez la page Tarification d'Amazon Redshift.

BigQuery vous facture les frais d'utilisation. La tarification se base sur la taille de stockage des données, le coût de calcul des requêtes et les insertions en flux continu. Si aucune table n'est mise à jour pendant 90 jours consécutifs, le prix du stockage des données diminue de moitié. Les requêtes sont facturées par téraoctet de données traitées. BigQuery propose une tarification à la demande ainsi qu'une tarification forfaitaire, qui permet de réaliser des économies substantielles pour des charges de travail prévisibles. BigQuery offre d'importants quotas d'utilisation gratuite : jusqu'à 20 Go d'espace de stockage et 1 To de lectures de requêtes par mois. Pour en savoir plus, consultez la page Tarifs de BigQuery.

Entrepôts de stockage d'objets

Les magasins d'objets sont un autre mécanisme couramment utilisé pour le stockage de données volumineuses. Amazon S3 et Google Cloud Storage sont des services de stockage d'objets entièrement gérés présentant des caractéristiques comparables. Pour en savoir plus sur ces deux services, consultez la section Stockage d'objets distribué dans le document comparatif consacré au stockage.

Pour les données volumineuses auxquelles vous accédez rarement, Google Cloud Storage Coldline est un choix judicieux, comparable au service de stockage Amazon Glacier. Pour en savoir plus sur ces deux services, consultez la page Google Cloud pour les utilisateurs professionnels d'AWS : stockage.

Analyse et stockage d'objets

Cette section porte sur la compatibilité d'Amazon Athena et de Google BigQuery avec le stockage d'objets.

Modèle de service

AWS Athena est un service d'analyse sans serveur compatible avec le stockage d'objets. Il vous permet d'exécuter des requêtes SQL sur des données dont le schéma est défini dans Amazon S3. Les requêtes fédérées BigQuery sont comparables à ce service et acceptent les données Google Cloud Storage, Google Drive et Bigtable.

Athena et BigQuery sur Cloud Storage sont deux services entièrement gérés offrant en particulier le scaling automatique, de sorte que les modèles de service sont similaires.

Scaling

En termes de volume de données, Amazon S3 et Cloud Storage offrent tous deux un espace de stockage à l'échelle de l'exaoctet. Amazon S3 limite le nombre de buckets à 100 par compte. Cloud Storage limite la cadence de création des buckets à un bucket toutes les deux secondes, mais le nombre de buckets par projet, par dossier ou par organisation n'est pas limité.

En ce qui concerne le délai d'exécution des requêtes, Athena expire au bout de 30 minutes, tandis que BigQuery expire au bout de 6 heures. Athena présente une limite logicielle de 20 requêtes DDL et de 20 requêtes DML simultanées. BigQuery gère jusqu'à 50 requêtes interactives simultanées sans aucun impact sur les performances ni le débit. Les requêtes de simulation ne sont pas prises en compte dans cette limite. Cette limite peut être augmentée au niveau du projet.

Athena limite la longueur des chaînes de requête à 262 144 octets. La taille des requêtes non résolues en ancien SQL BigQuery est limitée à 256 Ko, tandis que celle des requêtes non résolues en SQL standard est limitée à 1 Mo. Après la résolution, les vues et les tables génériques référencées sont prises en compte dans la taille globale de la requête : la limite pour les deux dialectes SQL BigQuery est alors de 12 Mo.

Opérations

Athéna et BigQuery étant entièrement gérés, la surcharge opérationnelle imposée à l'utilisateur est fortement réduite, voire nulle.

Coûts

Les coûts de stockage de Google Cloud Storage et d'Amazon S3 sont comparables, et sont essentiellement constitués par les frais de transfert et de stockage. Les clients Cloud Storage cherchant à stabiliser leurs coûts peuvent souscrire au forfait Augmentation du stockage, qui leur garantit des coûts mensuels constants.

AWS Athena et BigQuery (dans le cadre de la tarification à la demande) facturent 5 $ par téraoctet pour les requêtes. Cependant, les deux services ne mesurent pas le téraoctet de la même façon. Athena facture le nombre d'octets lus dans Amazon S3, ce qui signifie que les requêtes portant sur des données compressées coûtent moins cher que celles qui portent sur des données non compressées. BigQuery facture le nombre d'octets traités, si bien que le coût est identique quels que soient l'emplacement et le mode de stockage des données.

Les deux services appliquent un minimum de facturation de 10 Mo par requête. Aucun des deux services ne facture les requêtes ayant échoué, mais l'un et l'autre facturent le travail effectué sur les requêtes annulées.

Athena n'offre aucun niveau d'utilisation gratuite. Avec BigQuery, la première tranche de 1 To traitée chaque mois est gratuite pendant toute la durée de vie de votre compte.

Visualisation des données

Si vous utilisez AWS QuickSight, vous pouvez trouver des fonctionnalités comparables dans Google Data Studio. La principale différence réside dans la tarification. Data Studio est gratuit, tandis que QuickSight est facturé par session. De plus, Data Studio s'intègre à G Suite de façon à faciliter le partage au sein de votre organisation, tout comme Documents, Sheets et Slides.

Pour un contrôle renforcé ou dans le cadre de recherches scientifiques, Google propose également Colaboratory, un service gratuit et sans configuration qui s'intègre à BigQuery à l'aide de notebooks Jupyter.