Module BigData

Module BigData
Overview
Introduction Big Data
L'histoire du Big Data
Qu'est ce que c'est Big Data?
Cas du monde réel
Principes du Big Data
Caractéristiques du Big Data - 4Vs : Volume, Vélocité, Variété, Véracité
Volume
Vélocité
Variété
Véracité
Classification de Big Data
Données structurées
Données non structurées
Données semi-structurées
Différence entre les données structurées, semi-structurées et non structurées
Défis associés au Big Data - 2020
Approche traditionnelle du stockage et du traitement du Big Data
Inconvénients de l'utilisation de l'approche traditionnelle:
Traitement des données - Big data
Accès aux données
Niveau complexités
Rappel de la notion d'index
Modèle NoSQL
Exemple Twitter - Données non structurées et programmation fonctionnelle
BigData et systèmes de fichiers distribués
Mise à l'échelle du système de fichiers distribué (Scaling Distributed File System)
Google File System
 Introduction du Hadoop Distributed File System
Introduction du YARN
Modèle de redondance
États de bloc et de réplique, processus de récupération
Block & replica
Récupération de bloc(Block Recovery)
Récupération de bail(Lease Recovery)
Récupération de Pipeline(Pipeline Recovery)
Client HDFS
Docker
Exemple container
hdfs dfs -help
hdfs dfs -ls
hdfs dfs -du / -df
hdfs dfs -touchz
hdfs dfs -put
hdfs dfs -cat/-tail
hdfs dfs -get/-getmerge
Réglage de la plate-forme de stockage distribué avec les types de fichiers
Texte CSV&TSV
Efficacité spatiale
Vitesse d'encodage et de décodage / Type de données
Divisibilité
Extensibilité
Texte JSON
Efficacité spatiale
Vitesse d'encodage et de décodage / Type de données
Divisibilité
Extensibilité
Formats binaires
Fichier de séquence
Record compression
Block compression
Efficacité spatiale
Vitesse d'encodage et de décodage / Type de données
Divisibilité
Extensibilité
Explorer MapReduce
Composants peu fiables (Unreliable Components)
Échec Fail-stop
Échec Fail-recovery
Échec Byzantine
Perfect Link
Fail-loss Link
Byzantine Link
 Horloge cassée
Systèmes synchrones/Asynchrones
MapReduce
Map
Reduce
MapReduce
Exemple: Trouver les mots les plus populaires sur Wikipedia - Word Count
Programmation avec MapReduce
Hadoop Streaming
Hadoop Streaming - bigdatateam/hdfs-notebook
wc-l (wc (abréviation de word count) est une commande sous Unix)
awk
Hadoop Streaming Python
mapper.py
reducer.py
WordCount in Python
Mapper.py for WordCount
Reducer.py for WordCount
Mapper.py & Reducer.py
Travaux pratiques
TP 01: Les ventes d'un supermarché
Le fichier d'import: supermarket_sales_Module7.csv
Copier des fichiers sur un conteneur Docker
Les containers en run
Copier le fichier
Copier le fichier d'import dans HDFS
mapperTP01.py
reducerTP01.py
Conclusion
TP 02: Calculer maximum et minimum du salaire par profession
Le fichier d'import: salaries_Module7.csv
mapperTP02.py
reducerTP02.py
TP03: Déterminer l'âge moyen des personnes par sexe. dans la catastrophe du Titanic
Le fichier d'import: titanic_data.txt
mapperTP03.py
reducerTP03.py
 1 Overview

Big Data est apparue il y a une quinzaine d'années est aujourd'hui omniprésente. Nous savons plus ou
moins ce qu’elle signifie sans finalement savoir ce que cela provoque comme changements dans nos vies
personnelles et professionnelles. Dans cette module, nous allons commencer par une introduction du
concept Big Data ainsi ses cas d'utilisation.
 2 Introduction Big Data

2.1 L'histoire du Big Data

Le big data a une histoire récente et pour partie cachée, en tant qu'outil des technologies de l'information
et comme espace virtuel prenant une importance volumique croissante dans le cyberespace.

1926 - Nikola Tesla prédit que les humains pourront accéder et analyser d'énormes quantités de
données à l'avenir en utilisant un appareil compatible qui rentre dans les poches.

1937 - L'administration de Franklin D. Roosevelt aux États-Unis a créé le premier grand projet de
données pour suivre la contribution de près de 3 millions d'employeurs et 26 millions d'Américains,
après l'entrée en vigueur de la loi sur la sécurité sociale. IBM a confié le projet massif de tenue de
livres pour développer des machines à lire les cartes perforées.
1997 - L'expression « big data » serait apparue en octobre 1997 selon les archives de la
bibliothèque numérique de l'Association for Computing Machinery (ACM), dans un article
scientifique sur les défis technologiques à relever pour visualiser les « grands ensembles de
données »
1998 - Une base de données relationnelle open source a été développée par Carlo Strozzi qui l'a
baptisée NoSQL. Cependant, 10 ans plus tard, les bases de données NoSQL ont pris de l'ampleur avec
la nécessité de traiter de grands ensembles de données non structurés.

1999 - Le terme Internet des objets (IoT) a été utilisé pour la première fois par Kevin Ashton dans une
présentation commerciale chez P&G.
 2001 - Les dimensions des mégadonnées, c'est-à-dire les 3V, ont été définies par un analyste de
Gartner, Doug Laney, dans un document de recherche intitulé - «Gestion des données 3D: contrôle
du volume, de la vitesse et de la variété des données»
2008 - 9,57 milliards de gigaoctets de données ont été traités par les CPU du monde.
2011 - 1.8 Zettaoctets de données ont été générés de l'aube de la civilisation à l'année 2003. En 2011,
il n'a fallu que 2 jours pour générer 1,8 zettaoctets d'informations.
2015 - Google est la plus grande entreprise de Big Data au monde qui stocke 10 milliards de gigaoctets
de données et traite environ 3,5 milliards de demandes chaque jour.
2020 - Edge computing révisera le rôle du cloud dans des secteurs clés de l'économie.

2.2 Qu'est ce que c'est Big Data?

Le Big Data se réfère essentiellement à un énorme volume de données qui ne peuvent pas être stockées et
traitées en utilisant l'approche traditionnelle dans le délai imparti.

“
Quelle doit être l'énorme quantité de ces données? Afin d'être classé comme Big Data?

Nous utilisons généralement le terme big data pour désigner les données, c'est-à-dire soit en
gigaoctets(GO) ou téraoctets(TO) ou pétaoctets(PO) ou exaoctets(EO) ou tout ce qui est plus grand que cela
en taille. Cela ne définit pas complètement le terme Big Data. Même une petite quantité de données peut
être appelée "Big Data" selon le contexte dans lequel elles sont utilisées.

Exemple01:
Si nous essayons de joindre un document de 100 mégaoctets(MO) à un e-mail, nous
ne serions pas en mesure de le faire. Comme le système de messagerie ne prendrait
pas en charge une pièce jointe de cette taille.

Conséquence: Ces 100 mégaoctets(MO) de pièces jointes en ce qui concerne les e-

mails peuvent être appelés Big Data.

Exemple02:
Disons que nous avons environ 10 téraoctets(TO) de fichiers image, sur lesquels
certains traitements doivent être effectués. Par exemple, nous pouvons vouloir
redimensionner et améliorer ces images dans un délai donné.
Supposons que nous utilisions le système traditionnel pour effectuer cette tâche.
Nous ne serions pas en mesure d'accomplir cette tâche dans le délai imparti.
Comme les ressources informatiques du système traditionnel ne seraient pas
suffisantes pour accomplir cette tâche à temps.

Conséquence: Ces 10 téraoctets(TO) de fichiers image peuvent être appelés Big

Data.
2.3 Cas du monde réel

Requêtes sur Google - 2020

130 000 milliards de pages sont indexées par Google.

20 milliards de sites sont visitées (crawlées) par Google, chaque jour.

80 000 requêtes chaque seconde, soit 6,9 milliards par jour.

15% des requêtes sont de nouvelles requêtes (500 millions par jour) !
Plus de 100 millions de Go de données sont stockées sur les serveurs de Google

Plus de 90% du trafic des recherches en France provient de Google (février 2019)

Vous pouvez simplement imaginer le volume de données stockées et traitées sur ces sites. Mais comme le
nombre d'utilisateurs continue d'augmenter sur ces sites, le stockage et le traitement de ces données
deviennent une tâche difficile.

En utilisant ces informations précieuses, les entreprises peuvent augmenter leurs ventes et générer plus de
revenus.

En utilisant le système informatique traditionnel, nous ne serions pas en mesure d'accomplir cette tâche
dans le délai imparti, car les ressources informatiques du système traditionnel ne seraient pas suffisantes
pour le traitement et le stockage, un énorme volume de données.

C'est là que Hadoop entre en scène, nous discuterons plus en détail de Hadoop dans les sessions
ultérieures.

Nous pouvons donc qualifier cet énorme volume de données de Big Data.
 3 Principes du Big Data

3.1 Caractéristiques du Big Data - 4Vs : Volume, Vélocité, Variété, Véracité

3.1.1 Volume

Se réfère aux vastes quantités de données générées chaque seconde. Si nous prenons tous les données
générées dans le monde entre le début des temps et 2000, le même montant des données seront bientôt
générées toutes les minutes. Les nouveaux outils Big Data utilisent des systèmes distribués afin que nous
pouvons stocker et analyser des données à travers bases de données qui sont disséminées partout dans le
monde.

3.1.2 Vélocité

Se réfère à la vitesse à laquelle les nouvelles données sont générées et la vitesse à laquelle les données se
déplacent autour. Pensez simplement aux messages des réseaux sociaux devenir viral en quelques
secondes. La technologie nous permet maintenant d'analyser les données pendant qu'elles sont générées
(parfois appelé inmemory analytique), sans jamais le mettre en bases de données.

3.1.3 Variété

Se réfère aux différents types de données que nous pouvons maintenant utiliser. Dans le passé, nous nous
concentrions uniquement sur des données structurées qui s'intègrent parfaitement dans des tableaux ou
bases de données relationnelles, telles que les données financières. En fait, 80% des données mondiales ne
sont pas structurées (texte, images, vidéo, voix, etc.) Avec le big data la technologie que nous pouvons
maintenant analyser et apporter ensemble des données de différents types tels que messages,
conversations sur les réseaux sociaux, photos, données de capteur, enregistrements vidéo ou vocaux.

3.1.4 Véracité

Se réfère au désordre ou à la fiabilité de les données. Avec de nombreuses formes de qualité du Big Data et
la précision sont moins contrôlables (pensez à Messages Twitter avec des balises de hachage, des
abréviations, fautes de frappe et discours familier ainsi que fiabilité et précision du contenu) mais la
technologie nous permet maintenant de travailler avec ce type de données.

3.2 Classification de Big Data

3.2.1 Données structurées

Les données structurées sont utilisées pour faire référence aux données qui sont déjà stockées dans des
bases de données, de manière ordonnée. Il représente environ 20% du total des données existantes et est
le plus utilisé dans la programmation et les activités informatiques.
Il existe deux sources de machines de données structurées et les humains. Toutes les données reçues des
capteurs, des blogs et des systèmes financiers sont classées dans les données générées par machine. Il
s'agit notamment des appareils médicaux, des données GPS, des données de statistiques d'utilisation
capturées par les serveurs et les applications et de l'énorme quantité de données qui transitent
généralement par les plateformes de trading, pour n'en nommer que quelques-unes.

Comprenons les données structurées avec un exemple des cotations boursières:

AI.PA - timestamp,open,high,low,close,volume
2019-05-07 11:25:00,115.7,115.8,115.65,115.65,9360
2019-05-07 11:20:00,115.75,115.8,115.65,115.65,12498
2019-05-07 11:15:00,115.85,115.85,115.7,115.75,8886

3.2.2 Données non structurées

Alors que les données structurées résident dans les bases de données traditionnelles à colonnes de lignes,
les données non structurées sont l'inverse - elles n'ont pas de format clair dans le stockage. Le reste des
données créées, environ 80% du total représentent des mégadonnées non structurées. La plupart des
données qu'une personne rencontre appartiennent à cette catégorie - et jusqu'à récemment, il n'y avait pas
grand-chose à faire à part le stocker ou l'analyser manuellement.

Les données non structurées sont également classées en fonction de leur source, générées par machine ou
générées par l'homme. Les données générées par machine représentent toutes les images satellites, les
données scientifiques de diverses expériences et les données radar capturées par diverses facettes de la
technologie.

Les données non structurées générées par l'homme se trouvent en abondance sur Internet, car elles
incluent les données des médias sociaux, les données mobiles et le contenu du site Web. Cela signifie que
les photos que nous téléchargeons sur Facebook ou Instagram, les vidéos que nous regardons sur YouTube
et même les messages texte que nous envoyons contribuent tous au gigantesque tas de données non
structurées.

Des exemples de données non structurées incluent le texte, la vidéo, l'audio, l'activité mobile, l'activité des
médias sociaux, l'imagerie satellite, l'imagerie de surveillance - la liste s'allonge encore et encore.

Voici un exemple :

Un fichier d'image peut être considéré comme donnée non structurée

Les données non structurées sont en outre divisées en:

Données capturées: Ce sont les données basées sur le comportement de l'utilisateur. Le meilleur
exemple pour le comprendre est le GPS via les smartphones qui aident l'utilisateur à chaque instant
 et fournit une sortie en temps réel.

Données générées par l'utilisateur: C'est le genre de données non structurées où l'utilisateur lui-
même mettra des données sur Internet à chaque mouvement. Par exemple, Tweets et Re-tweets,

Likes, Partages, Commentaires, sur Youtube, Facebook, etc.

3.2.3 Données semi-structurées

La ligne entre les données non structurées et les données semi-structurées a toujours été floue car la
plupart des données semi-structurées semblent être non structurées en un coup d'œil. Les informations qui
ne sont pas dans le format de base de données traditionnel en tant que données structurées, mais qui
contiennent certaines propriétés organisationnelles qui facilitent le traitement, sont incluses dans les
données semi-structurées. Par exemple, les documents NoSQL sont considérés comme semi-structurés, car
ils contiennent des mots clés qui peuvent être utilisés pour traiter facilement le document.

L'analyse du Big Data a une valeur commerciale certaine, car son analyse et son traitement peuvent aider
une entreprise à réaliser des réductions de coûts et une croissance spectaculaire. Il est donc impératif de
ne pas attendre trop longtemps pour exploiter le potentiel de cette excellente opportunité commerciale.

Un fichier json:

{
"fruits": [
{ "kiwis": 3,
"mangues": 4,
"pommes": null
},
{ "panier": true }
],
"legumes": {
"patates": "amandine",
"poireaux": false
},
"viandes": ["poisson","poulet","boeuf"]
}

3.2.4 Différence entre les données structurées, semi-structurées et non structurées

 Données Données non
Facteurs Données semi-structurées
structurées structurées

Il est plus flexible que les données Il est de nature

Il est dépendant
Flexibilité structurées mais moins flexible que flexible et il n'y a
et moins flexible
les données non structurées pas de schéma

Transaction La transaction est adaptée à partir Aucune gestion des

Gestion des échue et diverses d'un SGBD(système de gestion de transactions et
transactions techniques de base de données) non arrivé à aucune
concurrence échéance concurrence

La requête
structurée Une seule requête
Performances Des requêtes sur des nœuds
permet une textuelle est
des requêtes anonymes sont possibles
jointure possible
complexe

Il est basé sur la Ceci est basé sur

table de base de les données de
Technologie Il est basé sur RDF et XML
données caractère et de
relationnelle bibliothèque

3.3 Défis associés au Big Data - 2020

Voici les 5 défis majeurs du Big Data auxquels les entreprises seront confrontées en 2020:

1. Le besoin de professionnels plus qualifiés

La recherche montre que depuis 2018, 2,5 quintillions d'octets (ou 2,5 exaoctets) d'informations
sont générées chaque jour. Au cours des deux dernières années, la quantité de flux, de publications,
de recherches et d'écrits a considérablement augmenté, ce qui a produit une énorme quantité de
données. De plus, ce nombre ne fait qu'augmenter de jour en jour. Une étude a prédit que d'ici
2025, chaque personne produira 463 exaoctets d'informations ahurissants chaque jour.

Un rapport de Indeed(Indeed est un moteur de recherche américain pour les offres d'emploi lancé
dans le monde entier en novembre 2004.) a montré une augmentation de 29% de la demande
annuelle de scientifiques des données et une augmentation de 344% depuis 2013 jusqu'à ce jour.
Cependant, les recherches des demandeurs d'emploi qualifiés en science des données continuent
de croître à un rythme d'escargot de 14%. En août 2018, LinkedIn a déclaré que les États-Unis
avaient à eux seuls besoin de 151717 professionnels possédant des compétences en science des
données. Ceci, ainsi qu'un écart de 15% entre les offres d'emploi et les recherches d'emploi sur
Indeed, montre clairement que la demande de scientifiques des données dépasse l'offre. Le plus
grand défi du traitement des données en 2020 est le manque de scientifiques des données qualifiés
possédant les compétences et l'expertise nécessaires pour gérer ce gigantesque volume de
données.

2. Incapacité à traiter de gros volumes de données

 Sur les 2,5 quintillions de données produites, seulement 60% des travailleurs y consacrent des jours
pour en comprendre le sens. Une grande partie des données brutes n'est généralement pas
pertinente. Et environ 43% des entreprises éprouvent toujours des difficultés ou ne sont pas
entièrement satisfaites des données filtrées.

3. Synchronisation entre les sources de données

Une fois que vous importez des données dans des plates-formes Big Data, vous pouvez également
vous rendre compte que les copies de données migrées à partir d'un large éventail de sources à
différents taux et horaires peuvent rapidement sortir de la synchronisation avec le système
d'origine. Cela implique deux choses, premièrement, les données provenant d'une source sont
obsolètes par rapport à une autre source. Deuxièmement, il crée une communauté de définitions de
données, de concepts, de métadonnées et similaires. La gestion des données et les entrepôts de
données traditionnels, ainsi que la séquence de transformation, d'extraction et de migration des
données, entraînent tous une situation dans laquelle les données risquent de ne pas être
synchronisées.

4. Absence de gouvernance adéquate des données

Les données collectées à partir de sources multiples devraient avoir une certaine corrélation entre
elles afin qu'elles puissent être considérées comme utilisables par les entreprises. Dans une récente
enquête sur la maturité des Big Data, le manque de gouvernance stricte des données a été reconnu
comme le domaine de préoccupation connaissant la croissance la plus rapide. Les organisations
doivent souvent mettre en place le personnel, les politiques et la technologie appropriés pour
garantir la gouvernance des données. Cela pourrait être un défi pour de nombreuses entreprises.

5. Menace de sécurité des données compromise

Bien que le Big Data ouvre de nombreuses opportunités aux entreprises pour développer leurs
activités, il existe un risque inhérent à la sécurité des données. Certaines des plus grandes
cybermenaces contre de grands acteurs comme Panera Bread, Facebook, Equifax et Marriot ont mis
en évidence le fait que personne n'est à l'abri des cyberattaques. En ce qui concerne le Big Data, la
sécurité des données devrait être prioritaire car la plupart des entreprises modernes sont
vulnérables à la génération de fausses données, surtout si les cybercriminels ont accès à la base de
données d'une entreprise. Cependant, la régulation de l'accès est l'un des principaux défis pour les
entreprises qui travaillent fréquemment avec de grands ensembles de données. Même la
conception du Big Data complique la tâche des entreprises pour garantir la sécurité des données.
Travailler avec des données réparties sur plusieurs systèmes les rend à la fois lourdes et risquées.

3.4 Approche traditionnelle du stockage et du traitement du Big Data

 1. Les données générées par les organisations, les institutions financières telles que les banques ou les
marchés boursiers et les hôpitaux sont généralement fournies en tant qu'intrants au système
ETL(Extract, Transform and Load).
2. Le système ETL extrait ensuite les données et convertit les données dans un format approprié. Ces
données sont ensuite chargées dans la base de données.
3. Les utilisateurs finaux peuvent générer des rapports et effectuer des analyses en acquérant ces
données.
4. À mesure que les données augmentent, il devient difficile de les gérer et de les traiter selon l'approche
traditionnelle. Il s'agit d'un inconvénient fondamental de l'utilisation de l'approche traditionnelle.

3.4.1 Inconvénients de l'utilisation de l'approche traditionnelle:

Cher - C'est un système coûteux. Cela nécessite beaucoup d'investissement pour mettre en œuvre ou

mettre à niveau le système. Ainsi, il est généralement utilisé par les grandes entreprises.

Évolutivité - À mesure que les données augmentent, l'expansion du système devient une tâche

difficile.
Temps de traitement - Il faut beaucoup de temps pour extraire et traiter des informations précieuses

de ces données.
 4 Traitement des données - Big data

Les données sont souvent considérées comme le nouveau pétrole - ce carburant qui alimente nos
industries. Mais les données ont plusieurs avantages par rapport au pétrole : elles sont bon marché, faciles
à transporter, durables et réutilisables à l’infini. Les données ont également beaucoup plus de cas d’usage
et leur rentabilité explique pourquoi la valeur boursière d'Uber est supérieure à celle des constructeurs
automobiles traditionnels et pourquoi Airbnb a plus de clients chaque mois que Hyatt.

Cependant, ces données ont besoin d'être raffinées - tout comme le pétrole. Que ces données soient
personnelles, transactionnelles, issues du web et de capteurs, le déploiement de traitement Big Data a
souvent été difficile, même pour les ordinateurs. Les entreprises devaient auparavant prélever un
échantillon représentatif des données pour les analyser, mais ce processus a changé avec l'évolution des
outils analytiques Big Data.

4.1 Accès aux données

Exemple01: Vous avez un dictionnaire Larousse à disposition, est-il facile de :

Trouver le premier mot de la page 153 ?
Conséquence: Facile

Exemple02: Vous avez un dictionnaire Larousse à disposition, est-il facile de :

Trouver le premier mot de la page 153 ?
Trouver la d´efinition de ziggourat ?
Conséquence: Moyen

Exemple03: Vous avez un dictionnaire Larousse à disposition, est-il facile de :

Trouver le premier mot de la page 153 ?
Trouver la d´efinition de ziggourat ?
Trouver le mot dont la définition est “Se dit d’une corollegamop étale en
forme d’entonnoir (fleur de liseron).”?

Conséquence: Difficile, dictionnaire inversé?

4.1.1 Niveau complexités

Accès séquentiel: O( 1 )

vous avez le numéro de la page d'un dictionnaire, vous y aller

Accès par recherche binaire/arbre binaire: O( log(n) )

vous cherchez le mot par rapport à l’ordre alphabétique

Accès par lecture complète ou partielle: O( n )

 vous lisez tout le dictionnaire à la recherche de votre définition

4.1.2 Rappel de la notion d'index

Un index est une structure de donnée (souvent un arbre de recherche binaire) permettant un acces en
log(n) pour un ou plusieurs champs.

Un index peut avoir plusieurs niveaux de clé (si la première clé est dupliquée). Par exemple pour des
personnes, vous pouvez avoir un index uniquement sur les noms, ou un index sur les noms et prénoms. Si
vous avez un index sur les noms et que vous recherchez “Jacques Martin”, vous allez devoir regarder toutes
les personnes dont le nom est “Martin”. Si vous avez un index sur les noms et prénoms, vous ne regarderez
que les personnes s’appelant “Jacques Martin”.

4.2 Modèle NoSQL

La majeure partie des bases de données actuelles (PostGres, MySql, Oracle, SQL Server, db2, MariaDB, etc .
. . ) sont des bases de données relationnelles & transactionnelles “classiques”. Elles assurent la cohérence
des données selon les principes definies par l’acronyme ACID. Ces principes impliquent des m´ecanismes
assez coûteux, notamment les “undo-segment”.

Pour en revenir à notre dictionnaire:

Est-ce une bonne idée de mettre un index sur un les définitions ?

Par exemple “Se dit d’une corolle gamopétale en forme d’entonnoir (fleur de liseron).” ?

Probablement pas, éventuellement sur les mots/notions de l’index

Nous allons comprendre le modèle en comparant avec le modèle SQL:

SQL :

Notion d’index

Ne scale pas pour la parallélisation d’un grande nombre de recherches sur des données modifiées en

permanence (mais à une moindre fréquence) (Cohérences des données, ACID)

Traduction d’une base de documents en un schéma relationnel parfois complexe lorsque les
documents ont une structure arborescente (plein de tables)

Récupérer un document entier nécessite plein de lookups

NoSQL

Clé/valeur –> simple et recherche très simple

Valeur = donnée simple comme document complexe

Recherche rapide sur les clés

Lente sur la plupart du reste

Efficace lorsqu’on veut récupérer la totalité d’un document

Structure relationnel VS Acces hierarchique

 Les structures relationnels classiques ne permettent pas de stocker des données éthérogènes dans

une seule table

Ce qui supposent de les répartir sur plusieurs tables, et donc de faire plusieurs accès.

Avec une structure hiérarchique, une fois que vous avez accédé à votre enregistrement, vous pouvez

accéder à toutes les données

Reprenons notre fichier Json pour vous illustrer un exemple du modèle NoSQL:

{
"fruits": [
{ "kiwis": 3,
"mangues": 4,
"pommes": null
},
{ "panier": true }
],
"legumes": {
"patates": "amandine",
"poireaux": false
},
"viandes": ["poisson","poulet","boeuf"]
}

4.3 Exemple Twitter - Données non structurées et programmation

fonctionnelle

Fichier Jupyter Notebook: Module BigData Twitter.ipynb

“
Calculs de moyennes et autres statistiques sur une base twitter au format JSON avec de la
programmation fonctionnelle (module cytoolz ).

twitter_for_network_100000: Un fichier de base de données qui contient 100000 twteets

import numpy as np

def my_sum(l):
res = 0
for it in l:
res += it
return res
l = list(range(100000))
a = np.arange(100000)

print("User defined method or cross-method")

%timeit my_sum(a) # user defined with numpy array
%timeit sum(a) # built-in with numpy array
%timeit np.sum(l) # numpy function with list
%timeit my_sum(l) # user definedwith list
print("Builtin function")
%timeit sum(l) # built-in with list
print("Numpy function")
%timeit np.sum(a) # numpy function
%timeit a.sum() # numpy method

User defined method or cross-method

c:\users\mayn\appdata\local\programs\python\python36\lib\site-
packages\ipykernel_launcher.py:6: RuntimeWarning: overflow encountered in
long_scalars

14.6 ms ± 87 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
c:\users\mayn\appdata\local\programs\python\python36\lib\site-
packages\ipykernel_launcher.py:1: RuntimeWarning: overflow encountered in
long_scalars
"""Entry point for launching an IPython kernel.
11 ms ± 78 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
4.88 ms ± 246 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
3.08 ms ± 12.8 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
Builtin function
1.07 ms ± 9.83 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
Numpy function
39.1 µs ± 252 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
42.5 µs ± 8.35 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
 5 BigData et systèmes de fichiers distribués

Dans ce cours, nous parlerons du Big Data. Du point de vue pratique, nous nous concentrerons sur deux
compétences. La couche de stockage et les paradigmes et technologies de traitement des données.

5.1 Mise à l'échelle du système de fichiers distribué (Scaling Distributed File

System)

Le sujet de cette section est les systèmes de fichiers distribués.

Tout d'abord, laissez-nous comprendre pourquoi vous en avez besoin et quelle est l'alternative. Lorsque
vous avez de nos jours beaucoup de données parfois utiles générées en quantités énormes, vous devriez
les stocker quelque part. Il existe deux options. Le premier est d'obtenir un nœud de grande capacité. Le
second est de stocker nos données sur une collection de nœuds.

La première approche est appelée mise à l'échelle ou mise à l'échelle verticale(vertical scaling). Si vous
souhaitez stocker plus de données, procurez-vous un meilleur disque dur, bien sûr plus grand.

Par exemple, Facebook avait un stockage de 300 pétaoctets de données en 2014. Savez-vous où acheter un
disque dur de 300 pétaoctets? Il existe un autre projet appelé Scale Out ou Horizontal Scale In. Besoin de
stocker plus de données? Obtenez plus des produits de base. Cela semble assez simple, mais en réalité, ce
n'est pas le cas.
Un nœud sera mis hors service dans trois ans en moyenne. Ainsi, avec un cluster de 1000 nœuds, vous
obtiendrez un pilier chaque jour, environ. Naturellement, vous souhaitez stocker vos données de manière
fiable. C'est là que se trouve la pierre d'achoppement du système de fichiers distribué. Chaque approche
de mise à l'échelle a ses avantages et ses inconvénients. En accédant aux données, vous obtenez
généralement une latence plus faible avec une mise à l'échelle verticale. Vous obtenez une latence plus
élevée avec une échelle horizontale, mais vous pouvez créer un stockage plus important d'un service de
base, et c'est exactement l'approche que vous aurez à traiter pendant nos cours.

5.1.1 Google File System

L'ère des systèmes de fichiers distribués a commencé au début des années 60. Les employés de Google ont
publié l'article sur Google File System en 2003, qui a été largement adopté au sein d'une société de
moteurs de recherche géante. Il s'agit d'un système de fichiers distribué évolutif avec un bon niveau de
tolérance totale fonctionnant sur du matériel de base peu coûteux.

Quelles sont les idées clés de Google File System? https://research.google/pubs/pub51/

Premièrement, les pannes de composants sont une norme plutôt qu'une exception. Pour cette raison,
toutes les données du magasin sont dupliquées ou, plus techniquement, répliquées.

Deuxièmement, il existe des fichiers petits et énormes. Néanmoins, vous souhaitez avoir une répartition
égale de l'utilisation de l'espace sur différentes machines. C'est pourquoi tous les fichiers sont divisés en
blocs de taille fixe, environ 100 mégaoctets. Troisièmement, vous utilisez l'écriture une fois, lisez de
nombreux modèles d'utilisation des données. C'est pourquoi il n'est pas permis de modifier les fichiers au
milieu, car cela simplifie considérablement l'API et la mise en œuvre interne d'un système de fichiers
distribué.

Cette diapositive clarifie visuellement les deux premiers points clés. Vous avez plusieurs fichiers, petits
comme S.txt et gros, B.txt. Ils sont tous deux divisés en blocs de taille égale, puis répartis sur une machine
différente, avec des réplications. Les machines de stockage sont appelées serveurs de canaux ou nœuds de
données. (channel servers, or data nodes.)
5.1.2 Introduction du Hadoop Distributed File System

Dans le système de fichiers distribué, avec un système de fichiers local, vous devriez également avoir des
métadonnées. Les métadonnées comprennent des informations administratives sur l'heure de création, les
propriétés d'accès, etc. Pour demander ces métadonnées avec une latence minimale, vous avez besoin
d'un nœud maître(master node), qui stocke toutes les métadonnées en mémoire. Hadoop Distributed File
System, ou HDFS en abrégé, est une implémentation open source de Google File System. Comme vous
pouvez le voir sur cette diapositive, il n'y a que de légers changements de dénomination. Par exemple, le
nœud maître dans HDFS est appelé namenode. Du point de vue de la mise en œuvre, le système de fichiers
Google est écrit en C ++, tandis que HDFS est écrit en Java.
Le client HDFS fournit une interface de ligne de commande pour communiquer avec ce système de fichiers
distribué. Il n'est donc pas nécessaire d'écrire du code dans les langages de programme pour accéder aux
données. En plus du protocole binaire RPC, il existe une option pour accéder aux données via le protocole
HTTP, qui est indépendant du langage de programmation.

Voyons comment lire des fichiers à partir de HDFS. Tout d'abord, vous demandez au nœud de nom
d'obtenir des informations sur les emplacements des blocs de fichiers. Ces blocs sont répartis sur
différentes machines, mais toute cette complexité est cachée derrière l'API HDFS.
L'utilisateur ne voit qu'un flux continu de données. Par exemple, si à un moment donné un datanode dont
vous récupérez des données est mort, vous obtenez ces données d'un autre réplica sans déranger les
utilisateurs à ce sujet. Pratique, non? De plus, vous obtiendrez des données de la machine la plus proche.
Le sens de la proximité, en réalité, est difficile à mesurer. Parce que cela dépend de la distance physique et
de la charge système imprévisible telle que la surutilisation des métriques. Pour cette raison, il s'agit de la
topologie du centre de données.

Si vous demandez des données à HDFS et que ces données sont disponibles sur la même machine, vous
pouvez utiliser la localité des données pour lire les données directement à partir du disque dur sans aucun
code RPC supplémentaire. La distance est donc nulle.

Si un datanode se trouve dans le même rack, la distance est de deux. si vous allez lire des données à partir
d'un autre rack, la distance est égale à quatre.

Si les données sont allouées dans un autre centre de données, vous obtiendrez une surcharge de livraison.
Dans ce cas, la distance est de 6. Ces mathématiques internes sont utilisées pour définir la signification de
la proximité. Sinon, voyons ce qui se passe lorsque vous essayez d'écrire un fichier dans HDFS.

5.1.3 Introduction du YARN

Apache Yarn – “Yet Another Resource Negotiator” est la couche de gestion des ressources de Hadoop. Le fil
a été introduit dans Hadoop 2.x. Yarn permet à différents moteurs de traitement de données comme le
traitement graphique, le traitement interactif, le traitement de flux ainsi que le traitement par lots
d'exécuter et de traiter des données stockées dans HDFS (Hadoop Distributed File System). Outre la gestion
des ressources, Yarn effectue également la planification des travaux. Yarn étend la puissance de Hadoop à
d'autres technologies en évolution, afin qu'ils puissent tirer parti des avantages du HDFS (le système de
stockage le plus fiable et le plus populaire de la planète) et du cluster économique. Pour apprendre
l'installation d'Apache Hadoop 2 avec Yarn, suivez ce guide d'installation rapide.
5.1.4 Modèle de redondance

Lorsque vous écrivez un bloc de données dans HDFS, Hadoop distribue des répliques sur le stockage. Le
premier réplica est généralement situé sur le même nœud si vous écrivez des données à partir d'une
machine DataNode. Sinon, le premier DataNode à placer le réplica est choisi au hasard.

La deuxième réplique est généralement placée dans un autre rack. Vous constatez que si ces racks tombent
en panne, par exemple à cause de problèmes d'alimentation, vous pourrez toujours accéder aux données
d'un autre rack.

La troisième réplique est située sur une machine différente dans le même rack que la deuxième réplique.
Vous ne payez pas de supplément entre l'utilisation du réseau en rack car la troisième réplique est copiée à
partir du deuxième nœud de données.

D'autres répliques s'appliquent aux nœuds aléatoires du cluster bien que le système essaie d'éviter de
placer trop de répliques sur le même rack.

“
Exemple 5.1.3 - 1
 Dans cet exemple , vous pouvez voir le flux de données détaillé d'une apparition droite. Tout
d'abord, la demande du client HDFS et le nom du nœud via le protocole RPC. Le nœud de nom valide
si vous avez le droit de créer un fichier et qu'il n'y a pas de conflit de nom. Après cela, le client HDFS
demande une liste de datanodes pour mettre une fraction de blocs du fichier. Ces datanodes forment
un pipeline lorsque votre premier client envoie des paquets de données au datanode le plus proche.
Le dernier transfère des copies de paquets via un pipeline de datanode. Dès que le paquet est
[INAUDIBLE] sur tous les datanodes, les datanodes renvoient des paquets d'accusé de réception.

Si quelque chose ne va pas, alors si le client ferme le pipeline de datanode, marque le mauvais
datanode comme mauvais et demande un remplacement pour les mauvais datanodes d'un nœud de
nom. Ainsi, un nouveau pipeline de nœuds de données sera organisé et le processus d'écriture du
fichier sur HDFS se poursuivra. Encore une fois, tout cela se produit de manière transparente pour un
utilisateur. HDFS cache toute cette complexité pour vous.

5.2 États de bloc et de réplique, processus de récupération

5.2.1 Block & replica

Le réplica est un stockage de données physique sur un nœud de données. Il existe généralement plusieurs
répliques avec le même contenu sur différents nœuds de données.

Block(Bloc) est un stockage de méta-informations sur un nœud de nom et fournit des informations sur les
emplacements des répliques et leurs états.

La réplique et le bloc ont leurs propres états. Il existe les états suivants du réplica de nœud de données. Si
la réplique est dans un état finalisé, cela signifie que le contenu de cette réplique est cool et glacé.
Techniquement parlant, c'est gelé. Ce dernier signifie que les méta-informations pour ce bloc sur le nœud
de nom sont alignées avec tous les états et données de la réplique correspondante. Par exemple, vous
pouvez lire en toute sécurité les données de n'importe quel nœud de données et vous obtiendrez
exactement le même contenu. Cette propriété préserve la cohérence de lecture. Chaque bloc de données a
un numéro de version appelé Generation Stamp ou GS en abrégé. Pour les répliques finalisées, vous avez la
garantie qu'elles ont toutes le même numéro GS qui ne peut qu'augmenter avec le temps. Cela se produit
pendant le processus de récupération d'erreur ou pendant l'ajout de données à un bloc.

State RBW signifie Replica being Written to. C'est l'état du dernier bloc d'un fichier ouvert ou d'un fichier
qui a été rouvert pour l'ajout. Pendant cet état, différents nœuds de données peuvent revenir pour utiliser
un ensemble d'octets différent. En bref, les octets reconnus par les nœuds de données en aval dans un
pipeline sont visibles pour un lecteur de cette réplique. De plus, le nœud de données sur les données du
disque et les méta-informations du nœud de nom peuvent ne pas correspondre pendant cet état. En cas de
défaillance, le nœud de données essaiera de conserver autant d'octets que possible. C'est un objectif de
conception appelé durabilité des données.
Réplique en attente de récupération(Replica Waiting to be Recovered) ou RWR pour faire court, est un état
de toutes les répliques en cours d'écriture après la panne et la récupération du nœud de données. Par
exemple, après un redémarrage du système ou après Pacer.sys ou BSOD, ce qui est très probable du point
de vue de la programmation. Les répliques RWR ne seront dans aucun pipeline de nœuds de données et ne
recevront donc aucun nouveau paquet de données. Donc, soit ils deviennent obsolètes et doivent être
supprimés, soit ils participeront à un processus de récupération spécial appelé récupération de bail si le
client décède également. Le client HDFS demande un bail à un nœud de nom pour avoir un accès exclusif
pour écrire ou ajouter des données à un fichier. En cas d'expiration du bail du client HDFS, la réplique
passe à un état RUR.

RUR signifie Replica Under Recovery. L'expiration du bail se produit généralement lors de la défaillance du
site du client. À mesure que les données augmentent et que différents nœuds sont ajoutés ou supprimés
d'un cluster, les données peuvent devenir inégalement réparties sur les nœuds du cluster. Un
administrateur Hadoop peut engendrer un processus de rééquilibrage des données ou un ingénieur de
données peut demander l'augmentation du facteur de réplication des données dans un souci de durabilité.
Dans ces cas, les nouvelles répliques générées seront dans un état appelé temporaire. C'est à peu près le
même état que RBW sauf le fait que ces données ne sont pas visibles pour l'utilisateur tant qu'elles ne sont
pas finalisées. En cas d'échec, l'ensemble des données est supprimé sans aucun état de récupération
intermédiaire.
En plus de la table de transition de réplique, un bloc de noeud de nom possède sa propre collection d'états
et de transitions.

Différent des états de réplique de nœuds de données, un état de bloc est stocké en mémoire, il ne persiste
sur aucun disque. Dès qu'un utilisateur ouvre un fichier pour l'écriture, le nœud de nom crée le bloc
correspondant avec l'état under_construction. Lorsqu'un utilisateur ouvre un fichier pour ajouter le nom du
nœud, faites également passer ce bloc à l'état under_construction. C'est toujours le dernier bloc d'un
fichier, sa longueur et le timbre de génération sont mutables. Le bloc de nœud de nom garde la trace du
bon pipeline. Cela signifie qu'il contient des informations sur toutes les répliques RBW et RWR. Il est assez
vindicatif et surveille chaque pas. Les répliques passent de l'état RWR à l'état RUR de récupération lorsque
le client meurt. De manière encore plus générale, cela se produit lorsque le bail d'un client expire. Par
conséquent, le bloc correspondant passe de l'état under_construction à under_recovery. Le bloc
under_construction passe à un état engagé lorsqu'un client demande avec succès au nœud de nom de
fermer un fichier ou de créer un nouveau bloc de données consécutif. L'état validé signifie qu'il existe déjà
des répliques finalisées mais pas toutes. Pour cette raison, pour répondre à une demande de lecture, le
bloc validé doit garder une trace des répliques RBW, jusqu'à ce que toutes les répliques soient passées à
l'état finalisé et que le client HDFS puisse fermer le fichier. Il doit réessayer ses demandes. L'état final
complet d'un bloc est un état dans lequel toutes les répliques sont dans l'état finalisé et ont donc une
longueur visible et des tampons de génération identiques. Ce n'est que lorsque tous les blocs d'un fichier
sont complets que le fichier peut être fermé. En cas de redémarrage du nœud de nom, il doit restaurer
l'état du fichier ouvert. Tous les blocs du fichier non fermé sont chargés comme complets à l'exception du
dernier bloc qui est chargé comme under_construction. Ensuite, les procédures de récupération
commenceront à fonctionner.

Il en existe plusieurs types, la récupération de réplica, la récupération de bloc, la récupération de bail et la

récupération de pipeline.

5.2.2 Récupération de bloc(Block Recovery)

Pendant le processus de récupération de bloc, NameNode doit s'assurer que toutes les répliques
correspondantes d'un bloc passeront à un état commun logiquement et physiquement. Par physiquement,
je veux dire que toutes les répliques correspondantes doivent avoir le même contenu sur le disque. Pour ce
faire, NameNode choisit un datanode principal appelé PD dans un document de conception. De toute
évidence, PD doit contenir une réplique pour le bloc cible. Demande PD d'un NameNode, un tampon de
nouvelle génération, des informations et l'emplacement d'autres répliques pour le processus de
récupération.
Contexte PD chaque DataNodes pertinents pour participer au processus de récupération de réplique. Le
processus de restauration de réplique inclut l'abandon des clients actifs directement dans une réplique.
Abandon de la réplique précédente du processus de récupération de bloc et participation au processus
d'accord de taille de réplique final. Au cours de cette phase, toutes les informations ou données nécessaires
sont propagées dans le pipeline.

À la dernière étape, PD informe NameNode du résultat, du succès ou de l'échec. En cas d'échec, NameNode
pourrait réessayer le processus de récupération de bloc.

5.2.3 Récupération de bail(Lease Recovery)

Le processus de récupération de bloc ne pouvait avoir lieu que dans le cadre du processus de récupération
de bail. Le gestionnaire de location gère tous les baux au NameNode. Les clients HDFS demandent au
moins à chaque fois qu'ils souhaitent écrire ou ajouter à un fichier. Le gestionnaire de location maintient
une limite souple et une limite ferme. Si un titulaire de bail actuel ne renouvelle pas son bail pendant le
délai d'expiration de la limite souple, un autre client pourra reprendre ce bail. Dans ce cas et dans ce cas où
l'on atteint une limite stricte, le processus de recouvrement du bail commencera.

Ce processus est nécessaire pour fermer les fichiers ouverts dans l'intérêt du client. Au cours de ce
processus, plusieurs garanties doivent être obtenues.

Le premier est le contrôle d'accès concurrentiel. Même si un client est toujours en vie, il ne pourra pas
écrire de données dans un fichier. Le second est la garantie de cohérence. Tous les réplicas doivent revenir
à un état de cohérence pour avoir les mêmes données sur disque et le même tampon de génération.

Le recouvrement du bail commence par un renouvellement de bail. Bien sûr, les nouveaux titulaires de bail
devraient avoir un super pouvoir, ce super pouvoir inclut la capacité de s'approprier le bail de tout autre
utilisateur. Dans notre cas, le nom du super utilisateur est DFS. Par conséquent, toutes les autres demandes
de client telles que l'obtention d'un tampon de nouvelle génération, l'obtention d'un nouveau bloc, la
fermeture d'un fichier d'autres clients à cette passe seront rejetées.

NameNode obtient la liste des DataNodes qui contient le dernier bloc d'un fichier. Et envoie un DataNode
principal et démarre un processus de récupération de bloc. Dès que le processus de récupération de bloc
se termine, le NameNode est notifié par PD du résultat. Met à jour le blocage pour et supprime la liste d'un
fichier.
5.2.4 Récupération de Pipeline(Pipeline Recovery)

Lorsque vous écrivez dans un fichier HDFS, le client HDFS écrit les données bloc par bloc. Chaque bloc est
construit via un bon pipeline, car le premier client décompose le bloc en morceaux appelés paquets. Ces
paquets sont propagés aux DataNodes via le pipeline. Comme l'illustre dans l'image au dessous, il y a
toujours trois étapes. Configuration du pipeline, diffusion des données et fermeture. Les lignes en gras sur
cette image représentent les paquets de données, les lignes pointillées représentent les messages d'accusé
de réception, les lignes régulières sont utilisées pour représenter les messages de contrôle. Au cours de la
phase de configuration du pipeline, un client envoie un message de configuration au pipeline. Chaque
DataNode ouvre une réplique pour l'écriture et renvoie un message d'accusé de réception en amont avec le
pipeline.

L'étape de transmission de données est définie par la plage de temps de t1 à t2, où t1 est l'heure à laquelle
un client reçoit le message d'accusé de réception pour l'étage supérieur. Et t2 est le moment où le client
reçoit le message d'accusé de réception pour tous les paquets de bloc.

Au cours de la phase de diffusion des données, les données sont mises en mémoire tampon sur le site
client pour former un paquet, puis propagées via le pipeline DataNode. Le paquet suivant peut être envoyé
avant même que l'accusé de réception du paquet précédent ne soit reçu. À propos, comme vous pouvez le
voir dans l'image au dessous, il existe des paquets de données spécifiques appelés flush. Ce sont des
paquets synchrones et utilisés comme points de synchronisation pour le droit DataNode. La dernière étape
est proche, qui est utilisée pour finaliser les répliques et arrêter le pipeline. Tous les DataNodes du pipeline
modifient l'état du réplica en finalisé. Signalez l'état à un NameNode et envoyez le message d'accusé de
réception en amont. Dans le cas des niveaux DataNode, la récupération du pipeline peut être lancée au
cours de chacune de ces étapes.
Si vous écrivez dans un nouveau fichier et qu'un échec se produit au cours de cette étape supérieure, vous
pouvez facilement abandonner le pipeline DataNode et en demander un nouveau à partir de zéro. Si
DataNode n'est pas en mesure de continuer à traiter les paquets de manière appropriée, par exemple à
cause de ces problèmes, il attribue le pipeline DataNode à ce sujet, en fermant toutes les connexions.
Lorsque le client HDFS détecte un incendie, il arrête d'envoyer de nouveaux paquets au pipeline existant,
demande un tampon de nouvelle génération à un NameNode et reconstruit un pipeline à partir de bons
DataNodes. Dans ce cas, certains paquets peuvent être renvoyés mais ils ne constitueront pas une
surcharge d'E / S disque supplémentaire pour les DataNodes qui ont déjà enregistré ce paquet sur le
disque. Tous les DataNodes vérifient les octets reçus, les octets écrits sur un disque et les octets reconnus.
Une fois que le client détecte une panne lors de la phase de fermeture, il reconstruit un pipeline avec de
bons DataNodes. Renforce le tampon de génération et les demandes de finalisation des répliques.
5.3 Client HDFS

5.3.1 Docker

Docker Engine est le moteur d’exécution de conteneur de facto de l’industrie qui

s’exécute sur divers systèmes d’exploitation Linux (CentOS, Debian, Fedora, Oracle Linux, RHEL, SUSE et
Ubuntu) et Windows Server. Docker crée des outils simples et une approche de packaging universelle qui
regroupe toutes les dépendances d'application dans un conteneur qui est ensuite exécuté sur Docker
Engine. Docker Engine permet aux applications conteneurisées de s'exécuter partout et de manière
cohérente sur n'importe quelle infrastructure, résolvant «l'enfer des dépendances» pour les développeurs
et les équipes d'exploitation, et éliminant le «cela fonctionne sur mon ordinateur portable!» problème.

Nous allons donc installer Docker pour la suite de ce chapitre:

La configuration minimale requise pour exécuter des notebooks sur votre ordinateur est:

Processeur 2 cœurs

4 Go de RAM

20 Go d'espace disque libre

Les exigences recommandées sont:

Processeur 4 cœurs

8 Go de RAM

50 Go d'espace disque libre

1. Aller sur le site officiel du Docker https://www.docker.com/

2. Cliquer sur Get Started

3. Télécharger Docker Desktop

4. Installer Docker
 5. Exécuter docker desktop

5.3.2 Exemple container

L'équipe Big Data a préparé vos conteneurs à jouer avec HDFS en

téléchargeant des conteneurs Docker localement. Vous pouvez copier coller le code suivant pour
télécharger le conteneur via cmd:

“
Attention:

La taille de cette image est environs 4,7 GB. Veuillez vous assurez d'abord que vous avez assez
d'espace dans vos disques dur avant de lancer la commande .
 docker pull bigdatateam/hdfs-notebook

Une fois installé, exécutez

docker run --rm -it -p <your_port>:8888 <container_name>

//Dans notre cas

docker run --rm -it -p 8888:8888 bigdatateam/hdfs-notebook

Dans votre client docker, vous pouvez donc voir l'image qu'on vient de télécharger est le conteneur est en
RUN:

Ouvrir le conteneur dans votre browser ainsi d'ouvrir le Demo.ipynb pour la suite de ce chapitre, Ceci est
un environnement pour votre pratique avec HDFS. Vous pouvez vous entraîner avec différentes
commandes shell HDFS.:
À partir de la section précédente, vous avez acquis des connaissances théoriques sur le système de fichiers
distribué Hadoop. À l'heure actuelle, il est grand temps de s'entraîner. Au cours de cette section , nous
allons vous montrer comment utiliser le client HDFS. Permettez-moi de comparer deux systèmes de
fichiers. L'API LocalFileSystem et l'API DistributedFileSystem.

5.3.3 hdfs dfs -help

Si vous souhaitez obtenir de l'aide ou des informations sur le programme de ligne commune dans le
système d'exploitation local, vous pouvez appeler un homme ou à info. Lorsque vous souhaitez obtenir de
l'aide sur l'API client HDFS, vous devez appeler hdfs dfs -help ou hdfs dfs -usage
<utility_name> . hdfs signifie que vous marchez avec le client hdfs. dfs signifie que vous travaillez avec
l'API du système de fichiers distribué.

5.3.4 hdfs dfs -ls

Lorsque vous appelez ls dans le système de fichiers local, vous voyez le contenu du répertoire ou les
informations sur le fichier. Comme arguments, nous pouvons utiliser des chemins absolus et relatifs. Pour
le système de fichiers distribué, vous devez appeler hdfs dfs -ls .

Veuillez faire attention au tiret suivant. En plus de la sortie que vous obtenez généralement de la
commande locale ls, vous voyez également un certain nombre de répliques pour chaque fichier dans hdfs.
Vous pouvez également utiliser des indicateurs supplémentaires tels que -R pour la sortie récursive et -h
pour amener la taille des fichiers dans un format lisible par l'homme. À propos, la taille du fichier que vous
voyez à l'écran n'est pas multipliée par le nombre de répliques. Donc, si vous souhaitez compter l'espace
occupé par ce fichier, vous devez multiplier ces nombres.
5.3.5 hdfs dfs -du / -df

Mais vous n'avez pas besoin de faire ce calcul en mémoire. Vous pouvez utiliser un programme appelé DU.
Il vous montrera la taille des fichiers et l'espace consommé par toutes les répliques de fichiers. Encore une
fois, l'option -h vous donnera une sortie lisible par l'homme.

Si vous souhaitez obtenir un résumé de l'utilisation totale de l'espace du système de fichiers, vous pouvez
utiliser l'utilitaire df. Il vous montrera l'espace consommé et disponible dans le stockage distribué.

5.3.6 hdfs dfs -touchz

Vous pouvez créer des fichiers vides avec l'utilitaire touchz. Il y a un léger changement avec le système de
fichiers local. Dans le système de fichiers local, vous utilisez touch pour mettre à jour les méta-informations
du fichier, telles que l'accès et le type de modification. Dans le système de fichiers distribué, vous créez un
fichier de longueur nulle. C'est de là que vient z. Vous pouvez supprimer ce fichier avec l'utilitaire rm. Vous
pouvez également déplacer ce fichier vers un autre emplacement avec un nom différent.

5.3.7 hdfs dfs -put

Laissez-nous plonger profondément pour découvrir comment communiquer avec des nœuds de données.
Imaginez que vous ayez un fichier, test_file.txt, dans le système de fichiers local.
Pour transférer ce fichier du système de fichiers local vers HDFS, vous devez utiliser l'utilitaire put. L'API est
la suivante. hdfs dfs -put et . Lorsque vous lancez l'exécution, toute cette magie que vous voyez à l'image
ci dessus se produira pour vous.

5.3.8 hdfs dfs -cat/-tail

Maintenant, la question raisonnable, comment lire le contenu d'un fichier distant. Dans le système de
fichiers local, nous utilisons les utilitaires de ligne de commande cat, head et tail pour afficher le contenu
d'un fichier sur un écran. Dans HDFS, vous pouvez utiliser un chat pour apporter le fichier entier. Si vous
souhaitez ne voir que les premières lignes du fichier, vous devez utiliser la piping car il n'y a pas
d'utilitaire principal dans HDFS. Si vous souhaitez voir la fin du fichier, vous pouvez utiliser l'utilitaire tail.
Ici, le comportement d'un utilitaire de queue local et de l'utilitaire de queue distribué est différent.

Les utilitaires de système de fichiers locaux se concentrent sur les fichiers texte. Dans un système de
fichiers distribué, vous devez travailler avec une sorte de données binaires. Les données sont généralement
structurées d'une manière spécifique et compressées. Ainsi, l'utilitaire de queue HDFS fait apparaître à
l'écran le dernier kilo-octet d'un fichier. Si vous souhaitez reproduire ce comportement localement, vous
devez fournir l'indicateur -c 1024, qui correspond exactement à 1 kilo-octet de données.

5.3.9 hdfs dfs -get/-getmerge

Comme pour le déplacement de fichiers du système de fichiers local vers HDFS, vous pouvez également
télécharger des fichiers de HDFS vers le système de fichiers local. Jetez un œil à get and get nodes en tant
qu'utilitaires HDFS. Avec l'utilitaire get, vous pouvez télécharger des fichiers. Par exemple, si vous
fournissez un chemin et commencez par le préfixe hdfs_, vous pouvez vous attendre à ce que tous les
fichiers avec ce préfixe soient téléchargés localement. Si vous utilisez l'utilitaire -getmerge, toutes ces
données seront fusionnées dans un fichier local.

5.4 Réglage de la plate-forme de stockage distribué avec les types de fichiers

5.4.1 Texte CSV&TSV

Dans cette section, nous examinerons de plus près les formats de fichiers de format texte, tels que CSV, TSV,
JSON et XML.

De nombreuses données se présentent sous la forme de fichiers texte délimités par des lignes. Disons que
les journaux du serveur Web sont une entrée de journal par ligne, des fichiers texte lisibles par l'homme.
C'est une manière remarquablement courante de générer des données. Le principal avantage des fichiers
texte est qu'ils sont lisibles par l'homme. Vous pouvez lire le fichier lors de l'apprentissage ou du débogage
d'une application. Mais il y a un prix à cela. Lors du traitement de données textuelles, vous devez les
analyser, les convertir de la forme textuelle en structures de données programmatiques. L'analyse est
activée lorsque vous testez des données, mais que vous appelez un pipeline sur des téraoctets de données
toutes les quelques minutes, et que les codes d'analyse s'accumulent et s'affichent rapidement sur un
profil.

Il existe deux cas plus courants pour les données textuelles à l'état sauvage, CSV, qui contient des valeurs
séparées par des virgules et TSV, qui est des valeurs séparées par des tabulations. CSV est souvent utilisé
lors du chargement de données vers et depuis Excel, ce qui est d'une grande utilité dans les finances. Vous
pouvez facilement trouver une bibliothèque CSV dans la plupart des langages de programmation tels que C
++, Python ou Java.

5.4.1.1 Efficacité spatiale

Voyons quels sont les avantages et les inconvénients du CSV. Efficacité spatiale. Eh bien, pas efficace pour
une virgule flottante ou une donnée catégorielle. Comme vous pouvez le voir dans les exemples de
données de codes NASDAQ ici, pour encoder le prix d'ouverture, nous utilisons 11 octets. Dans l'ordinateur,
la valeur à virgule flottante binaire double précision native occupe seulement 8 octets. Aussi, voici une
colonne particulière qui contient une seule valeur répétitive. Il ne semble pas que nous utilisions l'espace
efficacement.
5.4.1.2 Vitesse d'encodage et de décodage / Type de données

CSV et TSC sont des formats simples, leur génération et leur analyse sont donc très efficaces. Cependant, il
y a un hic. Types, types de données pris en charge. En CSV et TSV, il n'y a pas de notion de type valeur. Cela
signifie que techniquement, ils ne stockent que des valeurs de chaîne. Le format lui-même ne vous donne
aucune indication si vous stockez un nombre à virgule flottante ou simplement une chaîne de chiffres
sophistiquée. Le manque de types déplace la complexité vers le code utilisateur qui doit décider quelles
valeurs de chaîne convertir en valeurs principales et comment le faire.

5.4.1.3 Divisibilité

Plus réaliste ou fractionnable. De toute évidence, CSV et TSV sont divisibles à tous les autres formats de
fichiers délimités par des lignes. Le seul hic ici est l'en-tête. Vous ne devez inclure aucun en-tête dans vos
données, car cela empêche le fractionnement et la fusion de vos données.

5.4.1.4 Extensibilité

L'extensibilité est également un point faible pour CSV et TSV. Il n'est pas si facile de supprimer ou de
réorganiser les champs dans ces formats et le code est susceptible de faire des hypothèses sur les index de
champ. Par exemple, il est assez fréquent de trouver des lignes de code comme diviser une ligne sur une
virgule. Le premier champ est un ticker, le second champ est la date dans un code fonctionnant avec CSV.
Imaginez ce qui se passerait si vous ajoutiez un champ supplémentaire à la deuxième position.

5.4.2 Texte JSON

JSON signifie JavaScript Object Notation et définit une représentation des valeurs primitives et de leur
combinaison sous forme de listes et de cartes. JSON est un format populaire sur le Web, de nombreuses
API produisent et consomment des données JSON. Il n'est donc pas surprenant que de nombreuses
données JSON se retrouvent dans des clusters Hadoop. Vous pouvez facilement trouver des bibliothèques
en Python, C ++ et Java pour encoder et décoder JSON.
5.4.2.1 Efficacité spatiale

JSON présente les mêmes inconvénients que CSV et va encore plus loin. Il comprend les noms de champs
sous forme sérialisée. Comme vous pouvez le voir, le ticker de chaînes, la date et d'autres sont répétés
dans chaque ligne de l'ensemble de données.

5.4.2.2 Vitesse d'encodage et de décodage / Type de données

Pour les applications simples, la bibliothèque JSON pour Python peut mettre en pause environ 100 à 300
mégaoctets par seconde, ce qui est assez bien. En C ++ et Java, vous pouvez décoder JSON avec une
vitesse allant jusqu'à 1 gigaoctet par seconde.

JSON vous permet de stocker des chaînes, des nombres, des booléens, des cartes, des listes de manière
native. La variété est la raison de l'augmentation de l'utilisation de l'espace et de la complexité de
l'analyse. Cependant, pour un développeur, JSON est un format de fichier pratique car les types de
données pris en charge correspondent aux types de données fréquemment utilisés dans les langages de
programmation, éliminant ainsi le code de similitude et de désimilarisation standard.

5.4.2.3 Divisibilité

Une façon de stocker un ensemble de données serait de créer un document JSON avec une seule liste, où
chaque élément de liste correspond à un seul élément de données. En conséquence, il y aurait un fichier
monolithique qui doit être analysé, dans tous les cas. Cependant, il existe un format JSON Lines qui stocke
un document JSON pour un élément de données sur une ligne distincte, et il s'agit d'une façon
fractionnable d'utiliser JSON.

5.4.2.4 Extensibilité

L'extensibilité est là où JSON brille. Vous pouvez facilement ajouter et supprimer des champs de vos
éléments de données et JSON restera valide et analysable. Et vous pourriez en déduire de manière
problématique si un champ particulier est présent ou manquant et interroger son type.

5.4.3 Formats binaires

Comme vous l'avez appris dans la section précédente, les formats de texte sont conçus avec la lisibilité
humaine à l'esprit. Les formats binaires sont conçus pour les machines et ils troquent la lisibilité pour
l'efficacité et l'exactitude.
Considérez notre nombre comme exemple de chaîne. Pour analyser une chaîne en un entier, vous devez
parcourir les caractères, convertir chaque caractère en chiffre et effectuer une série d'additions et de
multiplications pour calculer la valeur finale. Vous pouvez également stocker les entiers tels quels en
copiant simplement les octets appropriés. Dans ce cas, chaque entier occuperait exactement 8 octets sur
une plate-forme 64 bits, et la sérialisation et la désérialisation seront tout aussi efficaces que la copie de
données. C'est un exemple d'inefficacité que les formats binaires visent à résoudre.

5.4.3.1 Fichier de séquence

Le principal objectif de conception du fichier de séquence était la simplicité et l'efficacité. Et le cas

d'utilisation principal était de stocker les données intermédiaires dans les calculs MapReduce.
Essentiellement, SequenceFile stocke une séquence de paires clé / valeur, où clé et valeur sont de type
arbitraire avec le code de sérialisation et de désérialisation défini par l'utilisateur. Dans la leçon
MapReduce, vous apprendrez pourquoi les paires clé-valeur sont si spéciales. Le format n'a pas été conçu
pour l'interopérabilité avec d'autres langues. Les codes de sérialisation et de désérialisation sont fournis en
implémentant des interfaces inscriptibles et lisibles en Java, ce qui est souvent fait de manière ad hoc
spécifique à Java. C'est pourquoi vous ne trouverez pas beaucoup d'utilisations ou de fichiers de séquence
en dehors du monde Java. Techniquement, SequenceFile commence par l'en-tête qui comprend la version
du format, les noms de classe pour les types de clé et de valeur, les indicateurs de compression de
syndication, les métadonnées et un marqueur de synchronisation. En fonction des indicateurs de
compression, la disposition des données tombe dans un ou trois cas. Dans le cas non compressé pour
chaque enregistrement, il existe un en-tête de taille fixe avec une longueur de clé d'enregistrement et une
longueur de valeur, suivi de la clé sérialisée et de la valeur sérialisée. Et parfois, suivi du marqueur de
synchronisation. Ainsi, pour décoder les données, vous pouvez lire le fichier de manière linéaire et utiliser
length pour lire la clé et la valeur. Un marqueur de synchronisation est similaire au caractère de nouvelle
ligne dans les formats de texte. Il est utilisé pour sauter des données permettant ainsi un fractionnement
efficace.
5.4.3.2 Record compression

Pour le cas de l'enregistrement compressé, la mise en page est la même, mais la valeur est compressée
avec le code spécifié dans l'en-tête.

5.4.3.3 Block compression

Pour le cas compressé par blocs, la disposition est légèrement différente. Les paires clé-valeur sont
regroupées en blocs et chaque bloc commence par un nombre de paires suivi des longueurs de clé et des
clés compressées. Puis par longueurs de valeur et enfin par valeurs compressées.

La différence entre le cas d'enregistrement compressé et le cas compressé par bloc est que dans le premier
cas, chaque valeur est compressée individuellement tandis que dans le second, un ensemble de clés ou de
valeurs sont compressés ensemble, ce qui entraîne une meilleure compression.
5.4.3.4 Efficacité spatiale

Le format sur disque correspond étroitement au format en mémoire pour permettre un encodage et un
décodage rapides. Strictement parlant, cette déclaration peut ne pas être valable pour un code défini par
l'utilisateur arbitraire, mais pour les types primitifs, c'est vrai. L'utilisation de la compression de prise
pourrait encore améliorer l'efficacité de l'espace.

5.4.3.5 Vitesse d'encodage et de décodage / Type de données

Les valeurs primitives sont copiées telles quelles. Il n'y a donc rien de compliqué.

5.4.3.6 Divisibilité

Tout type d'implémentation dans les interfaces appropriées peut être utilisé avec un format. Pour un
développeur, c'est un énorme avantage. Vous pouvez travailler avec des types de données personnalisés,
implémenter une logique arbitraire et utiliser exactement le même type lors de l'interopérabilité avec le
framework plus difficile.

5.4.3.7 Extensibilité

Les fichiers de séquence peuvent être divisés via des marqueurs de synchronisation. Les marqueurs de
synchronisation sont uniques avec une probabilité élevée, vous pouvez donc rechercher un point arbitraire
dans le fichier et rechercher la prochaine occurrence du marqueur de synchronisation pour obtenir
l'enregistrement suivant. Accessibilité. Pas hors de la boîte. Vous pouvez inclure une version lors de la
sérialisation des données et utiliser ultérieurement cette version pour choisir parmi différentes révisions du
code de désérialisation.