Skip to main content
How to enable StorageGRID in your environment
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

NetApp StorageGRID et l'analytique Big Data

Contributeurs

Utilisations de NetApp StorageGRID

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.

Tiering des données : les clients NetApp utilisent la fonction ONTAP FabricPool pour déplacer automatiquement les données entre un niveau local hautes performances vers StorageGRID. Le Tiering libère du 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.

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

Diagramme de cas d'utilisation StorageGRID,largeur=396,hauteur=394

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

Pourquoi choisir StorageGRID pour les data Lakes ?

  • Collaboration renforcée : colocation multisite partagée massive avec accès API standard

  • Coûts d'exploitation réduits : simplicité opérationnelle d'une seule architecture à autorétablissement

  • Évolutivité : contrairement aux solutions Hadoop et d'entrepôt de données classiques, le stockage objet StorageGRID S3 dissocie le stockage des ressources de calcul et de données pour vous permettre de faire évoluer vos besoins de stockage au fur et à mesure de leur croissance.

  • Durabilité et fiabilité : StorageGRID garantit une durabilité de 99.999999999 %, ce qui signifie que les données stockées sont hautement résistantes à la perte de données. Il assure également une haute disponibilité, garantissant ainsi un accès permanent aux données.

  • Sécurité : StorageGRID offre plusieurs fonctionnalités de sécurité, notamment le chiffrement, les règles de contrôle d'accès, la gestion du cycle de vie des données, le verrouillage d'objets et la gestion des versions pour protéger les données stockées dans des compartiments S3

StorageGRID S3 Data Lakes

Exemple de datalake StorageGRID,width=614,height=345

Quel data warehouse ou data Lake fonctionne le mieux avec le stockage objet S3

NetApp a évalué StorageGRID avec trois écosystèmes d'entrepôts de données et de maisons de lac - Hive, Delta Lake et Dremio. "Apache Iceberg : guide de référence" inclut une brève introduction du data warehouse et du data lake house, ainsi que les avantages/inconvénients de ces deux architectures.

  • Outil de référence - TPC-DS - https://www.tpc.org/tpcds/

  • Les écosystèmes Big Data

    • Cluster de 5 machines virtuelles, chacune avec 128 G de RAM et 24 vCPU, stockage SSD pour le disque système

    • Hadoop 3.3.5 avec Hive 3.1.3 (1 nœud de nom + 4 nœuds de données)

    • Delta Lake avec Spark 3.2.0 (1 maître + 4 employés) et Hadoop 3.3.5

    • Dremio v23 (1 maître + 4 exécuteurs)

  • Stockage objet

    • NetApp® StorageGRID® 11.6 avec 3 x SG6060 + 1 équilibreur de charge SG1000

    • Protection objet : 2 copies

  • Taille de base de données : 1 000 Go

  • Cache désactivé sur les 3 écosystèmes pour obtenir un résultat cohérent pour chaque test de requête.

TPC-DS est fourni avec 99 requêtes SQL complexes pour l'analyse comparative des requêtes. Nous avons mesuré le nombre total de minutes nécessaires pour effectuer les 99 requêtes et nous avons analysé le résultat plus en détail en dépanne le type et le nombre de requêtes S3. Le premier tableau ci-dessous présente la durée totale des 99 requêtes et le second tableau résume le nombre et les types de requêtes S3 envoyées à chaque écosystème à StorageGRID.

Résultat de la requête TPC-DS

Écosystème Ruche Delta Lake Dremio

La couche de stockage

NetApp® StorageGRID®

NetApp® StorageGRID®

NetApp® StorageGRID®

Type de disque

DISQUES DURS

DISQUES DURS

DISQUES DURS

Format de tableau

Parquet

Parquet

Parquet 1

Taille de la base de données

1 000 G

1 000 G

1 000 G

Requêtes TPCDS 99
nombre total de minutes

1084 2

55

47

1 testé les formats de table parquet et Iceberg, le résultat est similaire.

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

Requêtes TPC-DS - ventilation des requêtes S3

Requêtes S3 Ruche Delta Lake Dremio

OBTENEZ

1,117,184

2,074,610

4,414,227

observation:
Tous les ACCÈS à la gamme

Plage de 80 % de 2 Ko à 2 Mo à partir d'objets de 32 Mo, 50 à 100 requêtes/sec

Plage de 73 % inférieure à 100 Ko pour les objets de 32 Mo, 1000 à 1400 requêtes/sec

90 % plage d'octets de 1 Mo provenant d'objets de 256 Mo, 2000 à 2300 requêtes/sec

Liste des objets

312,053

24,158

240

TÊTE
(objet inexistant)

156,027

12,103

192

TÊTE
(objet existant)

982,126

922,732

1,845

Nombre total de demandes

2,567,390

3,033,603

4,416,504

À partir de la première table, nous pouvons voir Delta Lake et Dremio sont beaucoup plus rapides que Hive. À partir du second tableau, Hive a envoyé de nombreuses demandes d'objets de liste S3, qui sont généralement lentes dans toutes les plateformes de stockage objet, en particulier si le compartiment contient de nombreux objets. Cela augmente considérablement la durée globale des requêtes. Une autre observation est Dremio a pu envoyer un grand nombre de requêtes GET en parallèle, 2,000 à 2,300 requêtes par seconde contre 50 à 100 requêtes par seconde à Hive. Le système de fichiers standard du modèle ruve et Hadoop S3A contribue à la lenteur de Hive dans le stockage objet S3.

Pour utiliser Hadoop (HDFS ou le stockage objet S3) avec Hive ou Spark, il est nécessaire de disposer de connaissances approfondies sur Hadoop et Hive/Spark et sur l'interaction entre les paramètres de chaque service. Ensemble, ils disposent de plus de 1000 paramètres. Très souvent, les paramètres sont interdépendants et ne peuvent pas être modifiés seuls. Il faut beaucoup de temps et d'efforts pour trouver la combinaison optimale de paramètres et de valeurs à utiliser.

Dremio est un moteur de data Lake qui utilise Apache Arrow de bout en bout pour améliorer considérablement les performances de requêtes. Apache Arrow propose un format de mémoire standard par colonnes pour un partage efficace des données et une analyse rapide. Arrow utilise une approche indépendante du langage, conçue pour éliminer le besoin de sérialisation et de désérialisation des données, améliorant ainsi les performances et l'interopérabilité entre les processus et les systèmes de données complexes.

Les performances de Dremio sont principalement déterminées par la puissance de calcul sur le cluster Dremio. Bien que Dremio utilise le connecteur S3A de Hadoop pour la connexion de stockage d'objets S3, Hadoop n'est pas nécessaire et la plupart des paramètres fs.s3a de Hadoop ne sont pas utilisés par Dremio. Cela facilite le réglage des performances de Dremio sans passer de temps à apprendre et à tester 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 la charge de travail S3 constitue un facteur de performance majeur. Dremio optimise l'exécution des requêtes, utilise efficacement les métadonnées et fournit un accès transparent aux données S3. Il offre ainsi de meilleures performances que Hive avec le stockage S3. Se reporter à ceci "page" 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.