Guide de l'ingénieur de données sur les stockages de données non traditionnels

Ingénierie des données

Avec l'essor du Big Data et de la science des données, de nombreux rôles d'ingénierie sont remis en question et élargis. L' ingénierie des données est un rôle de la nouvelle ère.

À l'origine, le but de l'ingénierie des données était le chargement de sources de données externes et la conception de bases de données (conception et développement de pipelines pour collecter, manipuler, stocker et analyser des données).

Il s'est depuis développé pour prendre en charge le volume et la complexité du Big Data. Ainsi, l'ingénierie des données englobe désormais un large éventail de compétences, allant de l'exploration du Web au nettoyage des données, en passant par l'informatique distribuée, le stockage et la récupération des données.

Pour l'ingénierie des données et les ingénieurs de données, le stockage et la récupération des données sont le composant essentiel du pipeline, ainsi que la manière dont les données peuvent être utilisées et analysées.

Ces derniers temps, de nombreuses technologies de stockage de données nouvelles et différentes sont apparues. Cependant, lequel est le mieux adapté et possède les fonctionnalités les plus appropriées pour l'ingénierie des données ?

La plupart des ingénieurs connaissent les bases de données SQL, telles que PostgreSQL, MSSQL et MySQL, qui sont structurées en tables de données relationnelles avec un stockage orienté ligne.

Étant donné l'omniprésence de ces bases de données, nous n'en parlerons pas aujourd'hui. Au lieu de cela, nous explorons trois types de stockages de données alternatifs qui gagnent en popularité et qui ont introduit différentes approches pour traiter les données.

Dans le contexte de l'ingénierie des données, ces technologies sont les moteurs de recherche, les magasins de documents et les magasins en colonnes.

• Les moteurs de recherche excellent dans les requêtes textuelles. Par rapport aux correspondances de texte dans les bases de données SQL, telles que LIKE , les moteurs de recherche offrent des capacités de requête plus élevées et de meilleures performances prêtes à l'emploi.
• Les magasins de documents offrent une meilleure adaptabilité du schéma de données que les bases de données traditionnelles. En stockant les données sous forme d'objets de document individuels, souvent représentés sous forme de JSON, elles ne nécessitent pas de définition de schéma.
• Les magasins en colonnes sont spécialisés dans les requêtes à colonne unique et les agrégations de valeurs. Les opérations SQL, telles que SUM et AVG , sont considérablement plus rapides dans les magasins en colonnes, car les données de la même colonne sont stockées plus près les unes des autres sur le disque dur.

Dans cet article, nous explorons les trois technologies : Elasticsearch en tant que moteur de recherche, MongoDB en tant que magasin de documents et Amazon Redshift en tant que magasin en colonnes.

En comprenant le stockage de données alternatif, nous pouvons choisir celui qui convient le mieux à chaque situation.

Pour comparer ces technologies, nous examinerons comment elles indexent, fragmentent et agrégent les données.

Chaque stratégie d'indexation des données améliore certaines requêtes tout en en gênant d'autres.

Savoir quelles requêtes sont utilisées le plus souvent peut influencer le magasin de données à adopter.

Le sharding, une méthodologie par laquelle les bases de données divisent leurs données en morceaux, détermine la croissance de l'infrastructure à mesure que davantage de données sont ingérées.

Il est essentiel d'en choisir un qui corresponde à notre plan de croissance et à notre budget, et cela s'applique à toute entreprise de science des données, quelle que soit sa taille.

Enfin, ces technologies agrègent chacune ses données très différemment.

Lorsque nous traitons des gigaoctets et des téraoctets de données, une mauvaise stratégie d'agrégation peut limiter les types et les performances des rapports que nous pouvons générer.

En tant qu'ingénieurs de données, nous devons tenir compte de ces trois aspects lors de l'évaluation de différents stockages de données.

Concurrents

Moteur de recherche : Elasticsearch

Elasticsearch a rapidement gagné en popularité auprès de ses pairs pour son évolutivité et sa facilité d'intégration. Construit sur Apache Lucene, il offre une puissante fonctionnalité de recherche de texte et d'indexation prête à l'emploi. Outre les tâches traditionnelles des moteurs de recherche, la recherche de texte et les requêtes de valeurs exactes, Elasticsearch offre également des capacités d'agrégation en couches.

Magasin de documents : MongoDB

À ce stade, MongoDB peut être considéré comme la base de données NoSQL incontournable. Sa facilité d'utilisation et sa flexibilité lui ont rapidement valu sa popularité. MongoDB prend en charge des requêtes riches et adaptables pour creuser dans des documents complexes. Les champs souvent interrogés peuvent être accélérés grâce à l'indexation, et lors de l'agrégation d'une grande quantité de données, MongoDB offre un pipeline en plusieurs étapes.

Magasin à colonnes : Amazon Redshift

Parallèlement à la croissance de la popularité de NoSQL, les bases de données en colonnes ont également attiré l'attention, en particulier pour l'analyse de données. En stockant les données dans des colonnes au lieu des lignes habituelles, les opérations d'agrégation peuvent être exécutées directement à partir du disque, ce qui augmente considérablement les performances. Il y a quelques années, Amazon a déployé son service hébergé pour un magasin à colonnes appelé Redshift.

Indexage

Capacité d'indexation d'Elasticsearch

À bien des égards, les moteurs de recherche sont des magasins de données spécialisés dans l'indexation de textes.

Alors que d'autres magasins de données créent des index basés sur les valeurs exactes du champ, les moteurs de recherche permettent la récupération avec seulement un fragment du champ (généralement du texte).

Par défaut, cette récupération se fait automatiquement pour chaque champ via des analyseurs.

Un analyseur est un module qui crée plusieurs clés d'index en évaluant les valeurs des champs et en les décomposant en valeurs plus petites.

Par exemple, un analyseur de base pourrait examiner « le renard brun rapide a sauté par-dessus le chien paresseux » dans des mots tels que « le », « rapide », « marron », « renard », etc.

Cette méthode permet aux utilisateurs de trouver les données en recherchant des fragments dans les résultats, classés en fonction du nombre de fragments correspondant aux mêmes données de document.

Un analyseur plus sophistiqué pourrait utiliser les distances d'édition, les n-grammes et filtrer par mots vides pour créer un index de récupération complet.

Capacité d'indexation de MongoDB

En tant que magasin de données générique, MongoDB offre une grande flexibilité pour l'indexation des données.

Contrairement à Elasticsearch, il n'indexe que le champ _id par défaut, et nous devons créer manuellement des index pour les champs fréquemment interrogés.

Comparé à Elasticsearch, l'analyseur de texte de MongoDB n'est pas aussi puissant. Mais il offre une grande flexibilité avec les méthodes d'indexation, du composé et géospatial pour une interrogation optimale au TTL et clairsemé pour la réduction du stockage.

Capacité d'indexation de Redshift

Contrairement à Elasticsearch, MongoDB ou même aux bases de données traditionnelles, y compris PostgreSQL, Amazon Redshift ne prend pas en charge une méthode d'indexation.

Au lieu de cela, il réduit son temps de requête en maintenant un tri cohérent sur le disque.

En tant qu'utilisateurs, nous pouvons configurer un ensemble ordonné de valeurs de colonne comme clé de tri de table. Avec les données triées sur le disque, Redshift peut ignorer un bloc entier lors de la récupération si sa valeur se situe en dehors de la plage interrogée, ce qui améliore considérablement les performances.

Partage

Capacité de partitionnement d'Elasticsearch

Elasticsearch a été construit au-dessus de Lucene pour évoluer horizontalement et être prêt pour la production.

La mise à l'échelle s'effectue en créant plusieurs instances Lucene (fragments) et en les répartissant sur plusieurs nœuds (serveurs) au sein d'un cluster.

Par défaut, chaque document est acheminé vers sa partition respective via son champ _id .

Lors de la récupération, le nœud maître envoie à chaque partition une copie de la requête avant de finalement les agréger et les classer pour la sortie.

Capacité de partage de MongoDB

Dans un cluster MongoDB, il existe trois types de serveurs : routeur, configuration et partition.

En faisant évoluer le routeur, les serveurs peuvent accepter plus de requêtes, mais le gros du travail se produit sur les serveurs de partition.

Comme avec Elasticsearch, les documents MongoDB sont acheminés (par défaut) via _id vers leurs partitions respectives. Au moment de la requête, le serveur de configuration notifie le routeur, qui fragmente la requête, et le serveur du routeur distribue ensuite la requête et agrège les résultats.

Capacité de partitionnement de Redshift

Un cluster Amazon Redshift se compose d'un nœud principal et de plusieurs nœuds de calcul.

Le nœud leader gère la compilation et la distribution des requêtes ainsi que l'agrégation des résultats intermédiaires.

Contrairement aux serveurs routeurs de MongoDB, le nœud leader est cohérent et ne peut pas être mis à l'échelle horizontalement.

Bien que cela crée un goulot d'étranglement, cela permet également une mise en cache efficace des plans d'exécution compilés pour les requêtes populaires.

Agrégation

Capacité d'agrégation d'Elasticsearch

Les documents dans Elasticsearch peuvent être regroupés par valeurs exactes, étendues ou même temporelles et de géolocalisation.

Ces compartiments peuvent être regroupés en une granularité plus fine grâce à une agrégation imbriquée.

Les métriques, y compris les moyennes et les écarts types, peuvent être calculées pour chaque couche, ce qui permet de calculer une hiérarchie d'analyses au sein d'une seule requête.

Étant un stockage basé sur des documents, il souffre de la limitation des comparaisons de champs intra-document.

Par exemple, bien qu'il soit efficace pour filtrer si un champ followers est supérieur à 10, nous ne pouvons pas vérifier si followers est supérieur à un autre champ suivant .

Comme alternative, nous pouvons injecter des scripts en tant que prédicats personnalisés. Cette fonctionnalité est idéale pour les analyses ponctuelles, mais les performances en souffrent en production.

Capacité d'agrégation de MongoDB

Le pipeline d'agrégation est puissant et rapide.

Comme son nom l'indique, il fonctionne sur les données renvoyées de manière échelonnée.

Chaque étape peut filtrer, agréger et transformer les documents, introduire de nouvelles mesures ou dérouler des groupes précédemment agrégés.

Étant donné que ces opérations sont effectuées par étapes et en veillant à ce que les documents et les champs soient uniquement filtrés, le coût de la mémoire peut être minimisé. Comparé à Elasticsearch et même à Redshift, Aggregation Pipeline est un moyen extrêmement flexible de visualiser les données.

Malgré son adaptabilité, MongoDB souffre du même manque de comparaison de champs intra-document qu'Elasticsearch.

De plus, certaines opérations, y compris $group , nécessitent que les résultats soient transmis au nœud maître.

Ainsi, ils ne tirent pas parti de l'informatique distribuée.

Ceux qui ne sont pas familiers avec le calcul du pipeline par étapes trouveront certaines tâches peu intuitives. Par exemple, additionner le nombre d'éléments dans un champ de tableau nécessiterait deux étapes : d'abord, l'opération $unwind , puis l'opération $group .

Capacité d'agrégation de Redshift

Les avantages d'Amazon Redshift ne peuvent être sous-estimés.

Les agrégations frustrantes et lentes sur MongoDB lors de l'analyse du trafic mobile sont rapidement résolues par Amazon Redshift.

Prenant en charge SQL, les ingénieurs de base de données traditionnels auront plus de facilité à migrer leurs requêtes vers Redshift.

Mis à part le temps d'intégration, SQL est un langage de requête éprouvé, évolutif et puissant, prenant en charge facilement les comparaisons de champs intra-document/ligne. Amazon Redshift améliore encore ses performances en compilant et en mettant en cache les requêtes populaires exécutées sur les nœuds de calcul.

En tant que base de données relationnelle, Amazon Redshift n'a pas la flexibilité de schéma dont disposent MongoDB et Elasticsearch. Optimisé pour les opérations de lecture, il subit des baisses de performances lors des mises à jour et des suppressions.

Pour maintenir le meilleur temps de lecture, les lignes doivent être triées, ce qui ajoute des efforts opérationnels supplémentaires.

Adapté à ceux qui ont des problèmes de la taille d'un pétaoctet, il n'est pas bon marché et ne vaut probablement pas l'investissement à moins qu'il n'y ait des problèmes de mise à l'échelle avec d'autres bases de données.

Choisir le gagnant

Dans cet article, nous avons examiné trois technologies différentes - Elasticsearch, MongoDB et Amazon Redshift - dans le contexte de l'ingénierie des données. Cependant, il n'y a pas de gagnant clair car chacune de ces technologies est un précurseur dans sa catégorie de type de stockage.

Pour l'ingénierie des données, selon le cas d'utilisation, certaines options sont meilleures que d'autres.

• MongoDB est une base de données de démarrage fantastique. Il offre la flexibilité que nous souhaitons lorsque le schéma de données doit encore être déterminé. Cela dit, MongoDB ne surpasse pas les cas d'utilisation spécifiques dans lesquels d'autres bases de données se spécialisent.
• Bien qu'Elasticsearch offre un schéma fluide similaire à MongoDB, il est optimisé pour plusieurs index et requêtes de texte au détriment des performances d'écriture et de la taille de stockage. Ainsi, nous devrions envisager de migrer vers Elasticsearch lorsque nous nous retrouvons à maintenir de nombreux index dans MongoDB.
• Redshift nécessite un schéma de données prédéfini et manque de l'adaptabilité fournie par MongoDB. En retour, il surclasse les autres bases de données pour les requêtes n'impliquant qu'une seule (ou quelques) colonnes. Lorsque le budget le permet, Amazon Redshift est une excellente arme secrète lorsque d'autres ne peuvent pas gérer la quantité de données.