Technologie

Pourquoi et quand éviter S3 en tant que plateforme de données pour Data Lakes

Pourquoi et quand éviter S3 en tant que plateforme de données pour Data Lakes


2*MkANcy e4VdDfkor1D T9A - Pourquoi et quand éviter S3 en tant que plateforme de données pour Data Lakes

Les lacs de données font fureur de nos jours dans les grandes entreprises. Un lac de données est un magasin unique pour les copies brutes des données du système source et les données transformées à utiliser dans des tâches telles que la création de rapports, la visualisation, l'analyse avancée et l'apprentissage automatique.

Figure 1: Écosystème du lac de données

Les magasins d'objets (comme S3) deviennent la plate-forme de choix pour les lacs de données pour deux raisons principales:

  • Ils offrent un stockage bon marché, durable et pratiquement illimité dans le cloud
  • Ils permettent la séparation du calcul et du stockage, permettant à l'un ou l'autre d'être mis à l'échelle indépendamment

Dans cet article de blog, je vais approfondir certains des avantages des magasins d'objets qui sont responsables de leur popularité en tant que plate-forme pour les lacs de données. J'examinerai également certains des défis souvent sous-estimés qui minent l'utilisation des magasins d'objets pour de nombreux cas d'utilisation de Data Lake.

Les magasins d'objets comme S3 offrent onze 9 de durabilité (99,999999999%) et quatre 9 de disponibilité (99,99%), et ils parviennent à le faire à une échelle pratiquement illimitée, au prix incroyablement bas d'environ 23 $ / To / mois. Comparez cela aux appliances d'entrepôt de données sur site (DWA) qui étaient très populaires il y a quelques années à peine. Le DWA a coûté des dizaines de milliers de dollars par téraoctet, à l'exclusion de l'assistance aux entreprises. Les contrats de plusieurs millions de dollars pour les DWA qui ne prenaient en charge que quelques centaines de téraoctets étaient assez courants.

Lorsque les dirigeants informatiques réfléchissent aux choix de plates-formes de données pour leurs lacs de données, le prix de 23 $ / To / mois des magasins d'objets est tout simplement trop beau pour résister. Il est logique d'utiliser le stockage le moins cher disponible pour les grands volumes de données (de centaines de téraoctets à pétaoctets) que les lacs de données devraient contenir. Les magasins d'objets comme S3 semblent (à tort, comme nous le verrons plus loin dans cet article) représenter un avantage de prix mille fois supérieur au DWA toujours utilisé dans de nombreuses grandes entreprises.

L'échelle de stockage requise pour un lac de données rend l'utilisation des architectures telles que DWA dans laquelle le stockage et le calcul sont couplés ensemble dans un seul paquet. Le découplage du stockage et du calcul nous permet d'apporter à tout moment la bonne quantité de calcul à la demande aux données qui doivent être analysées. Cela réduit considérablement le coût global des solutions d'analyse de données.

Figure 2: séparation du stockage et du calcul

Tous ces avantages sont naturellement cruciaux pour alimenter la popularité de S3 et d'autres magasins d'objets en tant que plate-forme pour les lacs de données. Mais les magasins d'objets sont confrontés à de nombreux défis qui n'attirent pas suffisamment l'attention. Cela est particulièrement vrai pour les données provenant du SGBDR et fréquemment actualisées (quotidiennement / toutes les heures), qui constituent l'essentiel des données de haute qualité dans une entreprise.

Tous les magasins d'objets, y compris S3, GCS et Azure Blob Storage, sont immuables. Cela signifie que les fichiers, une fois écrits dans le magasin d'objets, ne peuvent jamais être modifiés. Les utilisateurs peuvent uniquement supprimer définitivement l'ancien fichier et en créer un nouveau, ou supprimer logiquement l'ancien fichier et en créer un nouveau (versioning).

Lorsque vous utilisez S3 en tant que plate-forme de données pour les données provenant du SGBDR et fréquemment actualisées, cela conduit à la création d'un nombre peu volumineux de petits fichiers pour chaque table.

Figure 3: Le problème de nombreux petits fichiers pour les données provenant du SGBDR

À mesure que les insertions, les mises à jour et les suppressions s'accumulent au fil du temps, essayer de dériver l'état actuel de la table devient exponentiellement plus gourmand en temps et en calcul. La plupart des scientifiques des données rechignent à cette entreprise complexe et demandent à la place un accès direct aux systèmes sources, ce qui va à l'encontre de l'objectif d'utiliser un lac de données en premier lieu.

Figure 4: problèmes avec l'utilisation des changesets bruts sur S3

U = Mettre à jour, I = Insérer, D = Supprimer

Une solution pour lever la responsabilité de la fusion des modifications des utilisateurs finaux consiste à partitionner les données, puis à réécrire la ou les partitions ciblées par les dernières insertions, mises à jour et suppressions. Cela allège quelque peu le fardeau des utilisateurs finaux. Cependant, des problèmes de performances persistent, en particulier si la table a un grand nombre de colonnes et que seul un sous-ensemble de ces colonnes est nécessaire pour l'analyse.

Figure 5: Utilisation de partitions pour fusionner des ensembles de modifications

La solution ci-dessus peut être améliorée en utilisant un format en colonnes comme Apache Parquet ou Apache ORC. Les formats en colonnes améliorent considérablement les performances grâce à une meilleure compression des données et en limitant les E / S aux seules colonnes nécessaires à l'analyse. Cependant, la lecture des fichiers Parquet à partir de langages et d'outils (tels que Python, R ou Tableau) reste difficile.

Figure 6: le stockage en colonnes améliore les performances

Pour développer davantage cette solution, de nombreux ingénieurs ajoutent une interface SQL (comme AWS Athena, Presto ou Spark SQL) sur les fichiers Parquet bruts. Cela rend l'accès aux données beaucoup plus rationalisé pour les utilisateurs finaux, qui peuvent désormais émettre des requêtes SQL à travers leurs langages de programmation et outils préférés (comme Python, R ou Tableau).

Figure 7: les interfaces SQL simplifient l'accès aux données dans un lac de données

La solution ci-dessus peut être améliorée une fois de plus en utilisant une couche de stockage open source comme Delta Lake. Delta Lake améliore encore le format Parquet en ajoutant la prise en charge des transactions ACID (atomicité, cohérence, isolement, durabilité), l'architecture lambda pour prendre en charge les cas d'utilisation en streaming et par lots, et la possibilité d'accéder aux données telles qu'elles étaient à une date de rafraîchissement précédente / le temps (voyage dans le temps).

Figure 8: Delta Lake ajoute des transactions, des cas d'utilisation simultanés de lots et de streaming et des voyages dans le temps

Pas si vite! L'architecture ci-dessus représente une solution viable, et de nombreuses entreprises se félicitent d'avoir pu concevoir et opérationnaliser une telle solution. Pour être juste, c'est tout un exploit que de pouvoir réaliser cela à grande échelle. Cependant, cette architecture est toujours en proie à de nombreux problèmes et a encore beaucoup de place à l'amélioration. Les principaux problèmes avec Delta Lake au-dessus de S3 en tant que plate-forme pour un lac de données comprennent:

  • L'architecture ne traite pas de la création d'ensembles de modifications, ce qui peut être assez difficile à créer
  • Il est assez complexe de mettre en œuvre et de prendre en charge des solutions d'extraction, de transformation et de chargement (ETL) résilientes de qualité entreprise.
  • L'écriture de fichiers Parquet et Delta nécessite un calcul supplémentaire, ainsi qu'un savoir-faire technique, pour configurer et opérationnaliser, à grande échelle, des plates-formes de calcul en cluster comme Apache Spark
  • L'accès à l'interface SQL (via des technologies comme AWS Athena, Presto ou Spark SQL) nécessite une infrastructure de calcul supplémentaire, augmentant ainsi la complexité globale et le coût de la solution
  • La complexité de la solution rend son support coûteux
  • S3 offre des capacités limitées de métadonnées et d'étiquetage
  • L'intégration de la sécurité au niveau des tables ou des lignes sur les objets dans S3, en particulier pour les grandes entreprises complexes, peut être assez difficile
  • Enfin et surtout, les performances d'une telle plate-forme sont loin derrière les performances des appliances d'entrepôt de données qu'elle visait à remplacer

gCompte tenu des coûts cachés de calcul et de support, de l'intégration de la sécurité et des problèmes de performances, S3 en tant que plate-forme de données pour les données provenant du SGBDR et fréquemment actualisées est loin de sa promesse de 23 $ / To / mois. Une fois que nous avons additionné tous les coûts, cela commence à se glisser dans la fourchette de milliers de dollars par To par mois. Pour ce type d'argent, il existe de bien meilleures alternatives.

Les bases de données analytiques gérées à l'échelle du cloud telles que Snowflake, Google BigQuery ou Azure Synapse Analytics offrent le meilleur des deux mondes. En séparant le stockage et le calcul, ils fournissent des coûts de stockage comparables à S3 ainsi qu'une plate-forme de données gérée qui résume la complexité de la mise en œuvre de solutions d'analyse à l'échelle du cloud. Ils offrent un TCO similaire à Parquet / ORC / Delta Lake basé sur S3 avec une interface SQL AWS Athena / Presto / Spark, tout en offrant de meilleures performances, une intégration de la sécurité et une prise en charge de schéma. Ils réduisent également les frais généraux opérationnels tout en transférant les risques techniques et liés aux talents à un fournisseur tiers.

Figure 9: Avantages d'une base de données d'analyse gérée par rapport à la solution «magasin d'objets + Delta Lake + interfaces SQL»

Les données provenant du SGBDR, principalement statiques (c'est-à-dire qu'elles ne changent pas pendant des semaines ou des mois) n'engendrent pas autant de calcul ETL et de prise en charge des frais généraux que les données provenant du SGBDR et fréquemment mises à jour. Cependant, ma recommandation serait de préférer les bases de données analytiques gérées à l'échelle du cloud au stockage Parquet / ORC / Delta Lake basé sur S3 pour de tels cas d'utilisation, car tous les défis et les coûts entourant la gestion des métadonnées, l'intégration de la sécurité et les performances demeurent.

La plupart des données semi-structurées entrant dans l'entreprise (via des formats tels que XML, JSON et CSV) ont un schéma raisonnablement stable et peuvent être ingérées dans des tables relationnelles. La plupart de ces données dans les grandes entreprises sont fréquemment ingérées dans des bases de données analytiques comme AWS Redshift ou accessibles via des interfaces SQL comme AWS Athena, Presto ou Spark SQL sur le stockage Parquet / ORC / Delta Lake basé sur S3. Pour ce type de cas d'utilisation, ma recommandation serait de considérer les bases de données analytiques gérées qui séparent le stockage et le calcul.

En fin de compte, les solutions doivent être jugées sur la base du coût total de possession (TCO), compte tenu des capacités qu'elles apportent à la table et des risques inhérents à la solution. Si deux solutions ont un coût total de possession similaire, mais que l'une d'entre elles offre de meilleures capacités, il devrait être évident de s'aligner sur cette solution. En outre, une attention particulière doit être accordée aux risques techniques et liés aux talents associés aux solutions développées en interne. En règle générale, pour les grandes entreprises, il est plus judicieux de décharger les risques liés à la technologie et aux talents sur des produits de fournisseurs réputés, lorsque cela est raisonnable.

Figure 10: équilibre du coût total de possession, des performances, des fonctionnalités et des risques

Les magasins d'objets (comme S3) restent une excellente plate-forme de données pour d'autres cas d'utilisation comme des données semi-structurées et non structurées qui ne peuvent pas ou ne devraient pas (pour des raisons de coût ou d'utilité) être ingérées dans des bases de données d'analyse à l'échelle du cloud. Par exemple, il ne serait pas logique d'intégrer des images, des fichiers audio, des vidéos, des e-mails, des présentations PowerPoint, des documents Word ou des PDF dans des bases de données analytiques gérées. De plus, bon nombre de ces bases de données distribuées à l'échelle du cloud utilisent des magasins d'objets (comme S3) comme interface d'ingestion de données, et certains utilisent même des magasins d'objets comme plates-formes de stockage gérées en interne derrière la scène.

Tableau 1: Recommandations

Dans un prochain article, nous expliquerons en détail pourquoi les bases de données analytiques gérées à l'échelle du cloud qui séparent le stockage et le calcul (comme Snowflake, Google BigQuery ou Azure Synapse Analytics), couplées à des outils CDC spécialement conçus (comme Qlik Replicate, Oracle GoldenGate ou HVR CDC), conviennent mieux aux données provenant du SGBDR et fréquemment actualisées dans les lacs de données d'entreprise.

Afficher plus

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Articles similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bouton retour en haut de la page
Fermer