Lorsque SQL ne suffit pas: contrôles pour les nouveaux centres de données volumineux

Auteur: Judy Howell
Date De Création: 3 Juillet 2021
Date De Mise À Jour: 1 Juillet 2024
Anonim
Lorsque SQL ne suffit pas: contrôles pour les nouveaux centres de données volumineux - La Technologie
Lorsque SQL ne suffit pas: contrôles pour les nouveaux centres de données volumineux - La Technologie

Contenu



À emporter:

Les développeurs et les ingénieurs doivent continuellement s’efforcer d’accélérer et d’améliorer les services sur des plates-formes qui se sont développées bien au-delà de leurs archétypes classiques des années 1990.

Avec tout l’engouement pour les énormes centres de données de la NSA qui contiennent des milliards de données sur notre vie privée, il ya une chose dont on n’a pas beaucoup parlé, du moins sur CNN. Il s'agit d'un problème d'ingénierie qui a émergé avec la technologie cloud, les données volumineuses et les impressionnants centres de stockage de données physiques actuellement en construction dans le monde entier. Alors c'est quoi? Peu importe qui administre l’un des énormes systèmes informatiques qui exploitent ces installations, il est nécessaire de disposer de systèmes logiciels permettant à toutes ces données d’entrer rapidement dans le pipeline. Ce besoin constitue l’une des questions ou des énigmes informatiques les plus intéressantes pour les professionnels.


Comme le soulignent de nombreux experts, la demande extrême actuelle en matière de traitement de données va bien au-delà des approches traditionnelles. En termes simples, l’utilisation de structures de base de données et d’outils simples, tels que l’interface de requête SQL, ne fournira pas assez de puissance de traitement ni de fonctionnalités pour les systèmes propriétaires développés au cours des dernières années. Les archives des grandes entreprises technologiques ont besoin d’une technologie extrêmement évolutive. Ils ont besoin d'outils de traitement de données capables d'entrer et de produire des volumes beaucoup plus importants qu'un serveur unique. Ils ont besoin de solutions évolutives pour la croissance, comprenant des niveaux complexes d’intelligence artificielle, conçues pour faciliter la gestion par un service informatique.

La question qui se pose est de savoir comment les entreprises et les agences gouvernementales peuvent-elles surmonter les limites du processus traditionnel de traitement des données? Voici une option très prometteuse: un logiciel qui gère le Big Data et l’administration de plusieurs centres de données.


Système de fichiers Google: une grande étude de cas

La technologie propriétaire utilisée par Google pour accéder à ses centres de données est l'un des meilleurs exemples de modèles courants de traitement de données volumineuses et d'administration de centres de données multiples. Le système de fichiers Google (GFS), développé en 2003, est conçu pour prendre en charge l’énorme volume d’amendements à grande vitesse des systèmes de données, qui permettent de faire entrer autant de nouvelles informations dans une plate-forme unique et que des millions d’utilisateurs cliquent dessus. le même temps. Les experts appellent cela un système de fichiers distribué et utilisent le terme "stockage d'objets de données" pour décrire ces techniques extrêmement complexes. En réalité, cependant, ces termes ne décrivent même pas la surface en décrivant ce qui est à l’œuvre.

Individuellement, les fonctionnalités et les composants d'un système tel que GFS ne sont peut-être plus révolutionnaires, mais ils sont complexes. Beaucoup d’entre elles ont été couvertes sur ce site en tant qu’innovations relativement nouvelles qui font partie des fondements d’un nouveau système informatique mondial toujours connecté et toujours connecté. Ensemble, un système tel que GFS est bien plus que la somme de ses composants: c’est un réseau en grande partie invisible, mais extrêmement complexe, qui regorge d’éléments de données individuels projetés de cette manière et qui, s’ils sont entièrement modélisés visuellement, ressemblent à du chaos. Comprendre où vont toutes les données demande beaucoup d’énergie et d’engagement, comme le reconnaîtront ceux qui gèrent les stations de combat de ces systèmes.

"Il y a trop de détails qui ont un impact profond sur les domaines d'utilisation - y compris la fragmentation externe et interne, les mises à jour basées sur les journaux vs sur place et les niveaux de cohérence des transactions - pour résumer la façon dont cela fonctionne en une phrase succincte ", déclare Momchil Michailov, PDG et cofondateur de Sanbolic.

"Un système de fichiers distribué est soit un agrégateur distribué d'espaces de noms locaux et d'espaces libres des noeuds participants, soit un système de fichiers local qui s'exécute sur plusieurs noeuds accédant à un stockage partagé à l'aide d'un composant de gestionnaire de verrouillage distribué", a-t-il déclaré.

Kerry Lebel est chef de produit principale chez Automic, une société reconnue pour ses plates-formes d'automatisation évolutives. Selon M. Lebel, bien qu’il soit juste de décrire un DFS comme un système qui assigne simplement des charges de travail à des serveurs connectés à du matériel peu coûteux, cela ne dit pas tout.

Pas de bugs, pas de stress - Votre guide étape par étape pour créer un logiciel qui change la vie sans vous détruire

Vous ne pouvez pas améliorer vos compétences en programmation lorsque personne ne se soucie de la qualité des logiciels.

"Ce que vous finissez par manquer est tout le facteur cool de Comment ils font ce qu'ils font ", a déclaré Lebel.

Lorsque vous vous éloignez des détails techniques et que vous ne pensez qu'à l'idée de base du système de fichiers distribué, le "facteur cool" dont parle Lebel est évident. Ces systèmes de traitement de données volumineuses remplacent les anciens systèmes de fichiers / dossiers par des structures qui impliquent non seulement de multiples systèmes de livraison, mais également une approche "orientée objet", dans laquelle un grand nombre d'unités sont tronquées ici et là pour éviter les goulots d'étranglement.

Pensez, par exemple, à un système routier ultramoderne, où des centaines de milliers de voitures ne sont pas simplement acheminées dans une file à plusieurs voies, mais ramassées dans de jolis petits affluents en forme de feuille de trèfle ou d'arc-en-ciel, qui sont tournés et envoyés vers leurs destinations sur une variété de détours. Du ciel, tout a l'air chorégraphié comme une montre suisse. C’est le type de modèle visuel que les ingénieurs examinent lorsqu’ils imaginent de nouvelles méthodes pour acheminer les informations en fonction des limitations en les «appliquant» à différents niveaux d’un schéma de confinement de données à plusieurs niveaux. Laissant de côté les spécifications, il s’agit de l’objectif principal d’un système de traitement: maintenir les objets autonomes avec leurs métadonnées incorporées à la vitesse maximale qui leur convient, pour atteindre les objectifs de cohérence, satisfaire un utilisateur final ou même pour informer une observation ou une analyse de haut niveau.

Un regard sur la technologie de base

Un article de Sean Gallagher paru dans Ars Technica divise le design GFS en parties plus gérables et fait allusion à ce qui se trouve sous la feuille chez Google.

GFS commence par un modèle redondant et tolérant aux pannes pour la lecture et l'écriture de données. L'idée ici est qu'au lieu d'écrire une mise à jour spécifique sur un seul lecteur, les nouveaux systèmes écrivent des blocs de données vers plusieurs destinations. De cette façon, si une écriture échoue, les autres resteront. Pour répondre à cela, un composant réseau principal met en réseau le traitement des données avec d'autres unités subordonnées, en regroupant à nouveau les données lorsqu'un client les "appelle". Tout cela est rendu possible par un protocole de métadonnées qui aide à identifier où se trouvent certaines mises à jour et résultats de transmission dans le système le plus large.

Un autre aspect très important de ceci est la manière dont ces systèmes très dupliqués imposent la cohérence des données. Comme le note Gallagher, la conception de GFS sacrifie une certaine cohérence tout en "renforçant l'atomicité" ou en protégeant le principe de la mise à jour des données sur plusieurs unités de stockage afin qu'elles correspondent au fil du temps. Le "modèle de cohérence assoupli" de Google semble suivre la théorie essentielle du modèle BASE, qui offre plus de flexibilité en échange d’un délai plus long pour l’application cohérente des règles.

Comment les autres grands systèmes y parviennent-ils?

"Lorsqu'une échelle suffisamment grande est atteinte, des incohérences ou des corruptions des données deviennent inévitables", explique Michailov. "Par conséquent, l'un des principaux objectifs des systèmes de fichiers distribués devrait être de pouvoir effectuer autant d'opérations que possible en présence de corruption, tout en fournissant des méthodes efficaces pour traiter simultanément la corruption." Michailov mentionne également la nécessité de préserver les performances grâce à une mise en œuvre prudente des redondances.

"Par exemple, la création de métadonnées (données concernant les données) sur chaque disque permet à ce disque de reconstruire sa structure de données appropriée si sa copie miroir est corrompue", a déclaré Michailov. "En outre, les niveaux RAID peuvent être utilisés pour lutter contre les défaillances de stockage au niveau de l'agrégateur de système de fichiers ou du gestionnaire de volumes partagés."

Dans ses discussions sur un autre modèle de cohérence, Lebel se concentre sur un système appelé système de fichiers distribués Hadoop (HDFS), qu’il appelle «norme de facto de l’industrie».

En HDFS, dit Lebel, chaque bloc de données est répliqué trois fois sur des nœuds différents et sur deux racks différents. Les données sont vérifiées de bout en bout. Les échecs sont signalés à NameNode, un gestionnaire de données qui supprime les blocs corrompus et en crée de nouveaux.

Tout cela prend en charge les types de "données propres" qui sont si importants pour l’intégrité de l’un de ces systèmes de données en masse.

Maintenir un DFS

Un autre regard très différent sur GFS provient d'un article d'octobre 2012 de Steven Levy, écrivain de Wired. Il est beaucoup plus bref de décrire l’approche logicielle utilisée pour la gestion collective du réseau top-down de Google.

"Au fil des ans", écrit Levy, "Google a également mis au point un système logiciel lui permettant de gérer ses innombrables serveurs comme s'il s'agissait d'une seule et même entité géante. Ses développeurs internes peuvent se comporter comme des maîtres de marionnettes, distribuant des milliers d'ordinateurs tâches aussi facilement que d’exécuter une seule machine ".

Cela implique également des tonnes de maintenance cyber et environnementale, allant d'équipes de test dédiées tentant de "casser" les systèmes de serveur, à des températures soigneusement contrôlées dans les halls de la cryptographie.

Levy mentionne également des technologies supplémentaires pour GFS, telles que MapReduce, un outil d'application dans le cloud, et Hadoop, un moteur d'analyse qui partage certains principes de conception avec GFS. Ces outils ont leur propre impact sur la conception des systèmes de traitement des grands centres de données et sur ce qui est susceptible de se produire à l’avenir. (En savoir plus sur ces technologies dans The Evolution of Big Data.)

M. Michailov pense que MapReduce est capable de prendre en charge des systèmes de centre de données toujours plus grands et parle d'une "implémentation unique" de systèmes de fichiers partagés et agrégés qui pourraient "conserver les nœuds de noms d'un système de fichiers agrégés dans un cluster partagé avec SSD pour le stockage. . "

Pour sa part, Lebel envisage de passer du traitement par lots (méthode prise en charge par Hadoop) au traitement en continu, ce qui rapprochera ces opérations de données du temps réel.

"Plus nous pourrons traiter les données et les mettre rapidement à la disposition des décideurs ou de nos clients, plus nous disposerons d'un avantage concurrentiel", a déclaré Lebel, qui propose également de remplacer la terminologie de traitement susmentionnée par des termes axés sur les utilisateur final. En pensant aux activités "synchrones", ou synchronisées avec les actions des utilisateurs finaux, et aux activités "asynchrones" qui sont plus flexibles en termes de mise en œuvre, Lebel indique que les entreprises peuvent utiliser des SLA et d'autres ressources pour définir le fonctionnement d'un système de service donné. .

En un sens, tout cela résume le fait que les développeurs et les ingénieurs doivent continuellement s’efforcer d’accélérer et d’améliorer les services sur des plates-formes qui se sont développées bien au-delà de leurs archétypes classiques des années 1990. Cela signifie examiner de manière critique le mécanisme des données et surmonter les goulets d'étranglement de manière à soutenir non seulement une population croissante, mais également ce changement exponentiel qui se produit à une vitesse vertigineuse que les experts appellent "la prochaine révolution industrielle". Il est probable que ceux qui ont fait le plus de progrès sur ces fronts finiront par dominer les marchés et les économies de demain.