Les 7 projets Hadoop et Spark les plus courants

Il y a un vieil axiome qui dit quelque chose comme ceci: si vous offrez à quelqu'un votre soutien total et votre soutien financier pour faire quelque chose de différent et d'innovation, il finira par faire ce que tout le monde fait.

Il en va de même avec Hadoop, Spark et Storm. Tout le monde pense faire quelque chose de spécial avec ces nouvelles technologies Big Data, mais il ne faut pas longtemps pour rencontrer les mêmes modèles encore et encore. Les implémentations spécifiques peuvent différer quelque peu, mais d'après mon expérience, voici les sept projets les plus courants.

Projet n ° 1: Consolidation des données

Appelez cela un «hub de données d'entreprise» ou un «lac de données». L'idée est que vous disposez de sources de données disparates et que vous souhaitez effectuer une analyse entre elles. Ce type de projet consiste à obtenir des flux de toutes les sources (en temps réel ou par lots) et à les pousser dans Hadoop. Parfois, c'est la première étape pour devenir une «entreprise axée sur les données»; parfois vous voulez simplement de jolis rapports. Les lacs de données se matérialisent généralement sous forme de fichiers sur HDFS et de tables dans Hive ou Impala. Il existe un nouveau monde audacieux où une grande partie de cela apparaît dans HBase - et Phoenix, à l'avenir, parce que Hive est lent.

Les vendeurs aiment dire des choses comme "schéma à la lecture", mais en vérité, pour réussir, vous devez avoir une bonne idée de ce que seront vos cas d'utilisation (ce schéma Hive ne sera pas très différent de ce que vous feriez dans un entrepôt de données d'entreprise). La vraie raison d'un lac de données est l'évolutivité horizontale et un coût bien inférieur à celui de Teradata ou Netezza. Pour «l'analyse», de nombreuses personnes configurent Tableau et Excel sur le front-end. Les entreprises plus sophistiquées avec de «vrais data scientists» (des geeks de maths qui écrivent du mauvais Python) utilisent Zeppelin ou iPython notebook comme interface.

Projet n ° 2: Analyse spécialisée

De nombreux projets de consolidation de données commencent en fait ici, où vous avez un besoin particulier et que vous tirez un ensemble de données pour un système qui effectue un type d'analyse. Celles-ci ont tendance à être incroyablement spécifiques à un domaine, comme les simulations de risque de liquidité / Monte Carlo dans une banque. Dans le passé, ces analyses spécialisées dépendaient de packages propriétaires désuets qui ne pouvaient pas évoluer comme les données et souffraient fréquemment d'un ensemble de fonctionnalités limité (en partie parce que le fournisseur de logiciels ne pouvait pas en savoir autant sur le domaine que l'institution immergé dedans).

Dans les mondes Hadoop et Spark, ces systèmes ressemblent à peu près aux systèmes de consolidation de données, mais ont souvent plus de HBase, de code non SQL personnalisé et moins de sources de données (si ce n'est une seule). De plus en plus, ils sont basés sur Spark.

Projet n ° 3: Hadoop en tant que service

Dans toute grande organisation avec des projets d '«analyse spécialisée» (et ironiquement un ou deux projets de «consolidation de données»), ils vont inévitablement ressentir la «joie» (c'est-à-dire la douleur) de gérer quelques clusters Hadoop configurés différemment, parfois de différents vendeurs. Ensuite, ils diront: «Peut-être devrions-nous consolider cela et mettre en commun les ressources», plutôt que de laisser la moitié de leurs nœuds inactifs la moitié du temps. Ils pourraient passer au cloud, mais de nombreuses entreprises ne le peuvent pas ou ne le feront pas, souvent pour des raisons de sécurité (lire: politique interne et protection de l'emploi). Cela signifie généralement beaucoup de recettes Chef et maintenant des packages de conteneurs Docker.

Je ne l'ai pas encore utilisé, mais Blue Data semble avoir ce qui se rapproche le plus d'une solution prête à l'emploi ici, qui plaira également aux petites organisations manquant de moyens pour déployer Hadoop en tant que service.

Projet n ° 4: Analyse en continu

Beaucoup de gens appelleraient cela le «streaming», mais l'analyse du streaming est assez différente du streaming à partir d'appareils. Souvent, l'analyse en continu est une version plus en temps réel de ce qu'une organisation a fait par lots. Prenons la lutte contre le blanchiment d'argent ou la détection des fraudes: pourquoi ne pas faire cela sur la base des transactions et les détecter au fur et à mesure plutôt qu'à la fin d'un cycle? Il en va de même pour la gestion des stocks ou toute autre chose.

Dans certains cas, il s'agit d'un nouveau type de système transactionnel qui analyse les données petit à petit lorsque vous les transformez en un système analytique en parallèle. Ces systèmes se manifestent par Spark ou Storm avec HBase comme magasin de données habituel. Notez que l'analyse en continu ne remplace pas toutes les formes d'analyse; vous voudrez toujours faire apparaître des tendances historiques ou consulter des données passées pour quelque chose que vous n'avez jamais envisagé.

Projet n ° 5: Traitement d'événements complexes

Nous parlons ici du traitement des événements en temps réel, où les sous-secondes comptent. Bien que ce ne soit toujours pas assez rapide pour les applications à très faible latence (picoseconde ou nanoseconde), telles que les systèmes de trading haut de gamme, vous pouvez vous attendre à des temps de réponse en millisecondes. Les exemples incluent l'évaluation en temps réel des enregistrements de données d'appel pour les opérateurs télécoms ou le traitement d'événements Internet des objets. Parfois, vous verrez de tels systèmes utiliser Spark et HBase - mais généralement, ils tombent sur leurs visages et doivent être convertis en Storm, qui est basé sur le modèle Disruptor développé par l'échange LMAX.

Dans le passé, ces systèmes reposaient sur des logiciels de messagerie personnalisés - ou des produits de messagerie client-serveur prêts à l'emploi et performants - mais les volumes de données actuels sont trop importants pour l'un ou l'autre. Les volumes d'échanges et le nombre de personnes possédant des téléphones portables ont augmenté depuis la création de ces systèmes hérités, et les capteurs médicaux et industriels pompent trop de bits. Je ne l'ai pas encore utilisé, mais le projet Apex semble prometteur et prétend être plus rapide que Storm.

Projet n ° 6: Streaming en ETL

Parfois, vous souhaitez capturer des données en streaming et les entreposer quelque part. Ces projets coïncident généralement avec le n ° 1 ou le n ° 2, mais ajoutent leur propre portée et leurs propres caractéristiques. (Certaines personnes pensent qu'elles font le n ° 4 ou le n ° 5, mais en fait, elles vident sur disque et analysent les données plus tard.) Ce sont presque toujours des projets Kafka et Storm. Spark est également utilisé, mais sans justification, car vous n'avez pas vraiment besoin d'analyses en mémoire.

Projet n ° 7: Remplacement ou augmentation de SAS

SAS va bien; SAS est sympa. SAS est également coûteux et nous n'achetons pas de boîtes pour tous les scientifiques et analystes des données afin que vous puissiez «jouer» avec les données. De plus, vous vouliez faire quelque chose de différent de ce que SAS pourrait faire ou générer un graphique plus joli. Voici votre joli lac de données. Voici iPython Notebook (maintenant) ou Zeppelin (plus tard). Nous allons introduire les résultats dans SAS et stocker les résultats de SAS ici.

Alors que j'ai vu d'autres projets Hadoop, Spark ou Storm, ce sont les types «normaux» de tous les jours. Si vous utilisez Hadoop, vous les reconnaissez probablement. Certains des cas d'utilisation de ces systèmes que j'ai mis en œuvre des années auparavant, en travaillant avec d'autres technologies.

Si vous êtes un vétéran trop effrayé par le «gros» du big data ou le «do» dans Hadoop, ne le soyez pas. Plus les choses changent, plus elles restent les mêmes. Vous trouverez de nombreux parallèles entre les éléments que vous aviez l'habitude de déployer et les technologies hipster qui tourbillonnaient dans l'hadooposphère.