Moteurs de traitement de données volumineuses - Lequel dois-je utiliser ? :Partie 1

Cet article de blog a été publié sur Hortonworks.com avant la fusion avec Cloudera. Certains liens, ressources ou références peuvent ne plus être exacts.

Remerciements particuliers à Bill Preachuk et Brandon Wilson pour avoir révisé et fourni leur expertise

Présentation

Le stockage en colonnes est un sujet souvent abordé dans le monde du traitement et du stockage de données volumineuses aujourd'hui - il existe des centaines de formats, de structures et d'optimisations dans lesquels vous pouvez stocker vos données et encore plus de façons de les récupérer en fonction de ce que vous envisagez de faire. avec ça. Cette pléthore d'options est née de la nécessité non seulement d'ingérer rapidement des données à l'aide d'outils de traitement transactionnel en ligne (OLTP), mais également de la nécessité de consommer et d'analyser les données avec une plus grande efficacité à l'aide du traitement analytique en ligne (OLAP). outils. Des milliers de cas d'utilisation différents ont chacun leurs propres besoins spécifiques et, par conséquent, de nombreuses options ont fait surface. Par exemple, la lecture des données boursières nécessite un état d'esprit complètement différent de l'analyse des mesures de qualité dans une chaîne de fabrication. Avec tous ces choix, il est facile de se perdre lorsque vous naviguez vers votre objectif final :choisir un outil qui fonctionne pour vous.

HDP intègre un certain nombre de solutions de stockage, chacune étant conçue sur mesure pour des cas d'utilisation spécifiques. Nous voulons commencer cette série de blogs en parlant des trois outils/moteurs suivants et de leurs formats de stockage associés :

• Apache Hive utilise Apache ORC comme format de stockage en colonnes efficace qui permet des performances pour le traitement des requêtes OLAP et Deep SQL
• Apache Phoenix/Apache HBase forment ensemble une base de données OLTP qui permet des requêtes en temps réel sur des milliards d'enregistrements et offre des recherches rapides basées sur des clés aléatoires ainsi que des mises à jour
• Apache Druid est un magasin de données hautes performances qui permet une analyse en temps réel de séries chronologiques sur des flux d'événements et des analyses OLAP sur des données historiques avec une latence extrêmement faible

Dans cet article, nous avons l'intention d'articuler l'outil approprié pour un cas d'utilisation donné, de comparer et de contraster les différents outils, et de fournir une ligne directrice de base pour choisir l'outil ou l'ensemble d'outils approprié pour répondre à votre cas d'utilisation.

C'est un peu comme jouer à Tetris - chaque pièce a une niche différente mais chacune ajoute une valeur unique à la structure plus large

Le traitement des mégadonnées et ses similitudes

Les données sont regroupées par colonnes dans le stockage car nous essayons souvent d'affiner les sommes, les moyennes ou d'autres calculs sur une colonne spécifique. Imaginez que vous êtes une compagnie aérienne essayant de comprendre la quantité de carburant à donner à un avion lorsqu'il est amarré - vous voudrez peut-être calculer la moyenne des miles parcourus par chaque vol à partir d'un tableau de données sur les vols. Cela nécessiterait d'effectuer la fonction de moyenne sur une seule colonne. Nous stockerions ces données sous forme de colonnes car les lectures séquentielles sur disque sont rapides, et ce que nous voulons faire dans ce cas est de lire une colonne complète de la table de manière séquentielle (puis d'effectuer un calcul moyen).

Il existe de nombreuses différences entre ces moteurs, mais quel que soit le moteur de traitement de données que vous choisissez, vous bénéficierez de quelques points communs. L'un d'entre eux est la fonctionnalité partagée de mise en cache. Chacun de ces trois moteurs fonctionne main dans la main avec la mise en cache en mémoire pour améliorer les performances de son traitement sans modifier le format de stockage principal, atteignant des temps de réponse inférieurs à la seconde. HBase a le BlockCache, Hive a la couche LLAP IO et Druid a plusieurs options de mise en cache en mémoire. Souvent, la partie coûteuse du traitement d'une requête implique l'analyse de la requête et l'accès au magasin persistant pour récupérer le sous-ensemble de données qui intéresse l'utilisateur. Cette étape entière peut cependant être évitée lors de l'utilisation d'un mécanisme de mise en cache en mémoire, car de nombreux formats de stockage en colonnes utiliser, permettant au processus d'accéder à la mémoire pour les données précédemment interrogées en quelques fractions de seconde. Revenons à notre exemple de calcul de carburant :disons que je viens de demander la moyenne des miles parcourus pour tous les vols de mon entreprise, mais sachez que les vols intérieurs auront des besoins en carburant très différents des vols internationaux. Je souhaiterai ensuite filtrer ma requête précédente avec une clause WHERE country='US' (ou code de pays équivalent). Ce modèle de requête est très courant pour l'exploration de données. Comme nous avons déjà en mémoire les données de la requête précédente, les résultats de cette requête peuvent être renvoyés sans avoir à effectuer une lecture coûteuse du disque.

La structure de la couche LLAP de Hive - une partie de son espace mémoire est utilisée pour la mise en cache, tandis que le stockage à long terme est sur HDFS. HBase et Druid ont également un concept similaire de cache et de stockage.

Une autre similitude existe dans les raccourcis que chacun de ces moteurs utilise pour se concentrer sur les données spécifiques qui sont interrogées. HBase a un accès aléatoire O(1) basé sur HashMap, Druid utilise des index bitmap inversés pour déterminer quelles valeurs de colonne se trouvent dans quelles lignes, et les tables Hive ont des statistiques, des index et un partitionnement pour raccourcir l'accès aux données. Ces fonctionnalités permettent aux moteurs de combiner la manière dont les données sont stockées avec la manière dont elles sont accessibles, permettant une analyse rapide tout en optimisant l'efficacité du matériel et en tirant le meilleur parti du processeur et de la RAM disponibles.

La dernière similitude est la préparation à l'entreprise de chacun de ces moteurs. Du côté de la redondance des données, ces trois moteurs utilisent HDFS comme mécanisme de stockage en profondeur; le facteur de réplication HDFS de 3x garantit que des copies des données existent ailleurs même si deux nœuds échouent simultanément. Les données peuvent être immédiatement répliquées à nouveau sur des nœuds sains pour maintenir la redondance. En ce qui concerne la tolérance aux pannes au sein d'un cluster, chaque outil comble le vide d'une manière ou d'une autre. HBase offre une réplication de région, Druid a une duplication des composants maître et travailleur ainsi qu'un facteur de réplication accru sur HDFS, et Hive a HDFS aux côtés de la logique tolérante aux pannes du framework YARN. La préparation de l'entreprise garantit que ces moteurs résistent aux pannes et sont prêts à fonctionner en production dès le premier jour.

Les différences entre nos moteurs de traitement de Big Data

Quelle est la meilleure façon d'ingérer des données ? Une fois que vous avez ingéré vos données, comment en tirez-vous rapidement des informations ? Voyons comment ces trois moteurs de traitement de données volumineuses prennent en charge cet ensemble de tâches de traitement de données

Ces moteurs sont parfois regroupés mentalement et pensés de la même manière en raison de leur capacité à stocker et à traiter le Big Data, mais comme nous le verrons, ils sont choisis pour des cas d'utilisation et des objectifs spécifiquement adaptés à leurs points forts. Vous verrez que la collection d'outils que contient la plate-forme de données Hortonworks est bien adaptée à toute charge de travail de Big Data que vous pouvez lui lancer, en particulier avec HDP 3.0 et les capacités de base de données en temps réel que nous avons introduites.

Hive est le moteur OLAP représentatif du plus grand nombre de cas d'utilisation, utilisant le plus souvent le système de fichiers distribués Hadoop (HDFS) comme couche de stockage pour permettre le stockage de presque tous les types de données. Il peut interroger, traiter et analyser des données textuelles non structurées, des fichiers CSV, XML, JSON semi-structuré, Parquet en colonnes et une foule d'autres formats. Hive prend également en charge des supports de stockage alternatifs tels que le stockage Cloud, Isilon et autres. La norme de stockage de facto pour Hive est ORC, qui optimise le plus efficacement et récolte les avantages du stockage en colonne. Une fois converties en ORC, vos données sont compressées et les colonnes de votre table sont stockées séquentiellement sur le disque, ce qui permet à la couche de mise en cache en mémoire LLAP de Hive d'extraire les données du disque une fois et de les servir de la mémoire plusieurs fois. La combinaison de Hive + LLAP est utilisée pour l'analyse ad hoc, le calcul de grands agrégats et la création de rapports à faible latence. Un excellent cas d'utilisation pour Hive consiste à exécuter quotidiennement un ensemble de rapports de tableau de bord pour les utilisateurs ; les requêtes répétitives profitent non seulement du cache LLAP, mais également de la fonction "Query Results Cache" - qui renvoie des résultats quasi instantanés si les données n'ont pas changé (à part :le cache des résultats de la requête est une fonctionnalité disponible dans Hive 3.0 - publié en HDP 3.0). Parallèlement à cela, un entrepôt de données Hive est une excellente utilisation des analyses ad hoc dont Hive est capable; les utilisateurs peuvent joindre des données, exécuter des requêtes simultanées et exécuter des transactions ACID. Considérez Hive comme une prise SQL de tous les métiers à cet égard, tandis que les deux autres moteurs offrent des performances extrêmement rapides pour des cas d'utilisation de niche spécifiques.

Notre deuxième moteur, HBase, est un magasin clé-valeur distribué doté de capacités de lecture, d'écriture, de mise à jour et de suppression aléatoires. HBase (une variante NoSQL) est conçu pour être un moteur OLTP, permettant une architecture d'opérations transactionnelles à volume élevé - pensez aux plates-formes de messagerie avec des messages constants échangés entre les utilisateurs ou des transactions générées dans un système financier. HBase est extrêmement efficace pour importer rapidement des données, les stocker et les restituer - insertions/mises à jour/suppressions aléatoires à latence ultra-faible. Ce pour quoi il n'est pas conçu, c'est l'agrégation et la jonction de données - cette fonctionnalité est réalisée via Phoenix, une couche et un moteur SQL au-dessus de HBase, mais n'est pas recommandée pour de plus grandes quantités de données car les données ne sont pas structurées de manière à obtenir une performances (utilisez plutôt Hive). Pour résumer, HBase est excellent pour traiter de gros volumes d'opérations de création-mise à jour-suppression, mais ne parvient pas à présenter ces données dans un format consommable pour les utilisateurs.

Enfin, Druid est le troisième moteur et celui qui convient aux charges de travail de séries temporelles OLAP à faible latence ainsi qu'à l'indexation en temps réel des données de streaming. Druid fournit des requêtes OLAP à la vitesse du cube pour votre cluster. La nature chronologique de Druid est la pierre angulaire du moteur ; il est conçu de cette façon car le temps est un filtre principal lors de l'analyse des données temporelles. Pensez au moment où vous analysez les horaires de vol pour réserver un voyage - je veux connaître le vol le moins cher vers l'Italie dans ce laps de temps particulier de 2 semaines. Druid correspond au créneau d'être très rapide pour ingérer des données et les localiser à la demande. D'autre part, il permet également aux utilisateurs professionnels et aux analystes d'interroger les données et de les comprendre via Superset, une couche de visualisation étroitement liée à Druid. Druid excelle dans la localisation d'une poignée de lignes de données parmi des centaines de millions ou de milliards en moins d'une seconde, et il excelle également dans le calcul extrêmement rapide de valeurs agrégées sur ce même volume de données. Cependant, il ne fait pas de jointures et ne peut donc pas être utilisé pour combiner des ensembles de données à des fins d'analyse. Si vous envisagez d'analyser une combinaison d'ensembles de données dans Druid, il serait judicieux de pré-joindre les données avant de les insérer dans Druid ou d'utiliser Hive (et les tables Hive basées sur Druid) pour effectuer des jointures. En d'autres termes, Druid s'intègre bien dans le rôle d'être le dernier arrêt pour vos données après qu'elles ont été traitées et transformées en la façon dont vos utilisateurs professionnels y accéderont. Druid est idéal pour les analystes commerciaux car ils peuvent se connecter à Superset et visualiser les métriques sous forme de tableau de bord sans avoir à écrire de requêtes; ils utilisent simplement une interface graphique pour sélectionner la source de données de la requête et les filtres. Il est également idéal comme source de données de sauvegarde pour les tableaux de bord système, qu'ils soient opérationnels ou analytiques, en raison de ses temps de requête rapides.

Voici une façon de décomposer la prise de décision sur l'outil à utiliser pour votre charge de travail :

SQL unifié

Nous avons discuté de plusieurs systèmes jusqu'à présent et chacun a sa propre façon d'accéder à ses données. C'est formidable lorsque vos utilisateurs savent comment fonctionnent tous ces outils, mais ils peuvent avoir une courbe d'apprentissage avant de pouvoir atteindre leur pleine productivité s'ils viennent d'un monde de SQL, SQL et plus de SQL comme le font la plupart des analystes. C'est pourquoi nous avons essayé de rendre cette interaction aussi simple que possible; avec Hive 3.0 dans HDP 3.0, vous pouvez utiliser la syntaxe HQL de type SQL de Hive pour interagir avec autant de magasins de données différents dans cet espace. Hive peut être utilisé comme un portail pour accéder et modifier Druid, HBase et tout ce qui fournit une interface et un pilote JDBC. Hive peut être utilisé pour administrer une tâche d'ingestion Druid qui écoute Kafka, offrant un moyen simple d'ingestion en temps réel. Et enfin, Hive peut être utilisé pour tout rassembler - stocker vos données là où cela a le plus de sens et y accéder à partir d'un seul endroit. Joignez-le ensemble, peut-être même stockez ce nouveau résultat dans un autre endroit. Les possibilités sont nombreuses, mais l'interface a été grandement simplifiée afin que votre base d'utilisateurs puisse passer moins de temps à apprendre un autre outil et plus de temps à apporter de la valeur à l'entreprise.

Conclusion

Hive, Druid et HBase ont tous des places différentes dans une architecture de données, comme nous l'avons vu dans l'analyse précédente. Ce sont cependant des outils complémentaires; vous pouvez ingérer des données transactionnelles avec HBase avec ses recherches rapides, déplacer ces données dans Druid pour une exploration/agrégation rapide, et faire en sorte que Hive intègre les deux avec ses propres données gérées par Hive pour permettre aux utilisateurs de combiner des données où qu'elles se trouvent pour une vue unique et une richesse d'idées. Avec cette approche, Druid stocke des données accessibles par elles-mêmes, mais cette fonctionnalité est augmentée par Hive, qui peut extraire des données Druid et les joindre à des données supplémentaires. Ajoutez à cela les améliorations majeures qui sont entrées en jeu avec Hive 3.0, dont les vues matérialisées, des intégrations améliorées avec Druid ainsi que de nombreux autres moteurs, et une fonctionnalité accrue de type entrepôt de données, et vous avez un groupe d'outils qui peuvent résoudre à peu près n'importe quel cas d'utilisation.

Les architectures telles que celles mentionnées ci-dessus apportent le meilleur de chaque outil pour optimiser votre flux de travail et en même temps résumer les détails pour les utilisateurs uniquement concernés par les données. Les architectes ont configuré les pipelines, en plaçant les données à leur place en fonction du cas d'utilisation. Cela conduit ensuite aux analystes de données, qui utilisent Hive comme interface unique pour acquérir des connaissances et des informations. Ils sont capables de trouver des modèles intéressants dans les données plutôt que de se soucier de l'endroit où les données sont stockées ou d'apprendre une nouvelle syntaxe pour y accéder - vous seriez surpris de découvrir à quelle fréquence nous voyons cela dans le monde.

À ce stade, nous avons démontré les forces, les faiblesses et les meilleures pratiques de chaque outil ; nous espérons que vous repartirez avec une meilleure compréhension de ce qui convient à quel endroit, ainsi qu'une vue d'ensemble de la combinaison des trois pour obtenir les meilleurs résultats.