This 1-week accelerated on-demand course introduces participants to the Big Data and Machine Learning capabilities of Google Cloud Platform (GCP). It provides a quick overview of the Google Cloud Platform and a deeper dive of the data processing capabilities. At the end of this course, participants will be able to: • Identify the purpose and value of the key Big Data and Machine Learning products in the Google Cloud Platform • Use CloudSQL and Cloud Dataproc to migrate existing MySQL and Hadoop/Pig/Spark/Hive workloads to Google Cloud Platform • Employ BigQuery and Cloud Datalab to carry out interactive data analysis • Choose between Cloud SQL, BigTable and Datastore • Train and use a neural network using TensorFlow • Choose between different data processing products on the Google Cloud Platform Before enrolling in this course, participants should have roughly one (1) year of experience with one or more of the following: • A common query language such as SQL • Extract, transform, load activities • Data modeling • Machine learning and/or statistics • Programming in Python Google Account Notes: • Google services are currently unavailable in China. Buscando la versión en español de este curso? Visita https://www.coursera.org/learn/gcp-big-data-ml-fundamentals-es/ このコースの日本語版をお探しですか？https://www.coursera.org/learn/gcp-big-data-ml-fundamentals-jp/
Fast Random Access
Loading...
Do curso por Google Cloud
Google Cloud Platform Big Data and Machine Learning Fundamentals
3217 classificações
Google Cloud
3217 classificações
Curso 1 de 5 em Specialization Data Engineering on Google Cloud Platform
Na lição
Scaling Data Analysis and Machine Learning
This module is about the more transformational technologies in Google Cloud platform that may not have immediate parallels to technologies that attendees are using (“what's next”).
Conheça os instrutores
Google Cloud Training
Nous allons voir quelques opérations de transformation,
et tout d'abord l'accès aléatoire rapide.
De nombreux langages de programmation sont orientés objet,
ce qui signifie que la majeure partie du logiciel que vous développez
traite des objets,
qui présentent l'avantage d'être hiérarchiques.
Imaginons par exemple que vous disposiez dans votre programme
d'une structure de données hiérarchique telle qu'un joueur.
Nous avons des joueurs qui sont soit des footballeurs,
soit des joueurs de cricket,
et les joueurs de cricket ne sont pas tous lanceurs.
Donc, seuls certains joueurs de cricket ont des moyennes au lancer,
mais tous ont des moyennes à la batte, car ils sont tous batteurs.
Nous avons donc cette hiérarchie
que nous voulons représenter dans une base de données relationnelle
pour conserver les données.
Si vous utilisez une base de données relationnelle
pour conserver une hiérarchie d'objets,
vous obtenez un défaut d'impédance objet/relationnel.
Par exemple, nous avons dit
que tous les joueurs de cricket ont des moyennes à la batte,
mais que tous n'ont pas des moyennes au lancer.
Pourtant, quand nous regardons la table,
nous voyons qu'il y aura un nom, un club,
une moyenne à la batte et une moyenne au lancer.
Mais quelle est la moyenne à la batte d'un footballeur ?
Ça n'a aucun sens, mais nous ne pouvons pas faire autrement que d'en avoir une.
Nous utilisons donc la valeur Null à ce niveau,
et nous nous retrouvons à partir de là avec des problèmes d'intégrité des données.
Comment pouvons-nous éviter ce problème de mappage objet/relationnel ?
L'une des méthodes consiste à stocker les objets directement.
C'est ce que vous pouvez faire avec Cloud Datastore sur GCP.
Datastore peut s'adapter pour traiter des téraoctets de données,
là où une base de données relationnelle atteint ses limites avec quelques gigaoctets.
Datastore peut traiter de très grandes quantités de données,
et, d'un point de vue conceptuel,
ce que vous stockez dans un datastore est comparable à une table de hachage.
C'est donc une clé (ou une ID) associée à une valeur
qui permet de stocker l'intégralité de l'objet.
Vous écrivez donc la totalité de l'objet dans Datastore.
Mais pour la lecture (la recherche),
vous pouvez utiliser la clé, mais également une propriété.
Vous pouvez donc rechercher tous les joueurs de cricket
dont la moyenne à la batte est supérieure à 30 courses par partie.
Vous pouvez utiliser pour cela l'un des flux indexés
auxquels nous allons nous intéresser sous peu.
La mise à jour peut ne concerner que la moyenne à la batte d'un joueur
et être effectuée de manière transactionnelle.
Datastore est donc compatible avec les transactions
et vous permet de lire et d'écrire des données structurées.
C'est une assez bonne solution alternative
que vous pouvez utiliser avec votre application,
afin de conserver vos données,
à la place d'une base de données relationnelle.
Vous devez toutefois y avoir recours de manière explicite,
à la différence de ce dont il a été question dans le chapitre précédent,
par exemple
lorsque nous avons parlé d'un programme Spark exécuté sur site sur un cluster Hadoop.
Pour exécuter ce programme sur GCP, il suffit de l'exécuter sur Dataproc,
et votre code est presque intégralement migré sans modification.
Si vous avez un codebase MySQL,
tout ce qui est possible sur site l'est également sur GCP avec Cloud SQL.
Il s'agit de migrations simples.
Il suffit de prendre ce que vous avez, avec les cas d'utilisation correspondants,
et de tout faire passer sur le cloud.
Mais avec Datastore, la migration n'est pas aussi simple.
Vous devez modifier le code que vous créez
en tenant compte du fait que l'interaction avec Datastore
diffère de l'interaction avec une base de données relationnelle.
Donc, comment peut-on interagir avec Datastore ?
Ce qui est déterminant pour le mode d'interaction,
c'est que Datastore s'apparente à une table de hachage persistante.
Imaginons par exemple que vous vouliez conserver des objets Author (Auteur).
Vous diriez que vous avez une classe Author,
que c'est une entité, et que c'est l'identité.
C'est une annotation que vous ajoutez.
Je vous montre ici du code Java,
mais ça fonctionne avec plusieurs langages orientés objet.
Vous dites que l'auteur se distingue par son adresse e-mail,
et l'adresse e-mail est une colonne ID, donc vous ajoutez l'ID.
Nous voulons effectuer une recherche sur les auteurs à l'aide de leur nom,
donc nous voulons que la propriété name soit indexée.
Et uniquement pour vous montrer
que vous pouvez avoir des relations de composition,
un auteur peut avoir divers centres d'intérêt (interests).
C'est la même chose avec les entrées de livre d'or (guestbook)
que vous stockez, chacune ayant une ID faisant qu'elle est unique.
Elle a une clé parente (parent key) et un auteur.
Ce sont les personnes qui ont écrit l'entrée de livre d'or, et c'est une relation.
Nous avons des messages,
que nous ne devrions pas rechercher
car ils ne sont pas indexés :
donc pas de recherche d'entrées de livre d'or sur la base du texte du message.
Et puis nous avons des dates
sur la base desquelles nous pourrions souhaiter effectuer des recherches.
Donc, dès lors que vous avez une entité, vous avez un auteur,
lequel a un e-mail qui est l'ID et un nom qui est l'index.
Donc, si vous voulez créer un auteur, vous appelez le constructeur,
comme vous le feriez pour une tâche ou un objet de base.
Le nouvel auteur est donc xjin@bu.edu. Le nom est Ha Jin.
Vous avez votre objet Author, mais à ce stade il n'existe qu'en mémoire.
Vous voulez l'enregistrer.
Vous utilisez donc save en transmettant l'entité.
Ici, ofy est la bibliothèque de fichiers d'objectif.
C'est l'une des quelques bibliothèques Java qui vous aident à utiliser Datastore.
Donc, dans ce cas, le code indique le fichier d'objectif.
Nous enregistrons l'entité, et voilà.
À ce stade, le nécessaire a été fait pour que l'objet xjin soit conservé.
Si vous voulez le lire ou le rechercher,
vous pouvez charger tous les auteurs et les filtrer en vous servant du nom Ha Jin,
et c'est possible puisque le nom est un champ indexé.
Nous pouvons filtrer les données avec le nom Ha Jin,
et nous obtiendrons un itérable des auteurs.
Pourquoi un itérable et pas une liste des auteurs ?
C'est parce que Datastore peut traiter des téraoctets de données.
L'une de ces colonnes sur lesquelles votre recherche est basée
pourrait donc donner des gigaoctets de données,
ce qui pourrait être bien plus que ce que la mémoire peut contenir.
C'est la raison pour laquelle vous obtenez un itérable.
Donc, si vous savez que vous allez seulement obtenir un élément,
tel que le deuxième ici,
vous chargez les auteurs et vous trouvez l'ID xjin@bu.edu.
À ce stade, vous allez obtenir un auteur,
de sorte que le mieux est de récupérer l'objet Author.
Nous l'appelons jh dans le code,
et nous pouvons maintenant mettre à jour le nom de jh.
Nous pouvons indiquer jh.name = Jin Xuefei, puis enregistrer cette entité.
Nous disposons à ce stade d'un objet nouvellement enregistré,
avec un nouveau nom.
Et si nous voulons supprimer l'entité, il suffit d'indiquer delete().entity(jh).
Donc créer, lire, mettre à jour et supprimer :
pratiquement tout ce que vous faites dans une base de données relationnelle
est également faisable avec Datastore de manière transactionnelle.
Toujours en remplacement d'une base de données relationnelle,
vous pouvez utiliser Datastore
si vous avez besoin d'une prise en charge transactionnelle
pour des données hiérarchiques,
chose que les bases de données relationnelles ne traitent pas très bien.
Une autre situation dans laquelle elles pourraient ne pas bien fonctionner,
que nous avons vue
dans la section du chapitre précédent consacrée à l'évaluation du module,
c'est celle dans laquelle vous avez besoin d'un débit élevé.
Si vous disposez de capteurs répartis dans le monde entier,
et que vous recevez des millions de messages par minute,
les performances de Cloud SQL risquent de ne pas être optimales.
Une base de données relationnelle ne peut alors être très efficace.
L'opération consiste essentiellement à ajouter des données.
Nous ne faisons que les recevoir et les enregistrer,
et nous n'avons pas besoin d'une prise en charge transactionnelle.
Et étant donné que nous sommes disposés à y renoncer,
nous pouvons avoir recours à la puissance de Bigtable,
laquelle ne se chiffre pas en téraoctets comme celle de Datastore, mais en pétaoctets.
L'inconvénient est qu'il est dans ce cas impossible
de ne mettre à jour qu'un seul champ de l'objet.
Nous devons écrire une ligne entièrement nouvelle.
L'idée est que, si nous obtenons un nouvel objet, nous l'ajoutons à la table
avant de lire les données les plus récentes et de revenir en arrière.
Il résulte de cela que le tout premier objet que nous trouvons au niveau d'une clé donnée
est la toute dernière version de cet objet.
Les performances de Bigtable sont donc vraiment bonnes
lorsque vous avez besoin d'un débit élevé
dans le cadre de scénarios pour lesquels vous ne voulez pas
avoir à gérer l'infrastructure.
Vous voulez autant que possible disposer d'une solution no-ops.
Avec Bigtable, vous traitez des données plates, non hiérarchiques,
et la recherche ne peut être effectuée que sur la base de la clé.
C'est la raison pour laquelle la clé et la façon dont elle est conçue
sont extrêmement importantes.
Vous devez tout d'abord envisager la clé
comme s'il s'agissait de la requête que vous allez exécuter.
Encore une fois, c'est parce que la recherche ne peut porter que sur la clé,
et pas sur des propriétés.
Vous devez donc faire en sorte
que votre clé vous permette de trouver rapidement ce que vous cherchez.
Elle doit aussi vous permettre d'éviter le hotspotting,
c'est-à-dire les situations dans lesquelles
tous vos objets et toutes vos lignes se retrouveraient dans le même bucket.
Vous voulez que les données soient réparties.
Quant aux tables, elles doivent être longues et étroites.
Longues parce que vous ne cessez d'y ajouter des données.
Et étroites. Pourquoi étroites ?
L'idée est que, si vous avez par exemple des indicateurs booléens,
plutôt que d'avoir recours pour chacun à une colonne contenant la valeur 0 ou 1,
vous pouvez peut-être n'avoir qu'une seule colonne
spécifiant les indicateurs valides pour l'objet concerné.
Cette démarche peut se révéler extrêmement utile
si vous essayez par exemple de stocker des notes d'utilisateurs.
Un utilisateur peut ne noter que cinq des articles de votre catalogue.
Plutôt que des milliers de colonnes correspondant à chacun de vos articles,
vous pouvez ne stocker que des données de type "objet,note"
pour les articles qui ont été effectivement notés,
dans une nouvelle colonne.
Même si j'ai souligné la nécessaire étroitesse de la table,
je me dois d'évoquer le concept de famille de colonnes.
Disons par exemple que "MD" correspond à "market data" (données de marché).
Nous avons ici MD:SYMBOL (symbole) ou encore MD:LASTSALE (dernière vente),
et cela nous permet de regrouper les colonnes liées.
Avec Bigtable, vous disposez donc d'une solution no-ops,
de l'équilibrage de charge, de la réplication automatique et de tables compactes.
Vous n'avez pas à gérer l'infrastructure,
et vous pouvez traiter des données à un débit très élevé.
Lorsque vous utilisez Bigtable, vous vous servez de l'API HBase.
C'est la raison pour laquelle vous importez org.apache.hadoop.hbase.
Vous procédez comme vous le feriez normalement avec HBase.
Vous établissez une connexion
au niveau de laquelle vous ajoutez l'instruction permettant d'obtenir la table.
Vous créez une opération put, vous ajoutez vos colonnes,
puis vous mettez le tout dans la table.
Et voilà, vous avez ajouté une nouvelle ligne à la table.
Ça fonctionne exactement comme HBase, que vous connaissez peut-être.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
