Concevoir des outils d’ingestion de Big Data

Concevoir des outils d’ingestion de Big Data


Cet article met en évidence certaines des fonctionnalités avancées de Snowflake et identifie les principales décisions architecturales susceptibles d’être influencées lors de la conception de pipelines pour l’ingestion de données en continu.

Qu’est-ce que les données diffusées ?

Les données diffusées en continu sont des informations générées en continu par des sources de données telles que les réseaux sociaux, les appareils connectés, les jeux vidéo, les capteurs, etc. Ainsi, à l’ère des médias sociaux et de l’Internet des objets (IoT), les architectures de diffusion en continu pour la capture et l’analyse de données ont devenir extrêmement populaire. La construction de ces pipelines de données pour collecter des données semi-structurées à partir de sources telles que Facebook, Twitter et LinkedIn nécessite une plate-forme capable de gérer ces nouvelles constructions et approche de l’analyse.

Pourquoi flocon de neige?

L’élastique du flocon de neige entrepôt de données en nuage est extrêmement bien adapté pour gérer les défis de volume, de variété et de vitesse de travail avec le Big Data. La meilleure pratique en vigueur pour l’ingestion de flux est l’architecture Lambda (https://lambda-architecture.net/). Snowflake peut facilement être utilisé comme composant central de Lambda, simplifiant l’architecture et accélérant l’accès aux données à la fois dans la couche batch et la couche vitesse.

Le schéma suivant fournit une vue de haut niveau d’un flux de données architecture d’ingestion, intégrant à la fois l’infrastructure cloud et les éléments Snowflake :

Architecture d'ingestion

Lors de la conception d’architectures complexes, il est utile de décomposer le problème en composants gérables. Je vais donc diviser cette discussion en deux parties :

  • Décisions à prendre avant le chargement
  • Décisions à prendre concernant le chargement (à l’aide de la commande COPY) et le post-traitement.

Ce billet de blog se concentre sur les décisions à prendre avant de charger des données. Un article de suivi se concentrera sur la commande COPY et sur la façon dont elle gère les erreurs et les transformations pendant le chargement, ainsi qu’une discussion sur les options de post-traitement après le chargement de vos données.

Décisions à prendre avant le chargement

L’entrepôt de données élastique de Snowflake s’exécute sur la plate-forme AWS d’Amazon, qui offre une grande variété de choix pour créer votre pipeline de données. Il est préférable de commencer petit avec un exemple d’ensemble de données et un nombre limité de services, en vous familiarisant avec les nuances de chacun. L’un des principaux avantages de l’utilisation de Snowflake comme plate-forme Big Data est notre implémentation du type de données VARIANT pour les données semi-structurées. En raison de la nature variable des données semi-structurées, de nouveaux éléments sont souvent ajoutés au flux, obligeant les développeurs à constamment mettre à jour leurs scripts d’ingestion et leurs structures de données internes. Snowflake modifie cette dynamique en décomposant automatiquement ces objets en sous-colonnes lors de l’ingestion, donnant aux utilisateurs un accès instantané aux données via SQL (voir ci-dessous pour plus de détails).

Langage de programmation

Pour les applications de streaming, choisissez un langage qui fonctionne bien avec le service de plateforme cloud (c’est-à-dire Snowflake sur Amazon AWS) que vous exploiterez pour les composants suivants :

  • Collecte de données (par exemple Kinesis, Firehose, SQS)
  • Notification (par exemple SNS)
  • Contrôler l’exécution du flux (par exemple Data Pipeline, Lambda)

Snowflake prend en charge plusieurs langages de programmation, y compris, mais sans s’y limiter, Python, Node.js, ODBC, JDBC et Spark. Toutes les connexions à Snowflake utilisent TLS et passent par notre API REST sécurisée.

Structure du répertoire du système de fichiers

Snowflake prend en charge le chargement directement depuis Amazon Simple Storage Service (S3) à l’aide de fichiers de type Avro, JSON, XML et CSV/TSV. La plupart des architectures de streaming sont conçues pour écrire des fichiers (compressés ou non) dans une zone de transfert temporaire pour la tolérance aux pannes et la gérabilité (Amazon S3 dispose de fonctionnalités très intéressantes pour déplacer les données). Lors de la configuration des compartiments S3 et des structures de répertoires, considérez que le moyen le plus efficace de charger des données dans Snowflake consiste à utiliser le micro-batch et la commande COPY (plus d’informations à ce sujet dans les prochains articles). Si vous utilisez une convention de nommage de répertoire et de fichier telle que s3:////////, vous pouvez utiliser l’option MOTIF dans la commande COPIER. L’option PATTERN utilise des expressions régulières pour faire correspondre des fichiers et/ou des répertoires spécifiques à charger. En segmentant les données et les fichiers dans le temps, les données peuvent être chargées en sous-ensembles ou en une seule fois, selon votre cas d’utilisation.

Pointe: La commande COPY de Snowflake ne charge chaque fichier dans une table qu’une seule fois, sauf instruction explicite de recharger les fichiers. C’est une fonctionnalité intéressante car vous pouvez diffuser vos données dans le même répertoire et continuer à exécuter la même commande COPY encore et encore, et seuls les nouveaux fichiers seront chargés. Cependant, au fur et à mesure que vous faites évoluer votre processus de chargement, n’abusez pas de cette fonctionnalité. Pour chaque commande COPY, Snowflake doit d’abord obtenir la liste des fichiers du répertoire pour effectuer la correspondance et, si la liste devient trop longue, la commande peut passer plus de temps à déterminer quels fichiers charger qu’à charger réellement les données.

Entrepôt pour le chargement

Snowflake a la capacité unique de faire tourner les ressources de calcul, et les ressources peuvent être configurées dans différentes tailles. Cela permet de stocker et d’analyser des ensembles de données à l’échelle du pétaoctet. Pour charger ou interroger des données, un entrepôt virtuel (VW) doit être en cours d’exécution et utilisé dans la session. Étant donné que Snowflake propose un modèle de tarification basé sur l’utilité similaire à Amazon (c’est-à-dire que nous facturons les ressources de calcul à l’heure), vous souhaiterez optimiser votre VW pour le chargement en fonction de votre cas d’utilisation (c’est-à-dire la quantité de données que vous chargez et la rapidité avec laquelle vous besoin d’y accéder). Vous pouvez activer ou désactiver un VW à l’aide de SQL ou de l’interface utilisateur Web. Vous pouvez également définir des paramètres pour la suspension automatique et la reprise automatique. Voici un exemple de commande pour créer et démarrer un VW :

CREATE WAREHOUSE load_warehouse WITH
                 WAREHOUSE_SIZE = 'MEDIUM'
                 WAREHOUSE_TYPE = 'STANDARD'
                 AUTO_SUSPEND = 1800 AUTO_RESUME = TRUE
                 MIN_CLUSTER_COUNT = 1 MAX_CLUSTER_COUNT = 1;

Pointe: Snowflake charge les données à partir de fichiers en parallèle de manière extrêmement efficace, alors commencez par une taille x-petite ou petite, et utilisez un seul VW pour le chargement et l’interrogation. Au fur et à mesure que vos volumes de données augmentent ou que les SLA pour les performances des requêtes se resserrent, vous pouvez séparer ces fonctions en VW distincts – un pour le chargement, un pour l’interrogation – et dimensionner chacun pour la charge de travail appropriée.

Définition du tableau

Avant de charger des données dans Snowflake, vous devez définir une structure. Étant donné que Snowflake est conforme à ANSI SQL, vous pouvez exécuter DDL tel que CREATE TABLE AS depuis l’interface Web (dans l’onglet Feuille de travail) ou via l’interface de ligne de commande (snowsql), ou vous pouvez simplement utiliser l’onglet Base de données dans l’interface Web. . Il y a deux éléments clés pour définir une table :

  • Type de tableau
  • Structure du tableau

Type de tableau

Snowflake prend en charge trois types de tables : permanent, transitoireet temporaire. Les différences entre les trois sont doubles : combien de temps la table persiste et combien de temps la protection Time Travel et Fail-safe est fournie (ce qui contribue au coût de stockage).

  • Les tables temporaires ne sont que cela – elles existent pour la durée de votre session. Ils sont généralement utilisés comme emplacement temporaire pour stocker et agir sur les données lors de la programmation. Ils ne fournissent aucune protection de voyage dans le temps ou de sécurité intégrée, de sorte qu’ils n’encourent aucune empreinte de stockage supplémentaire au-delà des données de la table, qui sont purgées de Snowflake à la fin de la session.
  • Les tables transitoires sont souvent utilisées comme zones de transit pour les données qui pourraient facilement être rechargées en cas de perte ou de corruption. Comme les tables temporaires, elles ne fournissent aucune protection Fail-safe, mais elles persistent pendant une journée lors de la suppression, de la suppression ou de la troncation de la table, permettant le voyage dans le temps (https://docs.snowflake.net/manuals/user-guide/data-time-travel.html). Les tables transitoires conservent les données exactement comme les tables permanentes, à l’exception de l’aspect Fail-safe.
  • Les tables permanentes sont le type par défaut créé par la commande CREATE TABLE. Par défaut, ils fournissent 1 jour de voyage dans le temps et bénéficient en plus de sept jours de protection Fail-safe (https://docs.snowflake.net/manuals/user-guide/data-cdp-storage-costs.html). Et, avec notre offre Enterprise, les tables permanentes peuvent être configurées pour un maximum de 90 jours de voyage dans le temps.

Structure du tableau

La structure que vous avez choisie pour votre table dépend du type de données que vous chargez :

  • Pour les données structurées (CSV/TSV), nous vous recommandons vivement de prédéfinir chaque colonne/champ de votre table cible avec une définition de type de données appropriée avant l’importation. Snowflake fournit un objet Format de fichier qui peut aider à la conversion de date, aux séparateurs de colonnes et de lignes, à la définition de valeurs nulles, etc.
  • Pour les données semi-structurées (JSON, Avro, XML), définissez une table avec une seule colonne en utilisant VARIANT comme type de données.

Créer une table de variantes

Lorsque vous chargez des données semi-structurées dans la colonne VARIANT, Snowflake décompose automatiquement chaque objet dans une sous-colonne optimisée pour le traitement des requêtes et accessible via SQL en utilisant la notation par points ; par exemple:

SELECT COUNT(fieldname:objectname) FROM table;

Conclusion

En fin de compte, la conception d’architectures de flux et l’analyse de ces données peuvent être simplifiées en fonction de vos décisions architecturales et en tirant parti des fonctionnalités de la plateforme à votre avantage. Commencez petit et continuez à ajouter des fonctionnalités à mesure que vos volumes de données, vos types de données et vos cas d’utilisation augmentent.

Dans la PARTIE II de cette série de blogs (à venir), nous verrons comment les données sont chargées dans Snowflake et quelles décisions doivent être prises concernant les transformations dans la base de données, telles que le passage du traditionnel ETL modèle à ELTce qui peut être beaucoup plus efficace pour les gros traitement de l’information.

Et, comme toujours, continuez à regarder ce site de blog et notre flux Twitter lié à Snowflake (@SnowflakeDB) pour des informations plus utiles et des actualités de dernière minute sur Snowflake Computing.

Liens supplémentaires

Laisser un commentaire

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