Conception d’une architecture moderne de streaming Big Data à grande échelle (première partie)

Conception d’une architecture moderne de streaming Big Data à grande échelle (première partie)


En septembre 2016, j’ai écrit une série d’articles de blog expliquant comment concevoir une architecture d’ingestion de flux de données volumineuses à l’aide de Snowflake. Il y a deux ans, fournir une alternative au transfert de données dans un système Hadoop sur site et concevoir une architecture moderne et évolutive utilisant des technologies cloud de pointe était un gros problème. Avance rapide jusqu’en 2018 et il est temps de revoir les données de chargement avec de nouvelles fonctionnalités.

Dans cet article en deux parties, je commencerai par me concentrer sur la mise à l’échelle de l’architecture Snowflake pour s’adapter à l’ingestion de volumes de données plus importants tout en offrant un accès plus rapide à l’analyse des données. Dans l’illustration ci-dessous, notez que j’ai divisé l’architecture en quatre sections principales :

  1. La couche de file d’attente
  2. La couche du lac
  3. La couche d’orchestration
  4. La couche d’entrepôt

De gauche à droite, le flux fournit des informations permettant de sélectionner l’architecture de streaming à suivre : Kappa (un flux) contre Lambda (deux flux). Lorsque vous travaillez avec Snowflake, Lambda ou Kappa fonctionneront bien ; cependant, lorsque l’on considère l’évolution des fonctionnalités de Snowflake pour le chargement de données à grande vitesse/volume, Kappa s’aligne plus naturellement. En simplifiant en une architecture à flux unique, il est possible d’avoir moins de couches et un temps d’analyse plus rapide.

Data Streaming 1

Couche de file d’attente

Que vos données proviennent d’applications IOT (par exemple, des capteurs ou des journaux de sécurité), vous traitez d’énormes volumes de données. Très peu de clients avec qui je travaille jettent leurs données, ce que je soutiens. Pourquoi? Parce que la conservation des données fournit un mécanisme pour gérer la commande d’ensembles de données volumineux sans perdre de vue quelles informations ont ou n’ont pas été traitées. Cela crée également la possibilité d’effectuer des analyses basées sur les événements sur les sous-sections du flux de données et recherchez les anomalies (ou conditions spécifiques) qui déclenchent des notifications comme une alerte de sécurité.

Avec Snowflake, la valeur de la couche de file d’attente réside dans son utilité pour contrôler la taille, le format et le placement des données dans la couche du lac de données. Il est important de connaître les limites de l’environnement cloud sous-jacent, y compris les limites de taille de fichier et les conditions de recherche (par exemple, essayer de répertorier 10 millions de fichiers en un seul appel). En tant que bonne pratique, il est préférable de charger des fichiers supérieurs à 100 Mo et inférieurs à 1 Go plutôt que de charger de nombreux fichiers plus petits pour les performances de chargement et de requête.

Couche de lac

Travailler avec des clients me donne l’opportunité d’observer de nombreuses implémentations différentes de Hadoop et de stockage de lac de données dans le cloud. La plus grande tendance que je vois est l’avènement des « zones » ou « couches » dans l’environnement de stockage en nuage. J’ai appelé quatre zones différentes dans l’illustration d’architecture ci-dessus, mais il n’y a vraiment pas de limite. L’interaction entre la couche du lac et la couche de l’entrepôt nécessite une réflexion approfondie sur l’opportunité de poursuivre une approche ETL ou ELT. Il faut également tenir compte des types d’outils d’analyse et de BI à utiliser pour accéder aux différentes couches. Trois considérations principales peuvent avoir un impact sur le travail dans Snowflake :

Norme de type de fichier

Chaque zone de l’architecture Kappa peut accueillir différents types de données, la couche brute permettant généralement presque tous les formats de données. Au fur et à mesure que vous vous déplacez dans les couches (de gauche à droite dans l’illustration), il devient important de normaliser et d’appliquer un certain type de gestion de la configuration afin que les utilisateurs finaux sachent quelles données sont disponibles et à quel point elles sont à jour.

À ce stade, vous devez décider quelles couches vous souhaitez charger dans Snowflake et comment créer une lignée (cycle de vie) des données au fur et à mesure qu’elles se déplacent dans les couches. Je recommande d’utiliser un catalogue (voir illustration), d’autant plus que vos volumes et sources de données augmentent. Snowflake peut ingérer nativement JSON, AVRO, XML, Parquet, ORC et CSV/TSV, donc si vous cherchez à obtenir un accès en temps quasi réel à vos données, le chargement directement à partir de la couche brute est la solution.

Politiques de charge

Tous les déplacements de données entre chaque couche et la transformation des données ne peuvent pas se produire avant, pendant ou après le chargement dans une couche. Généralement contrôlé par une couche d’orchestration, Snowflake fonctionne avec de nombreux fournisseurs ETL/ELT tiers et des implémentations Spark pour optimiser les charges de données à volume élevé (téraoctets par heure).

Certains clients avec lesquels je travaille ont une politique stipulant que toutes les données circulant dans Snowflake sont d’abord conservées dans la couche du lac. D’autres clients préfèrent l’autonomie métier (LOB) pour le chargement des données avec l’outil de leur choix. Indépendamment des politiques et des préférences pour les ensembles d’outils, à ce stade, vous devez déterminer la fréquence à laquelle vous souhaitez ou devez charger des données entre les couches de lac dans la couche d’entrepôt, ainsi que la manière de garder le contrôle sur les données à présenter aux utilisateurs finaux. Snowflake propose différentes options de chargement et copier les paramètres avec différentes caractéristiques de latence, choisissez donc une approche basée sur votre fenêtre d’analyse et vos exigences spécifiques pour la conservation des données historiques.

Méthodologie de charge

La méthodologie de charge est un domaine dans lequel Snowflake a considérablement évolué au cours des dernières années. Nous offrons maintenant Snowpipe, un service de chargement sans serveur que vous pouvez configurer sans code côté client. Vous pouvez également l’utiliser par programmation pour ingérer automatiquement des données à partir d’AWS S3 Storage. L’ingestion automatique donne aux concepteurs la possibilité d’utiliser des données basées sur des événements ou des planifications de manière idempotente, ce qui signifie que vous obteniez le même résultat, que vous chargiez le même fichier une fois ou cent fois.

Conclusion

L’idempotence est un concept puissant que je couvrirai plus en détail dans le prochain article (deuxième partie). Je reprendrai également le fil de cet article en explorant la couche d’entrepôt et les différents schémas, y compris les schémas PDA/transformation et de production, que vous pouvez utiliser pour charger des données, exécuter des requêtes analytiques et préparer des données sur la production pour des performances optimales. De plus, je passerai en revue la couche d’orchestration et donnerai quelques conseils sur les outils à utiliser pour configurer les flux de travail.

Laisser un commentaire

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