La solution de stockage objet NetApp StorageGRID offre évolutivité, disponibilité des données, sécurité et hautes performances. Les entreprises de toutes tailles et de tous secteurs utilisent StorageGRID S3 pour un large éventail d'utilisations. Étudions quelques scénarios types :

Analytique Big Data : StorageGRID S3 est fréquemment utilisé comme data Lake, où les entreprises stockent de grandes quantités de données structurées et non structurées à des fins d'analyse à l'aide d'outils tels que Apache Spark, Splunk Smartstore et Dremio.

Tiering des données : les clients NetApp utilisent la fonctionnalité FabricPool d'ONTAP pour déplacer automatiquement les données entre un niveau local haute performance et StorageGRID. Le Tiering libère un stockage Flash coûteux pour les données actives tout en maintenant les données inactives disponibles dans un stockage objet à faible coût. Cela optimise les performances et les économies.

Sauvegarde des données et reprise après incident : les entreprises peuvent utiliser StorageGRID S3 comme une solution fiable et économique pour sauvegarder des données critiques et les restaurer en cas d'incident.

Stockage des données pour les applications : StorageGRID S3 peut être utilisé comme backend de stockage pour les applications, ce qui permet aux développeurs de stocker et de récupérer facilement des fichiers, des images, des vidéos et d'autres types de données.

Diffusion de contenu : StorageGRID S3 peut être utilisé pour stocker et fournir aux utilisateurs du monde entier du contenu statique, des fichiers multimédias et des téléchargements logiciels, en exploitant la répartition géographique et l'espace de noms global de StorageGRID pour une diffusion de contenu rapide et fiable.

Archives de données : StorageGRID offre différents types de stockage et prend en charge la hiérarchisation vers des options de stockage public à faible coût à long terme, en faisant une solution idéale pour l'archivage et la conservation à long terme des données qui doivent être conservées à des fins de conformité ou d'historique.

Cas d'utilisation du stockage objet

Parmi ces cas d'usage, l'analytique Big Data est l'un des plus utilisés, et son utilisation est en hausse.

StorageGRID S3 Data Lakes

Cet article présente un banc d'essai complet de divers entrepôts de données et écosystèmes de lakehouse utilisant NetApp StorageGRID. L'objectif est de déterminer quel système fonctionne le mieux avec le stockage objet S3. Reportez-vous à cette "Apache Iceberg : guide de référence" section pour en savoir plus sur les architectures datawarehous/lakehouse et le format de table (parquet et Iceberg).

TPC-DS comprend 99 requêtes SQL complexes conçues pour l'analyse comparative. Nous avons mesuré le temps total nécessaire à l'exécution des 99 requêtes et réalisé une analyse détaillée en examinant le type et le nombre de requêtes S3. Nos tests ont comparé l'efficacité de deux formats de table courants : parquet et Iceberg.

Résultat de la requête TPC-DS avec le format de table parquet

¹ Hive Impossible de compléter la requête numéro 72

Résultat de la requête TPC-DS avec format de table Iceberg

² les performances de Trino/Starburst sont des engorgements dus aux ressources de calcul ; l'ajout de RAM au cluster réduit le temps total de requête.

Comme le montre le premier tableau, Hive est beaucoup plus lente que les autres écosystèmes de maisons de données modernes. Nous avons observé qu'Hive a envoyé un grand nombre de requêtes d'objets de liste S3, qui sont généralement lentes sur toutes les plateformes de stockage objet, en particulier lorsqu'il s'agit de compartiments contenant de nombreux objets. Cela augmente considérablement la durée globale des requêtes. En outre, les écosystèmes de lakehouse modernes peuvent envoyer un grand nombre de requêtes GET en parallèle, allant de 2,000 à 5,000 requêtes par seconde, contre 50 à 100 requêtes par seconde de Hive. La copie de système de fichiers standard de Hive et Hadoop S3A contribue à la lenteur d'Hive lors de l'interaction avec le stockage objet S3.

L'utilisation d'Hadoop (HDFS ou le stockage objet S3) avec Hive ou Spark nécessite une connaissance approfondie de Hadoop et Hive/Spark, ainsi qu'une compréhension des interactions entre les paramètres de chaque service. Ensemble, ils ont plus de 1,000 réglages, dont beaucoup sont liés et ne peuvent pas être modifiés indépendamment. Trouver la combinaison optimale de paramètres et de valeurs nécessite beaucoup de temps et d'efforts.

En comparant les résultats du parquet et de l'Iceberg, nous constatons que le format du tableau est un facteur de performance important. Le format de table Iceberg est plus efficace que le parquet en termes de nombre de requêtes S3, avec 35 à 50 % de demandes en moins par rapport au format parquet.

Les performances de Dremio, Trino ou Starburst sont principalement déterminées par la puissance de calcul du cluster. Bien que les trois utilisent le connecteur S3A pour la connexion de stockage objet S3, ils ne nécessitent pas Hadoop et la plupart des paramètres fs.s3a de Hadoop ne sont pas utilisés par ces systèmes. Cela simplifie le réglage des performances, éliminant ainsi la nécessité d'apprendre et de tester les différents paramètres Hadoop S3A.

À partir de ce résultat du banc d'essai, nous pouvons conclure que le système d'analytique Big Data optimisé pour les workloads S3 constitue un facteur de performance majeur. Les blanchisseurs modernes optimisent l'exécution des requêtes, utilisent efficacement les métadonnées et fournissent un accès transparent aux données S3. Ils offrent ainsi de meilleures performances que Hive avec le stockage S3.

Reportez-vous à cette "page" section pour configurer la source de données Dremio S3 avec StorageGRID.

Cliquez sur les liens ci-dessous pour découvrir comment StorageGRID et Dremio travaillent en collaboration pour fournir une infrastructure de data Lake moderne et efficace, et comment NetApp a migré de Hive + HDFS vers Dremio + StorageGRID pour améliorer considérablement l'efficacité de l'analyse Big Data.