Ingénierie des données

Avec la montée de Big Data et la science des données, de nombreux rôles d'ingénierie sont remis en question et élargis. Un rôle new-age est ingénierie des données .

À 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é des mégadonnées. Ainsi, l'ingénierie des données englobe désormais un large éventail de compétences, de l'exploration Web, du nettoyage des données, de l'informatique distribuée et du stockage et de la récupération de 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 la composante critique du pipeline, ainsi que la façon 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 ont vu le jour. 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é lignes.

Compte tenu de l'omniprésence de ces bases de données, nous n'en discuterons 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 des moteurs de recherche, des magasins de documents et des magasins en colonnes.

• Moteurs de recherche exceller 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 hors de la boîte.
• 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 en tant qu'objets de document individuels, souvent représentés sous forme de JSON, ils ne nécessitent pas de prédéfinition de schéma.
• Magasins en colonnes se spécialiser dans les requêtes à une seule colonne et les agrégations de valeurs. 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 comme 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 les ingénieurs de données, les aspects les plus importants du stockage de données sont
comment ils indexent, fragmentent et agrégent les données. Tweet

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.

mouvement dans les principes de conception

Savoir quelles requêtes sont les plus utilisées 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 façon dont l'infrastructure se développera à mesure que davantage de données seront ingérées.

Choisir celui qui correspond à notre plan de croissance et à notre budget est essentiel, et cela s'applique à tout entreprise de science des données , quelle que soit leur taille.

Enfin, ces technologies agrègent chacune ses données de manière très différente.

Lorsqu'il s'agit de gigaoctets et de 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 des trois aspects lors de l'évaluation des différents stockages de données.

Prétendants

Moteur de recherche: Elasticsearch

Elasticsearch a rapidement gagné en popularité parmi ses pairs pour son évolutivité et sa facilité d'intégration. Construit au-dessus de 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 valeur exacte, 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é ont rapidement gagné sa popularité. MongoDB prend en charge des requêtes riches et adaptables pour explorer 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 partie de données, MongoDB propose un pipeline en plusieurs étapes.

Magasin en 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 des 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 en 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 indices 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 est effectuée automatiquement pour chaque champ via des analyseurs.

Une analyseur est un module qui crée plusieurs clés d'index en évaluant les valeurs de champ 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» en mots tels que «le», «rapide», «brun», «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 modifier les distances , 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 indexe uniquement les _id par défaut, et nous devons créer manuellement des index pour les champs fréquemment interrogés.

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

Capacité d’indexation de Redshift

Contrairement à Elasticsearch, MongoDB ou même les 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 pendant la récupération si sa valeur tombe en dehors de la plage interrogée, ce qui améliore considérablement les performances.

Sharding

Capacité de partage d'Elasticsearch

Elasticsearch a été construit sur Lucene pour évoluer horizontalement et être prêt pour la production.

La mise à l'échelle est effectuée en créant plusieurs instances Lucene (fragments) et en les distribuant sur plusieurs nœuds (serveurs) au sein d'un cluster.

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

Lors de la récupération, le nœud maître envoie à chaque partition une copie de la requête avant de finalement l'agréger et de 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 mettant à l'échelle le routeur, les serveurs peuvent accepter plus de demandes, mais le gros du travail se produit au niveau des serveurs de fragments.

Comme pour Elasticsearch, les documents MongoDB sont acheminés (par défaut) via _id à leurs fragments respectifs. 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 Sharding 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 principal 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 courantes.

Agrégation

Capacité d'agrégation d'Elasticsearch

Les documents dans Elasticsearch peuvent être regroupés par valeurs exactes, à distance, voire temporelles et de géolocalisation.

Ces buckets 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 dans une seule requête.

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

Par exemple, alors qu'il est bon de filtrer si un champ suiveurs est supérieur à 10, nous ne pouvons pas vérifier si suiveurs 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 une analyse ponctuelle, mais les performances en souffrent en production.

Capacité d'agrégation de MongoDB

La Pipeline d'agrégation est puissant et rapide.

Comme son nom l'indique, il fonctionne par étapes sur les données renvoyées.

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

Étant donné que ces opérations sont effectuées par étapes, et en garantissant que les documents et les champs sont réduits à seulement 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 familiarisés avec le calcul du pipeline par étapes trouveront certaines tâches peu intuitives. Par exemple, la somme du nombre d'éléments dans un champ de tableau nécessiterait deux étapes: d'abord, le $unwind, puis le $group opération.

En relation: Business Intelligence Platform: didacticiel sur l'utilisation du pipeline d'agrégation MongoDB

Capacité d'agrégation de Redshift

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

Les agrégations extrêmement 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 bases 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 courantes exécutées sur les nœuds de calcul.

un bon test unitaire est complet et n'est généralement requis qu'une seule fois.

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

Pour maintenir le meilleur temps de lecture, les lignes doivent être triées, ajoutant 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, sauf en cas de 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 à l'avant-garde 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.
• Tandis que 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 trouvons à maintenir de nombreux index dans MongoDB.
• Redshift nécessite un schéma de données prédéfini et ne dispose pas 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.