Problème de Big Data
Les volumes de Big Data augmentent de manière exponentielle. Ce phénomène se produit depuis des années, mais son rythme s'est considérablement accéléré depuis 2012. Consultez ce blog intitulé Big Data Just Beginning to Explode du CSC pour un point de vue similaire sur l'émergence du Big Data et les défis qui y sont liés.
IRI est au courant de cette tendance depuis la création de l'entreprise à la fin des années 1970. Son package phare CoSort est conçu pour gérer des volumes de données croissants grâce à l'efficacité des algorithmes et de la conception des logiciels, aux techniques d'exploitation du matériel « portable » et à la consolidation des tâches (par exemple, trier-joindre-agréger-chiffrer-rapport). La question que pose cet article est une question d'approche face à "l'essor des machines".
Limitation du matériel pour résoudre ce problème
De toute évidence, les performances des ordinateurs se sont accélérées à presque tous les égards depuis des décennies. Et pour beaucoup, jeter du matériel sur le problème du Big Data est simplement une seconde nature. Cependant, le problème peut être plus important que cela. Considérez la loi de Moore, dans laquelle la puissance du processeur ne fait que doubler tous les 18 mois au mieux, et l'obsolescence inhérente, les problèmes de maintenance et les coûts purs d'une stratégie centrée sur le matériel.
Une autre nouveauté à prendre en compte est également l'attente que ce paradigme de performance pour le Big Data touche à sa fin. Selon Gery Menegaz, sa prémisse est que la fin de la loi de Moore est proche. Time Magazine a publié un article similaire en mai 2012 intitulé "L'effondrement de la loi de Moore : Le physicien dit que c'est déjà arrivé". D'après l'article du Time,
Compte tenu de cela, Kaku dit que lorsque la loi de Moore s'effondrera finalement d'ici la fin de la prochaine décennie, nous "la modifierons simplement un peu avec des ordinateurs de type puce en trois dimensions". Au-delà de cela, dit-il, "nous devrons peut-être passer aux ordinateurs moléculaires et peut-être à la fin du XXIe siècle aux ordinateurs quantiques".
Pour la plupart des utilisateurs, cependant, leur matériel est acheté pour gérer, et dans une certaine mesure, évoluer, pour relever les défis de traitement des mégadonnées auxquels ils sont confrontés ou prévoient. Mais moins le logiciel qui y est exécuté est efficace, plus il faut dépenser de ressources matérielles pour surmonter l'inefficacité. Un exemple dans notre monde pourrait être d'acheter un IBM p595 pour exécuter /bin/sort alors qu'une machine d'un tiers de cette taille et de ce coût exécutant CoSort à la place produirait le même résultat.
Pendant ce temps, les appliances DB et ELT comme Exadata et Netezza construites autour du matériel nécessitent déjà des investissements de 6 à 7 chiffres. Et bien qu'ils puissent évoluer pour prendre en charge des charges plus importantes, il y a généralement une limite à leur capacité d'évolution (certainement pas de manière exponentielle), à la somme d'argent pouvant être dépensée pour tenter de continuer à évoluer et à la volonté des gens de s'appuyer sur un fournisseur unique pour chaque aspect critique de leurs charges de travail. Et est-ce une bonne idée d'imposer à la place la surcharge de la transformation du Big Data dans des bases de données conçues pour l'optimisation du stockage et de la récupération (requête) ?
Même si toutes ces questions avaient des réponses faciles, comment résoudre les problèmes de calcul (même avec une croissance linéaire du Big Data) qui nécessitent une consommation de ressources exponentiellement plus importante (comme le tri) ? D'une manière ou d'une autre, la réponse ne semblerait pas résider dans la simple attente d'une informatique quantique abordable…
Le rôle des logiciels
Comme le savent Hadoop et les architectes d'entrepôts de données, le tri (ainsi que les opérations de jointure, d'agrégation et de chargement dans ETL qui s'appuient sur le tri) est au cœur du défi du traitement des mégadonnées et un consommateur exponentiel de ressources informatiques. À mesure que le Big Data double, les besoins en ressources pour le trier peuvent tripler. Par conséquent, les algorithmes, les techniques d'exploitation du matériel et les schémas de traitement impliqués dans les logiciels de tri multiplateformes et multicœurs sont les clés de la gestion de ce problème de manière évolutive, abordable et efficace.
Contribution de CoSort
Les performances de CoSort évoluent de manière linéaire en volume, plus dans le sens de la loi d'Amdahl. Alors que CoSort peut transformer des centaines de gigaoctets de données volumineuses en quelques minutes avec quelques dizaines de cœurs, d'autres outils peuvent prendre plus de deux fois plus de temps, ne pas évoluer aussi bien et/ou consommer plus de mémoire et d'E/S dans le processus. Peut-être plus important encore, CoSort intègre le tri directement dans les applications associées et fait tout le gros du travail en dehors de la couche DB et BI où les données intermédiaires seraient moins efficaces.
L'architecture de co-routine de CoSort déplace les enregistrements entre le trieur et des programmes tels que SortCL (l'utilitaire de transformation, de filtrage, de recherche, de création de rapports, de migration et de protection des données de CoSort) de manière interactive, via la mémoire. Ainsi, dès que le prochain enregistrement trié est disponible, il peut se déplacer dans l'application, se charger, etc. Il semble à l'application qu'il lit un fichier d'entrée, mais en réalité, le back-end de la source n'a pas encore été produit. Et non, vous ne devancerez pas le trieur.
Fin 2015, CoSort est également devenu le moteur de la plate-forme moderne de gestion et de manipulation de données volumineuses d'IRI, Voracity. Voracity exploite les moteurs CoSort ou Hadoop de manière transparente.
Conclusion
On ne peut pas compter sur les seules ressources informatiques physiques pour répondre à la problématique du traitement du Big Data. L'environnement logiciel CoSort est un environnement dans lequel la transformation de données volumineuses requise et les tâches associées ne s'exécutent pas en tant que processus autonomes, mais en parallèle au cours de la même passe d'E/S.
Donc, si vous avez besoin d'un tri rapide à d'autres fins que le temps de tri, vous devriez réfléchir à ce qui se passe en aval du tri et aux meilleurs moyens de relier ces processus entre eux. Et une fois que vous avez déterminé le meilleur paradigme d'exécution, pouvez-vous alors combiner un matériel haute performance avec un tel logiciel pour optimiser les performances ? Pouvez-vous organiser des données DW avec CoSort du côté serveur de base de données d'Exadata, par exemple ? Ou serait-il plus judicieux de conserver votre IBM p595 et d'ajouter CoSort pour tripler le débit ? Ou si vous avez l'intention d'utiliser Hadoop, envisagez d'utiliser les mêmes mappages 4GL simples de CoSort ou ETL intuitifs de Voracity pour piloter les tâches MapReduce 2, Spark, Storm ou Tez.
Laissez votre budget et votre imagination vous guider pour faire face à la croissance des données.
