S3 contre HDFS : que choisir pour son data lake

Un lac de données bâti sur S3 rationalise l'analyse des données, mais présente des limites pour ceux qui veulent aller au-delà de l'écosystème du groupe.

Avec le temps, Amazon S3 est devenu le standard de facto pour le stockage dans le cloud. Mais désormais, AWS souhaite aussi positionner son service sur d’autres terres : celles du lac de données (data lake).

Pour mener à bien cette stratégie, le fournisseur de cloud a ajusté S3 à ces cas d’usage, en le dotant de buckets plus vastes et en élargissant la gamme d’outils propres à ces data lakes. On peut par exemple citer AWS Glue (un ETL automatisé) et Athena qui permet de requêter les données stockées dans S3.

Certaines limites sont toutefois bien présentes, surtout en ce qui concerne les transferts et l'analyse de données. Dans certains cas, des alternatives à S3, comme Hadoop (HDFS), pourraient même être de meilleures options. Passons cela en revue.

Pourquoi un lac de données ?

Les lacs de données disposent d’une architecture qui permet de stocker une grande variété de types différents de données et de générer automatiquement un catalogue de ces différentes sources. Il s'agit d'une évolution par rapport aux entrepôts de données : ceux-ci ne sont optimisés que pour les données structurées issues des bases de données transactionnelles, d'ERP et de CRM. Les lacs de données facilitent la recherche de corrélations entre les sources de données structurées et non structurées – idéal pour la gestion des logs, les données issues de l’IoT, les applications mobiles ou encore les médias sociaux.

La data science exige généralement beaucoup d'ingénierie pour identifier les bonnes sources de données, mais aussi beaucoup de préparation. Comme les lacs de données stockent ses entrées en l’état, les entreprises n’y ajoutent un schéma approprié qu’a posteriori. Une façon de faciliter la tâche des data scientists et d’accélérer la mise au point d’algorithmes.

Toutefois, il existe également des difficultés. Il peut être difficile de trouver des sources, de comprendre les schémas et de valider la qualité de la source de données. AWS a conçu S3 pour  minimiser considérablement les procédures d’installation, mais aussi pour faciliter l'utilisation des lacs de données, avec des possibilités de sécurité et une gouvernance intégrées.

L’héritage d’HDFS

D’ailleurs, AWS a positionné S3 comme une alternative plus automatisée à HDFS. Le service de stockage a clairement été adapté à l'infrastructure d'AWS, tandis que HDFS s'appuie sur un historique open source.

HDFS (Hadoop Distributed File System) est une extension de MapReduce, qui est une composante clé d’Hadoop. HDFS assure la distribution des données sur plusieurs nœuds d'un cluster et est bien adapté à la gestion de données multi-sources. Par conséquent, il a préparé le terrain pour les lacs de données en entreprise.

Il y a quelques années, AWS a greffé un service HDFS à son catalogue de services -  Amazon Elastic MapReduce. Celui-ci automatise la création de clusters HDFS sur EC2. C'était jusqu’alors la meilleure option pour créer un lac de données sur AWS, puisque S3 était limité à 5 Go d'objets. On peut créer des data lakes plus élastiques en distribuant HDFS sur plusieurs instances EC2 et en y attachant des volumes de stockage bloc.

Depuis, Amazon a poussé S3. Le service supporte jusqu’à 5 To d’objets que les utilisateurs peuvent agréger. Il est donc plus facile de construire des lacs de données directement sur S3 plutôt que sur HDFS. De plus, S3 est un service, tandis que HDFS est un système de fichiers ; avec S3, Amazon prend en charge la lourde gestion des serveurs.

AWS Glue (ETL) peut ensuite être utilisé pour gagner du temps et automatiser la création d'un catalogue de données qui décrit la structure et le format des différentes sources de données. Ce service scanne plusieurs buckets S3, classe les sources de données et recommande automatiquement les outils  analytiques, comme Redshift Spectrum ou encore Athena.

AWS Glue réduit également les opérations d'extraction, de transformation et de chargement des données dans un référentiel S3 centralisé.

Les limites de S3

Mais tout n’est pas si rose. Créer son lac de données avec S3 n’est pas sans difficulté, notamment en matière de gestion des coûts. Le transfert de données vers d'autres moteurs d'analyse est également complexe. Une fois les données stockées dans S3, AWS ne facture plus le transfert pour l'analyse ou le traitement des données si les traitements sont effectués sur les applications situées dans la même région. Toutefois, les entreprises doivent payer un supplément lorsqu'elles transfèrent des données vers une infrastructure privée ou vers d'autres cloud.

S3 est parfois plus compliqué que HDFS. Le service d’AWS est un magasin d'objets plutôt qu'un système de fichiers. Cela peut réduire les performances lorsque les opérations sont exécutées dans  un répertoire. Certaines opérations effectuées sur les fichiers ne sont pas supportées sur S3.

Comparé à HDFS, les développeurs ne disposent que d’un contrôle limité sur la façon dont les données sont répliquées. Cela peut entraîner des problèmes de cohérence de données. Il est également plus difficile d'optimiser la bande passante entre S3 et les applications analytiques qui fonctionnent en dehors de l'écosystème AWS.

 

Pour approfondir sur Stockage en Cloud

Close