The Doppler Quarterly (FRANÇAIS) Été 2017 | Page 16

Consommation
Dérivations / calculs ajoutés
Metastore ajoutée
Couche brute
• Données sous forme quasi-organisée
• Aucune transformation
Figure 2|: Stockage d’objets partitionné avec la mise en cluster Hive
On pourrait discuter bien plus de cet exemple, mais nous
nous contenterons de dire que l’on peut implémenter de
nombreuses approches d’ajout de couches supplémen-
taires selon les schémas de consommation souhaités. du cluster, occupant en règle générale 150 bits chacun.
Ainsi, 100 millions de fi chiers, utilisant chacun un bloc,
occuperaient environ 30 gigabits de mémoire. Il paraît
donc évident que les outils de l’écosystème Hadoop ne
sont pas optimisés pour l’accès effi cace aux petits fi ch-
iers. Ils sont principalement conçus pour les grands
fi chiers, dont la taille est généralement un multiple pair
de la taille de bloc.
Choisir un format de fi chiers Apache ORC
Introduction ORC est un format de fi chiers en colonnes bien connu, et
conçu pour les charges de travail Hadoop. La possibilité
de lire, décompresser, et traiter uniquement les valeurs
nécessaires à la demande en cours est rendue possible
par le format de fi chier en colonnes. Bien qu’il existe plu-
sieurs formats en colonnes disponibles, beaucoup de
grands utilisateurs de Hadoop utilisent ORC. Ainsi, Face-
book emploie ORC pour économiser des dizaines de
pétaoctets dans son entrepôt de données. Ils ont égale-
ment démontré que ORC est nettement plus rapide que
les fi chiers RC ou Parquet. Yahoo utilise également ORC
pour le stockage de ses données de production, et a dif-
fusé comme Facebook certains de ses résultats d’études
comparatives.
titionnés en « répertoires » et les fi chiers mis en clusters
par Hive sont disposés de façon à améliorer les modèles
d’accès aux données décrits sur la Figure 2.
Les gens qui arrivent du monde des SGBDR sont souvent
surpris de l’extraordinaire latitude de contrôle dont
nous disposons en tant qu’architectes de lacs de don-
nées sur la façon de stocker les données. Contrairement
à un moteur de stockage SGBDR, les lacs de données
nous permettent de déterminer une gamme d’éléments
tels que la taille des fi chiers, le type de stockage (lignes/
colonnes), le degré de compression, l’indexation, les
schémas et les tailles de blocs. Ces éléments sont liés à
l’écosystème d’outils orientés Hadoop généralement
utilisés pour l’accès aux données d’un lac.
Taille du fi chier
Un petit fi chier est un fi chier dont la taille est nettement
inférieure à la taille de bloc par défaut du système de
fi chiers Hadoop (HDFS), qui est de 128 Mo. Dans le cas
d’un stockage de petits fi chiers, étant donné l’énorme
volume de données contenu dans un lac, on obtient un
très grand nombre de fi chiers. Chaque fi chier est
représenté par un objet dans la mémoire de name node
14 | THE DOPPLER | ÉTÉ 2017
Mêmes données, plusieurs formats
Il est tout à fait possible qu’un type de structure de
stockage et un format de fi chiers soient optimisés pour
une charge de travail particulière, mais pas pour une
autre. Dans ce genre de situation, étant donné le faible
coût du stockage, la création de plusieurs copies d’un
même ensemble de données est parfaitement envisage-