Conception d’architectures d’ingestion de flux de données volumineuses à l’aide de Snowflake

Conception d’architectures d’ingestion de flux de données volumineuses à l’aide de Snowflake


Dans PARTIE I de cet article de blog, nous avons discuté de certaines des décisions architecturales pour la construction d’un pipeline de données en continu et de la meilleure façon d’utiliser Snowflake à la fois comme entrepôt de données d’entreprise (EDW) et comme plate-forme Big Data. Conceptuellement, vous souhaitez vous préparer à analyser les données en quasi « temps réel », en fournissant à vos utilisateurs professionnels un accès aux données en quelques minutes, au lieu des heures ou des jours auxquels ils sont habitués. C’est ce que l’Architecture Lambda (https://lambda-architecture.net/) tente de réaliser et c’est ce que les clients de Snowflake adorent sur notre plateforme.

Snowflake offre le meilleur des deux mondes, c’est-à-dire que les utilisateurs peuvent interroger des données semi-structurées en utilisant SQL pendant le chargement des données, sans conflit et avec une cohérence transactionnelle totale. Si vous êtes comme moi, vous vous dites : « Vraiment ? Bref, la réponse est un « OUI » retentissant ! Alors quel est notre secret ? Nous profitons du fait d’être la première base de données cloud native hébergée sur AWS et d’utiliser au maximum les capacités du service de système de fichiers S3.

La PARTIE II explore la commande Snowflake COPY et ses options puissantes pour ajouter progressivement de la capacité et des capacités à votre pipeline de données pour la gestion des erreurs et la transformation. Il traite également des options de validation et de transformation des données après leur chargement.

Commande COPY de Snowflake

La commande COPY est extrêmement riche en fonctionnalités, vous donnant la possibilité de décider où dans le pipeline gérer certaines fonctions ou transformations, telles que l’utilisation ELT (Extraire/Charger/Transformer) au lieu de ETL traditionnel.

À l’aide de la commande COPY, les données peuvent être chargées à partir de S3 en parallèle, ce qui permet de charger des centaines de téraoctets (To) en quelques heures, sans compromettre l’accès en temps quasi réel aux données qui ont été chargées. La commande COPY peut être exécutée à partir du Feuille de travail dans l’interface utilisateur, comme toute autre opération DDL ou DML, ou par programmation à l’aide de l’un des langages pris en charge, tels que Python, Node.js, ODBC, JDBC ou Spark.

Pointe: Comme bonne pratique, nous vous recommandons de tester la syntaxe de vos commandes via l’interface utilisateur avant de l’intégrer dans le code.

Voici les points saillants des nombreuses options fournies par la commande COPY pour gérer le processus de chargement de bout en bout.

Compression

Étant donné que Snowflake utilise une implémentation de traitement massivement parallèle (MPP) en colonne, les données sont compressées pour optimiser les performances de stockage et de requête. De plus, les données peuvent être chargées à partir de fichiers déjà compressés comme indiqué ci-dessous :

fichier compressé

Pointe: Concevez votre application de collecte de données pour produire des fichiers d’une taille d’environ 100 Mo, ce qui donnera non seulement la meilleure valeur de stockage, mais également des performances de requête optimales basées sur l’architecture sous-jacente de Snowflake.

Charge parallèle

La capacité de Snowflake à charger plusieurs fichiers en parallèle en exécutant une seule commande COPY signifie que chaque nœud d’entrepôt virtuel (VW) peut fonctionner simultanément sur plusieurs fichiers. La considération de conception ici est de savoir s’il faut créer un fichier volumineux (par exemple, plusieurs Go) ou plusieurs petits fichiers pour des performances de chargement optimales. La commande Snowflake COPY peut gérer l’une ou l’autre configuration, mais chargera les fichiers les plus petits et les plus nombreux beaucoup plus rapidement. Les fichiers plus petits permettent également une gestion plus facile des erreurs en cas de problème avec les données.

La gestion des erreurs

Les options de la commande COPY qui doivent être prises en compte pour la gestion des erreurs incluent :

  • Valider avant chargement: Snowflake vous permet d’exécuter la commande COPY dans Validation mode sans réellement charger les données. Il peut soit renvoyer le nombre de lignes qui ont échoué, soit renvoyer toutes les erreurs. Cette fonctionnalité est intéressante pour les ensembles de données plus petits, mais présente l’inconvénient d’exiger que la commande soit exécutée deux fois : une fois pour la vérification des erreurs, puis une autre fois pour la charge réelle, ce qui peut entraîner une surcharge excessive, selon votre cas d’utilisation.
  • Valider au chargement: La commande COPY offre de multiples options pour contrôler le comportement en cas d’erreur lors du chargement :
    • La stratégie la plus simple consiste à continuer en cas d’erreur, ce qui est acceptable pour certains cas d’utilisation ou à des fins de test initial.
    • L’option suivante consiste à ignorer le fichier si des erreurs se produisent, ou si un nombre spécifique d’erreurs se produit, ou si un pourcentage spécifique des enregistrements contient des erreurs. Gardez à l’esprit que Snowflake conserve les métadonnées concernant les fichiers qui ont été chargés et, à moins qu’il ne soit spécifiquement configuré pour le faire, la commande COPY ne chargera pas le même fichier deux fois dans la même table. Cela vous permet d’utiliser la même commande COPY avec la même correspondance de modèle encore et encore à mesure que d’autres fichiers sont ajoutés dans la même structure de répertoires. Cependant, vous devez vous en souvenir lorsque vous essayez de charger.
    • Enfin, vous pouvez abandonner en cas d’erreur et arrêter complètement le chargement.

Nettoyage de fichier

La commande COPY a un paramètre pour purger automatiquement les fichiers chargés à partir de la zone de préparation S3 en cas de succès ou les laisser en place à des fins réglementaires ou de stockage à long terme. La plupart des clients ont choisi de conserver ces fichiers pendant au moins une courte période. Une fois les données validées, vous pouvez décider de les conserver à leur emplacement actuel (c’est-à-dire dans la zone de staging), de les déplacer vers un stockage à long terme moins cher (comme Amazon Glacier) ou de les supprimer complètement.

Chargement dans des tables de production ou des tables intermédiaires ?

Vous pouvez choisir de charger directement dans votre table de production ou vous pouvez organiser vos données pour le post-traitement une fois ingérées. Il y a des avantages et des compromis pour les deux. L’implémentation la plus simple et la plus directe serait d’avoir toute la logique de transformation et d’erreur construite autour de vos tables de niveau de production. En fonction de vos volumes de données, en particulier de la confiance que vous accordez à la qualité des données, cela pourrait bien fonctionner. L’inconvénient de cette approche est la flexibilité. Comme vous pouvez l’imaginer, vous vous êtes maintenant préparé à laisser cette table (ou cet ensemble de tables) grandir pour toujours.

Selon votre cas d’utilisation, si vous décidez d’effectuer des transformations, vous risquez de vous retrouver à travailler à partir d’ensembles de données extrêmement volumineux et potentiellement impurs, ce qui pourrait ne pas être optimal. La plupart des clients commencent par cette méthode, puis passent à l’architecture décrite dans PARTIE I de ce blog. Il est relativement facile de faire la transition de n’importe quel code écrit pour fonctionner avec des tables intermédiaires afin qu’il écrive plutôt de plus petits morceaux de données dans des tables de production.

Traitement post-chargement

Une fois les données chargées à l’aide de la commande COPY, Snowflake prend en charge des options de post-traitement supplémentaires.

Traitement dynamique des données semi-structurées

La plupart des données de streaming que nos clients chargent dans Snowflake sont des données semi-structurées, telles que JSON, AVRO ou XML. L’un des principaux avantages de l’utilisation de Snowflake pour le traitement de ces données est qu’il ne nécessite pas de modifications de code dans le pipeline de données à mesure que la structure des données change. La plupart des bases de données nécessitent un broyage avant l’ingestion pour placer les données dans des tables prédéfinies, ce qui permet d’y accéder via SQL. Nous avons plusieurs clients dont le format de données change quotidiennement, et avant Snowflake, l’équipe de développement d’applications devait hiérarchiser les éléments qui seraient exposés et les parties du pipeline qui seraient corrigées.

Ce n’est plus le cas avec Snowflake !

Notre type de données VARIANT s’adapte automatiquement pour permettre l’ingestion et la disponibilité immédiate de nouveaux éléments sans modifier le code de votre application ou le schéma de votre base de données. Chaque élément devient une sous-colonne interne qui peut être référencée à l’aide d’une notation par points, par exemple :

SELECT COUNT(:) FROM elt_table;

Cela permet aux utilisateurs finaux d’accéder instantanément aux nouvelles données au fur et à mesure qu’elles font partie du flux, sans avoir à demander à l’équipe de développement d’effectuer un nouveau travail. IMPRESSIONNANT!

La validation des données

Semblable à la Validation mode qui peut être utilisé pour la gestion des erreurs avant le chargement, les utilisateurs de Snowflake peuvent puiser dans les métadonnées collectées pour chaque fichier chargé. Pour chaque commande COPY, la fonction de table VALIDATE fournit des informations sur les types d’erreurs rencontrées, le nom du fichier contenant l’erreur et le décalage de ligne et d’octet de l’erreur, qui peuvent être utilisées pour analyser les données malformées dans le flux. Une meilleure pratique serait d’exécuter cette fonction après chaque commande COPY et d’enregistrer les résultats dans une table d’erreurs pour un débogage ultérieur, par exemple :

INSERT INTO save_copy_errors SELECT * FROM TABLE(VALIDATE(elt_table, Job_ID => '_LAST'));

Transformation des données

En fonction de vos cas d’utilisation, des compétences de vos utilisateurs finaux, des types d’analyses que vous effectuez et de vos outils de requête, vous souhaiterez peut-être (ou devrez) transformer des données semi-structurées (y compris des tableaux et des objets dans des structures non relationnelles) en tables relationnelles avec des types de données réguliers (INTEGER, CHAR, DATE, etc.), y compris des modèles de données utilisant la troisième forme normale, les étoiles, le flocon de neige ou tout type de schéma. Snowflake est un SGBDR entièrement fonctionnel et conforme à la norme ANSI qui ne limite pas la création de votre modèle de données. La fonctionnalité intégrée de Snowflake favorise l’ELT (extraction/chargement/transformation) en faveur de l’ETL traditionnel ou Architectures de lac de données qui reposent sur l’utilisation de Hadoop pour la transformation. Ces fonctionnalités incluent :

  • Performances extrêmes en utilisant SQL avec des données semi-structurées: Snowflake décompose automatiquement les objets semi-structurés en sous-colonnes. Un avantage supplémentaire est que chacune de ces colonnes contient des métadonnées statistiques capturées lors de l’ingestion ; ceci est utilisé pour optimiser les performances des requêtes, de la même manière que les colonnes relationnelles classiques. Cela nous permet d’offrir des performances améliorées par rapport à Hive ou à d’autres technologies de superposition Hadoop/SQL par un facteur de 10 à 1000 fois. De plus, vous pouvez toujours améliorer les performances en mettant à l’échelle votre VW sans recharger les données.
  • Prise en charge des fonctions définies par l’utilisateur (UDF): Si Snowflake ne fournit pas de fonction native, d’agrégation ou de transformation pour l’opération que vous souhaitez effectuer, vous pouvez facilement créer des UDF SQL et des UDF JavaScript.
  • Conversion de type de données: Snowflake simplifie le transtypage des données avec à la fois une fonction CAST et une notation ‘::’ fonctionnellement équivalente pour convertir implicitement les types de données. Une attention particulière doit être portée lors de la conversion des horodatages et des dates afin d’éviter toute diffusion ultérieure en aval dans le pipeline lors des requêtes des utilisateurs finaux.

Conclusion

La rationalisation du pipeline de données peut avoir un impact considérable sur la valeur des données entrant dans votre entreprise. Les utilisateurs finaux qui attendaient des jours avant de voir les résultats des modifications qu’ils ont apportées aux systèmes opérationnels pourront voir leurs résultats en quelques minutes. L’utilisation de la puissance d’un RDBMS de traitement massivement parallèle basé sur le cloud pour effectuer l’ELT signifie que vous n’avez pas à déplacer des To de données entre votre infrastructure Hadoop et votre EDW, ce qui réduit considérablement ou élimine les fenêtres de chargement des données. La plate-forme Snowflake Data vous permet de commencer petit avec peu de complexité, puis de faire évoluer votre architecture à mesure que les besoins de votre entreprise évoluent.

Je n’ai fait qu’effleurer la surface des capacités de Snowflake liées au traitement des données semi-structurées, alors recherchez d’autres articles pendant que je travaille avec des clients sur leurs scénarios d’analyse Big Data les plus difficiles et n’hésitez pas à me contacter pour toute question ! Et, comme toujours, assurez-vous de suivre nos flux Twitter liés à Snowflake (@SnowflakeDB) pour tous les derniers développements et annonces.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.